Change license to MIT for specific plugin-related files in LMMS

[PaulBatchelor]

Nevermind. Please don't respond anymore to this.

As discussed previously, the need for a less restrictive license for specific files in LMMS would be ideal for individuals developing third party native LMMS plugins. Such freedoms would allow faster prototyping and will yield more innovations for LMMS.

Based on my continuing work developing third party LMMS plugins, I have outlined below the files of specific methods or classes used. I'm probably missing one or two, but I intend to update this later.

A few guidelines I'm using:
- Ignore header files for. They are too interdependent on one another. This is a legal technicality that can and will be solved later (see: VST SDK model)
- virtual methods I implement should be included
- specific functions or classes I reference should be included.
- graphics or similar resources that I accidentally use, or am using for now will not be considered

IF YOU SEE YOU ARE A CONTRIBUTOR TO ANY OF THE FILES BELOW: please comment YES or NO to the following question: Would you be amenable to changing the license of that particular file to an MIT license?

If you respond NO, please explain your reasoning so we can continue further discussion.

~~- https://github.com/LMMS/lmms/blob/master/src/gui/embed.cpp @tobydox @lukas-w @Umcaruje @softrabbit @teeberg @grejppi
https://github.com/LMMS/lmms/blob/master/cmake/modules/BuildPlugin.cmake @tobydox @lukas-w @tresf @andrewrk @jasp00
https://github.com/LMMS/lmms/blob/master/src/core/Engine.cpp @lukas-w @Wallacoloo @badosu @M374LX @grejppi @Fastigium @diizy
https://github.com/LMMS/lmms/blob/master/src/core/audio/AudioPort.cpp @tobydox @diizy @M374LX @grejppi @Umcaruje @lukas-w @Fastigium
https://github.com/LMMS/lmms/blob/master/src/core/AutomatableModel.cpp @tobydox @diizy @JohannesLorenz @lukas-w @Umcaruje @NoiseByNorthwest @jasp00 @grejppi @Fastigium @BaraMGB @serdnab
https://github.com/LMMS/lmms/blob/master/src/lmmsconfig.h.in
https://github.com/LMMS/lmms/blob/master/src/lmmsversion.h.in @devnexen @tresf @andrewrk
https://github.com/LMMS/lmms/blob/master/buildtools/bin2res.cpp @tobydox
https://github.com/LMMS/lmms/blob/master/src/gui/EffectControlDialog.cpp @grejppi @Umcaruje @lukas-w @grejppi
https://github.com/LMMS/lmms/blob/master/src/gui/widgets/Knob.cpp @lukas-w @Umcaruje @michaelgregorius @Wallacoloo @zonkmachine @grejppi @BaraMGB
@lukas-w @Umcaruje
TODO:

• @ folks who are contributors
• contact contributors specifically via public email
• run git blame on files to figure out who exactly contributed what. It may be that I don't need to ask permission for entire files, only for specific methods, functions, and subroutines used.

Thoughts?

[tresf]

Would you be amenable to changing the licensing of the particular file to be more permissive specifically for the use of developing third party audio plugins in the native LMMS format?

We should pick an exact license first or else the contract is void. You'll get a yes from me regardless, but people need something to agree to, if not they can challenge the open-ended agreement.

Side note... I have not heard from @diizy in a very long time. We may need to revert all of his changes to the above files if he doesn't reply to email. He hasn't made any commits on GitHub for nearly two years.

[Umcaruje]

I didn't alter the code, but I changed all the website links, so I also technically contributed to the files. You have my wholehearted yes on this, and if you ask me, the whole of LMMS would be under a more permissive license, but as it was said in the other thread, that's a bit impractical to actually do now.

[PaulBatchelor]

MIT or BSD in my mind. I use the MIT license for my projects, so for my brain this is my first choice.

[tresf]

I vote MIT over BSD2/3.

Reasons:

1. MIT is shorter and slightly quicker to read and understand over BSD2/3.
2. BSD3 explicitly says the names of the copyright holders and contributors can't be used for promotion. I don't see why this needs to be explicitly mentioned and since we mention lmms.io at the top of each file, I'd hate for this to be misinterpreted. Any future trademark permission should be handled outside of our source code license, I'd think.

[PaulBatchelor]

Adjusted issue to be specifically MIT licensed.

[PaulBatchelor]

@fundamental Could you elaborate on your 👎 ?

[teeberg]

Yes

[Wallacoloo]

No: You do not have my permission to relicense my contributions to LMMS.

As an end user (of a different DAW) who has had to open 3rd party .so binaries (so called "Linux VST" plugins) with a hex editor in order to fix bugs because the developer refused to share their source code for a plugin that I bought, I'm not seeing why I would want to encourage this sort of thing. GPL generally prevents me from having to deal with silly stuff like that.

[tresf]

the developer refused to share their source code for a plugin that I bought

Can't one make the argument that Vestige encourages the very same thing? At what point does GPL become the priority over music?

[Wallacoloo]

@tresf My priority IS in making music. I thought the example above helped show how the lack of access to the source code cost me a day of not making music over just an hour.

How does GPL prevent people from making music, anyway? Developers can create plugins using LMMS code & whatever other libraries they want and then release the product under GPL. GPL != no cost - said developer could perfectly well sell their plugins and deliver the source code alongside the binary, while not providing either to those who don't purchase their work. If you think this is somehow worse for the developer than just distributing the binary, then let me know & I'm happy to discuss that aspect in more detail.

Besides, the code @PaulBatchelor asked me to relicense is in Engine and Knob. Plugins have no reason to dig this far into the internals of lmms. You could easily create a proper plugin system without having to relicense any of my work. I mean, my contributions to these files amounts to < 20 LOC anyway - just remove them if you seriously think GPL is somehow preventing people from making music.

Can't one make the argument that Vestige encourages the very same thing?

Sure. I was never involved in its development though, and I never used it from within lmms. I am involved in this portion of the code, hence why I speak now.

[PaulBatchelor]

@Wallacoloo Engine is needed for getting things like BPM and samplerate. Knob is needed to build layouts. If there is a safer way to get those, I'm all ears.

[PaulBatchelor]

@Wallacoloo Any work involving hardware gets tricky. If I wanted to build LMMS plugin wrappers for things like Google SOLI, Occulus rift. Forget about trying to bring VR into LMMS in some way. Not saying it's impossible. Just really unlikely in the next decade.

Speaking of the next decade... let's talk about microcontrollers. Nothing is open source there. STM series, atmega series. It has many proprietary parts, and one would have to tiptoe around the GPL to get things working? What if you had a LMMS eurorack module, where you could talk directly with a hardware patch? Do I really want to make these jumps?

What if you wanted to build a room model reverberation using GPU-based architecture like CUDA. Sorry folks, it's just not GPL all the way down with anything related to that hardware. You'll need a blob or two there. Instead of allowing a few rules to be broken, you can't have any nice things.

Soundpipe and Sporth are the driving forces behind AudioKit, an open source framework which brings audio processing to iPad devices. This brought about interesting innovations like McTrax... a musical placemat. Very musical, couldn't be done legally with GPL licensing (but they are MIT licensed). Not to mention you are creatively restricted from developing and distributing any new instruments for the iPad, even if they are free. And no, despite being open source and having fixes for it, there isn't a decent alternative for Android right now for audio.

And so on, and so forth.

[PaulBatchelor]

@Wallacoloo if you can tell me all of this is possible right now with our current situation, I won't need to change the licensing of the work you've done.

[Wallacoloo]

@PaulBatchelor You can have a GPL program that depends on non-GPL code/etc. You can easily write a GPL program for a microcontroller whose toolchain or USB stack/etc is proprietary. I believe you can even do this if the companies require you to sign NDAs to access the headers for their USB stack (you just couldn't store these in your GPL codebase). You can write CUDA code and release it under GPL. You can have a GPL program that depends on a non-free CUDA program.

In general, GPL code can depend upon non-GPL code - it's only the reverse that's false. Or did I misunderstand your comment?

[tresf]

How does GPL prevent people from making music, anyway?

GPL is an incestual license. It only works with other GPL licenses (or something that can be clobbered/restricted back into GPL). It doesn't play nice with others, it only plays nice with itself.

GPL has many strategic advantages in the industry. It has and continues to drive a lot of FOSS contributors to FOSS replacements for proprietary software while also protecting said project from being commercialized, closed-source and taken over. GPL is very effective.

However in hindsight... GPL can also be a curse when developing a system that by very nature talks to proprietary software and hardware. Music software lives in that realm. I would argue LGPL is better for music software. It has most of the pay-it-forward benefits of GPL, but without being abrasive and forceful to the libraries it talks to.

Sure. I was never involved in its development though, and I never used it from within lmms

That sounds sarcastically ignorant so I won't come to Vestige's defence.

But to keep this on topic... the MIT license is what was proposed for plugin code only.

• If one's vote is "NO" regardless of the scope, then that is the status of one's commits.
• If one's vote is "NO, BECAUSE OF THE SCOPE", then perhaps we talk about fixing scope.

[PaulBatchelor]

I believe you can even do this if the companies require you to sign NDAs to access the headers for their USB stack (you just couldn't store these in your GPL codebase).

@Wallacoloo I am doing something similar with LMMS, where I am just using the header files and calling the methods defined in the header file. Is this acceptable in your mind?

In general, GPL code can depend upon non-GPL code - it's only the reverse that's false. Or did I misunderstand your comment?

Similar. Right now, I have libsporth and libsoundpipe statically linking against a LMMS plugin I have made. The code for the plugin itself I want to make GPL, but the libraries that are statically linked are MIT. It's ambiguous to me whether or not this is a violation of the GPL. In my mind this automatically puts my libraries on parole. Right now, everything is lined up in such a way that it complies with the GPL. But what happens if one day my libraries decide to link against a proprietary library?

[tresf]

if the companies require you to sign NDAs to access the headers for their USB stack (you just couldn't store these in your GPL codebase).

Right, but this makes some broad assumptions.

1. The headers aren't needed in the codebase (they often are for any reasonable amount of collaboration to occur)
2. The headers aren't themselves part of a non-GPL API

Unless you completely clean-room an API (e.g. Vestige), you're subject to its license.

But you're right in one sense... when it comes to plugins, we're talking about EXPORTING our API, not IMPORTING others'.

[tresf]

but the libraries that are statically linked are MIT

Fortunately for this use-case MIT can be downgraded to GPL effortlessly. They're compatible. Which is why it suits plugin exports nicely.

[Wallacoloo]

But to keep this on topic... the MIT license is what was proposed for plugin code only.

• If one's vote is "NO" regardless of the scope, then that is the status of one's commits.
• If one's vote is "NO, BECAUSE OF THE SCOPE", then perhaps we talk about fixing scope.

@tresf My vote is "NO" regardless of the scope.

[PaulBatchelor]

@tresf @Wallacoloo what if I built an external-facing API specifically for plugin development? You'd just drop one header file in and be done with it.

[Wallacoloo]

@PaulBatchelor If you go that route you'll likely avoid having to relicense any of my code in the first place, so I wouldn't stop you.

[PaulBatchelor]

@Wallacoloo I think it'll actually be a cleaner solution in the long run. In a way, I should be thanking you for putting me in a position to come up with it in the first place :)

[fundamental]

"an external-facing API specifically for plugin development" That sounds oddly similar to a plugin API; I wonder if anyone has made one of those before, with a reasonably liberal license attached?

Oh, I don't know how about - "LV2 is an open standard for audio plugins, used by hundreds of plugins and other projects."

[lukas-w]

LV2 is an open standard for audio plugins

I too feel like this is the way to go in terms of plugins. No point in developing our own plugin API, exposing LMMS's (terribly broken) internal architecture, when there are good standards around that are already used by projects.

Regardless, you'll have a yes from me for a change to any OSI approved license. While I'm not entirely sure about the immediate advantages re-licensing under e.g. MIT will give us, I can't see any disadvantages compared to the GPL.

[tresf]

I'm not entirely sure about the immediate advantages re-licensing under e.g. MIT will give us, I can't see any disadvantages compared to the GPL.

Can you elaborate on this a bit? I was under the impression if we provide a GPL API we restrict who can use it and how they can use it. Am I wrong?

[lukas-w]

Can you elaborate on this a bit? I was under the impression if we provide a GPL API we restrict who can use it and how they can use it. Am I wrong?

As far as I know, you're right about that. The reasons "I'm not sure about the advantages" are

1. I just haven't put much research into the exact restrictions the GPL imposes on us or plugin developers. But more importantly:
2. I don't believe switching to MIT in order to potentially allow proprietary plugins will help the project gain popularity, at least not in the near future. I do agree with the idea of allowing proprietary plugins to be written for and used within LMMS, but using an already established standard such as LV2 will do the same thing, just better.
3. Even if we switched, we won't be able to provide a stable API to developers, because a lot of the code will likely (or hopefully) change as part of efforts to improve LMMS's architecture. Because we lack the resources to come up with an API that's decoupled from our existing code, we'll likely just expose most or all of our headers to plugins. Once we do that and people start using it, we'll be responsible for keeping it stable, which means we won't be able to do most of the improvements the project so desperately needs. Therefore, I feel providing a stable API is more likely to stall development on LMMS than to accelerate it.

[tresf]

Therefore, I feel providing a stable API is more likely to stall development on LMMS than to accelerate it.

Thanks. I agree. However, this is only an effort-spent argument, not a best-API-license argument.

I don't believe switching to MIT in order to potentially allow proprietary plugins will help the project gain popularity, at least not in the near future. I do agree with the idea of allowing proprietary plugins to be written for and used within LMMS, but using an already established standard such as LV2 will do the same thing, just better.

There seems to be LV2 consensus for years however in practice, we keep getting plugins written for native LMMS.

BTW, LV2 is released under an ISC clone license, which is a shorter but effectively identical version of MIT.

[fundamental]

we keep getting plugins written for native LMMS.

Isn't that an indication that there's a lack of a sufficiently powerful plugin interface (like LV2) which forces people interested in making plugins for LMMS into using unstable internal's?

[lukas-w]

However, this is only an effort-spent argument, not a best-API-license argument.

Sure, but seeing that the primary argument for switching to a more liberate license seems to be that it would allow us to open up our API to proprietary plugins, I still feel that it's part of this discussion, because we shouldn't.
From a pure API-license point of view (assuming we'd provide an API in the first place), I agree that MIT is probably the best choice.

[michaelgregorius]

@PaulBatchelor, I am ok with switching my few contributions to the Knob class to an MIT license.

However, I agree with the others that implementing LV2 support in LMMS would likely make more sense because lots of LV2 plugins already exist.

I assume that one of the reasons why people rather implement LMMS plugins instead of other formats is that it's easier to implement a GUI for it and you don't have to adhere to a very strict separation between the plugin's code and LMMS' code (although this is a bad thing in my opinion).

Some while ago I tried to get my feet wet with LV2 but I was not even able to show a simple Qt GUI with the test hosts. And to this day I don't know whether it's technically even possible for GTK hosts to show an LV2 GUI that's implemented with Qt and vice versa. I saw that @fundamental is active on this thread. Perhaps he (or someone else) can enlighten me with regards to that question, especially as he seems to be one of the Linux audio gurus. All the LV2 boilerplate is one of the reasons why I am currently implementing my audio stuff with VST on Windows using WDL-OL.

[fundamental]

@michaelgregorius The description of suil ( https://drobilla.net/software/suil ) seems to indicate that the embedding is entirely possible. For my own work I have avoided general purpose toolkits as the global state that they create has caused complications in other LV2 projects (this issue is certainly not LV2 specific however). In the past one popular workaround was the external-ui which IIRC was used for the embedding of the fltk/ntk UI in zynaddsubfx.

As per various LV2 boilerplate it can be a pain, though like many things within LV2 there's a pretty solid reason for why they made the specific choice. The .ttl files for example make it possible to cleanly ship multiple plugins within the same shared library, it makes it faster for hosts to scan plugins (as the host does not need to try to create an instance to get info), and formalizes metadata about plugins in a way that's relatively convent for hosts and extendable.

Is it a PITA to get used to it? yep, but it offers well thought out (on a technical level) advantages (which may be poorly expressed in the documentation) over prior commercial and open audio plugin standards.

It's important to note that LV2 is built with extensions in mind, so if limitations are reached with it there are relatively direct means of adding the needed functionality.

[PaulBatchelor]

The thing is, there are some cases where you would want to build plugins that specifically integrate with LMMS tools and UI.

[tresf]

The thing is, there are some cases where you would want to build plugins that specifically integrate with LMMS tools and UI.

Right however if they're that integrated, they should arguably become a base feature and comply with the project source license.

I think that's the overall point... If a third party needs to explicitly use our Knob.cpp code, they're writing LMMS, not a plugin.

[PaulBatchelor]

I think that's the overall point... If a third party needs to explicitly use our Knob.cpp code, they're writing LMMS, not a plugin.

Right. So I should back up. I'm not explicitly using that file, but I am using that class here. I'm just not sure where the line ends with the GPL.

The amount of code I actually have to copy is far less.

[tresf]

I'm just not sure where the line ends with the GPL.

• Unless we abstract it away it's usage is bound to GPL2.
• Abstracting it away is entirely possible (and probably an easier short-sighted goal than LV2) but would suffer as an unsustainable API due to the whole "moving target" problem, which can't happen with an API, at least shouldn't.

@PaulBatchelor If you are OK with it, we should keep your plugin tools GPL2 as a stop-gap for contributors until LV2 is introduced and close this issue out as wont-fix.

In regards to implementing your new plugins in LV2:

@tres if I can put a text editor in it, that would be motivational. I'll check it out.

Perhaps this? http://lv2plug.in/ns/extensions/ui/#Qt5UI

[PaulBatchelor]

Alrighty! No biggie.

[PaulBatchelor]

Alrighty! No biggie.

[softrabbit]

IF YOU SEE YOU ARE A CONTRIBUTOR TO ANY OF THE FILES BELOW: please comment YES or NO to the following question: Would you be amenable to changing the license of that particular file to an MIT license?

YES. Like, whatever. And don't ask me again for a file where I haven't explicitly claimed copyrights. It's silly that me dropping a few lines (or even characters) of code in some huge file should force others to ask my permission to do stuff with it.

#3412 (comment):

I assume that one of the reasons why people rather implement LMMS plugins instead of other formats is that it's easier to implement a GUI for it and you don't have to adhere to a very strict separation between the plugin's code and LMMS' code (although this is a bad thing in my opinion).

It's easier, period. A semi-competent developer starting from absolute 0 could have a working LMMS instrument (or simple LADSPA filter) in an evening, whereas the LV2 learning curve is steep enough that he'll still be scratching his head trying to make some sense of it all after putting in the equal time on that path.

[falkTX]

You don't have to write LV2 specific code if you use a plugin framework.
Consider juce: https://github.com/julianstorer/JUCE
and dpf: https://github.com/DISTRHO/DPF

The bonus of using an existing framework is that you only write code once, then deploy as LV2, VST and other formats. (plus multi platform)
On Juce's case, I wrote the LV2 wrapper. While not official upstream, we can still code LV2 plugins with juce.

[serdnab]

yes

[badosu]

Yes

[grejppi]

No, because changing the license of specific core parts of LMMS just to allow plugin development under a different license feels backwards to me.

[jasp00]

@PaulBatchelor, please restore your initial message. We can lock the conversation if needed.

Bits of information that might be useful:

• What was asked in this issue is not that feasible, GPL does not work that way.
• Your libsporth and libsoundpipe are fine to link against GPLd or proprietary software, just do not mix GPL code with proprietary software.
• It is not clear whether an API is copyrightable. In the US, there is the Java case.

[tresf]

What was asked in this issue is not that feasible, GPL does not work that way.

Why not? Regardless of why this task is not practical, what portion "does not work?"

One can place MIT components directly inside our project and if those MIT components are used stand-alone, what is the concern?

[michaelgregorius]

Thanks to @fundamental and @falkTX for answering my questions and giving some pointers regarding LV2. Perhaps I will have another look at it and study some of the existing LV2 plugins. Last but not least, thanks for letting me "borrow" this thread for that topic. :)

[jasp00]

Why not? Regardless of why this task is not practical, what portion "does not work?"

You cannot just write a simple MIT wrapper around a GPL program to cancel GPL. Sure, you may succeed in licensing the LMMS plug-in API under MIT, but you still need to replace the back end because this API is tied to the implementation as logs show.

Let us see some difficulties. At source level, for instance, it has been asked to relicense src/core/Engine.cpp (which also has contributions from tobydox, I and others, see src/core/engine.cpp). Not only contributors to Engine.cpp matter, but contributors to all included files: BBTrackContainer.h, TrackContainer.h, ConfigManager.h, etc. This is certain if there are macros, inline functions and templates of significant size.

Even with elements of small size, it is not clear that this qualifies as fair use. IMHO, it does not, unless the behavior is not documented or is public knowledge (I would appreciate a reference that proves Microsoft API documentation is public knowledge, this is a pending issue).

At binary level, because of the tight integration, the plug-in depends on the back end implementation, which is under GPL. Thus, all contributors to all GPLd source files are concerned. Those files are the ones corresponding to the version used to produce the binary, i.e., if the plug-in dynamically links with a later version, later contributions do not apply.

[jasp00]

From #3447 (comment),

we did eventually settle on an agreement (focus on LV2), but we still require a programmer.

From Wikipedia: "KXStudio's Carla is a multiplatform host supporting many plug-in formats including LV2." I do not build Carla plug-ins. Is LV2 support not there?

[fundamental]

@jasp00 Perhaps I'm misreading your comment, but are you implying that Carla is the only LV2 host?

From the same article:

Currently there is support for LV2 in Ardour, Calf Studio Gear,[1] Qtractor, Traverso DAW,[2] Harrison Mixbus,[3] MusE and the 2.0.6 and above versions of Audacity.[4] It is also the plugin format used by the Mod Duo[5] hardware effects unit.

[tresf]

KXStudio's Carla is a multiplatform host supporting many plug-in formats including LV2.

We still need to do some work on our end... e.g. #2689

[jasp00]

Is LV2 support not there?

LMMS has two plug-ins: Carla Patchbay and Carla Rack. Can a LV2 plug-in be used through Carla Patchbay or Carla Rack?

[mikobuntu]

Yes LV2 , Native Linux VST, DSSI and LADSPA can be used through Carla Rack and Carla Patchbay ( the patchbay has a rack tab as well as a patchbay tab )

[jasp00]

If there is LV2 support through Carla plug-ins, then what is the problem?

[Umcaruje]

If there is LV2 support through Carla plug-ins, then what is the problem?

Carla is not available on windows, and also in my experience it's kinda unreliable (e.g. my projects that I made on my previous system now open with a completely empty carla). Another big issue is that you can't automate any of the parameters for plugins, cause we can't automate midi CC signals, which is the only thing Carla accepts AFAIK.

[falkTX]

my projects that I made on my previous system now open with a completely empty carla

I'm waiting for the bug report on that.

Carla can do OSC as well, but doesn't help the case here.
Automating plugin parameters is planned for a future release.

On a somewhat related topic, how is the LV2 plugin support for LMMS going so far?
I know some efforts were started, but haven't been following them closely.

[jasp00]

how is the LV2 plugin support for LMMS going so far?

See #562.