[Development] Documenting 3rd party license code (with SPDX?)

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 6 de junio de 2016 7:20:21 A. M. ART Kai Koehne wrote:
> tl;dr: Does anyone have experience with SPDX?

Not here, but...

> Qt modules contain quite some 3rd party code under various (permissible)
> licenses. We've been listening these in the
 documentation, but this is
> certainly improvable - while the list is (hopefully) comprehensive, it
> gives users little help in where the 3rd party code is actually used
> (library, plugin, platform), what to do to avoid it (configure arguments?),
> how to acknowledge distribution requirements ...
> 
> The list is also managed centrally in qtdoc.git, which requires a lot of
> effort to keep up to date with the other modules. 
 My first step to
> improve the situation is therefore to move the documentation to where the
> code is actually located. At the same time I think it's a good idea not to
> just write .qdoc, but use a more specific format that then can be
> processed. 
> What I'd like to suggest eventually is that
> - every code in our git modules where we don't have the relicensing rights
> for needs to be under a '3rdparty' folder
 - every folder needs a
> structured document that describes things like the license(s), copyright,
> where the code originated ... 
> And that we then automatically process the documents to generate the
> documentation.

With my Debian maintainer hat on I would really love to see this implemented 
not only because of 3rd party licenses (because we will still need to recheck 
non the less) but because it might become possible to:

- Now exactly how to avoid using the embedded code where possible
- Now which code can not be (currently) de embedded (an area we packagers 
would surely like to help with).
 
> Anyhow, first we have to settle on a file format. So far I have had a look
> at two file formats:
[snip]

For the sake of completeness, here's another one:

  <http://dep.debian.net/deps/dep5/>

Definitely not the panacea but just another option. The "possible" plus is 
that the initial work is already done, but can definitely be improved.

Some examples:

<http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/copyright>
<http://anonscm.debian.org/cgit/pkg-kde/qt/qttools.git/tree/debian/copyright>

We in Debian also have some tools to help us check for this kind of stuff 
(licensecheck, for example).

<http://manpages.ubuntu.com/manpages/precise/man1/licensecheck.1.html>

Again, not panacea, but...

> Personally I'm leaning
> towards defining our own customized JSON format that uses the best things
> from SPDX (standardized license id's) and README.Chromium. But I'd be glad
> to discuss with people interested in the topic :) 

Personally I would prefer to avoid defining a new standard *except* there is a 
good reason to do so.

-- 
6: Cual es el boton del mouse que permite acceder a las acciones mas
comunes del manejo de archivos
    * Depende el tipo de accion mas comun
    Damian Nadales
    http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160616/718aa464/attachment.sig>