trevor@lemmy.blahaj.zone
on 25 May 17:26
nextcollapse
Precisely. The Rust community should stop using pushover licenses.
sugar_in_your_tea@sh.itjust.works
on 25 May 18:01
collapse
Eh, I don’t see the issue here. The MIT license is fine for a few reasons:
attractive to lots of FOSS projects, like BSDs, Redox, etc
no incentive to embed into proprietary projects - ls, cp, etc aren’t particularly interesting to embed, and functionality is usually better in the stdlib of whatever language you’re using
increases appeal generally for research purposes
I really don’t see much benefit of GPL here. It makes sense for larger works with interesting snippets of code, but not for small, one-off tools like this.
If the other projects are licensed with a GPL, there is no issue doing any of these things (except using them for proprietary purposes later), which is the point. If you licensed your project incorrectly, that isn’t the GPL-licensed project’s fault.
sugar_in_your_tea@sh.itjust.works
on 25 May 19:40
nextcollapse
Right, because the GPL is viral, forcing everything to be GPL-compatible or you’ll have problems. Some FOSS licenses aren’t GPL-compatible, notably the CDDL used for OpenZFS, which is why it has been a part of FreeBSD but not Linux (and it’s available now outside the kernel).
The GPL makes more sense the more “application-y” your project is, but if you want it used more broadly, more permissive licenses make more sense. Yes, the LGPL exists, but there are still a ton of caveats to it.
The code in something like coreutils isn’t all that useful generally, so protecting it with the GPL doesn’t bring a ton of value, whereas a more permissive license could.
I like the GPL and its variants and I use it from time to time. I also like the MIT and similar permissive licenses, and I use them as well. Use the right license for the use case. I think the MIT is fine here.
If you think other people disagreeing with you on how to license their own work is “incorrect” maybe you are the one not really in favor of freedom.
GPL is more freedom for users and developers. MIT is less freedom for users because it grants more “freedom” for some company to exploit the developer’s labor by taking it to make something proprietary with it.
If you want to use GPL code, pushover licenses are incorrect because they protect the user and developer from this nonsense.
taladar@sh.itjust.works
on 26 May 17:20
nextcollapse
GPL is just as bad as proprietary licenses in the sense that GPL makes the user worry about the licensing of some library they just want to use. MIT, BSD,… give the code user the freedom to avoid worrying about licensing bullshit. GPL meanwhile doesn’t really solve any of the problems you claim it solves because all it does is duplicate effort and the non-GPL duplicate is used in a lot of places where a single copy of the code could be used if the GPL-using author hadn’t stubbornly insisted on a disproven theory of how GPL will save us.
bitfucker@programming.dev
on 26 May 22:28
collapse
I always see people with the argument that the developer labour is somehow being exploited. But have you never thought that maybe, just maybe, the person in question does not care? He just wanted to publish his creation and be done with it. He does not care if people are using it. That’s my case. I don’t care if people want to use my piece of cryptographic library. Just be aware that I am just some random dude, providing no support nor warranty. I make the library for my use cases and it works fine.
Well presumably there are at least some performance and safety benefits to using these new alternatives. Otherwise it’s just a blatant license dodge.
bitcrafter@programming.dev
on 26 May 17:04
collapse
In that case, nothing is stopping Debian from using uutils as it is; they can’t really “re-license” it anyway since the original code will continue to be MIT-licensed.
Using MIT license means the developers cannot look at GNU source code when writing code for uutils. This feels like a unnecessary hurdle given that uutils wants to be 100% compatible with GNU tools.
taladar@sh.itjust.works
on 26 May 10:37
nextcollapse
On the other hand a new GPL licensed version of coreutils will run into the exact same adoption problems that brought us the current mess of “you can use this parameter on GNU but not on the BSD version”,…
FizzyOrange@programming.dev
on 26 May 15:56
nextcollapse
It’s not quite that bad. They say
This means that we cannot accept any changes based on the GNU source code.
You are totally allowed to look at it. For example if there was some weird behaviour that you couldn’t work out, you could look at the GNU code to understand it.
What you can’t do is closely base your code on the GNU code. I.e. you can’t just translate it from C into Rust.
That’s not accurate. They can look at it, but they can’t port it. But looking at how it works and then coming up with their own implementation is fine.
Maybe not the best example then, but not the only example. If you unintentionally create something that resembles the original too much you may still become liable. It’s hard to draw the line, which is why many in such a position would prefer to be safe rather than sorry.
bitfucker@programming.dev
on 28 May 09:13
collapse
How so? People come up with the same idea all the time independently of each other. When doing clean room implementation (the ideal best case), you are not liable if what you create at the end matches 1-1 with the original. You never know anything about the implementation detail of the original. Academia also acknowledged independent discovery and publication of many things. Why would clean room implementation be different?
Because coming up with the same implementation independently is legal, while copying someone else’s implementation isn’t. Which method you used to arrive at your implementation can be difficult to prove either way, which is why it’s important for implementors to be able to say they never looked at the original. It’s a legal defence, in case you ever need to stand in front of a judge or jury who will question how you arrived at yours.
bitfucker@programming.dev
on 28 May 20:13
collapse
That’s… what I’m saying. Clean room implementation is legal. You accidentally arrive at the same conclusion independently. And yes, it is tedious to do it but it is legal.
Ah yes, then we are in agreement. I thought we were talking about unintentionally arriving at the same implementation after looking at the original, which is where the discussion started.
The original CoreUtils have beenvetted through decades of use. They have been broken and fixed many times, and they have been hardened against so many edge cases, it’s not funny anymore. That’s where those 600 tests come from (mostly). Once they have brought the Rust tools to that level, how much performance advantage will there be left?
threaded - newest
Rust đź‘Ť
MIT instead of GPL đź‘Ž
Precisely. The Rust community should stop using pushover licenses.
Eh, I don’t see the issue here. The MIT license is fine for a few reasons:
I really don’t see much benefit of GPL here. It makes sense for larger works with interesting snippets of code, but not for small, one-off tools like this.
If the other projects are licensed with a GPL, there is no issue doing any of these things (except using them for proprietary purposes later), which is the point. If you licensed your project incorrectly, that isn’t the GPL-licensed project’s fault.
Right, because the GPL is viral, forcing everything to be GPL-compatible or you’ll have problems. Some FOSS licenses aren’t GPL-compatible, notably the CDDL used for OpenZFS, which is why it has been a part of FreeBSD but not Linux (and it’s available now outside the kernel).
The GPL makes more sense the more “application-y” your project is, but if you want it used more broadly, more permissive licenses make more sense. Yes, the LGPL exists, but there are still a ton of caveats to it.
The code in something like coreutils isn’t all that useful generally, so protecting it with the GPL doesn’t bring a ton of value, whereas a more permissive license could.
I like the GPL and its variants and I use it from time to time. I also like the MIT and similar permissive licenses, and I use them as well. Use the right license for the use case. I think the MIT is fine here.
If you think other people disagreeing with you on how to license their own work is “incorrect” maybe you are the one not really in favor of freedom.
GPL is more freedom for users and developers. MIT is less freedom for users because it grants more “freedom” for some company to exploit the developer’s labor by taking it to make something proprietary with it.
If you want to use GPL code, pushover licenses are incorrect because they protect the user and developer from this nonsense.
GPL is just as bad as proprietary licenses in the sense that GPL makes the user worry about the licensing of some library they just want to use. MIT, BSD,… give the code user the freedom to avoid worrying about licensing bullshit. GPL meanwhile doesn’t really solve any of the problems you claim it solves because all it does is duplicate effort and the non-GPL duplicate is used in a lot of places where a single copy of the code could be used if the GPL-using author hadn’t stubbornly insisted on a disproven theory of how GPL will save us.
I always see people with the argument that the developer labour is somehow being exploited. But have you never thought that maybe, just maybe, the person in question does not care? He just wanted to publish his creation and be done with it. He does not care if people are using it. That’s my case. I don’t care if people want to use my piece of cryptographic library. Just be aware that I am just some random dude, providing no support nor warranty. I make the library for my use cases and it works fine.
Debian should fork it and re-license it under the GPL.
What would be the point of doing that when they can just keep using GNU coreutils?
Well presumably there are at least some performance and safety benefits to using these new alternatives. Otherwise it’s just a blatant license dodge.
In that case, nothing is stopping Debian from using uutils as it is; they can’t really “re-license” it anyway since the original code will continue to be MIT-licensed.
Using MIT license means the developers cannot look at GNU source code when writing code for uutils. This feels like a unnecessary hurdle given that uutils wants to be 100% compatible with GNU tools.
On the other hand a new GPL licensed version of coreutils will run into the exact same adoption problems that brought us the current mess of “you can use this parameter on GNU but not on the BSD version”,…
It’s not quite that bad. They say
You are totally allowed to look at it. For example if there was some weird behaviour that you couldn’t work out, you could look at the GNU code to understand it.
What you can’t do is closely base your code on the GNU code. I.e. you can’t just translate it from C into Rust.
That’s not accurate. They can look at it, but they can’t port it. But looking at how it works and then coming up with their own implementation is fine.
It’s a gray area, legally. What you say is theoretically correct, but there’s practical issues once you’ve looked at the code that will open you up to legal liability anyway.

For instance, what if you need a utility function during your reimplementation for which there is really only one obvious implementation? You can no longer claim to have come up with it by yourself.

I doubt the FSF would sue over it, but companies are known to avoid the risk.
If a piece of code is so trivial there is only one obvious solution then it does not fall under copyright. There is jurisprudence for this.
Maybe not the best example then, but not the only example. If you unintentionally create something that resembles the original too much you may still become liable. It’s hard to draw the line, which is why many in such a position would prefer to be safe rather than sorry.
How so? People come up with the same idea all the time independently of each other. When doing clean room implementation (the ideal best case), you are not liable if what you create at the end matches 1-1 with the original. You never know anything about the implementation detail of the original. Academia also acknowledged independent discovery and publication of many things. Why would clean room implementation be different?
Because coming up with the same implementation independently is legal, while copying someone else’s implementation isn’t. Which method you used to arrive at your implementation can be difficult to prove either way, which is why it’s important for implementors to be able to say they never looked at the original. It’s a legal defence, in case you ever need to stand in front of a judge or jury who will question how you arrived at yours.
That’s… what I’m saying. Clean room implementation is legal. You accidentally arrive at the same conclusion independently. And yes, it is tedious to do it but it is legal.
Ah yes, then we are in agreement. I thought we were talking about unintentionally arriving at the same implementation after looking at the original, which is where the discussion started.
1000%
It’s also a great learning opportunity to see how core tools like
cat,ls, etc are written in rust. Relevant repo dir: github.com/uutils/coreutils/tree/main/src/uuThe original CoreUtils have beenvetted through decades of use. They have been broken and fixed many times, and they have been hardened against so many edge cases, it’s not funny anymore. That’s where those 600 tests come from (mostly). Once they have brought the Rust tools to that level, how much performance advantage will there be left?