License Changing GPLv2-3 -> AGPLv3+

[peepo5]

If it is possible to change licensing, it would be beneficial to change licensing to the strongest copyleft license.
This would improve the terms for cloud services, and it would make implementing the code in proprietary ways harder.

Let me know if this cannot be done.

[Semisol]

I think we already started to lock in GPLv2-only already due to incoming commits.

[falkTX]

Then best to stop taking commits until this is resolved.
Going to be real messy otherwise

[Semisol]

Then best to stop taking commits until this is resolved.
Going to be real messy otherwise

Or ask for permission from older contributors (No CLA), most PRs already say GPLv2 or above

[ErikPrantare]

I thought the license was GPLv2+, which should be compatible with AGPLv3+. I am 100% for this change, we saw how Muse Group changed license to make proprietary cloud services easier to develop. This would make that much harder.

[falkTX]

Right, but how many would agree to license to AGPL instead of GPL?

This is a tricky situation because IIRC there are some conflicts with GPLv2+ and AGPL (in general), which were fixed in GPLv3+.
I know that AGPLv3+ and GPLv3+ can combine well, but there are some oddities with older versions.

Since audacity still has some GPLv2-only code, we can't just switch to AGPLv3+.

[ErikPrantare]

How much of the code GPLv2-only? We should at least be able to use GPLv3, as audacity changed their license to that.

[falkTX]

they havent changed yet afaik.
https://github.com/audacity/audacity/blob/master/LICENSE.txt still says GPLv2
audacity/audacity@368ab6f changes the readme to say GPLv2 to GPLv2+

[ErikPrantare]

If they actually change it to GPLv2+, we should be able to use that to relicense to AGPLv3+.

[peepo5]

hmm this + seems important.

[Songtech-0912]

Technically I am unqualified to answer due to my previous incorrect comment. However, after doing research and consulting with several sources, here is what I found:

(I should clarify again that this is the result of my research and analysis. I very much could be wrong, please point out immediately if I am at any point. I do NOT want to be the misinformation spreader here.)

Audacity depends on the following libraries (there are more but here are a few of note):

* alsa-lib
* Expat
* libogg
* libvorbis
* libsndfile
* lv2
* connan
* ffmpeg
* sdl2
* wxwidgets

Of these libraries, assuming my research is correct (and I believe it is), these are the respective licenses:

• Expat, sdl2, and conan are MIT licensed
• Alsa and Libsndfile are LGPL 2
• Libogg, libvorbis is BSD
• LV2 is ISC licensed
• FFmpeg is GPL 3
• WxWidgets has a custom license that is very close to LGPL

Now, according to the FSF, "you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa". So moving to AGPL is a permanent choice, in a sense. AFAIK there are not many projects that have audacity as a dependency, but any such projects would also be subjected to the same terms. This is kind of a good thing - as many of you have pointed out:

"The restrictions placed on any subsequent versions of AGPL software make it difficult to adopt when there are competing commercial interests."

Additionally, there may be another problem (or advantage, if you see it that way) with AGPL. This is that AGPL allows works that fall under GPL v3 to be combined if it is unmodified work. If it is modified, then we have to publish the modifications as AGPL. This may cause futures in the future if Tenacity diverges significantly from Audacity to the point of needing to tweaks its depending libraries.

So this is my (best attempt) at trying to give a non-biased assessment of the change to AGPL:

• Pro: Prevents Tenacity from becoming Audacity if commerical interests take over
• Pro: The strictest copyleft possible
• Pro/Con: Tenacity has many dependencies and if we tweak them they have to be under AGPL too, thus causing more trouble with dependency management (but this can be a pro as well)
• AGPL is highly restrictive in regards with what others can do with it, and this can deter contributions made to it - there's a reason why the most permissive licenses (e.g. MIT) are the largest FOSS projects

[peepo5]

the + is important to account for future fixes

[Sciss]

just for fun, google even has a page dedicated to AGPL and why they hate it https://opensource.google/docs/using/agpl-policy/
which is great :)

Yeah, I take that as an objective indicator that the license is useful ;)

[RoaddogLabs]

On your last point, I myself am rather deterred by projects with permissive licenses, as I don't want my work to be proprietary'd in the future.

I think the main reason the largest projects are permissive is that projects backed by large corporations are hesitant to use copyleft. So it's not necessarily that permissive is more popular, but rather that they have the backing of corporations (google, microsoft, et.c.)

They're hesitant to use copyleft because it's a technology limitation as well as a legal barrier. The tech limitation is what can be rolled into the app under the licensing. You'll find by and large the for profit companies developing FOSS are using primarily, if not strictly in house or contract coders. They don't take pull requests from outsiders. Most large FOSS projects are not for profit foundations that are supported by corporate entities. Many of those do accept contributions from the community. Without that internet technology as we know it today wouldn't exist.

In the current form it's not well suited to be served as an app. An API specific to cloud apps would need to be developed as well as a re engineered UI and a scalable, cloud centric audio engine. The audio processing engine is pretty rudimentary and is unlikely to scale even deployed in a container over scores of instances. While it's possible to offload renders making an app where the cloud does all the lifting using current Audcaity/Tenacity code is a gigantic step backwards. A more likely scenario is Avid and/or Steinberg/Yamaha making cloud based editors base on their respective products.

Keep with the most restrictive license if that's the projects intent. It fits the vibe of the reason for the fork.

[jjaeggli]

With regard to the AGPL and large software companies, there's something called copyright assignment, which you agree to when you're hired. This means that any software development you do, even in your own free time, is copyright your employer. In the case of Google, this means that their employees cannot contribute to software which is licensed under the AGPL in their own free time unless they receive explicit authorization to do so, because essentially "your work is our work".

So what this means in terms of the project is that engineers at large software companies who might want to contribute to this project, either contributing something they need professionally, or who work on music production on the side, might be deterred from doing so. I don't know what percentage of contributions are made by professional software developers, but this is something to consider.

However, it does not, at least on the surface, make it intelligible accepting Google Summer of Code contributions.

I only speak here from my personal experience and am not advocating against AGPL, in fact Slic3r, the 3D printing software, is licensed under the AGPL and I think this a benefit for the community given that there are some blurry open source / commercial lines in that industry.

[falkTX]

Google requires employees to credit "Google LLC" as the author for open-source contributions.
Which is even more insane, because Google did nothing, a person did.

I have rejected pull requests in the past because of this, giving credit to a company where a person did something on their free time is just... a little bit evil.

[unbeatable-101]

Related issue from upstream: audacity/audacity#1270

[ajayyy]

GPLv2+ means "GPLv2 or any later version". AGPL is not a "later version" of GPL, but a different category of license entirely. Switching licenses would violate the freedom of GPL.

I don't think this is possible.

[ajayyy]

Thanks.

To clarify for others, there is a special clause in GPL-3.0 for this (Section 13)

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such

[peepo5]

Please note that the GNU AGPL is not compatible with GPLv2. It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want. See section 13 of both licenses for details.

[ajayyy]

ah, missed the vice versa

[peepo5]

If i am understanding correctly does GPLv2 not allow for AGPLv3 higher-levelled licensing but GPLv2+ does? or do GPL v2 and v3 both support being part of a multi-licensed project?

[falkTX]

you cant have GPLv2-only and AGPL. but you can have GPLv2+ and AGPL (because GPLv3 and AGPL were made compatible).
Also, we can't simply change a project from GPLv2+ to AGPL, as one is not a subset of the other (like GPLv3+ is a subset of GPLv2+).

What we can do though is to introduce new AGPL code in GPLv2+ projects.
On such cases the final product would be AGPL licensed.

[Be-ing]

Is there any pressing need to relicense? We're still just trying to get the code to build.

[purplesyringa]

I think we don't need to relicense at this very moment, but we should ensure we don't accidentally make that impossible if we merge some PR with invalid license. I think we haven't done anything like that though.

[nyanpasu64]

Have you heard of the copyleft-next license? It has interesting ideas like releasing the code under a BSD-like license to everyone if the copyright holder charges money for proprietary licenses. It also allows relicensing under the GPL (v2?) if the derivative work incorporates GPL code. I found out about it from news of the Linux kernel using it for some pieces of their code.

I'm not sure if you get VST3 compatibility under GPLv3 (the supposed motivation for Audacity's CLA) though.