OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
Posted Sep 11, 2020 21:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)In reply to: OpenPGP in Rust: the Sequoia project by IanKelling
Parent article: OpenPGP in Rust: the Sequoia project
GPLv3 is NOT better...
Posted Sep 12, 2020 13:29 UTC (Sat)
by Deleted user 129183 (guest, #129183)
[Link] (9 responses)
Please stop spreading FUD. GPL 3 improves upon GPL 2 by fixing the tivoisation loophole, providing patent grants, increasing compatibility with licences like Apache 2 and some other things which I’ve forgotten.
Posted Sep 12, 2020 15:04 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (7 responses)
Yes v3 has a bunch of bug-fixes for v2, and if they'd limited to that it would be a real improvement.
(And I've had people say that - for things that the FSF said were bug fixes - they thought v2 was a feature and didn't WANT the fix!)
So I think a LOT people wouldn't say v3 was an improvement.
Cheers,
Posted Sep 12, 2020 19:47 UTC (Sat)
by martin.langhoff (subscriber, #61417)
[Link] (4 responses)
GPLv3 is _different_.
Some bug fixes that would be nice to fold into a "GPLv2.1".
And some major changes of social contract, which would be better suited in a different license.
Posted Sep 13, 2020 23:24 UTC (Sun)
by cyphar (subscriber, #110703)
[Link] (3 responses)
I do want to point out (since I assume your reference to "change in the social contract" is in relation to the tivoisation clause), that while folks like to wax lyrical about GPLv3's tivoisation clause, many seem to forget that GPLv2 actually had a similar (in spirit) requirement: > For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. [emphasis added] I don't think it's a stretch to say that if firmware keys were widely deployed in 1991 that GPLv2 would've had a more substantial clause dedicated to making sure that the "scripts used to control compilation and installation of the executable" would've included any firmware signing keys necessary to make it possible to actually use the software you've modified. And yes, the modern interpretation of "scripts used to control compilation and installation of the executable" does include instructions on how to install the software on to whatever hardware you've been sold. My point is, maybe you disagree with the tivoisation clause -- but GPLv2 clearly had a similar spirit in this area (it's just that the FSF didn't predict that firmware signing was going to be a widespread method for stopping people from being able to run modified software). So it's less a "change in the social contract" and more "updating the legal wording to match the original intent in a world where firmware signing keys exist"
Posted Sep 14, 2020 21:09 UTC (Mon)
by martin.langhoff (subscriber, #61417)
[Link] (2 responses)
No, that does not hold. You get the tools so can build install the executable... somewhere.
The _gist_ of GPLv2 is share and share-alike. It's about the source code.
GPLv3 improved on v2 on many aspects, but also brought it a new front: control of the hardware. Applied to software not tightly tied to hw -- a web app -- it doesn't matter. Applied to kernels, device drivers, etc it's a massive problem. As a result, folks who work closely to hardware don't want to use it.
To be clear. I don't intend to re-hash the GPLv3 controversies here. Just to point out -- GPLv3 is different, in a meaningful way. Pick GPLv2 or GPLv3, but know they are different beasts.
Posted Sep 15, 2020 5:06 UTC (Tue)
by cyphar (subscriber, #110703)
[Link] (1 responses)
> No, that does not hold. You get the tools so can build install the executable... somewhere. Yes, GPLv2 and GPLv3 are obviously legally speaking quite different on this point. My point is that since the discussion was about "social contracts", it should be noted that the GPLv2 does have a spiritually similar requirement. If you don't see the similarity in spirit between "scripts that control the compilation and installation of the executable" and "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source", I don't really know what else to say. My point was simply that the new requirements didn't come out of nowhere.
Posted Sep 15, 2020 14:23 UTC (Tue)
by martin.langhoff (subscriber, #61417)
[Link]
Good? Bad? That was the social contract under GPLv2.
GPLv3 introduces rules about the User Product. We're trying to leverage _software_ to put rules on _hardware_. That is a new frontier, and a new social contract.
No significant/popular low-level software projects, where this matters, have adopted GPLv3. So on that front, it did not find traction.
And here's the funny thing -- I personally dislike Tivoization. If the current GPLv3 was called T(ivo)GPL, similar to what happened with AGPL, and we had a GPLv2.1, life would be much better.
Posted Sep 13, 2020 8:15 UTC (Sun)
by cyphar (subscriber, #110703)
[Link]
If you want compatibility with Apache-2.0 (which GPLv2 doesn't have), you need to have patent grants.
Posted Sep 24, 2020 3:21 UTC (Thu)
by donbarry (guest, #10485)
[Link]
Posted Sep 23, 2020 23:04 UTC (Wed)
by flussence (guest, #85566)
[Link]
…like remediating the sudden death aspect of GPLv2. The old version certainly is better if you're Patrick McHardy.
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
Wol
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
> that GPLv2 actually had a similar (in spirit) requirement
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project
OpenPGP in Rust: the Sequoia project