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.

[VelizarVESSELINOV]

Thank you (@pfmoore and @cjerdonek) for all the links, I will try to test them for my new project start.

[Ivoz]

We should release this under public domain if we want to make it clear people can use this completely as they wish, including copying, modifying and relicensing.

[dstufft]

Public domain doesn't exist in all jurisdictions.

[dstufft]

And even so, you still have o get permission from everyone who has contributed so far, or remove their contributions since they own the copyright on that work.

[Ivoz]

I consider that a bug in those jurisdictions, and there's certainly not much we can do about it.

[dstufft]

Well, unless you want the sample project, and all projects derived from it to be unusable in say... Germany (for instance) it's an important thing to consider.

[Ivoz]

That's not a change in the status-quo, though. You can't transfer copyright in Germany to allow for re-licensing anyway; it's a bug that neither us or any license text we choose can actually fix.

[dstufft]

Licensing doesn't require copyright transfer nor does re-licensing, only CLAs that require a copyright assignment requires that.

[magicgoose]

I consider that a bug in those jurisdictions, and there's certainly not much we can do about it.

You can dual-license it, or triple-license, etc.
For example state that the code is available under MIT terms, and also GPLv2 and GPLv3, and etc.
Should cover all practical use cases. Am I correct?

[CAM-Gerlach]

FYI, this exact issue is precisely what the standard CC0 license is written to address. It both a standard "license" with legally valid terms and widely used as a public domain declaration, and releases the maximum rights permitted by law, i.e. a strict superset of MIT in that regard. Only 4 people have committed more than 20 lines of code, and there's a good guess most of the rest is either superfluous, replaceable, no longer used or sufficiently trivial as to not be copyrightable, so its actual not as unrealistic as one might think to relicense this.

[oxr463]

FYI, this exact issue is precisely what the standard CC0 license is written to address. It both a standard "license" with legally valid terms and widely used as a public domain declaration, and releases the maximum rights permitted by law, i.e. a strict superset of MIT in that regard. Only 4 people have committed more than 20 lines of code, and there's a good guess most of the rest is either superfluous, replaceable, no longer used or sufficiently trivial as to not be copyrightable, so its actual not as unrealistic as one might think to relicense this.

I don't think software should be licensed under a Creative Commons license if it can be avoided, (See: https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software).

See instead: https://spdx.org/licenses/0BSD.html

[CAM-Gerlach]

@oxr463 Those reasons apply to the actual CC licenses, not CC0, which is a public domain declaration (also termed a "public domain equivalent license"). From the very FAQ entry you linked,

Also, the CC0 Public Domain Dedication is GPL-compatible and acceptable for software. For details, see the relevant CC0 FAQ entry.

Furthermore, as this is a template, it primary consists of structure, metadata and written files, not functional code

The real only concern I've seen with CC0 is disclaiming patent grants, which some argue weakens users' protection against software patents, but as a practical matter there are no software patents involved here, if there were PyPA or the contributors are never going to sue over them, the other public domain equivalent licenses don't actually grant them either, and this has not proven to be a significant distinction in practice.

CC0 offers the advantages of legal significance across the maximum variety of jurisdictions across the world, matching Python's similarly international userbase, is the de-facto standard license for template repos, and has a sufficient long history and wide adoption to give it sufficient legal weight. There's also the big, pointless drama over 0BSD that seemingly has been mostly resolved, but still crops up from time to time.

A search across Github for projects identified with each license records 56 380 results for CC0, mostly various template-style repositories, and 359 for 0BSD, mostly actual code. Ergo, CC0 appears to be the clear choice.

Presuming that the maintainers agree, is there anything contributors like myself can do to help make this happen? I can submit a PR with the license, but most of the work is getting written sign-offs from the contributors involved.

[pfmoore]

I'm sorry if this is awkward for anyone, but to be clear, I licensed the original code as MIT, and I'd like it to stay that way. Ownership of the project is now with PyPA, but I don't want to get sucked into debates where people try to persuade me that I should sign off on changing the license to such-and-such other license.

I'll stay out of any further discussion (as I've already said, I don't want to participate in license debates as a general matter), but I wanted to make things clear so people weren't under any misapprehensions.

For the record, I don't actually think there was anything particularly clever or innovative about the original code I wrote. It was basically just a consolidation of various "good practices". I have no idea whether that makes any difference to how it can be used, or whether it can be used in differently-licensed projects. (And I don't want to debate the matter - that's for lawyers to establish, if needed).

[CAM-Gerlach]

Thanks for providing that detailed insight, @pfmoore . I appreciate your time, even though it sounds like this unfortunate issue is rather bothersome for you—sorry about that. I am unclear on one point, however—have you transferred copyright ownership of your individual code contributions to PyPA, or simply physical control over the project in which it is developed? They are two very different things that have central implications for how we can move forward to resolve this issue.

In any case, to summarize moving forward, the whole intent of using a public-domain-equivalent license for templates, as is standard practice, is to avoid these tedious license debates you rightfully decry, so that those using this project can pick any license they choose for their own projects without having to worry about the legal technicalities and concerns with the current situation. As such, using MIT does not match with the original author's intention to not "dictat[e] how other people license their projects", because unfortunately that's precisely what it does, just like any other license (aside from one like CC0) would.

Therefore, as a practical matter for the PyPA (and its lawyers) to consider, something needs to be done if this template is to fulfill its purpose for more than the minority of Python projects using one specific license. Whether that's convincing contributors to relicense, rewriting the portions contributed by those who choose not to, or replacing this with a template that can be used as the basis for any Python project is not for me to decide, but I'm happy to help further if I can.