[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package licenses - use of SPDX identifiers
From: |
Oliver Heimlich |
Subject: |
Re: package licenses - use of SPDX identifiers |
Date: |
Sun, 07 Feb 2016 22:15:51 +0100 |
User-agent: |
K-9 Mail for Android |
Am 7. Februar 2016 22:03:00 MEZ, schrieb "Carnë Draug" <address@hidden>:
>On 7 February 2016 at 10:27, Oliver Heimlich <address@hidden> wrote:
>> Am 7. Februar 2016 01:51:24 MEZ, schrieb "Carnë Draug"
><address@hidden>:
>>>Hi everyone
>>>
>>>A couple of years ago, downstream packagers complained that Octave
>>>Forge
>>>packages were not consistent on naming the license on the DESCRIPTION
>>>file which made it harder for them to automate license checks and
>>>packaging.
>>>
>>>Because of that, Octave Forge packages use all the same identifiers
>for
>>>the
>>>licenses but it was something made up by us at the time. Turns out
>>>that
>>>there are standard identifiers for the licenses which we should be
>>>using
>>>instead [1].
>>>
>>>This was brought up recently by Colin Macdonald [2] who's been doing
>>>some
>>>work on making Octave Forge appear nicely in package managers [3].
>>>
>>>So unless someone opposes it, I propose that future packages make use
>>>of
>>>those identifiers.
>>>
>>>Carnë
>>>
>>>[1] https://spdx.org/licenses/
>>>[2]
>>>https://lists.gnu.org/archive/html/octave-maintainers/2016-01/msg00133.html
>>>[3]
>>>https://lists.gnu.org/archive/html/octave-maintainers/2016-01/msg00114.html
>>
>> The DESCRIPTION file is not meant to be machine readable by anything
>but
>> Octave's pkg command and he generate_html package. If we really want
>to
>> address easier license checks and automated packaging, using a
>different
>> license ID is not enough. Currently, downstream has to scan each file
>in
>> the package anyway.
>>
>> We would have to distribute actual SPDX files with the packages.
>These
>> would contain machine readable license information about the package
>as
>> a whole and single files within the package. (You can think of it as
>a
>> superset of the information in a debian/copyright file in XML
>format.)
>>
>> Oliver
>
>Hmmm... So maybe packages could have those spdx files too and the
>DESCRIPTION
>files be generated as part of the release? I'm not sure if we should
>make
>this a requirement for packages or just suggest it though.
>
>Carnë
A requirement would be too much atm, given that the tooling for this file type
is still very poor. Also I don't know which downstream projects can actually
make use of spdx files.
Oliver