Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sequoia PGP is now LGPL 2.0

sequoia-pgp.org

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Sequoia PGP is now LGPL 2.0

#51

Post by anderskaseorg »

dathinab wrote: post #43
anderskaseorg wrote: post #25

Earlier quoted context omitted.

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-so…

> available and buildable But what does buildable mean, no-one but you has access to your CI (which also might likely not be public). So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".

You can read this in the license:

> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

A good open-source (or even source-available) project will include all the necessary build scripts and instructions needed for rebuilding it anyway, and it will be portable enough that this process isn’t tied down to a non-public CI environment.

If you’re asking exactly how much of this you can legally get away with omitting from a project using an LGPL library, then (a) you’re clearly not interested in providing a good open-source project, and (b) you should probably consult a lawyer rather than looking for free armchair legal advice from the community that you’re trying to avoid contributing to.

Re: Sequoia PGP is now LGPL 2.0

#52

Post by mastax »

dralley wrote: post #3

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 agai…

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.

Re: Sequoia PGP is now LGPL 2.0

#54

Post by rStar »

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.

Re: Sequoia PGP is now LGPL 2.0

#55

Post by jcelerier »

dathinab wrote: post #43
anderskaseorg wrote: post #25

Earlier quoted context omitted.

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-so…

> available and buildable But what does buildable mean, no-one but you has access to your CI (which also might likely not be public). So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".

Entirely outside of the licensing debate, if your project only builds on a specific CI that's a huge engineering red flag I'd say

Re: Sequoia PGP is now LGPL 2.0

#57

Post by jcelerier »

jcranmer wrote: post #36
jcelerier wrote: post #33

Earlier quoted context omitted.

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

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).

... how is that not equivalent ? ar is just tar with less features. At worse extract the .o's from the .a beforehand if that causes issues but I'd really like to know where this differs

Re: Sequoia PGP is now LGPL 2.0

#58

Post by lmm »

dathinab wrote: post #43
anderskaseorg wrote: post #25

Earlier quoted context omitted.

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-so…

> available and buildable But what does buildable mean, no-one but you has access to your CI (which also might likely not be public). So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".

The license text just requires that the user "can" do it: "Accompany the work... with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library." Interpreting that is a question for the court; I would speculate that manual instructions are probably good enough as long as you provide instructions that actually work.

Re: Sequoia PGP is now LGPL 2.0

#59

Post by jcelerier »

tzs wrote: post #38
jcelerier wrote: post #28

Earlier quoted context omitted.

yep, here's a list of GPL apps on iOS: https://en.wikipedia.org/wiki/List_of_free_and_open-source_i...

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 p…

> The issue with GPL on the iOS store arises when you put someone else's GPL code in your iOS app.

If that were true, Cisco wouldn't be shipping iOS apps with LGPL code from GStreamer in it.

> These restriction are at odds with the GPL requirement that you not place additional restrictions on GPL software you distribute.

No, the GPL wording is that any additional restriction can be ignored by the end-user.

Quoting:

> If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

Re: Sequoia PGP is now LGPL 2.0

#60

Post by thaumasiotes »

lmm wrote: post #58
dathinab wrote: post #43

Earlier quoted context omitted.

> available and buildable But what does buildable mean, no-one but you has access to your CI (which also might likely not be public). So do you need to provide another CI, a make-file you maintain additionally, etc.? Or is it good enough so that someone could run "the right CLI commands to build and link the project".

The license text just requires that the user "can" do it: "Accompany the work... with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library." Interpreting that is a question for the court; I would speculate that manual instructions are probably good enough a…

> I would speculate that manual instructions are probably good enough as long as you provide instructions that actually work.

Well, as long as the instructions rely only on things to which the user has access. If you document your internal build system beautifully, and nobody else is allowed to use it, that would not seem to pass muster.

Post reply on HN