Allow the project to be used as starting point for non-MIT licensed project

[cjerdonek]

It seems like if one is starting a new project using the sample project as the "first commit," then the new project also has to be licensed using MIT (since the sample project is licensed using MIT).

Is there a way to license the sample project so that different licenses could be used for projects starting from it? Thanks.

[VelizarVESSELINOV]

👍

[pfmoore]

As the owner of the new project, can't you simply relicense it as you please? Obviously the new license has to be compatible with the project being derived from MIT-licensed sources, but that's always going to be an issue with deriving your code from someone else's work...

As with any discussion of licensing, the only opinions that really matter are those of lawyers, and I'm not one. But when I originally wrote the project I chose the MIT license as the standard open-source license I preferred, and when it was taken over as a PyPA project it retained that. I'm not in favour of the sample project having anything other than a standard boilerplate open-source license, as we should be encouraging people starting projects to have a "known good" license and not to make up their own.

[pfmoore]

... um, I just noticed (a) that this is an old issue, and (b) that even though setup.py states that the license is MIT (which was my intent, as noted) there's no LICENSE.txt file to confirm that. Maybe there should be?

[cjerdonek]

As the owner of the new project, can't you simply relicense it as you please?

Well, yes and no (I think). I'm not a lawyer either. But if, say, you wanted your new project to be BSD 3-clause, it seems the best you could do is add the BSD license in addition to the license that's already there. This is because the MIT license (like most or all OSI-approved licenses) has this language (or language like it): "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." And then the conditions would be the sum of the licenses.

But as you soon as you have two license files, it raises questions like, do I need to mention both licenses in the Trove classifiers, what do I put for the license keyword to setup(), and should I now have two different license files, or should I concatenate them together in a single file, etc? My point is that these questions don't have obvious answers, so it provides a barrier to doing so.

I suppose an argument could be made that because the sample project consists only of standard boiler-plate, there's no content really to license, so any person starting a new project could change it, but I'm not sure.

To your point about wanting some standard license to be used, maybe that can be handled by having language granting the person permission to use whatever OSI-approved license they want (or maybe enumerating them).

I'm also not sure whether or not it's possible to change the license-related stuff at this point without getting the permission of previous contributors.

[cjerdonek]

there's no LICENSE.txt file to confirm that.

Oh, then maybe it's not licensed after all and you can start with whatever language you want. :)

[pfmoore]

Al I said, my intention was that it was licensed under MIT (From what I understand, there's no legal concept of "not licensed" so we should be explicit). I have no idea what the legalities around licensing of "stuff intended to be a starting point for other work" might be.

As the original author, my intent was that the code be MIT-licensed, but I had no intention of dictating how other people license their projects. Beyond that, (1) the project is now managed by PyPA and any license change needs agreement from PyPA as a whole, and (2) I find license debates annoying, counter-productive and typically not in the interests of anyone who doesn't have some sort of ideological axe to grind, so I don't intend to comment further unless someone tries to make a change that's contrary to my preferences, when I'll say so.

[dstufft]

You'd need the permission from anyone who has contributed any copywritable items to the code base to change the license. That means either you just get permission from everyone, or you audit the source code to see who still has relevant items and then get their permission.

[pfmoore]

Agreed. Should I add a LICENSE.txt file with the MIT details to make it clearer that the project is under MIT license (as per setup.py)?

[dstufft]

Yea, that'd be reasonable.

[pfmoore]

Done via #40

If someone wants to clone this project to use as a base for a non-MIT licensed project, I suggest they get legal advice on what would be needed from this project to allow that, and come back with a specific request.

[cjerdonek]

I can try asking on OSI's license-discuss list.

It sounds like there's no getting around what @dstufft said (getting permission). But you want to do it in a way where you only need to ask once, and that the permission holds for future contributors that contribute later.

[pfmoore]

One thought - why is this not an issue for cookiecutter templates (https://github.com/audreyr/cookiecutter)? From a quick check, their templates seem to have various licenses including BSD. Maybe it's worth seeing how that project solved the issue (if they even did).

[cjerdonek]

Good question. It is an issue for them, but it doesn't look like they've solved it either.

Yes, it looks at least some of their project templates have hard-coded licenses. For example, the maintainer of cookiecutter's main Python package template has hard-coded here the ISCL license. Ideally, that would be templatized, too, with whatever legal permission statement, etc, to authorize that to be filled in however the template user wants. Indeed, it looks like someone filed an issue there, too, to let the license be customized.