Thanks for sharing this thought, it hadn't occured to me that this could be an issue. Would the choice of AGPL or MPL for a licence have satisfied your concerns?

As a person who shares OPs concerns, (A)GPL is acceltable, in v2 or v3 form. Anything permissive is not, because allows a closed fork, which everybody wants to do to rob free software ecosystem to undo what has been done over these years.

Because "monies".

Personally I haven’t seen this motive across any of the organizations I’ve worked at. They usually seem more interested in minimizing maintenance costs, which means they try to upstream changes where possible or practical.

What would motivate a company to fork and keep private changes to a core GNU utility like chmod?

Any hardware company which would want to block 3rd party firmware from loading or executing on their systems. They can add a small handshake code to every binary on that system to authenticate via TPM or the processor's embedded secure element on start.

They don't need to make extensive changes. Pull the latest, patch, compile, burn to FW. TaDa!

IOW, TiVoization 2.0. GPL2 makes it very hard already, but GPL3 makes it impossible.

With permissive licenses, it's very possible.

ref: https://en.wikipedia.org/wiki/Tivoization

> What would motivate a company to fork and keep private changes to a core GNU utility like chmod?

Maybe ask these folks: https://www.busybox.net/license.html

https://en.wikipedia.org/wiki/BusyBox

While I don't share OP's concern, I believe AGPL is much more preferable, yes.

Having both available means that someone can use it under the MIT license to produce a proprietary version.

For me the most important thing is the rights of the end user. So I consider the AGPL the best of all licenses I am aware of. And hey, if Google bans AGPL software then it must be doing something right.

It would depend on what the end goal of the rewritten project is. If they pursue widespread adoption GPL licenses can definitely hinder it in many cases.

AGPL? I can understand. Pure GPL 2 or even GPL 3? Never heard of that.

You've never heard that GPL can hinder adoption? Most codebases simply cannot use GPL code because if they do, they'd be forced to relicense under GPL (obviously). Not everyone wants to do that, even setting companies aside.

Even people who nominally agree with the concept of Free Software might not want to be forced to use GPL. The freedom to choose how to license one's work is also an important freedom, after all. GPL can be confusing, so you can't fault anyone from not wanting to use it even if they agree with the spirit of the license.

(For the record, I use GPL on some of my projects. I don't hate it, but I also like to use MIT on some projects, too.)

Libraries are normally released under LGPL, which allows the use inside your differently licensed code.

A ton of commercial services and products somehow use Linux, the poster child of GPL2, while also running tons of their proprietary code. Python is GPL, and it's all over the place in the computing world.

If you just want to take some code someone else wrote, for free, and alter and meld it into your commercial product, well, yes, GPL does not allow that. I don't think it's a huge impediment for legitimate use.

I'd say that all open-source approaches have their own use cases. Certain things are easier to release under BSD / MIT license, some makes sense to release under GPL, some have to resort to AGPL, to the detriment of commercial adoption. A dual restrictive open-source + paid commercial license can be the best in many cases.

Yup, and one doesn't need to look further than FreeBSD to see what the end result is.

I wonder, to what extent is the Linux Rust effort "generously subsidized" by corporations?

> He is thinking about ""what we are going to leave to the next generation"". Developers starting out don't want to use COBOL, Fortran, or C, he said. They want to work with fancy stuff like Rust, Swift, Go, or Kotlin.

Oh, think about the children! The wolf in sheep's clothing.

What does Rust have to do with it? You can write MIT or GPL licensed code in any language.

It's not the language selection, but the license selection what bothers many.

> I wonder, to what extent is the Linux Rust effort "generously subsidized" by corporations?

I would hazard that extent is strictly less than Linux itself.

I did not see these posts before I posted similar. I fully believe this is a direction Corporations are pushing.

Almost wonder when spyware will be added and restrictive DRM.

This is FUD. The folks funding this generally believe in the benefits. Not everything is 4D chess. There are plenty of not more of examples of rewrites where licenses do not change.

If that's no 4D chess, and if the license is not that important, why not relicense uutils to GPLv3 then?

I don't mind GPL, but if I were to start a new project it would be MIT licensed. There is no hidden agenda in my decision to do that and it's certainly not some grand scheme by my employer to make me do that. I simply find gpl less free because it has obligations attached to it. I don't think I'm alone in feeling this way. In fact I think this may very well be the way the majority of folks feel at this point.

Corporations have been attacking the GPL for decades. Your employer would likely not allow you to license something with the GPL even if you wanted to. Many employer's employee handbook comes with specific clauses against not using, let alone contributing to, GPL software. So your take on the corporate part is rather disingenuous and ignores much of recent history.

Yes, some people do believe liberal licenses are free-er. Corporations certainly like the freedom to not contribute back.

> Corporations have been attacking the GPL for decades... So your take on the corporate part is rather disingenuous and ignores much of recent history.

Corporations do not like the GPL on its merits, but it's also worth remembering that the GPL is also not that popular compared to MIT among developers. Developers have not been choosing the GPL for new projects.

See: https://github.blog/open-source/open-source-license-usage-on...

Isn't it likely that newer projects licensing under GPL are also unlikely to be using GitHub and instead be using a platform like GitLab or Forgejo (or previously Gitea or something)?

> Isn't it likely that newer projects licensing under GPL are also unlikely to be using GitHub and instead be using a platform like GitLab or Forgejo (or previously Gitea or something)?

Why?

But let's assume you're correct. What better metric do we have about which license OSS projects are using?

Because the kind of people who use the GPL do not entirely appreciate Microsoft profiting from all code hosted on Github without respecting the original licence. And before you reply; yes, there is litigation ongoing on that front.

And who cares about those ad-hoc metrics? GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL. That alone is a good metric. Blender and OBS are also heavy hitters. It is easy to take these things for granted, and anyone seeking to rewrite GPL software under a liberal licence (whether it is in Rust is irrelevant) would benefit from reading a little history.

> GNU/Linux is the most successful free software project in the world and that is in part thanks to the GPL.

I don't disagree, but you're missing the point which is -- the reason why the GPL is not popular is not only because corporations disfavor it, it's because devs disfavor it too. You might ask yourself, "Why?"

> Blender and OBS are also heavy hitters.

And so is Firefox which is MPL2, etc. If your point is -- OSS can't be successful (or successful and copyleft) without the GPL, then you're obviously wrong.

> It is easy to take these things for granted, and anyone seeking to rewrite GPL software under a liberal licence (whether it is in Rust is irrelevant) would benefit from reading a little history.

Is this meant to be maximally patronizing? I am old enough and I was there. It is also fair to see the world differently than you do, and to appreciate different things (as others do and will do.) Some may say, "More than 25 years have passed since the Halloween documents and I am no longer on a jihad."

What I am saying is not that the GPL is not good, only that the GPL isn't the highest good, and more important than the GPL (or the MIT license for that matter) is my freedom to reimplement any software in whatever language and under whatever license I choose.

Your points are valid and the comparisons between liberal and copyleft licenses have been discussed a million times. But scroll up to the original context here: what's the advantage of rewriting large swathes of critical OS infra that already works fine?

> what's the advantage of rewriting large swathes of critical OS infra that already works fine?

If you don't get it, then, it's not for you.

The reality -- I think this is an instance of who knew uutils would be this popular. The project became a way for new Rust devs to get their first Github commit.

What’s the problem with FreeBSD?

It’s been my daily driver for 20 years. That it has an open license is a good thing.

That it's irrelevant outside of the server space and has terrible hardware support. FreeBSD folks themselves use Macs.

Don't get me wrong, I very much like FreeBSD, but I believe a liberal licence on critical infrastructure like an OS is detrimental. Of course, FreeBSD folks will argue the opposite.

+1 also, it is much less interesting if this is not sent upstream (even if upstream is not interested at this point)

Perhaps, but MIT licensed code is Free like Air and Sunshine.

...and can be closed anytime, if the author wants to.

Which will happen with these tools, anyway.

What is released under MIT (or BSD) will stay under that license forever, so it cannot "be closed anytime". The owner can change the license, but that will affect only future developments.

Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made.

IOW, this is de-facto closed source distribution.

What happens when a company decides to add their own secret sauce and release that version only, or what happens tons of slightly incompatible, closed source variants pop-up, what happens upstream decides to not release future versions' source code.

We have seen it all, and we'll see all of them again.

Yes, obviously the license can change by the author. The same can be done with GPL software.

But what has once been licensed under a permissive license, will remain free forever.

Only the changes will be affected.

> Permissive licenses sometimes allow sublicensing, which allows changing of the license

No! Sublicensing simply means that there can be a chain of licensing, e.g. author —— Linux distribution —— end user. Not that the middleman can change the license.

(It's actually irrelevant in Germany, because consensus in our legal community seems to be that there is a direct licensing relationship between author and end user, even if they don't know each other and never interact)

> Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made.

If I own the code, I can redistribute that code under a non-GPL license any time I want to (or not release changes at all). The GPL license that I grant to you on my code only affects what YOU can do with it. Consider the common practice of dual-licensed GPL code (a very common strategy for FOSS libraries to extort license fees).

And yes, an MIT license permits sub-licensing. Which is a good thing. (So does GPL). Maybe that word doesn't mean what you think it means. Perhaps you meant re-licensing.

> What happens when a company decides to add their own secret sauce

Then you use the old code without the secret sauce.

> what happens tons of slightly incompatible, closed source variants pop-up,

The same thing that happens when tons of slightly incompatible GPL-licensed variants pop up.

> What happens when upstream decides not to release future version's source code.

GPL does't help with that either.

> We have seen it all

To be perfectly honest, coming to Linux world, I find the various creative strategies to extort license fees for GPL code to be extremely distasteful. Off the top of my head: Juce: three dozen dual-GPL- and GPL-incompatible (not-for commercial use without paid license) libraries and tools with no upfront documentation on which libraries and tools are distributed under which license. You have to download them one by one to find out which license they are distributed under. Ubuntu: withholds (currently) 21 security fixes unless you pay for a license! Reaper, which is GPL-licensed, but demands that you purchase a license when you run it; sources are available but are impossible to build. GPL libraries that require use of non-GPL services in the cloud. Seems much more like a dystopia to me.

All I want is for people to be able to use my code. For whatever. And I am grateful to those who have provide code that I use under equally generous terms. And not at all impressed by somebody who added four hundred lines of code to a huge MIT-licensed library, and licensed them under a GPL license. (It took me less time to rewrite from scratch than I spent trying to get a fix pulled into the GPL project).

> that will affect only future developments.

There's a term for that: Embrace-Extend-Extinguish

Also known as Embrace, Extend and Innovate. Which would be a good thing.

You say that like big tech doesn't use these tools when they are gpl. The primary advantage here is big tech employees can safely read and contribute to these tools without fear of upsetting some internal lawyers or getting explicit permission. No one is arbitrarily forking, extending, and keeping that new source hidden despite placing it in some commercial product. Working upstream is far less costly for long term maintenance and everyone knows that. Sure there are exceptions but far from the common case

> The primary advantage here is big tech employees can safely [...] contribute to these tools without fear of upsetting some internal lawyers

Doesn't GPL do that better by mandating that changes must be accessible to the public? Like, if an employee worked out some patch, it would be a violation of the license to not make it accessible to the public.

No, because the fear of possibly not complying is enough to stop folks from even getting near it. I would argue that's worse for the ecosystem.

I would have said this in the past, but at this point I don't think it matters that much anymore.

1. Code copyright has devalued a lot in general, as you can code significantly faster with LLMs and use them to launder GPL'd code into whatever you want.

2. Big tech seems to be getting away with most other forms of abuses these days, GPL wouldn't really stop them from doing anything important.

To the extent that code is being devalued, I would say that these LLMs are a benefit to open source overall, as devaluing of code also reduces the opportunity cost of open sourcing software. They also somewhat level the playing field between single-contributor open source projects and companies with teams of developers, because an individual is almost always limited by the rate at which he/she can write or architecture code, whereas teams have significant non-code overheads (meetings, reviews, bureaucracy).

> 1. Code copyright has devalued a lot in general, as you can code significantly faster with LLMs and use them to launder GPL'd code into whatever you want.

I see no real evidence this is the case. Can you provide examples?

For instance -- do you see many Linux clones right now? Ask yourself: why might you not? Perhaps it's because it's almost impossible for an AI to rewrite Linux.

It is specifically with these smaller projects, not something like Linux or Chromium, that AI can accelerate. In particular, companies would probably not bother using an (A)GPL'd library, and would instead recreate them from scratch with help from AI. I don't have specific evidence for this, though.

What small A/GPL projects are we talking about?

The problem with your argument is that the GPL has not only provided the corporate world with free labor, but with a licensing model that big corporations now like for their own stuff, because it lets them license the code to other parties while retaining important advantages over those parties.

GNU and Linux are the engine that powers practically every form of online harm.

The best licenses are BSD and MIT and others of that sort; they have no naive pretense of not helping corporations: everyone can do almost whatever they want, be they a large business or an individual. These licenses also don't encourage unlevel playing fields where the copyright proprietor enjoys dominance in the ecosystem.

For instance, if you are licensee under the BSD2, the only thing you cannot do, in comparison with the copyright holder, is remove copyright notices from the documentation or other materials accompanying the compiled code. This is really a minor thing which only stands in the way of those who want to be outright plagiarists.

With the GPL, it's extremely important to be the copyright holder, so that you can litigate. That's why the Free Software Foundation and GNU Project require copyright assignment for all non-trivial contributions to every project. If your program is a patchwork of files, each copyright someone else, you can't litigate infringement cases easily.

>The best licenses are BSD and MIT and others of that sort; they have no naive pretense of not helping corporations: everyone can do almost whatever they want, be they a large business or an individual. These licenses also don't encourage unlevel playing fields where the copyright proprietor enjoys dominance in the ecosystem.

The project owner ALWAYS has dominance in the ecosystem. At least with GPL the owner is protected from someone else scooping up the project to make a closed version. How would you feel if you made an awesome open project only for someone to copy it and close the source, make minor changes, and sell it without even giving you the changes? That crap is not possible with GPL.

The GPL does not prevent closed versions because of Tivoization, and SaaS.

For instance, Facebook is closed, in spite of running on a mountain of GPLed stuff.

A locked device may prevent the user from running a kernel image that is not signed with a certain private key, even though the vendor of the device complies with the GPL and provides the matching kernel sources and the correct toolchain to reproduce the build without a signature.

I would almost go as far as to say that, in this day and age, someone ripping off free source code in order to create a nice, local-only application, is practically a hero. :)

This is why we have AGPL and GPLv3. You can TiVoize the kernel, but you have to provide the user land, at minimum.

In a MIT only world, you would have no source of anything. So not only you can’t build a signature-free version of the kernel for educational purposes, you can’t even have it.

This is a corporation paradise.

Unfortunately, AGPL is a non-free license, which dictates how one may run the program when not redistributing any of its code. It's a clumsy attempt to attack a certain problem in the social computing sphere using software licensing. (You know the adage about every problem looking like a nail when the only tool you have is a hammer.)

Open source licenses are characterized by the fact that you don't have to read them, let alone agree with them, merely in order to obtain the software and use it. These licenses "kick in" when you redistribute.

The AGPL can only be litigated as a closed license; i.e. the argument being that if the defendant does not use the program in accordance with the license, their copy is infringing, the same like a cracked version of Photoshop. Whether you are allowed to have a copy or not depends on how you are using it.

A successful AGPL litigation would mainly succeed in proving to the world that the license is nonfree, which would be evident from the arguments that would necessarily have to be used, and the reasoning necessarily expressed in the verdict.

Like it or not, AGPL is a free software license. It only says that even if you provide the service as a SaaS, you share the code if you change it.

You may dislike that particular family of licenses, but it doesn’t allow you to give false information about it. Maybe it’s not intentional, so you need to refresh your understanding. We’re humans, and our brains are not tapes. Knowledge distorts. I experience the same.

GPL says something simple: “Modified the code? Share it. Oh, BTW, you can’t change the license.” The rest is legalese.

It curtails one of the four essential freedoms that form the core of the Free Software Foundation's definition of Free Software:

https://www.gnu.org/philosophy/free-sw.html

"The freedom to run the program as you wish, for any purpose (freedom 0)."

If you modified the software, there are restrictions on running it; you cannot run the program as you wish, for any purpose.

It looks like an open and shut case to me. The place where the AGPL comes from doesn't meet the free software definition coming from the same place.

It might meet your personal definition of what is free, but that doesn't fix the above hypocrisy.

What usage purpose is prevented in LGPL software? The whole point of GPL-type licenses may seem hypocritical to you ("boo hoo I can't use someone else's code without contributing my changes back!") but it's a well-reasoned strategy to prevent theft of code from a GPL project.

The "Lesser GPL" (preceded by "Library GPL") doesn't prevent usage, to my knowledge; it isn't hypocritical with regard to freedom zero.

It allows certain combined works to be redistributed whose redistribution would be forbidden by the GPL, like proprietary, closed-source programs dynamically linked to a LGPLed library.

Given a GPLed library, you can make such a combined work anyway, and use it; but you may not redistribute it.

The LGPL is more free than the GPL, whereas the AGPL is nonfree.

In 2016, the Cygwin project LGPLed its libraries (DLLs). That was great news; that meant I could bundle a BSD-licensed program without having to put a GPL license on the combined work as a whole and cast doubts about how it could be used (since it is a programming language implementation, needing to be redistributed by downstream developers).

I immediately started working on a fork of the Cygwin DLL that would enable it to serve as a more native-looking run-time for Windows applications. I could build the program on Cygwin (and make a regular Cygwin package), but also ship exactly the same executable as a Windows application by bundling it with the modified cygwin1.dll.

The LGPL is good.

In computer science, there is the question whether P =? NP.

Likewise, we have the question GPL =? LGPL; would the GPL's unreasonable exclusion of dynamic linking hold up in court, or would it fall, reducing GPL to LGPL?

I'm of the opinion that everything library-like should use the LGPL rather than the GPL (if it must use some kind of GPL). The LGPL is what the GPL should be (if it legally isn't already anyway).

The LGPL is better for promoting free software. If some developer has a choice between a proprietary library and a free one, it's counterproductive to slap a GPL on the free one to steer them to the other one.

Obviously, the LGPL is used for platform libraries like Glibc, based on similar reasoning, which is probably also why Cygwin sobered up and switched to LGPL. Because banishing proprietary programs from linking to the libraries that comprise free platforms would be counterproductive. You just lose user base and mind share.

My bad, I accidentally typed LGPL when I meant AGPL. I do actually know what these licenses entail in general, despite the typo. I kinda wonder if it was autocorrect that screwed it up.

The extra provisions of the AGPL do not get triggered based on how you run the program, they get triggered when you modify the program. You definitely don't need to read the AGPL to run the software. Please check out the text of the AGPL rather than repeating what people say about it.

You don't need to read the GPL, or any other free software license, to modify a program and to run it.

Modifying a program is illegal under copyright law, so yes you do need to read the license before doing that.

No, copyright law doesn't say anything about privately modifying a work. Only about distributing derived works.

It would behoove you to check the license in order to confirm that whoever gave it to you had the right to do so.

Beyond confirming that you have a legit copy, you don't have to be concerned with the license at all, if you're not redistributing anything.

The vendors of proprietary software and their lawyers dreamed up this idea that a license can lapse based on the user's non-redistributing uses of the work. For instance, if the user reverse-engineers the binary code to understand how it works, then they become unlicensed, the idea then being that they are perpetrating copyright infringement by continuing to have a copy.

The AGPL falls into this category.

The restriction itself does not come from copyright law; copyright law doesn't say things like that allowing network users to interact with a software program is an infringing activity, or that reading the work to understand it is infringing activity.

AFAICT, American copyright law does say "To prepare derivative works based upon the work" is not allowed, and doesn't say anything about private derivatives being an exception to that.

https://en.wikipedia.org/wiki/Copyright_law_of_the_United_St...

Certainly if you privately modify it is going to be unlikely for someone to find out you did that, but that doesn't make it any less illegal.

Preparation means getting ready for something. here, that almost certainly means redistribution.

You're not breaking the law if you scribble notes in the margin of a textbook; that's just crazy. Even if you pass that on to a friend, for that matter.

Anyway, if a license tries to rely on such draconian doctrines to prevent uses, it's obviously not a free license.

That is definitely not what the word prepare means in that sentence. Its more like the meaning in the phrase "prepare a meal".

I'm guesssing that likely intent is so that the authorities could raid a large scale copyright infringment operation, and obtain convictions based on evidence of perparation alone. I.e. not have to catch anyone red-handed redistributing the prepared materials.

Kind of like how cops in some places in America can evidently arrest someone for DUI if that person merely walks to their car with their car keys, intending to sleep inside until sober.

The GPLv3 doesn't prevent what TiVo did (break proprietary software after installing modified GPLed software), and GPLv2 requires users be able to install modified GPL software, so a "TiVoised" kernel is a GPLv2 violation.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017... Behan-Webster-1.pdf

The GPLv3 was explicitly created to prevent tivoization.

The GPLv2 already did that, the GPLv3 was created to prevent what TiVo did (not Tivoization), but ended up not actually doing that.

TiVo did not do what is currently referred to as Tiviosation, they just broke their proprietary software on top of Linux when you modified Linux, which you could still do. Both the GPLv2 and GPLv3 require you to be able to modify and reinstall GPL software, so devices that are locked against this are GPL violating. There is the AGPL for the SaaSS problem.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

>The GPL does not prevent closed versions because of Tivoization, and SaaS.

This is exactly what AGPL is for. Of course, AGPL is too overbearing for most projects, and only makes sense for SaaS.

>A locked device may prevent the user from running a kernel image that is not signed with a certain private key, even though the vendor of the device complies with the GPL and provides the matching kernel sources and the correct toolchain to reproduce the build without a signature.

This is a problem indeed (that most people have forgotten about, due to the shim code that people use to load other operating systems like Linux). It may become a problem in the future so we need to stay vigilant and never support products that lock the bootloader. Unfortunately most phones do that. Phones are a rats nest of proprietary software and hardware and we need more development of open technology in that space.

The AGPL does squat all for the social problems causes by SaaSS, and only succeeds in being a technically non-free license.

Nobody cares if you take some open source server software, and run version that you modified with your own cool features, without sharing the source code, and this is something you're entitled to under the FSF's Freedom Zero.

Among the social harms of SaaSS, this is not on the radar; and obsession with it shows either that the FSF are out of touch, or that they think that any action is better than inaction, so that if they take a swing at the problem with the wrong tool (copyright licensing) they look like they gave it a good college try.

The problem of SaaSS is people being locked to a service because that's where their data is siloed. This harm can be perpetrated with completely unmodified software you can download yourself. Running your own copy does nothing to solve the problem; your copy is not where the data is, where the other users are.

Under the GPL, users can litigate too. There is a test case for this running now:

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