[berkes]

Thanks for correcting me!

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

[proddata]

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

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.

[eeZah7Ux]

> why not go full-oss, instead of retaining control through a restrictive OSS licence?

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.

[derefr]

Copyleft licensing was invented in an era when most things were written in C, and software fell into roughly four categories:

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

[eeZah7Ux]

The distinction between GPL and LGPL seems completely lost on you.

LGPL existed since 1991. Also large libraries and frameworks.

[derefr]

I'm not talking about the GPL or the LGPL specifically, but rather I'm talking about the thing that was in Stallman's head before either of them existed — the concept of copyleft, of an infectious "Free" license.

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.

[nealmcb2]

Re: > it was to inhibit Cathedral-style codebases from using GPLed software at all.

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.

[derefr]

Sure, big frameworks existed back then, but they were all either

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

[xorcist]

Especially since the term cathedral was popularized by esr to call out the development style of the GNU project.

[eznzt]

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

You forget the user.

[gcblkjaidfj]

i will bite.

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?

[webmaven]

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

[gcblkjaidfj]

You guys are missing the point that some company already cornered the market by using open source code and not contributing back their work. they have a head start from everyone that can ever be involved.

[eznzt]

The user does not care, he throws it away. But the user cares about having a good operating system and good apps and those are built on OSS.

[pabs3]

They can backport the patch for the security fix themselves and rebuild the old version, or band together with other users to do the same.

[gcblkjaidfj]

that would be a full GPL compliant product, which is not what the comment was talking about.

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)

[pabs3]

Your post above doesn't mention GPL compliance, only vendors using ancient versions of open source code. If you don't have the source, of course you can't do anything. So you ask the vendor for source and if they refuse then you contact the Linux kernel community to enforce GPL compliance. At some point the source will come out, even if the vendor has to get sued in order to do it.

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

[eeZah7Ux]

No, I did not forget the user. The user is the victim.