HashiCorp's license change [LWN.net]

Aren't the licensing 'wars' over?

Posted Aug 16, 2023 23:09 UTC (Wed) by faramir (subscriber, #2327) [Link] (14 responses)

But Matt Asay @ Infoworld tells me that the "open source licensing war is over"

https://www.infoworld.com/article/3703768/the-open-source...

so everything is fine, right?

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 1:06 UTC (Thu) by JMB (guest, #74439) [Link] (13 responses)

LWN was always the technical side - not the business side.
Monopoly companies don't like access for free - but they like
personal info for free.
The problem with licenses are, that the authors can change it.
The GPL licensed SW is 'owned by FSF' - that means if the FSF
would consist of business people, they may change GPL licensed
SW to something more 'permissive' - i.e. companies can steal it,
enhance it and enslave users who won't have access any longer.
Similar to programs - if servers/clouds are involved, this right
to use is worth nothing.
So after seeing more and more problems, the war for SW freedom
must ignite again. But currently even scientist are just consumers
without thinking of the outcome.
We will see what happens next - if access to information and data
is a right for everyone in any county or if most people will suddenly
find themselves enslaved.
But if people seems to give alarm by Red Hat no longer giving
others direct source code of their programs ... is a little bit strange.
And most fire comes from those who really steal things and pretend
they are authors and can fix problems ... while they can not!
There is no business without focus on money ... so words from business
(licenses are words, right?) are never trustworthy.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 1:35 UTC (Thu) by irvingleonard (guest, #156786) [Link] (4 responses)

After all that has been written about the Red Hat thing: why do people have an issue with Red Hat's business model?

- You can run Red Hat's code directly from their infrastructure without the licensing nonsense (CentOS Stream) and with up to date security patches and bug squashes.
- You can get the source for such code
- You can even get the exact source that you would be running if you were to be a Red Hat customer (as a RHEL user).

The only thing that was removed was the possibility to have clones of Red Hat (bug for bug clones). You can even get close to that if you were to identify which versions of packages Red Hat released for each OS (and dissect them from CentOS Stream). Why is that business model against the spirit of FOSS?

I understand there are issues with the change, but to be fair, the CentOS 8 debacle should have shown people that there was no future following that path, something that Alma already assumed (and Rocky probably will). If you want a safe set and forget mostly supported by different vendors distro (usual reasons to run RHEL) you should probably pick Debian and stick to it, history suggests that it's the safest bet.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 11:22 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

> - You can even get the exact source that you would be running if you were to be a Red Hat customer (as a RHEL user).

As a Red Hat engineer, I assure you that CentOS Stream will *never* have the sources for many of the updates that get pushed to RHEL. That's just not how the branching model works, and anybody who tells you otherwise is incorrect. Often changes needed for current releases are just not needed for the next release, and therefore they never appear in CentOS Stream.

Aren't the licensing 'wars' over?

Posted Aug 28, 2023 11:51 UTC (Mon) by irvingleonard (guest, #156786) [Link]

Fair, so you would be able to get the "initial" version from CentOS Stream because they move on to the "next thing". It would mean that CentOS would be working on the next version (basically the next minor release of RHEL) while current RHEL is releasing patches for current version. With this in mind, access to patches and bug squashed versions is reserved only to RHEL customers. Does it works like this?

Aren't the licensing 'wars' over?

Posted Aug 18, 2023 0:56 UTC (Fri) by comex (subscriber, #71521) [Link] (1 responses)

The “spirit of FOSS” is subjective. But here are some quotes from the Free Software Definition [1]:

> Freedom to distribute (freedoms 2 and 3) means you are free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere.

> A free program must offer the four freedoms to any would-be user that obtains a copy of the software, who has complied thus far with the conditions of the free license covering the software in any previous distribution of it.

> A program is free software if it gives users adequately all of these freedoms. Otherwise, it is nonfree. While we can distinguish various nonfree distribution schemes in terms of how far they fall short of being free, we consider them all equally unethical.

Whether or not it’s technically a GPL violation, any Red Hat customer who has the code is *in practice* not free to distribute it to “anyone anywhere”. In my opinion that makes Red Hat nonfree software.

[1] https://www.gnu.org/philosophy/free-sw.html#four-freedoms

Aren't the licensing 'wars' over?

Posted Aug 28, 2023 12:07 UTC (Mon) by irvingleonard (guest, #156786) [Link]

This sounds accurate, probably RHEL is technically nonfree, but is it an illegal business model (the usual claim)? You always have the option to use "something else", and leave RHEL deal with whomever want their nonfree thing. Afaik they "solve" the "limited access to source" (only their clients can see it and then they don't get to re-publish it) with upstream patches. Most of the time they're also running ANCIENT software, so the value of such thing is questionable. Their best contributions would be related to their projects (systemd & Co.?) and stuff related to their "next" version (which their clients don't have access to, yet).

The point being that this should be ANOTHER wake up call for all the cloners, to go somewhere else (after the CentOS 8 and the current crisis). There are A LOT of distros with very good stuff and people, if RedHat don't want you around, just let them be, put your money where your mouth is, get a real "free" as in freedom distro instead.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 11:57 UTC (Thu) by eru (subscriber, #2753) [Link]

The GPL licensed SW is 'owned by FSF' - that means if the FSF would consist of business people, they may change GPL licensed SW to something more 'permissive'

No, only GPL-licensed software whose rights have explicitly been assigned to the FSF by the contributors. Lots of software use the GPL license, but the FSF has no control over them. The Linux kernel is one example.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 12:55 UTC (Thu) by e-rk (subscriber, #166547) [Link] (6 responses)

> The GPL licensed SW is 'owned by FSF'
My understanding is that FSF does not 'own' GPL licensed software. A subset of GPL software, namely the projects under GNU, are on the other hand are owned by FSF.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 15:49 UTC (Thu) by danielthompson (subscriber, #97243) [Link] (5 responses)

That is true. The FSF only owns the copyrights for (most but not all of) the GNU project components.

However it should also be noted that developers who use GPL-3.0-or-later (and GPL-2.0-or-later) licensing have granted to the FSF the capability to add another license to software that they do not own the copyrights for. This is certainly a significant power although is much more subtle than the one wielded by HashiCorp (and therefore rather harder to abuse).

Although the foundation can add a new license to existing software by releasing a new version of the GPL they they cannot withdraw the existing license from a GPL-3.0-or-later that they do not own (e.g. the new GPL license doesn't mean a GPL-3.0-or-later project becomes a GPL-4.0-or-later project). Likewise they cannot stop a project reacting to a new GNU GPL license that they do not like by licensing any *future* releases as GPL-3.0-only.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 21:01 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

There's also a whole issue of equitable estoppel. In the part of the GPL that discusses future versions, it says:

The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

The bit about future versions being similar in spirit is vague, but courts in the USA have the power to enforce terms like that under the principle of equity. If the FSF tried to release a new GPL that was substantially different, for example by giving the FSF power over any software released under GPL v 4, a court could rule it didn't count under the new version clause because it wasn't similar in spirit. This isn't an easy or guaranteed thing, but it would limit how large any changes to the license could be.

Aren't the licensing 'wars' over?

Posted Aug 17, 2023 23:15 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

As I understand it, also, part of the deal with you handing over copyright to the FSF was that you got, in return, a promise that the software would always be under a Free licence.

So if the FSF tried to relicence the software under a commercial licence they would open themselves up to a breach of contract lawsuit.

The problem would be if the FSF went bust. I've heard at least one story (on Groklaw) where an American bankruptcy court rewrote a copyright agreement (to the detriment of the copyright holder) before selling it on.

Cheers,
Wol

Aren't the licensing 'wars' over?

Posted Aug 18, 2023 13:15 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (2 responses)

> The problem would be if the FSF went bust.

The FSF would not go bust. A nonprofit can exist based on part time volunteer hours and little to no money. Of course, that would be a very sad day which I hope never happens.

Aren't the licensing 'wars' over?

Posted Aug 18, 2023 19:07 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

It is certainly possible for a charitable organization like the FSF to go bust. The most obvious way this could happen is if they borrowed money they couldn't pay back. Unless they borrowed some really huge amount, they might get bailed out by being taken over by another charity with a similar interest. I could easily imagine FSF getting taken over by someone like Software in the Public Interest or the GNOME Foundation if something like that happened. I don't know the ins and outs, but they might have to be taken over by another charity (a 501(c)3 like SPI or GNOME) rather than some other kind of non-profit (e.g. a 501(c)6 industry consortium like the Linux Foundation).

Aren't the licensing 'wars' over?

Posted Aug 19, 2023 14:17 UTC (Sat) by IanKelling (subscriber, #89418) [Link]

> It is certainly possible for a charitable organization like the FSF to go bust.

In relation to my post, this is typical strawman kind of argument: https://en.wikipedia.org/wiki/Straw_man: "You said X, but in fact it is possible for not X to happen!"

HashiCorp's license change

Posted Aug 17, 2023 8:52 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

As always, check you have working backups for the important things every so often. This goes for more than just the contents of your disks; securing the software supply chain ought to be on everyone's mind after several recent events.

Anyone operating at a scale where this company's products are even relevant really ought to know what a second source is though, so I don't feel all that sorry for them.

HashiCorp's license change

Posted Aug 17, 2023 9:34 UTC (Thu) by nsheed (subscriber, #5151) [Link] (1 responses)

Mmm. Interesting debate ongoing in my org. right now around aspects of this (not tied directly to Hashicorp products). Is portability - in our case the ability to quite literally lift and shift a major national service from one cloud provider to another if there's a future change of wind direction (oh happy days) - the absolute top of the pile (so containerisation basically) or are we a little more pragmatic in saying that over it's lifetime this solution will have many heads and many shafts and still fundamentally be the same broom so we can think different.

Managing the infrastructure that underpins all of that (and it will be a lot) is infrastructure as code and that now opens up all kinds of interesting new avenues - the scripts that we use to provision and manage the underlying resources are tied to a product/likely to some degree closely tied to a cloud provider so they're good as far as they go but as with everything else I doubt they'll last the distance - they're going to suffer from bitrot just as badly (I'm guessing even worse) than $insert_language_of_choice_here.

HashiCorp's license change

Posted Aug 18, 2023 1:45 UTC (Fri) by himi (subscriber, #340) [Link]

Unfortunately, by its very nature "infrastructure as code" tends to lock you into one platform, particularly if that infrastructure goes all the way down to the bare metal (i.e. self-hosted services, rather than someone elses cloud). The cost of switching to a different platform pretty much amounts to rebuilding the whole stack from the ground up - which may not require reinventing everything from scratch, but it isn't just about replicating the architecture on the new platform, it's about porting all the knowledge and hard-won experience over as well. In our environment it's ten years of Puppet development, it could just as easily have been Ansible or any of the other free/open platforms - switching over sometimes looks tempting (from a "grass is greener" perspective), but it doesn't take more than a moment's thought to realise the costs /far/ outweigh the benefits.

Until someone comes up with some kind of standardised architecture for this kind of thing, with multiple different sets of compatible tooling, I don't think there's any alternative to this "pragmatism". It sucks, but it's either that or build you own automation tooling from scratch (which then inevitably grows into the next Puppet/Ansible/Chef/whatever).

HashiCorp's license change

Posted Aug 17, 2023 9:40 UTC (Thu) by smurf (subscriber, #17840) [Link] (3 responses)

In sane jurisdictions, material license changes (IANAL but this one seems to qualify) automatically invalidate your previous consent; clauses that force you to auto-agree to updated versions regardless of the changes are void.

Thus if people consented to the CLA in consideration of the old version of this license, said consent is now invalid and needs to be renewed. If I were a contributor to Hashicorp code I'd notify them of my refusal to do so ASAP.

HashiCorp's license change

Posted Aug 17, 2023 11:28 UTC (Thu) by Funcan (subscriber, #44209) [Link] (2 responses)

The previous version of the license clearly and explicitly allowed Hashicorp to dual-license. Your previous contribution(s) are still available under the old license. There may be an argument for requiring you to sign a new license grant for future contributions, but the past ones are covered

HashiCorp's license change

Posted Aug 17, 2023 18:57 UTC (Thu) by lmb (subscriber, #39048) [Link]

Did it?

> ""to ensure that our projects remain licensed under Free and Open Source licenses""

That's the context in which the CLA was agreed to previously; this is *not* dual-licensing. I think this might be a questionable move, and I wouldn't want to predict which way the legal dice would roll.

HashiCorp's license change

Posted Aug 21, 2023 3:10 UTC (Mon) by roffey (guest, #166590) [Link]

> Your previous contribution(s) are still available under the old license.

What about PRs that were signed under the CLA prior to the announcement but not yet merged? Recent external contributors have effectively handed over copyrights to HashiCorp via the CLA under the impression that they would be available under the MPL plus commercial, but instead they will be released under BSL plus commercial. It could be an edge case, but if it happened to me I would have been pretty cheesed off.

HashiCorp's license change

Posted Aug 17, 2023 11:53 UTC (Thu) by ebee_matteo (subscriber, #165284) [Link] (9 responses)

> When a company is given the right to take somebody else's code proprietary, many of them will eventually make use of that right.

Exactly. This is why I see people licensing their code under the MIT, BSD, etc. as much more idealists/utopists than those who prefer a copyleft license such as the GPL.

HashiCorp's license change

Posted Aug 17, 2023 12:55 UTC (Thu) by e-rk (subscriber, #166547) [Link] (8 responses)

Another friendly reminder to never sign a CLA, unless you have made sure that it doesn't contain clauses allowing re-licensing, or transfers of the copyright, or you got paid for the code you wrote.

HashiCorp's license change

Posted Aug 17, 2023 14:42 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (3 responses)

100% agreed, on all three points. Unfortunately the term 'CLA' covers a wide range of documents with substantially different behaviors (including some that include copyright assignment but are still called 'CLA' and 'CCA').

Some projects have inbound==outbound CLAs, and those are generally fine for nearly everyone. It's all the other (asymmetric) CLAs which cause these problems.

HashiCorp's license change

Posted Aug 17, 2023 18:09 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (2 responses)

You could, in principle, also have a CLA that says something like "the company agrees to only relicense your work under an OSI-approved license, or if OSI is later dissolved, then a license which complies with the Open Source Definition, a copy of which is attached as Appendix A [or wherever]." That's probably fine unless you think some tech company is somehow going to buy out OSI (which IMHO is unlikely).

HashiCorp's license change

Posted Aug 17, 2023 21:07 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I don't know how much help it would be to specify only OSI approved licenses, since that list include permissive licenses. They could relicense your code under the X license and then take that whole product proprietary while still arguing they had kept to the terms of the CLA.

HashiCorp's license change

Posted Aug 18, 2023 13:26 UTC (Fri) by IanKelling (subscriber, #89418) [Link]

I assume that HashiCorp was already selling proprietary versions and that was what the CLA was for. I think the proposed CLA would make an important difference.

HashiCorp's license change

Posted Aug 17, 2023 15:57 UTC (Thu) by kleptog (subscriber, #1183) [Link]

Or the code is something you don't care about. I submitted a 50 line patch for a feature in a project and they asked for a CLA. Fine, whatever, they can have those 50 lines. They could have gotten them BSD licenced as well if they wanted.

As long as it's helping people it's fine for me. If you're talking about more significant contributions you obviously need to pay more attention.

HashiCorp's license change

Posted Aug 18, 2023 21:06 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (2 responses)

Agreed. The few times I was asked to go through a CLA for various projects, it was just to send a bug fix or something like this, and each time I responded with a middle finger, suggesting them to watch their project die a long death instead.

It is really important to warn anyone against CLAs. If nobody signs them, those asking for them will just starve and either stop or disappear, because they're making a living on others' work with the hope to keep the ability to never give back in return. Sometimes they may do this just to look more appealing to future investors as they can claim they own a lot of IP. One more reason for encouraging them to get back on earth and not try to call theirs others' work.

HashiCorp's license change

Posted Aug 18, 2023 21:08 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

In fact I even think we should develop a culture of making fun of those who accepted to sign a CLA. I know it's not fair, but it would spread the word easier and make some doubt when asked to do so.

HashiCorp's license change

Posted Aug 19, 2023 12:46 UTC (Sat) by e-rk (subscriber, #166547) [Link]

I don't think making fun will do any good, because you can't really differentiate between people who made the contribution for free, or were doing it as part of their employment. Also the people you make fun of may just double down as a defense mechanism and dismiss your stance as a conspiracy theory of some sort.

The way it should be approached I think is to make an educative website that explains what CLAs are, the risks they pose, and some practical examples of real CLAs that are evil (copyright transfer, re-licensing, etc.) and examples that are fair along with some more detailed analysis of the terms.

My wishful thinking is that if such website were high quality enough, you could have major repository hosts link to such website in some prominent place when a project you view requires you to sign a CLA to contribute. This would hopefully help educate people before signing.

HashiCorp's license change

Posted Aug 17, 2023 13:24 UTC (Thu) by ejr (subscriber, #51652) [Link]

Well, then, it's back to k3s for me. Blah. I prefer the Hashicorp tools.

Potential legal issue

Posted Aug 17, 2023 17:00 UTC (Thu) by proski (subscriber, #104) [Link] (3 responses)

The old Contributor License Agreement said at the very top:

We require our external contributors to sign a Contributor License Agreement ("CLA") in order to ensure that our projects remain licensed under Free and Open Source licenses

It appears that HashiCorp didn't fulfill their part of the agreement but kept the benefits. I hope lawyers have a closer look.

Potential legal issue

Posted Aug 17, 2023 17:51 UTC (Thu) by smurf (subscriber, #17840) [Link] (2 responses)

> We require our external contributors to sign a Contributor License Agreement ("CLA") in order to ensure that our projects remain licensed under Free and Open Source licenses

That sentence alone is (or rather, was) somewhat suspicious IMHO, because you definitely do not need a CLA to ensure that.

Potential legal issue

Posted Aug 17, 2023 22:18 UTC (Thu) by proski (subscriber, #104) [Link] (1 responses)

It sounds like a promise to me. You assign us the copyright, we keep the code open source.

Potential legal issue

Posted Aug 18, 2023 6:11 UTC (Fri) by timrichardson (subscriber, #72836) [Link]

Most of the sneaky CLAs do not require the contributor to reassign copyright; they grant the receiving entity various indemnities, over patents and claims about actual authorship and the right of the submitter to claim ownership of the contribution, which seem fair enough, and they grant a licence to the code which includes allowing the recipient to distribute the submission under any other licence. So you keep your copyright, upon which open source licences are built, but you have effectively relaxed the power of your copyright to undermine the open source licence. I don't think projects should be allowed to claim to be open source with CLAs like this. I wish GitHub would surface the CLA aspect; it makes the licence highly visible, but it's not the full story.

HashiCorp's license change

Posted Aug 19, 2023 0:19 UTC (Sat) by carlosrodfern (subscriber, #166486) [Link] (5 responses)

If they were that concerned about cloud providers using their code, modifying it privately, and not contributing back to the project everything they change, they should have used something like AGPL as Scylladb is doing.

I think the Software industry has had a aversion to GPL-like licenses for being not very “bussiness-friendly” and many won’t even consider any of them when releasing their code. A lot of the younger generation grew up with that idea and they automatically open their code with MIT, BSD or Apache, without thinking.

I guess they all are coming to the conclusion that GPL-like license had a reason to be.

HashiCorp's license change

Posted Aug 19, 2023 2:12 UTC (Sat) by carlosrodfern (subscriber, #166486) [Link] (2 responses)

Look at Google's aversion to AGPL. https://opensource.google/documentation/reference/using/a...

You can feel their fear as you read it. I bet they have tons of GPL software modified internally, and not released to the community. Makes me want to release everything that it is not a library as AGPL, lol.

HashiCorp's license change

Posted Aug 19, 2023 16:56 UTC (Sat) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Companies like Google could buy a commercial license.

HashiCorp's license change

Posted Aug 19, 2023 20:43 UTC (Sat) by kleptog (subscriber, #1183) [Link]

> Companies like Google could buy a commercial license.

For Hashicorp maybe, but for the vast majority of GPL projects (other other open source projects) there is no entity authorised to even negotiate a commercial licence, let alone be able to collect and distribute any funds received. A CLA is an attempt to make it even possible to do a commercial licence, without that it's not even an option.

HashiCorp's license change

Posted Aug 23, 2023 6:56 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

Some of these companies have switched away from the AGPL. That tells me that they aren't concerned about code contributions, but about money and competition. Principally they are concerned about Amazon running their software as a service on AWS and taking all their customers away. ISTR a talk or blog post about how this is naive because AWS bringing up a SaaSS using some software grows the market for support of that software.

HashiCorp's license change

Posted Aug 23, 2023 9:14 UTC (Wed) by Wol (subscriber, #4433) [Link]

> ISTR a talk or blog post about how this is naive because AWS bringing up a SaaSS using some software grows the market for support of that software.

But surely, if Amazon are providing the SaaS, they're the obvious provider for said support ... to the detriment of the team/company who were doing it before.

Cheers,
Wol

HashiCorp's license change

Posted Aug 19, 2023 15:03 UTC (Sat) by IanKelling (subscriber, #89418) [Link]

The original CLA page actually says this "ensuring" thing twice, and the second time is even worse:

"the CLA ensures that all contributions to our open source projects are licensed under the project's respective open source license, such as MPL2." Even before this change, the main point of the CLA was so Hashicorp could distribute under proprietary licenses. It was always a lie, double speak, weasel words, something like that, but the reality of what they were actually doing was still releasing free software. Now they aren't and they deserve condemnation.

HashiCorp's license change

Posted Aug 21, 2023 12:56 UTC (Mon) by jtaylor (subscriber, #91739) [Link]

For hashicorp's terraform users this may be interesting:
https://opentf.org/

its probably going to end up as a forked under a foundation.

I hope something similar happens for vault.