[HN Gopher] Sequoia PGP is now LGPL 2.0
___________________________________________________________________
Sequoia PGP is now LGPL 2.0
Author : nwalfield
Score : 82 points
Date : 2021-10-18 15:00 UTC (8 hours ago)
(HTM) web link (sequoia-pgp.org)
(TXT) w3m dump (sequoia-pgp.org)
| robertkarljr wrote:
| 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 wrote:
| yep, here's a list of GPL apps on iOS:
| https://en.wikipedia.org/wiki/List_of_free_and_open-source_i...
| neatze wrote:
| moreover, LGPL makes it even worse for using library with app
| stores.
| encryptluks2 wrote:
| Is Sequoia PGP a drop in replacement for GPG? How do I go about
| integrating with Git and what not?
| tristan957 wrote:
| 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...
| lapinot wrote:
| 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).
| dralley wrote:
| 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
| greyw wrote:
| You can static link your program and release your it under the
| GPL license. I don't see the problem there.
| roblabla wrote:
| 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
| arp242 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Rust's support for dynamic linking is entirely unrelated
| to how much of a pain LGPL makes static linking.
| mike_hock wrote:
| But it's entirely related to how much of a pain Rust
| makes dynamic linking.
| baybal2 wrote:
| > which seems incredibly problematic to manage with the Rust
| toolchain.
|
| I think this is very well intentional
| tristan957 wrote:
| Why would they write it in Rust if they somehow want to
| disadvantage Rust?
| [deleted]
| legutierr wrote:
| 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.
| cormacrelf wrote:
| 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/
| jcelerier wrote:
| 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#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.
| cormacrelf wrote:
| The parent comment literally posted the same link. I am
| aware of the replacement concept and how it is technically
| distinct from an outright ban on static linking.
|
| > That's possible with static linking, that's possible with
| other languages than the ones relying on a linker step,
| etc.
|
| We are talking about Rust, not languages other than Rust.
| Could you walk us through how you would offer a Rust binary
| with a statically linked LGPL Rust crate that is
| replaceable according to the license requirements (v2.0,
| 2.1, 3.0, pick your poison), without also releasing the
| binary's source code? I think it's technically possible,
| but how would you do it? * Edit: keep in mind that .rlib
| files are not stable across compiler versions. AFAIK very
| little about the target/ folder is stable at all, except
| the final product location.
| _jal wrote:
| I don't think it matters that it is impractical. It isn't
| the FSF's job to write Rust tooling, it is to write
| licenses.
|
| I do agree that that the concern is becoming much more
| orthogonal both to the FSF's goals and to the way
| software is built. But that doesn't change the fact that
| the license works the way it does, nor does it let you
| insert the words 'dynamic linking' in it.
| cormacrelf wrote:
| At no point did I suggest it requires dynamic linking.
| Again, I understand how the license works. I'm talking
| about why you would choose it if it were this difficult
| for someone to use your technology.
|
| In many projects, ensuring the freedom to replace a copy
| of the library just isn't worth all this trouble. If I
| make my code LGPL, I'm mostly shifting that burden onto
| other people who want to use it, not myself, and so there
| are presumably very few LGPL authors who are actually
| motivated to fix all these problems for someone else.
| Further, most corps will simply not use the LGPL
| software, because difficulty looks like license trouble.
| In that sense, this does look a bit like a job for the
| FSF, to be honest. At this rate, LGPL use will die out,
| and not in favour of GPL.
|
| In another sense, a proprietary product choosing to embed
| my component would be a massive victory for the ecosystem
| it is built to support. I think that is also true for
| Sequoia. I just straight up don't care about the ability
| to replace my component within another proprietary
| program. If they are using it at all, they will
| presumably update it themselves, it would be a pretty
| central dependency; if they don't want to, they can just
| build their own version. I'm just hoping to get anyone to
| pull the trigger and drop their commercial alternative in
| favour of the open standard my component implements. So
| is Sequoia; their livelihood depends on it. Will they
| hack on rustc to make it easier to use? Somehow I think
| they will not! This makes no sense to me.
|
| A lot of open source today cares less about LGPL-style
| replaceability and more about adoption of an open
| standard that is separate from the code itself. In this
| case it's PGP-compatible encryption and signing, which
| has famously never really taken off and by some odd
| coincidence never had a project of Sequoia's quality with
| e.g. a BSD-style license that you could simply slap in a
| project and depend on. (Although much of the blame
| deservedly goes to GPG providing over a hundred intricate
| and one must presume deliberately hard-to-reproduce
| APIs.) In Kubernetes-land, the concept of being
| k8s-compatible and interoperable is arguably responsible
| for more freedom than the core software itself. This is
| simply true of so many things, and further you must
| admit: Sequoia as code is 100% replaceable by a motivated
| corporation, if only there were more demand for being
| compatible with PGP. If you're still thinking in 2021
| that if PGP were in demand the only reason Amazon would
| be shipping software without a user-serviceable Sequoia
| package is the LGPL, you haven't seen how many hundreds
| of thousands of dev job ads they posted in the last
| month. Adoption of the open standard is just more
| important than anyone's actual code, up until the
| codebase is so big it would be prohibitively difficult to
| replicate. If you think your code in particular is
| special, maybe you're right, or maybe it's just the rare
| piece of software whose existence is not entirely
| justified by an open standard.
| _jal wrote:
| > A lot of open source today cares [...] about adoption
| of an open standard that is separate from the code
| itself.
|
| No arguments from me! I absolutely agree with this.
|
| > I just straight up don't care about the ability to
| replace my component
|
| I get it. And I agree that the LGPL is increasingly
| shaped wrong for a lot of this.
|
| I'll go further and assert that software economics have
| changed enough that a lot of the GPL's goals deserve
| another look. I don't think tomorrow's software freedom
| battles will look like yesterday's.
|
| I was really only commenting on the fact that a lot of
| folks seem to erroneously believe that because there's no
| tool to do something, or that doing something is
| technically nonsensical, the license must say something
| other than what it does.
| cxr wrote:
| It would work the same way that it works for programs
| written in languages that aren't Rust. You're doing the
| classic thing where you're conflating a language with a
| given implementation.
|
| The free software advocate's take: You say the toolchain
| from rust-lang.org makes this difficult? Granted--I'll
| take your word for it. Go fix that toolchain. (And as a
| side note, the fact that rust-lang.org chose LLVM is
| likely to do the opposite of cultivating sympathy.) It's
| a lot like the saying that goes something like, "poor
| planning on your end does not automatically make for an
| emergency on my end."
| dralley wrote:
| To be clear, I'm not saying that the FSF has written a
| poor license. It's a fine license for many libraries,
| especially at the time it was written.
|
| I'm saying it's a poor choice for a brand new library
| written in a language where the vast majority of the
| ecosystem utilizes static linking.
| cormacrelf wrote:
| There's a case to be made that Sequoia or another LGPL
| user should also invest in making it easier to comply
| with the LGPL with Rust tooling. But I doubt that will
| happen anytime soon.
| [deleted]
| jcelerier wrote:
| > Could you walk us through how you would offer a Rust
| binary with a statically linked LGPL Rust crate that is
| replaceable according to the license requirements (v2.0,
| 2.1, 3.0, pick your poison), without also releasing the
| binary's source code?
|
| I see that rustc has a "--emit obj" option, from there
| surely any decent build system would allow enough
| customization to do what you want but there's enough raw
| capability to write a user guide that says "build your
| stuff with rustc --emit obj lgpl_lib_1.rs -o lgpl_lib_1.o
| and link with our proprietary .o with lld" ; and you'd be
| good to go.
|
| > * Edit: keep in mind that .rlib files are not stable
| across compiler versions.
|
| sure, that's not an issue, just say that you used
| compiler version x.y ? the LGPL does not require that
| things work with any compiler version, only that there is
| a way to patch / rebuild the LGPL parts. e.g. if I ship a
| C++20 proprietary library with C++20-specific types in
| the API which interoperates with a C++20 LGPL lib, of
| course things won't work with GCC 2.95 and everyone will
| be fine with that.
| jcranmer wrote:
| While it's true that the LGPL doesn't specifically require
| dynamic linking, it requires something that is effectively
| dynamic linking. The way you'd have to do static linking
| isn't something that is easy to set up in most build
| systems, and deprives you of the ability to do certain
| post-build steps (such as signing the build) or certain
| build options (LTO) without some pain.
| jcelerier wrote:
| > The way you'd have to do static linking isn't something
| that is easy to set up in most build systems,
|
| it's trivial in CMake which is the most used buildsystem
| in languages with a linker, just set
| -DBUILD_SHARED_LIBS=0 on the command line
|
| > and deprives you of the ability to do certain post-
| build steps (such as signing the build)
|
| why would it ? I build my app as a set of static libs
| linked together in the end and there's no trouble signing
| it... and it does not make sense for people who will
| build their own custom version of your app to sign it.
|
| here's a guide inspired by instructions given by Cisco to
| rebuild one of their proprietary apps for instance on
| iOS:
|
| https://github.com/freedesktop/gstreamer/blob/master/READ
| ME....
| jcranmer wrote:
| > it's trivial in CMake which is the most used
| buildsystem in languages with a linker, just set
| -DBUILD_SHARED_LIBS=0 on the command line
|
| Building or using static libraries isn't hard. Doing so
| in a way that doesn't violate the LGPL's replacement
| requirement is. The document you yourself linked says
| this about developing statically-linked libraries with
| the GPL:
|
| > 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.
|
| If you're distributing an object format, you need a .o
| that could be linked with the user's custom version of
| the LGPLed library. Building such a .o file cannot be
| done easily with tools, and that is what I'm referring
| to.
| jcelerier wrote:
| I don't understand, if you can build your app statically
| then you have the .o ; a static library libfoo.a is just
| an archive of .o files that pretty much any Unix system
| can extract
| jcranmer wrote:
| The final link line in a build system for an application
| is generally `cc -o app file1.o file2.o file3.o ...
| -llib1 -lib2 -llib3`. Turning that link line into one
| that produces an app.o that can be combined with
| liblgpllib.a to produce an equivalent app file is
| nontrivial. (And before you say just add all the .o files
| into a single .a file, no, that is not equivalent.
| Because Unix linking sucks).
| anderskaseorg wrote:
| If the source code for your application is available and
| buildable, that satisfies the LGPL's definition of
| "Corresponding Application Code", regardless of how it's
| linked. You don't need the object code if you have the
| source code; you can replace the library by rebuilding
| the application.
|
| So this is only an inconvenience for proprietary closed-
| source applications. Making the library conveniently
| usable by closed-source applications is outside the
| stated objective in the blog post.
___________________________________________________________________
(page generated 2021-10-18 23:01 UTC)