Hello,
a short question about licences.
I heard, for the MIT-Licence and the Apache 2.0 Licence, that when someone compiles a new complete binary, without sourcecode, he don't must deliver the sourcecode and he don't must give a link to the origin author? Is that right?
Should i use GPL or LGPL when i want to upload my sourcecode?
Can you describe your high level goals with respect to licensing?
If we know better what you desire we can give better (non-legal) advice.
I recommend this site for information on different licences: https://tldrlegal.com/
For instance this is the Apache licence:
Apache License 2.0 (Apache-2.0) Explained in Plain English - TLDRLegal
This is the MIT licence:
This is the GPL:
The big differences in these licences is in the MUST column on the right.
You can do what you want with the source code that you write. It belongs to you.
Most Rust crates use both MIT and Apache. I prefer the GPL but I use MIT and Apache when I write Rust because that fits better with the rest of the community.
Did a write-up, as a lookup reference for licensing related discussion with developers and users.
[Slightly off-topic] Amazon's attitude towards Open Source
@Centril Hello, no big projects only my fifty cents for some problems:). Now is the time where i have broken some knots and can begin leave old trash from other coding language and go straight with rust.
@newbie101 Thx for the Links, after reading i think the GPL is the best for my little needs. And so i understand it i can combine a GPL-licenced project with MIT/Apache2.0 licenced code.
@prataprc Very cool write-up, thx. Good to know.
Another background for my question is the tree of crate-bindings in other crates that i use, there are some mixed mit, apache and unlicence. Now i know that is no problem when i use gpl for my projects thx.
This doesn't appear to discuss Rust-specific issues. The Rust-specific issue is that the instability of Rust's ABI and the compiler intentionally injecting hashes into name mangling makes complying with the LGPL relinking clause impractical. Therefore, as applied to Rust crates, LGPL becomes equivalent to GPL in practice, so unless the linkage boundary uses C linkage (FFI), it's probably best to avoid LGPL for Rust code and to either round to MPL2 or GPL depending on intent.
@hsivonen will surely add rust specific sections sooner or later.
Meanwhile, I don't understand how,
injecting hashes into name mangling makes complying with the LGPL relinking clause impractical.
Injecting hashes, does it make the caller a derivative work ?
This article says:
The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs.
subsequently,
In most cases we shouldn't care how the linkage between separate programs was technically done, unless that fact helps determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like.
Came across this pre-RFC as well.
The motivation section says:
It depends on compiler internals and its results cannot be replicated by another compiler implementation or external tool.
Hi All, okay i don't undertand nothing at this point 
.
First my understandings after the reading from the links:
MIT-Licence
The User only must deliver the MIT-Licence as an readme and link to the used Crates, no more.
Apache2
The User only must deliver the Apache2-Licence as an readme and link to the used Crates, no more if he don't alter the crates himself and respect an NOTES-File if he existed.
Is it right that i can mix MIT and Apache2? I mean when i have an project that i licence with MIT i can use MIT/Apache2-Crates?
Yes L/GPL without problems only when i licence all with GPL.
You pretty much got it all right.
Yes.
Yes. The MIT and Apache 2 licences are "compatible".
When using Rust that is a good summary.
You said before that you wanted to use GPL. The GPL (version 3) is also compatible with many other lic ences and there is a helpful page describing which ones: Various Licenses and Comments about Them - GNU Project - Free Software Foundation
I have seen that it gives projects with The Unlicence and MIT/Apache2/ISC-Licence in the dependencies? How can this be?
I have heard of no such requirement. If you are the author of code that merely depends on MIT-licensed code, there are basically no requirements on you that I am aware of.[1]
You would have to do those things if you published, say, a fork of MIT licensed code, or if you copied a substantial piece of the code directly into your code base. Basically, the portion that you copy remains MIT-licensed even when it appears in a private codebase, and this must be communicated at least to people with access to that private source (not necessarily to end-users), usually via a code comment.
This is in contrast to the GPL, which affects all code that depends on the package. This gives the GPL a viral nature, and is why I avoid it when possible.
Looking at the precise wording, it is unclear whether monomorphizations of generic functions defined in an MIT-licensed crate count as portions of "the software;" but the way I've always understood it to mean, that would simply not be in the spirit of the license. ↩︎
I think we need some clarification ASAP before we end up violating licensing agreements and causing heart ache on both sides.
Also I don't understand the above statement. Is this same as the licensing uncertainity around mono-morphisation ?
I am in a mobile phone so cannot give a detailed answer but I recommend checking out the tdlr legal site if there are worries or confusion.
Also don't forget, if you develop a crate, that you're not distributing third Party Software. Cargo downloads an assembles the finished product.
Yes, its a good idea to depend on compatible licences, but things like links to copyrights are not a requirement for the author of a crate.
Hello All,
okay i understand The Unlicence is absolutely correct applied on an mit/apache2-licence project when i only use Librarys/Crates in cargo and i don't rerelease code of this Crates with my changes.
Hmm now make its sense why the most rust librarys are mit/a2 licenced. With gpl (and lpgl,too) all users/coders are binded to the copyleft and this can be the end of an modern programming language, think.
But a controversial guided discussion, very interested.
The "viral licensing" terminology was consciously popularized by large corporations like Microsoft and Apple, in a rather successful attempt to convince open-source developers that it's normal to give them free labor and get nothing back in return.
For a well-known example, given how Apple treated the KHTML developers back in the day, it can be easily argued that Webkit wouldn't be open-source today if its base hadn't been LGPL-licensed, and if some KHTML devs didn't fight back by bringing the story to the eyes of wide-audience media.
Please carefully consider the history and societal implications of corporate marketing before spreading it.
The analysis assumes that the caller and the LGPLed library form a Combined Work to use the defined term from LGPLv3 or "work that uses the Library" to use the defined term from LGPL 2.1 and, therefore, there is an obligation to comply with the requirements the LGPL imposes on the whole thing. (Arguments about something not being a derivative work so as for there not being an obligation to comply are outside the scope of the point I'm making.)
If you don't want to provide source code for the whole thing (both your code and the LGPLed library), you need to comply with the LGPL relinking clause (LGPLv3 4.d.1 or LGPL 2.1 6.b). Since Rust's ABI is explicitly unstable in principle and Rust appends a hash to the symbols seen by the linker to make the ABI unstable in practice and, as I understand it, relatively small toolchain changes change the hash, it's technically impractical to enable the recipient of the Combined Work / "work that uses the Library" to do the relinking contemplated by the LGPL relinking clause. Therefore, the practical way to comply is to provide the source code for the whole thing, which makes the situation pretty much as if the library had been under the GPL instead. (Or to put the LGPLed code behind the C ABI and using it from the rest of the Rust code via the FFI, which is technically silly.)
So in layman terms, if I am going to compile and release my "combined work" using, say rust toolchain version 1.34.1, then all those who are going to use that combined work, in binary form, if they are going to use any other toolchain version, will have trouble linking with it.
Is my above interpretation correct ?
Yes, and more importantly, the point of the relinking clause is not mere relinking but changing the library and then relinking, and some kinds of changes to the library (I'm not sure what kinds of changes exactly) change the hash included in its symbols, which foils relinking.
Thanks @hsivonen for taking the time and explaining in detail.
@ExpHP
does that mean that everybody that make an compiled executable without sourcecode don't must deliver an MIT-Licence copy and links to the used crates? Only when this person deliver sourcecode to another person?