Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Why no license file? #1
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.
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:
referenced this issue
Sep 30, 2016
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.
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.
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.
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.
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:
FWIW the MIT does not require you to copy anything in each file. A single copy of the text is enough.
And if you want a concise mention in every file, you could use this blessed approach:
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!
This was referenced
Mar 20, 2017
added a commit
Jun 18, 2017
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.
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.