Why no license file?

[jaraco]

In many of the projects I maintain, I'm asked to create and maintain a license file separate from the license declaration in the metadata. I'd rather not paste a license file into the source, maintain the license declaration separately, and ensure that those stay in sync. In fact many times I've seen them fall out of sync. I'd like instead to have a single point where the license is referenced and let that serve as the authoritative indication of the license under which the project is released.

To communicate this, I'm filing this ticket with the project skeleton from which many of the projects I maintain is derived.

[jaraco]

I acknowledge that there might be some subtle legal ramifications with not having the license text with the source code. I'll happily revisit this issue at such a point that legal disputes become a real issue.

[jaraco]

The technique employed herein allows the license to be simply declared as a reference to a known license that is reflected in the metadata and available in PyPI and at run time. For example:

>>> import pkg_resources
>>> pkg = pkg_resources.require('keyring')[0]
>>> import json
>>> licenses = [cl for cl in json.loads(pkg.get_metadata('Metadata.json'))['classifiers'] if cl.startswith('License ::')]
>>> licenses
['License :: OSI Approved :: Python Software Foundation License', 'License :: OSI Approved :: MIT License']

[pombredanne]

@jaraco
There is nothing subtle about: no text included with the code by a user means the user has NO license from you...
So there is an immediate legal issue for a user of your code as if you take the MIT, the essential condition to be licensed is to include the text of the MIT.
If you do not include it therefore everyone is not fulfilling your conditions and therefore not licensed at all to use your MIT licensed code.... Note that same applies to the vast majority of FOSS licenses in general and to the licenses you use for your packages in particular.

So when you do not include such license text in your packages (including down to the wheels and not only the sdist) your are in a bizantyne way making every user non-licensed? unless --like I do-- you recheck and add back a license text to your packages, e.g. https://github.com/nexB/scancode-toolkit/blob/develop/thirdparty/prod/yg.lockfile.LICENSE . I end up having to go through the hoops of crafting one by guessing your intent....

Yeah! I am licensed! but millions of your users may not be properly licensed to use your wares.
I reckon this is a pain :) but this is the way these things work.

[jaraco]

As I understand it, to be in compliance, a license must be included with each and every file. Most people accept that such an approach is generally unsustainable, so they cheat by including the license near the files and possibly (though rarely) referencing the license from each of the files. I maintain enough packages that the same sustainability problem applies to each project as well. It's for this reason that I've created a separate repository just to maintain the skeleton of the projects.

To that end, I could lean on this skeleton to copy the license and ensure that it's included in wheels and installs, but even then, I'd probably still not be technically in compliance with the legal standards. The attribution and copyright would probably still need to be individually maintained.

So perhaps you're right, that technically these packages appear unlicensed, but I still assert that no legal challenge to the licensing of these projects will ever come under legal scrutiny. The intention is clear and unambiguous. Even with wheel installs, the license is indicated in the package metadata, so every file affiliated with the installed package is linked explicitly to the license.

>>> import pkg_resources
>>> dist = pkg_resources.get_distribution('rwt')
>>> import json
>>> md = json.loads(next(dist._get_metadata('metadata.json')))
>>> print(next(cl for cl in md['classifiers'] if cl.startswith('License')))
License :: OSI Approved :: MIT License

I forget in which package someone mentioned it, but I pointed out that if Python Packaging or the larger Open Source community were to come up with a way to either embed or (preferably) declare a license and tooling to manage the cascading of that license through the packaging and distribution chains, I'd be all for adopting that, but I'm not interested in doing the tedious busy work required to comply manually still to only be somewhat compliant.

[jaraco]

Is there anyone who seriously believes that if I (as copyright owner) were to challenge another's incorporation or use of the code in court that they couldn't use that metadata to defend their right to use the code according to the terms of the MIT license? If someone can show precedent of such a case, I'll concede and include the license text.

[pombredanne]

@jaraco
You wrote:

If someone can show precedent of such a case, I'll concede and include the license text.

There is no such precedent. It is just that dealing with exceptions (as in this project is MIT-licensed, but does-not-have-a-license-text) is a tad harder. And since one or more of your packages are eventually used in every python app and installation, you are at the bottom of the stack which has some consequences:

1. volume: your code and ways are everywhere raising their visibility
2. example: because of your prominence and importance in the Python community, what you do is likely to be followed my many other.

You wrote:

but even then, I'd probably still not be technically in compliance with the legal standards.

FWIW the MIT does not require you to copy anything in each file. A single copy of the text is enough.
Adding a standard copyright without a date would make it plenty good IMHO.

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

And if you want a concise mention in every file, you could use this blessed approach:
# SPDX-License-Identifier: MIT

See https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf

I forget in which package someone mentioned it, but I pointed out that if Python Packaging or the larger Open Source community were to come up with a way to either embed or (preferably) declare a license and tooling to manage the cascading of that license through the packaging and distribution chains, I'd be all for adopting that, but I'm not interested in doing the tedious busy work required to comply manually still to only be somewhat compliant.

I guess this was me here: pombredanne/spdx-pypi-pep#1

So for now, I guess you can do as you like and leave your ways as they are. You are correct that we should best come with a common way that can work for everyone first.

Thank you ++ for your code and for taking the time to reply here!

[six8]

What if the MIT license changes its text to something you don't agree with? As far as I know, many licenses don't version themselves. Having the actual license text guarantees that no matter what the source license changes to, you're sticking to the license in your code.

[jaraco]

What if the MIT license changes its text to something you don't agree with?

Then I will correct the situation, and update the license to reference another resource with the intended license or maybe I'll consider bundling the license then.

[prof7bit]

I'm trying to use cherrypy in an embedded linux distribution for a controller board in an industrial application and that distribution will be built using the yocto/openembedded build platform.

CherryPy indirectly depends on portend

So I have to write a bitbake recipe to pull portend from pypi

In order to write a bitbake recipe and have it run without fatal QA errors I need to provide it with a license file URL in the unpacked source tree and an md5sum of that file.

Please consider reopening this issue and provide a license file. Thank you.

[jaraco]

In order to have [bitbake] run without fatal QA errors, [packages must have a license file]

That sounds to me like a defect in bitbake. Is there an option for bitbake to indicate "project doesn't bundle a license file because it more consisely links to its license" or even better for bitbake to automatically detect that the license is declared in the metadata for the package?

I presume the answer is no, in part because there's no endorsed standard. And there's little motivation for someone to create a standard because the status quo is to bully every project into copying the license file into their project.

So fine. I'm sufficiently bullied. I'll put the license file in the skeleton and copy it across all the projects. If it falls out of sync with the declared license, I'll leave it to the lawyers to figure it out.