wide screen

Determine licensing and contribution protocol.

Initial Author: Mārtiņš Avots

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

DONE Determine licensing.
- DONE Determine licensing for software code.
- DONE Determine licensing for documentation.
DONE Implement licensing.
- DONE Add copy of licenses to repo.
- DONE Determine license obligations.
- DONE Templates
- DONE Determine and create license related files.
- DONE Define copyright headers.
- DONE Add copyright headers.
  - DONE net.splitcells.dem
  - DONE net.splitcells.gel
  - DONE net.splitcells.gel.core
  - DONE net.splitcells.gel.doc
  - DONE net.splitcells.gel.sheath
  - DONE net.splitcells.network.blog
  - DONE net.splitcells.os.state.interface
  - DONE net.splitcells.os.state.interface.lib
  - DONE net.splitcells.pom.java.defaults
  - DONE net.splitcells.ses
  - DONE net.splitcells.system
  - DONE net.splitcells.website.default.content
  - DONE net.splitcells.website.server
- DONE Fulfill license obligations.
- DONE Consider all licenses in notice file.
- DONE Document third party content licensing.
  - DONE net.splitcells.dem
  - DONE net.splitcells.gel
  - DONE net.splitcells.gel.core
  - DONE net.splitcells.gel.doc
  - DONE net.splitcells.gel.sheath
  - DONE net.splitcells.network.blog
  - DONE net.splitcells.os.state.interface
  - DONE net.splitcells.os.state.interface.lib
  - DONE net.splitcells.pom.java.defaults
  - DONE net.splitcells.ses
  - DONE net.splitcells.system
  - DONE net.splitcells.website.default.content
  - DONE net.splitcells.website.server
- DONE Remove old license information.
  - DONE net.splitcells.os.state.interface
  - DONE net.splitcells.os.state.interface.lib
- DONE Determine secondary licensing requirements.
- DONE Create attributions files for not bundled third party content.
- DONE Create guidelines for notice and license file.
- DONE Note needed changes for future binary distributions.
- DONE Create top level legal document, where everything relevant including tickets are linked.
- DONE Have copies of all relevant licenses.
DONE Organize contributions.
DONE Sign project and document project founder's (Mārtiņš Avots) public keys.

Following sites were used as a kind of general guide:

History

With the ticket #86 the GPL licensing was removed, because the dependencies of the project are not compatible with GPL. With the ticket #88 GPL compatibility is planned for the core code.

Determine licensing.

When referring to a license use its full name or its SPDX-License-Identifier.

Licensing Goal

Dual licensing the program source code under the MIT and EPL 2.0 with the secondary licenses notice is considered the solution. Thereby, one can relicense the project, if the license is considered to be incorrect. On the other hand, one can still switch to EPL 2.0 only, if the license is considered to be correct.

The rest of the source code is licensed like program source code.

This does not apply to external dependencies.

Understanding

To my 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.

Reasoning

Before that, dual licensing the program source code under MIT and Apache 2.0 was considered 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.

I also looked for alternative licenses, which provided extended copyright protection via copyleft (example argumentation context for copyleft). I wanted some additional protections, but did view strong copyleft a bit harmful (example problem), because its bounds are not very clearly defined. Consider the fact, that there was a legal battle in the USA, about the question if APIs are copyrightable, and the historic problems of defining the bounds of strong copyleft licenses.

MPL 2.0 was considered, but the termination clause seems 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. I 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 for me.

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 (additiona source). They adapted the termination clause of the GPL 3.0, which is very similar with the termination clause of the MPL 2.0, but this does not personally make me comfortable with the termination clause of MPL 2.0.

Next I considered the EPL 2.0. 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 also enables some extended copyright protections, while offering similar license compatibility, so dual licensing with MIT and EPL 2.0 was adopted.

Implementation

The Eclipse Foundation Project Handbook is used as a guide in order to determine licensing related file layout and license notices.

Detailed information about EPL 2.0 can be found here.

Licensing On Project Basis

Every project in this repo is licensed under the same license. Not every project needs a dedicated license info. For now, it is enough if the license notice file is located at the top root folder.

The LICENSE.md provides links to all licensing information and also needs to explicitly state the licensing of the project files without accounting for third party content (i.e. dependencies).

Notice File

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: [...]

File License Header

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

/*
 * Copyright (c) 2021 Mārtiņš Avots (Martins Avots) and others
 *
 * 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, or the MIT License,
 * which is available at https://spdx.org/licenses/MIT.html.
 *
 * SPDX-License-Identifier: EPL-2.0 OR MIT
 * 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 MIT
# SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects

This is the license header template for Bash, sh and .gitignore files.

"""
SPDX-License-Identifier: EPL-2.0 OR MIT
SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
"""

__author__ = "Mārtiņš Avots"
__authors__ = ["and other"]
__copyright__ = "Copyright 2021"
__license__ = "EPL-2.0 OR MIT"

This is the license header for Python 3 files.

<!--
  SPDX-License-Identifier: EPL-2.0 OR MIT
  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 MIT
* SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects

For CommonMark files the meta data should be at the end of the document, because not every renderer can display meta data in a nice way. The empty line at the start of the suffix ensures, that it is rendered correctly.

If the file is too big and therefore the license info is too far away from the start, the license info should be at the very start of the document in the following way:

----
* SPDX-License-Identifier: EPL-2.0 OR MIT
* SPDX-FileCopyrightText: Contributors To The `net.splitcells.*` Projects
----

License File

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.

License Information on File Basis

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.

License Obligations

Default

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.

Overview of License Specific License Obligations

Apache-2.0:

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

BSD-2-Clause

Provide license file.
Provide copyright notice and attribution.

BSD-3-Clause

Provide license file.
Provide copyright notice and attribution.

GPL-2.0-or-later WITH Classpath-exception-2.0

This license is not accepted for third party content of a project at the moment.

EPL-2.0

Provide license file, attribution and license notice.
When bundled provide NOTICE, source code or working link to source code.
Generally, do not provide third party code
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.
Point to NO WARRANTY and DISCLAIMER OF LIABILITY in distributions.
This is weak copy left.
ISC
Provide license file.
Provide copyright notice and attribution.
LGPL-2.1-or-later
Link to or provide original source code.
Provide license file, copyright notice and attribution.
Statically linked/bundled requires a way to change or replace this dependency.
Sublicensing is not allowed.
This is weak copy left.

MIT

Provide license file.
Provide copyright notice and attribution.

MPL 2.0

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

Organize Contributions

Determine contribution protocol.

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.

https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/
https://blog.hansenpartnership.com/owning-your-own-copyrights-in-open-source/
https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
https://sfconservancy.org/contractpatch/

Determine contribution documents.

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.

Interesting Third Party Documents

SPDX-License-Identifier: EPL-2.0 OR MIT
SPDX-FileCopyrightText: Contributors To The net.splitcells.* Projects

SPDX-License-Identifier: EPL-2.0 OR MIT
SPDX-FileCopyrightText: Contributors To The net.splitcells.* Projects