Skip to content

License Cleanup Rationale and Implementation

Jump to bottom
Allan Nordhøy edited this page Apr 18, 2018 · 3 revisions

Rationale

  1. Validate and verify what the definitive license is for Pootle.
    1. So that we can ensure consistency in the license claims throughout the code.
    2. So that we know if we are able to update the licenses if required. E.g. are we using GPLv2 or GPLv2 and later.
  2. Reduce or eliminate the maintenance of headers in files.
    1. Header noise is confusing and detracts from code.
    2. Header copyright claims are sometimes used to claim credit, we think there is a better and fairer way to claim and show credit.
    3. Headers should be simple and easy and require no maintenance or thought.
  3. Document more fully the copyright history, the funders and major contributors.
    1. We don't just have code contributors we have contributors that have worked on Pootle for years. They deserver special mention.
    2. Funder have not added one line of code, but there would also be no code without them. We want to acknowledge them.
  4. Document clearly Pootle's copyright policy and views. E.g. why there is no copyright assignment and why it will, in fact has to remain as free software.
    1. We don't require or want copyright assignment. Contributors need to know that.
    2. Pootle's license terms and copyright holders are limited in their ability to make the product proprietary. That's a feature and we'd like to tell people about it.
  5. Relicense Pootle code.
    1. If the validation shows that we are allowed to relicense then we can proceed.
    2. As we use code with other license e.g. Apache we are technical not allowed to distribute them with our GPLv2 licensed code.

Findings

Pootle's definitive license is GPLv2 or later.

Pootle was first release under the GPLv2 or later license. This is from the __init__.py file for the very first Pootle commit.

Some of these early commits are only in Subversion as they were not ported to Git. The Subversion commits themselves are conversion of the original CVS repository.

  1. The first Pootle commit on Fri Oct 22 08:51:35 2004 UTC claim GPL2 and later
  2. The oldest tagged release is Pootle 0.6.1 and it claims GPL2 or later.
  3. The tarball for Pootle 0.8 says GPL2 or later (See Pootle-0.8.2005.0217/translate/pootle/__init__.py). This is the oldest release that we have available.

All of the license headers across Pootle code have been verified to be the standard GPLv2 boiler plate for GPLv2 or later.

Revised Header

We want a new simple header that:

  1. Points out the license terms simply and clearly
  2. Has no variable information as anything that varies needs maintenance and thought, we don't want to think about headers or have to maintain them:
    1. No dates - these change and often people forget to change them
    2. No credits - there are better places to put this like an AUTHORS file

Decisions:

  1. No dates - if you need dates these can be found in the git log or the COPYING file.
  2. No specific contributors - these are credited in the AUTHORS file and in git log.

Do we have to use the full GPLv2 header?

In the GPLv2 license, well actually in the section "How to Apply These Terms to Your New Programs" which appears after the "Terms and Conditions", the GPLv2 advises the following:

"[A]ttach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found."

GPLv2, "How to Apply These Terms to Your New Programs", 2nd paragraph

By default that has been interpreted as attaching that full notice to every single source files. The advice is actually that this is safest because of the warranty exclusion. But this ignores the "at least" part of this advice, which is what we will be following.

Thus our header should contain:

  1. The copyright line
  2. Pointer to the full notice

A similar, or best example, is the LibreOffice project.

LibreOffice has a detailed license breakdown for the product and for all included software. At the top level they have the licenses applicable to the product.

The LibreOffice MPL copyright header looks like this.

# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#

LibreOffice also includes a template of license header snippets

Decision

# Copyright (C) Pootle contributors.
#
# This file is a part of the Pootle project. It is distributed under the GPLv2
# license. See the LICENSE file for a copy of the license and the AUTHORS
# file for copyright and authorship information.

This has the following features:

  1. Simple and small
  2. Copyright header
  3. Statement of the license being used
  4. Pointer to the full license
  5. Pointer the the copyright holders

Additional headers

Pootle has been good at adding copyrights to code files but license headers are missing from other files that really should be licensed:

  • JavaScript
  • CSS
  • Gettext PO

However, for some file types we've chosen to not add these headers:

  • Django templates

For the following reasons:

  1. They are problematic the implement and obtrusive when implemented in the files.
  2. The files are not useful on their own outside of the body of work of Pootle. They are already covered by the LICENSE files and are unlikely to have any use outside of Pootle. And if they where they would need the associated CSS and JavaScript files which are explicitly licensed.

Moving to GPLv3

Pootle combines a number of source with other license which are incompatible with the GPL3v. We wanted to ensure that we are compliant with out own and other upstream license.

Moving to GPLv3 is possible as we're licensed under GPLv2 or later. Moving to any other license, including AGPL, would have required agreement from all code contributors and certain funders. Staying with GPL achieve our aim of the software being open source and the agreements reached with contributors and funders.

We are technically already operating as GPLv3 software because we combine licensed code that is only possible in GPLv3. So this exercise is in some ways a GPL license cleanup.

Clone this wiki locally