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
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.
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.
Law is (in my understanding) normally based on concepts not technical implementation details.
As such for me the idea that there is a difference legal between static linking, dynamic linking or "linking together by a unix-pipe" sounds strange and irritating.
Instead I would argue weather or not something is a derivative of something else should depend on the conceptual usage of that thing, not some technical implementation detail.
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.
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.
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.
I think this is very well intentional
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.
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".
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/
[0]: https://git-scm.com/docs/git-config#Documentation/git-config...
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).
Curious as to why LGPLv3 wasn't chosen though.
