What's with the move to MIT over AGPL for utilities?
-
I would understand if Canonical want a new cow to milk, but why are developers even agreeing to this? Are they out of their minds?? Do they actually want companies to steal their code? Or is this some reverse-uno move I don't see yet? I cannot fathom any FOSS project not using the AGPL anymore. It's like they're painting their faces with "here, take my stuff and don't contribute anything back, that's totally fine"
I worked on an oss library with an MIT license and my colleagues told me they with that instead of GPL was with GPL it basically forces anyone who uses the library to make everything in their project available.
-
I assume this is in reference to the rust coreutils being MIT-licensed. How would using GPL benefit them?
Improvements would be upstreamed. Not with MIT
-
Maybe there could be another reason why people choose MIT to begin with:
When you start a new repo on github it makes suggestions which license to use, and I bet many people can't be arsed to think about it and just accept what they're offered. [My memory is a little patchy since I very rarely use github anymore, but I definitely remember something like this.]
That said, please undestand that many, many git platforms exist and there is no reason at all to choose one of the two that actually have the word git in them.
I can't believe professional developers choose MIT because they can't be arsed to look at the license choices
-
I worked on an oss library with an MIT license and my colleagues told me they with that instead of GPL was with GPL it basically forces anyone who uses the library to make everything in their project available.
Only if they make changes/improvements to the code. If it's a library that is used then no, AFAIK you don't need to.
-
I would understand if Canonical want a new cow to milk, but why are developers even agreeing to this? Are they out of their minds?? Do they actually want companies to steal their code? Or is this some reverse-uno move I don't see yet? I cannot fathom any FOSS project not using the AGPL anymore. It's like they're painting their faces with "here, take my stuff and don't contribute anything back, that's totally fine"
here, take my stuff and don’t contribute anything back, that’s totally fine
I mean, yeah? They are probably fine with that and think that software should be distributed without restrictions. You may not agree with it, but it's their choice. Not really stealing if they give it away willingly.
I cannot fathom any FOSS project not using the AGPL anymore.
I mean, most of them that want to use a GPL-like license use the GPL or LGPL rather than the AGPL.
why are developers even agreeing to this?
Are they? Last I checked this wasn't as much of a plan as much of it was just a developer thinking out loud. And even if it was a real plan, developers should continue doing what they should be doing anyway: Write their scripts without any GNU/uutils/whatever-microsoft-calls-their-evil-uutils-fork extensions. Then their scripts could run across all platforms, including GNU, uutils, FreeBSD and BusyBox.
At any rate, if Microsoft really wanted to make their own coreutils fork (if they haven't already), they're not really that complicated tools. They could devote like maybe a year of engineering time and get it pretty much compatible.
-
it's been a trend for a while unfortunately. getting rid of the gpl is the motivation behind e.g. companies sponsoring clang/llvm so hard right now. there's also developers that think permissive licenses are "freer" bc freedom is doing whatever you want /s. they're ideologically motivated to ditch the gpl so they'll support the change even if there's no benefit for them, financial or otherwise.
getting rid of the gpl is the motivation behind e.g. companies sponsoring clang/llvm so hard right now.
Is it? As I understand it, LLVM is much easier to work with than GCC, especially given their LLVM IR and passes frameworks.
-
I can't believe professional developers choose MIT because they can't be arsed to look at the license choices
Ah, OK. No, of course not. I was thinking more about hobby developers.
-
Yeah, specifically for something like coreutils I can't see the malicious endgame that is suggested by others here. Is the fear that a proprietary version of
catorpwdorprintftakes over the ecosystem and then traps users into a nonfree agreement? Or a proprietary coreutils superset that offers some new tool and does the same thing? What would stop anyone from just writing their own proprietary set of tools to do the same thing now, even if uutils didn't exist?I personally don't see a compelling reason to change to MIT, but I also don't see the problem.
-
Improvements would be upstreamed. Not with MIT
GPL would not require that. It would only require publication of the source. There is no requirement to give back or even make your changes compatible with upstream.
-
I would understand if Canonical want a new cow to milk, but why are developers even agreeing to this? Are they out of their minds?? Do they actually want companies to steal their code? Or is this some reverse-uno move I don't see yet? I cannot fathom any FOSS project not using the AGPL anymore. It's like they're painting their faces with "here, take my stuff and don't contribute anything back, that's totally fine"
My rule-of-thumb is: is the licence going to make things better for users? In other words, I try to predict whether a company would just not use my AGPL-licensed code, or would potentially contribute back. If they wouldn't, I don't really care and rather my code at least gets used to build something presumably useful.
-
I can't believe professional developers choose MIT because they can't be arsed to look at the license choices
I can’t believe professional developers choose MIT because they can’t be arsed to look at the license choices
Have you worked with many professional developers?
-
Only if they make changes/improvements to the code. If it's a library that is used then no, AFAIK you don't need to.
I think it's more complicated than use, like something about being allowed to dynamically link to it but not statically, or something like that.
-
GPL would not require that. It would only require publication of the source. There is no requirement to give back or even make your changes compatible with upstream.
True.
Though, you are probably going to have a much easier time implementing a change to your code that is present in a company's published code, than you would trying to reverse-engineer a binary.
Sharing of the code I would consider "giving back" in it of itself.
-
The unfortunate reality is that a significant proportion of software engineers (and other IT folks) are either laissez-faire "libertarians" who are ideologically opposed to the restrictions in the GPL, or "apolitical" tech-bros who are mostly just interested in their six figure paychecks.
To these folks, the MIT/BSD licenses have fewer restrictions, and are therefore more free, and are therefore more better.
Yeah, that's all there's to it. In a past not so ideologically developed life, I've written code under Apache 2 because it was "more free." Understanding licenses, their implications, the ideologies behind them and their socioeconomic effects isn't trivial, and people certainly aren't born educated in that.
-
Yeah, specifically for something like coreutils I can't see the malicious endgame that is suggested by others here. Is the fear that a proprietary version of
catorpwdorprintftakes over the ecosystem and then traps users into a nonfree agreement? Or a proprietary coreutils superset that offers some new tool and does the same thing? What would stop anyone from just writing their own proprietary set of tools to do the same thing now, even if uutils didn't exist?I personally don't see a compelling reason to change to MIT, but I also don't see the problem.
What's stopping people from doing that today is network effects. There are enough differences today between bsd coreutils and gnu coreutils that substituting one for the other doesn't work out of the box.
The chain of events that would cause a problem are: due to Ubuntu popularity rust MIT core utils overtakes gnu coreutils and people drop support for gnu coreutils, then a large and we'll funded corporate entity could privately fork rust coreutils and lock people in.
-
What's stopping people from doing that today is network effects. There are enough differences today between bsd coreutils and gnu coreutils that substituting one for the other doesn't work out of the box.
The chain of events that would cause a problem are: due to Ubuntu popularity rust MIT core utils overtakes gnu coreutils and people drop support for gnu coreutils, then a large and we'll funded corporate entity could privately fork rust coreutils and lock people in.
I'm with you until the lockin. How does that happen?
-
I can’t believe professional developers choose MIT because they can’t be arsed to look at the license choices
Have you worked with many professional developers?
At work, yes
-
My rule-of-thumb is: is the licence going to make things better for users? In other words, I try to predict whether a company would just not use my AGPL-licensed code, or would potentially contribute back. If they wouldn't, I don't really care and rather my code at least gets used to build something presumably useful.
The point is that even if companies have the personnel to contribute back, most of them don't. It simply isn't in their interest. If a project is good enough, AGPL will mean that no monopoly will form around that project and open standards will be maintained. AGPL is simply a bastion against closed-source software working against the best interests of consumers
-
GPL would not require that. It would only require publication of the source. There is no requirement to give back or even make your changes compatible with upstream.
Yes, publication of the source is enough. However, you are correct and I should have worded it better. In practice, publishing the source allows the developers of the software to make improvements unhindered by licensing and other IP-based hindrances which are otherwise present in closed-source software
-
Ah, OK. No, of course not. I was thinking more about hobby developers.
If it is solely for investors, then I understand. However I'm saddened to think that altrium in software has gone to the gutter
