octave-maintainers
[Top][All Lists]
Advanced

[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  



reply via email to

[Prev in Thread] Current Thread [Next in Thread]