fluidsynth license

[tresf]

@jasp00 can you please explain this stir you are causing?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859793

Edit: Also, https://github.com/LMMS/lmms/pull/3489/commits/4ec90b7a85c0a840a73cc1c53dac9b8f2eea5a1a

[tresf]

From your message to Debian...

       This source code is freely redistributable and may be used for
       any purpose.

The license does not grant the right to modify the software. Therefore, it is not compatible with GPL-2.1+ (sic) or LGPL-2.0+.

Are you implying the author in his words freely redistributable and may be used for any purpose does not explicitly or implicitly right to modify?

[tresf]

The Debian email thread has been updated. This is a file from the SoX project. The team is familiar with this library and this license and are working out the details with @jasp00.

[tresf]

I cannot push any patch depending on FluidSynth without having my rights automatically terminated again.

Then this PR is void. Commit project suicide elsewhere, please.

Could you explain what does that mean? What is it that you do not understand?

Yes, but I will only explain it once, and I have no interest in a discussion.

If any contributor is going to create a conquest where he/she must hold themselves in GPL violation by strict adherence to the discrimination clause, the unravelling effect is going to cut off the nose, despite the face of said project.

But it's a license, right? We need to follow it, right? Yes. However... although the long-term effect of this conquest... of the discriminatory words in GPL2 certainly affect us all, this isn't the time nor the place for anyone to prove a point about the GPL discrimination clause. The words in the GPL were intended to protect freedoms, not continually loophole projects into extinction. Removing fluidsynth from our project is an example of this, where we're deliberately removing a feature in speculation of an undecided upstream license ambiguity.

In the direct case of fluidsynth, a legally valid yet 100% regressive approach at compliance simply is suicide. Even if merits are founded in good faith, but if the execution seems targeted directly at the projects these freedoms were intended to protect, you've fucked up.

Although LMMS is tremendously lucky to finally regain a developer that actually does perform upstream code review, care about strict adherence and focus on these violations... although this insight is going to benefit the upstream libraries as well as LMMS for years to come, the severities imposed by this witchhunt are purely self-inflicted. The only report of violation is coming from the project itself. To put Debian and LMMS on the same playing field as "intentional repeat offenders" is taking contract law to a new low as it allows the enforcer to removing intent, remove merit, remove motive and worst, remove judgement, which are weighing factors in any law, in any court proceeding.

So in summary, I will continue to decline each PR that puts speculative violations in higher regard than the project itself. If this continues, I will also revoke your commit access to the project.

Edit: If a library does turn out to be in direct, deliberate GPL violation, LMMS will certainly do what's needed moving forward to unwind said library from the codebase. In the case of fluidsynth, we should monitor the conversation at the Debian mailing list, linked in the first post.

[jasp00]

To put Debian and LMMS on the same playing field as "intentional repeat offenders"

Who does that? What does all you have said have to do with closing issues and pull requests?

So, I point out legal problems in the project and I suggest how to fix them. In response, you refuse to fix the issues by closing them rather than waiting, you tell me that you will not discuss the problems, you do not want to understand them, and you threaten to kick me out if I report further legal matters. IMHO, you should not blame me for trying to protect the project and not wanting to infringe copyright myself.

If a library does turn out to be in direct, deliberate GPL violation, LMMS will certainly do what's needed moving forward to unwind said library from the codebase.

Are you aware of what "do what's needed" may mean? It may not be as easy as removing files from GitHub. In the event of copyright infringement, there is criminal and civil liability. Criminal one is unlikely to apply (for previous actions), but civil one is hard to avoid. You may be liable for downstream too, "no warranty" clauses are not an invincible shield.

I am sure you do not like this matter, neither do I, but I did not create it. You may be liable for your actions, do you not want to understand the situation? Developers may not transfer liability, but you are the one making decisions; do you assume the risk for the project? Do you want me to stop reporting legal hazards? Fine, I will help in other ways.

[jasp00]

do you not want to understand the situation?

You look like you want to understand. I will keep the discussion.

[tresf]

Rather than continuing in an endless discussion, I'd like to be very clear that if anyone is able to illustrate a measurable tort from or against the project or their members, they're very welcome here.

In this case, Copyright (C) 1998 Juergen Mueller And Sundry are the copyright holders and it is their right to raise a copyright violation against responsible parties. They haven't done this in 19 years and the license they chose is only in violation of GPL under vague interpretations.

Measuring downstream liability -- damages to which have occurred based on the actions of myself or LMMS as a whole.. are most likely to happen due to redistribution of source code combined with damages to the holder or in some events, the indirect damage caused by other projects downstream from us (think of a car you crash into flies into yet another car. We're the car in the middle).

Although I do feel this violation is worthy of fixing, I'm in strong disagreement as to the effect it has had on our PR process.

[midi-pascal]

@tresf :+1: Sometimes enough is enough. You have my entire support on this matter.

[jasp00]

So you do not understand the problem. I will explain gradually.

This source code is freely redistributable and may be used for any purpose.

Does this sentence unambiguously grant the right to modify the source code?

[jasp00]

I want you no harm, @tresf; I am only stating facts. Negligence is no valid defense; you know this is a violation. Do you not have the strength to discuss this? Then let someone else help you. @midi-pascal has expressed his entire support on this matter; this is a simple task an old programmer can handle.

[tresf]

Our stance is already stated above. Locking. Please instead fill up the fluidsynth tracker with this rhetoric.

[jasp00]

You are making it worse, @tresf.

[tresf]

Once the upstream decision is made, please let us know and we'll reopen this topic and start to discuss the repercussions -- if any -- it has on LMMS.

The project has an accepted workflow for this until a decision is reached.

[tresf]

Update from the Debian mailing list... I'm sure there will be more dialog about this.

I agree that the licenses in fluidsynth are not completely consisted and
Debian is right to make sure that they are.
However, it seems that chorus.c is now under the LGPL license. From
https://sourceforge.net/p/sox/code/ci/master/tree/COPYING:

  SoX source code is distributed under two main licenses. The two
  licenses are in the files LICENSE.GPL and LICENSE.LGPL. sox.c,
  and thus SoX-the user application, is distributed under the
  GPL, while the files that make up libsox are licensed under the
  less restrictive LGPL.

In the Makefile.am, you can see that chorus.c is part of libsox
(https://sourceforge.net/p/sox/code/ci/master/tree/src/Makefile.am).

I don't check the list of contributors to
fluidsynth_chorus.c. There was Markus Nentwig and me but surely
others, too. However, since fluidsynth was under LGPL
with "Copyright (C) 2003 Peter Hanappe and others" from the
beginning, I don't believe any contributors to
fluidsynth_chorus.c would object to putting their changes to that
file under the LGPL. I'll happily make my changes available under
that license.

So, because SoX/chorus.c is now under the LGPL and all the
changes that have been made between chorus.c and
fluidsynth_chorus.c fall under the LGPL, I believe that
fluidsynth_chorus.c can be put under the LGPL, too.

Cheers,
Peter

[tresf]

Update: This issue will be resolved once https://github.com/FluidSynth/fluidsynth/pull/177 is merged.

Note, if fluidsynth ever upgraded to LGPL 3.0, we won't be able to use it until we upgrade our own license to GPL 3.0 (pay close attention to the L in the fluidsynth license).

[zonkmachine]

Update: This issue will be resolved once FluidSynth/fluidsynth#177 is merged.

FluidSynth/fluidsynth#177 is now merged.