Apply a standard open source license

[garth-wells]

pybind11 does not use a standard open source license, i.e. a license listed at https://opensource.org/licenses.

It's good for the open source projetcs to use standard licenses that are well understood. Is there a reason why pybind11 cannot adopt one of the BSD licenses?

[henryiii]

Looks like a standard BSD 3-clause license to me... The only addition is the contributor clause at the end.

[garth-wells]

@henryiii It looks like BSD 3-clause but it isn't BSD 3-clause.

[henryiii]

Could you mention what's different?

[jagerman]

The addition is the non-standard part. I don't see that we actually need it: I think it would probably suffice to put a disclaimer somewhere else in the github project page (rather than in the source code itself) that contributions are implicitly assumed to be licensed under the same terms as the BSD 3-clause licence of pybind itself.

Cc @wjakob for input.

[wjakob]

There is a good reason to have the extra paragraph in the one file which clarifies legal aspects: The 3-clause BSD license does not say anything about the status of pull requests on GitHub or e.g. patches sent via email, which can put larger project with many external contributions into an awkward situation. An alternative would be to use CLAs, which are annoying. (Quite frankly, I think the discussion of whether LICENSE.txt has the exact MD5 sum of the standard 3-clause BSD file a bit silly.) In this case, it is a perfectly reasonable (and readable) addition that does not encumber the software in any way, and which just clarifies interactions with other users.

PS: Try googling for this specific extra paragraph -- you will find that many other projects use it.

[henryiii]

One more comment: A BSD is not like the GPL/LGPL, which are very specific and versioned. You'll notice that BSD licenses never even say "BSD license", since they really are just a do-anything but keep credit type licenses, so you can't into the pickles that GPL/LGPL version mismatches can cause.

I'm not a lawyer but I talked to one at length about CLI11, and was able to move that from a LGPL to BSD-style license right before release 1.0, but I didn't even know it was 3-clause BSD at first because he just sent me the text to include.

[henryiii]

PS: sort of related. Would it make sense to put CONTRIBUTING.md and ISSUE_TEMPLATE.md, and maybe a new PULL_REQUEST_TEMPLATE.md, into a .github` folder? That is allowed by GitHub (they still get shown in the GUI), and would reduce the main directory clutter (a tiny bit). Just curious.

[garth-wells]

@wjakob The problem with a non-standard license is that it complicates compliance. In the case of an open source library that depends on say 10s of other open source libraries, if it is used commercially it is good practice to do a license audit. If each of the 10s of dependencies use custom licenses the lawyers may well struggle to come out the other end, and may recommend against use and support on the basis of an uncertain license position. This ultimately hinders support for open source projects.

[jagerman]

I think we need to draw a distinction between the actual license of the software, governing its use, and the process of developing the software.

For the software itself, a 3-clause BSD license is perfectly acceptable. This, essentially, means you can do whatever you want except lie about or hide who created it, or lie that the creators somehow endorse your use of it. Beyond that, you can do what you want with it, including distribution in proprietary software, etc.

The second issue is the matter of how we treat contributions to the software, and this is what that last paragraph is attempting to do. We need, of course, to be able to assume that code contributed to pybind is compatible with that license, i.e. that we can continue to distribution pybind under the 3-clause BSD once we add that contribution. We could ask for that every time, but the process of asking every contributor "do you agree to licence this code under pybind's license?" is burdensome and error-prone, and so we really do want to rely on a clause that says that if you don't claim otherwise, you implicitly agree that your code can be distributed under those terms.

But note that all of that matters entirely before that code becomes part of pybind: it's part of the development process, not part of the code distribution and use.

There are also some issues with that last clause as currently worded, as it also seems a bit inequitable to me: it's asking contributors to give up more rights on their contribution than the license grants them over the pybind code in the first place—in particular it goes beyond the requirement that the code be usable under the same terms as the LICENSE itself spells out, but I don't see why this needs to be the case. It also seems to imply that parts of pybind are under difference licenses: first-party code (which, I suppose, could be interpreted as code written by Wenzel, Dean and myself) is under the 3BSD+CLA, while other is under "a non-exclusive, royalty-free perpetual license to install, use, modify, prepare derivative works, incorporate into other computer software, distribute, and sublicense such enhancements or derivative works thereof, in binary and source code form." One possible interpretation is then that such code can be, for example, used as endorsement, and can be relicensed to some other license; these aren't intentional, seem to go against the spirit of the license, but don't necessarily go against the wording of the license.

That all brings me back to my original point: we don't really need that clause to be part of the license because it's a clause designed to govern contributions, not the use of the released code.

TL;DR: I think we should move the last clause (with or without edits) to a separate CONTRIBUTING file which would keep the project under a very standard, vetted 3-clause BSD license, and still provide us with the necessary requirements for merging contributions without having to resort to a CLA process or license check on every PR.

[wjakob]

I think we already have a CONTRIBUTING.md file, no? My main concern is that text concerning legal aspects of the project is usually consolidated in a single file (e.g. LICENSE.txt or EULA.txt). Could we at least add a footer or header saying that rules concerning pull requests and patches are discussed elsewhere?

[jagerman]

That sounds reasonable to me. Maybe something like "(For details on contributing to the project, see CONTRIBUTING.md)," with a new section on implicit licensing assumptions of contributions added there.

@garth-wells - would that solve your concerns?

[garth-wells]

@jagerman Sounds good.

License section in README.md (https://github.com/pybind/pybind11#license) would need updating.