9 ms·

Sequoia PGP is now LGPL 2.0

113 points by nwalfield 5y ago

dralley 5y ago
I know that a few years ago there was some discussion about which license to choose, with LGPL and MPLv2 being two strong contenders, and it was noted (by Neal himself actually) that MPLv2 is much easier to use when static linking (as is the norm in the Rust community). Why was LGPL chosen instead? The LGPL requires that all applications that consume it as a static library provide the tools to re-link the binary against modified forms [0], which seems incredibly problematic to manage with the Rust toolchain. I like the idea behind the LGPL conceptually, but in practice the LGPL is strongly tied to the way Linux applications and libraries were developed in the 90s and 2000s - namely, in C, with dependencies that are generally dynamically linked, with C-like toolchains that directly expose all of the intermediate object files. It just doesn't make a whole lot of sense for any software outside of that bubble. [0] www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
- roblabla 5y ago
  SequoiaPGP provides a C FFI interface, which can be dynamically linked against from any C-compatible language. Though safe wrappers would have to be written around that to be able to use it from Rust, which is kind of going full circle. It'd be interesting if a Rust FFI interface could be defined (using abi_stable[0] or something). [0]: https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable
  - arp242 5y ago
    I believe git just uses the gpg commandline; in a quick grep of the source I don't see it use any GnuPG includes/functions at all (and gpg-interface.c just runs pipe_command()), but maybe I missed it.
  - dralley 5y ago
    That's great, but it's a Rust library, which would be nice to use from Rust, without going through a C FFI layer for the sole purpose of license compliance. It feels like the Rust ecosystem is a second class citizen due to this license. The GPL or MPL would at least enforce the same rules for everyone, but the LGPL gives a relative advantage to the C and C++ ecosystem over the Rust ecosystem in terms of actually using the library.
    - drran 5y ago
      Static linking good for vendor, dynamic linking good for maintainers. Some distros already made exception from "no bundled libraries" rule for Rust. Now we need to add another exception just for Rust. Maybe, it's time for Rust to catch up and implement dynamic linking instead?
      - dralley 5y ago
        Rust's support for dynamic linking is entirely unrelated to how much of a pain LGPL makes static linking.
        mike_hock 5y ago
        But it's entirely related to how much of a pain Rust makes dynamic linking.
      - roblabla 5y ago
        Rust does support dynamic linking. But it suffers from the same issues C++ does: Code using generics will get inlined into your final binary, the ABI is unstable so you need to make sure you use the same compiler version, etc... All those can technically be worked around, but it's more work for the maintainer. Dynamic linking is actually worse for the maintainer here, as it force them to have a stable ABI, which is a lot of work!
- cormacrelf 5y ago
  Quite right. I contribute a Rust component to a larger AGPL-3.0 project and went with MPL-2.0 over LGPL for this reason. A bit off-topic, but I wonder if the FSF's ideas about dynamic linking have been litigated yet. It has always seemed a pretty suspicious to me that a dynamically linked program, existing only in volatile memory, could really be a copyright work at all, let alone a derivative one. I found this LWN article that touches on this question[0] and links to some more discussion, which I will have to look into. [0]: https://lwn.net/Articles/548216/ https://lwn.net/Articles/548216/
  - Avshalom 5y ago
    https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Computer,_Inc https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Comp.... would suggest that a program that exists in volatile memory does count for copyright purposes.
  - jcelerier 5y ago
    To think that I had entertained the thought for 6 months or so that I had did it enough a d would not have to post this link again: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn... The LGPL text does not require dynamic linking. It's FUD. What the LGPL requires is that the LGPL part can be replaced. That's possible with static linking, that's possible with other languages than the ones relying on a linker step, etc.
    - dathinab 5y ago
      > That's possible with static linking, Yes, but in practice it tend to not matter. > (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. Now to get the "oh C objects" thing out of the way, GPLv3 defines: > “Object code” means any non-source form of a work. Still this means what you need is to distribute you application in a partial compiled state which can be relinked with the LGPL library (or a updated version) to re-produce the final application. (You also might need to provide the tools to do so if they are not freely available.) Also let's not forgot the context, i.e. you don't want (or can't) provide the source code of the "main application" which links against the LGPL library. Now if you program in C, providing a (set-of) pre-compiled pre-symbol stripped objects is feasible. But most (new) programs are not in C anymore and most new languages do not have clear ABI boundaries at library level. Only clear API boundaries. A good example are generics or template programming. E.g. even in C++ if there is heavy use of template programming around the library boundary can make LGP infeasible for that use case. And we are still in C++ which is rather close to C in how it compiles stuff. If we go a step further, e.g. into Rust it becomes even more of a mess. (It is possible, at least theoretically, with a lot of hacks and restrictions, but totally a nightmare not worth even considering. And again if generics are used a lot, all the generic code at the interface boundary leaks.) Then there is the additional complexity this introduces to CI. So possible yes, but for many projects not worth considering. > What the LGPL requires is that the LGPL part can be replaced. Not quite, they require you to provide intermediates which can be re-linked with a alternate version of the library. Which means if you want to e.g. provide the functionality through binary patching it gets tricky, because you need to provide a binary without the LGPled library (1) which you then can "patch" the library into. Instead of being able to provide a binary with the LGPled library in it and allowing you to replace/update it. Which means various approaches around binary patching just became way more complex. (1): The reason for it is that the object you provide falls itself under license terms. So ya, no dynamic linking requirement. But for some modern languages still a major problem. And conceptually too closely bound to the concept of the C-compilation process IMHO.
- greyw 5y ago
  You can static link your program and release your it under the GPL license. I don't see the problem there.
- baybal2 5y ago
  > which seems incredibly problematic to manage with the Rust toolchain. I think this is very well intentional
  - tristan957 5y ago
    Why would they write it in Rust if they somehow want to disadvantage Rust?
    - deleted 5y ago
      [deleted]
    - baybal2 5y ago
      To make a point
- legutierr 5y ago
  You don’t need to provide special tooling, you only have to provide the source code of your own program so that the program can be recompiled with a different version of the LGPL-licensed library. Your source code can be released under another license, even a proprietary license, provided that the user can physically undertake the necessary steps to produce a new executable that interoperates with an updated or modified version of the LGPL-licensed package. The idea is that the LGPL-licensed portion of the final runtime program should itself be open source in the sense of being modifiable in a useful way by the end user.
  - saagarjha 5y ago
    You don't even need to provide the source code; object files are acceptable too.
- mastax 5y ago
  Programs using Sequoia which are not written in Rust will be using the C-API, which should be easy to dynamically link (or statically re-link). Programs using the Sequoia Rust API are very likely to be source available, which satisfies the LGPL requirement. Programs using the Sequoia Rust API which are not distributed do not need to do anything to comply with the LGPL. Only proprietary Rust programs which are distributed to users need to really care. They can spend the modicum of effort to wrap the C-API. If it were up to me, though, I'd choose MPLv2.
encryptluks2 5y ago
Is Sequoia PGP a drop in replacement for GPG? How do I go about integrating with Git and what not?
- tristan957 5y ago
  There is a gpg program config key for Git[0], but beyond that I am not sure what else would need to be done. I am sure a blog post describing your experience would be well-received. [0]: https://git-scm.com/docs/git-config#Documentation/git-config.txt-gpgprogram https://git-scm.com/docs/git-config#Documentation/git-config...
- lapinot 5y ago
  tldr: not yet I tried a bit (i'm only using gpg for my pass keyring, but as pass is dead simple i wanted to write a clone and hack around sequoia), but i found the command-line interface to be missing some features. As a showstopper it doesn't seem to allow on-the-fly decryption of secret keys to sign/encrypt stuff (at least i didn't get it to work). Also, there are very few options for editing secret keys (subkeys, managing certifications). Keyrings are amusingly barebone: they are just concatenated keys (as armored ascii), seems to do the job. I'm confident this will improve in the matter of a handful of months tho. I didn't check but i'd bet this is mostly a problem of writing the front-end cli code to advertise all the library features. They seem to be pretty active, 1.0 on the lib was cut not so long ago and 'sq' (the executable) is still pre 1.0. Other execs are sqv (verifier) and sqop ("stateless command interface", seems to be oriented at scripting, apparently aiming to drive interop between implementations).
robertkarljr 5y ago
From the article: > Delta Chat planned an iOS app, but because Apple does not allow GPL software in their App store, the Delta Chat developers couldn’t use Sequoia. I don't think this is true in theory or in practice, for the iOS App store or the Mac App Store. Take the WordPress app for example.
- jcelerier 5y ago
  yep, here's a list of GPL apps on iOS: https://en.wikipedia.org/wiki/List_of_free_and_open-source_iOS_applications https://en.wikipedia.org/wiki/List_of_free_and_open-source_i...
  - neatze 5y ago
    moreover, LGPL makes it even worse for using library with app stores.
  - yepguy 5y ago
    My understanding is that Apple's terms of service are incompatible with the GPL. If you hold the copyright yourself though, you have no need to abide by the license and can distribute it on the App Store under different terms.
  - tzs 5y ago
    I took a brief look at a few of those and it looked like they either only included code that they owned the copyright to or that was under a more permissive license than GPL. Putting your own GPL code in your iOS app is fine. The issue with GPL on the iOS store arises when you put someone else's GPL code in your iOS app. The problem is that that the terms of use that the user must agree to in order to use the store place restrictions on what the user can do with the software they obtain through the store. These restriction are at odds with the GPL requirement that you not place additional restrictions on GPL software you distribute. For Apple to distribute GPLed software on the Apple store, the copyright holder has to give them permission to do so on terms other than GPL. In the case where the developer who places the GPL app on the store is the copyright holder to the entire app this is no problem. They have had to agree to Apple's terms for developers in order to be allowed to upload. I've forgotten what exactly is in those terms, but I'm almost certain there is something in there that requires the developer to give Apple permission to distribute. That permission that a developer of a GPLed app (or an app under any other license) gives to Apple to make and distribute copies only applies to code owned by that developer. If they have included any third party GPL code from owners who have not granted Apple that permission, then the app as a whole will not be legal for Apple to distribute. In summary, distributing on the Apple app store requires that you give Apple a license to make and distribute copies under Apple's terms, which are not GPL compatible. Apple does not care what license you give to anyone else, so it is fine to go with "GPL for everyone plus this special license for Apple".
fire 5y ago
Is there an easy to consume explanation of why one would want to use Sequoia as an alternative?
hda2 5y ago
This is an excellent UVP to have over GnuPG. I'll probably end up using sequoia for my app for this reason alone (amusing it's dependency graph is manageable). Curious as to why LGPLv3 wasn't chosen though.
deleted 5y ago
[deleted]
rStar 5y ago
i’ve still not seen a good reason for going to a “more permissive” license for “pragmatic” reasons, when the language being cast off is the gpl, 2, 2+, 3, you choose. not many good results either.

113 points by nwalfield 5y ago

I know that a few years ago there was some discussion about which license to choose, with LGPL and MPLv2 being two strong contenders, and it was noted (by Neal himself actually) that MPLv2 is much easier to use when static linking (as is the norm in the Rust community). Why was LGPL chosen instead? The LGPL requires that all applications that consume it as a static library provide the tools to re-link the binary against modified forms [0], which seems incredibly problematic to manage with the Rust toolchain. I like the idea behind the LGPL conceptually, but in practice the LGPL is strongly tied to the way Linux applications and libraries were developed in the 90s and 2000s - namely, in C, with dependencies that are generally dynamically linked, with C-like toolchains that directly expose all of the intermediate object files. It just doesn't make a whole lot of sense for any software outside of that bubble. [0] www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

roblabla 5y ago
SequoiaPGP provides a C FFI interface, which can be dynamically linked against from any C-compatible language. Though safe wrappers would have to be written around that to be able to use it from Rust, which is kind of going full circle. It'd be interesting if a Rust FFI interface could be defined (using abi_stable[0] or something). [0]: https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable
- arp242 5y ago
  I believe git just uses the gpg commandline; in a quick grep of the source I don't see it use any GnuPG includes/functions at all (and gpg-interface.c just runs pipe_command()), but maybe I missed it.
- dralley 5y ago
  That's great, but it's a Rust library, which would be nice to use from Rust, without going through a C FFI layer for the sole purpose of license compliance. It feels like the Rust ecosystem is a second class citizen due to this license. The GPL or MPL would at least enforce the same rules for everyone, but the LGPL gives a relative advantage to the C and C++ ecosystem over the Rust ecosystem in terms of actually using the library.
  - drran 5y ago
    Static linking good for vendor, dynamic linking good for maintainers. Some distros already made exception from "no bundled libraries" rule for Rust. Now we need to add another exception just for Rust. Maybe, it's time for Rust to catch up and implement dynamic linking instead?
    - dralley 5y ago
      Rust's support for dynamic linking is entirely unrelated to how much of a pain LGPL makes static linking.
      - mike_hock 5y ago
        But it's entirely related to how much of a pain Rust makes dynamic linking.
    - roblabla 5y ago
      Rust does support dynamic linking. But it suffers from the same issues C++ does: Code using generics will get inlined into your final binary, the ABI is unstable so you need to make sure you use the same compiler version, etc... All those can technically be worked around, but it's more work for the maintainer. Dynamic linking is actually worse for the maintainer here, as it force them to have a stable ABI, which is a lot of work!
cormacrelf 5y ago
Quite right. I contribute a Rust component to a larger AGPL-3.0 project and went with MPL-2.0 over LGPL for this reason. A bit off-topic, but I wonder if the FSF's ideas about dynamic linking have been litigated yet. It has always seemed a pretty suspicious to me that a dynamically linked program, existing only in volatile memory, could really be a copyright work at all, let alone a derivative one. I found this LWN article that touches on this question[0] and links to some more discussion, which I will have to look into. [0]: https://lwn.net/Articles/548216/ https://lwn.net/Articles/548216/
- Avshalom 5y ago
  https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Computer,_Inc https://en.wikipedia.org/wiki/MAI_Systems_Corp._v._Peak_Comp.... would suggest that a program that exists in volatile memory does count for copyright purposes.
- jcelerier 5y ago
  To think that I had entertained the thought for 6 months or so that I had did it enough a d would not have to post this link again: https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn... The LGPL text does not require dynamic linking. It's FUD. What the LGPL requires is that the LGPL part can be replaced. That's possible with static linking, that's possible with other languages than the ones relying on a linker step, etc.
  - dathinab 5y ago
    > That's possible with static linking, Yes, but in practice it tend to not matter. > (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. Now to get the "oh C objects" thing out of the way, GPLv3 defines: > “Object code” means any non-source form of a work. Still this means what you need is to distribute you application in a partial compiled state which can be relinked with the LGPL library (or a updated version) to re-produce the final application. (You also might need to provide the tools to do so if they are not freely available.) Also let's not forgot the context, i.e. you don't want (or can't) provide the source code of the "main application" which links against the LGPL library. Now if you program in C, providing a (set-of) pre-compiled pre-symbol stripped objects is feasible. But most (new) programs are not in C anymore and most new languages do not have clear ABI boundaries at library level. Only clear API boundaries. A good example are generics or template programming. E.g. even in C++ if there is heavy use of template programming around the library boundary can make LGP infeasible for that use case. And we are still in C++ which is rather close to C in how it compiles stuff. If we go a step further, e.g. into Rust it becomes even more of a mess. (It is possible, at least theoretically, with a lot of hacks and restrictions, but totally a nightmare not worth even considering. And again if generics are used a lot, all the generic code at the interface boundary leaks.) Then there is the additional complexity this introduces to CI. So possible yes, but for many projects not worth considering. > What the LGPL requires is that the LGPL part can be replaced. Not quite, they require you to provide intermediates which can be re-linked with a alternate version of the library. Which means if you want to e.g. provide the functionality through binary patching it gets tricky, because you need to provide a binary without the LGPled library (1) which you then can "patch" the library into. Instead of being able to provide a binary with the LGPled library in it and allowing you to replace/update it. Which means various approaches around binary patching just became way more complex. (1): The reason for it is that the object you provide falls itself under license terms. So ya, no dynamic linking requirement. But for some modern languages still a major problem. And conceptually too closely bound to the concept of the C-compilation process IMHO.
greyw 5y ago
You can static link your program and release your it under the GPL license. I don't see the problem there.
baybal2 5y ago
> which seems incredibly problematic to manage with the Rust toolchain. I think this is very well intentional
- tristan957 5y ago
  Why would they write it in Rust if they somehow want to disadvantage Rust?
  - deleted 5y ago
    [deleted]
  - baybal2 5y ago
    To make a point
legutierr 5y ago
You don’t need to provide special tooling, you only have to provide the source code of your own program so that the program can be recompiled with a different version of the LGPL-licensed library. Your source code can be released under another license, even a proprietary license, provided that the user can physically undertake the necessary steps to produce a new executable that interoperates with an updated or modified version of the LGPL-licensed package. The idea is that the LGPL-licensed portion of the final runtime program should itself be open source in the sense of being modifiable in a useful way by the end user.
- saagarjha 5y ago
  You don't even need to provide the source code; object files are acceptable too.
mastax 5y ago
Programs using Sequoia which are not written in Rust will be using the C-API, which should be easy to dynamically link (or statically re-link). Programs using the Sequoia Rust API are very likely to be source available, which satisfies the LGPL requirement. Programs using the Sequoia Rust API which are not distributed do not need to do anything to comply with the LGPL. Only proprietary Rust programs which are distributed to users need to really care. They can spend the modicum of effort to wrap the C-API. If it were up to me, though, I'd choose MPLv2.

encryptluks2 5y ago

Is Sequoia PGP a drop in replacement for GPG? How do I go about integrating with Git and what not?

tristan957 5y ago
There is a gpg program config key for Git[0], but beyond that I am not sure what else would need to be done. I am sure a blog post describing your experience would be well-received. [0]: https://git-scm.com/docs/git-config#Documentation/git-config.txt-gpgprogram https://git-scm.com/docs/git-config#Documentation/git-config...
lapinot 5y ago
tldr: not yet I tried a bit (i'm only using gpg for my pass keyring, but as pass is dead simple i wanted to write a clone and hack around sequoia), but i found the command-line interface to be missing some features. As a showstopper it doesn't seem to allow on-the-fly decryption of secret keys to sign/encrypt stuff (at least i didn't get it to work). Also, there are very few options for editing secret keys (subkeys, managing certifications). Keyrings are amusingly barebone: they are just concatenated keys (as armored ascii), seems to do the job. I'm confident this will improve in the matter of a handful of months tho. I didn't check but i'd bet this is mostly a problem of writing the front-end cli code to advertise all the library features. They seem to be pretty active, 1.0 on the lib was cut not so long ago and 'sq' (the executable) is still pre 1.0. Other execs are sqv (verifier) and sqop ("stateless command interface", seems to be oriented at scripting, apparently aiming to drive interop between implementations).

robertkarljr 5y ago

From the article: > Delta Chat planned an iOS app, but because Apple does not allow GPL software in their App store, the Delta Chat developers couldn’t use Sequoia. I don't think this is true in theory or in practice, for the iOS App store or the Mac App Store. Take the WordPress app for example.

jcelerier 5y ago
yep, here's a list of GPL apps on iOS: https://en.wikipedia.org/wiki/List_of_free_and_open-source_iOS_applications https://en.wikipedia.org/wiki/List_of_free_and_open-source_i...
- neatze 5y ago
  moreover, LGPL makes it even worse for using library with app stores.
- yepguy 5y ago
  My understanding is that Apple's terms of service are incompatible with the GPL. If you hold the copyright yourself though, you have no need to abide by the license and can distribute it on the App Store under different terms.
- tzs 5y ago
  I took a brief look at a few of those and it looked like they either only included code that they owned the copyright to or that was under a more permissive license than GPL. Putting your own GPL code in your iOS app is fine. The issue with GPL on the iOS store arises when you put someone else's GPL code in your iOS app. The problem is that that the terms of use that the user must agree to in order to use the store place restrictions on what the user can do with the software they obtain through the store. These restriction are at odds with the GPL requirement that you not place additional restrictions on GPL software you distribute. For Apple to distribute GPLed software on the Apple store, the copyright holder has to give them permission to do so on terms other than GPL. In the case where the developer who places the GPL app on the store is the copyright holder to the entire app this is no problem. They have had to agree to Apple's terms for developers in order to be allowed to upload. I've forgotten what exactly is in those terms, but I'm almost certain there is something in there that requires the developer to give Apple permission to distribute. That permission that a developer of a GPLed app (or an app under any other license) gives to Apple to make and distribute copies only applies to code owned by that developer. If they have included any third party GPL code from owners who have not granted Apple that permission, then the app as a whole will not be legal for Apple to distribute. In summary, distributing on the Apple app store requires that you give Apple a license to make and distribute copies under Apple's terms, which are not GPL compatible. Apple does not care what license you give to anyone else, so it is fine to go with "GPL for everyone plus this special license for Apple".

fire 5y ago

Is there an easy to consume explanation of why one would want to use Sequoia as an alternative?

hda2 5y ago

This is an excellent UVP to have over GnuPG. I'll probably end up using sequoia for my app for this reason alone (amusing it's dependency graph is manageable). Curious as to why LGPLv3 wasn't chosen though.

deleted 5y ago

[deleted]

rStar 5y ago

i’ve still not seen a good reason for going to a “more permissive” license for “pragmatic” reasons, when the language being cast off is the gpl, 2, 2+, 3, you choose. not many good results either.