Hacker News Reader

Comment by tytso | Hacker News Reader

I've always thought that the GPLv3 effort was one of the FSF's biggest mistakes. It split the GPL community into GPLv2 and GPLv3, since the two aren't compatible. And the GPLv3 was simply far too scary for companies.

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.

View on HN

> the GPLv3 was simply far too scary for companies.

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.

Not everyone agrees that the freedom to start a SaaS business with GPL software is a "loophole".

I wonder when this idea really started propagating, was it around when AWS came along? Because by a technical definition I don’t understand why this “loophole” wouldn’t also apply to a hypothetical web host back in the late 90s.

The GPL has no element saying it can't be used to start any kind of business, and I don't think any of its defenders has ever said the GPL's goal is to suppress that freedom. It seems the FUD is still going strong.

The same people who made the GPL use the term "ASP loophole" and made the AGPL.

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.

Not everyone has trouble with AGPLv3 being the core of their SaaS business.

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.

But the comment you replied to was about the v2->v3 loophole fixing. That has nothing to do with AGPL, it's about bootloader locking.

AGPL isn't pro- or anti-SaaS, though. It just says that you have to provide sources to anyone you grant access to the software over a network. So if you host an AGPL database for someone else, they need access to the source code for that database somehow. But it doesn't prohibit you from hosting the database at all.

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.

AGPL restricts developer freedom simply because they launched a webserver on the same machine. There is a legitimate logical argument that the AGPL is not free software.

The whole idea behind copyleft, hence free software as Stalman envisioned it, is to restrict the developer's freedom in favour of the user freedom.

Copt-left licenses are about preserving the users’ freedom. If we want to maximize developers’ freedom then the freest license is proprietary code where you own all the rights and then you can do anything you want and nobody can do anything about it.

No, the license that maximizes developer freedom is a permissive license, like Apache, MIT, BSD 3-clause etc. That lets you mix your code with either a proprietary or a copylefted project. Since a lot of Free Software is written by people who just want to solve a problem for themselves, they often just pick the permissive license.

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.

> the license that maximizes developer freedom is a permissive license, like Apache, MIT, BSD 3-clause etc.

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.

So you're using the world "developer" not as the one creating the project, but as the one retrieving it and modifying it. That's actually what licenses call "users", and copyleft licenses improve your liberties by maximizing the amount of projects that are Free.

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.

> Not everyone agrees that the freedom to start a SaaS business with GPL software is a "loophole".

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.

The reason people confuse it is because early work on GPLv3 was going to include similar clauses but they were later abandoned.

Thats wrong too. If you use an unmodified version of AGPL software, or just host any modifications in a public repository like github, then you aren't in violation of AGPL, even if the rest of your stack is proprietary and your service paid. How does it prevent SaaS?

Are you thinking of AGPL instead of GPLv3?

AGPL, like any version of GPL (and most if not all open source licenses) does not prohibit anyone from starting a business. It's weird this FUD is still spreading after all this time, after all the debates the community has had already.

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 ?

I can count the number of remotely successful businesses built on AGPL software on one hand.

The AGPL doesn't prohibit starting a business, it makes starting a business prohibitive.

OwnCloud, NextCloud, Linphone (their pricelist starts in the 5 figures for support!), etc all run successful businesses off AGPLv3 code. Amazon is notorious for turning AGPLv3 projects and products into SaaS services!

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

Also I think GCC's loss of prominence due to LLVM hurts the pull of the whole GPL ecosystem.

Isn't this the other way around? LLVM makes it easy to embed parts of the project into IDEs, linters, etc.

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.

Maybe I’m misunderstanding but it seems you’re totally in agreement!

If by "involve everyone" you mean "ignore the many many companies that said the current GPLv3 is a non-starter and will entirely end our involvement" then sure.

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.

FSF picked the bone that needed to be picked. Well, they should have addressed tainted linux kernel firsts... but oh well.

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.

> The FSF made a huge effort to make GPLv3 not scary.

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

> it was a resounding no according to Linus' very public rant at a Debconf a few years back

This one? https://www.youtube.com/watch?v=PaKIZ7gJlRU&t=241

Yes, thanks for the link.

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

The fact that the Linux kernel removed the "or later version" from the licence and doesn't do copyright assignment make it impossible to switch to anything other than GPLv2.

You'd need to get every single person who'd contributed to agree. Even if they're dead.

It's not that insurmountable. Each release, large parts of the kernel get rewritten anyway. Lots of kernel code is copyrighted by companies now.

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.

> Each release, large parts of the kernel get rewritten anyway.

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.

That's a good point. But then it immediately brings up the question: if that's the case, why would the FSF have been in communication with the Linux kernel peeps with regard to license compatibility and potential upgrade? I can understand getting input from them on the upcoming GPLv3, but not an effort trying to convince them to adopt it.

It was never going to be possible for Linux to switch, so it's honestly a bit of a moot point. By 2007, the overwhelming majority of copyrights were not held by Linus and lots of the code was already licensed as GPLv2-only (not to mention that tracking down copyright holders pre-Git would've been basically impossible -- and that's before you start worrying about bankrupt companies or people who've passed away). Switching licenses is incredibly hard, and in my view it was a mistake to make GPL upgrades opt-in (they should've been opt-out as is the case with the Mozilla Public License).

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.

The LLVM relicense shows that it is actually possible for a large project with distributed ownership to switch licenses given there is enough motivation to do so. From what I understand as a non-lawyer, situations with this old code where the copyright owners can't be tracked down is undesirable for a number of reasons and they may need to rectify that eventually anyway. (I believe it can be seen as a liability)

> It was never going to be possible for Linux to switch, so it's honestly a bit of a moot point.

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.

FWIW the situation is not quite as bad as Linus implies. He may personally dislike GPL3 but that doesn't appear to reflect the opinions of the entire project. A license analysis of the current mainline Linux source shows that roughly 30%-40% files in the kernel are already GPL3 compatible because they're either licensed as GPL-2.0-or-later or dual licensed as MIT or BSD. (I don't have exact statistics on this, it's a rough estimate from a non-exhaustive SPDX audit. You can reproduce by simply grepping through the source for license identifiers) This can happen because individual kernel developers can contribute using whatever license they like as long as it's compatible with GPL2 for a binary distribution. Additionally, Linus and several other kernel developers did decide to adopt the termination provisions from GPL3 not too long ago [0].

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...

To be clear-- I didn't get the sense from Linus' rant that he's opposed to GPLv3 at all.

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.

There were a lot more concerns than just that. I refer you to:

https://lwn.net/Articles/200422/

You might be right as a practical matter, but I do think the FSF's tivoization concerns are well-founded, especially in light of what we've seen happen in the mobile industry. If the user isn't allowed to actually compile and run their own code, what good is it for that code to be open source?

If you believe that "software will eat the world", then hardware doesn't matter. Sure, the customers who purchase a locked-down device might not be able to update their device. But the technology will still be out there, so that it can be built upon to improve the next generation of hardware --- perhaps hardware created by a competitor, or using open hardware. This is especially true for consumer-grade devices, which generally become obsolete and replaced within 2-3 years anyway.

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.

Right to Read comes to mind.

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.

>hardware doesn't matter

>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.

The way free software is supposed to work is that you buy a device, you want to improve it, so you do. And then you share your improvements with everybody else.

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.

This argument doesn't work when PCs are essentially the only widely available hardware platform that ended up with an open standard for modifying the software running on the device. Even here, the fact that we ended up with this model was an accident.

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.

That simply is not true. Chromebooks, many Android phones (all of the ones sold by Google) have a way of turning off the requirement for signed boot. The device is less secure if you disable signed boot; an evil maid who gains access to your device, or the FBI after they seize your device, will have a much easier time getting access to your data --- but if you want to build your own version of Chromium, or put your own Linux distro on a chromebook, or if you want to build your own version of Android from source, and put it on a Nexus or Pixel phone, you can do this easily.

(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!

You're right. For all of Google's other flaws, their hardware has been surprisingly good about this. The Chromebook write-protect screw is a good example of a thoughtful feature here.

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."

There are a lot of other devices (that aren't x86 PCs) which let you boot OSs wholly from third parties. A couple that come to mind are Canon Cameras[1], and the Remarkable Tablet[2]. A lot of routers, too, don't put up any barriers the installation of alternate firmware (some do), and even Apple Silicon Macs can be made to boot unsigned OSs (and are getting a Linux port). Not to mention the Raspberry Pi and its ilk.

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...

Ted, you have to remember why Chromebooks have a way of turning off signed boot. It's actually to comply with GPLv3 requirements for the GPLv3 code used in ChromeOS.

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 :-).

Google could have stripped GPLv3 code out of ChromeOS like they did with Android. The reason why they provide owner overrides is entirely a matter of corporate culture.

Yes, this is true. Google corporate culture is one of the big reasons I work here. There are few places that take Open Source as seriously as Google does.

Intellectual property is a state enforced monopoly that interferes with market forces. In a purely market driven world “locked down” phones would be harder to create/enforce.

If you're eliminating intellectual property you're eliminating the GPL anyway.

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.

My point is that this is not a "free market". It has substantial restrictions.

You have the market forces backwards. People don't avoid the lockouts, the lockouts shape people into a particular behavior. For example, look at Apple's ridiculous levels of anti-repair nonsense - it is designed specifically to make it harder for non-Apple technicians to properly repair a device. These lockouts have legal force thanks to... rather prevalent misreadings of DMCA 1201 that make large companies unwilling to design circumvention tools for these sorts of things.

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.)

It always seemed to me that problem with GPLv2 wasn't any shortcoming in the license, as such, but in certain legal opinions that labeled things "compliant" which were clearly against the spirit. TiVo-ization is a violation because GPL software and proprietary software are combined to form a single piece of software, distributed as a single binary firmware image; the fact that there's some notional internal interface between the GPL and non-GPL code within, if you manage to crack the firmware that is, should be legally irrelevant. But engineers are wont to be distracted by concerns such as "kernel space" and "user space", and "dynamically linked" vs "compiled in". Absolutely none of this matters, if I'm getting a big-ass opaque blob with a mixture of GPL and proprietary code in it. The same goes for the average Android handset, for that matter.

I think the battle was lost by not pushing the advantage hard enough.

I don't think I agree with that. I want to be able to run GPL programs on Windows, for example.

There's nothing stopping you. What would be stopping you is if Windows included DRM that stopped you running all GPL programs apart from Microsoft Official Builds™.

Well, I wasn't clear that it would still be allowed under the interpretation the GP was advocating for. Perhaps they need to flesh out their position.

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.

This is why Apple is so scared of GPL3 on iPhones/iPads.

GPLv2 and GPLv3 both have an exception for proprietary "system libraries", which is designed to allow you to ship GPLed software that runs on proprietary systems. (You still have to meet the terms of the GPL in other regards, but you can ignore the system libraries.)

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.

That would be fine. The software is distributed to you separately, and so any "derived work" resulting from installing your GPL software on Windows is owned by you anyway.

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?

The more interesting case is when the software automatically downloads said binary.

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.

> 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.

Yes, the boundaries are fuzzy; that's typical in law. The "reasonable person" language is not my invention, and it's assumed that somewhere along the line someone is going to have to fight in court over the particulars of ambiguous cases. The ambiguity is a strength - it forces compliance with the spirit of the wording, instead of risking litigation by trying to find a technical loophole.

Software engineers consistently underestimate the degree to which law is not like coding.

GPLv3 effort was made in order to address two main problem. One was that the market dominated manufacturer who held close to 90% of the market was going around and claiming royalties for claimed software patent in free software, and if I remember right against actually members who participated in the drafting of GPLv3. People saw how a dominated party would distribute GPL software and then go and try shake down same people for patent money, and people were really scared at the time. Quality patents like "1-click" were being fought in courts and companies like Microsoft spent billions, with a capital B, of dollars on patent deals. People did not assume Microsoft just did that for laughs and so the drafting process had a distinct goal of addressing this problem. After gplv3 release Microsoft did halt their claims on Linux users, which could naturally be just a major coincidence.

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.

We are about to open source our projects too [0], and have been faced with the question of xGPLv3 vs other permissive licenses. Not a big fan of source-available licenses because as Bryan Cantrill argues, one is better off with closed-source in that case [1].

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...

[2] https://www.mozilla.org/en-US/MPL/2.0/FAQ/

[3] https://www.youtube-nocookie.com/embed/uKKVydoqF_0

We thought about the Eclipse Public License in advance of the shift. There is a very persuasive member of our community who argued in its favor. In the end, it is ease of recognition that swayed us to Apache. If you have to forward for approval or read the details of the license before getting started, that is often a bridge too far.

Good luck with the open sourcing!

> 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.

I'm curious if anyone knows of any cases where this actually happened.

LibreOffice vs OpenOffice. LibreOffice is, IIRC, under the MPL2, and can take improvements from the Apache-licensed OpenOffice (and has done so in the past, though Apache OpenOffice has been moribound for its entire existence so there's not much to take from there anymore), but Apache OpenOffice can't take improvements from LibreOffice.

I have released some minor personal projects under the MPL2, but in practice AFAICS MPL2 isn't much stronger than the permissive licenses (Apache/MIT/BSD/etc.). 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.

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.

Apache is GPL3 compatible. Did you mean GPL2 incompatible?

Yes, I clarified that.

> I'm not sure I understand your arguments about MPL2 being better protected against forks with stronger copyleft licenses.

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.

> 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.

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..

> No, you can't change the license of existing code that you don't hold copyright of...

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).

"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."

If the GPL fork becomes more popular then one of the main arguments for not having a GPL license falls apart.

> The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3.

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.

That's assuming the businesses using the Apache Licensed version are comfortable with the original developer moving to xGPL.

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.

What if you went with GPLv2 only as your license? It isn't AGPL-compatible, so nobody could release an AGPL fork, and then companies wouldn't have to worry about it unless they distributed your code to other people, rather than just using it themselves, with the former being way less common than the latter. And most companies are okay with GPLv2 since they use Linux.

The irony of someone using Apache license complaining that other people's usage of their code doesn't let them merge changes back is, of course, palpable.

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.

I agree with your sentiment overall (if you don't want obstacles to merging back downstream code, maybe consider requiring that it keep compatible licensing, i.e. use the GPL, use copyleft).

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.

Yes, but by the point your downstream project has changes that you want to merge back, it is the upstream for purposes of GPL sentiment. These roles are transactional, not historic.

Otherwise, any company could break the GPL wide open by just morally considering themselves to be the upstream.

Not strictly. Downstream GPL users do not need to publish their changes. Businesses and individuals can get GPL software, change it for their own internal use and keep the changes private.

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.

> And the GPLv3 was simply far too scary for companies.

"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.

Reading the text of GPLv3 closely, I was disappointed at how little its additional provisions actually protect. It read like it guarded against Tivoisation and not much else, but the world's moved on since then.

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 do wonder what would have happened in the counterfactual world in which the FSF put out a new version of the GPL annually, with minor changes in each version, rather than a big revision one time. A slow ratchet, together with the guarantee of forward-compatibility.

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.

Endless FUD is a likely outcome of that. Worse than now, if you can imagine it.

I think you are absolutely right. Basically don't take my opinion for it and just look at how the corporate world has responded to licenses:

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.

Not really

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

> 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.

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.

I dual license my software using GPLv3 and don't feel like I fall in any of your categories.

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.

Yeah you're very clearly in the third category, further described under the second point.

I don't see how that's the case. There are corporations that use the GPL'd version of my software without issue. They use my software internally and also extend it with custom functionality for their own business purposes and have absolutely no issue doing so. There are also corporations that use the commercial license of my software in situations where they wish to release software commercially to other parties.

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.

That is exactly my point of view. Good luck keeping it that way.

> you are certainly not free to build a business on top of the software

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.

I suspect neither of us are lawyers. On the other hand I've definitely dealt with corporate lawyers pretty much interpreting it exactly as I outlined. And by that I mean they issued a blanket ban on any single line of code licensed under GPLv3. For GPLv2 the verdict was use with caution and MIT/Apache 2.0/Eclipse/BSD/etc. were generally fine provided the code was licensed properly and clearly (some projects fail this test). This was Nokia around the time they were in the courts with Apple, Qualcomm, Microsoft, etc. regularly on all sorts of IP issues and at the same time they were putting together a Linux based phone platform. In other words, they weren't amateurs; like us.

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.

> issued a blanket ban on any single line of code licensed under GPLv3

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.

I think the truth is that money wins. It doesn't really matter that GPLv3 is stricter than 2. Corporate interests didn't like GPLv2 either. They just dealt with it to use Linux. I think the current state of things was basically inevitable. Corporations love open source because it means they can outsource labor to "the community" and use that labor to profit on their actual cash cows.

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?

Various companies, Apple most notably, clearly avoid GPLv3. For years Mac OS X has had the last GPLv2 version of bash.

Amazon had GPLv3 blacklisted when I worked there. Nothing new by way of legal concerns about GPLv3. No lawyer is going to advise a company to take actions that will likely see the company go to court to explore just how much of a license is legally enforceable, and just what it actually means.

And they also avoided GPLv2. Sure, they had bash, but all of the "coreutils" were the BSD flavors. That an exception was made for one or a couple of things doesn't exactly counter my claim very strongly.

They accepted the sister LGPLv2 license as the basis of WebKit, and had other tools like Samba integrated. They may have avoided the GPLv2 when easy, but they outright banned GPLv3 (froze bash and gcc on the last version while working to remove them; wrote their own from-scratch CIFS implementation to drop samba).

They accepted those things because they had nothing else. The forked WebKit from KHTML, which was LGPL. It's not like they chose that license. Same with Samba. It was either take those things or invent something new. Especially at that point in Apple's history, they probably didn't have the resources to NIH everything. Today, that would be a different story, I'm sure.

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?

Darwin is a BSD so maybe there is another explanation for that.

That’s probably more because of MacOS’s FreeBSD heritage. They used BSD tools where they could get them and used gnu where they must.

Sure. That's true. But follow the rabbit hole. Why do they have a BSD heritage? Why doesn't BSD use GNU software? It's anti-copyleft all the way down. Long before GPLv3.

Because BSD is older than GNU, and NeXTSTEP was based on BSD.

Running GNU coreutils with a highly BSD kernel is a recipe for sadness. If you don't believe me, try Debian GNU/kFreeBSD.

Like what? I install the GNU coreutils with macports on my work Mac. It seems fine.

Sorry. I forgot coreutils doesn't mean core utilities, like ifconfig and route and netstat and those things.

And as we all know, FreeBSD has enjoyed plenty of Apple contributions upstream.

Without GPL, all commercial UNIXes would be around and Linux would be just another school clone.

"I think the truth is that money wins.. the current state of things was basically inevitable"

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 mean... I get what you're saying, but most of the things you listed as victories over corporate money happened 100 years ago. That says something about the current struggle.

So should we give up because things are currently not going our way?

Not at all. I was merely arguing against the assertion that GPLv3 was a mistake and that things would be different if GNU left it at GPLv2.

I'm an idealist. I do lots of things that are inconvenient and feel like a losing battle.

Meanwhile, there's at least two boxes in my house running Linux that I have absolutely no access to, no chance to upgrade after the manufacturer stops supporting them - on a fast track to e-waste.

Honestly the GPLv3 really isn't that radical. It has three major changes along with a bunch of more minor cleanups and improvements:

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

The "tivoisation clause" also in many cases makes it against the law to use GPLv3 software in some consumer products, or parts of the products. For example much embedded software that comes under radio transmission laws, much software in safety critical applications such as rail, or automotive use, software that have environmental impact at leat in the automotive industry. At leat in the way that automotive legislator reads the laws at the moment.

> And the GPLv3 was simply far too scary for companies.

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.

why isnt the said corporation not using any open source licensed software then? why don't they either built their own proprietary software from the ground up or ask the developer to set up a parallel commercial license for their specific purpose?

Why aren't they building or buying a proprietary software solution instead? Because the open source solution is cheaper, and adds more value to them that the proprietary alternatives. The GPL means that enhancements to Linux generally get contributed back to the core. That has allowed Linux to development faster, have better hardware support, etc., compared to operating systems that have a more permissive licensing scheme, such as BSD, and it's cheaper than a purely proprietary OS where one company has to shoulder the whole cost writing all of the software from scratch.

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.

is there anyone good reference online where i could read a simple, summary of the differences between all of these licenses