mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Roland Hieber <rhi@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH 2/2] doc: working with licensing information in packages
Date: Fri, 29 May 2020 10:27:04 +0200	[thread overview]
Message-ID: <20200529082704.samisjejtieiucs7@pengutronix.de> (raw)
In-Reply-To: <20200529062346.GB31789@pengutronix.de>

On Fri, May 29, 2020 at 08:23:46AM +0200, Michael Olbrich wrote:
> On Mon, May 11, 2020 at 12:03:06PM +0200, Roland Hieber wrote:
> > Co-authored-by: Felicitas Jung <f.jung@pengutronix.de>
> > Signed-off-by: Felicitas Jung <f.jung@pengutronix.de>
> > Signed-off-by: Roland Hieber <rhi@pengutronix.de>
> > ---
> >  doc/contributing.rst        |   5 +
> >  doc/daily_work.inc          |   2 +
> >  doc/daily_work_licenses.inc | 208 ++++++++++++++++++++++++++++++++++++
> >  doc/ref_make_variables.inc  |   4 +
> >  4 files changed, 219 insertions(+)
> >  create mode 100644 doc/daily_work_licenses.inc
> > 
> > diff --git a/doc/contributing.rst b/doc/contributing.rst
> > index 705f01377d32..7352b46dfcf0 100644
> > --- a/doc/contributing.rst
> > +++ b/doc/contributing.rst
> > @@ -90,6 +90,11 @@ For new packages, the generated templates contain commented-out default
> >  sections. These are meant as a helper to simplify creating custom stages.
> >  Any remaining default stages must be removed.
> >  
> > +New packages should also have licensing information in the ``<PKG>_LICENSE``
> > +and ``<PKG>_LICENSE_FILES`` variables.
> > +Refer to the section :ref:`licensing_in_packages` for more information.
> > +
> > +
> >  Helper Scripts
> >  --------------
> >  
> > diff --git a/doc/daily_work.inc b/doc/daily_work.inc
> > index a37aac4c3339..f68d25bf7cb5 100644
> > --- a/doc/daily_work.inc
> > +++ b/doc/daily_work.inc
> > @@ -1472,3 +1472,5 @@ be enabled. A used mount option of the overlayfs in the default
> >  newer.
> >  If your kernel does not meet this requirement you can provide your own local
> >  and adapted variant of the mentioned mount unit.
> > +
> > +.. include:: daily_work_licenses.inc
> > diff --git a/doc/daily_work_licenses.inc b/doc/daily_work_licenses.inc
> > new file mode 100644
> > index 000000000000..7e90b7ba541d
> > --- /dev/null
> > +++ b/doc/daily_work_licenses.inc
> > @@ -0,0 +1,208 @@
> > +.. _licensing_in_packages:
> > +
> > +Tracking licensing information in packages
> > +------------------------------------------
> > +
> > +PTXdist aims to track licensing information for every package.
> > +This includes the license(s) under which a package can be distributed,
> > +as well as the respective files in the package's source tree that state those terms.
> > +Sadly there is no widely adopted standard for machine-readable licensing
> > +information in source code (`yet <https://reuse.software>`_),
> > +so here are a few hints where to look.
> > +
> > +There are many older package rules in PTXdist which don't specify licensing information.
> > +If you want to help complete the database,
> > +you can use ``grep -L _LICENSE_FILES rules/*.make`` (in the PTXdist tree) to find those rules.
> > +Note however that this cannot find wrong or incomplete licensing information.
> > +
> > +Finding licensing information
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +You should first select and extract the package in question, and then have a
> > +look at in the extracted package sources (usually something like
> > +``platform-nnn/build-target/mypackage-1.0`` in your BSP, if in doubt see
> > +``ptxdist package-info mypackage``).
> > +
> > +* Check for files named ``COPYING``, ``COPYRIGHT``,  or ``LICENSE``.
> > +  These often only contain the license text and, in case of GPL, no information
> > +  if the code is available under the *-only* or *-or-later* variant.
> > +  Sometimes these files are in a folder ``/doc`` or ``/legal``.
> > +
> > +* Check the ``README``, if there is any.
> > +  Often there is important information there, e.g. in case of GPL if the
> > +  software is *GPL-x.x-or-later* or *GPL-x.x-only*.
> > +
> > +* Check some relevant-sounding files, like ``main.c`` for license headers.
> > +  Often additional information can be found here.
> 
> This is too lax for me. Unless there is an explicit statement that all code
> has the same license, all source files must be checked. Especially older
> projects have a few files that where copied from somewhere else and have a
> different license.

Yes, right.

> > +
> > +* If you want to be extra sure, use a license compliance toolchain (e.g.
> > +  `FOSSology <https://www.fossology.org/>`__) on the project.
> > +
> > +On the other hand, there are some things that can be ignored for our purposes:
> > +
> > +* Everything that is auto-generated, either by a script in the project source,
> > +  or by the build system previous to packaging.
> > +  The generator itself cannot hold copyright, although the authors of the
> > +  templates used for the generation or the authors of the generator can.
> > +
> > +* Most files belonging to the build system don't make it into the compiled code
> > +  and can therefore be ignored (e.g. configure scripts, Makefiles).
> > +  These cases sometimes can be hard to detect – if unsure, include the file in
> > +  your research.
> > +
> > +Distillation down to license identifiers
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +We use the `SPDX license identifiers <https://spdx.org/licenses/>`_.
> > +
> > +Either the license is clear, e.g. because it says "GPL 2.0" (roughly check the
> > +license content to be sure), or you can use tools like
> > +`FOSSology <https://www.fossology.org>`__,
> > +`licensecheck <https://wiki.debian.org/CopyrightReviewTools#Command-line_tools_in_Debian>`_,
> > +or `spdx-license-match <https://github.com/rohieb/spdx-license-match>`_
> > +to detect license material in the project.
> > +
> > +License texts don't have to match exactly, you should apply the
> > +`SPDX Matching Guidelines <https://spdx.org/spdx-license-list/matching-guidelines>`_
> > +accordingly.
> > +The important part here is that the project's license and the SPDX identifier
> > +describe the same licensing terms.
> > +"Rather close" or "mostly similar" statements are not enough for a match,
> > +but simple unimportant changes like replacing *"The Author"* with the project's
> > +maintainer's name, or a change in e-mail adresses, are usually okay.
> > +
> > +For software that is not open-source according to the `OSI definition
> > +<https://opensource.org/osd>`_, use the identifier ``proprietary``.
> > +
> > +If no license identifier matches, use ``unknown``.
> > +If the project is considered open source or free software, you can
> > +`report its license to be added to the SPDX license list
> > +<https://github.com/spdx/license-list-XML/blob/master/CONTRIBUTING.md#request-a-new-license-or-exception-be-added-to-the-spdx-license-list>`_.
> 
> I think I'd like to use something else here. Right now 'unknown' mostly
> means "nobody looked at this yet". I want something else to say "I looked
> at this and here it the license text but there is no SPDX identifier".
> I'm considering the package name to make it unique. But that has the
> downside, that it's not easily found.
> Suggestions?

In the IRC channel, someone suggested using "custom" instead, since it is
apparently used by other distros. We could also use it as a prefix and
combine it with the package name, but I think this becomes a problem
when multiple "unknown" cases happen in one package.

> > +Conflicting statements
> > +^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Human interpretation is needed when statements inside the project conflict with
> > +each other.
> > +Some clues that can help you decide:
> > +
> > +Detailedness:
> > +  If the header in COPYING or the README says *"GNU General Public License"*,
> > +  but the license text is in fact a BSD license, the correct license is the BSD
> > +  license.
> > +
> > +Author Intent:
> > +  If the README says *"this is LGPL 2.1"*, but COPYING contains a GPL boilerplate
> > +  license text, the correct licensing information is probably *"LGPL 2.1"* –
> > +  the README written by the author prevails over the boilerplate text.
> > +
> > +Recency:
> > +  If README and COPYING are both clearly written by the author themselves, and
> > +  the README says *"don't do $thing*" and COPYING says *"do $thing*", the more
> > +  recent file prevails.
> > +
> > +  .. note::
> > +
> > +   Any of such cases is considered a bug and should be reported to the upstream maintainer!
> > +
> > +License versions, and GPL-vv-only or GPL-vv-or-later?
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +If the ``COPYING`` file is a GPL text, it is still uncertain if the correct
> > +license identifier is *GPL-vv-only* or *GPL-vv-or-later*.
> > +The GPL text itself does not give information on that in its terms and
> > +conditions.
> > +Sometimes there is a notice at the top of the COPYING or the README file stating
> > +whether *"-only"* or *"-or-later"* applies – this is the easy case.
> > +Otherwise: check headers in relevant files.
> > +
> > +If no license information can be found, but one file mentions e.g. *"GPL-vv or
> > +later"*, use that information for the whole project.
> > +E.g.: no license information can be found except a ``COPYING`` which contains
> > +a GPL-2.0 text → the license is GPL-2.0-only.
> > +
> > +Sometimes the best information available is statements like
> > +*"this code is under GPL"* without any version information.
> > +Such cases should be interpreted as the most liberal reading,
> > +i.e. *GPL-1.0-or-later* (any possible GPL version).
> 
> I'm not sure this is good. I would say, when in doubt then be restrictive.
> After all, this is about compliance. If we comply with the more restrictive
> interpretation then we also comply with more liberal interpretations.

What would being restrictive look like? We don't have any good pointers
as to what license to use here.

 - Roland

> > +If multiple versions and variants can be found in the project, combine them with
> > +``AND``, e.g.: ``GPL-2.0-only AND GPL-2.0-or-later`` in the license identifier.
> 
> This should also mention `OR` for a license choice.
> 
> Michael

-- 
Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de

  reply	other threads:[~2020-05-29  8:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 10:03 [ptxdist] [PATCH 1/2] doc: ref_make_variables: link to the SPDX license list Roland Hieber
2020-05-11 10:03 ` [ptxdist] [PATCH 2/2] doc: working with licensing information in packages Roland Hieber
2020-05-26 10:29   ` Roland Hieber
2020-05-26 11:12   ` Alexander Dahl
2020-05-29  6:23   ` Michael Olbrich
2020-05-29  8:27     ` Roland Hieber [this message]
2020-05-29  8:55       ` Michael Olbrich
2020-05-29  9:40         ` Roland Hieber
2020-05-29 12:03           ` Michael Olbrich
2020-05-31 19:56             ` Roland Hieber
2020-06-02 13:16               ` Michael Olbrich
2020-06-02 15:14                 ` Roland Hieber
2021-06-08 10:36 ` [ptxdist] [PATCH] " Roland Hieber
2021-06-16 14:19   ` Michael Olbrich
2021-06-16 14:40     ` Roland Hieber
2021-08-05  9:18     ` [ptxdist] [PATCH v3] " Roland Hieber
2021-08-06  6:29       ` Michael Olbrich
2021-08-06 10:44         ` [ptxdist] [PATCH] " Roland Hieber
2021-10-07 10:18           ` [ptxdist] [APPLIED] " Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200529082704.samisjejtieiucs7@pengutronix.de \
    --to=rhi@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox