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

61–69 of 69 posts

Re: Sequoia PGP is now LGPL 2.0

#61

Post by jcelerier »

dathinab wrote: post #45
jcelerier wrote: post #22

Earlier quoted context omitted.

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

> 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. No, that is not how it works, like not at all. Rust doesn't use the same…

> You don't build stuff with `rustc` in general. (You build it with cargo.)

It doesn't matter in the slightest what you do, just that there is a documented way for someone to be able to do it, as convoluted as it may be. I should be able to patch your LGPL dependency even if I had never written a line of Rust in my life, so considerations like using the mainstream buildsystem there do not apply. A build.sh shell script is fine - I've used cmake to generate those for instance.

> Rust widely uses generics similar to C++ templates this means part of the code which is not supposed to become public will leak if the libary interface involves templates/generics.

Design your API boundaries better if you don't want that. Pimpl is often used for this.

> What is theoretically possible doesn't matter, what matters is what is practical. I.e. simple, and fast to setup and maintain.

.. no, what matters is respecting the license

> In rust (and somewhat in C) you normally don't link two "objects" to produce the final binary you build it with a number of "object" dependencies.

Sure, just ship the link line that cmake generates or whatever ? I don't understand what is so hard in that and it's more than enough to comply with LGPL.

> binary patching

I was referring of the standard process of applying a patch to the source code of a LGPL library before rebuilding it and linking it against the rest

Re: Sequoia PGP is now LGPL 2.0

#62

Post by jcelerier »

dathinab wrote: post #41
jcelerier wrote: post #9

Earlier quoted context omitted.

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

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

... You think people haven't solved this problem for literal decades in c++ ?

If your LGPL lib uses a template :

If it gets inlined the license says that it's fine and not breaking LGPL that you won't be able to change the call sites. All c++ compilers will still produce a non-inline version of the symbol with weak linkage that can be replaced in the cases where inlining did not happen. Surely rust does the same in order to comply with LD_PRELOAD semantics ? (Even MSVC does that inline symbol exporting afaik).

Like, you think people who wrote the LGPL did not consider the case of macros in C for instance ?

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

If that's such a nightmare then don't depend on the work of people who wrote LGPL libs and find an alternative instead ?

Re: Sequoia PGP is now LGPL 2.0

#63

Post by saagarjha »

legutierr wrote: post #29
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…

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

You don't even need to provide the source code; object files are acceptable too.

Re: Sequoia PGP is now LGPL 2.0

#65

Post by pornel »

robertkarljr wrote: post #11

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.

If there are any GPL apps in the App Store, it's only because Apple is terrible and inconsistent in enforcement of their own rules.

App Store developer agreement requires you to license your app to Apple on Apple's terms, including geo restrictions, max number of installs, and other things that are incompatible with GPL.

https://www.fsf.org/blogs/licensing/more-about-the-app-store... https://www.fsf.org/news/2010-05-app-store-compliance/

Re: Sequoia PGP is now LGPL 2.0

#66

Post by pornel »

cormacrelf wrote: post #10
jcelerier wrote: post #9

Earlier quoted context omitted.

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

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…

I assume requiring a very specific compiler version would still satisfy the letter of the license. The compiler is publicly available, so you could replace the LGPL part. You get no promises about being able to replace or even maintain anything else.

BTW, Rust's objects/rlibs may contain bitcode and a high-level form of generic/inlineable code, so they should be much easier to reverse/decompile than an optimized binary. If the goal was to keep the non-LGPL part closed, it won't work well.

Re: Sequoia PGP is now LGPL 2.0

#67

Post by _jal »

dathinab wrote: post #47
_jal wrote: post #20

Earlier quoted context omitted.

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.

> I don't think it matters that it is impractical. But it does matter, it practice it matters more then what is legal if we are honest. > It isn't the FSF's job to write Rust tooling Yes, but it doesn't mean that it's not a bad license for the given use-case. If it's impractical, then in practice there is not much difference to the license simply forbidding the usage (iff the company cares about what is legal). Throu…

> But it does matter, it practice it matters more then what is legal if we are honest.

To the first part, I meant simply "impracticality does not effect the legal analysis here". Of course it matters for writing code.

To the second part, "if we're honest", it doesn't matter at all, because people are going to do what they're going to do, right?

Re: Sequoia PGP is now LGPL 2.0

#68

Post by roblabla »

drran wrote: post #15
dralley wrote: post #7

Earlier quoted context omitted.

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

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?

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!

Re: Sequoia PGP is now LGPL 2.0

#69

Post by dathinab »

_jal wrote: post #67
dathinab wrote: post #47

Earlier quoted context omitted.

> I don't think it matters that it is impractical. But it does matter, it practice it matters more then what is legal if we are honest. > It isn't the FSF's job to write Rust tooling Yes, but it doesn't mean that it's not a bad license for the given use-case. If it's impractical, then in practice there is not much difference to the license simply forbidding the usage (iff the company cares about what is legal). Throu…

> But it does matter, it practice it matters more then what is legal if we are honest. To the first part, I meant simply "impracticality does not effect the legal analysis here". Of course it matters for writing code. To the second part, "if we're honest", it doesn't matter at all, because people are going to do what they're going to do, right?

Yes
Post reply on HN