Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting essential Linux packages in Rust

lwn.net

Post reply on HN
Print view View original

151–160 of 175 posts

Re: Rewriting essential Linux packages in Rust

#151

Post by tmtvl »

loufe wrote: post #47
tmtvl wrote: post #29

Rewriting GPL software under the MIT license is a terrible thing to do. The GPL is meant to protect and preserve what should be basic human rights. So-called "permissive" licenses are meant to provide big tech with free labour.

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?

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.

Re: Rewriting essential Linux packages in Rust

#152

Post by wakawaka28 »

kazinator wrote: post #133
bayindirh wrote: post #122

Earlier quoted context omitted.

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

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…

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.

Re: Rewriting essential Linux packages in Rust

#153

Post by conor- »

mustache_kimono wrote: post #123
grg0 wrote: post #119

Earlier quoted context omitted.

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 fre…

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

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

Re: Rewriting essential Linux packages in Rust

#154

Post by mustache_kimono »

conor- wrote: post #153
mustache_kimono wrote: post #123

Earlier quoted context omitted.

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

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?

Re: Rewriting essential Linux packages in Rust

#155

Post by mustache_kimono »

alwayslikethis wrote: post #139
mustache_kimono wrote: post #124

Earlier quoted context omitted.

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

Re: Rewriting essential Linux packages in Rust

#156

Post by kazinator »

wakawaka28 wrote: post #152
kazinator wrote: post #133

Earlier quoted context omitted.

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…

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.

Re: Rewriting essential Linux packages in Rust

#157

Post by pabs3 »

kazinator wrote: post #149
pabs3 wrote: post #148

Earlier quoted context omitted.

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

Re: Rewriting essential Linux packages in Rust

#158

Post by wakawaka28 »

kazinator wrote: post #115
wakawaka28 wrote: post #114

Earlier quoted context omitted.

>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 prot…

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…

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

Re: Rewriting essential Linux packages in Rust

#159

Post by wakawaka28 »

kazinator wrote: post #156
wakawaka28 wrote: post #152

Earlier quoted context omitted.

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 redis…

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.

Re: Rewriting essential Linux packages in Rust

#160

Post by grg0 »

mustache_kimono wrote: post #154
conor- wrote: post #153

Earlier quoted context omitted.

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.

Post reply on HN