Why no license file? #1

Closed
jaraco opened this Issue Sep 30, 2016 · 10 comments

Comments

Projects
None yet
4 participants
@jaraco
Owner

jaraco commented Sep 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Sep 30, 2016

Owner

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.

Owner

jaraco commented Sep 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Sep 30, 2016

Owner

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']
Owner

jaraco commented Sep 30, 2016

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']

@jaraco jaraco referenced this issue in jaraco/backports.functools_lru_cache Sep 30, 2016

Closed

Please include license file #8

@pombredanne

This comment has been minimized.

Show comment
Hide comment
@pombredanne

pombredanne Mar 9, 2017

@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.

pombredanne commented Mar 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Mar 9, 2017

Owner

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.

Owner

jaraco commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Mar 9, 2017

Owner

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.

Owner

jaraco commented Mar 9, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pombredanne

pombredanne Mar 9, 2017

@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!

pombredanne commented Mar 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@six8

six8 May 31, 2017

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.

six8 commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Jun 1, 2017

Owner

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.

Owner

jaraco commented Jun 1, 2017

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.

the-maldridge added a commit to the-maldridge/void-packages that referenced this issue Jun 18, 2017

New package: python-portend
This package is licensed MIT but the original author doesn't seem to
understand how to use MIT, so there is no provided license file.
Since this quite prolific author is opposed to following the standard
license management practices (and indeed those likely mandated by the
text of the license itself) I leave here in this commit message a
pointer to where numerous people have tried to convince the author to
just use the license in the manner in which it was designed.  No one
has thus far been successful...

jaraco/skeleton#1
@prof7bit

This comment has been minimized.

Show comment
Hide comment
@prof7bit

prof7bit Sep 26, 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.

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

This comment has been minimized.

Show comment
Hide comment
@jaraco

jaraco Sep 26, 2017

Owner

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.

Owner

jaraco commented Sep 26, 2017

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.

@jaraco jaraco reopened this Sep 26, 2017

@jaraco jaraco closed this in 5dc924c Sep 26, 2017

clrpackages pushed a commit to clearlinux-pkgs/hgtools that referenced this issue May 14, 2018

[update to 8.1.1] Need to avoid .eggs in recursing dirs. Ref pypa/set…
…uptools_scm#212.

Jason R. Coombs (65):
      Set the origin date once and forget it.
      Add python_requires directive.
      Don't bother with copyright year(s). Let the repository history track the changes and copyright years. YAGNI.
      Include the project (for docstrings). Include Sphinx (for environments where it's not an implied provision).
      Include pytest-sugar for nicer test output.
      Rely on jaraco.packaging for loading the package metadata from the package for Sphinx.
      Use single-quotes to satisfy the style nazis.
      The requirement is no longer needed for tests.
      Add readthedocs yml file
      Move requirements for docs and testing into extras
      Add appveyor script for CI testing on Windows.
      Require tox 2.4 or later; fixes #2.
      Remove namespace_packages declaration, no longer needed.
      Use a simple build number rather than prefixing with '1.0.'
      Restore support for namespace package declaration, selected on a 'nspkg_technique' setting
      Inspired by pypa/setuptools#1059, use the preferred bdist_wheel heading.
      Check the docs during tests
      Use stages in travis to have deployment depend on success in all Python versions.
      Remove 'bootstrap', artifact from setuptools
      --add doesn't work in a list
      Add a license file. Fixes jaraco/skeleton#1.
      Remove downloads shield, no longer available.
      Add documentation badge.
      Normalize indentation in docs/conf.py
      Declare 'python' factor at top level
      Correct travis syntax
      reference the license file in metadata
      Use https
      Add build-docs env in tox.
      Run only default environment by default.
      To support namespace packages, Setuptools must be 31.0.1. This change is necessary with the adoption of tox-venv, which uses Python's venv, which does not install the latest setuptools by default.
      Need to avoid .eggs in recursing dirs. Ref pypa/setuptools_scm#212.
      Use tox-venv for future compatibility.
      Disable pytest-sugar until Frozenball/pytest-sugar#133 is addressed.
      Bring back pytest-sugar with a minimum version to support Pytest 3.4.
      Save the pip cache across builds. Ref pypa/setuptools#1279.
      Add workaround for build failures on Python 3.7 (yaml/pyyaml#126).
      Run flake8 with tests. Add flake8 config to ignore common exclusions. Add comments to testing and docs extras to aid with merges.
      Add appveyor badge (commented). Disable RTD by default.
      Limit workaround to affected Python
      Bump minimum pytest version
      Add pyproject.toml declaring build dependencies.
      When ignoring linter warnings, document the reason.
      Merge https://github.com/jaraco/skeleton
      Drop support for Python 2.6
      Feed the hobgoblins (delint).
      dos2unix
      Fix test failures by restoring working directory in fixtures.
      Fix test failures in checkdocs
      Remove setuptools plugin
      Use behavior from other packages
      dos2unix
      Use relative import
      Use packaging for version parsing
      Drop support for Python 2.7 and 3.4
      Revert "Remove setuptools plugin"
      Revert "Drop support for Python 2.7 and 3.4"
      Update changelog
      Use new style classes through the lib.
      Revert "Use packaging for version parsing"
      Revert "Use behavior from other packages"
      Rename util to _vendor
      Update iter_subclasses to latest version from jaraco.classes
      Update one from more_itertools
      Update changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment