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

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 19:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
Parent article: OpenPGP in Rust: the Sequoia project

I see a problem with the iOS - they won't be able to use it, because of the GPL.

to post comments

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 19:32 UTC (Fri) by jazzy (subscriber, #132608) [Link] (16 responses)

Yes, and it will still be invoked as a command line tool by non GPLv2 projects to avoid the copyleft. Why not adopt MPL 2.0 which is copyleft per file and can be used on iOS like VLC.

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 20:43 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (14 responses)

Why not change the iOS TOS to be conflict with the GPL?

I think there are a few GPL apps on iOS (GNU Jami is the one I know of) that have been there for years, so Apple just doesn't seem to care or enforce their TOS.

So, the real question is, why did they pick GPLv2 when GPLv3 is better? They want their program embedded in tivoized devices without any legal recourse? They should upgrade their license.

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 20:44 UTC (Fri) by IanKelling (subscriber, #89418) [Link]

*not be in conflict with the GPL

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 21:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

> So, the real question is, why did they pick GPLv2 when GPLv3 is better? They want their program embedded in tivoized devices without any legal recourse? They should upgrade their license.
GPLv3 is NOT better...

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 13:29 UTC (Sat) by Deleted user 129183 (guest, #129183) [Link] (9 responses)

> GPLv3 is NOT better...

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.

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 15:04 UTC (Sat) by Wol (subscriber, #4433) [Link] (7 responses)

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

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.

OpenPGP in Rust: the Sequoia project

Posted Sep 23, 2020 23:04 UTC (Wed) by flussence (guest, #85566) [Link]

>and some other things which I’ve forgotten

…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

Posted Sep 11, 2020 21:33 UTC (Fri) by neal (subscriber, #7439) [Link] (1 responses)

We actually originally picked GPLv3+, but someone asked us to change to GPLv2+ and the request was reasonable, so we did.

OpenPGP in Rust: the Sequoia project

Posted Sep 27, 2020 17:14 UTC (Sun) by oldtomas (guest, #72579) [Link]

Now this is interesting.

I assume it was private communicaton. If not, I'd appreciate a link to that, to learn motivation and background.

OpenPGP in Rust: the Sequoia project

Posted Sep 13, 2020 13:56 UTC (Sun) by link2xt (guest, #141333) [Link]

If you need a library instead of a command line tool, there is rPGP: https://github.com/rpgp/rpgp

It is licensed under MIT/Apache 2.0, like most of the code in Rust.

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 19:48 UTC (Fri) by geofft (subscriber, #59789) [Link] (6 responses)

The copyright holders can disclaim any restrictions of the GPL that conflict with the App Store terms. For instance, Blink Shell is GPL'd and has been available on iOS for a while, relying on a waiver from the mosh developers (since mosh is also GPL'd).

OpenPGP in Rust: the Sequoia project

Posted Sep 11, 2020 19:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

The problem is that the GPL+disclaimer is basically a different license, and every contributor must agree to it.

This is not really sustainable. For example, if Apple is forced to split the Apple Store into a different company and rename it to "Pear Store", the disclaimer will become void. They'll have to get agreement for a new exception from every copyright holder who has ever contributed to the core code.

I actually won't mind a lawyer-proofed GPL exception to allow distribution through app stores, but that won't allow abuse ("my application is a store, so I can distribute GPL-ed app through it!").

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 15:40 UTC (Sat) by rvolgers (guest, #63218) [Link] (1 responses)

That's not a problem in this case since contributors are required to assign copyright to the foundation, who can relicense with exceptions as needed, if I understand correctly.

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 18:57 UTC (Sat) by Wol (subscriber, #4433) [Link]

But it means that OpenPGP becomes a "code donor" project only - they cannot re-use code from other projects because they need to reach out to the copyright holder - the code hasn't been submitted to the project.

That's the problem with any extension to the GPL - you can't take advantage of other GPL code to include in your own project.

Cheers,
Wol

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 18:51 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

> I actually won't mind a lawyer-proofed GPL exception to allow distribution through app stores, but that won't allow abuse ("my application is a store, so I can distribute GPL-ed app through it!").

Just say "it is acceptable to distribute binaries on a binary-only site, provided the download points the user to the corresponding source on a 3rd-party source distribution site (3rd party as in "not yours, not the app-store"). Note that the GPLv3 permits separate distribution of binary and source without triggering the "binary-only means you must offer source for 3 years" clause. (That was a bug in v2, which at least some people would love to have seen make its way into v3). It's a bug because it means the actions of the recipient change the liability of the provider.

Cheers,
Wol

OpenPGP in Rust: the Sequoia project

Posted Sep 13, 2020 12:53 UTC (Sun) by ballombe (subscriber, #9523) [Link] (1 responses)

Do not bother. Just include a copy of the source in the binary package!

OpenPGP in Rust: the Sequoia project

Posted Sep 23, 2020 23:54 UTC (Wed) by Wol (subscriber, #4433) [Link]

And if your customer is on a metered connection they won't thank you ...

Cheers,
Wol