Clarify license

[davidak]

This should make it possible for people to use this software in a legally safe way.

Fixes #3390

The interesting question is if we are legally allowed to merge this PR or if we need the approval of all contributors.

Right now there are different statements about the projects license.

LGPL-2.0-or-later

https://github.com/NixOS/nix/blob/2.3.3/nix.spec.in#L22 (file does not exist anymore)

LGPL-2.1-or-later

https://github.com/NixOS/nix/blob/2.3.3/doc/manual/introduction/about-nix.xml#L263
https://github.com/NixOS/nixpkgs/blob/nixos-21.05/pkgs/tools/package-management/nix/default.nix#L163 (external, no legal relevance here)

LGPL-2.1-only

https://github.com/NixOS/nix/blob/2.3.15/README.md

So under which license are contributions licensed?

I guess the one from the Readme, so we would need approval of all contributors for this change.

cc @silverhook (lawyer)

Reference of other license issues: NixOS/nixos-homepage#260

[L-as]

The "or later" vs "only" distinction is legally quite murky honestly, since in the COPYING file nothing is written about it also being licensed under later versions of LGPL.

We can not safely assume that all contributors noticed the "or later" in the manual, so I think the correct choice would be to remove the "or later" from the manual.

[silverhook]

So under which license are contributions licensed?

Nix’ license is the one the authors agree on ;)

But with the history of Nix, I would say it’s a fairly safe assumption it is supposed to be LGPL-2.1-or-later and that the missing “or later” parts are a bug.

(cc @armijnhemel , @edolstra, who should know the original intent)

---

As a side note, you mention the license of the “contributions”, which is the inbound side from the Nix PoV and a different can of worms. What the original issue (#3390) and this pull request are about is the outbound side – under which license Nix is offered to the general public.

If we’re talking about the license of the contributions (i.e. Nix’ inbound license), from what I can tell, I would say it’s relatively safe to assume an Inbound=Outbound licensing model is implied, and as such it is expected that the contributions to Nix are also made under the same LGPL-2.1-or-later license. Although without a document describing what license the contributions should be under (i.e. a CLA in its actual/wider sense), it is hard to tell.

To achieve that a simple statement in the CONTRIBUTING.md (and enforcement of that) or something like that should suffice.

[davidak]

@silverhook thanks a lot!

If we’re talking about the license of the contributions (i.e. Nix’ inbound license), from what I can tell, I would say it’s relatively safe to assume an Inbound=Outbound licensing model is implied, and as such it is expected that the contributions to Nix are also made under the same LGPL-2.1-or-later license.

Yes, that's how i understand licensing on GitHub too. But where do you get that LGPL-2.1-or-later is the outbound license? The README says LGPL-2.1-only and that is what contributors see and agree on when contributing.

In practice, we can assume that everyone who agrees with LGPL-2.1-only also agrees with LGPL-2.1-or-later. It's not much difference in practice.

So we could just merge this and see if someone complains.

Would you agree that that is a good way to move forward?

To achieve that a simple statement in the CONTRIBUTING.md (and enforcement of that) or something like that should suffice.

I have never seen such a statement und think it's enough to have the license in LICENSE and README (including optional "or later" statement). Is that legally safe? Do you know projects that have such a statement? (I know CLA and i think that's against the open source spirit that a company can change the license how they want)

[L-as]

In practice, we can assume that everyone who agrees with LGPL-2.1-only also agrees with LGPL-2.1-or-later. It's not much difference in practice.

...I don't think you can assume this. You can't just merge this and "see if someone complains". Misrepresenting the license of the code is likely illegal in many jurisdictions.

I don't think you'll get anyone to merge this, as it would be a risk for them legally.

[armijnhemel]

So under which license are contributions licensed?

Nix’ license is the one the authors agree on ;)

But with the history of Nix, I would say it’s a fairly safe assumption it is supposed to be LGPL-2.1-or-later and that the missing “or later” parts are a bug.

(cc @armijnhemel , @edolstra, who should know the original intent)

I was not involved with this part (this was all @edolstra )

[silverhook]

If we’re talking about the license of the contributions (i.e. Nix’ inbound license), from what I can tell, I would say it’s relatively safe to assume an Inbound=Outbound licensing model is implied, and as such it is expected that the contributions to Nix are also made under the same LGPL-2.1-or-later license.

Yes, that's how i understand licensing on GitHub too. But where do you get that LGPL-2.1-or-later is the outbound license? The README says LGPL-2.1-only and that is what contributors see and agree on when contributing.

Here is how I would interpret it based solely on the info you provided in your original post.

README does not mention specifically whether it’s “only” or “or later”. While this by itself in general means “only” and that is the default of the license, the documentation and the .spec file both indicate it is “or later”. With the ”or later” being an option in the license and therefore a conscious choice. A conscious choice that overrides the default.

In addition, according to git blame the LGPL-2.1(-only) in the README was written by @domenkozar (and that line has not had anyone else touch it), while all the instances where it says LGPL-2.1-or-later can be originated to @edolstra.

(…and people think licensing archeology is boring, ha!)

In practice, we can assume that everyone who agrees with LGPL-2.1-only also agrees with LGPL-2.1-or-later. It's not much difference in practice.

No, very much not. See e.g. the Linux kernel (and Linus Torvalds) for a famous (and back then loud) example :)

To achieve that a simple statement in the CONTRIBUTING.md (and enforcement of that) or something like that should suffice.

I have never seen such a statement und think it's enough to have the license in LICENSE and README (including optional "or later" statement). Is that legally safe? Do you know projects that have such a statement?

I am not in a position to advise whether something is legally safe or not.

(I know CLA and i think that's against the open source spirit that a company can change the license how they want)

As someone who did his master’s thesis on the FLA (which is a CLA, and prioritises the author over the legal entity), I’d beg to differ. I would ask you to show me the text of The One CLA™, but this would be off topic for this issue.

Sorry, it’s a pet peeve of mine …yes, there are many many awful CLAs and CAAs (Copyright Assignment Agreements) out there, but a CLA as a concept by itself is nothing bad. Just as a license is nothing bad, it just happens that there are many more proprietary EULAs out there than there are FOSS licenses.

By definition if you agree on what license the contributions should be under, that is a Contribution License Agreement (CLA). Hence the name ;)

You can have it as a simple statement to do an Inbound=Outbound situation – and that is quite common – e.g.:

All contributions to this project are to be made (or use “MUST” if you prefer RFP lingo) under the same license as the outbound license of this project (or explicitly say “LGPL-2.1-or-later”).

Or you could choose some other license, that allows for re-/sub-licensing (although I would not suggest that unless you have good reasons; spoiler: you probably don’t):

All contributions to this projects are to be made under MIT license.

You can even further enforce this with a DCO that everyone has to sign off on, when they commit to Git.

[stale]

I marked this as stale due to inactivity. → More info