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.

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.

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

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.

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

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

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

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

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.

https://www.gnu.org/licenses/license-list.html

http://slides.com/adamretter/are-we-still-open-source

Not easy as hard to know what the future will bring, but Apache feels like the right place if we are not GPL.

One usual mechanism for this is to require a CLA on all contributions, with a copyright assignment so you become the owner of the contribution (and probably cope with a lower amount of people willing to contribute, as some consider CLAs as harmful to Open Source). But of course this had to be put in place from the beginning, which I don't know if it was.

Other solutions are to reimplement all parts of which you don't own the copyright, or to ask one by one for copyright assignment from all previous contributors. In this HN thread they talk precisely about this: https://news.ycombinator.com/item?id=24954772

In your case the relicense is to Apache 2 instead of proprietary, but I think the same set of issues apply. I think we'd learn a lot if you could tell us about your case, so there are more examples about the fine detail of relicensing Open Source projects.

The contributors to the server & core, which is more challenging from a getting started perspective (prolog server and Rust triple store), have had fewer active outside contributors. I was looking at these slides (17 - 22 here: https://www.slideshare.net/slidarko/mmadt-a-virtual-machinea...) earlier in the week and remarked on how few devs actually worked on most of the major DB and OSS projects. Tinkerpop is effectively written by 1.5 people! But that largely tallies with our experience. Small number of focused devs keeping a lot of the architecture in their heads while they write the code.

Those that did contribute, and we are eternally grateful to them, were happy to allow their code to be re-licensed. But I wrote to all individually and waited until they had time to think before taking any other steps. If we had been moving to a proprietary license, I think it would have been harder to get sign off, but that is pure speculation!

Well good news for you then: There’s nothing stopping you making all future changes proprietary now that it’s Apache licensed. You can effectively relicense the project however you want now, attribution notwithstanding.

We really don't like the 'traditional' open source economic model - with a community version and all the good features in a proprietary enterprise edition. The community version is almost necessarily weak and you end up annoying your users. We'd prefer to keep as open as possible and have a commercial SaaS or open core model.

Isn't this opposed to this?

> We really don't like the 'traditional' open source economic model - with a community version and all the good features in a proprietary enterprise edition

This is what I thought open core was, am I wrong?

A commercial SaaS model would make a lot of sense for a project that wants to remain completely free software, though. You are the people who know your code best, and it makes sense to trust and pay you to run it reliably.

We want people to build stuff on our database whether they are companies or individuals and we don't want to encumber this with stumbling blocks.

We intend to do this by having a SaaS revenue model which doesn't require we hobble anything in the database in order to make money.

I wish you success!

You might not know anything about how the engine works in your car but it is still important that it is made correctly. The whole Free Software movement targets end users and works on the assumption that these questions are important for them.

Licenses might look like non significant technical details to most end users, but they are not, and many people not in the field are able to understand the subtleties. We should consider people's ignorance inevitable. This is not a fact we can't do anything about. Software is omnipresent in our societies and as massive effects on them. They have the right to know, should care, and actually often do if you don't push them. I know, I tried.

> all the proprietary blobs

Which ones? Nvidia seems to the exception here, and only concerns Nvidia's hardware anyway. If you think of Android drivers, they are in user space libraries (Had the Linux kernel been in a non-copyleft license, they would probably live in kernel space and working out the shitty situation of Android with the kernel would be far more difficult.

Thanks to the Linux kernel being under GPL, Android vendors and manufacturers are forced to release their kernel sources, which allows projects like Lineage OS and other Android derivatives to exist.

> or potentially worsened kernel

I can't imagine why kernel developers would accept a patch that knowingly worsens the kernel upstream.

The GPL forces shitty hardware makers to release their shitty code but nobody is forced to merge it upstream.

bad closed firmware are unfortunate but I don't know what it has to do with Linux being under the GPL.

I think the sibling comment covered most of this well, but I just wanted to add that relying on closed-source drivers is far from necessary with many setups of modern day Linux. All of the drivers on my computer, save for the processor microcode, are open source and for the most part, bug free. In fact, they are probably mostly bug free because they have so many eyes on them.

> Nearly no one cares that most Androids have stoneage Linux kernels, whats important for them is that the Android-Runtime (aka Play-store) can download and execute "Apps".

While many users might not know this is the reason, I think the copyleft license of Linux has let it become where it is currently, as it forces vendors who might otherwise release proprietary blobs addressing issues must instead release the changes with a license such that it can be improved upstream. This pushes companies who spend the energy to fix the bugs in an otherwise good kernel to give those changes back to the community, similar to how the companies took from the community in order to use the kernel.

> > potentially improved kernel

> Or potentially worsened kernel, which now sits in you closed down IoT device, again the license is NOT important for the normal end-user.

Well I think this is a great argument in favor of GPLv3 over GPLv2, which bans this (see [1]). This is another reason why end users could care about the license used in the code. GPLv3 code guarantees the end user the freedom to modify the code and run it on their device (or apply other people's modifications). Though I will concede that this is less of an end-user-centric idea because it requires a decent level of technical competency.

[1]: https://en.wikipedia.org/wiki/Tivoization

https://www.mongodb.com/licensing/server-side-public-license

Mongo license would be a permissioned license however

Especially relevant to GPL, it ends up being counterproductive, as the license is a hardcore protection of the users' rights, at the expense of the project owner's rights. See the debate caused by Octotree [1], [2].

It's a pity because the way I see it, GPL is the ideal way to go. But if you need to pay the bills with software you write, it is also one of the worst open source choices out there.

(A)GPL is then relegated to either 100% vocational non-commercial code that one writes as a side project, or to big entities that for some reason write GPL code that is not part of their main business.

[0]: http://slides.com/adamretter/are-we-still-open-source

[1]: https://news.ycombinator.com/item?id=24953821

[2]: https://github.com/christianbundy/octotree/issues/1

Congratulations to all the teams getting co-opted by Amazon and becoming just another Docker Enterprise.

Everyone should go GPL. The time to do it was yesterday. The next best time is now.

Make money with licenses so you can actually have a business. Unless you just like funding billion dollar companies for free. (They don't even have to contribute code back!)

Open source without fangs is free, stolen labor that gets turned against us.

AGPL solves the AWS and MongoDB problem.

Absolutely the commercial license business model is driven by that threat of "nuclear" retaliation. But that doesn't necessarily make that business model correct. (In some ways it seems rather skeevy, negotiating with someone that has an untested "nuclear device" and is threatening to use it.)

Also, just because it is untested doesn't make it any less of a nuclear device. Einstein and Bohr and a few other mathematicians had a very good idea of what a nuclear bomb could do before one was ever built or tested. We can make, based on the (poor) wording of the AGPL, some pretty good assumptions about how badly it could be used in a court of law should someone actually try to call in their threatened strike. (Everyone is too afraid to let that happen, but should it happen, it may be devastating, and worse no one knows in which direction: if the AGPL will prove to be so virulent as to be toxic or if the AGPL will open questions about enforce-ability of copyleft clauses in what are ostensibly presented as copyright licenses that risk even the GPLv2 falling to a dangerous counter-precedent. Either way, a source for great damage to the software industry should the AGPL ever go to court.)

I don’t think it would hurt to have AWS release some of their software, like the Nitro hypervisor. The world would probably benefit from that more than any license they’d have to pay.

The AGPL to do its work has to close the "mere aggregation" "hole" in at least some cases, which alone makes it "more viral" on the spectrum of GPL licenses. That's before you get into problems with how the APGL defines "some cases", in that it doesn't do a great job so no one knows exactly how viral it is because it will take court cases to sort out its bad wording on the subject.

(For instances: 1) The AGPL is intended to expand to include "running it in a SaaS environment" yet the way it (doesn't) define "SaaS environment" is so poor it could mean running it anywhere. 2) The AGPL was written by a PHP company and so a lot of the definitions, distinctions, and clauses from the GPL regarding the differences between binary and source distributions were struck out. Because most of the known legal definitions on "mere aggregation" with regards to the GPL hinge on those distinctions we have fewer and fewer ideas of what "mere aggregation" means with respect to the AGPL, and it again possibly implies that the AGPL's virality is potentially unbounded, that their "some cases" is intentionally or accidentally written as "all cases".)

AGPL doesn't solve the AWS problem, which is that Amazon will take the project your open source company wrote and soak up all the money to be had offering that project as a service and they will do a better job of it, while still complying with the license.

A related problem is that Amazon have enough engineers they can just look at your proprietary or source available project and just clone your programming interfaces on top of a new project (and if you are unlucky, open source that, killing your market entirely).

For example, while I don't mind the GPL, I prefer to use more permissive licenses for my own code, because that's what's more in line with my personal ethics. I'm just not a "strings attached" kind of person. There is a courage criticism to make of how I do things, but it works in the opposite of the direction you're trying to take things: I sometimes wish I had the guts to follow SQLite's lead on software licensing.

Where?

> This kind of comment does little to advance the discussion.

What are you talking about? Wider GPL adoption is central to the discussion!

Companies are taking permissively licensed work, making billions, not contributing back, and building massive platforms we'll all be forced to build upon.

AWS and the like are a step forward in terms of not needing to image and upgrade machines, but it's ten steps back in terms of computing freedom.

The future of computing is closed and they're using open source to corral us in.

Sure. And so the question is, did the GPLv3 improve or degrade adoption of copyleft licensing?

To quote from Star Wars, "The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."

Like it or not, companies fund the vast majority of open source software development, not hobbists, and when the FSF tried to "tighten its grip" by making a license which moved the balance of benefits more towards free software users, and away from the companies which funded the work, things didn't go well for them. And so what the FSF has found is that the the goals of the free software manifesto has been, more and more, slipping through its fingers.

Unless you can make non-free software illegal across all countries, at the end of the day, you need to find a balance where all stakeholders are comfortable with the result so that users, developers, and company freely and happily choose to use free software. This is a negotiation, and if there is more value that can be gained by signing onto the free software ecosystem, then perhaps the balance can be shifted a bit more towards the free software goals. But until you can, given that most open source developers do like food with their meals, a successful open source strategist has to be grounded in the economic and business realities. Just raising your right hand in a fist and shouting, "power to the people" and "freedom" is generally not going to get you very far.

I don't think GPL3 really affected adoption of copyleft licensing. Permissive licenses were gaining already.[1]

[1] https://redmonk.com/dberkholz/2013/04/02/quantifying-the-shi...

Post 2005 is when cloud computing & the web as an app platform began to gain traction, and a lot of open source software from ‘big tech’ is either cloud or web related.

The adoption of more permissive licenses is just because the big players favour those licences.

This argument does little to advance the discussion either.

Some projects take a weekend to build. Others are the result of years of blood, sweat and tears.

The latter is probably where you're going to want to have a little more control over how the fruits of your labor are used and maybe get yourself paid a bit more than $0.

I am OK with people using whatever license they want for software they write. But if you think GPL 3 is ideal, by using something else you are just killing your ideal.

Why? These users overall aren't even willing to pay token money to support the creator so why should the creator care about them more than their own goals and desires?

20 years ago GPL was the only thing most users new to OSS knew about. Since then they have learned there are better choices Meanwhile GPLv3 was the final nail in the coffin of the bossy OSS licenses.

One thing I don't get is why the OP proclaims love for GPLv3. It's the worst GPL license out there. I avoid it as both a contributor and user.

If you are running GNU/Linux and not Solaris, it is because of the network effects of the GPL.

Apparently most anti-GPL folks don't have an issue going back to those days.

Corporations can use GPLv3 in their codebases, they r just not bothered following the lawyer approvals so that code is shared back. If you cared about that, perhaps a better option is dual licensing.

I hope that the project does not become...yet another free labour camp by developers for big tech money bags.

a) You need to have absolute 100% of the code ownership/copyright in order to change the project license. This is not true and there have been precedents where a valid and successful relicense was done with much less (if I remember correctly I learnt this from a comment somewhere hidden in that same Github issue)

b) The other project contributors would not necessarily agree with the relicense. Which was not the case: the most prominent contributors showed up and explicitly gave the author ownership (or free license) over their small parts of the code.

I suppose you could have somebody quite ideologically attached to the GNU/GPL who could then hold up a change. If the code was core and you couldn't easily re-implement, could make the price high.

At the time, the failure modes of the more permissive licensing model (for example, of NetApp's innovations for things like WAFL were never contributed back to BSD) were more foremost in our mind, and so for us the GPLv2 was the right compromise between the rights of the community and the companies using, and improving, the code. Of course, the decision that we made in 1992 was in a world very different from 2020, and so hopefully the choice of the Apache license will be the best one for TerminusDB. I have only the best wishes for you and your community!

From a business's perspective, there are can absolutely be legitimate concerns to taking certain kinds of dependencies on GPL software. But the ones that seem most legitimate to me concern core library dependencies. I have a really hard time seeing how one would be comfortable, as so many businesses are, with building their entire tech stack on top of OpenJDK, but then balk at a database server that isn't even running in the same process space as the rest of your code.

Is there any legal grounding there, or is it just that we're all comfortable with Java, whereas a new database is a new thing, and we're naturally more fearful about new things?

I think they came up with GPL + classpath exception instead of adopting LGPL because LGPL has all this language about static vs. dynamic linking etc. that is rooted in the C world and not how Java does things.

I just wish more devs had the courage to just stop capitulating to fear of a few different types.

That said, Apache 2.0 is one of the licenses I usually consider as acceptable (as opposed to mit and bsd).

This. I've heard that licensing my code under the AGPLv3 will prevent its widespread use by industry, and my answer to that is, good! I licensed the code under the AGPLv3 because I intend for it to be used under the terms of the AGPLv3. If that puts companies off because they want to use it for free, but don't want to use it under those terms, then my licensing requirements are working as intended.

If you want to pay me, that's a different story, and I leave the door open for commercial licensing.

Interesting. What do you not like about the latter two? I tend to think of the three as equivalent.

I found this website on stackexchange that is good for comparing: https://tldrlegal.com/

It's not fear: it's Apache-/MIT-/BSD-license-as-marketing. It' no longer enough to have a project that solves a specific problem - you now have to build "mindshare" and a "community" and have the metrics to show VC's so they can fund your growth, and corporate acceptability is key here. The playbook of a successful open source project is:

1. Use the most liberal license you can think & grow a community

2. Become popular, gain traction in enterprise market & get millions in funding

3. AWS forks your project, tells customers they can scale it better than you

4. Investors call you and demand you do something - competing with Amazon wrecks all their projections on your future revenue. You add anti-cloud-hosting clauses to your license - building a community is no longer a concern the way Amazon is.

TerminusDB were on step 0 (no thanks to the GPL), now they are on step 1.

Maybe if MySQL, its offshoot MariaDB, and our graph brothers Neo4j weren’t the only GPL flag flyers in the top 20 databases, it might be easier to gain adoption with GPL

That compounded with the following trite slogan actually detracts from what should have just been a simple announcement instead of extended squirming: code freedom is being overtaken by developer freedom

Reading the license text[0], the prominent section related to remote network interaction very clearly notes "if you modify the Program", and the terms and conditions lay out that "Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying".

When people discuss not being able to offer AGPL-licensed programs as a service, are they exclusively talking about modifications?

Another point is the requirement to only provide source to your users, who might be bound by something else, like an EULA that prohibits them from using the AGPL software you give to them to run a competing service, for example.

I guess until this stuff gets tested in a court of law, everyone is reacting to the threat of litigation more than actual litigation but it feels like the threat to companies is overblown, except if they try to improve the software and not contribute back.

[0]: https://www.gnu.org/licenses/agpl-3.0.en.html

At least in my limited experience with extremely large companies (which are the companies that would be capable/interested in reselling these services) they rarely run open source software exactly as is, even for their internal usage. They usually patch it themselves or contract out patches either to fit within their systems, or for specific features the want/need.

For example, MongoDB used to be AGPL and there where some companies dedicated to provide hosted services for it. Specifically MongoHQ (later renamed to Compose) and MongoLabs (later renamed to mLabs). I believe neither of these companies had any specific contract with MongoDB, nor where they breaching the AGPL in any way.

However, MongoDB eventually changed it's license in a way that explicitly made it impossible for these services to continue to exist without making their entire stack open source, or getting a separate license agreement with them. In this particular example, the impact may have been minor for these two companies, as Compose got acquired by IBM before this, and mLabs got acquired by MongoDB themselves. But any other product that effectively ran hosted MongoDB for you would need to get a license from MongoDB. It is speculated (fairly) that these changes were made so that MongoDB could get a greater market share with their own hosted that they sell, and to block out much bigger cloud providers from finding ways to wrap their services in non license breaking ways, but still not providing much more extra value add other than hosted Mongo.

I ultimately chose the GPL v3 license, so that if anyone wanted to use my code commercially in a proprietary product, they would have to consult with me to work out a suitable arrangement (like dual licensing and granting them the right to use the code with a more permissive license - this would be easy in this case, as I was the sole developer with all rights). This was not done with any monetary consideration in mind but as a young developer I just wanted to be made aware when someone wanted to use my code commercially, to mention the same in my resume.

The second reason was that GPL v3 better protects the ideal of open source that I subscribe to - the USER should have access to the source code and be able to modify and use it for their own purposes. Other more permissive open source license don't protect this right.

This is where AGPL comes in too.

With "cloud computing" and "software as a service" becoming popular, many tech corporates that had avoided GPL softwares, now started using the software on servers and offering it as an online hosted service. GPL requires you to share the source code, along with any modifications, when someone asks for it, when you distribute a software using GPL code. But with online hosted services, corporates claimed that since they weren't distributing the software and the user was not running it on his computer, they didn't need to share the source code or any modification made to it with anyone.

AGPL was created to prevent this and further protect the USERS right, as it forced anyone who chose to use AGPL software and offer it as a service, to share their source code.

I still believe GPL / AGPL is the BEST open-source license. All developers are also USERS of their application. Thus, GPL's focus to protect the USERS right at all cost, works to protect your rights as a developer too as your source code, in any form, will always be open and available.

For commercial open source projects, dual license (partially or fully closed + GPL) is the way to go. MySQL / MariaDB is a good example.

I'm also wondering if it's even worth bothering with this at all and whether companies should just open source the orchestration software/shim layer. Open sourcing the shim/adapter you use to orchestrate running the unmodified software doesn't even seem to be an issue, because usually what's stopping competitors is not simply development difficulty. Then the question becomes how far past the orchestration does the virality go -- I think it's pretty hard to make a case that your customer frontend (which is where the money gets made) that calls out to the orchestration software (maybe it doesn't even, maybe it just puts a message on a queue) is now a work derived from the Program.

Here's a more concrete example. If I want to run a hosted mongo service, I can take mongodb's own k8s operator[0] and build using that. For this to be damaging to the business, the virality of AGPL would have to extend all the way to whatever software I use to check out customers, but even that seems like it would be fine if that software was open source too (imagine some self-hostable saas project that takes your stripe key as an ENV variable).

Here's another thing worth considering -- who is going to sue companies that violate? Some random group of developers? The EFF/FSF + a developer? when are they going to sue you? By the time that you're a giant company off of the software, even if a competitor got the complete source code to one, two or all services that run on your platform, could they really replicate it? Wouldn't they still have to get that source from a customer (user) that requested the source?

It seems that if you really want to stop this from happening, something like the Business Source License[1] (or some equivalent license) or bust.

Aside from all this, it really feels like AGPL is the best license for all software -- it really hits the "don't use this if you will improve it but not contribute back" intention perfectly -- if you make your derived work public (such that your modified version becomes the unmodified version) it seems like there are little to no issues running a business on it.

[0]: https://github.com/mongodb/mongodb-kubernetes-operator

[1]: https://mariadb.com/bsl11

They want to have the option to, when they see a market opportunity, slap a logo and one tiny feature on top, and a price tag!

If there was a single, one, any tiny reason to not use GPL, nobody would be using linux.

Not using GPLv3 is sabotaging open source. People who stand with corporations and dislike GPLv3, are the same people that stood with microsoft in the 90s and disliked GPLv2. There's no way to please that people. Let them go. You do not need them.

As such everything I do outside work, is dual licensed, don't want to pay me? GPL

Want to earn money with my work? Lets talk about a commercial license that makes sense to both parties.

I was there in the shareware/public domain days, and this is where everything is going back to with these decisions of moving away from the GPL.

The major uptake of BSD UNIX clones across the industry shows how it would have worked out without Linux and GNU being GPL, basically HP-UX, Solaris, Aix, Irix would still dominate the server room.

You say that because there was BSD, apple could have OSX and not license Solaris or what not.

I say that without BSD licenses, Apple would have OSX with proper open source and up to date releases. Heck they did that with the kernel and most of the distro for a while.

No word about Apple, where did you got it from?

If you get more nefarious with it, what if they started building tooling around it -- like a proxy that rewrote requests to fix a bug, or a file system that sat underneath the program that solved some issue with IO?

I also think that the majority of value delivered by something like RDS is not actually proprietary changes, it's just the underlying software being kinda good (because it was developed in the open, and the F/OSS community was leveraged as bug finders and fixers) -- I'm thinking mostly of Postgres. Even things like HA and scalability are often considered in projects these days, so you wouldn't even need to add much to check off the usual enterprise-y boxes.

They seem to really believe the GPL better reflects their views, but feel coerced by corporations and by what they see as widespread misconceptions into dishing it.

They cite the GNU manifesto, they even seem to encourage a GPL fork, almost as if they wanted this to happen.

> We would welcome a GPL fork of the TerminusDB code – we are happy to work with any such project should it emerge.

If you have ideals and it saddens you that someone seems forced to compromise theirs: stay strong! Your ideals are important, fight for them. You may have to make compromises but do not let it hinder them.

It's copyleft, but not viral like the GPL is. It is GPL compatible but can also link to (and be linked by) proprietary code. It is file-based, so the rule is that if you modify one of the original project files, it has to be provided under MPLv2 - but extensions to the original library in separate files are permissible.

It also provides a lot of the same protections that Apache 2.0 provides in comparison to MIT/BSD licenses.

Interesting. This seems to be the licensing equivalent of "Piracy is Progressive Taxation", which is an angle on software licensing I hadn't considered before (and it should have, since these are copyright licenses, and similar popularity-based dynamics regarding violation of norms ought not to be surprising):

https://www.oreilly.com/content/piracy-is-progressive-taxati...

IMO the substantive points of practical difference are vastly important: the obligations of GPLv3 vs Apache 2.0 are not the same...

The whole document is a side-discussion never addressing the changes in obligations. It's about the supposed predominance of license-signaling over what is actually written and wanted by licenses. It even randomly talks about AGPL at one point, without any specific reason for doing that, except somehow qualifying it as a "pariah" license, maybe in an attempt to associate the GPL a little with that derogative qualification.

This reads as if they do not actually give a fuck about the actual effects of the various license but only about second order effects caused by some mainly folklore signaling. The first sentence of "Why Shift Licenses" could even be taken directly as an argument for not doing it. I find the whole thing extremely sad.

One could of course feel that the difference in obligations are more important, but those who believe this are also free to fork the project and demonstrate just how easy survival would be trying to ignore the consequences of the perceptions.

It's clearly possible for some GPL projects to keep forging ahead despite the difficulties, but survival rates paint a picture that isn't so kind.

I didn't see that mentioned in the announcement, so TBD.

However, since the code was GPLed, it's still GPLed at the commit prior to the licence change. One could theoretically fork at that commit.

These decisions are difficult... but the big issue is about having any traction once there are decent liberally-licensed competition.

It's not an issue of copyleft.

Note, IANAL. I've just talked with several about licenses.

The GPL2 linux kernel may be treated as an exception and allowed, but it doesn't mean GPL2 anything else won't be treated like leprosy.

[0] https://en.wikipedia.org/wiki/Tivoization#GNU_GPLv3

If they never intended to contribute then nothing is lost. It’s not a popularity contest.

[0]: https://github.com/cla-assistant/cla-assistant

Moving to LGPL doesn't improve anything with regards to the non-problem of using the GPL for this purpose in the first place.

The problem lies outside of the technical/theoretical legal entitlements.

That's not the _problem_ with the GPL, that's the _point_!

The introductory paragraph (preamble) is, and personally I would indeed strip it from the COPYING or LICENSE.txt file and just start at "0. This License applies" whenever using the GPL2.

>Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

From wiki though:

>According to the GPL FAQ, anyone can make a new license using a modified version of the GPL as long as they use a different name for the license, do not mention "GNU", and remove the preamble, though the preamble can be used in a modified license if permission to use it is obtained from the Free Software Foundation (FSF).[60]