OpenPGP in Rust: the Sequoia project [LWN.net]

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 15:04 UTC (Sat) by Wol (subscriber, #4433)
In reply to: OpenPGP in Rust: the Sequoia project by Deleted user 129183
Parent article: OpenPGP in Rust: the Sequoia project

I wouldn't call providing patent grants an improvement ...

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,
Wol

to post comments

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 19:47 UTC (Sat) by martin.langhoff (subscriber, #61417) [Link] (4 responses)

I'm with Wol.

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.

OpenPGP in Rust: the Sequoia project

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"

OpenPGP in Rust: the Sequoia project

Posted Sep 14, 2020 21:09 UTC (Mon) by martin.langhoff (subscriber, #61417) [Link] (2 responses)

> while folks like to wax lyrical about GPLv3's tivoisation clause, many seem to forget
> that GPLv2 actually had a similar (in spirit) requirement

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.

OpenPGP in Rust: the Sequoia project

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.

OpenPGP in Rust: the Sequoia project

Posted Sep 15, 2020 14:23 UTC (Tue) by martin.langhoff (subscriber, #61417) [Link]

In GPLv2 the social contract is - share and share _code_ alike. The hardware running software was nowhere in the picture.

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.

OpenPGP in Rust: the Sequoia project

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.

OpenPGP in Rust: the Sequoia project

Posted Sep 24, 2020 3:21 UTC (Thu) by donbarry (guest, #10485) [Link]

It all depends on whether you think the point is to improve software freedom or to give firms ammunition to create fear, uncertainty, and doubt. I'm firmly in the camp of the GPLv3. It addresses problems which arose when billions of dollars of revenues were tied to new ecosystems and methods were developed by their corporate fiefs outside the spirit of the GPLv2 to control those ecosystems, and their fury that they would lose those unprincipled mechanisms back to users.