On Tue, Aug 17, 2021 at 6:22 PM Richard Fontana <
rfontana@...> wrote:
On Tue, Aug 17, 2021 at 3:48 PM Warner Losh <imp@...> wrote:
>
> I would suggest, though, that if we do this we strongly discourage people from using these identifiers
> for the 'copyright + SPDX-Identifier but no boilerplate' license scenarios.
Hi Warner,
Can you explain what you mean by "copyright + SPDX-Identifier but no
boilerplate"? Sorry if it's obvious. :-)
Sure. SPDX arouse as a way to cope with the variations on different licenses by providing a
set of templates, with variations, to match. Since these variations had no legal differences,
this was viewed as a reasonable simplification.
Some time later, different open source projects noticed that there was a large trove of
licenses and that providing a simple pointer to the license would help reduce the proliferation
of texts and be easier to manage.
So, things went from having the following at the top of all the files
* Copyright (c) 2013 Some Author
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <
http://www.gnu.org/licenses/>.
to something simpler like at the top.
* Copyright (c) 2021 Jane Author
*
* SPDX-License-Identifier: GPL-2.0-or-later
which simplifies things greatly, but only if everybody involved knows and understands where to
find this "GPL-2.0-or-later". So as it's copied around, everybody knows it's GPL'd code v2 or
later. You can go to the SPDX web site to find this and it's clear.
My concern is that if there starts to be Fedora--FooLicense in this situation, and it's copied
around and time passes, what guarantees are there that Fedora will be as careful about
keeping a historical list of these things as the SPDX folks have been. And I mean no disrespect
to Fedora specifically, mind you, to be clear. It's just thinking ahead to code that's passed
from hand to hand to some project that's not Fedora, how will they know what all they
can do with the code.
> Since Fedora--, etc isn't
> well standardized, is only a place holder until standardization, and therefore generally expected
> to be ephemeral, this may create issues in establishing which license is talked about, especially
> if the code is copied away from one of those distributions and a fair amount of time has passed.
It's probably important to note that the current interest in adoption
of SPDX identifiers for Fedora is specifically limited to a
replacement for Fedora's longstanding "Callaway" system of license
identifiers which are pretty much exclusively used in RPM spec file
license metadata, thus analogous to other uses of SPDX or pseudo-SPDX
identifiers in package metadata seen in recent years. Thus I don't
think we are talking about scenarios where there would be copying away
of code in the sense I think you mean, but we could expect derivative
distributions to inherit the use of identifiers in RPM metadata much
as happens today.
It's not totally inconceivable that Fedora-related projects may
someday come to adopt use of the SPDX-License-Identifier construct in
source files to some degree, since some Red Hat engineers (many of
whom of course are active in Fedora-related projects) have begun to do
so. I would guess there is some such use in some Fedora-related
projects already. But historically practices of that sort have been
outside the scope of what Fedora has attempted to provide rules or
guidance on and I'm not sure I would expect that to change.
My concern is to communicate it from the SPDX group in some way that's uniform and fair so
that expectations are clear. This would include the range of possible uses that would run
from what your use case (having it in a meta file to describe things in a more uniform
way in a constrained environment that has limited lifetimes and any obsolete designators
are easy to find ane replace ) through the possible inclusion in code that gets copied and
passed around and may pop up years from now with an unclear license, leading to
uncertainty and doubt.
Warner
Richard
>
> Warner
>
> On Tue, Aug 17, 2021 at 11:41 AM Alexios Zavras <alexios.zavras@...> wrote:
>>
>> Since we're all expressing agreement, let me add mine...
>> and remind that we have this wonderful construct that can be used for "list of licenses curated by a single entity but not necessarily on the SPDX License List": namespaces!
>> We can have a couple of hundred "Fedora--" or "Debian--" identifiers immediately, while waiting for the official inclusion in the list.
>>
>> -- zvr
>>
>> -----Original Message-----
>> From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Matija Šuklje
>> Sent: Tuesday, 17 August, 2021 16:35
>> To: spdx-legal@...
>> Subject: Re: SPDX License List coverage for a full distro
>>
>> Die 16. 08. 21 et hora 19:10 J Lovejoy scripsit:
>> > What do you all think?
>>
>> I don’t have much to add to what has been said so far, but just want to add a big fat +1 on everything said so far.
>>
>>
>> cheers,
>> Matija
>> --
>> gsm: tel:+386.41.849.552
>> www: https://matija.suklje.name
>> xmpp: matija.suklje@...
>> sip: matija_suklje@...
>>
>>
>>
>>
>>
>>
>>
>> Intel Deutschland GmbH
>> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
>> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
>> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
>> Chairperson of the Supervisory Board: Nicole Lau
>> Registered Office: Munich
>> Commercial Register: Amtsgericht Muenchen HRB 186928
>>
>>
>>
>>
>>
--
