Add SWH upstream files

[jasp00]

LMMS only includes generated .c files for SWH, but it can be proved that at least since 14 May 2014 (swh/ladspa@7986492) the preferred form of the work for making modifications are upstream files (.xml, makestub.pl, etc.), which are not included. Because we have distributed LMMS without including the preferred form for making modifications, our rights under GPL have been automatically terminated. Versions since 1.0.3 should be fixed or withdrawn.

Ceasing violation does not restore rights and a new license should be acquired. I have run the following script and I believe I have gathered all missing permissions; this process would not be necessary if authors granted the permission in #3346. Committing this request will propagate the license.

Unfortunately, while identifying GPL dependencies, I noticed a GPL incompatibility in FluidSynth; see the Debian report for more information. The report shows that it is not enough to follow the spirit of the license, the letter matters too. Thus, FluidSynth is disabled.

[tresf]

@jasp00 get fluidsynth out of this PR. It's a separate issue.

Edit, opened new issue for fluidsynth here: #3490

[tresf]

Because we have distributed LMMS without including the preferred form for making modifications, our rights under GPL have been automatically terminated.

I feel you're trying to use LMMS as an example to prove your point about problems with the GPL in general. Why are you trying to make a spectacle of our bug tracker? It's like walking into the Post Office, realizing it doesn't have handicap accessibility and shutting the whole fucking thing down.

Wouldn't it be more progressive to just contact the author of this header and fix the source code?
Edit: Wrong topic, sorry.

Versions since 1.0.3 should be fixed or withdrawn.

Why 1.0.3 btw? Why such a special cutoff ? We've always distributed this as .c source.

In the case of swh, the source is identical, just in a different format, no?

[tresf]

Also pinging @swh.

[tresf]

@jasp00 it looks like gig player has an unobvious reliance on fluidsynth. This compile error should go away once you've removed the unrelated fluidsynth changes from this PR.

[swh]

For the record, while I maintain the source via .xml, and only accept patches to that, I have no problem with other people distributing the .c files as part of their projects. It's fairly common.

[jasp00]

Thanks, @swh. The problem is not on your side, but on ours because we want to mainstream changes, so our de facto preferred form for modifications are .xml files. It is a GPL requirement to include them.

Why 1.0.3 btw?

1.0.3 was released 9 July 2014 and it is the first release after 14 May 2014.

In the case of swh, the source is identical, just in a different format, no?

No, makestub.pl modifies all plug-ins and takes care of run and runAdding callbacks.

@jasp00 get fluidsynth out of this PR. It's a separate issue.

Project's rights under GPL have been automatically terminated. I cannot push any patch depending on FluidSynth without having my rights automatically terminated again.

[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.

[jasp00]

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?

[tresf]

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

Moving off-topic discussion here: #3490 (comment)

[tresf]

LMMS only includes generated .c files for SWH, but it can be proved that at least since 14 May 2014 (swh/ladspa@7986492) the preferred form of the work for making modifications are upstream files (.xml, makestub.pl, etc.), which are not included. Because we have distributed LMMS without including the preferred form for making modifications, our rights under GPL have been automatically terminated. Versions since 1.0.3 should be fixed or withdrawn.

I will quote one of the fsf guidelines for discovering a violation...

Community-oriented compliance work starts with carefully verifying violations and finishes only after a comprehensive analysis. This means fully checking reports and confirming violations before accusing an entity of violating the GPL. Then, all of the relevant software should be examined to ensure any compliance problems, beyond those identified in initial reports and those relating to any clauses of the relevant licenses, are raised and fixed. This is important so that the dialogue ends with reasonable assurance for both sides that additional violations are not waiting to be discovered. (Good examples of compliance already exist to help distributors understand their obligations.)

In this case, I feel you've failed to carefully verify the violation. Since @swh states this distribution form is common and often preferred for some projects, you've gone against this very basic principle when reporting a violation. Furthermore, it's up to the copyright holders to enforce GPL violations. Since you've now contributed code to the swh project, you're technically a copyright holder. Do you feel you are a better candidate for judging preferred distribution over the project maintainer? Furthermore, are you prepared to go after all other projects which distribute source in this same fashion? Last, do you think this properly reflects the mission of the fsf? </endless-conversation-topics>

our de facto preferred form for modifications are .xml files.

And we make those available in upstream.

But enough about the violation, it's a moot point if we merge this. The problem with this PR is that it disables an unrelated feature.

Since the PR actually adds some benefit to the code maintainability, I really want to reopen this but only after the fluidsynth disabling commit is removed.

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

Then I'll continue closing the PRs that toggle this off, unfortunately. I'd prefer not to do this. If we can find another way to restore and maintain your rights without toggling this off every time, that would be much preferred.

[jasp00]

If we can find another way to restore and maintain your rights without toggling this off every time, that would be much preferred.

I see three ways:

1. I submit patches that do not disable FluidSynth. Someone else would need to apply these patches.
2. I create LMMS/lmms branches that disable FluidSynth and I open PRs. Someone else would need to reenable it prior to merging.
3. I open PRs that disable FluidSynth. An automated task could reenable it after a merge; I can write this task.

[lukas-w]

I open PRs that disable FluidSynth. An automated task could reenable it after a merge

WTF

[jasp00]

An automated task could reenable it after a merge

lmms.io should be able to run automated tasks once LMMS/lmms.io#221 is addressed.

[tresf]

We can't afford to over-manage this flag and we certainly can't afford to lose you as a developer.

I create LMMS/lmms branches that disable FluidSynth and I open PRs. Someone else would need to reenable it prior to merging.

It sucks for both parties involved, but sure, I'll bite.

[jasp00]

If you are satisfied with this request, you should merge.

[tresf]

Before merging, we should remove the .c files that we bundle. This is two three fold...

1. It clarifies the preferred distribution mechanism is the xml format.
2. It makes for easier PRs back to upstream.
3. It removes code which is redundant.

What I'd like to see before merging:

• We should leverage a swh configure step that generates these .c files so that we can still edit them for troubleshooting purposes, but so that we don't have to rebuild all 100+ plugins on each build.
• A failed swh configure should disable the plugin and issue a warning; not break the build.
• This configure steps should be automatic and work without necessarily being triggered by programmer intervention.

So essentially, what we have, but upstream would be the ideal mergeable solution. This should address the licensing concerns without burdening the build process.

Long-term, we will be switching this to leverage a git submodule technique but since reproducible builds are of a concern, we should really handle that portion as a larger more comprehensive meta task and move towards #296.

[tresf]

Superseded by #3931.