Licensing Guidelines

This is no lawyer advice, the following only represents some contributor opinions and understanding.

The preferred license for source code and documentation is EPL-2.0 OR GPL-2.0-or-later (EPL 2.0 with GPL-2.0-or-later as the secondary license).

When referring to a license use its full name or its  SPDX-License-Identifier  (  Eclipse FAQ  ) . Projects should be  REUSE recommendations  compliant regarding licensing information. The  Eclipse Foundation Project Handbook  is used as a guide in order to determine licensing related license notice files and similar. Detailed information about EPL 2.0 can be found  here  .

With the ticket  #86  the GPL-2.0-or-later license as a secondary license to EPL-2.0 was dropped, because the dependencies of the project were not compatible with GPL-2.0-or-later, as it was understood, that dependencies needed to comply with the secondary license at all time. Later, it was found out, that the secondary license does not have to apply to the dependencies. The person that publishes the work only under the secondary license, is required to only include complying dependencies. The person publishing the work under EPL-2.0 with GPL-2.0-or-later as the secondary license, is not required to only include complying dependencies. See 2 e) and 3.2 a) in the EPL-2.0 for more details ( relevant discussion. ).

With the ticket  #88  GPL compatibility is planned for the core code. Instead EPL-2.0 OR MIT was adopted with the later goal to adopt EPL-2.0 OR GPL-2.0-or-later (EPL 2.0 with GPL-2.0-or-later as the secondary license), when GPL-2.0-or-later compliance of the dependencies is achieved.

Later it was noticed, that dependencies compliance with the GPL-2.0-or-later is not relevant, if the GPL-2.0-or-later is used as a secondary license to the EPL-2.0. So it was decided to immediately fallback to the EPL-2.0 with GPL-2.0-or-later as the secondary license. Adopting the EPL-2.0 OR GPL-2.0-or-later is done via the ticket   #218: Relicense main repo to EPL-2.0 with GPL-2.0-or-later as a secondary license.   .

To the current understanding of the EPL 2.0 license and the  Eclipse EPL 2.0 FAQ  derivative works do not seem to include works that merely link (or bind by name) the original work and derivative works.

Dual licensing the program source code under MIT and Apache 2.0 was considered as a correct way, because Rust seemed to be a good open source role model. It provided patent protections and great flexibility. The reasoning for  dual licensing  seemed to be good, so it was considered.

Alternative licenses, which provided extended copyright protection via copyleft (  example argumentation context for copyleft  ), were also checked. Some additional protections were wanted, but using strong copyleft from the start seemed to have some downsides in practice, primarily because of standard dependencies like JUnit. Furthermore, the inability to integrate external code with incompatible licenses, would be hindered. So, instead weak copyleft licensing was considered.

MPL 2.0 was considered, but the termination clause seemed to be awful: if one did some error regarding the licensing, one could loose the license of an IP simply by missing some time frames set by the license. It was also noted, that one may even get terminated after fixing of licensing issues, if the contributor choose to do so and if certain conditions are met. This seems to be a too big uncertainty.

A similar problem arises from the termination clause in the (L)GPL 2.x license. Some corporations even explicitly stated,  that the termination clause of this license will not be enforced  (  additional source  ).

Next the EPL 2.0 was considered. The termination clauses seemed to be very ...**drom roll** ... reasonable **BA DUM TSS** and it was a weak copyleft license.

The Apache Software Foundation is an American organization, whereas the Eclipse Foundation AISBL is an Euorpean-based organization. The founder of the project is located in Europe, so it makes more sense to target European communities. The weak copy-left approach of the EPL-2.0 also enables some extended copyright protections, while offering improved license compatibility, so EPL-2.0 OR GPL-2.0-or-later was adopted (  Developing Software at Gunpoint: Weak Copy Left Versus Pseudo Permissive  ).

Metadata like references to documents via  BibTeX  , containing info about the author's name, the title, etc., is licensed like any other info in this project. In most places such info does not seem to be protected by copyright or have appropriate exceptions in copyright law. Otherwise, it would not be possible to have multiple articles referencing the same third party document by using the same reference string.

This means, that even so document references would be licensed under the EPL-2.0, others probably can use these document references and ignore the licensing of these. This effect is desired, because there are no positives to prevent others from using references freely.

This file states the project and contains the licensing and attributions of the project's content. Third party dependencies not inside the repo may also be attributed here.

The notice file also contains additional legally required notifications and attributions (i.e. required notification by the Apache 2.0 license).

The notice file should contain all licensing and attribution information, except for the actual complete copies of the licenses etc. Keep in mind that the notice file may need to be updated/extended, if the project is distributed with bundled third party dependencies.

# Notices for [project]

## Copyright

All content is the property of the respective authors or their employers.
For more information regarding authorship of content, please consult the
listed source code repository logs.

## Project Licenses

[...]

## Notes

## Third Party Content

[Only needed if present.]

### Third Party Dependencies

[Third Party Content ID/Name]

* [optional if no specific version is used] Version: [...]
* License: [...]
* [optional] Website: [...]
* [optional] Source Code: [...]

For short Bash/sh scripts a license header is not required.

/*
 * Copyright (c) 2021 Contributors To The `net.splitcells.*` Projects
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0.
 *
 * This Source Code may also be made available under the following Secondary
 * Licenses when the conditions for such availability set forth in the Eclipse
 * Public License, v. 2.0 are satisfied: GNU General Public License v2.0 or later
 * which is available at https://www.gnu.org/licenses/old-licenses/gpl-2.0-standalone.html
 *
 * SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
 * SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
 */
This is the license header template for Java files.

A long header is maintained, because most other projects seem to be doing this for Java files. It is suspected, that this is needless, as long it is part of a repo, where this info is present and easily notable. Maybe the short only SPDX version will be enough in the future.

/* SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
 * SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
 */
This is the license header template for Javascript and CSS files.
# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
# SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
This is the license header template for Bash, sh, toml and .gitignore files.
"""
SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
"""

__author__ = "Mārtiņš Avots"
__authors__ = ["and other"]
__copyright__ = "Copyright 2021"
__license__ = "EPL-2.0 OR GPL-2.0-or-later"
This is the license header for Python 3 files.
<!--
  SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
  SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
-->
This is the license header template for HTML and XML files.
----
* SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
* SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
----
This is the license header template for CommonMark files.
----
SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later
SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
----
This is the license header template for CommonMark files used for Hugo. There is a distinction between Hugo files and CommonMark files, because the formatting of the header does not look good in the Hugo format, if the document is rendered by a renderer other than Hugo itself.

The license file in the top level folder has to contain all licensing of the information (like source code and documentation) in this repository. The actual full license text has to be present in the license file, in order to ensure that everything is present. The license file has to contain all licensing of bundled dependencies in a distribution.

Each file should have its own licensing info. In other words licensing is done on a per-file basis. It is recommended, that the licensing info is located in the licensed files itself. This is usually done via copyright headers.

Alternatively, Licensing info of a file can be split into a separate file, but each such file needs its own separate licensing file. This is separate licensing file should be in the same folder as the file with the actual content. Their relation should be clearly visible by using the same file prefix.

Every copy and distribution of this project should contain copies of the licenses, the notice and the license file of all present components in general. Also, always provide a list of all components and their attributions. They should be easily findable via top level files, whereby linking to further files is acceptable and often good in order to avoid cluttering the top level folder. If the distribution is in the form of a program etc., it should provide this information in its native way easily.

It is recommended to not change the licensing of the project's components and leave these in its original form.

Apache-2.0:

  1. Provide license file, attribution and license notice.
  2. Provide NOTICE, when the component is bundled.
  3. State changes done to these if any.

BSD-2-Clause:

  1. Provide license file.
  2. Provide copyright notice and attribution.

BSD-3-Clause:

  1. Provide license file.
  2. Provide copyright notice and attribution.

EPL-2.0:

  1. Provide license file, attribution and license notice.
  2. When distributed provide NOTICE, source code or working link to source code.
  3. Do not mix EPL 2.0 code with other code, because of the EPL 2.0 copy left nature. EPL 2.0 code and other licensed code should be kept in separate projects.
  4. Point to NO WARRANTY and DISCLAIMER OF LIABILITY in distributions.
  5. This is weak copy left.

ISC:

  1. Provide license file.
  2. Provide copyright notice and attribution.

LGPL-2.1-or-later:

  1. Link to or provide original source code.
  2. Provide license file, copyright notice and attribution.
  3. Statically linked/bundled requires a way to change or replace this dependency.
  4. Sublicensing is not allowed.
  5. This is weak copy left.

MIT:

  1. Provide license file.
  2. Provide copyright notice and attribution.

MPL 2.0:

  1. Provide license file.
  2. Provide copyright notice and attribution.
  3. This is weak copy left.
  4. Link to or provide original source code.

The Linux kernel and Git are the main role models for this.

CTAs (copyright transfer agreement) and CLAs (copyright licensing aggreements) are not required by default, because the meaning, usage, effects, consequence, etc. of this are hard to manage and understand. Keep in mind, that the legal system in USA works different from the legal system of the EU and Germany.

  1.  It Matters Who Owns Your Copylefted Copyrights 
  2.  Owning Your Own Copyrights in Open Source 
  3.  Why Your Project Doesn't Need a Contributor Licensing Agreement 
  4.  What is ContractPatch? 

The CONTRIBUTING.md and the Developer_Certificate_of_Origin.v1.1.txt are used as contribution guidelines. Support information and tutorials will also be added as they are needed.