The FSF made a huge effort to make GPLv3 not scary. They tried to involve absolutely everyone, and tried to take everyone’s concern into account. The GPLv3 was made to be not scary.
The GPLv3 instead became “scary” not because anything scary in it, but because of a huge FUD campaign from large companies who didn’t want people to switch from GPLv2 to GPLv3, since the companies wanted to keep exploiting the loopholes in the old v2. For those old enough to remember, this was mostly the same old FUD campaign against the GPL (any GPL) versus a permissive license, many years before that. But, largely thanks to Linux, the GPL slowly won over that old batch of FUD. With the GPLv3, however, the opportunity was there to start it all up again. The GPLv3 is slowly winning against the FUD this time too, but it hasn’t prevailed yet, and Linux is not here to help this time.
They decided to pick an ideological bone on purpose. That's fine, it's their right. But it was a deliberate decision knowing the consequences.
It is ironic (and sad) how people here campaigning against GPLv3 are all happy and warm when they realize they can download the driver and kernel sources for their modem, phone, rPI or whatever device.
But then if someone want to even suggest the same thing for digital products, then, no, it's the end of the world.
If they were serious about that effort, the metric would have been a simple boolean: "Will the Linux kernel make the switch?" That's got to be your most visible, most well-funded GPLv2 project in existence.
If no (and it was a resounding no according to Linus' very public rant at a Debconf a few years back) then the license would almost by definition appear to be "scary" from the outset. The only exception would be some very rare edge case in Linux that makes it impossible to switch. In reality-- again, at least according to Linus-- it was a complete breakdown in trust between a holder of the old license and the organization writing the new one.
I don't know the intricate details, but it's clearly a bigger problem than "large companies" spreading FUD.
Edit: clarification
Based on this, I don't think it's accurate to say that the kernel developers are currently opposed on the whole to GPL3, or at least to some of the ideas in it anyway. If the stance of some developers was "we'll upgrade the license if you remove all the extra provisions except the termination ones" then it seems obvious why that is a no-go from the perspective of everyone else.
[0]: https://www.kernel.org/doc/html/latest/process/kernel-enforc...
His beef seemed to be with a discussion with the FSF about compatibility of licenses. From what I gathered from the rant:
* Linus made clear to the FSF that he wanted a license for the Linux kernel that did not include the anti-tivoization clause. His desire as I understand it is that his project gives a licensee the code, they give back changes to the code, and that is as far as he wants the license to go. GPLv2 is a perfect fit for that. (Aside from whatever legal desiderata is required for such a license to be practical/sensible in the first place to achieve this, and I'm assuming that's what those two clauses you quoted are about.)
* Linus claims the FSF told him he could "invalidate the tivoization clause" as a solution to his stated goals. But, according to Linus, that would create a mess since someone could fork and write drivers under the full GPLv3 (which is compatible with the version that doesn't contain the tivoization clause), and as Linus states, "Where does that leave me?" He could end up in situations Linux is unable to accept the changes without asking the driver writer to re-license the thing under GPLv3-minus-tivoization for upstream inclusion. (Furthermore, the more popular GPLv3 becomes, the worse this problem would get!) But his whole purpose in GPLv2 was to make a simple "code-goes-out-and-changes-come-back-in" deal with other developers, end of story. So that clearly doesn't fit his use case.
* His central claim isn't that GPLv3 is bad, or even that GPLv3 doesn't fit his needs. Rather, he claims that FSF misrepresented the license and its compatibility with the GPLv2 in their discussion with him behind closed doors.
Of course that's just his allegation, and I haven't seen an email chain to confirm anything. But that allegation alone is enough to call into question the idea that the history of GPLv3 adoption is only scary due to FUD from companies.
I also broadly disagree with the argument that if the Linux community (or in this case, Linus) is against something then it is not a reasonable thing to put in the GPL. A reminder that the official policy of the Linux Foundation and lead maintainers is to avoid GPL enforcement at all costs[+] -- meaning that by this reasoning, the GPLv2 having any enforcement provisions at all is "too scary".
[+] GregKH has spoken on this quite a few times. I don't disagree with their view that enforcement reduces the chance of recurring contributions (which is what they actually care about), but it does mean that Linux's usage of the GPLv2 is more akin to MIT but with some extra public shaming if a company doesn't provide sources.
It wasn't moot because:
* the FSF apparently attempted to convince Linux devs that the GPLv3 could be compatible with Linus' intended use of GPLv2
* Linus has publicly claimed they were mendacious in his communication with them
That's not a great starting point for adoption of a new license. And while I'm sure there was also plenty of self-serving FUD coming from companies about the GPLv3, this ain't that.
You'd need to get every single person who'd contributed to agree. Even if they're dead.
So yes, it will probably take too much time and effort and give too little benefit to be practical, but impossible? No.
> Even if they're dead.
If they are dead, their copyrights are held by someone else now who can be asked.
That's not really true, and if code is being modified rather than completely replaced it is probably a derivative work of the original code (meaning the license is still GPLv2). The only practical way to make sure the license change is legitimate is to get permission from every single copyright holder.
> Lots of kernel code is copyrighted by companies now.
And some of those companies may have gone bankrupt or been dissolved which puts you in a similar situation to a contributor who has died, except it may be even harder to figure out who exactly owns the copyrights.
> If they are dead, their copyrights are held by someone else now who can be asked.
Even if you figure out who owns the copyrights, do you really think you'll be able to convince every single bereaved spouse, sibling, or child to "relicense your dearly departed [father/mother/wife/husband/brother/sister]'s contributions to Linux to GPLv3"? I envy your optimism.
Digression-- I'm sure the FSF doesn't appreciate it, but there is something very disarming about Linus ending his rant calling the entire FSF "bigoted people," and then immediately following it with, "I may have overstated that a bit."
It's a very unprofessional and risky way to joke around, especially after making the accusations he made minutes before. But the fact that you can hear how the room laughs and carries on after he essentially calls himself a "drama queen" tells you that pretty much everyone understood the upshot (whether or not they appreciated the joke).
That makes me think that of how rotten online communication is. In person, a maintainer of one of the biggest open source projects can call an entire organization one of the worst insults, and probably none of the members of that organization in attendance even considered interrupting him. Yet HN needs a "cool down" period to keep participants arguing about semicolons from throwing their device at the wall.
Edit: typo
My understanding was that Stallman continually fought to keep GCC difficult to avoid linking with if you wanted to use parts of it.
As I see it, once LLVM became competitive with GCC, adoption quickly accelerated due to liberal licensing.
Not everyone agrees that the freedom to make a SaaS business with a private GPL fork is a loophole or bug. It seems (from their creation of the AGPL and use of terms like "ASP loophole") that the GPL people do.
It's the perfect license for MongoDB and all these other companies trying to keep Amazon from taking their software and proprietarizing it... but instead they make weirdly restrictive one-off licenses nobody are going to contribute to.
Proprietary code is actually the most restrictive to both users and developers. That's because you can't legally mix proprietary code without a license at every step of the way. Any significantly large proprietary project becomes a mass of third-party dependencies with all sorts of license restrictions that your company is probably ignoring and breaking. Even if you follow all the tenants of those licenses, you don't own your code at the end. A Node-style mess of dependencies becomes ten times worse when each dependency has license restrictions attached to it.
In other forms of media, you generally don't see people try to license 30-50 different properties all at once for the same work, because that means nobody owns anything and the work will be really hard to market internationally. Software almost demands this sort of dependency soup, however, which creates all sorts of unique preservation problems. Whenever a large software project (or game engine) is discontinued, a lot of people wonder why the company who wrote it doesn't just release the code as Free for third parties to maintain. The answer is that in most cases, it's not their code to release.
Depends on what open source philosophy you support - do you believe users should have the right to look at your source code, modify it, and share the modifications with others? In that case only an open source license like the GPL, that protects the USERS right meets this requirement.
Every developer is also a user of their product. Thus, protecting the rights of the USER, automatically protects the rights of the developer too, to further study, develop and customise their code further. On the other hand, permissive license can restrict developers, as others can close-source your open-source work.
If all you want is recognition and credit for your work, then permissive open source licenses are definitely better.
What copyleft licenses prohibit is distributing software with less freedom than what you had when you received it, whether you modified it or not. But that's not a developer's issue, that's an issue for someone that hopes to gain something from restricting freedom.
Just because your core business software is AGPLv3 doesn't mean any other business will be able to build a coherent business model atop it, look at Kazoo by 2600Hz or Iris by Lowes.
Knowing how to properly configure and maintain said code in production, creating integrations with third party vendors (that your competition likely can't interact with on the same terms) and marketing to build mindshare among potential customers is a common way to offer your core software as AGPLv3 yet have no competitors or few competitors use your core software.
Neither GPLv3 nor GPLv2 prohibit this.
You're thinking of the AGPL, the first version of which was based on the GPLv2 and released in 2002, years before the FSF announced that they were even beginning work on the GPLv3.
AGPL does have restrictions, and it's anyone's preference as to whether they're good or bad, but there has never been an intent to forbid businesses. If anything it's the recent RedisLabs' modules license and the SSPL-style licences that do it: they explicitely contains the wording to indicate that the product can't be used to create a similar product and offer it as a service. Heck, the SSPL says (https://www.mongodb.com/licensing/server-side-public-license):
"If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License"
The AGPL tells you that if a user asks for the source code, you must give it to them and them only. The SSPL says that the source code must be publicly available to all, at no cost. It was created specifically to prevent competitors to run MongoDB as a Service. Surely if they had to change it's because the previous license did authorize competitors to do it. Wanna take a guess what the previous license was ?
The AGPL doesn't prohibit starting a business, it makes starting a business prohibitive.
Look at all the SaaS offerings of MongoDB (formerly AGPLv3): https://news.ycombinator.com/item?id=19362919
AGPLv3 doesn't make starting a business prohibitive, arguably forks like NextCloud would not exist if AGPLv3 did not compel codebase users to publish the additional code they wrote to extend OwnCloud
I think the battle was lost by not pushing the advantage hard enough.
GPLv2 was stricter in that regard, in that the entity shipping the system libraries couldn't be the one shipping the GPLed software; GPLv3 drops that and allows anyone to ship GPLv3ed software for a proprietary platform, as long as you still meet the other requirements of the GPLv3.
I'm largely thinking about the current situation with ZFS on Linux. IMO, this benefits no one, and so I'd generally like to see less draconian interpretations of what code is allowed to link together—but more licenses which protect other user freedoms, like the ability to run your own code.
What would arguably not be fine, under my interpretation, would be if Windows would not function without a GPL component, that's built-in to the OS and distributed on the install disks and updated through Windows Update. Even if it's a self-contained binary, and you can navigate to it in the filesystem.
The standard is - would a reasonable person view the combination of GPL and non-GPL code as a single piece of software?
I think reasonable people would disagree with each other.
macOS used to come with iTunes preinstalled, but you could remove it by turning off SIP and running `sudo rm -rf /Applications/iTunes.app` in the Terminal. I always did so, because iTunes sucks, and the rest of the OS always continued to work fine.
Is iTunes a part of macOS, or is iTunes a separate piece of software? Would it matter if you could remove iTunes through Finder, or without turning off SIP? Would it matter if iTunes wasn't included with macOS, but was automatically downloaded and installed a day later? Would it matter if iTunes was created by a third party, or if macOS couldn't output any audio without it?
What about Google Play Services? DirectX? ZFS? I could certainly make a case for how I think each of these should be classified, but I don't think it's at all obvious.
Software engineers consistently underestimate the degree to which law is not like coding.
The even more interesting case is when there is more than one option for that binary, all with the same interface (but possibly different features), and only some of them are GPL. This was famously the hypothetical presented by the author of CLisp (which had a dynamic dependency on GNU Readline) to Stallman.
And if this is something that a sufficiently large segment of the users actually care about, then they will vote with their feet, and purchase hardware where they can update their own code. Maybe this will even result in a software ecosystem where the company selling an open product will be able to take those improvements from the dedicated power users to improve future releases of their product. But this is something which is best enforced by market forces --- if it's really an important right that users find important, they will demand it.
This is essentially the debate when the FSF tried to convince the Linux kernel community to relicense to the Linux kernel to the GPLv3. We declined, essentially because we saw the downsides of the anti-Tivo-ization clauses had towards people choosing to use Linux versus some other OS. And we believed that growing the contributor base was in the long term, far more important than the more short-term anti-Tivoization concerns of the FSF. This is why the Linux kernel is GPLv2 and not GPLv3. We didn't give in to the siren call of the FSF position.
If you buy a TiVo and then can't modify it, you don't. So there is nothing to share with everybody else. The entire system is destroyed. It's an existential threat.
> And if this is something that a sufficiently large segment of the users actually care about, then they will vote with their feet, and purchase hardware where they can update their own code.
But that's the problem. Most of the users aren't (currently) developers, but if the dominant hardware isn't open to developers then there are fewer developers, and the users then can't receive their improvements.
It's not obvious that there are always enough developers to justify a production run of open hardware separate from the hardware everybody else uses, even though everyone benefits from its existence. So we need the dominant hardware to be open.
> Maybe this will even result in a software ecosystem where the company selling an open product will be able to take those improvements from the dedicated power users to improve future releases of their product.
Except that if this becomes popular and the software is open source but can be locked down, proprietary hardware vendors will ship the improvements on locked down hardware. Then anyone who doesn't make modifications themselves, or doesn't anticipate making them even though they might have, buys the locked down hardware and the open hardware has no competitive advantage in the market among non-developers. Even though its existence is a prerequisite to continued community software improvements that everybody wants.
Every device or platform since the IBM PC, including phones, tablets, non-x86 PCs, thermostats, wristwatches, routers, appliances, cars, etc. -- all of them have switched to the device-only-accepts-firmware-signed-by-the-manufacturer model where you can't put your own software on the vast majority of devices without a significant amount of reverse engineering and hardware/firmware exploit hunting.
Software can't eat the world if nobody wants to make hardware that can run arbitrary software. Then it's only "this one particular company's software can eat your thermostat for the two years that they feel like providing device support, then it's trash."
I think that hardware (or at least boot architecture) does matter. For all of UEFI's flaws, the secure boot model is actually pretty good. A device can come with a preloaded manufacturer key, and can be configured by default to only run manufacturer signed firmware. But once a user buys the device, they have the option of adding an additional key, either from another third party (i.e. like the key that RedHat and Ubuntu use to sign their kernels), or keys that you or your organization generate and manage yourselves. You can also remove the preloaded key, because as the owner of the device, you should be able to do whatever you want with it. If the manufacturer needs their application to only work if the secure boot settings haven't been altered (i.e. in a car, with safety/liability concerns), they can do that.
I would be a lot happier if we had a model like this for literally any other non-PC platform. Right now everybody rolls their own crappy implementation of signature checking with hard-coded manufacturer keys. It's really pretty awful.
(Well, the hard part is learning how to download all of the source code and learning how to use the Android build system, and then downloading a new system image onto the Android device; there is no technical restriction which prevents you from doing this.)
I developed the ext4 encryption specifically for Chrome and Android, and I was building my own Android images and putting it on putting it on a Nexus 9 device. This didn't require any kind of special privilege or encryption keys only available to Google employees. Neither did this:
https://thunk.org/android-xfstests
It's all open source, and you can certainly rebuild your kernel, make other changes to the firmware, and install it on your phone. No reverse engineering or hardware/firmware exploits necessary!
However, Google's approach is so uncommon, that it's basically the exception that proves the rule. The vast majority of device manufacturers don't do anything like this, and if you were to pick a phone at random, you would probably expect to encounter some sort of issue flashing it. That's why we're still stuck with databases of "if you want to run a custom Android ROM on your phone / OpenWRT on your router / etc., pick from one of these known-good devices."
I say this almost preemptively, because I really don't think it should obscure your core point: open devices are increasingly the exception, not the norm.
1: https://chdk.fandom.com/wiki/CHDK 2: https://hackaday.com/2020/09/06/a-free-software-os-for-the-r...
Google takes licensing seriously (as both know you and I know :-).
No idea why we do the same for Android phones though. No GPLv3 in there :-).
Software might be eating the world, but IP industry and legislation are eating the hardware. There soon may be no user-controlled hardware, especially with the advent of the internet where "vulnerabilities" that let users run their own code can be patched, and Apple-like certificate checking can be deployed out.
GPLv3 might be seen as an effort to counter-act this situation.
>perhaps hardware created by a competitor, or using open hardware
I think as the Purism folks are demonstrating with the Librem phone, we live in a world where the barrier to entry to compete in hardware markets is enormous. The "hardware doesn't matter" argument only holds where the hardware to run software is sufficiently commoditized or where it's easy to develop open-source alternatives.
For phones and select other segments of the hardware sector this simply isn't the case: consider the yawning chasm that separates the Librem phone from the iPhone.
Granted, all of these are legal problems that need to be remedied with judicious case law and acts of Congress. However, so is the concept of software copyrightability itself. (CONTU fucked up, software should have been sui generis.) The whole point of the GPL was to legally construct something like a public domain dedication that subsequent derivative works couldn't reverse. The idea was that software would always serve the user (or be modifiable to do so). If you look at the GPL in that light, TiVoization is a clear circumvention of licensing intent.
Given that the FSF came first, I'm not entirely sure I'm OK with calling anti-TiVo a "short-term" concern. It's more like protecting the users of the software and ensuring developers are able to collaborate under equitable terms are both long-term concerns that are occasionally in conflict with one another.
(FWIW, most of those lockouts wouldn't actually qualify for 1201 protection in isolation. However, they often are tied to systems that would. Nobody builds a separate repair lockout and DRM system - they build one system that prohibits both use cases. Even when the law agrees that you're allowed to break the part of the lock that keeps you from swapping parts on a tractor, it doesn't let you distribute the tools to do so if that lockout also enforces a copyright owner's licensing intent. So, for example, it's legal to jailbreak a phone to make Touch ID work, but that jailbreaking tool you used is still illegal because someone might use it to pirate iOS games.)
You also probably create an even greater incentive for manufacturers to strictly lock down their devices, doubling down on technical solutions in the absence of legal ones.
The second concern was that millions of devices with Linux in them would be sold for which users could not modify, share or distribute changes for. This happened beyond what anyone could have imagined. FSF fought and lost that fight, but I am not sure I would have called it a mistake. Mobile phones are full with anti-patterns, have zero security, zero privacy, zero control for the user. Their operational lifespan is a small portion of that open platforms and when the developer cuts updates then the device is unfixable. At any time the device can stop working and ransom the user for a subscription in order to regain operation. It is hard to imagine how those devices could get worse in term of user agency, except if the manufacturer join hands with an oppressive regime.
From all that I have read, the Mozilla Public License v2 [2] (file-level copyleft) seems like a good intermediate between GNU family of licenses (strong copyleft) and Apache / MIT / 3-Clause BSD (copyright).
The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. If that fork becomes more popular, there's no way for the Apache-licensed upstream to merge any patches from the xGPLv3d fork back in.
With MPLv2, all "files" in the immediate xGPLv3 fork are automatically dual-licensed under both, xGPLv3 and MPLv2. This means MPLv2-licensed upstream is free to merge in changes without worries from immediate forks. MPLv2 additionally bakes in a choice for the original developer (viz. "initial Contributor") to make xGPL forks illegal (using the incompatibility clause), but it isn't the default.
The Eclipse Public License v2 [3], which is very similar to MPLv2 in its copyleft aspects, takes this a step further and makes xGPL forks illegal by default. The original developer; however, can explicitly choose to permit xGPLv3 forks.
[0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
[1] http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...
Why is this a problem? If a GPL fork becomes more popular, you can switch your own license to GPL too, and then take the changes back. The real risk of using a pushover license is that someone makes a proprietary fork, in which case you are locked out of their changes forever, which is the exact thing the GPL disallows.
Also, the businesses need to be wary of other proprietary code they might have to now open source as an unintended side-effect of moving to xGPL.
That's exactly what the GPL is for!
Someone using Apache complaining about GPL relicenses is saying they're fine with closed-source products making money off their private forks of their code without being forced to contribute it back, but open-source projects doing the same thing is where they draw the line.
But this sort of contribute-back-upstream is not what the GPL was written for and not how it behaves. The GPL is specifically a pass-it-forward downstream focused license. It is about requiring others to pass on the freedoms. The idea that it has any send-back-upstream requirements is a common misunderstanding that shouldn't be encouraged.
Otherwise, any company could break the GPL wide open by just morally considering themselves to be the upstream.
GPL's upstream features are incidental and often practical but are not the point of the GPL and more importantly do not describe how it works legally.
My personal reasons for MPL2 are basically:
- Modern goodies like explicit patent protections without being GPLv2 incompatible like Apache.
- Showing the sharing "spirit" I'd like to see, even though it's in practice impossible to enforce against a "hostile" user (see above). That is, feel free to use it in your proprietary product, but if you make improvements to my code please share those with me.
That being said, I'm not actually sure that MPL2 is worth it, considering it's very much an uncommon license compared to the big permissive ones.
I'm not sure I understand your arguments about MPL2 being better protected against forks with stronger copyleft licenses. The forker can still make their own additions subject to the xGPLv3, as long as they're in separate source files, effectively making the combined work xGPLv3.
IANAL. MPLv2 has two modes of protection:
1. By default, the immediate fork of a MPLv2 project under xGPLv3 is auto dual-licensed (for existing files, at least). Usually, the project stays dual-licensed (even for the larger work) unless the contributors make an explicit decision to remove the top-level MPLv2 license file.
2. Initial Contributor (original developer) can choose to make the "Covered Software" incompatibile with secondary licenses (like xGPLv3) for posterity.
> An evil corporation that wants to leech without giving anything back can practically as easily do that with an MPL2 licensed project as with a permissive licensed project.
Evil corp at least (if nothing) is required to open source their changes to MPLv2 files (part of the original work), if any. Whereas Apache / MIT / BSD don't require any form of reciprocation except an attribution.
> That being said, I'm not actually sure that MPL2 is worth it, considering it's very much an uncommon license compared to the big permissive ones.
From what I know, MPLv2 is well understood and it isn't ambiguous as WTFPL or confusing as AGPL. Hashicorp and Mozilla are two of the biggest corporate users of the license I know.
Of course there can be no argument that xGPLv3 protects the interests of the consumers better, though, MPLv2 (and EPLv2), I feel is a good compromise.
No, you can't change the license of existing code that you don't hold copyright of. Even permissive licenses like MIT don't allow that. Where you can add your own license terms is for additional code you wrote that you hold the copyright for. Permissive vs. weak vs. strong copyleft then tell you under which terms you can combine your own code and the other code that you forked.
> 2. Initial Contributor (original developer) can choose to make the "Covered Software" incompatibile with secondary licenses (like xGPLv3) for posterity.
The "secondary license" thing in MPL2 is a (clever) hack to make it compatible with *GPL. That just means that without the secondary license you can't make a combined work (called "larger work" in the MPL2) that contains both MPL2 code and your own GPL code. It doesn't allow you to relicense MPL2 code to GPL.
> Evil corp at least (if nothing) is required to open source their changes to MPLv2 files (part of the original work), if any. Whereas Apache / MIT / BSD don't require any form of reciprocation except an attribution.
Yes, but nothing prevents Evil Corp from just doing minimal modifications to the MPL2 code to add entry points or call out to the proprietary code in other files.
That is sort of the argument against weak copyleft licenses in general; they are easy to circumvent. So if you want copyleft protection, you should go for a strong copyleft license, or then you just accept that Evil Corp may leech and you might as well use a simple permissive license.
> From what I know, MPLv2 is well understood and it isn't ambiguous as WTFPL or confusing as AGPL. Hashicorp and Mozilla are two of the biggest corporate users of the license I know.
Maybe. I mean, if you look e.g. at https://resources.whitesourcesoftware.com/blog-whitesource/o... MPL2 isn't even a rounding error.
> Of course there can be no argument that xGPLv3 protects the interests of the consumers better, though, MPLv2 (and EPLv2), I feel is a good compromise.
Yeah, I think in many ways GPLv3 is pretty good, but considering how soundly it has been rejected by corporations I'm not sure it's worth it..
It's not that simple, see: Modifying and Distributing Files Licensed Under Both the MPL and (L)GPL.
Once an MPL-licensed file has been distributed as part of a larger (L)GPL-licensed work, third parties who receive the file may use and redistribute the file under the terms of either license. As a result, new modifications can be provided to recipients under the terms of both licenses, or solely under the terms of the (L)GPL.
https://www.mozilla.org/en-US/MPL/2.0/combining-mpl-and-gpl/
> So if you want copyleft protection, you should go for a strong copyleft license...
True, but MPLv2 with incompatibility clause (or EPLv2) prevents stronger copyleft, which has some nice properties whilst also retaining a weak "file-level" copyleft (which enterprises are okay with).
If the GPL fork becomes more popular then one of the main arguments for not having a GPL license falls apart.
Good luck with the open sourcing!
I'm curious if anyone knows of any cases where this actually happened.
"scary" from a different perspective is "functional". Many companies also push back against even GPLv2 in anything other than the Linux kernel, and as a result, more people use permissive licenses, even when those permissive licenses run counter to their goals. I've directly seen corporate decision-makers ask "how can we prevent our competitors from using this to compete with us" and yet still choose permissive licensing rather than copyleft, for no obvious or stated reason. That's leaving aside many individual projects using permissive licensing; I wonder how many people doing so specifically want permissive licensing for a concrete reason, and how many just aren't sure and so they pick what seems more prevalent/"acceptable"?
In many contexts, GPL of any flavor is "that thing that the Linux kernel and a few bits of low-level Linux userspace use, and everything else avoids". GPLv3 didn't cause that; widespread corporate pushback against copyleft caused that.
GPLv3 either went too far, or not far enough (in terms of cost incurred: gaining enough ground that the community split is worthwhile, volume of license text, ...).
If I had a time machine, I'd suggest the FSF to try frog-boiling people into software freedom instead.
I also wonder whether many people would have refused to use the GPL if it had had the "or any later version" built in and unremovable, rather than making it part of the license grant.
1) GPLv2: a legacy license still dominating e.g. Linux and other projects that simply never switched and leaves enough legal loop holes to not block commercial usage. Huge commercial success and arguably what bootstrapped the OSS world.
2) Apache 2.0. Huge commercial success and together with the MIT & BSD style licenses the no brainer go to license for anyone wanting to release some software under reasonable terms. These licenses dominate the vast majority of Github projects.
3) GPLv3 & AGPL v3. Only used by 1) people with outlier opinions on freedom related topics (trying to be diplomatic here). 2) companies looking to dual license their software under a highly restrictive commercial license or a highly restrictive OSS licenses. Technically free but limiting in practice in what you are actually allowed to do to the point where you probably need to worry about signing a proper deal for a proprietary license. Which is a different way of saying that it is not free at all You are not free to do what you want and you are certainly not free to build a business on top of the software; that requires a non free closed source license. The OSS limitations with respect to any form of commercial applications are kind of the whole point for the companies choosing this license: it practically leaves their users no other choice than their commercial license. Whatever your opinion on this, these licenses are considered problematic by most corporate legal departments and simply not widely used by companies with such departments for this reason.
A common mistake in interpreting the GPL in my experience is that it is designed to protect the freedoms of the producer. It is explicitly designed to promote certain freedoms for the user. The producers set and the users set are likely to intersect, which is likely where some of the confusion comes from, but it is not common that they are identical sets.
If the corporate world is part of your target audience, then the GPL family, particularly AGPL and GPLv3 (though not so much so LGPL) are unlikely to be good choices. This is true whether you are a solo home developer, or a significant commercial entity, or something in between, yourself.
Just like commercial licences, and other F/OSS licences, the GPL takes away nothing. It grants rights subject to the grantee agreeing to its other conditions.
> under reasonable terms
That is a very subjective thing.
If commercial entities won't touch something of mine because I've chosen to license it under GPLv3/AGPL/else, that is only a problem for me if I care whether commercial entities use it. They are free to try negotiate a different licence. Of course I'm only able to do that for my contributions unless others the project has taken contributions from have legally stated on the record something to the contrary, but that is no different than for a commercial project which has multiple otherwise independent contributors.
As far as I know most fortune 500 companies would probably have similar reservations about these licenses (correct me if I'm wrong). Companies like TerminusDB switching license because "sufficient lawyers have advised teams to be wary of GPL" probably means that they were loosing lucrative deals with big customers because of the license. Hence the switch. I think dual licensing as a viable business strategy is pretty much dead at this point. An overly restrictive OSS license is a hard sell for a SAAS business in a competitive market with alternative solutions.
Legal interpretations are not an exact science of course but there's enough language in these licenses to cause raised eyebrows for lawyers and probably not enough court cases to argue one way or another definitely. That equals a lot of uncertainty and corporate legal departments hate that sort of thing. GPLv2 has had some exposure in courts over the years so lawyers are more comfortable with it at this point and know how to limit and contain its infamous viral nature.
I've also seen blanket bans on all GPL related licences in code (the dynamic in OS/app/other use differs, though way-back-when there was enough FUD/misinformation that there were blanket bans for those too) especially when GPLv2 was introduced (the "liberty or death" aspect was the cause of much consternation, I recall).
I don't think they are interpreting the license differently though for the most part. They are agreeing that is protects the user not the producer, and in giving those protects to the user it might be inconvenient for them (or even impossible for them legally, depending on licensing agreements and other restrictions they have to operate under regarding other parts of their codebase) as a producer.
> In other words, they weren't amateurs; like us.
At least some of the original impetus for the GPL was to protect amateurs like us from being used as free resource for parties that aren't. I'd say this is the system working.
> I think dual licensing as a viable business strategy is pretty much dead at this point
That is quite likely true, but only relevant in such a commercial context. If a developer doesn't care about commercial users of their code, for instance they are scratching an itch & want to share but aren't seeking worldwide adoption (and hold those "outlier opinions on freedom related topics"), then this is not a problem and GPLv3 is still a relevant option on its own.
Commercial viability is not the be all and end all of licensing decisions, if commercial gain and massive reach are not your concerns.
If a user wants to integrate my software into their commercial software, then they in turn pay me for their commercial use of my software.
If a user wants to integrate my software into their software to distribute it freely, then they don't pay me.
The only time a problem exists is when someone wants to integrate my software into their software for commercial purposes and doesn't want to pay me for it.
I also do the same myself. Internally within my company I use Linux and MySQL, both of which are GPL'd software and I am a very happy user of both software products and never felt like I was restricted in how I can use them.
If I wish to incorporate MySQL into commercial software, then I'd need to pay Oracle for a license, but I have no need to do that.
In what way is any of this incredibly restrictive?
At any rate, I don't know that we're going to change one another's minds on this issue, all I can say is that there seems to be a fairly substantial group of users who do not feel restricted in how they use very popular GPL software such as Ad Block, Wordpress, Git, Linux, MySQL.
I use all of those and never once felt like they restricted my usage.
Most freedoms constrain others. The freedoms that the FSF care about are the freedoms of the users. Not the freedoms of the developers, and not the freedoms of the corporations that make the devices that sell to users. If you want to recognise and protect the rights of end users, you will constrain other peoples rights to exploit them in various ways.
Which is to say that I think that GPLv3 (dual) licensed software does give genuine freedoms, even if they aren't the freedoms you are most interested in.
Your freedom to create a consultancy around the GPLv3 licensed code and to charge for customisations or support are all protected too. Again, I understand that that isn't the kind of business you wanted to build on top of the software, but it's still a real freedom.
I actually think a dual license might have been better in the case of terminusDB too.
https://github.com/search?q=license%3Agpl-3.0&type=Repositor... 1,419,692
https://github.com/search?q=license%3Aapache-2.0&type=Reposi... 1,500,312
gpl2 414,348 MIT 5,501,412
The free software fight has already lost in spirit. It's not even clear that it ever could have really survived with how complex software has become, anyway. Are any of us really able to customize MS Excel to do something new that we want anyway?
If corporate money always wins, then why do we have environmental legislation, worker protection laws, 40 hour work weeks, overtime pay, anti-child labor laws, and unions?
Sure, in some places and in some cases these have been violated or aren't as strong as they could be, but you can't say they they don't exist and corporations and money always win.
Something else we need to keep in mind is that corporations are made of people, and the opinions of these people can and do change.
Plenty of things that used to be unthinkable in the past are now commonplace, and plenty of things (like slavery or segregation) that were ubiquitous and seemed inevitable to a lot of people back then came to be rejected by society at large.
I'm an idealist. I do lots of things that are inconvenient and feel like a losing battle.
I understand your point about outright banning GPLv3 vs just avoiding GPLv2. But I have to wonder what would have happened in an alternate timeline where KHTML, Samba, and GCC were all GPLv3 at the point in time where this universe's Apple adopted them. Would they have just skipped making their own browser and integrating with SMB?
Without GPL, all commercial UNIXes would be around and Linux would be just another school clone.
1. Protections against patent trolls (similar to Apache-2.0, so this is a clear improvement over the GPLv2 which didn't protect users from patent trolls at all).
2. The enforcement provisions were made much less harsh (the GPLv2 immediately terminates your rights upon any violation of the GPLv2) with a curing period so that distributions could rectify honest mistakes without losing their rights.
These two are both clearly improvements over the GPLv2 (so much so that many distributions in the Linux community have explicitly promised to only enforce GPLv3-style enforcement for non-compliance of their Linux copyrights[1]).
3. The "tivoisation clause". This one is probably the most controversial change, but honestly it's actually a fairly understandable extension of this clause of the GPLv2 (s3):
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
In 1991, firmware keys and walled-gardens were unheard of and so I would expect that most people living in 1991 would expect the above line to mean that you should be given everything required to install a program (including if it came with a piece of hardware). You may not personally feel that this is reasonable, but given that the FSF's main goal is complete software freedom, I am surprised people can't see the above clause from their perspective. Today we know that firmware keys aren't part of "the scripts used to control compilation and installation of the executable" and so with the GPLv2 you can still get locked down devices. Hence the "tivoisation clause".
[1]: https://www.redhat.com/en/about/gplv3-enforcement-statement
I've not got anything out there covered by GPLv3, or any GPL these days, but I remember the same arguments against GPLv3 being given for the older versions too.
Much like the answer to "if it doesn't say how much it is, it'll be too much and I move on" is "that is probably the intention, if you move on for that reason then you probably aren't the target audience" - if you are scared of GPLv3 then you probably aren't the target audience of the people using it.
(of course if you are the target audience, and they state as much, there is obviously a disconnect somewhere, in both cases)
I don't agree that the changes in GPL (AGPL, GPLv3) are the reason for the drop in use of that family of licences, rather that the rise in less restrictive open source options would have happened just as much had GPLv3 never been a thing. That is a mix of many people becoming less ideological in their licence choice overall as the F/OSS developer base increased, and an increase in commercial interest in F/OSS software that has lead to investment (dev & other time & resource, not just money) which has of course gone to less restrictive projects where such exist for obvious alignment-of-interests reasons.
So companies use Linux because it provides a better cost/benefit solution than the alternatives. I will argue that the GPLv2 helps this situation by allowing Linux to get back the software investment made by other companies and merge them back to the core code. So I will be the first to argue that the GPL approach has its benefits. But it also, at the same time, makes companies uncomfortable. So it's simply a matter of nuance. The more value you can provide, the more you can insist that that companies "give back" to the community.
I believe the GPLv2, as, for at least some software projects, manage to achieve a balance which works for most of the stakeholders. And I don't consider this to be "the companies are taking advantage of free work from the community", because the companies are paying developers to work on Linux, so their are part of the community, and they are also contributing back to the community. We just need to make sure that the benefit is such that it is worthwhile for companies to continue to contribute to the community. The whole point is that this is not a zero-sum game, but that by enforcing cooperation, everyone wins.
But if the GPLv3 is too scary, such that no one wants to even try out the community model, then it's a losing proposition.
It's clear that the Apache license is more friendly toward corporate concerns. But companies were willing to deal with GPLv2, because there were sufficiently large projects (such as the Linux kernel) that added enough value that it overcame their fears over how the GPLv2 restricted how they could monetize their software engineering investments.
Unfortunately, the GPLv3 and even more so, the AGPLv3, was simply a step too far; put simply, in my opinion, the FSF overplayed their hand. Whether a more scaled back GPLv3, or simply sticking with GPLv2, with all of its admitted ambiguities and admitted legal short-comings, would have made enough of a difference at the end of the day is impossible to know. But I think copyleft as a viable open source licensing regime, and the GPL in particular, would have had a much better chance of success if GPLv3 never happened.