How to share software easily

[jaraco]

i.e. how to license the software without encumbering the project

background

As one of the few developers in the Python ecosystem maintaining more than a handful of projects, I'm also highly sensitive to the scalability problem, illustrated here. Essentially, the toil of managing the cross-project (ancillary) concerns of each project can overwhelm the maintenance burden of the project itself. One of these concerns is licensing.

objective

In both the Coherent System and the skeleton system, I'm aiming to develop software and share it with the world, which by community standards requires the software to be licensed. I'd like to minimally encumber the software and license it in such a way that it's similar to releasing it into the public domain. I'd like to make it available for others to use in nearly any capacity, at their own risk, and without any guarantees. Additionally, I'd like to accept contributions to the project and share those contributions, similarly unencumbered. I'd like to accomplish this sharing/licensing with as little boilerplate as possible (ideally with a system-wide default and standardized single declaration to override).

challenge

To meet the objective, I chose to license the software under the well-known minimal MIT license. I briefly considered some BSD and Apache licenses, but those were more verbose, complicated, and associated with specific entities, so I elected MIT for its simplicity. I've since realized that even the MIT license has several problems:

• The template includes a copyright notice, which itself has several problems:
  • It implies the need for a copyright year or years, but it's not obvious what these years should be. Is it the date of inception of the project? The year it was most recently modified? A list of ranges of years in which any contribution was made? A separate line for each year and copyright holder combination?
  • It implies the need for specification of the copyright holder, but by my understanding, the copyright is held by the original contributors, which are various. For some projects, there may be a legal entity that could be considered an overseeing entity for the project, but without a CLA assigning copyright, the copyright for any substantial contribution remains with the contributing author.
  • The copyright changes over time and requires maintenance.
  • The copyright notice may be omitted entirely (according to spdx.org), but that invalidates a future clause. Most consumers don't seem to mind the copyright clause being omitted.
• The license specifically stipulates that the copyright notice and the permission notice must be included. This clause is problematic in several ways.
  • The copyright notice may be omitted.
  • The requirement of "permission notice shall be included in all copies or substantial portions of the software" is almost certainly not honored in the general case. Although the wording is included in, generally, the permission notice is attached to or associated with a project. As a stark example, when a package is pip installed, the license is attached as metadata, completely separate from the installed software. Contrast that with the Apache-2.0 license, which seems to only require that a copy of the license be provided (by reference) to any licensees.
• The license seems to attach itself to the software and encumber it permanently. If a maintainer wishes to license the project under MIT without including a copy of the permission notice and copyright, they are technically in violation of the license, even if the copyright notice doesn't accurately reflect the true copyright.
• Any attribution of the license to contributions is implicit.
• Integrators and others scrutinize the license will lean on these words to constrain a project as to how it can license the project, demanding that copies of the license text be present in specific places in each and every repository, despite the project's authors specifically and unambiguously declaring the intended license.
• Attempts to remove the boilerplate from the source code repo but then resolve and inject the default/declared license when distributing the software have been met with fierce opposition.

questions

1. Is there an OSI license that can be applied by referencing in the project? It appears as if MIT does not allow this form of application. Perhaps Apache-2.0 does.
2. Is there a systematic way a project or set of projects can simply declare an OSI license and not require the project to carry boilerplate text (especially in the root of the repo)?
3. What is the purpose of the Python License-Expression if not to express the license of the project using unambiguous SPDX identifiers to identify the license?
4. Is it not reasonable and possible to omit a copyright notice and to rely on the default copyright afforded to each contributor as tracked in the version control system and tooling (e.g. Github)?

[sthen]

"Is there an OSI license that can be applied by referencing in the project?" - I don't think that's possible at all. As far as I'm aware you need to have the copyright notice and permission grant included in the project. Debian packaging guidelines seem to agree; https://www.debian.org/doc/debian-policy/ch-archive.html#copyright-considerations "Note that under international copyright law (this applies in the United States, too), no distribution or modification of a work is allowed without an explicit notice saying so. Therefore a program without a copyright notice is copyrighted and you may not do anything to it without risking being sued! Likewise if a program has a copyright notice but no statement saying what is permitted then nothing is permitted."

[tburt-nv]

Firstly:

• I am not an lawyer and my statements are not legal advice
• I am an NVIDIA employee and my statements here reflect my own views and not the views of NVIDIA

The https://reuse.software/ framework suggests placing license files in a LICENSES directory. Perhaps this LICENSES directory could be a submodule of a standard "license" repository, such that the license repository contains different branches for different combinations of licenses. Projects that use a single license for all their content could then select a "license" repository ref that contains only one LICENSE. In this way, projects can refer to the license without actually containing a copy of the license, while also clearly communicating the license that applies to the project's content.

In cases where projects contain combinations of content with different licenses, such as when a file from an Apache-2 project is copied into an MIT project, the https://reuse.software/ framework provides a mechanism to distinguish which license applies to which content. In these cases, the Python License-Expression used in a binary wheel may be a combination of both Apache-2 and MIT to reflect the combination of content with different licenses, but the individual source files retain their individual licenses.