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 <[email protected]> > > Signed-off-by: Felicitas Jung <[email protected]> > > Signed-off-by: Roland Hieber <[email protected]> > > --- > > 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. | [email protected] | 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 [email protected] To unsubscribe, send a mail with subject "unsubscribe" to [email protected]
