That isn't what it means but the problem with it is that it has extra knock on effects.
There is a reason GPL v2 was incredibly popular and GPLv3 basically killed all momentum and it wasn't because GPLv3 was better. At least not from a business point of view.
And that, at its core, is the issue. In a world where the only licence is GPLv3... it works. But in a world where people can choose other licenses - it won't be the choice of most.
It's a shame because I love the GPLv2 but I'll never use GPLv3 and honestly it's just less hassle to chose MIT for most companies.
You should stop looking things only from "a business point of view", often what is best for business is bad for the users - even if they don't understand it themselves to care enough about (at which point what the business is doing is little different from taking advantage of their users' lack of knowledge and should be shamed instead of used as an example for others to mimic).
Thinking like yours gave us GPLv3 and less subsequent adoption of copyleft licenses.
Which means you’ve got a lovely and ideologically pure hill to die on, but die you will.
In the real world code is useless without being adopted. The largest adopters? Businesses. They don’t want to use GPLv3? Less developers likely to use it (market forces I’m afraid).
So no, I’ll keep paying attention to what works and not be beholden to the idealistic notions of the FSF, thanks.
What business stay away from GPL3 that were OK with GPL2? The only one I can think of is apple and they're the type of free loaders that don't benefit the wider OSS community anyway. Most companies are still using linux with gnu tools so the version 3 hasn't affected them at all.
Back in 2008, a large "feature-phone" chip maker I used to work for decided the GPLv3 was a total no-go while the GPLv2 was kinda reluctantly accepted.
The same business that will happily take anything that is MIT licensed, to reduce development costs by getting software at $0 and never contributing anything back.
When they do, is only a few bread crumbs to the villagers, while keeping the crown jewels behind their gates.
But hey, "they are contributing back see how nice they are!".
I used to be a big (L)GPL zealot during the 90's, nowadays I just reverted back to using commercial software, because the community just doesn't care about companies taking their work away.
>The same business that will happily take anything that is MIT licensed, to reduce development costs by getting software at $0 and never contributing anything back.
Isn't that part of what people chose MIT for? To allow businesses to adopt their project without having to "contribute anything back"?
>I used to be a big (L)GPL zealot during the 90's, nowadays I just reverted back to using commercial software, because the community just doesn't care about companies taking their work away.
Isn't that their own decision? Whether to worry about or not?
People chose MIT because they are OK with this scenario.
Yeah, but then they aren't entitled to complain that cannot get access to the fork used by company XYZ, that the *BSDs get less love than GNU/Linux, embedded OEMs don't publish their clang forks, Android devices are locked down to a specific version,.....
Right, and at least I am not aware of complaints like such. My experience rather is, that any larger customisations of open source software are usually propagated back to the project for the simple reason of saving the hassle of maintaining a fork of that software.
I imagine you don't have much experience with enterprise code.
They have piles of patches and team specific forks that are never going to go out of those Clearcase and TFS repositories.
Sony was the only company I ever saw doing a presentation at a LLVM summit, referring that keeping up with upstream as their main reason to get the PS4 clang code "partially" into clang. They did not contribute back any kind of optimizations that might reveal too much of PS4's architecture.
I guess some would say it is better than nothing.
OEMs using Android or BSD/Linux forks for embedded use, don't have any issue maintaining their own forks.
I am working at a very large software company, don't know whether that qualifies as enterprise code :).
Yes, if you do customisations of open source software which could reveal trade secrets, I wouldn't expect this to be back-donated, and you could do that only with permissive licenses in the first place. But the large majority of open source software means just using it, and if it gets modified at all, it consists of bug fixes an small enhancements, that can and are back-donated to the projects. And as you wrote yourself, Sony tries to get the changes which don't disclose their trade secrets into upstream to reduce the merging load.
How many of those patches have non zero chance to be accepted and how much time would it take to actually hop through all obstacles to push them? My answers are 1.) a few 2.) a lot.
Majority of Linux contributions are paid by various companies. It is not volunteers working for free, it is companies paying.
GPLv3 has many, many improvements over GPLv2. In fact, there are several improvements that should make it _more_ favourable to companies:
1. The terms of section 8 (termination) are much "nicer" to people who make mistakes and infringe on the terms of the GPLv3. GPLv2 was very hard-line, and in principle the revocation of rights was immediate. This is something that companies should _like_ about GPLv3.
2. The text is written to be far similar to a legal document (GPLv2 uses non-standard formatting especially with regards to how definitions of terms are done), which makes it easier for lawyers to understand and argue about the license.
3. It is compatible with Apache-2.0 now, by having a patent protection clause that is similar to Apache-2.0 (but of course it's copyleft) -- most notably it only affects contributors (which includes people who distribution verbatim and modified works). Using the program doesn't add any patent requirements (other than the Apache-2.0-like patent revocation system).
4. The "tivoisation" clauses that people like to make a fuss over actually only state two key things. First, it states that no software licensed under GPLv3 "shall be deemed part of an effective technological measure" -- which effectively means that the DMCA cannot apply to GPLv3 licensed programs (this is good for both users and companies). Second, one of the requirements is that you must distribute tools and instructions (this includes things like keys if appropriate) for changing the software on a system. This second requirement may seem onerous, but it actually doesn't require you to ship the hardware signing keys if you have a way to disable the hardware signing (or a way to replace the signing keys without needing the original keys). This is also good for companies that buy hardware that has GPLv3 software (but it does place some additional burden on companies that ship said software).
While (4) might cause some angst, there are other very useful features of the GPLv3 that you seem to be ignoring. Not to mention you didn't actually specify what the issue you're talking about is. I presume it's got to do with the "tivoisation" clause, but that clause is not the most important part of GPLv3.
Not to mention that, depending who you ask, there is a "tivoisation" clause in GPLv2. In particular, GPLv2 states that "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" (emphasis mine). Personally "the scripts used to control [...] installation" could include instructions on how to install an executable on a piece of hardware you've sold me (if that hardware has DRM, you have to tell me how to install the executable despite the DRM). This is still not entirely agreed upon in in the GPL conformance community (the SFC has not explicitly stated which way they go on this one either).
The question is not how many "improvements" GPLv3 has, as long as there exists any single clause which makes it incompatible with the business, it is ruled out as a base of operations.
> GPLv3 basically killed all momentum and it wasn't because GPLv3 was better. At least not from a business point of view.
I was pointing out that this is not entirely correct. There are quite important improvements in GPLv3 that are "better" from a business point of view. Very few businesses care about the "tivoisation clause", and some businesses may actually benefit from not having to worry about being provided GPLvX software that they can't modify.
There is a reason GPL v2 was incredibly popular and GPLv3 basically killed all momentum and it wasn't because GPLv3 was better. At least not from a business point of view.
And that, at its core, is the issue. In a world where the only licence is GPLv3... it works. But in a world where people can choose other licenses - it won't be the choice of most.
It's a shame because I love the GPLv2 but I'll never use GPLv3 and honestly it's just less hassle to chose MIT for most companies.