Rewriting the GNU Coreutils in Rust
Rewriting the GNU Coreutils in Rust
Posted Jun 11, 2021 10:37 UTC (Fri) by pizza (subscriber, #46)In reply to: Rewriting the GNU Coreutils in Rust by marcH
Parent article: Rewriting the GNU Coreutils in Rust
And do I really have to point out that the software world is *much much much* bigger than the "tech industry"?
Posted Jun 11, 2021 11:53 UTC (Fri)
by khim (subscriber, #9252)
[Link] (6 responses)
The whole thing was designed to fight tivoization. It wasn't the only reason to create GPLv3, but that was the main one. And the expected outcome was that hardware manufacturers would just make it possible to change the code on a device they sell. But it was really quite naive to expect such an outcome in a world where the same hardware is sold to a different users at “differentiated prices”. Think Intel's CPUs or compare prices of TI-NSpire and TI-NSpire CAS (not only they have identical hardware, their sales rely on the inability of the buyer to tinker with their software… they are not doing all that good of a job ensuring that, actually, since they only need to claim that it's impossible to change the software, they don't need to make it actually impossible — but that stil absolutely precludes use of GPLv3 software). FSF hoped to, basically, change the business models of many different industries, laws (that's very explicitly written there, look on section #3), the style in which governments operate — with very limited reward: the ability to use some software for free. No wonder the attempt backfired. It was a gamble: we may change the rules under which the whole world operates or we would be kicked out of mainstream and relegated to tiny, insignificant niches. But GCC looked so entrenched, Linux was so popular… the die was cast. “Free software” lost. Indeed. And since software replaces hardware more and more it becomes more and more important for the developers of hardware to stop unauthorized modifications. For market compliance and other reasons. Indeed, that was pointed out to FSF many, many times during the GPLv3 drafting. And it was altered to accommodate some such uses (look for distinctions WRT to “User Product”, e.g. — it's there specifically to allow producers of industrial devices not intended to be used by “Joe Average” to be able to delived locked-down hardware to their customers who very expressly don't want the ability to change the code on a device with associated liability). But it was very obvious even back then that such cases would become more widespread, not less (heck, look on #3 “Protecting Users' Legal Rights From Anti-Circumvention Law” again). In a world where problems in software may lead to, at most, some papers being incorrectly printed GPLv3 may have been acceptable (yet, ironically enough, it was also not needed in such a world). In a world where software drives literally everything… it's unusable and ensures that end-users would never see your software. Relying on software to fix hardware bugs is the norm novadays and it's much, much, MUCH simpler to rely on the locked down, signed, firmware instead on some nebulous schemes which may detect and alter modification of core system library (like libstdc++) and save the hardware anyway. It's certainly nice that some niche industries may still afford to use GPLv3 and I really would be glad to read your article about that (no sarcasm here) but GPLv3 was expressly designed to make sure software under said license wouldn't be acceptable for many, many, MANY industries and thus would never reach the end users.
Posted Jun 11, 2021 12:15 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
This may have been the end result, but it is was not the "Expressly designed intent", as you yourself said in the very first sentence of your reply:
> The whole thing was designed to fight tivoization. It wasn't the only reason to create GPLv3, but that was the main one. And the expected outcome was that hardware manufacturers would just make it possible to change the code on a device they sell.
(though that should be "continue to make it possible" -- manufacturers have to do considerably more work to create a locked-down device than not)
Anyway. In my experience (based on discussions with the last two $dayjobs' legal staff) it's not the anti-DRM clauses that made the GPLv3 a pariah -- that was a minor nuisance, easily worked around via technical means. The patent language, however, was the RealProblem(tm).
Posted Jun 11, 2021 12:36 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Locked-down devices predate not just GPLv3, not just the whole GNU project. They go back to early days of the IT industry. IBM sold features which would be unlocked (by installation of some SMS cards) back in 1950th, TROS modules in 1960th and so on. Yes, it was relatively easy to circumvent these limitations (compared to RSA signature in modern devices) but that's not something people invented just to make FSF angry at them. GPLv3 needs entirely new scheme, though: the one where you can change part of your base system software but not the whole thing. That is certainly harder to achieve than full lock down of the whole thing.
> Anyway. In my experience (based on discussions with the last two $dayjobs' legal staff) it's not the anti-DRM clauses that made the GPLv3 a pariah -- that was a minor nuisance, easily worked around via technical means. The patent language, however, was the RealProblem(tm).
How is that substantially different from Apache license? It also includes the patent grant. And is loved by the industry.
Posted Jun 11, 2021 12:49 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
For the "tech industry" as a whole, the "user" is not the "customer" -- as in, those _using_ the product/device/whatever are not the same parties who actually fork over money. In those scenarios (and other business models where hardware is sold at a loss and made up for on the back end), locked-down devices are economically advantageous.
For everything else, barring legal/regulatory anti-tamper requirements (which are actually quite rare), there simply isn't an economic incentive/advantage to lock the hardware down; indeed it doing so can actually place you at a competitive disadvantage (because it both raises your costs and _reduces_ end-user functionality/utility)
In my two decades of experience in this field, the general concept of copyleft as a whole is the problem -- businesses simply don't want to have to comply with source distribution requirements and the risk that their "secret sauce" is forced into the open due to viral GPL contamination. Nevermind that having the processes to maintain/track the "software supply chain" is a practical necessity (ie _not_ having it can be a massive liability even without copyleft/GPL)
Once they accept the practical realities of having some GPL software (ie providing corresponding source code and keeping their proprietary stuff, if any, properly segregated), GPLv2 vs GPLv3 vs MPL vs SCCL or whatever is largely irrelevant... unless you have patents you're trying to protect/enforce, and the GPLv3's explicit patent license can possibly render your business' entire patent portfolio effectively useless for anything other than purely defensive means. That scares the bejeebus out of the suits, so the edict comes down that GPLv3 is bad, along with the funding to avoid its use, even to the point of wholesale development of in-house replacements.
Posted Jun 11, 2021 12:57 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Jun 11, 2021 14:17 UTC (Fri)
by pizza (subscriber, #46)
[Link]
ASLv2's patent clauses kick in only for _contributions_ to the software (ie "by contributing, you're granting a license for all patents you have that relate to the software") , but GPLv3's patent clauses go considerably further, applying even if you merely redistribute unmodified 3rd party software covered by a patent you hold or have licensed.
Posted Jun 11, 2021 15:42 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
macOS has been stuck to the last GPLv2 version of bash for years, now switching to zsh. Same for other software on macOS.
Same timing all across the industry, what a coincidence!
> I'd think such an absolute declaration as to the intents of the GPLv3 would be trivial to cite, as the whole drafting process was quite public
Rewriting the GNU Coreutils in Rust
Rewriting the GNU Coreutils in Rust
> though that should be "continue to make it possible" -- manufacturers have to do considerably more work to create a locked-down device than not
Rewriting the GNU Coreutils in Rust
Rewriting the GNU Coreutils in Rust
You still haven't explained what makes explicit patent grant in GPLv3 worse than no less explicit patent grant of APL. And APL is certainly warmly embraced by the industry.
Rewriting the GNU Coreutils in Rust
Rewriting the GNU Coreutils in Rust
Rewriting the GNU Coreutils in Rust