To be clear CrateDB started out as OSS and we decide to stay OSS. Elasticsearch used the Apache License and so did CrateDB. All in the spirit of OSS. Elastic are however now the ones how decided, that their business model isn't viable anymore.

> It sounds like they are making up excuses for not wanting to fully Open Source their code

We do want to make it fully open source! Everything that was under a more restrictive License is going to be offered under Apache License.

> We do want to make it fully open source!

This begs the question: isn't "a restrictive OSS licence" not less "fully open source" than a more permissive licence like GPL, MIT or BSD?

If you are fully committed to OSS, why not go full-oss, instead of retaining control through a restrictive OSS licence?

Is that really only because of some enterprises not liking GPL?

We gonna change CrateDB fully to Apache License v2 ;) I would say that counts as a "more permissive" license.

> Is that really only because of some enterprises not liking GPL?

There are various reasons for the change. A big part is definitely also the spirit of many our contributors. We built CrateDB on open source software and also want to make the software available as open source. It also was planned for quite some time to be more open.

The main point of copyleft is to pass down freedoms to use/modify/distribute all the way to the end user.

Instead we got locked-down privacy-breaching smartphones, IoT devices, SaaS, where only the manufacturer benefits from OSS.

• Unix-ish black-box "primitive" tools, that were so focused on accomplishing one fundamental job that they were essentially "final" in their interfaces, with there being no point to extending them any further; where you reused them by executing them, not by integrating with them.

• A library for such Unix-ish black-box tools to use. Most tools that used any libraries at all, would use one main library to accomplish their one primary purpose, effectively making the tool a "driver program" for the library.

• Academic data-science/statistics code.

• Cathedral-style highly-integrated software, e.g. Windows.

Copyleft was mostly devised for the purpose of licensing the codebases of the first two types.

As Unix tools are self-contained, they only "infect" direct forks. The GPL originally intentionally avoided infecting the things that called (i.e. interacted with) those tools — because, back then, a downstream project that "uses" a tool wasn't vendoring in its own version, but rather relying on the system installation of that tool, through that tool's known API; and it wouldn't make sense for a license to be infectious through a standardized API.

It was intentional that libraries would infect their downstream clients with copyleft; but downstream clients, back then, were mostly just those single-purpose tools. It wouldn't make sense for e.g. libgit to be GPL-licensed, but for git(1) to be proprietary.

Of course, there was also an awareness that the Cathedral-style codebases would have their whole monolith infected if they used the GPLed library. The idea there, though, wasn't to actually cause that infection — it was to inhibit Cathedral-style codebases from using GPLed software at all.

(With the parallel awareness that such entities could always reach out to the project maintainers, and buy a separate license, just like you can purchase a license from any IP-holder. There were few-enough contributors per project, back then, that "copyright assignment" and such wasn't a concern; you could just get a proprietary license from the one dude who built the whole thing.)

And that same consideration was implicit with academic use of GPLed software. FOSS programmers, back then, considered academic (or non-profit) integration/derivation of their software to be something they'd grant a free license for if asked; and academics knew this, and so didn't bother to ask for such licenses, because they knew they'd almost assuredly get one, for free, if-and-when it ever became important to do so.

---

The GPL was well-suited to this early-90s software IP ecosystem. It doesn't fit nearly as well in the modern software IP ecosystem.

There's a whole fifth category of software — semi-Cathedral, semi-Bazaar mega-tools, like youtube-dl or Calibre; or mega-libraries, like Qt, or LLVM, or WebKit; which both are components while also consuming many components themselves. The GPL never "expected" this type of software. This kind of software just didn't exist back then; only its entirely-Cathedal final-product equivalent did.

Which is a problem, because it's impossible to build something like WebKit or LLVM in a self-contained, "you call it over a standard interface" sort of way, where it's non-infectious. These days, lot more projects are infectious, even when "integrated" at a much higher level of abstraction, than the GPL was ever intended to require.

LGPL existed since 1991. Also large libraries and frameworks.

Yes, you can create different implementations of that concept, that are variously infectious. But the reason I laid out the whole state of the ecosystem as RMS would have seen it when he was still just conceptualizing copyleft, is that in that ecosystem, "infectiousness" was something that's almost trivial, toothless.

In the ecosystem of the early 90s, licensing a codebase was just a consideration of who you trusted to freely use and modify your thing ("us", hackers); vs. who you wanted to not use your thing, unless they paid you ("them", corporate.) Copyleft neatly prevented "them" from swiping and profiting off of the software created by "us", while not really inhibiting anything that "us hackers" wanted to do with that same software.

Contrast to the ecosystem of today: there's an entire category of people — individuals who start projects as hackers or academics, but then build huge software businesses around them — that didn't even exist back in the 90s.

Google is the epitome of this: at its inception, BackRub (Google Search) was exactly the type of project that copyleft was designed to avoid restricting. But it evolved, through commercialization, patenting, SaaS-ification, and scale, into exactly the type of project that copyleft wants to "shun out of" the FOSS ecosystem. (Not that Google Search integrated any FOSS libraries; just that it could have.)

Google's story, is the story of most software projects today. Every developer is considering their project as a potential "open core" for a SaaS, or considering having an "enterprise version" of their tool, or considering licensing their algorithm as a plugin to some big studio to redistribute. Which is exactly why many programmers avoid integrating copyleft software into even their hobby projects. Why build on GCC when you can build on LLVM, and ensure that there'll be no legal problem

Modern copyleft licenses are ever-more-strained legal contortions to make a design that's no longer very applicable to the modern software IP ecosystem, work for it anyway. They're licenses with epicycles.

Sure, I can in fact link AGPLed and LGPLed system libraries in my language runtime; and in a pinch — if there's no equally-good alternative — I'll take the time, work out the precise legal implications, and go ahead with it.

But if there's a BSD or MIT-licensed (or even Apache-licensed) alternative to those libraries? I'll choose that one. Because, in the modern landscape, by doing so, I'm saving myself, my future self, and my future hypothetical SaaS's future hypothetical lawyers, a lot of time and effort.

I'm surprised at the notion that RMS ever had the intention of inhibiting GPL use in Cathedral-style codebases. And I agree with others that big frameworks existed back then also.

1. literally "frameworks" in the inversion-of-control sense — where your code is a script that runs "inside" the framework — and you don't ship the framework to your customers as part of your product, but rather walk them through getting it from its own vendor as a prerequisite step to installing your product (e.g. TeX); or

2. proprietary, not copyleft-licensed (e.g. game-console SDKs.)

If anyone has a good counter-example, I'm all ears :)

You forget the user.

How does the user benefit from having a phone built on top of open source software, that they cannot update a well known security vulnerability because the manufacturer can't bother to run a build with the last upstream version?

Well, depending on the incentives and restrictions involved, an ecosystem of 3rd-party builds is a potentially viable escape hatch for the user from the manufacturer's grip.

Of course the sticking point is the degree to which the hardware requires proprietary and opaque binary blobs in order to enable important user-facing features. But then, that isn't anything really new, as open source PC operating systems have been dealing with this issue since forever, with the caveat that PC hardware is mostly modular, so having or swapping in well-supported components is an option, whereas smartphones are an integrated slab of metal, plastic, and glass, with "no user serviceable parts inside" as the status quo.

But even that caveat has precedents, in non-PC devices such as consumer networking gear that only became well supported through aggressive GPL license enforcement actions that freed some of the necessary code.

Someone said companies use GPL software, add their business logic or drivers, and never contribute back: e.g. android phones.

Then someone else said the insane thing that the user benefits.

I pointed out that if there is a security flaw, you CANNOT build/path because you do not have all the source (e.g. alternative android OS cannot use the camera or radio for lack of kernel drivers)

https://sfconservancy.org/copyleft-compliance/

Also the SSPL is so vague, that we probably would not only have to release CrateDB itself - which we already do, but also everything we use for the services we provide. Also we could never make any kind of deals with OEMs, etc.

See section and links for "Why not the GNU General Public License?"

It's not GPL for some of the same reasons described here and enterprise does like it.

In short though - was developed at berkeley so released under a BSD license. The license has served them well (there are a lot of commercial entities supporting postgresql development, and lots of others with various forks). And finally, it would be hard to change at this point and they don't see a gain.

A note - in contrast to Elastic, there is no one copyright holder with postgresql. So this makes it much hard to get a relicense to for example a situation where one commercial entity has a special right to the terms / relicensing power.

(please note that GPL doesn't in actuality force anyone to back-contribute but in effect it tends to work that way - it actually puts a lot of responsibility on the original authors to re-acquire improved versions of the library but it does ensure that those improved versions are accessible in some manner)

They are changing the license on ALL of their source code. How is this making up excuses?

Second, I know plenty of companies where MySQL or Wordpress are not allowed to be used because they are GPL.

PostgreSQL is NOT GPL and thus is allowed.

The fact that some companies have incompetent legal teams isn't a good argument against the GPL. There's no reason you can't use Wordpress to back a commercial website.

There are concerns that doing so, in the context of a monorepo, might infect your entire codebase — including the components that have nothing to do with the control-panel, and so never touch the Wordpress stuff — with GPL.

Of course, you can architect code to get around that, e.g. building your shared architecture that the control-panel uses as a library, and then pulling that lib in from your isolated Wordpress control-panel codebase. But enterprises don't want to be forced into (possibly sub-optimal) architectures just because one component legally requires it. They'd rather just not use that component, so that their architecture can be totally determined by what's best for their development.

I realize this is an ideological position (and not necessarily a popular one on this board) but that's the point of the GPL. If certain companies lose out because they're afraid to share, then they have no one to blame but themselves.

The pitch is that the world of free software can, collectively, build better software for everyone sharing, than the proprietary islands who selfishly cut themselves off from that ocean.

At a previous company I worked at legal considered it cheaper to reinvent the wheel if necessary to avoid GPL software than to potentially have to deal with a lawsuit around GPL being used in our software.

Even LGPL software was considered off-limits, because one wrong linker flag and now it's statically linked into the resulting binary...

Then, to get compliance, you just have to fix the linker flag. Providing the source code is not the only way to get compliance.

I think they appear to be surviving just fine - they are switching forks not shuttering their doors or even withdrawing ES compatibility.

Suddenly changing licenses to increase how restrictive it is absolutely is a nightmare scenario to a lot of businesses and it quite rationally is so. We share software and build on each other's shoulders, to reject that and build everything from scratch is silly and fiscally irresponsible.

I'm very confused why this is so strongly stated when it's likely that most of us have, at one point, sat down with two pieces of libraries and gone with the less useful one due to licensing issues.

So, they don't run Linux, don't use glibc? That can't be all that common? (I mean sure, there's the bsds.. But still..).

We do run Linux :)

But there is a difference between building on and building with.

> Which is completely new to me

I work in a consultancy for enterprise-scale customers - every.single.one prohibits the use of GPL libraries and frameworks.

As for MySQL, notice how no one builds anything on top of it (like TimescaleDB and others did with PostgreSQL), but just uses MySQL as-is without modifying it, also rendering copy-left moot.