Legal considerations for contributors¶
The copyright holder for all source files of the Lino framework is Rumma & Ko Ltd. This is our pragmatic choice as long as we are the community motor and provide infrastructure for coordinating the work of all contributors. The members of the Lino community trust us to manage things correctly. We made these choices in order to avoid vendor lock-in and because we want Lino to be Sustainably Free Software.
Without this choice, the copyright holder would be an informal group, e.g. "The Lino developers". This would have certain disadvantages regarding personal liability, lack of a framework for management or mistakes regarding tax obligations (more about this for example here). That's why we have the Contributor License Agreement.
Contributor License Agreement¶
Before we can use your code contribution, you must give us permission to do so. You remain the author of your contributions, but you give us the right to integrate your work into Lino and to publish it under the AGPL.
You must do this by signing the Lino Contributor License Agreement in a way that is legally valid. We are still searching an easy method for doing this, but meanwhile it seems that you must either have an Estonian ID card (Estonia has a national software DigiDoc for digitally signing), or print the document, sign it on paper, and send us photos of (1) your national ID card and (2) the signed document.
We apologize for the inconveniences. They are because you remain the copyright owner of your changes even after your contribution gets merged into our codebase. We cannot use your contribution if you don't sign this document. Just imagine that somebody would infringe copyright, e.g. by making a non-free fork, and we would decide to protect Lino by going to court: without a clear and unique legal copyright holder the infringer could use nasty tricks to escape justice.
As a contributing developer you should care about the risk that Lino, like any Free Software product, might get jeopardized by a Rights-Ratchet Model. To avoid this risk, paragraph (3) of our CLA explicitly states that we "shall not use Your Contributions in a way that is contrary to the license terms in effect at the time of the Contribution."
Coding standards¶
Any new source code file should start with the following header:
# -*- coding: UTF-8 -*-
# Copyright AAAA-ZZZZ Rumma & Ko Ltd
# License: GNU Affero General Public License v3 (see file COPYING for details)
The start year (AAAA) should be the year of first publication. If your file is based on an existing file, keep the original value of AAAA. When updating a file, check the end year (ZZZZ) and increase it if needed. We write only the start and the end year. Anyway these year numbers are informative, in case of a dispute the git history would be authoritative.
The FSF recommends to add a quite long header with three paragraphs of text to each source file. This long header was one of the major reasons why we changed from GPL to BSD in October 2016. In April 2021 we switched back to GPL (and even to the strictest of them, the AGPL) after realizing that actually we don't need follow this recommendation. We assume that a one-line header is enough to protect the code from accidentally being separated from its license.
Standard files¶
Every repository should contain the following four files in its root directory:
- README.rst¶
A file named
README
(or some variant thereof) should be in the root directory of every public code repository and should contain a description of the project, links to more detailed documentation, ...In Lino projects this file is automatically generated by the
inv bd
command from the long_description in yoursetup_info.py
file.
- CONTRIBUTING.rst¶
Explains how to contribute. For repositories maintained by Rumma & Ko Ltd this just links to Contributor Guide.
- AUTHORS.rst¶
Lists all source contributors. This is a reviewed output of
git shortlog --summary --numbered --email
.
- COPYING¶
The content of these files should be the same for all repositories that are part of the Lino framework. The book repository is considered the master copy: if we change any thing in one of these files, the other repositories should copy the new version as soon as possible.