4 ms·
I actually support this as an Audacity user. While there is the possibility of abuse — see RedHat cutting CentOS short (last night, I converted my final CentOS
by strenholme 5y ago
I actually support this as an Audacity user. While there is the possibility of abuse — see RedHat cutting CentOS short (last night, I converted my final CentOS virtual machine in to a Ubuntu 20.04 VM) and see https://github.com/newsboat/newsboat/issues/1643 https://github.com/newsboat/newsboat/issues/1643 (or https://freenode.net/news/for-foss https://freenode.net/news/for-foss for the other side of this soap opera) — there are benefits to this.
One is moving to GPLv3 so that Audacity has VST3 support. Right now, Audacity only has 32-bit VST2 support, which means I currently have to use older versions of my favorite plugins (since the plugins are now 64-bit only) since Audacity is part of my workflow.
The other is making proprietary versions of Audacity for things like the iOS app store, to help fund the development of F/OSS versions of Audacity. In a perfect world, everyone would be able to spend all day making open source for fun and for free, but that’s not the world we live in today.
If Audacity does start to abuse this, we can always fork from the final GPL version of the code base.
- oolonthegreat 5y agoI am not an expert, but I read that a CLA is not needed for the gplv2 to 3 transition. it seems to me that the CLA gives a blank check to the "company" to do whatever it wants with the contributed code: > The CLA provides the ability to release Audacity under multiple licenses surely this is not okay?
- strenholme 5y agoSorry for the late reply: It depends on the copyright the software has. Some copyright has “GPLv2 or later”/“GPLv3 or later”; other copyright (such as the Linux kernel) is “GPLv2 only”. CLAs like this are not that uncommon; the Free Software Foundation (FSF) famously requires all patches over 10 lines long (or so) to have a formal copyright assignment given to them.