Business models and reasons to fund LMMS

[jasp00]

Following #3346...

LMMS as a music tool is the target market product. For some artists, it is a cheap DAW. Other users realize that this free program can run on their favorite platform; LMMS is supported on many architectures. As time passes, since there are many free audio projects compatible with GPL and free software is unlikely to die, there is a good chance that LMMS will become the best DAW or part of it.

There are some business models that apply to GPL. LMMS as a developing experience allows some job opportunities: programmers, designers, composers, etc. People may get paid for such activities.

The above models extend to GPL projects based on LMMS. A different problem are companies that sell closed-source software or projects that use other free licenses. Undoubtedly, you cannot integrate LMMS code into a non-GPL application or develop non-GPL binary plug-ins. However, non-GPL works can leverage LMMS because there are ways to "break" the GPL.

One method I will not explain is the use of the delay trick.

Any project may use LMMS from a user point of view. The application may be invoked with arguments to render and other useful actions; more operations can be added. A command-line interface may be implemented to allow scripted interaction. Even a GPLed library may be turned into a program that performs as you like, as long as you do not expose the API. This technique was suggested to decouple GPLv3 from LMMS.

Regarding plug-ins, like any covered work, you may develop them using LMMS code and GPL incompatible parts as long as:

1. The incompatible parts are not derived from LMMS code or API.
2. There is a clear separation between LMMS code and the incompatible parts.
3. You convey the LMMS code only in source form.
4. Whatever you convey together does not restrict GPL rights.

Users are free to compile from source. You may even convey an environment (compiler, controller scripts, etc.) to automate the process for the user. This technique was used by VeSTige before our aeffectx.h came to life.

Binary plug-ins may interact with non-GPL services:

• Plug-ins may invoke non-GPL tools; this is the reverse path of the decoupling technique above.
• They may load non-GPL user code, such as VST or LADSPA plug-ins.
• It is possible to communicate with online paid services.

So there are many reasons to contribute to LMMS, either economically or with human resources. GPL is about freedom of covered works, it is not against their usage. GPL allows many business models, even non-GPL development; it is a matter of software design.

[fundamental]

This sounds pretty optimistic. Is this intended to be a starting point for fundraising efforts or just a braindump?

[tresf]

GPL allows many business models, even non-GPL development; it is a matter of software design.

Perhaps, but don't make it sound better than it is. People can't make plugins for LMMS unless they are GPL-compatible, or unless they reverse-engineer the plugin architecture.

If LMMS ever wants to hold the title there is a good chance that LMMS will become the best DAW, it needs to drop GPL in some areas.

First, GPL is stupid for creative artwork. It doesn't even make sense. All presets, projects, sounds, graphics should be released under a Creative Commons license, NOT GPL.

Second, the plugin architecture should be a separate open license which doesn't restrict closing source. This isn't how I feel, this is just how the market will adopt it. The big plugin creators won't be compiling their expensive plugins against LMMS so as long as our plugin headers are GPL.

But my biggest complaint with GPL is the lack of bundling non-GPL components. For example, if Library X directly links against system Library Y and System Library Y is not GPL, GPL prohibits it. In the case of projects that leverage proprietary hardware features, this becomes problematic with the GPL license and we have to tell people to download and install components manually which is horrible software delivery and in my opinion, stifles "software design".

[PaulBatchelor]

Second, the plugin architecture should be a separate open license which doesn't restrict closing source.

I am for this. Any files needed to build plugins should have a more permissive license. This way, people could sell commercial LMMS plugins the same way FL Studio sells plugins.

[algorev]

MIT?

[unfa]

A bit of an OFF-TOPIC, but I think that there's some stuff to take care of before LMMS can get commercial attention.
There are still some very basic tools missing in the song editor like delete a selected block of regions. Copying a block of regions was introduced not long ago, and Linux users still can't have that without compiling from source.

[tresf]

Linux users still can't have that without compiling from source.

They can if someone helps with #2932. Please don't act helpless here. Identifying problems is different than helping solve them, and a Linux installer is something EVERYONE asks for but NO ONE actually steps up and helps out with. Copying and relinking libraries is trivial. Users (Windows and Mac alike) can have whatever they want, they just need to roll up their sleeves.

[SirBothersome]

@jasp00 , @tresf , this is all very interesting, but I think I see a snag in trying to change our current model. In order to use Qt Open Source, we are obliged to comply with certain terms https://www.qt.io/qt-licensing-terms/ I haven't read through them all, but if I remember correctly, they rather restrict some of the ideas you propose. This is probably waaaaay out of my field, but I thought I'd point that out anyways

[tresf]

@SirBothersome LGPL 2.1 is rather liberal about linking to proprietary code. VirtualBox (NOT OSE) is written in Qt and it contains several proprietary and closed source items.

Furthermore, Qt actually offers a proprietary/commercial license which is more than can be said for a lot of GPL and LGPL products. Proprietary plugins can always work out a licensing model with Qt if they need to. Remember, commercial is not the same as closed-source. ZynAddSubFX and Ardour are two examples of audio applications that are both open source AND commercial.

[fundamental]

To be clear, both Ardour and ZynAddSubFX are able to use GPLv2/GPLv2+ code with proprietary code by creating a clear boundary between the two differently licensed codebase (Ardour keeps mixbus in one or more plugins, Zyn keeps the new UI either out-of-process or in a dynamically loaded library with a publicly defined API). Additionally, the proprietary sections of each codebase were not originally opensourced via GPL or a GPL license at any point.

For LMMS a change of license would require an agreement from all the developers who contributed to the affected portion of the codebase, which seems impractical at this stage (or developing a new dynamically linked layer/sub-codebase, though dev resources appear to be stretched too thin for that to be practical).

[tresf]

People can't make plugins for LMMS unless they are GPL-compatible, or unless they reverse-engineer the plugin architecture.

I am for this. Any files needed to build plugins should have a more permissive license. This way, people could sell commercial LMMS plugins the same way FL Studio sells plugins.

LMMS [...] change of license would require

To be clear, the license change conversations were more about the plugin architecture and less about the 0.5 Million lines of GPL code that makes up LMMS. I think we all agree GPL can't be reverted at this point for the entire project, but limiting scope to only the plugin architecture would be much more feasible.

both Ardour and ZynAddSubFX are able to use GPLv2/GPLv2+ code with proprietary code by creating a clear boundary between the two differently licensed codebase (Ardour keeps mixbus in one or more plugins, Zyn keeps the new UI either out-of-process or in a dynamically loaded library with a publicly defined API)

Mark, I'm interested in knowing more about this process. I've read the GPLv2 several times and it really makes it hard to ship with proprietary. It is for this reason I personally favor the LGPL. For example, CutePDF uses a downloader to fetch the GPL components. I work on other projects where this becomes a hassle and I'd like to know more. I feel this would benefit me personally as well as the future of LMMS.

[fundamental]

On 03-07, Tres Finocchiaro wrote: Mark, I'm interested in knowing more about this process. I've read the GPLv2 several times and it really makes it hard to ship with proprietary. It is for this reason I personally favor the LGPL. For example, CutePDF uses a downloader to fetch the GPL components. I work on other projects where this becomes a hassle and I'd like to know more. I feel this would benefit me personally as well as the future of LMMS.

<Insert standard I am not a lawyer clause> The GPL defines the license in terms of how it affects 'The Program'. If there is a component that interacts with a piece of software which isn't considered to be a part of 'The Program' then the component is not bound by the GPL's restrictions. Per the GPL FAQ they state any plugin which can be run through fork()+exec() is not a part of 'The Program' and this is re-enforced by the stance of how the Linux kernel interacts with userspace applications with differing licenses. The case of plugins gets closer to a grey area, though a limited API which shares no data structures between the applications is generally accepted. This includes various audio plugin hosts loading plugins which may or may not have the same license as they may not be interpreted to be part of 'The Program'. In the case of Ardour's extensions (assuming my knowledge is accurate there), they are not bound to Ardour as they comply to a plugin specification which a variety of hosts use and thus they are not part of 'The Program' affected by Ardour's license. For ZynAddSubFX the UI accesses data through a network socket, it is capable of running on its own without a 'zynaddsubfx' process, and any text label information from ZynAddSubFX that it uses is stored in a json serialization which 'zynaddsubfx' produces. Given these pieces of functionality the 'zyn-fusion' program is not part of 'The Program' which makes up 'zynaddsubfx'. Similarly, Zyn-Fusion used (or previously used) libGLPK (a GPL licensed project) for layout, but only through the 'glpsol' binary through fork()/exec(), so 'zyn-fusion' was not affected by the license of 'libGLPK'. I am skeptical that a similar argument can be constructed for changing *just* the plugin subsystem of LMMS and arguing that the plugin subsystem is a separate program, though I may be misunderstanding your intent and the definitions of what you refer to.

[tresf]

isn't considered to be a part of The Program

Right, this is why CutePDF forces a separate download. Applications that don't clearly make that distinction are abusing the definition, no? Even CutePDF is in violation under some interpretations, since the The Program is not in any way usable without the GPL components. To make an application that's sole purpose is vapor without a GPL component seems to make direct abuse.

I'm not making any accusations, I'm just trying to interpret the limitations or interpretations of GPL2. I've read that GPL3 is much more strict about "Tivo-ization" problems so perhaps GPL2 falls into a 'ol loophole here.

I am skeptical that a similar argument can be constructed for changing just the plugin subsystem of LMMS and arguing that the plugin subsystem is a separate program, though I may be misunderstanding your intent and the definitions of what you refer to.

The idea is to author a separate project for plugin creation that is compatible with both GPL 2.0 as well as more permissive and even proprietary licenses (to the likes of Apache, MIT, BSD, whatever fits, I'll call this "MIT"). LMMS would then downgrade that code license -- legally -- under GPL 2.0 but the plugin authors would be able to use the original (e.g. "MIT") license. To simplify things further, we may eventually embed "MIT" in all build tools and plugin headers so that we don't have yet another project to maintain.

For ZynAddSubFX the UI accesses data through a network socket, it is capable of running on its own without a 'zynaddsubfx' process, and any text label information from ZynAddSubFX that it uses is stored in a json serialization which 'zynaddsubfx' produces.

Thanks for the detailed explanation.

[PaulBatchelor]

The idea is to author a separate project for plugin creation that is compatible with both GPL 2.0 as well as more permissive and even proprietary licenses

I have such separate projects here, here, and also here as well.

From a plugin development perspective, here are the specific files you need to switch to a more permissive license:

• All (or as many as possible) of the header files (the entire include directory)
• embed.cpp
• lmmsconfig.h.in
• lmmsversion.h.in
• BuildPlugin.cmake
• bin2res.cpp
• some of your CMakeFiles (I forget which ones I used)

If you can do this, developers are free to make third party native LMMS plugins using non-GPL code.

[fundamental]

On 03-07, Tres Finocchiaro wrote: > isn't considered to be a part of `The Program` Right, this is why CutePDF forces a separate download. Applications that don't clearly make that distinction are abusing the definition, no? Even CutePDF is in violation under some interpretations, since the `The Program` is not in any way usable without the GPL components. To make an application that's sole purpose is vapor without a GPL component seems to make direct abuse.

Looking at CutePDF the separate download you refer to is for a ghostscript converter. Since this converter is a separate binary (and thus a separate 'program' under common interpretations of the GPL) CutePDF's license is not affected, but the converter must be supplied with an offer of the source which appears to be done on CutePDF's download page. As any converter could be used in place of the supplied converter, CutePDF isn't bound to the individual implementation by ghostscript and thus you have two separate programs in what is a typical use of a GPL component. The issue of working around GPL/GPL-like licenses by having the situation of "program A <-> serialization <-> program B" is a well documented issue which affected the development of gcc with respect to proprietary or partially proprietary architecture specific backends.

I've read that GPL3 is much more strict about "Tivo-ization" problems so perhaps GPL2 falls into a loophole here.

To the best of my current understanding the GPLv3 only addresses the additional situation where a user receives hardware that contains GPL software with no viable means of upgrading it with a version that the user has modified.

[fundamental]

On 03-07, Paul Batchelor wrote: > The idea is to author a separate project for plugin creation that is > compatible with both GPL 2.0 as well as more permissive and even > proprietary licenses I have such separate projects [here](https://github.com/paulbatchelor/lmms-sporth), [here](https://github.com/PaulBatchelor/LMMS-Signal), and also [here as well](https://github.com/paulbatchelor/lmms-reverbsc).

Those linked projects make extensive use of LMMS's infastructure, share data structures, call functions, and have functions called through a broad and deeply integrated interface. This IMO certainly does not fall under the allowable use as an external plugin and I agree with the GPL FAQ https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins that in this context they form a single 'program'. The only way to permit the sort of use in the linked examples would be to have the licensing terms of the whole LMMS project changed (to the best of my knowledge).

[PaulBatchelor]

The only way to permit the sort of use in the linked examples would be to have the licensing terms of the whole LMMS project changed (to the best of my knowledge).

Can someone explain to me in plain english what is stopping LMMS from adding some sort of dual licensing scheme? Are there ethical concerns (GPL is the only right thing to do)? Legal reaons (we can't change to license X because we did something in LMMS that would violate a cluase)? Practical reasons (We don't have the amount of manpower to switch to license X )?

[tresf]

The issue of working around GPL/GPL-like licenses by having the
situation of "program A <-> serialization <-> program B" is a well
documented issue which affected the development of gcc with respect to
proprietary or partially proprietary architecture specific backends.

Is there an article you can link? I'd like to know more about how GCC handled this.

In regards to "CutePDF isn't bound to the individual implementation by ghostscript", this statement is only true by loophole, not by business function since the software explicitly looks for gswin executable and the software The Program no purpose without it. I digress though because the loophole seems to be fully allowed.

My other projects cannot fire off a separate downloader. I'd rather know how Zyn and GCC handled this. Specifically this part of the GPL2:

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

[fundamental]

@PaulBatchelor The GPL is a license that specifies how a copyrighted work can be distributed. Without a license you fall back on the default IP/copyright laws of individual countries. In the case of USA law:

(from wikipedia)

Copyright law grants authors and artists the exclusive right to make and sell copies
 of their works, the right to create derivative works, and the right to perform or display
 their works publicly.
 These exclusive rights are subject to a time limit, and generally expire 70 years after the
 author's death. In the United States, any music composed before January 1, 1923, is
 generally considered public domain.

LMMS is composed of many contributions from many individuals. Each one hold copyright over their own contributed sections of code. By contributing their work to LMMS they have agreed to allow their work to be distributed under the GPL. If you change this license without permission of absolutely everyone involved with the work, then you are infringing on their copyright and subject to all sorts of legal ramifications.

[tresf]

Can someone explain to me in plain english what is stopping LMMS from adding some sort of dual licensing scheme?

We can for new files. Old files would require research. That said, there are fundamental ethical reasons to choose GPL over MIT and those differ between developers.

For historical reasons, we cannot easily change the entire source code, but for components which we want to encourage plugin development your project is the place to start by looking at every contributor from the commit logs and getting permission from them to switch it.

[fundamental]

@tresf LWN has talked about the GCC (and later emacs) issue a few times, here's one of the articles https://lwn.net/Articles/629259/

[tresf]

Closing this as it's a conversation/discussion thread and can't be "fixed". Please feel free to continue conversation in the closed thread.

[jasp00]

Well, the concern for this issue was whether LMMS allows some business models, one case being the development of non-GPL LMMS plug-ins, including GPL-incompatible ones. This case is allowed; as I said, software design.

This issue should not be a GPL FAQ, but...
@tresf, the paragraph you quote from the GPL2 is not part of the license terms. Anyway, regarding your projects that cannot fire off a separate downloader, the ones using gs/mu, the answer is the same: software design. Nevertheless, CutePDF calling gswin32c explicitly is a risky case, your worries are well-founded.

Lay out the problem in LMMS terms and someone might be able to help.