Re: SPDX license for Public Domain works?

[Richard Fontana]

Ah that's a good point. I wonder if the language could be tweaked a
bit to cover the "creative but out of copyright" case, but I'm not
sure it's worthwhile.

In Fedora's use of SPDX expressions, I think there is no situation
that would necessitate an SPDX identifier covering some
out-of-copyright work. There are packages I'm aware of that contain
such works (generally used for test purposes), but in those packages
Fedora's rules around use of SPDX expressions in package metadata
wouldn't require accounting for those works, I believe.

On Tue, Mar 26, 2024 at 3:09 PM David Foster
 wrote:
>
> The proposed license identifier Not-Copyrightable has the following text:
>
> The material covered by this statement is not creative or original, is
> trivial and non-expressive, and is believed to be non-copyrightable
> and in the public domain in all jurisdictions in which it may be
> published.
>
> That description doesn't seem appropriate for works that were once under 
> copyright (such as Mary Shelley's Frankenstein) but whose copyright term has 
> expired.
>
> Most of the works I'm attempting to mark are old works sourced from Project 
> Gutenberg whose copyrights have expired.
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3531): https://lists.spdx.org/g/Spdx-legal/message/3531
Mute This Topic: https://lists.spdx.org/mt/105158733/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: SPDX license for Public Domain works?

[Richard Fontana]

I submitted the following issue to add a "license" identifier that
could be used in this situation:
https://github.com/spdx/license-list-XML/issues/2294
(as a LicenseRef- this is already being used in the Fedora project).

I think the problem with the Public Domain Mark is that it's not a
license-like "text", so not something that SPDX could represent in its
license list or even properly something that could be represented by a
LicenseRef-.

Richard

On Tue, Mar 26, 2024 at 10:30 AM David Foster
 wrote:
>
> Let's say I have a work like Mary Shelley's Frankenstein which I believe to 
> be in the public domain. What SPDX license should I use to mark such a work 
> believed to be in the public domain?
>
>
>
> At first I thought CC-PDDC (Creative Commons Public Domain Dedication and 
> Certification) would be a good candidate but that deed has been deprecated 
> since 2010 in favor of:
>
> CC Public Domain Mark
> CC0 Public Domain Dedication
>
> Now it seems like the CC Public Domain Mark would be the most appropriate 
> alternative, but there does not appear to be a SPDX license identifier for it.
>
>
>
> So I have a few questions:
>
> 1. Is there an appropriate way to mark a Public Domain work using a SPDX 
> license?
> 2. Should the CC Public Domain Mark be added to the SPDX license list?
>
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3529): https://lists.spdx.org/g/Spdx-legal/message/3529
Mute This Topic: https://lists.spdx.org/mt/105158733/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: XML format is unsatisfactory

[Richard Fontana]

On Tue, Jan 16, 2024 at 8:51 PM Warner Losh  wrote:

> On Tue, Jan 16, 2024, 6:31 PM Richard Fontana  wrote:

>> But in a lot of these cases, the SPDX matching guidelines indicate
>> that the structural element is not important. For example, newlines
>> and blank lines are supposed to be equivalent to other whitespace. So
>> why does SPDX go to such lengths to preserve the structure of the
>> formatting of the originally-encountered version of the license text?
>> Why are  tags used at all, for example - aren't paragraph divisions
>> supposed to have no meaning for SPDX matching purposes? This is why I
>> say it seems that a lot of the reason for the complexity must be tied
>> to the goal of using the XML as a source form for generated formats
>> (HTML, plain text) that look sufficiently pretty or normal or
>> something, instead of focusing on using the XML as a basis for license
>> text matching.
>

> Becasue the licenses are also used to go the other way. From a tag to text. 
> Lots of open source projects, including the Linux Kernel,do this and if all 
> that structure were to go away, SPDX would be somewhat less useful to them.
>
> So for matching, they are useless. There is more to life than just matching.

Right, this seems to confirm something I've been saying, though I
don't know much about the history of SPDX. It seems that SPDX started
out focusing on the problem of matching license texts to template
matching texts, but expanded to a separate mission of maintaining an
authoritative repository of official and immediately usable HTML and
plain text renditions of license texts (necessitating some judgment by
the SPDX project on what the authoritative text ought to be in the
many cases where a template license contains specific elements that
can be matched against multiple alternative texts). That second
mission has influenced the format of particular XML files in numerous
ways.

Maybe I have the history backwards, I don't know. But this is what I
was suggesting seemed like a kind of mission creep that has resulted
in the XML files (including but not limited to the use of regular
expressions in the XML files) being unnecessarily complex and poorly
readable and maintainable. These two goals are in conflict, or at
least in tension.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3499): https://lists.spdx.org/g/Spdx-legal/message/3499
Mute This Topic: https://lists.spdx.org/mt/103724268/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: XML format is unsatisfactory

[Richard Fontana]

On Mon, Jan 15, 2024 at 10:09 AM Zavras, Alexios
 wrote:

> Then we have the data: it started out as pure text, then we wanted to have 
> some structure (split into paragraphs, or bullet lists), then we had to 
> represent that some parts of the text are optional (they could be present or 
> not), then there were also alternatives (something must be there, but maybe 
> the content is not arbitrary).

But in a lot of these cases, the SPDX matching guidelines indicate
that the structural element is not important. For example, newlines
and blank lines are supposed to be equivalent to other whitespace. So
why does SPDX go to such lengths to preserve the structure of the
formatting of the originally-encountered version of the license text?
Why are  tags used at all, for example - aren't paragraph divisions
supposed to have no meaning for SPDX matching purposes? This is why I
say it seems that a lot of the reason for the complexity must be tied
to the goal of using the XML as a source form for generated formats
(HTML, plain text) that look sufficiently pretty or normal or
something, instead of focusing on using the XML as a basis for license
text matching.

I understand the need to indicate various kinds of optional or
alternative elements in some license texts, but I wonder if there
isn't a simpler, more minimalist way to achieve this than what I
generally see in the XML files.

Richard

> Sent: Monday, 15 January, 2024 06:29
> To: Richard Fontana 
> Cc: SPDX-legal 
> Subject: Re: XML format is unsatisfactory
>
> Quoting Richard Fontana (2024-01-15 06:22:47)
> > On Mon, Jan 15, 2024 at 12:01 AM Jonas Smedegaard  wrote:
> > >
> > > Quoting Richard Fontana (2024-01-14 23:41:55)
> > > > On Sun, Jan 14, 2024 at 2:47 PM Jonas Smedegaard  wrote:
> > > >
> > > > > The XML files is a representation of RDF.
> > > > >
> > > > > Another more human readable and editable RDF repræsentation
> > > > > exists which is a *lossless* conversion: Turtle.
> > > > >
> > > > > On a Debian-based system, you can see how MIT license looks as
> > > > > Turtle by installing te package raptor2-utils, an then run this 
> > > > > command:
> > > > >
> > > > >   rapper -i rdfxml -O http://spdx.org/licenses/ -o turtle
> > > > > MIT.rdf
> > > >
> > > > This sounds interesting but:
> > > >
> > > > [ref@charlie ~]$ rapper -i rdfxml -O http://spdx.org/licenses/ -o
> > > > turtle MIT.rdf
> > > > rapper: Parsing URI MIT.rdf with parser rdfxml
> > > > rapper: Serializing with serializer turtle and base URI
> > > > http://spdx.org/licenses/ @base <http://spdx.org/licenses/> .
> > > > rapper: Error - URI MIT.rdf - Resolving URI failed: Could not
> > > > resolve
> > > > host: MIT.rdf
> > > > rapper: Failed to parse URI MIT.rdf rdfxml content @prefix rdf:
> > > > <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> > > >
> > > > rapper: Parsing returned 0 triples
> > >
> > > Sorry, I thought it was obvious but realize now that I should have
> > > been
> > > explicit: You need to `cd` to the path where the MIT.rdf is located
> > > - i.e. you need to checkout the git repository for the sources first.
> >
> > Ah, I see. So:
> >
> > [ref@charlie rdfxml]$ rapper -i rdfxml -O http://spdx.org/licenses/ -o
> > turtle MIT.rdf
> > rapper: Parsing URI file:///home/ref/license-list-data/rdfxml/MIT.rdf
> > with parser rdfxml
> > rapper: Serializing with serializer turtle and base URI
> > http://spdx.org/licenses/ @base <http://spdx.org/licenses/> .
> > @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> > @prefix spdx: <../rdf/terms#> .
> > @prefix doap: <http://usefulinc.com/ns/doap#> .
> > @prefix ptr: <http://www.w3.org/2009/pointers#> .
> > @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> >
> > 
> > spdx:crossRef [
> > spdx:isLive false ;
> > spdx:isValid true ;
> > spdx:isWayBackLink false ;
> > spdx:match "N/A" ;
> > spdx:order "0"^^<http://www.w3.org/2001/XMLSchema#int> ;
> > spdx:timestamp "2024-01-05T20:12:47Z" ;
> > spdx:url "https://opensource.org/licenses/MIT; ;
> > a spdx:CrossRef
> > ] ;
> > spdx:isDeprecatedLicenseId false ;
> > spdx:isFsfLibre true ;
> > spdx:isOsiApproved true ;
> > spdx:licenseId "MIT" ;
> 

Re: XML format is unsatisfactory

[Richard Fontana]

On Mon, Jan 15, 2024 at 12:29 AM Jonas Smedegaard  wrote:
>
> Quoting Richard Fontana (2024-01-15 06:22:47)
> > On Mon, Jan 15, 2024 at 12:01 AM Jonas Smedegaard  wrote:
> > >
> > > Quoting Richard Fontana (2024-01-14 23:41:55)

> > This doesn't really seem to be any better than (and actually seems
> > worse than) the license-list-XML file "MIT.xml" for purposes of
> > readability and maintainability.
>
> How so?
>
> Because it doesn't look like YAML?

No, and I am not particularly an advocate for YAML (although, naively,
it seems like it would be an obvious candidate for an alternative to
XML, even if suboptimal for its own reasons). Maybe I should restate
what I think would be desirable:

- A *source format* that is relatively easy for humans to create,
read, understand, and modify. There are two separate (though
overlapping) groups of humans here: (1) contributors or potential
contributors to the project, and (2) users outside of this project
attempting to apply SPDX license identifiers in non-careless,
specification-conformant ways in real-world situations. My assertion
is that XML (or at least the form of XML used by this project) is
poorly suited to this purpose, and that real or hypothetical tools
cannot make this problem disappear (in part because of limits on
automatability of these problems). I don't think any format that is
generated from XML, or generated from XML in multiple stages with one
or more intermediate formats, addresses the problem. XML might however
be suitable as a sort of tools-consumable object code format generated
from the hypothetical source format I am talking about.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3495): https://lists.spdx.org/g/Spdx-legal/message/3495
Mute This Topic: https://lists.spdx.org/mt/103724268/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: XML format is unsatisfactory

[Richard Fontana]

On Mon, Jan 15, 2024 at 12:01 AM Jonas Smedegaard  wrote:
>
> Quoting Richard Fontana (2024-01-14 23:41:55)
> > On Sun, Jan 14, 2024 at 2:47 PM Jonas Smedegaard  wrote:
> >
> > > The XML files is a representation of RDF.
> > >
> > > Another more human readable and editable RDF repræsentation exists
> > > which is a *lossless* conversion: Turtle.
> > >
> > > On a Debian-based system, you can see how MIT license looks as Turtle
> > > by installing te package raptor2-utils, an then run this command:
> > >
> > >   rapper -i rdfxml -O http://spdx.org/licenses/ -o turtle MIT.rdf
> >
> > This sounds interesting but:
> >
> > [ref@charlie ~]$ rapper -i rdfxml -O http://spdx.org/licenses/ -o turtle 
> > MIT.rdf
> > rapper: Parsing URI MIT.rdf with parser rdfxml
> > rapper: Serializing with serializer turtle and base URI
> > http://spdx.org/licenses/
> > @base <http://spdx.org/licenses/> .
> > rapper: Error - URI MIT.rdf - Resolving URI failed: Could not resolve
> > host: MIT.rdf
> > rapper: Failed to parse URI MIT.rdf rdfxml content
> > @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> >
> > rapper: Parsing returned 0 triples
>
> Sorry, I thought it was obvious but realize now that I should have been
> explicit: You need to `cd` to the path where the MIT.rdf is located -
> i.e. you need to checkout the git repository for the sources first.

Ah, I see. So:

[ref@charlie rdfxml]$ rapper -i rdfxml -O http://spdx.org/licenses/ -o
turtle MIT.rdf
rapper: Parsing URI file:///home/ref/license-list-data/rdfxml/MIT.rdf
with parser rdfxml
rapper: Serializing with serializer turtle and base URI
http://spdx.org/licenses/
@base <http://spdx.org/licenses/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix spdx: <../rdf/terms#> .
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix ptr: <http://www.w3.org/2009/pointers#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .


spdx:crossRef [
spdx:isLive false ;
spdx:isValid true ;
spdx:isWayBackLink false ;
spdx:match "N/A" ;
spdx:order "0"^^<http://www.w3.org/2001/XMLSchema#int> ;
spdx:timestamp "2024-01-05T20:12:47Z" ;
spdx:url "https://opensource.org/licenses/MIT; ;
a spdx:CrossRef
] ;
spdx:isDeprecatedLicenseId false ;
spdx:isFsfLibre true ;
spdx:isOsiApproved true ;
spdx:licenseId "MIT" ;
spdx:licenseText """MIT License

Copyright (c)  

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
\"Software\"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
""" ;
spdx:licenseTextHtml """
  
 MIT License

  
  
 Copyright (c) year copyright holders
 

  

  Permission is hereby granted, free of charge, to any person
obtaining a copy of  this
software and
 associated documentation files (the
Software), to deal in the Software without restriction,
 including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense,
 and/or sell copies of the Software, and to permit persons to
whom the Software is furnished to do so,
 subject to the following conditions:

  The above copyright notice and this permission notice
  (including the next
paragraph)
 shall be included in all copies or substantial
 portions of the Software.

  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
 LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
 NO EVENT SHALL  THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY,
 

Re: XML format is unsatisfactory

[Richard Fontana]

On Sun, Jan 14, 2024 at 2:47 PM Jonas Smedegaard  wrote:

> The XML files is a representation of RDF.
>
> Another more human readable and editable RDF repræsentation exists
> which is a *lossless* conversion: Turtle.
>
> On a Debian-based system, you can see how MIT license looks as Turtle
> by installing te package raptor2-utils, an then run this command:
>
>   rapper -i rdfxml -O http://spdx.org/licenses/ -o turtle MIT.rdf

This sounds interesting but:

[ref@charlie ~]$ rapper -i rdfxml -O http://spdx.org/licenses/ -o turtle MIT.rdf
rapper: Parsing URI MIT.rdf with parser rdfxml
rapper: Serializing with serializer turtle and base URI
http://spdx.org/licenses/
@base  .
rapper: Error - URI MIT.rdf - Resolving URI failed: Could not resolve
host: MIT.rdf
rapper: Failed to parse URI MIT.rdf rdfxml content
@prefix rdf:  .

rapper: Parsing returned 0 triples



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3490): https://lists.spdx.org/g/Spdx-legal/message/3490
Mute This Topic: https://lists.spdx.org/mt/103724268/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

XML format is unsatisfactory

[Richard Fontana]

I would like to revive a topic originally raised by Philippe
Ombredanne in https://github.com/spdx/license-list-XML/issues/395
(2017). This is going to be a bit of a rant, so I apologize in
advance.

I believe the XML format used by SPDX in the license-list-XML
repository is unsatisfactory for a number of reasons. As an initial
comment, I do not think it is unfair to say that XML is an
increasingly outdated, if not legacy, data format. I do not think it
can seriously be contended that it would be chosen if the SPDX license
list were being started today.

>From personal experience, I have found the SPDX XML format to be
relatively difficult to read and edit. Having begun to look at these
files more closely recently, I have found that they are full of
structural inconsistencies and semantic errors (for an example of the
latter, see: https://github.com/spdx/license-list-XML/issues/2293).
They are at least a minor, and probably a major, barrier to
participation by new contributors to the project.

In issue #395 Gary O'Neall said: "I've also thought of the master XML
as more of a format internal to the legal team - not something that
would be directly consumed by tools outside of the SPDX community." I
think this perspective encapsulates the problem. Not only do tools
outside of SPDX need to consume the XML directly, the XML also has to
be consumed by humans unmediated by tools (i.e., humans need to read
these files, which is not so strange since XML is or was intended to
be a human-readable file format [1]). As things currently stand, it is
not possible to use SPDX identifiers in a way that is consistent with
the SPDX specification without frequent human reading of the XML files
(which may lead to the need to make human edits to those files). This
is only partly a reflection of the currrent primitive state of tooling
around license detection. The SPDX concept of matching, as defined in
the matching guidelines, is, in general, not susceptible to complete
automation even if we imagine better tools than we currently have
today.

We have found this to be the case in Fedora's adoption of SPDX
identifiers. We cannot simply tell Fedora community members to use the
various tools maintained by the SPDX project because they yield
inaccurate or ambiguous results in most cases and a conclusion about
whether a license text matches an SPDX identifier, within the meaning
of the matching guidelines, ultimately requires human analysis of the
relevant XML file which defines what the identifier means.

I believe there may be a mistaken view, I guess perpetrated by the
SPDX project, that users can rely on the way license texts are
presented in the SPDX License List pages for individual license
identifiers. Now that I've immersed myself in SPDX stuff over the past
year and a half, I'm actually puzzled over why those pages exist at
all, leaving aside the issue that they have accessibility problems
[2]. At best, these pages are only a starting point and in general
users who want to use SPDX license identifiers in an accurate way will
need to consult the XML files to make a full assessment of whether a
text is a match to a given identifier. This is obviously more or less
challenging depending on what license identifier we are talking about.
All this is just to say that the XML files *do* have to be read by
users of SPDX identifiers, unless you want to tolerate widespread
inaccurate use of such identifiers. And it is obvious that XML has to
be sufficiently readable and comprehensible to new (particularly
technically less skilled) contributors to the license-list-XML
repository, at a time when the SPDX legal team seems to be struggling
somewhat to keep up with the volume of new license submissions.

A point made by Gary in the 2017 issue is that the XML files are used
to generate alternative formats which include some that are arguably
more readable. However, at least some of these generated formats
entail a loss of information or seem to commonly suffer from other
kinds of subtle errors. For example, we obviously can't tell Fedora
contributors to look at the plain text generated files, because these
do not have the key information about what a license template means
that is embodied in the XML files.

As far as I can tell, the justification for using XML seems to be
twofold: (1) the SPDX team agonized over this many years ago and
decided to use XML (where there seems to be the implication both that
they must have made the correct choice and that we are stuck with this
choice forever); (2) XML is specifically useful for generating the
HTML used in the license identifier pages at spdx.org/licenses. I
think we can dismiss justification (1) as possibly-excessive
conservatism and consider justification (2). I think it is a form of
mission creep for SPDX to be concerned at all about generating
nice-looking or project-usable license texts. SPDX is supposed to be
defining *identifiers* which real-world license texts can then be
matched 

Re: public domain dedication variants in the wild (found in Fedora)

[Richard Fontana]

On Tue, May 9, 2023 at 2:38 PM McCoy Smith  wrote:

> FWIW, maybe this is an opportunity for SPDX to lead?
> Most of these look similar, but not the same. I’m guessing a lot of the
> similar ones would have the same legal effect, although the more dissimilar
> ones, maybe not (depending on where you are, and as we know some places
> don’t recognize PD).
>
> Might it be useful for SPDX to adopt a single PD tag for what they think
> is the best format for such a dedication, and see if that leads to adoption
> of that format/text, rather than everyone writing their own?
>

I think most of these public domain dedications are relatively
ancient, dating from a time in FOSS when such permission grants were very
common. Nowadays someone with similar inclinations would probably be more
likely to reach for the Unlicense or CC0 or MIT-0 or 0BSD or a simple
permissive license like the MIT license. So SPDX adopting a preferred
format would probably not have much impact.

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3369): https://lists.spdx.org/g/Spdx-legal/message/3369
Mute This Topic: https://lists.spdx.org/mt/98776908/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: public domain dedication variants in the wild (found in Fedora)

[Richard Fontana]

On Tue, May 9, 2023 at 1:00 PM Philippe Ombredanne 
wrote:

>
> - We track over 750 unique public domain dedications variations in
> ScanCode Toolkit that we have seen in the wild, and you should
> consider using these. I reckon that you may already be using ScanCode
> to build some of https://gitlab.com/fedora/legal/fedora-license-data ,
> right?
>

Not very much, currently. Some of the (non-LicenseRef-Fedora-Public-Domain)
license data does originate with ScanCode, mostly as a result of some
internal use of ScanCode at Red Hat.

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3368): https://lists.spdx.org/g/Spdx-legal/message/3368
Mute This Topic: https://lists.spdx.org/mt/98776908/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

SPDX should take a stronger stance against vanity/promotional licenses

[Richard Fontana]

As I've been following the issue queue for
github.com/spdx/license-list-XML/issues over the past several months,
it seems to me that you get a significant number of license
submissions like this latest one:
https://github.com/spdx/license-list-XML/issues/1790

The pattern is, someone has drafted their own license, it either isn't
being used at all in the real world or it is being used for a few
insignificant projects of the license author. In some cases the
license seems to be connected to some contemplated commercial activity
of the license submitter. Presumably SPDX license list inclusion is
seen as a way of legitimizing or popularizing the novel license. I am
quite familiar with this sort of phenomenon from my past involvement
with the OSI, where the nature of the OSI process as it was
historically defined seemed to unintentionally result in many license
submissions of this sort.

When I look at the SPDX license inclusion guidelines, I am concerned
that this sort of behavior is not sufficiently discouraged. The
guidelines say "The license has actual, substantial use such that it
is likely to be encountered. Substantial use may be demonstrated via
use in many projects, or in one or a few significant projects. For new
licenses, there are definitive plans for the license to be used in one
or a few significant projects."
But this is not one of the "definitive" factors and it is the third of
a list of non-definitive factors that are given "roughly in order of
importance". Someone might understandably conclude that "substantial
use" isn't too important to SPDX.

My main criticism of the SPDX license list from years ago was that it
was not representative of the makeup of the FOSS project world that I
was seeing in Linux distribution packages and other software I
encountered in my work. I have been engaged in trying to get the SPDX
license list to more accurately reflect the state of widely-used FOSS
today and it is frustrating to see repeated examples of vanity license
submissions. I suggest that the license inclusion principles should be
revised to elevate and perhaps strengthen the "substantial use"
requirement and the maintainers of license-list-XML should more
actively make clear that such licenses are generally inappropriate for
the SPDX license list.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3306): https://lists.spdx.org/g/Spdx-legal/message/3306
Mute This Topic: https://lists.spdx.org/mt/96510436/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Mismatches between OSI and SPDX

[Richard Fontana]

On Fri, Dec 9, 2022 at 4:22 AM Max Mehl  wrote:

> In my organisation, we define all licenses approved by OSI as valid Open 
> Source licenses. However, we also increasingly rely on SPDX and therefore 
> also its license list.
>
> Recently, we found several mismatches between OSI’s list of approved licenses 
> [1] and the licenses marked as OSI-approved in SPDX’s list [2].
>
> Certainly, some of these issues are on OSI’s side (e.g., misleading links or 
> wrong SPDX identifiers). But most mismatches are from licenses on SPDX’s list 
> that cannot be found on the OSI website.
>
> I documented my findings for all issues in this gist:
>
> https://gist.github.com/mxmehl/1e7a3aed4ff14a8ddfd4aff8ab4de552
>
> Now, I am sure I’m not the first who notices this. Is this a known problem?
>
> Is the OSI website incomplete and/or SPDX list incorrect? What can we do to 
> better align both sources?
>
> [1]: https://opensource.org/licenses/alphabetical
>
> [2]: https://github.com/spdx/license-list-data/blob/v3.19/json/licenses.json

Not speaking for SPDX or OSI: To some degree this is a known problem,
and possibly viewable as not a problem in some cases. Some issues I
see embodied in your list:

1. In some cases licenses published on the OSI website are incorrect
in the sense that they do not match widely used versions of the
license text that the OSI probably intended to be the approved license
text. I think these cases have all been noticed through activity
related to creation or adoption of SPDX identifiers -- for example,
Fedora recently adopted use of SPDX identifiers for package license
metadata and early on it was noticed that the license SPDX calls
Python-2.0, which I assume is a faithful copy of the corresponding
license text from the OSI website, does not actually match the license
(or "license stack") text used in known releases of CPython, so SPDX
added Python-2.0.1 to capture the latter text. There is a similar
situation involving the Artistic License 1.0.

I think it is not reasonable to expect the OSI to have historically
applied the degree of rigor SPDX applies in associating an identifier
with a matchable license text (where "matching" is a concept that SPDX
has itself defined). This simply didn't exist in FOSS before SPDX; it
was foreign to the culture. I'm not excusing outright mistakes in
published licenses though (see e.g.
https://github.com/spdx/license-list-XML/issues/1653). For submitted
licenses, I can tell you from my time on the board that OSI assumes
the license submitter has the correct text. In some cases the
"incorrect" text gets adopted by projects, at which point it is
questionable whether it is really incorrect.

2. You list some cases of 'WITH' expressions. The OSI has been
reluctant to approve license exceptions, except in a few special cases
where the exception (or exception coupled with a standard license) is
itself thought of as a single license (e.g. LGPL version 3; ec0s-2.0
is also like this). From my recollection of my time on the OSI board,
the main concern was the potential numerosity of license submissions
if the OSI encouraged submission of exceptions. There's been a
tendency to assume that typical types of GPL exceptions are legit (for
a GPL-world notion of legit) because they conform to the model of a
grant of additional permission -- I need to comment on this issue on
another recent thread.

3. The OSI website IIRC does not list (though still publishes?)
certain licenses or license versions considered by the license steward
to be deprecated. Not sure if that accounts for anything on your list.

4. Use of SPDX identifiers: Probably the main issue here today is that
an SPDX identifier gets adopted after the approval of the license by
the OSI (for most OSI-approved licenses in recent memory).

One basic issue here, which is not really acknowledged by anyone, is
that the kinds of things the OSI has been historically approving are
not the same kinds of things that SPDX assigns identifiers to. For
example, the OSI has approved a license text it calls the MIT license.
It has not approved the (infinite?) set of license texts that meet the
SPDX definition of licenses that match "MIT" (i.e., that match the
ever-evolving XML file that defines what "MIT" means). Indeed it
cannot, because the OSI cannot possibly know how SPDX might alter that
XML file in the future. Or maybe it has signalled approval of some
range of licenses that are only trivially different from the canonical
MIT license, but that undefined set may not be equivalent to the
present/future set of license texts that match to SPDX "MIT". Some
confusion has resulted from a sort of collectively forced merger of
these different concepts of "license". This looseness around what a
license is is also evident (and maybe more obvious) when considering
the "FSF-free" category.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3287): 

Re: standardizing opt-out of EU data mining rights?

[Richard Fontana]

On Thu, Nov 10, 2022 at 3:01 PM Luis Villa  wrote:
[...]

> (1) Would SPDX be an appropriate mechanism for representing that opt-out 
> clause in a machine-readable way, eg via a short identifier + WITH?
>
> (2) This would be, to the best of my knowledge, the first proposed Exception 
> that removes permissions[3] rather than granting new permissions. Would that 
> be acceptable to SPDX? Would that break any implicit or explicit expectations 
> of the specifications or tooling?

Recent exchange that is possibly slightly related to those questions:
https://github.com/spdx/change-proposal/issues/4#issuecomment-1283004681
https://github.com/spdx/change-proposal/issues/4#issuecomment-1304842184

Basically, I believe SPDX has locked itself into a model of what an
"exception" is that is based on normative FSF doctrine built up around
FSF-authorized GPL exceptions, but which does not fully reflect how
standardized license terms actually get supplemented by other terms in
the real world with the GPL and other FOSS licenses (in some cases by
removing permissions, and in some cases where it is not actually clear
whether permissions are being removed). I think this is inconsistent
with SPDX's professed mission of focusing on "just the facts". I think
Steve's view is that indeed generalizing the concept of what an
exception is would break some expectations around models and tooling.

- Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3272): https://lists.spdx.org/g/Spdx-legal/message/3272
Mute This Topic: https://lists.spdx.org/mt/94944281/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: for discussion: license inclusion guidelines

[Richard Fontana]

On Wed, Sep 7, 2022 at 2:17 PM Steve Winslow  wrote:
>
> Jilayne -- yes, I'd be open to a lighter-weight or streamlined approach to 
> approving licenses submitted from use in distros such as Debian and Fedora.
>
> In these cases we have greater confidence that those communities have done 
> the work to vet certain of the license inclusion principles. In particular 
> the first and most important "Other Factor" re: "substantially complies with 
> open source definitions"; and its inclusion in the distro likely demonstrates 
> the "substantial use" factor for SPDX purposes.
>
> I expect we'd want to be a bit specific about what we mean by "is included in 
> the distro". For instance, for Debian I'd think `main` would be covered, 
> `non-free` would not, and I don't know for `contrib`. I don't know how Fedora 
> divides things up...

In contrast to Debian, Fedora does not have separate
official/project-administered package repositories with different
license inclusion criteria.

Fedora has an explanation here that may be helpful:
https://docs.fedoraproject.org/en-US/legal/license-approval/

To summarize, there are different categories of material to which
different license standards are applied:

- The general "allowed" category -- licenses here are determined by
Fedora to be FOSS through a sort of common law-like approach (Fedora
has no DFSG/FSD/OSD counterpart of its own)
- "Allowed-documentation" -- licenses approved only for documentation.
The intent here is that the licenses are libre, i.e., equivalent in
permissiveness/restrictiveness to software-oriented FOSS licenses,
except that a few licenses (already recognized by SPDX) are treated as
allowed-documentation for historical reasons even though they can't
seriously be considered to meet all the standards of the licenses in
the allowed category
- "Allowed-content" -- licenses approved only for "content" which
basically means something that can't be considered software,
documentation, or fonts. These have to be FOSS except they can
prohibit modification and have a "no patent licenses" provision.
- "Allowed-firmware" -- licenses approved only for binary firmware
files that meet certain technical operating system-related criteria;
these licenses need not be FOSS but only certain kinds of non-FOSS
terms are permitted.
- "Allowed-fonts" -- licenses approved only for fonts. These licenses
must meet the standards for FOSS except that they can have a "Sun RPC"
clause (i.e. a prohibition on resale/distribution in isolation, which
is for some reason commonly found in pseudo-FOSS font licenses). The
main community authorities on FOSS definitional norms (FSF, OSI,
Debian) have all implicitly taken the position that these kinds of
clauses do not preclude a classification of a font license as FOSS,
but to varying degrees and with a large dose of historical
inconsistency have taken the view that they are generally not
acceptable in a FOSS software license. Fedora is simply being more
transparent that there are relaxed community standards for font
licenses in this one respect.

So I think Fedora has made an effort to ensure that the licenses in
the "allowed", "allowed-documentation" and "allowed-fonts" categories
substantially comply with widely-held community open source
definitions. That  can't be said of all licenses in the
allowed-content (probably) and allowed-firmware (definitely)
categories. However, I wonder if the fact that these generally
non-FOSS licenses are determined to meet the license criteria of a
distro that is basically conceptualized as a free software community
distro ought to justify the lighter-weight review Jilayne speaks of.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3250): https://lists.spdx.org/g/Spdx-legal/message/3250
Mute This Topic: https://lists.spdx.org/mt/93487313/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: updates to license submission tool

[Richard Fontana]

On Wed, Aug 31, 2022 at 12:40 AM J Lovejoy  wrote:

> One outstanding issue we didn’t get to on our call (and captured here: 
> https://github.com/spdx/spdx-online-tools/issues/388)
> - I think we can simply remove the “Standard License Header” field in the 
> submission form, does anyone disagree with this?

I think this is a good idea. The vast majority of FOSS licenses,
licenses already on the SPDX list (FOSS or otherwise), and licenses
likely to be added to the SPDX license list in the future, will not
have any sort of 'standard header', which is kind of an outmoded
concept, and as I understand it SPDX is contributing to a general
movement away from using such things by promoting the use of the
'SPDX-License-Identifier' construct.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3232): https://lists.spdx.org/g/Spdx-legal/message/3232
Mute This Topic: https://lists.spdx.org/mt/93364839/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Matching Guidelines and English grammatical differences

[Richard Fontana]

In Fedora a license has been submitted for review that seems to match
HPND-sell-variant except that the word "appears" in HPND-sell-variant
is "appear" in this license.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/63

My prescriptivist English grammar is rusty but I think this can be
interpreted as a difference in English verb number as well as possibly
a difference in manifestation of a subjunctive that I would expect to
see vary between British English and American English.

Looking at the SPDX Matching Guidelines, am I right in concluding that
the guidelines don't address formally-minor English grammar
differences of this sort?

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3223): https://lists.spdx.org/g/Spdx-legal/message/3223
Mute This Topic: https://lists.spdx.org/mt/93229791/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Idea: SPDX-DCO-File-License-Identifier

[Richard Fontana]

I've thought some more about certain unintended problems some of us
were previously discussing regarding the use of
SPDX-License-Identifier: in source files. In particular it's occurred
to me that the practice is in tension with the use of the Developer
Certificate of Origin. This is significant given that Linux is the
most important project to have adopted both the DCO and the use of
SPDX-License-Identifier.

Somewhat problematically, the DCO makes reference to a license of a
*file* in its certification: "The contribution was created in whole or
in part by me and I have the right to submit it under the open source
license indicated in the file." Most open source projects (including
possibly most DCO-using open source projects, a tiny minority of open
source projects) do not use explicit licensing of source files, a
practice I understand SPDX at least implicitly disapproves of. In
typical situations, the use of SPDX-License-Identifier: has the nice
feature of clarifying what the "open source license indicated in the
file" is in a standard way.

But for any source file that properly uses SPDX-License-Identifier and
is based on multiply-licensed code (for example, a file properly
reflecting contributions under both GPLv2 and the 3-clause BSD
license), the DCO-related benefit goes away. I don't know if there is
an example like this in the kernel, but suppose the kernel had such a
source file, saying "SPDX-License-Identifier: GPL-2.0-only AND
BSD-3-Clause". What is the "license indicated in the file" for
purposes of the DCO? Prior to the use of SPDX-License-Identifier, the
variously-worded GPL headers might have made it sufficiently clear
that the license for purposes of the DCO is GPLv2 (GPL-2.0-only). Or
the situation was ambiguous but you could then rely on the note from
Linus Torvalds in the kernel COPYING file (or wherever that lives
now). Now, it appears that a DCO-certifying contributor to a file that
already has (based on an analysis of past-incorporated license
notices) "SPDX-License-Identifier: GPL-2.0-only AND BSD-3-Clause" is
certifying that they have the right to submit it under the stated
composite license. It's not even clear this is non-nonsensical -- how
can a single isolable contribution by one person be licensed under two
different open source licenses in a conjunctive, not disjunctive,
sense? (As I said previously, the snippet construct is probably not
going to be practical to use in most cases and I'm not sure it solves
the problem anyway.)

So I am wondering if it would be a good solution to introduce an
additional construct like "SPDX-DCO-File-License-Identifier" for those
cases involving source files where SPDX-License-Identifier:  would
imply a licensing policy at odds with the actual policy of the
project. For example, you could have a source file with the following
header:

SPDX-License-Identifier: GPL-2.0-only AND BSD-3-Clause
SPDX-DCO-File-License-Identifier: GPL-2.0-only

Note this is different from the issue that McCoy was asking about in
an earlier thread, but I think it is somewhat related.

The issue of course is not really limited to projects using the DCO,
but rather any project that informally or otherwise adopts an
"inbound=outbound" approach to licensing of contributions, which is
the vast majority of open source projects (so maybe a solution
shouldn't seem to be DCO-specific). A concern I have is that the use
of SPDX-License-Identifier: may be unintentionally optimized for the
use of that minority of projects that use asymmetric contributor
license agreements to handle licensing in of contributions.

Richard



On Mon, Jul 18, 2022 at 8:14 PM Richard Fontana  wrote:
>
> I feel like what some projects might find useful is something like:
>
> SPDX-License-Identifier-Concluding-What's-Been-Contributed-As-Of-Some-Past-Time:
> SPDX-License-Identifier-Of-What's-Been-Contributed-After-That-Past-Time-And-Default-License-of-Future-Contributions:
>
> since these might point to different licenses. The snippet construct
> can possibly express this adequately in some cases but I think
> reliable identification of a snippet will normally be impractical.
>
> Richard
>
> On Sun, Jul 17, 2022 at 3:18 PM McCoy Smith  wrote:
> >
> > At the risk of sounding like I’m hijacking this to re-raise my prior issue:
> > If AND is the operator to be used when having different inbound vs 
> > outbound, then AND may not be commutative, since the order of listing the 
> > licenses may convey information about which license is inbound vs outbound, 
> > and (maybe) which license applies to different parts of the code.
> > Which militates to me toward a new expression, but I’ve made that point 
> > already.
> >
> > > On Jul 17, 2022, at 11:22 AM, Richard Fontana  wrote:
> > >
> > > I'm working

Re: Commutativity of SPDX expressions

[Richard Fontana]

I feel like what some projects might find useful is something like:

SPDX-License-Identifier-Concluding-What's-Been-Contributed-As-Of-Some-Past-Time:
SPDX-License-Identifier-Of-What's-Been-Contributed-After-That-Past-Time-And-Default-License-of-Future-Contributions:

since these might point to different licenses. The snippet construct
can possibly express this adequately in some cases but I think
reliable identification of a snippet will normally be impractical.

Richard

On Sun, Jul 17, 2022 at 3:18 PM McCoy Smith  wrote:
>
> At the risk of sounding like I’m hijacking this to re-raise my prior issue:
> If AND is the operator to be used when having different inbound vs outbound, 
> then AND may not be commutative, since the order of listing the licenses may 
> convey information about which license is inbound vs outbound, and (maybe) 
> which license applies to different parts of the code.
> Which militates to me toward a new expression, but I’ve made that point 
> already.
>
> > On Jul 17, 2022, at 11:22 AM, Richard Fontana  wrote:
> >
> > I'm working on some draft documentation for Fedora around use of SPDX
> > expressions in RPM spec file License: fields. I was surprised to
> > apparently not see anything in the SPDX spec that says that the AND
> > and OR operators are commutative. I want to assert that the expression
> > "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
> > SPDX spec actually take no position on this?
> >
> > Richard
> >
> >
> >
> > 
> >
> >
>b



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3187): https://lists.spdx.org/g/Spdx-legal/message/3187
Mute This Topic: https://lists.spdx.org/mt/92443713/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Commutativity of SPDX expressions

[Richard Fontana]

The order of operations is a different issue, I think. I guess the
SPDX spec assumes, as you say, that commutativity of AND and OR is
implicit (like counterpart operations in propositional logic), but
this implicit property was not obvious to one Fedora contributor.

Richard

On Sun, Jul 17, 2022 at 4:08 PM J Lovejoy  wrote:
>
> Hi Richard,
>
> Annex D explains the order of precedence for the operators and use of 
> parentheses.  https://spdx.github.io/spdx-spec/SPDX-license-expressions/
>
> I admit, I find the use of parentheses easier to understand overall (than 
> relying on remembering the order of precedence).
>
> I’m not sure it explicitly states that "MIT AND Apache-2.0" is equivalent to 
> "Apache-2.0 AND MIT” but I think that’s kind of implicit, no?
>
> I also think this entire annex could use a re-write to make it a bit more 
> user-friendly (on the topic of improving documentation…)
>
> Jilayne
>
> > On Jul 17, 2022, at 12:21 PM, Richard Fontana  wrote:
> >
> > I'm working on some draft documentation for Fedora around use of SPDX
> > expressions in RPM spec file License: fields. I was surprised to
> > apparently not see anything in the SPDX spec that says that the AND
> > and OR operators are commutative. I want to assert that the expression
> > "MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
> > SPDX spec actually take no position on this?
> >
> > Richard
> >
> >
> >
> > 
> >
> >
>



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3182): https://lists.spdx.org/g/Spdx-legal/message/3182
Mute This Topic: https://lists.spdx.org/mt/92443713/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Commutativity of SPDX expressions

[Richard Fontana]

I'm working on some draft documentation for Fedora around use of SPDX
expressions in RPM spec file License: fields. I was surprised to
apparently not see anything in the SPDX spec that says that the AND
and OR operators are commutative. I want to assert that the expression
"MIT AND Apache-2.0" is equivalent to "Apache-2.0 AND MIT". Does the
SPDX spec actually take no position on this?

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3176): https://lists.spdx.org/g/Spdx-legal/message/3176
Mute This Topic: https://lists.spdx.org/mt/92443713/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx] Specific SPDX identifier question I didn't see addressed in the specification

[Richard Fontana]

McCoy's topic reminds me of a question I asked here some time ago:
https://lists.spdx.org/g/Spdx-legal/message/2706?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Ccomposite%2C20%2C2%2C0%2C68280619

I wasn't really satisfied with that discussion; I was left feeling
that in some situations (perhaps rare in practice, admittedly) there
is a loss of useful information when you replace a set of license
notice strata in a source file with a conjunctive expression in an
SPDX-License-Identifier: statement. McCoy's question seems to be a
little different though.

Richard



On Wed, Jul 6, 2022 at 10:29 AM Steve Winslow  wrote:
>
> If I'm following the discussion correctly, I'd agree with Warner here.
>
> If I take code that I received under BSD-2-Clause and I redistribute it under 
> MIT, I'm really redistributing it under MIT subject to the requirements of 
> the original BSD-2-Clause license under which I received it. I'd say that 
> BSD-2-Clause doesn't give me the right to "relicense" the code in the sense 
> of eliminating the inbound requirements and applying a fully different 
> license in its place.
>
> Rather, BSD-2-Clause allows me to redistribute under different terms as long 
> as I also comply with the BSD-2-Clause obligations; and the same would apply 
> to any downstream recipient of the code. In SPDX license expression terms, 
> I'd describe the resulting license as "MIT AND BSD-2-Clause". (And subject of 
> course to Warner's very good point, about whether in any particular case 
> you're using a sufficiently copyrightable amount of the BSD-2-Clause code 
> such that you need a license under applicable copyright laws.)
>
> In terms of how to express this in source code files: I could see a couple of 
> different ways to do so:
>
> 1. You could just include a single comment header at the top of the file with 
> "SPDX-License-Identifier: MIT AND BSD-2-Clause"
>
> 2. Or if you wanted to be more specific about the particular portions of the 
> code, you could use "SPDX-License-Identifier: MIT" at the top of the file, 
> and then Snippet Tags [0] with "SPDX-License-Identifier: BSD-2-Clause" within 
> the specific marked snippet of code which is subject to that license.
>
> Steve
>
> [0] Newly added in SPDX 2.3; see 
> https://github.com/spdx/spdx-spec/blob/development/v2.3/chapters/file-tags.md#h3-snippet-tags-format-
>
> On Wed, Jul 6, 2022 at 10:08 AM Warner Losh  wrote:
>>
>>
>>
>> On Wed, Jul 6, 2022 at 5:48 AM McCoy Smith  wrote:
>>>
>>> No, that’s not really my issue. I believe the logical operators and the 
>>> ability to designate file-level licenses in SPDX handle your situation.
>>>
>>> I’m talking about using SPDX to provide a copy of the terms of a license 
>>> which don’t apply, but which nevertheless must be provided per the license 
>>> itself. As is required in BSD/MIT/Apache (as well as copyleft licenses, but 
>>> that’s really not applicable to my circumstances since copyleft requires 
>>> the license terms be provided, *and* be applied)
>>
>>
>> What makes you think they don't apply? If you have to reproduce the notice, 
>> the terms apply. You can't just take code and change the license without the 
>> permission of the copyright holders/owners/etc. As an author of BSD code, I 
>> for one would strongly and strenuously object to this sort of thing were it 
>> done to my code. Either you used enough code that the terms apply (you 
>> created a derived work and have to comply) or you didn't (you created a new 
>> enough work the terms do not apply and you don't need to comply). If it 
>> applies, it is an AND. If it doesn't apply, I'd say it's outside the scope 
>> of SPDX. There is no "provide the notice but doesn't comply" option that I'm 
>> aware of in copyright law.
>>
>> So, I don't think legally there's this halfway thing that you are 
>> suggesting, but I'm going to let others on the list opine about that as I'm 
>> not an attorney. I've just been doing this for the last 30 years and have 
>> been FreeBSD's licensing expert for much of that time.
>>
>> Warner
>>>
>>>
>>>
>>> From: s...@lists.spdx.org  On Behalf Of Shawn Clark
>>> Sent: Tuesday, July 5, 2022 10:48 AM
>>> To: s...@lists.spdx.org
>>> Cc: SPDX-legal 
>>> Subject: Re: [spdx] Specific SPDX identifier question I didn't see 
>>> addressed in the specification
>>>
>>>
>>>
>>> I have spent a lot of time contemplating the question, but want to confirm 
>>> I'm thinking about the same thing:
>>>
>>>
>>>
>>> Are you talking about the nature of open source requiring (such as in a 
>>> requirements.txt) other open source code/components that ultimately mean 
>>> the terms of several licenses would apply to the top level software package 
>>> (such as the total python package)? And how to include those identifiers in 
>>> spdx, either as a requirement of the open source license, or as a 
>>> pass-through of a license (such as lgpl/gpl)?
>>>
>>>
>>>
>>> I have thoughts on the topic but wanted to confirm before I 

Re: License text for LGPL-3.0

[Richard Fontana]

On Tue, Jan 11, 2022 at 10:48 AM Till Jaeger via lists.spdx.org
 wrote:
>
> Dear Steve and list members,
>
> In my opinion it is a good idea to add the license text of the GPL-3.0 to the 
> SPDX license information.
>
> The simple reason is that the text that pretends to be the LGPL-3.0 license 
> text isn't complete : "This version of the GNU Lesser General Public License 
> incorporates the terms and conditions of version 3 of the GNU General Public 
> License". Hence, the GPL-3.0 license text is integral part of the LGPL-3.0 
> rather than just a reference.
>
> Furthermore, I have seen many license violations because people just refer to 
> a file with the (incomplete) license text. SPDX could improve the situation. 
> In particular, some scanning tools copy the license text from SPDX.

I am not sure SPDX should get involved in influencing norms around
license text inclusion, as I think it should be responding to the
world as it is rather than (as REUSE does) trying to reform the world
into what it would want to see. But if the FSF is now encouraging use
of a license file that contains LGPL version 3 followed by GPL version
3, it seems to make sense for SPDX to reflect that change by adding
the GPL version 3 (I don't think we should say "GPL-3.0" in this case,
but that's a philosophical discussion for another time :) text.

> I know that FSF traditionally used two license files (e. g. GPL-2.0 and 
> LGPL-2.1) in its projects. Perhaps, the reason is that sec. 3 LGPL-2.1 
> provides a dual licensing scheme. Version 3 is different and I strongly 
> recommend to always add the GPL-3.0 license text to the LGPL-3.0 license text 
> (in the same file).

I don't think so, if we are thinking of the same thing. Rather, a very
common pattern seen in old GNU projects (and indeed similarly old
non-GNU projects using *GPL licensing) is that some portions of code
are deliberately maintained under LGPL and some portions under GPL. A
library might be under LGPL while a utility or daemon might be under
GPL, or at least the project would attempt to implement such a policy.

Richard


>
>
>
>  Ursprüngliche Nachricht 
> Von: Steve Winslow 
> Datum: 11.01.22 08:41 (GMT-06:00)
> An: Alexios Zavras 
> Cc: Spdx-legal@lists.spdx.org
> Betreff: Re: License text for LGPL-3.0
>
> Thanks Alan, Max and Alexios for your thoughts. A couple of responses inline 
> below:
>
> On Tue, Jan 11, 2022 at 5:55 AM Alexios Zavras  
> wrote:
>>
>> . . .
>>
>>
>>
>> Therefore I am not confident we should do a change to such a well-known text 
>> as LGPLv3 to support “use [a single] plain text license file as a source for 
>> obtaining and reproducing the [complete] license's text” (I’ve added 
>> clarifications to the original phrase by Steve).
>
>
> Even setting aside the use case that REUSE has raised here (reproducing 
> license texts), there's another good reason to make this change which I maybe 
> didn't highlight.
>
> The primary purpose of the SPDX License List templates is to enable matching 
> to license texts. This combined LGPL+GPL text file [1] is now an option from 
> the FSF for expressing the LGPL-3.0 license, and given that, it makes sense 
> for the LGPL-3.0 template to match to it. The proposal here would enable 
> that, by matching to this file because of including the GPL-3.0 text as 
> .
>
>>
>> I’m more than happy to extend the data in license-list-XML and add 
>> information attributes like “extra-files-needed” or something similar, which 
>> might help us address somehow the one-license-one-file limitation.
>
>
> This is an interesting thought, and may be worth looking at more closely in 
> the longer term. I can think of others that arguably fall into the category 
> of typically-uses-more-than-one-file. For instance, Golang uses a 
> BSD-3-Clause license [2] together with an additional patent license grant [3] 
> which is expressed in a separate file. I don't want to derail us into a 
> discussion of whether this would be an exception vs. a modification [4] so 
> just noting that as another one that is somewhat complicated by appearing in 
> two separate files.
>
> That said, I think this would be a much more complex and longer-term 
> consideration to think through (with implications for tooling and the tech 
> team side of things). So I'd be inclined to add the  text to 
> LGPL-3.0 now, in parallel to whatever might be considered in the future for 
> this.
>
> [1] https://www.gnu.org/licenses/lgpl+gpl-3.0.txt
> [2] https://github.com/golang/go/blob/master/LICENSE
> [3] https://github.com/golang/go/blob/master/PATENTS
> [4] 
> https://github.com/spdx/license-list-XML/issues/646#issuecomment-569969690 if 
> you're really bored
>
>>
>>
>>
>> -- zvr
>>
>>
>>
>> From: Spdx-legal@lists.spdx.org  On Behalf Of 
>> Steve Winslow
>> Sent: Monday, 10 January, 2022 23:33
>> To: Spdx-legal@lists.spdx.org
>> Subject: License text for LGPL-3.0
>>
>>
>>
>> Hi all,
>>
>>
>>
>> This is a follow-up from the discussion 

Use of exception to communicate legal ambiguity

[Richard Fontana]

Greetings,

Over at Red Hat, we've been gradually increasing our support of the
use of "SPDX-License-Identifier:" in source files for various reasons.

We've encountered some situations where a traditional project practice
might be to insert a GPL license notice at the top of a file, perhaps
following a copyright notice, where the contents of the file are of
dubious copyrightability, and where there is an important policy
(perhaps more significant now than in the past) in avoiding any
contribution of support to the idea that such material is, or ought to
be, copyrightable. (I'm using "copyrightable" a little loosely here,
as we often do in open source, in a way that might also encompass, for
example, situations where the contents are strictly speaking likely
copyrightable but also likely subject to a noninfringement defense of
some sort for essentially all users.)

As one example, though not necessarily the most interesting one, think
of the default form of a configuration file that might be installed
with a particular package. (Such configuration files actually tend not
to have license notices, but occasionally they do.)

In such situations there may also be significant value in preserving
the traditional practice of including the GPL (or other) license
notice. Thus for example using a public domain approximation like CC-0
or the Unlicense or what have you is not particularly helpful.

We've been thinking one useful approach to take in such cases is to
say something like the following:

// The content of this file is such that this file may not need a license.
// But, if this file does need a license, the license is:
// SPDX-License-Identifier: GPL-2.0-or-later

At any rate, that's what we're trying to get across. The problem is
that the SPDX-License-Identifier expression there by itself does not
express the notion of "if needed" or "not sure". Even apart from that,
the bare use of GPL-2.0-or-later in this example seems inappropriate
from an SPDX standpoint since it does not accurately reflect the legal
intent being expressed in the file.

NOASSERTION (I gather not normally used with SPDX-License-Identifier:
) does not seem to adequately capture what we're trying to express
here. Nor something like the possibly-nonsensical "GPL-2.0-or-later OR
NOASSERTION".

We were thinking one possibility would be to define an exception
(worded similarly to the example statement above) that would express
the "not sure/if needed" concept, and could be used with the baseline
license identifier using the WITH expression. Imagine if SPDX accepted
this as an exception identifier called "If-Needed":

   SPDX-License-Identifier: GPL-2.0-or-later WITH If-Needed

But this sort of identifier would depart from the model that I think
SPDX has assumed thus far in recognizing exceptions, which is the
FSF-popularized notion of "additional permission" exceptions. (See
https://github.com/spdx/spdx-spec/issues/153)

Does anyone have any suggestions/reactions to this issue?

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3045): https://lists.spdx.org/g/Spdx-legal/message/3045
Mute This Topic: https://lists.spdx.org/mt/87265601/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: SPDX License List coverage for a full distro

[Richard Fontana]

On Tue, Aug 17, 2021 at 9:10 PM Warner Losh  wrote:
>
> 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 .
>
> 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.

Right, this is what I thought you meant. So to rephrase what I said in
an earlier reply, the current interest among some involved in Fedora
is solely to use valid SPDX short identifier expressions in package
license metadata.

For those not familiar with RPM-based distros, packages are associated
with "spec files" that contain a "License:" field, the contents of
which are not standardized across all uses of RPM. In Fedora, since
time immemorial the License: field contents have in theory conformed
to a system developed primarily by Tom Callaway, which is documented
mainly here:
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses
Somewhat importantly, the meaning of an identifier is sort of defined
in this document:
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/

I could get into this in more detail, but the point is that we are not
talking about the use of SPDX identifiers in *source files* (as a
replacement for traditional FOSS source file license notices or
otherwise), which is what I think you are contemplating. Fedora as a
distribution is primarily packaging software developed upstream of
Fedora. There are plenty of Fedora-specific projects, but even if all
these projects decided to adopt the use of SPDX-License-Identifier,
this would not present any interesting problem because 99% of the
source files of such projects are licensed under, I'm guessing, a set
of fewer than five licenses which have well-established SPDX
representations (ignoring possibly-applicable license exceptions).

Something analogous to the problem of "passing from hand to hand"
could occur in the form of derivative RPM-based distributions that
replicate license tags in spec files, to be sure, and moreover I think
some nonderivative distributions have informally adopted the existing
Callaway system so we might expect nonderivative distributions to
similarly copy the specifics of Fedora's possible effort to
incorporate the use of SPDX identifiers. But historically the Callaway
system has been reasonably well documented and I would expect that to
continue.

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2991): https://lists.spdx.org/g/Spdx-legal/message/2991
Mute This Topic: https://lists.spdx.org/mt/84928724/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: SPDX License List coverage for a full distro

[Richard Fontana]

On Tue, Aug 17, 2021 at 3:48 PM Warner Losh  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. :-)

> 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.

Richard


>
> Warner
>
> On Tue, Aug 17, 2021 at 11:41 AM 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@lists.spdx.org  On Behalf Of 
>> Matija Šuklje
>> Sent: Tuesday, 17 August, 2021 16:35
>> To: spdx-legal@lists.spdx.org
>> 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.suk...@gabbler.org
>> sip:matija_suk...@ippi.fr
>>
>>
>>
>>
>>
>>
>>
>> Intel Deutschland GmbH
>> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
>> Tel: +49 89 99 8853-0, 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
>>
>>
>>
>>
>>
> 



--



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2989): https://lists.spdx.org/g/Spdx-legal/message/2989
Mute This Topic: https://lists.spdx.org/mt/84928724/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: FW: Invalid SPDX identifier in Linux source tree

[Richard Fontana]

My understanding from being on the linux-spdx mailing list is that
this is intentionally tolerated for existing SPDX-License-Identifier
notices because it was correct SPDX syntax under the earlier version
of the SPDX spec.

Richard

On Wed, May 6, 2020 at 9:25 PM Mark Atwood via lists.spdx.org
 wrote:
>
> I just got this note from one of my developers.
>
>
>
> Is he correct? Should we or someone send a patch to Linux project?
>
>
>
> ..m
>
>
>
>
>
> From: REDACTED
>
> Sent: Tuesday, May 5, 2020 8:26 AM
> To: Atwood, Mark 
> Subject: Invalid SPDX identifier in Linux source tree
>
>
>
> Mark,
>
> Sorry for the delay, I'm long overdue in forwarding this to you.
>
> https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c-dev.h
>
> Contains the following invalid SPDX identifier:
>
> /* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
>
>
> The SPDX list of license identifiers (https://spdx.org/licenses/) does not 
> include GPL-2.0+ in any form.  The closest would (presumably) be 
> GPL-2.0-or-later.
>
> ---
>
>
>
> 



-- 
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2802): https://lists.spdx.org/g/Spdx-legal/message/2802
Mute This Topic: https://lists.spdx.org/mt/74042508/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: documentation/examples of License Ref?

[Richard Fontana]

If you have a standard license text (that maps to one of the SPDX
license identifiers) coupled with some additional nonstandardized
terms, which are not captured by anything in the exceptions list
(which IIRC are not supposed to cover supplementary restrictive terms
anyway, though I seem to remember a debate many years ago about that
topic), would the only SPDX-sanctioned way of expressing this be to
use a LicenseRef for the whole expression? For example, suppose you
have a project that says it's licensed under GPL version 2 along with
an attribution-like requirement for web services (this is a real case
I was pointed to today, see:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

To represent that in SPDX notation, I assume you wouldn't refer to
"GPL-2.0" unless you prefixed it with a LicenseRef, something like
LicenseRef-GPL-2.0-Web-Services-Attribution
where "GPL-2.0" doesn't particularly have any precise connection to
the SPDX GPL-2.0 identifier, but might have the benefit of
communicating to humans that the license in question here is, in part,
textually-intact GPL version 2.

This is a common enough case, though, that I wonder if there is some
value to having a way of representing it in an SPDX expression that
uses the official SPDX identifier in an official sort of way, not
prefixed by LicenseRef. Maybe you'd have to define a new operator and
perhaps SPDX wouldn't want to go down that road. I assume from reading
the spec that LicenseRef can't be used inside an expression to cover
just the identifier that follows the WITH operator.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
 wrote:
>
> Hi Luis, hope you (and others) are staying safe and healthy as well.
>
> Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined in 
> Appendix IV of the spec. [1] In an actual SPDX document, it would be defined 
> in a corresponding "Other License" section. [2]
>
> In the v2.2 release of the spec (for which a release candidate was circulated 
> this morning), the spec now explicitly clarifies that LicenseRefs can be used 
> in short-form identifiers in source code. [3] REUSE has also implemented this 
> in their spec and described a mechanism for including the corresponding 
> license text directly in a repo.
>
> Hope this helps!
> Steve
>
> (links below are to sections of the v2.2 release candidate)
>
> [1] 
> https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-expressions/
> [2] 
> https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-information-detected/
> [3] 
> https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-identifiers-in-source-files/,
>  scroll to the bottom
> [4] https://reuse.software/spec/, search for "LicenseRef"
>
> On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell  wrote:
>>
>> Luis,
>>
>> `LicenseRef-*` is technically part of the license expression
>> syntax, too.  But it mostly comes up in the context of
>> (private, shared) SPDX XML files.  I'm not aware of any
>> package managers that leverage it as a way for package
>> authors to express their own license terms.
>>
>> --
>> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
>>
>>
>>
>
>
> --
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
> swins...@linuxfoundation.org
> 



-- 
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2793): https://lists.spdx.org/g/Spdx-legal/message/2793
Mute This Topic: https://lists.spdx.org/mt/73085652/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

SPDX-License-Identifier for composite-licensed source files

[Richard Fontana]

Suppose you're dealing with the following source file legal notice
(example taken from
https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/,
itself adapted from the examples discussed by SFLC in this old paper:
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html):

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following copyright and
 * permission notice:
 *
 *   Copyright 2013 Joe Bloggs
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *   See the License for the specific language governing permissions and
 *   limitations under the License.
 */

Is there a recommended approach to translating this to use
SPDX-Liense-Identifier strings?

One possibility might be:

/* Copyright 2013 Joe Bloggs
 * SPDX-License-Identifier: MPL-2.0 AND Apache-2.0
 */

This approach represents all the copyright and license information in
the original file without making the legal judgment that is implicit
in the original notice (as to the legal effect of one-way
compatibility of the Apache License 2.0 with MPL 2.0), beyond possibly
what someone might choose to infer from the mere ordering of the
conjunctive set of licenses. But it gives the possibly-false
impression that Joe Bloggs is the sole or, in some sense, primary
copyright owner of the code in the file, which results in part from
the absence of a copyright notice for the MPL licensor(s).

Another possibility might be:

/* SPDX-License-Identifier: MPL-2.0
 * This file incorporates work covered by the following copyright
notice and license:
 *   Copyright 2013 Joe Bloggs
 *   SPDX-License-Identifier: Apache-2.0
 */

This is closer to the original, and provides the same opinion on the
licensing consequence of the "incorporation" of the Apache License 2.0
code, but whether that is good or bad I'm not sure. (As I understand
it there's a theme in SPDX of attempting to avoid making legal
judgments.) But it has a verbosity that I would think goes against the
whole spirit of using the SPDX-License-Identifier construct.

What's the best practice for source files of this sort, containing
code under multiple licenses where there is some notion of code under
the more permissive license being subsumed under the more restrictive
license of incorporation?

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2706): https://lists.spdx.org/g/Spdx-legal/message/2706
Mute This Topic: https://lists.spdx.org/mt/68280619/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

OFL-1.1 and Reserved Font Name

[Richard Fontana]

The SIL Open Font License 1.1 (SPDX short identifier OFL-1.1) and its
superseded predecessor (OFL-1.0) have a notion of a "Reserved Font
Name". In the case of OFL-1.1, at least, this is contemplated as a
licensor-optional addition to a copyright notice ("Copyright (c)
,  (), with Reserved Font Name
"), with some licensing consequences flowing from
specifying the name ("No Modified Version of the Font Software may use
the Reserved Font Name(s) unless explicit written permission is
granted by the corresponding Copyright Holder.").

Shouldn't OFL-1.1 (and possibly also OFL-1.0) with the Reserved Font
Name feature be distinguished in SPDX from OFL-1.1 where no Reserved
Font Name is specified?

-- 
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2579): https://lists.spdx.org/g/Spdx-legal/message/2579
Mute This Topic: https://lists.spdx.org/mt/30795784/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] An example of a super simple SPDX licenses registry, for discussion

[Richard Fontana]

d58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=dBq66UPR0wShGDO0SNmM06x0geoU5pABTj1Gjus0%2FsY%3Dreserved=0
> nexB Inc. - 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nexb.comdata=02%7C01%7CJeff.McAffer%40microsoft.com%7Cd58f7f9edbbe4e4ee95d08d6a3249aba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636875774948859901sdata=sGjYB7p6aHw7Ag11XKkodFq%2BbDEeoaZlMmSsUrFbcOM%3Dreserved=0
>
>
>
>
> 
>


-- 
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2560): https://lists.spdx.org/g/Spdx-legal/message/2560
Mute This Topic: https://lists.spdx.org/mt/30394607/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Linux kernel enforcement statement discussion

[Richard Fontana]

On Thu, Dec 13, 2018 at 08:51:10AM -0500, Karen Sandler wrote:
> * A few Linux developers have expressed an opinion that they would not use
> this identifier to mark upstream code at this point, mostly because they
> have not done the work mentioned above. James in particular has agreed that
> it operates like any other additional permission/exception, but has
> expressed that upstream Linux use of SPDX identifiers in files has a much
> higher burden of proof than is typically used by others downstream and
> outside of Linux.

I believe it was also pointed out that Linux's DCO policy, and the
current wording of the DCO, could have the effect of seeming to force
contributors to an existing file with "SPDX-License-Identifier:
GPL-2.0 WITH KES-Exception" to make the commitment, presumably
something the kernel would not wish to adopt as a policy (whereas the
Project flavor of GPLCC deliberately implements such a policy). That
could be addressed by revising the wording of the DCO but presumably
no one wants to do that.

> * The consensus on the phone call was to give a chance for a legal argument
> here to support the statement that "the KES-Exception fails to grant
> additional permissions under copyright", as Steve was wondering on the call
> if such an argument existed because he'd heard it said that the
> KES-Exception isn't an additional permission. I can't find any argument like
> that presented here. It looks like people disagreeing on what I think are
> more minor points do seem to agree that the KES is in fact an additional
> permission / exception, and operates like others on the list. I have to
> admit that surprised me a bit, because when we started this thread, that was
> what I thought the disagreement was.

I myself have assumed that the KES is a GPLv3-style additional
permission (that is, a "GPL exception" in the traditional sense),
since that's how it's described in the KES itself ("additional
permissions under our license"). FWIW Red Hat's view is that GPLCC is
an additional permission in the same sense, as we've said publicly
numerous times.

I don't see inclusion in the SPDX exception list as conferring
validation that something is, in fact, a GPL-style additional
permission, especially since there seems to have been some interest in
broadening the definition of what an "exception" is for SPDX purposes,
if I understand correctly. I am not sure why the "exceptions" list
couldn't also be broadened to include standardized "additional
restrictions" (to use another GPLv3 concept), obviously with the
"exception" terminology replaced with something less confusing, unless
the exception list is designed to be quasi-political in nature (to
reinforce orthodox GPL interpretive concepts or whatever). I think
that issue may have been discussed before though.

There is something about KES and GPLCC that is different from typical
GPL exceptions, in that they seem to go to enforcement procedure
rather than substantive formal details of license compliance or scope
of copyleft. But I don't see why that difference should create any
doubt that they qualify as additional permissions in the GPL
sense. However IMO that is orthogonal to whether they should be
included in the SPDX exception list, because the SPDX exception list
is not intended to be an authoritative designator of GPL-style
additional permissions. I am not sure the difference goes to
"strippability", to use James's term. A fork of a project using the
similar GPLCC could, I have to assume, strip out GPLCC, but the
additional permission would continue to burden copyrights covered by
GPLCC prior to that fork. This is true of all GPL additional
permissions, though.

> * There is now discussion, similar to that about the KES last year  that we
> delay it again for the next release. I think that's ok, but unlike last
> year, we now have similar exceptions from Red Hat that will also get delayed
> if we delay this one, so delay here means delaying a whole line of listing
> requests.

I am obviously completely biased here but I would prefer that
consideration of GPLCC not be delayed. And since the fates of GPLCC
and KES-Exception are, for better or worse, intertwined, I would also
hope consideration of KES-Exception would not be delayed. FWIW I see
no reason why we shouldn't add KES-Exception as well as GPLCC to the
exception list. It's clear that the Linux project won't be
using KES-Exception as an identifier in source files, so the various
potential problems associated with doing so won't actually occur.

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2491): https://lists.spdx.org/g/Spdx-legal/message/2491
Mute This Topic: https://lists.spdx.org/mt/28714103/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: GPL Cooperation Commitment variations

[Richard Fontana]

I guess I will further say that if the SPDX group would like to informally 
condition adoption of GPLCC-1.0 (or whatever) as an exception identifier on 
some assurance that Red Hat will actually use it in one of the ways 
contemplated by SPDX (on the thinking that SPDX identifiers are not worth 
adopting unless they are actually used), we could use that as an opportunity to 
try to get at least those Red Hat-maintained projects adopting GPLCC to use 
SPDX-License-Identifier in source files. :-) 

Richard 

- Original Message -

From: "Richard Fontana"  
To: "J Lovejoy"  
Cc: "SPDX-legal"  
Sent: Wednesday, December 12, 2018 5:49:16 PM 
Subject: Re: GPL Cooperation Commitment variations 

We're not specifically planning to use the hypothetical SPDX identifier in 
source files -- basically we just haven't considered the issue. Currently, I 
know of one or two Red Hat-maintained projects that are using SPDX identifiers 
in source files, but we haven't reached the point of generally recommending 
this; for one of those two projects the desire to use SPDX identifiers came 
from the developers. 

I think there is a decent chance we will begin recommending use of 
"SPDX-License-Identifier:" (or, at the very least, SPDX identifiers in source 
files) at some point in the foreseeable future. On my team we've certainly had 
a number of discussions about it. I am definitely personally moving towards 
seeing it as a good idea. However as you can imagine that would be a big step 
for us :-) If that were to happen, we would certainly want to use the 
hypothetical future SPDX identifier for GPLCC in source files of those projects 
adopting GPLCC. 

As for using the hypothetical GPLCC identifier in SPDX documents, we currently 
have no foreseeable plans to generate or make use of SPDX documents, but that 
too is a topic we continue to explore. 

Richard 



- Original Message -

From: "J Lovejoy"  
To: "Richard Fontana"  
Cc: "SPDX-legal"  
Sent: Wednesday, December 12, 2018 5:32:34 PM 
Subject: Re: GPL Cooperation Commitment variations 

Richard, 

You stated: 
> If SPDX adopts an identifier solely for the Project variant, 
> let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation 
> for all three variants on https://gplcc.github.io/gplcc and other 
> informational and promotional materials. 

But, is Red Hat intending on using the SPDX identifier in source files of Red 
Hat projects that have adopted the project variant or SPDX documents? 


Jilayne 



> On Dec 7, 2018, at 11:51 PM, Richard Fontana  wrote: 
> 
> I've thought further about the issue of whether GPLCC, as a possible 
> future SPDX exception identifier, should cover the three GPLCC 
> variants (Corporate, Indivdiual and Project), as seemed to be the 
> consensus on the recent call, or whether instead it should just refer 
> to the Project version (which was my original proposal). 
> 
> There's an argument that someone might want to use a convenient SPDX 
> identifier to reference the non-Project variants when annotating some 
> source code wholly or partially covered by one of those 
> commitments. (This is related to some of the arguments Bradley has 
> been making in connection with the Kernel Enforcement Statement, I 
> think.) I suspect this will be unlikely, but who knows? 
> 
> My concern though is the effort to use markup to generalize the 
> textual differences among the three variants might have the 
> problematic effect (from Red Hat's perspective) that some unknown set 
> of additional variants, unauthorized by the GPLCC initiative, could 
> match to the GPLCC SPDX identifier. To put it simply, I see value in 
> an SPDX identifier for GPLCC if the identifier can be mapped to from 
> the three official GPLCC variants, but I see no value in the 
> possibility of anything else matching GPLCC. I am not clear on whether 
> the markup can be crafted so precisely that it could only match the 
> three documents in question. I think the problem I am highlighting 
> would be tolerable if we (Red Hat) actually cared about having an 
> identifier for the Corporate and Individual variants, but we really 
> don't. If SPDX adopts an identifier solely for the Project variant, 
> let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation 
> for all three variants on https://gplcc.github.io/gplcc and other 
> informational and promotional materials. 
> 
> Richard 
> 
> 
> 
> 
> 
> 
> On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote: 
>> Hi all, 
>> 
>> I know I just wrote in the minutes that this task was on Richard F, but I 
>> was too curious not to have a cursory look myself! 
>> 
>> Attached is a compare of the project to corporate variant; and of th

Re: GPL Cooperation Commitment variations

[Richard Fontana]

I've thought further about the issue of whether GPLCC, as a possible
future SPDX exception identifier, should cover the three GPLCC
variants (Corporate, Indivdiual and Project), as seemed to be the
consensus on the recent call, or whether instead it should just refer
to the Project version (which was my original proposal).

There's an argument that someone might want to use a convenient SPDX
identifier to reference the non-Project variants when annotating some
source code wholly or partially covered by one of those
commitments. (This is related to some of the arguments Bradley has
been making in connection with the Kernel Enforcement Statement, I
think.) I suspect this will be unlikely, but who knows?

My concern though is the effort to use markup to generalize the
textual differences among the three variants might have the
problematic effect (from Red Hat's perspective) that some unknown set
of additional variants, unauthorized by the GPLCC initiative, could
match to the GPLCC SPDX identifier. To put it simply, I see value in
an SPDX identifier for GPLCC if the identifier can be mapped to from
the three official GPLCC variants, but I see no value in the
possibility of anything else matching GPLCC. I am not clear on whether
the markup can be crafted so precisely that it could only match the
three documents in question. I think the problem I am highlighting
would be tolerable if we (Red Hat) actually cared about having an
identifier for the Corporate and Individual variants, but we really
don't. If SPDX adopts an identifier solely for the Project variant,
let's say "GPLCC-1.0", we'd be happy to use that as an abbreviation
for all three variants on https://gplcc.github.io/gplcc and other
informational and promotional materials.

Richard






On Thu, Nov 29, 2018 at 11:54:08AM -0700, J Lovejoy wrote:
> Hi all,
> 
> I know I just wrote in the minutes that this task was on Richard F, but I was 
> too curious not to have a cursory look myself!
> 
> Attached is a compare of the project to corporate variant; and of the 
> individual to project variant.  The main difference seem to be: 
> - in the use of pronouns (I, We, name of coroporation) - easily accommodated 
> with markup.
> - likewise, the associated definition of We or the corporation name, or the 
> absence of a definition for individual at the end
> - likewise, lead-in text for the individual version clarifying it only 
> applies to their sole copyright 
> - there is also an additional term that the corporate variant has about the 
> ability to modify the commitment by posting a new edition - this is not 
> included at all in the project or individual variants. I think this could be 
> omitable in some way? if a cooperation did make a modified version, then it 
> would not match
> 
> 
> Interested to hear other thoughts.  This will still need some expert markup 
> attention!!
> 
> 
> Jilayne
> 
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2462): https://lists.spdx.org/g/Spdx-legal/message/2462
Mute This Topic: https://lists.spdx.org/mt/28502129/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment

[Richard Fontana]

On Fri, Nov 30, 2018 at 07:20:15PM -0500, Michael Dolan wrote:
> The Common Cure Rights Commitment (CCRC) which was based on the KES also
> applies to an indefinite pool of projects. If one or a few of the companies
> own all the copyright, my recommendation would be to just relicense the
> project with an appropriate additional permission as a license modifier and
> require all new contributors to give the same license. Instead it could
> apply to N number of projects, many of which we do not know about and for
> each one it only applies to contributions from that company and it doesn't
> change the project license. Even if the company wrote all the code in a
> file today, what happens when NewContributor makes a contribution - now you
> have to notify everyone to remove the "WITH CCRC-1.0" in the next SPDX
> review? Unless someone is running cregit and reviewing each of those files
> they would never know.

Note: Common Cure Rights Commitment was an earlier name for what Red
Hat later ended up branding the GPL Cooperation Commitment. As was
pointed out on the call, GPLCC now exists as three variants,
Corporate, Individual and Project. The Corporate version is a
commitment made by companies, not specifically tied to particular
projects or code. The Individual version is similar but is made by
individuals. The Project version is designed be used in a project
source repository. My original suggestion had been to have an SPDX
exception identifier for the Project version only (I will comment on
this issue in a separate posting).

The Project version of GPLCC serves exactly as what Mike calls "an
appropriate additional permission as a license modifier and require[s]
all new contributors to give the same license". It is designed to be
usable by existing as well as new projects, by applying prospectively
to all contributions as of the date of adoption of the commitment. 

> I think if communities want to do this, we should be guiding them to
> revisit using a CLA or some other means to capture commitments from prior
> contributors and change the project license itself to include these
> exceptions in any future contributions.

With the GPLCC Project version, a CLA is not needed since it
contemplates that past contributions might not be covered by the
commitment while future ones will be. This may make an SPDX identifier
for GPLCC unusual, in that it describes a licensing fact for an entire
project that may not apply to all contributions made under the
underlying project license. Nonetheless, Red Hat considers it highly
desirable to have SPDX recognize GPLCC with an identifier. 

As for the KES, I don't have any concerns about SPDX separately
recognizing an identifier for it. If it does, however, then I believe
it would be no less justifiable to have an identifier for GPLCC. I do
not think Red Hat itself would find any practical value in using a KES
identifier, especially if the kernel developers themselves don't use
it in individual source files, but admittedly we are making only
limited use of SPDX identifiers at present.

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2461): https://lists.spdx.org/g/Spdx-legal/message/2461
Mute This Topic: https://lists.spdx.org/mt/28501931/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: meeting tomorrow/Thursday

[Richard Fontana]

Should that be 12 noon Eastern time? (or 8am Pacific?) 

- Original Message -

From: "J Lovejoy"  
To: "SPDX-legal"  
Sent: Wednesday, November 28, 2018 11:20:10 PM 
Subject: meeting tomorrow/Thursday 

Hi all, 


We’ll be back on our regularly scheduled call tomorrow/Thursday at 9am Pacific 
time / 11am Eastern time / 5pm Central European time. 
Web conference: http://uberconference.com/SPDXTeam 
Optional dial in number: 415-881-1586 
No PIN needed 

We scheduled for this meeting to discuss the way to refer to license exception 
or “additional permissions” in a broader way. I have drafted some proposed 
changes to the way we describe this part of the SPDX License List in a Google 
doc, using tracked changes as compared to the current text. You can see that 
here: 
https://docs.google.com/document/d/1vWlwlIN1IKNn-lJMx1iqZ7A2Xb-b3lTZ9WjhRQov-DE/edit?usp=sharing
 

If you are unable to view that link, the basic premise is to replace 
“exception” with “license modifier” to use a more neutral and inclusive term. 
(attempts to download in .pdf or .odt did not include the tracked changes… 
grrr) 

We will also discuss specific requests for: 
the Linux kernel enforcement statement - 
https://github.com/spdx/license-list-XML/issues/655 

the GPL Cooperation Commitment - 
https://github.com/spdx/license-list-XML/issues/714 

as well as the variants for the Google patent grant - 
https://github.com/spdx/license-list-XML/issues/646 

and also see https://wiki.spdx.org/view/Legal_Team/Minutes/2018-06-28 

I’m sorry I didn’t send this sooner to enable some pre-meeting email 
discussion, but would greatly appreciate if people could have a look at these 
items prior to the call so we can hit the ground running. 


Thanks, 
Jilayne 
 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2446): https://lists.spdx.org/g/Spdx-legal/message/2446
Mute This Topic: https://lists.spdx.org/mt/28484247/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: New Exception Request: GPL Cooperation Commitment 1.0

[Richard Fontana]

I previously wrote, referring to
https://github.com/spdx/license-list-XML/issues/655

> as Bradley Kuhn says in a comment to that issue, "drafted somewhat
> differently and therefore presumably should be analyzed differently
> so as not to conflate apples and oranges".

On further thought, there are actually more underlying similarities
than differences between these two exceptions. I believe it would be
productive for them to be considered and discussed at the same time.

Re-reading the GitHub issue, I remembered that this list had an
earlier thread about whether an SPDX identifier would be appropriate
for the commitment texts published by Red Hat and other companies at
the launch of what we now call the GPL Cooperation Commitment
initiative. Since that time, the GPL Cooperation Commitment has been
slightly expanded to include a form suitable for inclusion in source
trees, much as the Linux Kernel Enforcement Statement is included in
the kernel source tree.

Bradley, given that, what are your feelings on this at this point?
Would you be comfortable at this point considering them together?

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2413): https://lists.spdx.org/g/Spdx-legal/message/2413
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

New Exception Request: GPL Cooperation Commitment 1.0

[Richard Fontana]

Heya, 

This is a request for addition of the GPL Cooperation Commitment version 
version 1.0 to the SPDX list of License Exceptions ( 
https://spdx.org/licenses/exceptions-index.html ) 

1. Proposed Full Name: GPL Cooperation Commitment 1.0 

2. Proposed Short Identifier: GPLCC-1.0 

3. URL reference: 
https://github.com/gplcc/gplcc/blob/eee52346dd48bdf985657f082bb847f12f40c464/Project/COMMITMENT
 

4. Text of exception is attached 

5. This exception has not been approved by the OSI nor has it been submitted to 
the OSI for approval 

6. Short explanation: 

Last year Red Hat started an initiative, which we now call the GPL Cooperation 
Commitment, to encourage companies, individual developers, and open source 
projects, to extend the cure and repose period commitments in GPL-3.0 section 8 
to code under GPL-2.0-only, GPL-2.0-or-later, LGPL-2.0-only, LGPL-2.0-or-later, 
LGPL-2.1-only, and LGPL-2.1-or-later. As part of this effort, we created a 
"project" variant of the commitment language, and we announced that henceforth 
new Red Hat-initiated projects opting to use GPL-2.0-or-later or 
LGPL-2.1-or-later [1] would be expected to supplement the license with the 
commitment language, with the official text of the project variant of the 
commitment, titled GPL Cooperation Commitment Version 1.0, published at 
https://github.com/gplcc/gplcc/blob/master/Project/COMMITMENT 

A few existing Red Hat-maintained projects also recently began using the 
commitment, but this was done using an earlier title, the "Common Cure Rights 
Commitment". We're in the process of updating these projects so that they will 
use the commitment language under the new title (GPL Cooperation Commitment). 
Note that the text of the commitment language has not changed apart from the 
title. Here are a few examples of projects currently using the commitment 
language: 
https://github.com/wildfly/wildfly/blob/master/COMMITMENT 
https://github.com/wildfly/wildfly-core/blob/master/COMMITMENT 
https://github.com/pulp/pulp/blob/master/COMMITMENT (currently uses old title) 

I discussed the new expectation of use of the GPL Cooperation Commitment by Red 
Hat-initiated projects in a blog post: 
https://www.redhat.com/en/blog/gpl-cooperation-commitment-and-red-hat-projects?source=author=26851
 
(Note that this refers to the commitment file as "an additional permission 
extended to users".) 

While project adoption of the GPL Cooperation Commitment is in its very 
earliest stages, we anticipate that over time a significant number of projects 
may adopt it, and that it will appear also as a license document in or 
accompanying a number of commercial software products. 

To be candid, Red Hat is primarily interested in having GPLCC-1.0 be added to 
the SPDX exception list because we think this will lend prestige and legitimacy 
to the commitment and ultimately encourage its adoption by projects, developers 
and organizations. But we think from the SPDX perspective adding GPLCC-1.0 is 
justified because its use by projects and appearance in downstream products and 
distributions is likely to grow, even if slowly. 

Note that there is a pending exception list addition proposal, 
https://github.com/spdx/license-list-XML/issues/655, for the Linux Kernel 
Enforcement Statement, which similarly extends the GPL-3.0 cure language. 
However this is, as Bradley Kuhn says in a comment to that issue, "drafted 
somewhat differently and therefore presumably should be analyzed differently so 
as not to conflate apples and oranges ". It is also not designed as a 
project-wide commitment but rather is signed on to by particular named 
individual developers, while GPLCC-1.0 is by design adopted by a project and 
applicable to contributions to the project following the date of adoption (note 
definition of "We".) Finally, the Linux Kernel Enforcement Statement is 
specific to one project, the Linux kernel (and one license, GPL-2.0-only), 
while GPLCC-1.0 is designed to be usable by any project that uses GPL-2.0-only, 
GPL-2.0-or-later, LGPL-2.0-only, LGPL-2.0-or-later, LGPL-2.1-only, or 
LGPL-2.1-or-later. 

Richard 

[1] Nowadays, for Red Hat-initiated projects, we don't normally approve the use 
of LGPL-2.0-only / LGPL-2.0-or-later, and we don't normally approve the use of 
GPL-2.0-only. 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2410): https://lists.spdx.org/g/Spdx-legal/message/2410
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



COMMITMENT
Description: Binary data

Re: New License/Exception Request: copyleft-next

[Richard Fontana]

I would suggest the following: 

Full name: copyleft-next 0.3.1 
Identifier: copyleft-next-0.3.1 

- Richard 


- Original Message -

From: "J Lovejoy"  
To: "SPDX-legal"  
Sent: Friday, September 21, 2018 12:04:17 AM 
Subject: Re: New License/Exception Request: copyleft-next 

Richard, 

As the author of the license, do you have any input/preference as to the full 
name and identifier? (we usually try to ask the author, if the license is not 
submitted by the author) 

Thanks, 
Jilayne 

SPDX Legal Team co-lead 
opensou...@jilayne.com 


On Sep 20, 2018, at 3:39 PM, Richard Fontana  wrote: 

On Sat, Sep 15, 2018 at 10:08:13AM -0500, Kuno Woudt wrote: 
> 
> 5. Indicate whether the license is OSI-approved (see: 
> http://www.opensource.org/licenses/alphabetical) or whether it has been 
> submitted for approval to the OSI and is currently under review. 
> 
> The license is not formally OSI approved, nor has it been submitted for 
> review (AFAIK). 

Correct on both counts. 

- Richard 





 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2380): https://lists.spdx.org/g/Spdx-legal/message/2380
Mute This Topic: https://lists.spdx.org/mt/25836301/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: New License/Exception Request: copyleft-next

[Richard Fontana]

On Sat, Sep 15, 2018 at 10:08:13AM -0500, Kuno Woudt wrote:
> 
> 5. Indicate whether the license is OSI-approved (see: 
> http://www.opensource.org/licenses/alphabetical) or whether it has been 
> submitted for approval to the OSI and is currently under review.
> 
> The license is not formally OSI approved, nor has it been submitted for 
> review (AFAIK).

Correct on both counts.

- Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2378): https://lists.spdx.org/g/Spdx-legal/message/2378
Mute This Topic: https://lists.spdx.org/mt/25836301/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: W3C-20150513 now OSI approved

[Richard Fontana]

No, not yet, and there are a couple of others that need to be posted as
well. Once I take care of that I will follow up here.

Richard
 
On Sat, Dec 2, 2017, at 04:59 PM, g...@sourceauditor.com wrote:
> 
> > -Original Message-
> > From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-
> > boun...@lists.spdx.org] On Behalf Of Richard Fontana
> > Sent: Saturday, December 2, 2017 7:26 AM
> > To: spdx-legal@lists.spdx.org
> > Subject: W3C-20150513 now OSI approved
> > 
> > Hi,
> > 
> > The OSI has now approved the license SPDX  publishes at
> > https://spdx.org/licenses/W3C-20150513.html .
> > 
> [G.O.] 
> Hi Richard,
> 
> Has this been posted to the OSI website?  I checked
> https://opensource.org/licenses/alphabetical and only found the original
> W3C
> license (not the W3C-20150513).  
> 
> I can create a pull request to update the OSI approved to true once OSI
> has
> published the update.
> 
> Gary
> 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

W3C-20150513 now OSI approved

[Richard Fontana]

Hi,

The OSI has now approved the license SPDX  publishes at
https://spdx.org/licenses/W3C-20150513.html .

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: this likely calls for a new L/GPL "exception"?

[Richard Fontana]

On Mon, Nov 27, 2017 at 11:04:15AM -0800, Bradley M. Kuhn wrote:
> As I understand Richard's reasons, they relate to license documents that
> *don't* appear in a source code repository, which is the case for the Google
> and Red Hat statements today.

Right. I can't really see a justification for creating SPDX
identifiers to represent purely external statements.
 
Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: this likely calls for a new L/GPL "exception"?

[Richard Fontana]

On Mon, Nov 27, 2017 at 10:23:40AM -0800, Bradley M. Kuhn wrote:
> 
> Richard Fontana wrote:
> > You could certainly reformulate this commitment so that it would look like
> > a traditional GPLv2 exception or GPLv3 additional permission. But I
> > wouldn't expect it to appear in or even be referenced in source code, so at
> > least for that reason wouldn't it be out of scope for SPDX representation?
> 
> Certainly there is nothing else this could be other than an additional
> permission under copyright.

I agree that it's an additional permission under copyright. I just
realized my earlier statement may have been ambiguous. When I say "you
could reformulate ..." what I mean is you could draft a
*legally-equivalent* statement having the conventional form of a GPLv2
exception. If anyone were to draft such an exception and start using
it, it might then be useful to assign an SPDX identifier for it. 

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: Providing access to FSF license metadata

[Richard Fontana]

W. Trevor King wrote:

> They also list the Expat license as free and GPL-compatible [5], and
> it matches the SPDX MIT [6].  So you can say the FSF considers the
> SPDX MIT free and GPL-compatible.

Ah right - so not as interesting an example as others I was thinking
of. I've been thinking about this because there's been some interest
among the FSF and OSI in seeing where exactly the lists of
FSF-recognized-as-free and OSI-approved licenses disagree.

It's an accident of history that the Expat license text, rather than
the X11 license text, is what came to be known as the MIT license, I
suppose.

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: [spdx-tech] Providing access to FSF license metadata (was: Issues added based on this weeks Legal Call)

[Richard Fontana]

W. Trevor King wrote:

> I am against this in license-list-XML, for the same reasons I am
> against our current osi-approved type: SPDX should not be a
> canonical source of whether *someone else* has approved a license or
> not.  I'd much rather provide tools for Alice to start with an SDPX
> ID and lookup Bob's notes for a given license.  More on this in [1].
> 
> I think the FSF should provide a similar API to expose its
> license-categorization information in a structured way.  Then we can
> include FSF IDs in our license metadata (ideally generated through
> automated matching [4]) and/or they can provide SPDX IDs in their
> license metadata.  User agents could ask the FSF if they consider a
> license GPL-compatible, GPL-incompatible, free, non-free,
> for-a-viewpoint, etc., etc. [5] in a machine-readable way.

By the bye, one thing I'd find useful, either inside or outside of SPDX, is some
notion of correspondence of an FSF-approved license with a counterpart
OSI-approved, or SPDX-recognized, license.

To illustrate, consider the MIT license. There is no MIT license
steward; the de facto standard text (basically for historical reasons)
is that on the OSI website, https://opensource.org/licenses/MIT

The FSF speaks of a license it calls the X11 license as being a free
software license and says that this is sometimes called the MIT
license (a label the FSF has long considered confusing or
misleading). However, the license pointed to by the FSF is not
textually identical to the OSI MIT license and also does not match the
SPDX license "MIT", but does match the SPDX license "X11".

Today one can't justifiably say that the FSF and the OSI both approve the MIT
license as meeting the respective definitional licensing norms of
those organizations, even though everyone *knows* that's true.

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: EPL-2.0 and Secondary Licenses

[Richard Fontana]

On Mon, Oct 02, 2017 at 02:05:31PM -0700, Bradley M. Kuhn wrote:
> Richard Fontana wrote:
> > I believe the Eclipse Foundation has already released some software under
> > EPL-2.0 with Exhibit A specifying GPLv2 with the Classpath Exception. I
> > think you're saying Eclipse can adequately represent that as EPL-2.0 OR
> > (GPL-2.0 WITH Classpath-exception-2.0)
> 
> I can't imagine any other SPDX formulation that could describe the licensing
> scenario, and it seems right to me.  (Noting of course the problem with
> GPL-2.0 as an identifier that we're still discussing separately.)
> 
> > I believe that the Eclipse Foundation and certain of its stakeholders might
> > take issue with that.
> 
> You've definitely got me curious... why do you believe that?

I think they aren't comfortable with the idea that they would be
distributing code under the GPL themselves. They just want to solve a
license compatibility problem. They're okay with facilitating a
downstream GPL licensing act. The label "EPL-2.0 OR GPL-2.0" *looks*
like they are distributing under both licenses. I think that's how
they might see it.

Richard


___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: EPL-2.0 and Secondary Licenses

[Richard Fontana]

On Mon, Oct 02, 2017 at 01:47:36PM -0600, J Lovejoy wrote:
> Hi All,
> 
> We didn’t get a chance to discuss this on the call, so I’m sending around my 
> thoughts as to the newly minted EPL-2.0 (which will be officially added to 
> the SPDX License List for the next release). There were some questions on the 
> Secondary License option. I re-read the thread previously on this (thanks 
> all), and have noted the change in the Exhibit A wording. Below are my 
> thoughts on this, with relevant bits of license bits.
> 
> TL;DR
> The existing license expression syntax, “OR” covers the Exhibit A option, if 
> observed. No need to add new expression or identifier.

That was what I was originally suggesting for what bkuhn calls
EPL-2.0-original, but I think it was the cognitive dissonance that
this created which in part led to the creation of what bkuhn calls
EPL-2.0-revised.

I believe the Eclipse Foundation has already released some software
under EPL-2.0 with Exhibit A specifying GPLv2 with the Classpath
Exception. I think you're saying Eclipse can adequately represent that
as EPL-2.0 OR (GPL-2.0 WITH Classpath-exception-2.0) but I believe
that the Eclipse Foundation and certain of its stakeholders might take
issue with that. Would be interesting to hear their view on this.

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: EPL-2.0 final text (was: meeting tomorrow, general update)

[Richard Fontana]

On Fri, Sep 15, 2017 at 02:08:15PM -0700, W. Trevor King wrote:
> On Fri, Sep 15, 2017 at 01:10:44PM -0400, Wayne Beaton wrote:
> > Exhibit A - Form of Secondary Licenses Notice
> > 
> > "This Source Code may also be made available under the following 
> > Secondary Licenses when the conditions for such availability set forth 
> > in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
> > version(s), and exceptions or additional permissions here}."
> 
> This seems like the new version.  The OSI still hasn't published their
> approved text [1], although they were originally considering the “This
> Source Code is also Distributed under” wording [2] and that's what
> they approved [3].  The text change is under OCI discussion in [4],
> but that just started yesterday.  We probably want to wait and see how
> the change shakes out in the OSI before stamping an ID for the final
> text.

This is now probably sufficiently resolved for purposes of the SPDX
legal group. See:
https://lists.opensource.org/pipermail/license-review/2017-September/003090.html

Richard


> [1]: https://opensource.org/licenses/alphabetical
> [2]: 
> https://lists.opensource.org/pipermail/license-review/2017-June/003048.html
>  Subject: [License-review] For Approval: Eclipse Public LIcense version 
> 2.0
>  Date: Thu Jun 15 19:50:51 UTC 2017
> [3]: 
> https://lists.opensource.org/pipermail/license-review/2017-August/003074.html
>  Subject: [License-review] For Approval: Eclipse Public LIcense version 
> 2.0
>  Date: Thu Aug 10 17:11:18 UTC 2017
> [4]: 
> https://lists.opensource.org/pipermail/license-review/2017-September/003082.html
>  Subject: [License-review] New Exhibit A for EPLv2
>  Date: Thu Sep 14 21:11:06 UTC 2017
> 
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy



> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: meeting tomorrow, general update

[Richard Fontana]

Note that the EPL-2.0 text, at the canonical eclipse.org URL, and specifically 
Exhibit A, has been changed since this was first discussed on spdx-legal -- in 
fact I think it was that discussion that led to the change. 




- Original Message -

From: "Dennis Clark"  
To: "J Lovejoy"  
Cc: "SPDX-legal"  
Sent: Thursday, September 14, 2017 12:53:56 PM 
Subject: Re: meeting tomorrow, general update 

Jilayne, Legal Team, 

I would like to suggest that we include in our meeting agenda the Request to 
add EPL-2.0 to the SPDX License List. This is an important license, and as I 
mentioned in a previous email: "This initial request is just for the EPL-2.0 
License (the easy part). The other issues will be discussed by the legal team, 
which may result in the definition of one or more additions to the Exceptions 
list and/or Notes to be associated with the License." 

The request is here: 
https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681
 

I don't think we want to hold up putting this license on the list because of 
any controversy about how to interpret specific aspects of the license text and 
whether it calls for more extended use of the license expression in actual 
practice. 

Thanks, 
Dennis Clark 
nexB Inc. 


On Wed, Sep 13, 2017 at 6:13 PM, J Lovejoy < opensou...@jilayne.com > wrote: 



Hi All, 

A quick update and reminder for tomorrow’s call. 

On our last call, we had come up with a viable (seeming) proposal to respond to 
the FSF’s request for clarification in SPDX identifiers for the “only x 
version” scenario for the GPL family of licenses. Our plan at the end of that 
calls was to present this to the general meeting for further input, a bit more 
time, and then implement if there was no further concerns. The general meeting 
last week did not yield any further concerns, although most people attending 
were already part of the conversation. 

In any case, we can clearly see from the mailing list, that we have not 
bottomed out on this issue and proposal. We are also waiting for further 
guidance from the FSF on some of the questions that came up on the various 
calls. While it’d be great to have this resolved for the next release, we 
cannot rush this and we can also not delay the next release any longer than it 
has already been taking. 

I would ask that we continue this discussion on the mailing list. But in the 
meantime, we need to move forward with the XML work and next release. The call 
tomorrow will focus on picking up that work and what still needs to be done. I 
would encourage people to focus there energy there as well. 

Call information can be found here, as always: 
https://wiki.spdx.org/view/Legal_Team 


Thanks, 
Jilayne 

SPDX Legal Team co-lead 
opensou...@jilayne.com 



___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 



___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: Package licensing part I - the approach - was Github example

[Richard Fontana]

Just a comment, which seems to resonate with some of what you are saying and 
expresses something I've been struggling with for a while: 

As (mostly) an intentionally-not-watching-too-closely bystander wrt SPDX, for 
some time I've realized that SPDX means at least two different things. There is 
SPDX as contemplated by those who have been most closely and actively involved 
in its development. This anticipates the creation of SPDX-conformant files and 
among other things defines an important distinction between "declared" and 
"concluded" licenses -- while expecting the use of an identical license 
expression language for both, which, as an aside, I think is conceptually very 
confusing. 

The other SPDX is the use of something that *superficially* looks like 
SPDX-conformant license expressions to describe licensing in a way that is, I 
guess, outside the intended scope of SPDX. Examples of this nonconformant use 
of SPDX license expressions include developers annotating the licensing of 
their own software as well as distributors annotating the licensing of things 
they distribute. 

It's the second use of SPDX that in recent years I see catching on in the real 
world of developers and vendors and users, and not the first. The first use of 
SPDX continues after many years to be relegated to an extremely small set of 
enthusiasts, and I think to the rest of the world seems impractical for various 
reasons. In particular I would assert that these two uses of SPDX are 
fundamentally in conflict. 

>From what I can see, the SPDX group counts the second development as a set of 
>signs of "adoption of SPDX". For example, when Fedora began to consider 
>"switching to SPDX" for RPM spec file license tags (which still is nowhere 
>near actual adoption and implementation, for reasons relating to this post), I 
>think the SPDX group saw that as a potential major victory. But that is not 
>really accurate at all. What's happening is that SPDX license expressions have 
>been hijacked to a non-contemplated use which is of much greater interest to 
>the community than the original contemplated use for SPDX. 

These seem to correspond directly to your two stakeholders, except the second 
stakeholder in my mind also includes non-developers who are looking for a 
simple, standardized way to adequately describe the licensing of things they 
distribute. Maybe that's a third stakeholder which sees value in the LEL that 
is similar to what the second stakeholder sees. 

Now speaking specifically of things Red Hat is involved with, we have 
essentially zero interest in the first use of SPDX. Basically no one we 
encounter (outside of some individuals on this list) wants to create or see 
conformant SPDX files - not projects, not us as a company, not our customers. 
But we see a growing interest in the second use of SPDX from developers of Red 
Hat-maintained projects, in certain internal engineering efforts, and with a 
small number of customers, and an accompanying growing dissatisfaction with 
other conventions for describing licensing of software components. And one of 
the big challenges in this second use of SPDX is developing a set of 
conventions that hides sufficient complexity in license description, which I 
think is philosophically completely at odds with the basic direction of 
official SPDX. The conflict is such that I wonder whether there really 
shouldn't be a separate official effort around the second use of SPDX. 

Richard 


- Original Message -

From: "Mark Gisi"  
To: "SPDX-legal"  
Sent: Wednesday, September 13, 2017 1:13:51 AM 
Subject: Package licensing part I - the approach - was Github example 

How to move forward: 

It appears we have not collectively agreed on what the problem is. I believe 
this is because there are at least two different stakeholders expressing two 
different sets of requirements for the License Expression Language (LEL). 
Stakeholder 1 (Traditional): Linux License Compliance people who use SPDX to 
deliver accurate and complete licensing information for Linux packages - many 
of which they did not author but may have patched. Accurate and complete 
licensing means from the package level down to each file level (using 
reasonable efforts). 
Stakeholder 2 (New): Developers who want to use license expressions i) in their 
code in place of the more tradition license notices and ii) for package level 
licensing designations. 

There are three steps I would like to suggest we achieve before developing 
updates to the LEL. 

1) Describe the background on how the LEL was designed to date and the process 
used. The hope is that we can continue using the same process. 

2) Define the requirements for the two different stakeholders and perhaps 
identify other stakeholders or correct the ones that are identified above. 

3) Use the requirements to come up with a more precise problem description. 

Before we proceed - any feedback 

Re: New license proposal: Verbatim

[Richard Fontana]

Not to detract from your general point but Creative Commons has, admirably, 
placed CC0 under CC0. :-) 
https://creativecommons.org/policies/#license 

- Original Message -

From: "Matija Šuklje"  
To: spdx-legal@lists.spdx.org 
Sent: Tuesday, September 12, 2017 8:03:01 AM 
Subject: Re: New license proposal: Verbatim 

Disclaimer: I haven’t read the full thread and for now don’t intend to, unless 
I get a compelling reason to. I apologise if this e-mail will repeat something 
already said. 

All I wanted to say about this is that if we go down that rabbit hole, we will 
evenutally end with the question what license the SPDX file is under (CC0-1.0) 
and then ask ourselves what license CC0-1.0 in under – to which, after quickly 
skimming the text of the license/waiver¹, I can’t say I found any. 

So what then? Are we allowed to even put SDXP data under that CC0-1.0 if we 
don’t have an explicit license to the license/waiver in the text of the 
license/waiver itself? If we aren’t the whole exercise is moot. 

Yes, this is an argumentum ad absurdum FWIW. 

Long story short: I’d say we shouldn’t concern ourselves with the question of 
the license of the license. If a condition of the license is that the text of 
the license should be distributed with the code, I’d argue that is a school 
example of an implied license and leave it at that. 


cheers, 
Matija 
— 
1 https://creativecommons.org/publicdomain/zero/1.0/legalcode 
-- 
gsm: +386 41 849 552 
www: http://matija.suklje.name 
xmpp: matija.suk...@gabbler.org 
sip: matija_suk...@ippi.fr 
___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New license proposal: Verbatim

[Richard Fontana]

On Thu, Sep 07, 2017 at 01:28:07PM -0700, W. Trevor King wrote:
> It's not clear to if the Verbatim license is long enough to be
> copyrightably, but if it is I'd guess it's copyright 1989 by the FSF
> and self-licensed under the Verbatim license as a subset of the GPL
> 1.0 (unless someone can turn up an earlier reference).

Out of curiosity I searched a bit just now and found in the earliest
extant GCC release, apparently from 1988, the license (GNU CC General
Public License) has this slightly different meta-license:

Copyright (C) 1987 Richard M. Stallman
 Everyone is permitted to copy and distribute verbatim copies
 of this license, but changing it is not allowed.

There is no corresponding metalicense in the Emacs General Public
License, which I believe was the first of the proto-GPLs.

IHTBTG but ... if you want to go down this path, do you want to
consider such things as, say, the fact that the vast majority of the
other license texts recognized by SPDX have no explicit metalicense?
(I wonder if the idea of even nonfreely licensing the GPL license
texts was actually an innovation of the FSF.)

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: EPL-2.0

[Richard Fontana]

On Fri, Aug 25, 2017 at 05:10:45PM -0400, Wheeler, David A wrote:
> However, 2(e) makes me wonder:
> > e) Notwithstanding the terms of any Secondary License, no Contributor makes 
> > additional grants to any Recipient (other than those set forth in this 
> > Agreement) as a result of such Recipient's receipt of the Program under the 
> > terms of a Secondary License (if permitted under the terms of Section 3).
> 
> It's not clear to me that this EPL-2.0 clause adds a conflict with GPL-2.0 or 
> GPL-3.0.  For argument's sake I'll assume it doesn't, in part because I 
> expect that the EPL-2.0 drafters would have noticed this.  However, there's a 
> weirdness: This text seems to add a constraint that a *future* version of the 
> GPL might conceivably conflict with.  My crystal ball is murky today :-).

I can shed some light on some of the deeper origins of this text.

In 2007, GPLv3 added the following language to the GPL license
updatability provision:

  Later license versions may give you additional or different
  permissions. However, no additional obligations are imposed on any
  author or copyright holder as a result of your choosing to follow a
  later version.

Although of course this does not by its terms relate to GPLv2, it was
intended primarily to make the point that if someone upgraded
GPLv2-or-later code to GPLv3, this would not somehow mean that an
upstream licensor would suddenly be held to have granted (or have an
obligation to grant) some permission present in GPLv3 but not in GPLv2
(for example, some particular aspect of the GPLv3 express patent
license grant).

(The language thus originated as an effort to mollify intellectual
property lawyers who had irrational fears around open source
licensing.)

I am fairly sure that this language influenced MPL 2.0 section 2.4:

  No Contributor makes additional grants as a result of Your choice to
  distribute the Covered Software under a subsequent version of this
  License (see Section 10.2) or under the terms of a Secondary License
  (if permitted under the terms of Section 3.3).

Notice that the MPL GPL-family copyleft escape hatch feature is being
treated the same way as a future version of the MPL, for purposes of
that provision.

EPL 2.0 adapted that language in 2(e):

  Notwithstanding the terms of any Secondary License, no Contributor
  makes additional grants to any Recipient (other than those set forth
  in this Agreement) as a result of such Recipient's receipt of the
  Program under the terms of a Secondary License (if permitted under
  the terms of Section 3).

In light of the history I would like to take 2(e) just to be saying
that, for example:

- A puts some code under EPL 2.0 with a Secondary License notice that
  references GPLv3 (which might or might not be correctly describable
  as 'EPL-2.0 OR GPL-3.0')

- A also owns a patent with a claim that reads on some GPL-3.0 code
  created by B

- C takes A's code and combines it with B's code

- Even if A's code was 'EPL-2.0 OR GPL-3.0', A did not grant a GPLv3
  section 11 patent license covering its patent which reads on B's
  code (cf. GPLv3: licensed patent claims "do not include claims that
  would be infringed only as a consequence of further modification of
  the contributor version")

I do think this is a somewhat tortured reading though and the
torturedness all seems to stem from that language in Exhibit A.

> If my understanding is correct (and it might not be), then "(EPL-2.0 OR 
> GPL-2.0+)" is *NOT* correct, because you can't necessarily just use arbitrary 
> later versions of the GPL after 2.0 and ignore the EPL-2.0 text.

I think the issue is simpler.

Exhibit A should probably not have said:

  "This Source Code is also Distributed under one or more Secondary
  Licenses ..."

because I think the intention was something more like

  "This Source Code may [at some point in the future from the
  perspective of me, the initial Contributor] also be Distributed
  under one or more Secondary Licenses, under the circumstances
  described in section 3.2..."

(That supports the view that a simple OR expression is not truly the
right way to describe what's going on here.)

cc'ing Mike Milinkovich so he is aware of this.

Richard


___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: EPL-2.0

[Richard Fontana]

I think you're right about the intent. The annoying thing here is the 
ceremonial wording of Exhibit A says nothing about compatibility as such and 
instead seems to merely express the traditional concept of a dual license 
(which admittedly is one way to achieve compatibility), which has a well 
understood translation into SPDX expressions. I hesitate to call this a 
"mistake" but if I'd noticed it before I would have brought it to the Eclipse 
Foundation's attention. 

The Exhibit A notice says: " This Source Code is also Distributed under one or 
more Secondary Licenses, as those terms are defined by the Eclipse Public 
License, v. 2.0: {name license(s),version(s), and exceptions or additional 
permissions here}.” Thinking about it some more, I think this was intended to 
be understood in such a way that the "Source Code" is the Source code of the 
Program at a given iteration downstream, and not just the initial version. If 
that's right, that means at all times the source code is "also Distributed 
under" some form of Secondary License, say GPLv2 with the Classpath Exception. 
It may be that in some cases it will be formally noncompliant with the 

What 3.2 says is 
"[the source code] must be made available under this Agreement, or if the 
Program (i) is combined with other material in a separate file or files made 
available under a Secondary License, and (ii) the initial Contributor attached 
to the Source Code the notice described in Exhibit A of this Agreement, then 
the Program may be made available under the terms of such Secondary Licenses". 
But this is just saying that the Exhibit A notice applies to all subsequent 
nominally-EPL-2.0 contributions. So this is the same thing as dual-licensing 
under EPL and the Secondary License, just through one particular sanctioned 
mechanism. 

Thus I think SPDX could simply use an OR expression instead of coming up with 
some special purpose notation. I don't think that was necessarily intended by 
Eclipse but that would be the plain interpretation of Exhibit A. It says it 
*is* distributed under the Secondary License -- it doesn't say "the Program may 
potentially be distributed under" the Secondary License. 

If prior to EPL 2.0 one had seen EPL 1.0 code used with a statement "This 
Source Code is also Distributed under one or more Secondary Licenses, namely 
GPLv2 with the Classpath Exception", wouldn't everyone have agreed that this 
was "EPL-1.0 OR (GPL-2.0 WITH Classpath-exception-2.0" in SPDX-speak? I guess 
otherwise one would have to have the legal conclusion that while Exhibit A says 
"is also Distributed under" it doesn't really mean "is also Distributed under" 
but rather means "is potentially Distributed under even though it is not 
actually Distributed under right now". 

Not sure it matters all that much in the scheme of things, but I am kicking 
myself for not noticing this before. :) 

Richard 





- Original Message -

From: "Wayne Beaton" <wayne.bea...@eclipse-foundation.org> 
To: "Richard Fontana" <rfont...@redhat.com> 
Cc: "David A Wheeler" <dwhee...@ida.org>, "Kate Stewart" 
<kstew...@linuxfoundation.org>, "SPDX-legal" <spdx-legal@lists.spdx.org> 
Sent: Tuesday, August 22, 2017 2:43:12 PM 
Subject: Re: New License/Exception Request: EPL-2.0 

I actually did mean WITH, but may have been clumsy with my selection of terms. 
Using OR is basically saying that the content is dual-licensed which is not the 
intent (please correct me if my understanding is wrong). 

My understanding (based on section 3.2a of the license) is that the intent with 
the secondary license is provide a switch that says that the license is 
compatible with some particular version (or versions) of the GPL and some set 
of exceptions. That is, the content can be compiled and linked with GPL code 
(at which point the output becomes GPL). 

e.g. (EPL-2.0 WITH GPL-2.0-Compatibility-exception) where the secondary license 
is GPL-2.0. 

Perhaps we can define a more generic "secondary-license-exception" as meaning 
something like "compatibility with GPL-2.0+" and just chain other exceptions, 
e.g. (EPL-2.0 WITH secondary-license-exception WITH Classpath-exception-2.0). 

As I think about this more, I'm leaning more towards something that's similar 
to the solution adopted for the MPL-2.0. i.e. the straight up EPL-2.0, and the 
EPL-2.0 with an escape hatch (EPL-2.0-with-secondary-license-exception). The 
problem is that the escape hatch is dynamic for EPL-2.0 ("exhibit A" requires 
that the secondary license and any exceptions be explicitly listed), but is 
static for MPL-2.0 ("exhibit B" is a blanket removal of secondary license 
support). 

Are we able to provide the right level of precision with just two license 
codes? 

Does it make sense

Re: New License/Exception Request: EPL-2.0

[Richard Fontana]

I think there's something a little odd about the EPL 2.0 opt-in GPL 
compatibility feature I hadn't paid attention to before (despite having 
reviewed the license closely during its drafting and the OSI approval process). 

The way the opt-in GPL compatibility works, the initial licensor of 'the 
Program' has to include a notice which seems to say, in effect, that the code 
from that initial licensor is disjunctively dual-licensed under EPL and some 
particular allowed GPL-family license. 

Subsequent licensors downstream are inheriting a feature that is not really 
obvious from the text of the required notice from the initial licensor, which I 
read as allowing pure-EPL-2.0 code to be distributed under the GPL-family 
license instead. 

So, for example, in a scenario where the initial licensor wanted to allow 
compatibility with GPLv2 + Classpath Exception, the correct SPDX description of 
the Program would seem to be, potentially: 

(EPL-2.0 OR (GPL-2.0 WITH Classpath-exception-2.0)) AND (EPL-2.0 WITH 
whatever-SPDX-were-to-call-the-Built-in-EPL-2.0-GPL-copyleft-escape-hatch) 

This is odd because it seems to imply that the EPL 2.0 compatibility provision 
is unnecessary. The initial licensor is dual licensing the initial EPL code 
anyway, so it would always have been possible for subsequent contributions to 
the Program to be combinable with other GPLv2 + Classpath Exception code. The 
only difference seems to be that the subsequent EPL 2.0 licensors can present 
their code as "pure EPL 2.0" code and still benefit from the compatibility 
feature - i.e. they can avoid having to worry about being careful not to be 
seen as removing the upstream dual license feature. 

Maybe I'm not reading it correctly or need a second cup of coffee but I'm not 
really seeing how the above SPDX expression would be different from 

(EPL-2.0 OR (GPL-2.0 WITH Classpath-exception-2.0)) though. 


Richard 




- Original Message -

From: "David A Wheeler"  
To: "Kate Stewart" , "Gàry O'Neall" 
 
Cc: "SPDX-legal"  
Sent: Tuesday, August 22, 2017 1:02:51 PM 
Subject: RE: New License/Exception Request: EPL-2.0 

Kate Stewart: 


Possibly you're using WITH (which is restricted to only refer to exceptions 
when you mean to use AND?? 
Does the following look like what you're trying to represent? 
EPL-2.0 
EPL-2.0 AND GPL-2.0 
EPL-2.0 AND (GPL-2.0 with Classpath-exception-2.0) 

Those are *syntactically* fine SPDX license expressions, of course. 




However - do they really *mean* "EPL-2.0 AND GPL-2.0"?!? That would mean that 
recipients would have to comply with *both* licenses. 

Perhaps they meant "EPL-2.0 OR GPL-2.0". That way, recipients could choose 
which one could be used. 

--- David A. Wheeler 

___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: EPL-2.0

[Richard Fontana]

Regarding the secondary license support, should it follow what's done with MPL 
2.0 (SPDX has separate license identifiers for MPL-2.0 and 
"MPL-2.0-no-copyleft-exception"), thus something like "EPL-2.0" and 
"EPL-2.0-copyleft-exception"? 

I don't like the "MPL-2.0-no-copyleft-exception" myself as I find it 
confusing/counterintuitive, given that MPL-2.0 itself is a copyleft license, 
the 'exception' is not some sort of general exception having to do with 
copyleft (but rather is GPL-family-specific), and the GPL compatibility feature 
of MPL 2.0 is not described or (I think) generally thought of as an 
"exception". 

Richard 
- Original Message -

From: "Wayne Beaton"  
To: spdx-legal@lists.spdx.org 
Sent: Monday, August 21, 2017 8:52:44 PM 
Subject: New License/Exception Request: EPL-2.0 



The EPL-2.0 has been approved by the OSI and the Eclipse Board of Directors. 
We'd obviously like to see it included in the SPDX license list. FWIW, we're 
updating our legal documentation requirements to make heavy use of SPDX. 

1. License name: Eclipse Public License 2.0 
2. Proposed Identifier: EPL-2.0 
3. URL: https://www.eclipse.org/legal/epl-2.0/ 
4. The license is OSI-approved (though only just recently and so it's not 
posted yet) 
5. The Eclipse OMR and Eclipse OpenJ9 projects are both currently switching 
over to the new version and we expect numerous other existing Eclipse projects 
do so as well. 
6. The Eclipse Foundation is investing in the use of SPDX and since we expect 
many/most of our projects to update to the new version of the license, having 
representation in SPDX is critical path. 



The wrinkle, I think, is that there is a provision in the license for 
"secondary license" support. A project team may opt to declare that their 
project code is GPL compatible. I believe that this means that GPL 
compatibility is an exception; this is compounded by the ability to include 
various exceptions to the GPL. 

The OpenJ9 project, for example, will be EPL-2.0 with GPL-2.0+CPE+AE. I think 
that this would manifest something like this: 

EPL-2.0 WITH (GPL-2.0 WITH Classpath-exception-2.0 WITH Assembly-exception-2.0) 

I'm a little concerned that I don't see Assembly-exception-2.0 on the 
exceptions list. I assume that this means that I'll have to shepherd this 
exception through as well. 

Is this syntax even supported? 




FWIW, in a fit of stupidity--after misreading a comment on another issue--I 
opened a GitHub Issue to track this. 




Thanks, 




Wayne 

-- 
Wayne Beaton 
Director of Open Source Projects 
The Eclipse Foundation 

___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: Your license: full name and identifier - BSD-2-Clause-Patent?

[Richard Fontana]

On Wed, Aug 09, 2017 at 05:51:45PM -0400, Wheeler, David A wrote:
> Smith, McCoy [mailto:mccoy.sm...@intel.com]
> > Adding to the confusion is that FB frequently refers to their React.js 
> > license as
> > "BSD+Patents" (plural), although that nomenclature appears somewhat
> > recent (and, I think, post-dates the submission of the "BSD+Patent" --
> > singular -- license to OSI in early 2016).
> 
> I can't be the only one to confuse "BSD+Patent" with "BSD+Patents".
> 
> But in that case, I think there needs to be a *speedy* assignment (hah!) of
> a SPDX license id/expression to the React.js license.  I'll file
> a request separately to this list.

I think this is a good idea. But I encourage SPDX to come up with an
identifier that takes into account all the circumstances surrounding
this license, including the current controversy (whether it's
justified or not from anyone's perspective).

Suppose BSD+Patent (the real one) hadn't existed -- I could see SPDX
picking "BSD-3-Clause-Patent" for the Facebook license. Or even now,
SPDX might foreseeably do this, since, after all, who would mix up
"BSD-2-Clause-Patent" with "BSD-3-Clause-Patent"? Except the chances
of a mixup by people actually using SPDX short identifiers in the wild
are very high.

I've seen some evidence that "BSD-3-Clause-Clear" is being
misunderstood by people engaging with license metadata to mean, I
guess, "the 3-clause BSD license in some very clear sense" instead of
"the 3-clause BSD-derived license which includes a sentence that says
you don't get any patent licenses". (The possible effect is that Clear
BSD is getting somewhat less marginalized than it otherwise would be,
which may have some interesting implications.) Had SPDX chosen
"ClearBSD" as the identifier -- i.e. an identifier closer to the
actual name of the license, not the reformulated SPDX full name no one
uses in real life ("BSD 3-Clause Clear"), I don't think that would
have happened.

So, please, use something like BSD-3-Clause-React, or
BSD-3-Clause-Facebook, or React, or (this might require a change to
the definition of WITH) BSD-3-Clause WITH React-PATENTS, rather than
'BSD-3-Clause-Patent'.

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: License checking tool available

[Richard Fontana]

On Fri, Aug 04, 2017 at 11:44:45AM -0700, W. Trevor King wrote:
[...] 
> The only difference that turned up in the license text is:
> 
>   Copyright [-©-]{+(C)+} 2007 Free Software Foundation, Inc.
> 
> Our guideline for equating copyright symbols includes (c) but not (C)
> [2].  Maybe that's what's going on?

Is that intentional? I hadn't noticed it before but that's a fairly
clear deficiency in the matching guidelines. "(C)" is probably the
most common attempt at something like a copyright symbol in
copyright/license notices in source files. I think it is much more
common than "(c)" (or the real copyright symbol).

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: SPDX full names of GPL family licenses

[Richard Fontana]

Just to add on a related matter, and because this came up too with the team I'm 
working with, the explanatory notes provided by SPDX for the GPL family 
licenses are poorly written and rather confusing. The one for LGPL-2.1 says: 
"This refers to when this LGPL 2.1 only is being used (as opposed to "or 
later)." and the notes accompanying the other GPL family licenses have 
corresponding sentences. 


- Original Message -
From: "Richard Fontana" <rfont...@redhat.com>
To: "SPDX-legal" <spdx-legal@lists.spdx.org>
Sent: Thursday, July 27, 2017 3:24:20 PM
Subject: SPDX full names of GPL family licenses

Recently I posted something to this list, I think with another hat on, casting 
doubt on the value of SPDX full license names as opposed to the short 
identifiers. 

I have a situation at Red Hat where we'd like to use the SPDX full names for a 
certain particular purpose but we're finding that would mean, for LGPL-2.1+ for 
example, the full name is the (to us, at least) ridiculous "GNU Lesser General 
Public License v.2.1 only or any later version". 

Traditionally of course (I mean outside of SPDX) the full name of that sort of 
license would have been something like "GNU Lesser General Public License 
version 2.1 or any later version", i.e. the "only" would of course only be used 
in the name of a GPL family license if the "or later" permission wasn't present.

I don't follow SPDX developments too closely but I gather the addition of 
"only" in the full name is a recent development. Doesn't this show a negative 
unintended consequence, since "only or any later version" is highly awkward 
phrasing (if only because it goes against traditional FLOSS licensing idiom, 
but I think it probably extends beyond that)? 

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: revised wording for top of exceptions page

[Richard Fontana]

There was one notorious case of the use of GPLv2 with a permissive and 
restrictive additional term that was described at the time as an "exception" -- 
Red Hat's license for Liberation Fonts 1.0. See: 
https://en.wikipedia.org/wiki/Liberation_fonts#Distribution 

I wouldn't particularly recommend use of a 'WITH' expression to describe 
Liberation Fonts 1.0, but might not be the only example of a use of "exception" 
by a licensor (and the general public too) in this sense in the real world. 
IOW, there could be multiple cases in the real world of things called 
"exceptions" that are not "additional permissions". 

Richard 

- Original Message -

From: "W. Trevor King"  
To: "Phil Odence"  
Cc: "SPDX-legal"  
Sent: Monday, July 10, 2017 2:03:15 PM 
Subject: Re: revised wording for top of exceptions page 

On Fri, Jul 07, 2017 at 12:23:43PM +, Phil Odence wrote: 


The SPDX License List includes a list of Exceptions. These 
Exceptions are commonly-granted permissions beyond those normally 
granted in a license. (They are not stand-alone licenses.) 
Exceptions are added to a license using the License Expression 
Syntax operator "WITH." 

This sounds good to me, although I don't see a need to parenthesize 



the stand-alone sentence. I also think there may be room for 
confusion around whether “a license” includes the exception or not. 
And the exception list is distinct from the license list (although 
both are currently tracked in the same repository). How about: 

The SPDX Exception List includes a list of Exceptions. These 
Exceptions are added to a License using the License Expression 
Syntax operator "WITH" to grant additional permissions beyond those 
already given in the License that the Exception modifies. 

If we restrict exceptions to only granting additional permissions, we 
probably also want to adjust the License Expression wording, which has 
[1]: 

Sometimes a set of license terms apply except under special 
circumstances. In this case, use the binary "WITH" operator to 
construct a new license expression to represent the special 
exception situation. 

The current License Expression wording would cover an exception like 
“but I grant no license to users whose first name starts with the 
letter A” which would not be covered by the proposed 
additional-permissions wording. And it would be good to keep the 
wording for WITH in the License Expression appendix close to the 
wording used to introduce the Exception list. 

Cheers, 
Trevor 

[1]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60 

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). 
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy 

___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: BTC License (BTC)

[Richard Fontana]

This seems to be equivalent to the ISC license from an SPDX point of view (see 
https://spdx.org/spdx-license-list/matching-guidelines: 
" Ignore copyright notices. A copyright notice consists of the following 
elements, for example: "2012 Copyright, John Doe. All rights reserved." or "(c) 
2012 John Doe." Templates may or may not include markup for this guideline.") 


- Original Message -

From: "Josh Habdas"  
To: spdx-legal@lists.spdx.org 
Sent: Wednesday, July 5, 2017 12:52:38 AM 
Subject: New License/Exception Request: BTC License (BTC) 

For consideration during the next SPDX Legal Team meeting. 

Full name: BTC License 
Identifier: BTC 
URL: https://gist.github.com/jhabdas/9fc645415bf277e3a1f3bc5c04083f01 
OSI: Not OSI-submitted nor approved 
Explanation: Verbatim copy of ISC, with updated copyright line intended to 
protect individual privacy and facilitate transmission of funds to creators of 
open source work. Example use within software provided below. 

Example LICENSE text file . 
Example license header . 
Example abbreviated license header . 

Thank you for your consideration. 

Regards, 
Josh Habdas 


___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License Request: The Glasgow Haskell Compiler License

[Richard Fontana]

Re-reading the SPDX matching guidelines, one sentence I had been completely 
overlooking seems to address some of the concerns I've had about 
BSD-3-Clause-variant licenses: "T he text indicated as such can be replaced 
with similar values (e.g., a different name or generic term; different date) 
and still be considered a positive match." However I find this sentence 
difficult to interpret -- do "similar" and "different" refer to the 
parameterized things in the SPDX version, or do they instead go to internal 
consistency within a real-world instance of a license type? -- and I might not 
be reading it correctly. 

In light of that sentence, the way I am assuming it should be read, the colored 
items in, for example, https://spdx.org/licenses/BSD-3-Clause.html are not 
supposed to be understood to be strict internally-consistent placeholders - for 
example, the fact that " THE COPYRIGHT HOLDERS AND CONTRIBUTORS" is used in the 
first sentence in the disclaimer does not mean that " THE COPYRIGHT HOLDER OR 
CONTRIBUTORS " is supposed to correspond to the first sentence such that an 
instantiation of "COPYRIGHT HOLDER" in the first sentence must match an 
instantiation of "COPYRIGHT HOLDER" in the second sentence (as an aside, I 
assume the inconsistency in pluralization of COPYRIGHT HOLDER is the result of 
copying of the OSI version of the 3-clause BSD license, which probably will get 
fixed on the OSI website). 

In the case of the GHC license, we have a very small discrepancy relative to 
the SPDX version: " THE UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW AND THE 
CONTRIBUTORS" in the first sentence of the disclaimer and " THE UNIVERSITY 
COURT OF THE UNIVERSITY OF GLASGOW OR THE CONTRIBUTORS" in the second sentence. 
I can read the sentence I quoted above from the matching guidelines to indicate 
that "THE CONTRIBUTORS" matches article-less "CONTRIBUTORS", but if that's a 
correct reading I think it should be stated more clearly. 


- Original Message -----

From: "W. Trevor King" <wk...@tremily.us> 
To: "David A Wheeler" <dwhee...@ida.org> 
Cc: "Richard Fontana" <rfont...@redhat.com>, "J Lovejoy" 
<opensou...@jilayne.com>, "SPDX-legal" <spdx-legal@lists.spdx.org>, "David 
Parrish" <daveparr...@tutanota.com> 
Sent: Tuesday, June 13, 2017 3:13:40 PM 
Subject: Re: New License Request: The Glasgow Haskell Compiler License 

On Tue, Jun 13, 2017 at 02:59:30PM -0400, Wheeler, David A wrote: 


Richard Fontana: 
> The way I read the matching guidelines this license does not 
> actually match to BSD-3-Clause, even though it obviously should. 
> I think the problem is that I am reading the matching guidelines 
> more literally than they may be intended to be read, but given 
> that this is supposed to be a formal specification I think the 
> matching guidelines ought to be made more precise. For example, if 
> the word "the" is optional in certain contexts for purposes of 
> matching, that ought to be accounted for in the formulation of the 
> matching guidelines. 

I think those are bugs in the matching guidelines, not a failure to 
match ☺. If there are bugs, I think they should be fixed! 

Are you suggesting a blanket: 




All articles (“a”, “an”, “the”, …) are optional for matching 
purposes. 

in [1]? Or are you suggesting BSD-3-Clause be updated to use: 

3. Neither <<var;name=organizationArticleClause3;original=the ;match=.+>>name 
of 

Cheers, 
Trevor 

[1]: https://spdx.org/spdx-license-list/matching-guidelines 

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). 
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License Request: The Glasgow Haskell Compiler License

[Richard Fontana]

The way I read the matching guidelines this license does not actually match to 
BSD-3-Clause, even though it obviously should. I think the problem is that I am 
reading the matching guidelines more literally than they may be intended to be 
read, but given that this is supposed to be a formal specification I think the 
matching guidelines ought to be made more precise. For example, if the word 
"the" is optional in certain contexts for purposes of matching, that ought to 
be accounted for in the formulation of the matching guidelines. (I recently was 
engaged in an activity in which I attempted to make use of SPDX identifiers and 
found this to be a common problem, particularly with respect to licenses 
closely resembling the specified templates for BSD-3-Clause and BSD-2-Clause). 

- Original Message -

From: "J Lovejoy"  
To: "David Wheeler"  
Cc: "SPDX-legal" , "David Parrish" 
 
Sent: Thursday, June 1, 2017 12:02:03 AM 
Subject: Re: New License Request: The Glasgow Haskell Compiler License 

Hi David (P), 

David W is right - this is the same license as BSD-3-Clause. The only 
difference is in the “replaceable” text (i.e., the names) as per the license 
matching guidelines and which you can see visually in the red text on the 
license webpage here: https://spdx.org/licenses/BSD-3-Clause.html 

Thanks, 
Jilayne 


SPDX Legal Team co-lead 
opensou...@jilayne.com 





On May 1, 2017, at 11:44 AM, Wheeler, David A < dwhee...@ida.org > wrote: 

David Parrish: 


1. Provide a proposed Full Name for the license or exception. 
The Glasgow Haskell Compiler License 
2. Provide a proposed Short Identifier. 
ghc 
3. Provide a functioning url reference to the license or exception text, either 
from the author or a community recognized source. 
https://www.haskell.org/ghc/license 



This appears to be an existing SPDX license, BSD-3-Clause. See: 
https://spdx.org/licenses/BSD-3-Clause 

This is a widely-used OSI-approved license. 

--- David A. Wheeler 

___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 





___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

New OSI approved license

[Richard Fontana]

Hi spdx-legal,

The OSI recently approved a license called "BSD+Patent" which I would
like to propose as an addition to the SPDX license list.

https://opensource.org/licenses/BSDplusPatent

IIUC "+" can't be used in an SPDX short license identifier - in that
case I'd recommend "BSDplusPatent" unless anyone has a better
suggestion.

 Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: [spdx-tech] various threads on "only" suffix (for GPL)

[Richard Fontana]

On Fri, May 26, 2017 at 02:19:14PM -0700, W. Trevor King wrote:

> Digging at this “acceptable” idea a bit more, I'm guessing it's
> something like “adapters may share adapted works under”.  But the SPDX
> isn't just about copyleft (e.g. it includes CC-BY-ND-*).  I think it
> makes more sense to focus on licenses (just the text, e.g. GPL-2.0)
> and license grants.  For example, here are some SPDX License
> Expressions translated into grants:
> 
> * GPL-2.0: You can redistribute it and/or modify it under the terms of
>   the GNU General Public License version 2 as published by the Free
>   Software Foundation.
> 
> * GPL-2.0+: 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.
> 
> * CC-BY-SA-4.0: This work is licensed under a Creative Commons
>   Attribution-ShareAlike 4.0 International License.
> 
>   You can distribute an adaptation under a later version of the CC
>   BY-SA because that's part of the CC-BY-SA-4.0 [1].
> 
> * CC-BY-SA-4.0+: This work is licensed under a Creative Commons
>   Attribution 4.0 International License; either version 4.0 of the
>   License, or (at your option) any later version.
> 
>   The CC-BY-SA-4.0 tries to grant you that right anyway, but
>   regardless of how you read the CC-BY-SA-4.0, I'm granting you that
>   right directly.

CC BY-SA 4.0 implies that an adaptation can be licensed under a future
CC BY-SA 5.0, but the original material can't. If one explicitly said
some content was licensed under "CC BY-SA 4.0 or later", it might mean
that the originally-received material can be distributed downstream
under CC BY-SA 5.0. Thus CC-BY-SA-4.0+ does not mean the same thing as
CC-BY-SA-4.0.

The traditional GPL "or later" notice says clearly that the licensee
can distribute the original under a later version of the GPL, and
that's the concept that seems to be imported in the
post-GPLv2/LGPLv2.0 copyleft "open source" licenses that have built-in
or-later provisions. (What that actually means, as to unmodified code,
may not be clear, which I speculate might be why Creative Commons
makes a point of not saying there is any permission to distribute the
original material under the later license).

I don't know if that point makes a difference as to this discussion
though.

There might also be a problem with the way SPDX defines the '+', which
as far as I know is this: "An SPDX License List Short Form Identifier
with a unary"+" operator suffix to represent the current version of
the license or any later version." This is *not* really the same as
what the traditional GPL "or later" notice says, or is perhaps one of
multiple possible legal interpretations of what the traditional GPL
"or later" notice says (which I think goes against the whole SPDX
philosophy of objective description of license texts).

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: Error in SPDX version of Apache-1.0 (was: Re: Error in SPDX version of Apache-1.1)

[Richard Fontana]

I would think that the word "name[s]" should not be replaceable - anything 
reasonably viewed as a variant of these licenses will have the word "name[s]" 
in the relevant clauses. (But maybe there's some variant I'm not thinking of.)

Richard

- Original Message -
From: "J Lovejoy" <opensou...@jilayne.com>
To: "Philippe Ombredanne" <pombreda...@nexb.com>
Cc: "Richard Fontana" <rfont...@redhat.com>, "SPDX-legal" 
<spdx-legal@lists.spdx.org>
Sent: Tuesday, April 11, 2017 8:10:34 PM
Subject: Re: Error in SPDX version of Apache-1.0 (was: Re: Error in SPDX 
version of Apache-1.1)

Philippe, Richard,

So, now I’m confused… 

Going back to Richard’s original email, to remind myself what I think I was 
supposed to fix here, Richard had noticed the following:

For Apache-1.0, we have clause 4 as:

4. The "Apache" and "Apache Software Foundation" must not be used to endorse or 
promote products derived from this software without prior written permission. 
For written permission, please contact apa...@apache.org

But, if you go to http://www.apache.org/licenses/LICENSE-1.0 - clause 4 states:

* 4. The names "Apache Server" and "Apache Group" must not be used to
 *endorse or promote products derived from this software without
 *prior written permission. For written permission, please contact
 *apa...@apache.org.
(and I’m quite sure if you look in a bunch of other places, you will find other 
variations…)

Now, as per the matching guidelines, the bit in red is “replaceable’ meaning 
that these two licenses would be a match.  
 
Likewise, for Apache-1.1, we have clause 4 as:

4. The "Apache" and "Apache Software Foundation" must not be used to endorse or 
promote products derived from this software without prior written permission. 
For written permission, please contact apa...@apache.org

Whereas, http://apache.org/licenses/LICENSE-1.1 
<http://apache.org/licenses/LICENSE-1.1> has:

 * 4. The names "Apache" and "Apache Software Foundation" must
 *not be used to endorse or promote products derived from this
 *software without prior written permission. For written
 *permission, please contact apa...@apache.org.
In which case, we have lost a period at the end, as Richard pointed out. And 
the word “names” is also missing - I believe the word “names” would simply be 
added to the red/replaceable text here.  

I believe Richard’s point here is that we ought to at least match up with the 
ASF’s original text as the starting point, even if it doesn’t make a difference 
for matching purposes. And I’d agree.   (Richard - correct me if I’m wrong 
there)

So, I was going to make these updates.

But then Philippe asked:  


> On Mar 29, 2017, at 12:02 PM, Philippe Ombredanne <pombreda...@nexb.com> 
> wrote:
> 
> On Tue, Mar 28, 2017 at 8:28 PM, J Lovejoy <opensou...@jilayne.com> wrote:
>> Thanks Richard. We will update this for the next release.
>> 
>> Also note, this text is considered "replaceable" for purposes of license
>> matching as per license matching guideline 2.1.3 and as indicated by the red
>> text on the website.
> 
> Jilayne:
> What about tracking and keeping the original text too?
> Having  only one text that is systematically marked up is not a great
> solution IMHO.
> For instance it makes the reuse of the text as-is impossible or
> difficult in an attribution
> notice and makes automation there more difficult.
> This kind of usage is important and orthogonal to matching guidelines.

I think you answered your own question when you said it’s orthogonal to the 
matching guidelines. If you want to save the text that is different (and 
allowed to be different as per the matching guidelines / markup) then you are 
free to write a tool to do so. 
 
> 
> And editing for markup is conducive to small mistakes like the one
> Richard found.
> This is likely to be more frequent if you are adding XML markup on top.

Really, how so?  How is editing for ark up conducive for small mistakes like 
the ones that Richard found?  The “mistakes” Richard found may have been there 
from day one and no one caught them. 

And how is the XML markup likely to make small mistakes more frequent? I don’t 
believe I have seen you contributing to the review of the XML conversion 
project, so that seems like a judgement without familiarity, perhaps? 

Having been the almost sole maintainer of the SPDX License List (and hence, the 
main contributor of any mistakes!) I am quite sure that the combination of a 
new format for maintaining the data that comprises the SPDX License List that 
retains every change made in source control plus the format of using Github and 
the ease with which others can see, point out issues or areas where we can 
impro

Incorrect name of HPND

[Richard Fontana]

SPDX gives the name of this license  
as "Historic Permission Notice and Disclaimer", but the OSI website lists it as 
"Historical Permission Notice and Disclaimer". Given that, as a named and 
conceptualized thing, this license is sort of a creature of the OSI license 
list (I have never looked up who actually submitted this for approval, and 
[just as intriguingly] who purported to be the "author" who deprecate it) I 
believe its name should match the name on the OSI list. 

What's the best way to report things like this - this mailing list, or the SPDX 
bugzilla? 

Richard 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Error in SPDX version of Apache-1.0 (was: Re: Error in SPDX version of Apache-1.1)

[Richard Fontana]

The same error exists in the SPDX text for Apache-1.0:
https://spdx.org/licenses/Apache-1.0.html
"4. The "Apache" and "Apache Software Foundation" must not be used to endorse 
or promote products derived from this software without prior written 
permission. For written permission, please contact apa...@apache.org"

Compare to http://www.apache.org/licenses/LICENSE-1.0 : 
*  4. The names "Apache Server" and "Apache Group" must not be used to
 *endorse or promote products derived from this software without
 *prior written permission. For written permission, please contact
 *apa...@apache.org.



On Mon, Mar 27, 2017 at 11:53:53AM -0400, Richard Fontana wrote:
> Hi, 
> 
> The license text for Apache-1.1 
> has for clause 4: "4. The "Apache" and "Apache Software Foundation" must not 
> be used to endorse or promote products derived from this software without 
> prior written permission. For written permission, please contact 
> apa...@apache.org" 
> 
> Assuming the following text at apache.org is or should be treated as 
> authoritative: 
> https://www.apache.org/licenses/LICENSE-1.1 
> 
> the SPDX text is in error, as it is missing the word "names" (and the closing 
> period). 
> 
> See also the template version at 
> https://github.com/spdx/license-list/blob/master/Apache-1.1.txt#L15. 
> 
> Richard 
> 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Error in SPDX version of Apache-1.1

[Richard Fontana]

Hi, 

The license text for Apache-1.1 
has for clause 4: "4. The "Apache" and "Apache Software Foundation" must not be 
used to endorse or promote products derived from this software without prior 
written permission. For written permission, please contact apa...@apache.org" 

Assuming the following text at apache.org is or should be treated as 
authoritative: 
https://www.apache.org/licenses/LICENSE-1.1 

the SPDX text is in error, as it is missing the word "names" (and the closing 
period). 

See also the template version at 
https://github.com/spdx/license-list/blob/master/Apache-1.1.txt#L15. 

Richard 

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: legal call today!

[Richard Fontana]

On Mon, Jan 09, 2017 at 09:03:25AM +, Zavras, Alexios wrote:
> At least, Mark, net-snmp includes a version number to the collection of 
> licenses!
> The other well-known culprit is newlib, with its infamous “COPYING.NEWLIB” 
> (also a collection): https://sourceware.org/newlib/COPYING.NEWLIB
> … which does not include any identifier for different versions.
> 
> [sorry for venting, I have spent too much time on this]

That's just a file that is intended to collect certain license notices
-- it doesn't claim to be some sort of atomic 'license stack'.

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: SPDX should not list licenses that might infringe copyright themselves (was Re: New License/Exception Request)

[Richard Fontana]

On Tue, Jan 03, 2017 at 09:54:44AM -0800, Bradley M. Kuhn wrote:
> Richard Fontana wrote:
> >It appears to be for the most part a translation of GPLv3 into Spanish.
> Malcolm Bain confirmed:
> >>As Richard says, this is 90% or more a direct translation of GPLv3. 
> 
> Is the translation authorized?  Is it in compliance with the FSF's published
> meta-license of the GPL?

I consider the true meta-license to be this
https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL
(which is more liberal than the meta-license given at the top of the GPL text).

Presumably it is not in compliance with that meta-license unless the
FSF has given authorization.
 
> While, as my personal position, I have been on record for many years saying
> that I believe license texts themselves should be licensed as CC-0, the FSF
> doesn't agree.  FSF's license texts are themselves governed by copyright and
> under a no-modifications-allowed license, which means translations are only
> permitted with permission from the FSF.

FWIW, as you may recall, bkuhn, I relied on the GPL FAQ meta-license
during the earliest days of what (thanks to your naming suggestion)
became known as copyleft-next, as initially the text was fairly close
to that of GPLv3. But copyleft-next never copied the Preamble.

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request

[Richard Fontana]

It appears to be for the most part a translation of GPLv3 into Spanish. 

- Original Message -

From: "Brad Edmondson"  
To: "J Lovejoy"  
Cc: "David Nina M." , "SPDX-legal" 
, "Malcolm Bain"  
Sent: Thursday, December 22, 2016 4:49:55 PM 
Subject: Re: New License/Exception Request 

Thanks Jilayne, 

As we discussed on today's call, I reviewed a Google translation of the license 
web page. Based on quick overview, it seems to be pretty standard copyleft. I 
agree that we should plan on adding it to the SPDX list. 

Best, 
Brad 

-- 
Brad Edmondson, Esq. 
512-673-8782 | brad.edmond...@gmail.com 

On Thu, Dec 22, 2016 at 2:09 PM, J Lovejoy < opensou...@jilayne.com > wrote: 



Hola, 

We would like to add this license to the SPDX License List. None of us 
reviewing the license are fluent Spanish speakers. Could you verify that this 
is an open source license according to the OSI definition? 

I’ve also copied Malcolm Bain here, as he may be able to help answer this 
question :) 

 

Nos gustaría añadir esta licencia a SPDX License List. Ninguno de nosotros 
revisar la licencia son hablantes de español con fluidez. ¿Podría verificar que 
se trata de una licencia de código abierto de acuerdo con la definición OSI? 

También he copiado a Malcolm Bain aquí, ya que él puede ser capaz de ayudar a 
responder a esta pregunta :) 

Lo siento por el retraso. 
 

Gracias, 
Jilayne 

SPDX Legal Team co-lead 
opensou...@jilayne.com 





On Sep 29, 2016, at 7:29 AM, David Nina M. < nmtda...@gmail.com > wrote: 

Hola SPDX, 
Envió datos para Nueva Solicitud de licencia 

New License 
1.- Provide a proposed Full Name for the license or exception. 
Licencia Pública General para Bolivia 

2.- Provide a proposed Short Identifier. 
LPG-Bolivia 

3.- Provide a functioning url reference to the license or exception text, 
either from the author or a community recognized source. 
https://softwarelibre.gob.bo/licencia.php 

4.- Create and attach a text file with the license or exception text from the 
url provided in #3. Please proofread the text file to ensure that: 

Information has not been lost or modified. 
Formatting is clean and consistent with the license or exception URL. 

5.- Indicate whether the license is OSI-approved (see: 
http://www.opensource.org/licenses/alphabetical ) or whether it has been 
submitted for approval to the OSI and is currently under review. 

6.- Provide a short explanation regarding the need for this license or 
exception to be included on the SPDX License List, including identifying at 
least one program that uses this license. 

Es muy importante incorporar este tipos de licencia a todo tipo de Software 
desarrollado en el territorio de Bolivia y su uso libre. 
Hacer que no solo las instituciones públicas de Bolivia, puedan usarla sino 
hacer que el conjunto de los desarrolladores puedan utilizarla y hacer crecer 
la comunidad de Software Libre en Bolivia. 
Este proyecto debe contener una licencia LPG-Bolivia 
https://www.npmjs.com/package/codigos-gob-bo 


 ___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 





___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 






___ 
Spdx-legal mailing list 
Spdx-legal@lists.spdx.org 
https://lists.spdx.org/mailman/listinfo/spdx-legal 

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: Short identifiers

[Richard Fontana]

Thanks Jilayne and Gary - that was the kind of information I was looking for!

Richard

- Original Message -
From: "J Lovejoy" <opensou...@jilayne.com>
To: "Gary O'Neall" <g...@sourceauditor.com>
Cc: "Richard Fontana" <rfont...@redhat.com>, "SPDX-legal" 
<spdx-legal@lists.spdx.org>
Sent: Friday, December 9, 2016 2:39:10 PM
Subject: Re: Short identifiers

Hi Richard,

Of course there are conventions!  Gary already sent you the link.  The only 
other thing I’d add that is too obvious to state on that list is that we make 
sure there are no other licenses with the proposed short identifier.  

We also try and contact the license author, if they are not the one requesting 
the license for any input as to the short identifier.  This is a more recent 
practice, so I should probably add a bullet to that list!

Thanks
Jilayne


SPDX Legal Team co-lead
opensou...@jilayne.com


> On Dec 9, 2016, at 11:31 AM, g...@sourceauditor.com wrote:
> 
> Hi Richard,
> 
> I found this which describes the short identifier conventions:
> https://spdx.org/spdx-license-list/license-list-overview#fields
> 
> Gary
> 
>> -Original Message-
>> From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-
>> boun...@lists.spdx.org] On Behalf Of Richard Fontana
>> Sent: Thursday, December 8, 2016 10:06 PM
>> To: spdx-legal@lists.spdx.org
>> Subject: Short identifiers
>> 
>> Hi,
>> 
>> Are there any established SPDX standards or conventions for devising a
> short
>> identifier for a license? I assume not but wanted to check.
>> 
>> Richard
>> ___
>> Spdx-legal mailing list
>> Spdx-legal@lists.spdx.org
>> https://lists.spdx.org/mailman/listinfo/spdx-legal
> 
> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Short identifiers

[Richard Fontana]

Hi,

Are there any established SPDX standards or conventions for devising a
short identifier for a license? I assume not but wanted to check.

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New OSI approved licenses

[Richard Fontana]

Yes, changing should not be inconvenient; I recently created those
pages and haven't publicized the URLs beyond updating the global lists
of OSI approved licenses on the website.


On Tue, Jan 19, 2016 at 09:38:58PM +, Philip Odence wrote:
> +1, thanks, Richard. 
> We may need to tweak the short identifiers, at least the one with a “+” 
> because
> that is an operator in the license expression language. 
> We appreciate your keeping us in the loop; it would be great if we could get
> involved even sooner in the process. Ideally, we could settle on an identifier
> before you create a URL, so we could keep those consistent. You mention that
> the license text is CURRENTLY at the URLs; does that imply there is still
> flexibility to change?
> Thanks,
> Phil
> 
> From: <spdx-legal-boun...@lists.spdx.org> on behalf of Paul <pmad...@cox.net>
> Date: Monday, January 18, 2016 at 8:06 PM
> To: Richard Fontana <font...@opensource.org>, "spdx-legal@lists.spdx.org" <
> spdx-legal@lists.spdx.org>
> Subject: Re: New OSI approved licenses
> 
> Thank you Richard.  The SPDX legal team will review the licenses for
> inclusion on the SPDX license list.
> 
> Best,
> 
> Paul Madick
> SPDX Legal Team co-lead
> 
> On 1/17/2016 5:50 PM, Richard Fontana wrote:
> 
> Greetings spdx-legal,
> 
> The OSI recently approved three new licenses:
> Licence Libre du Québec – Permissive (LiLiQ-P) v1.1
> Licence Libre du Québec – Réciprocité (LiLiQ-R) v1.1
> Licence Libre du Québec – Réciprocité forte (LiLiQ-R+) v1.1
> 
> (of some historical significance as the first non-English-language
> OSI-approved licenses)
> 
> The texts of the licenses are currently at
> http://opensource.org/licenses/LiLiQ-P-1.1
> http://opensource.org/licenses/LiLiQ-R-1.1
> http://opensource.org/licenses/LiLiQ-Rplus-1.1
> respectively, but they do not include the 'English translation' given
> on those pages following the license texts themselves.
> 
> I am hoping that the SPDX group will be willing to designate a short
> identifier for these licenses. FWIW, as can be seen, the license
> steward refers to the suite as 'LiLiQ' and uses the abbreviations
> 'LiLiQ-P', 'LiLiQ-R' and 'LiLiQ-R+' respectively.
> 
>Richard
>   
> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal
> 
> 
> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal
> 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

New OSI approved licenses

[Richard Fontana]

Greetings spdx-legal,

The OSI recently approved three new licenses:
Licence Libre du Québec – Permissive (LiLiQ-P) v1.1
Licence Libre du Québec – Réciprocité (LiLiQ-R) v1.1
Licence Libre du Québec – Réciprocité forte (LiLiQ-R+) v1.1

(of some historical significance as the first non-English-language
OSI-approved licenses)

The texts of the licenses are currently at
http://opensource.org/licenses/LiLiQ-P-1.1
http://opensource.org/licenses/LiLiQ-R-1.1
http://opensource.org/licenses/LiLiQ-Rplus-1.1
respectively, but they do not include the 'English translation' given
on those pages following the license texts themselves.

I am hoping that the SPDX group will be willing to designate a short
identifier for these licenses. FWIW, as can be seen, the license
steward refers to the suite as 'LiLiQ' and uses the abbreviations
'LiLiQ-P', 'LiLiQ-R' and 'LiLiQ-R+' respectively.

 Richard
 
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New OSI-approved licenses

[Richard Fontana]

I discussed the issue with Christian Bundy. He does not wish to change
the name of the license. With respect to the Zero Clause BSD License I
have therefore retained the existing approach on the OSI website:

https://opensource.org/licenses/alphabetical (Zero Clause BSD included
in list, with "0BSD" identifier, with cross reference to Free Public
License)

https://opensource.org/licenses/FPL-1.0.0 (explanatory note
acknowledges existence of identical Zero Clause BSD License)

Richard



On Tue, Dec 15, 2015 at 12:12:47PM -0600, Rob Landley wrote:
> Back home from traveling, I believe the ball is still in your court on this?
> 
> Rob
> 
> On 12/10/2015 08:58 AM, Richard Fontana wrote:
> > I don't think that is a good idea.
> > 
> > I have described the situation to Christian Bundy, the person who
> > submitted the Free Public License, with a link to this discussion. He
> > said he would get back to me by the end of the week. If Christian does
> > not recommend otherwise I will keep things as they currently are on
> > the OSI website.
> > 
> > Richard
> > 
> > 
> > On Thu, Dec 10, 2015 at 07:31:00AM +, J Lovejoy wrote:
> >> Having more of a think on this - It may be more appropriate for Rob to 
> >> talk to the “Free Public License” folks.  
> >> Rob - your thoughts?  
> >>
> >> Cheers,
> >> Jilayne
> >>
> >>
> >>>
> >>> On Tue, Dec 08, 2015 at 06:56:09AM -0500, Richard Fontana wrote:
> >>>> Hi Jilayne,
> >>>>
> >>>> No but that was my thought as well after reading Rob's response. I
> >>>> will check.
> >>>>
> >>>> Thanks,
> >>>> Richard
> >>>>
> >>>>
> >>>> On Tue, Dec 08, 2015 at 08:16:15AM +, J Lovejoy wrote:
> >>>>> Richard,
> >>>>>
> >>>>> Has anyone from OSI gone back to the folks who submitted the “Free 
> >>>>> Public License” and ask if they mind or care if the name that Rob 
> >>>>> prefers is used instead of the one they suggested?  Seems like that 
> >>>>> could potentially be an easy solution.
> >>>>>
> >>>>> Jilayne
> >>>>>
> >>>>> SPDX Legal Team co-lead
> >>>>> opensou...@jilayne.com
> >>>>>
> >>>>>
> >>>>>> On Dec 8, 2015, at 6:17 AM, Rob Landley <r...@landley.net> wrote:
> >>>>>>
> >>>>>> The tl;dr of this whole email is "I humbly ask SPDX to retain both its
> >>>>>> original long and short names for zero clause BSD as the only SDPX
> >>>>>> approved name for this license".
> >>>>>>
> >>>>>> On 12/07/2015 01:56 PM, Richard Fontana wrote:
> >>>>>>> On Mon, Dec 07, 2015 at 07:30:18PM +, J Lovejoy wrote:
> >>>>>>> 3) While I have no inherent problem with the name 'Zero Clause BSD
> >>>>>>> License', it does bother me that the name has 'BSD' in it but the
> >>>>>>> license text is not clearly descended from the BSD license family.
> >>>>>>
> >>>>>> "I have no problem, and here it is..."
> >>>>>>
> >>>>>>> In this sense both the name and the identifier are flawed. There is no
> >>>>>>> parallelism between the Zero Clause BSD License and the well-known
> >>>>>>> 3-clause and 2-clause BSD licenses. I would probably not be objecting
> >>>>>>> to the identifier if it were '0ISC' rather than '0BSD' because the
> >>>>>>> Zero Clause BSD License is a stripped-down ISC license, not a
> >>>>>>> stripped-down BSD license.
> >>>>>>
> >>>>>> So you still haven't looked back at the SPDX approval process for zero
> >>>>>> clause BSD and noticed they raised that objection then, and got an 
> >>>>>> answer?
> >>>>>>
> >>>>>> http://lists.spdx.org/pipermail/spdx-legal/2015-June/001457.html
> >>>>>>
> >>>>>> If the association between this license and ISC was important, why
> >>>>>> didn't OSI's name for it mention ISC instead of making up a new name?
> >>>>>>
> >>>>>> This is not the only public domain license derived from BSD licens

Re: New OSI-approved licenses

[Richard Fontana]

On Mon, Dec 07, 2015 at 07:30:18PM +, J Lovejoy wrote:
> Correct me if I’m wrong, but the suggestion seems to be:
> 
> OSI has now posted the "Free Public License 1.0.0" and wants to use the short 
> identifier FPL-1.0.0 

Well that identifier (or something else that bears some similarity to
the license name as approved by the OSI) is my own suggestion, not the
view of the whole OSI board. I haven't bothered to explain this issue
to the board, as I'm not sure it's that significant.

> This license is, according to the SPDX Matching Guidelines, the same license 
> the Rob submitted previously and which was added to SPDX License List v2.2 as 
> "BSD Zero Clause License” using the short identifier 0BSD
> 
> Now, the OSI wants SPDX to change its short identifier to FPL-1.0.0 - is that 
> right?  And if so, why would you want us to do that?  

My reasoning is as follows:

1) The license that was submitted to and approved by the OSI is called
the 'Free Public License 1.0.0'. I note that Rob Landley chose not to
submit the Zero Clause BSD License for OSI approval as of course is
his prerogative.

2) I think it is confusing to have a short identifier that looks
nothing like the name of the thing, especially given that most if not
all of the SPDX short identifiers have some clear relationship to the
name of the license being identified.

3) While I have no inherent problem with the name 'Zero Clause BSD
License', it does bother me that the name has 'BSD' in it but the
license text is not clearly descended from the BSD license family. In
this sense both the name and the identifier are flawed. There is no
parallelism between the Zero Clause BSD License and the well-known
3-clause and 2-clause BSD licenses. I would probably not be objecting
to the identifier if it were '0ISC' rather than '0BSD' because the
Zero Clause BSD License is a stripped-down ISC license, not a
stripped-down BSD license.

4) Since I am coming at this from a viewpoint that is biased in favor
of the name of the license as submitted to the OSI, I can only object
to the idea that OSI should be expected to apply the identifier '0BSD'
to a license called the Free Public License 1.0.0.

5) For some time there's been some desire on the part of the OSI to
make use of the SPDX identifiers, and you can see evidence of this on
the OSI website. But I think with the Free Public License 1.0.0 and
also the recently-approved eCos License version 2.0 this policy has
reached a breaking point. In the case of eCos we can't seriously be
expected to entertain use of a short identifier that is longer than
the name of the license.

> We endeavor not to change the short identifiers unless there is an extremely 
> compelling reason and users of the SPDX License List (of which there are 
> many) rely on us to not make such changes unnecessarily.  I’m not sure I see 
> the compelling reason here, especially when, as Rob has now told us, part of 
> the reason he submitted the license to be on the SPDX License List was as per 
> the request of a large company using the SPDX short identifiers.  

I'm not suggesting that the identifier be changed, but rather that two
identifiers be adopted, each being considered equally official in an
SPDX sense. 

Ultimately, the issue isn't too important, but I simply can't bring
myself to use "0BSD" on the OSI website in the manner in which other
SPDX short identifiers have now been used. (Although as noted I did
use '0BSD' in my cross-referencing of the Zero Clause BSD License to
the Free Public License.) Similarly, I can't bring myself to use the
lengthy GPL exception identifier in connection with the eCos License.

Richard



> We do have some flexibility with the full name, which would be reasonably to 
> change to something like, "BSD Zero Clause / Free Public License 1.0.0” 
> (clunky, perhaps) and then also add a note as Richard did explaining the 
> similarity-yet-name-variation-possibility.  However, changing the short 
> identifier is a much more serious consideration. We have a legal call this 
> Thursday, so any info as to why we should change that part or if my above 
> idea would be amenable to all would be helpful.
> 
> Thanks,
> 
> Jilayne
> 
> SPDX Legal Team co-lead
> opensou...@jilayne.com
> 
> 
> > On Dec 5, 2015, at 12:36 PM, Richard Fontana <font...@opensource.org> wrote:
> > 
> > On Sat, Dec 05, 2015 at 12:57:43AM -0600, Rob Landley wrote:
> >> As far as I can tell, OSI continues to be unaware that unlicense.org or
> >> creative commons zero even exist.
> > 
> > The OSI is aware of them. There's actually been interest for some time
> > in getting OSI approval of a license (or license-like instrument) in
> > this category, what I've recently been calling 'ultrapermissive'. CC0
> > was actually submitted by Creative Comm

Re: New OSI-approved licenses

[Richard Fontana]

On Sat, Dec 05, 2015 at 12:57:43AM -0600, Rob Landley wrote:
> As far as I can tell, OSI continues to be unaware that unlicense.org or
> creative commons zero even exist.

The OSI is aware of them. There's actually been interest for some time
in getting OSI approval of a license (or license-like instrument) in
this category, what I've recently been calling 'ultrapermissive'. CC0
was actually submitted by Creative Commons for OSI approval a few
years ago. The submission was withdrawn because of controversy over
clause 4a in CC0 ("No ... patent rights held by Affirmer are waived,
abandoned, surrendered, licensed or otherwise affected by this
document."). The Unlicense hasn't been submitted for approval.

I have now modified http://opensource.org/licenses/alphabetical to
include Zero Clause BSD License (0BSD) with a cross reference to the
Free Public License, and I have also added the following prefatory
text to http://opensource.org/licenses/FPL-1.0.0:
"Note: There is a license that is identical to the Free Public License
1.0.0 called the Zero Clause BSD License. Apart from the name, the
only difference is that the Zero Clause BSD License has generally been
used with a copyright notice, while the Free Public License has
generally been used without a copyright notice."

Hopefully that will remove whatever possibility there was of anyone
thinking the Zero Clause BSD License (for those who choose to call it
that) is not now OSI-approved by virtue of the approval of the Free
Public License.

However I still recommend that the SPDX group come up with a short
identifier for the Free Public License that is different from "0BSD";
I'm going to pretend that it would be "FPL-1.0.0".

Richard



___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New OSI-approved licenses

[Richard Fontana]

Not really. I respect your desire to keep the name of the license
you've been using and appreciate your policy objections to the name of
the Free Public License; however I have no inclination to ask the OSI
to change the name of the approved license (which seems to differ from
0BSD in one respect, namely the normative non-inclusion of a template
copyright notice). 

I think then, if we assume that 0BSD and the Free Public License are
really the same license from the SPDX world view standpoint, that this
may unfortunately be the first departure from the trend of OSI
endorsing the use of SPDX short names (I think the one for the
recently-approved eCos license is a little problematic too). I
encourage the SPDX group to consider coming up with a new short name
for the Free Public License without altering the status of 0BSD.

- RF



On Fri, Dec 04, 2015 at 07:37:55PM -0600, Rob Landley wrote:
> Did this ever get resolved?
> 
> On 11/17/2015 12:51 AM, Richard Fontana wrote:
> > On Tue, Nov 17, 2015 at 01:32:44AM -0500, Richard Fontana wrote:
> >>>> 2) Free Public License 1.0.0
> >>>> Text of approved license contained within:
> >>>>
> https://lists.opensource.org/pipermail/license-review/2015-August/001104.html
> >>>
> >>>  We have added as of v2.2 - http://spdx.org/licenses/0BSD.html -
> although it was submitted using a different name as suggested by the
> submitter (who I think said he authored the license… or at least seemed
> to know a lot about it’s origins and the suggested name, which we went
> with - see
> http://lists.spdx.org/pipermail/spdx-legal/2015-June/001443.html for
> that thread).
> >>>
> >>> Would the OSI oppose the name we already went with??
> >>
> >> Hmm, I think this is really a case of two people independently
> >> inventing approximately the same thing at about the same time,
> 
> Given the timeline, it's more likely they copied the license from Android.
> 
> March 2013:
> 
> I start using this license:
> http://lists.landley.net/pipermail/toybox-landley.net/2013-March/000794.html
> 
> November 2014:
> 
> Android merges toybox to replace toolbox:
> https://code.google.com/p/android/issues/detail?id=76861#c11
> 
> January 2015:
> 
> Linux Weekly News covers toybox's addition to Android:
> https://lwn.net/Articles/629362/
> 
> May 2015:
> 
> Android-M preview containing toybox distributed to developers:
> https://en.wikipedia.org/wiki/Android_Marshmallow
> 
> June 2015:
> 
> Either Samsung or Sony (I forget which) asks me to submit the the toybox
> license to SPDX to simplify their internal paperwork:
> http://lists.spdx.org/pipermail/spdx-legal/2015-June/001443.html
> 
> August 30, 2015:
> 
> These guys submit the license to OSI.
> https://lists.opensource.org/pipermail/license-review/2015-August/001104.html
> 
> I didn't submit my public domain equivalent license to OSI because their
> lawyer wrote an article literally comparing public domain software to
> abandoning trash by the side of a highway
> (http://www.linuxjournal.com/article/6225 paragraph 5), and if you
> google for "Linux Public Domain" it's still the second hit.
> 
> >> where
> >> 'invention' means removing some language from an existing short
> >> license.
> 
> Yes, it is a minor variant of an existing BSD license.
> 
> Specifically, the OpenBSD template license
> (http://www.openbsd.org/policy.html links to
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/misc/license.template?rev=HEAD)
> which is why I felt justified in calling it a BSD license.
> 
> There were already "2 clause", "3 clause", and "4 clause" BSD licenses
> commonly referred to, "zero clause" to mean public domain didn't seem
> like a stretch (and is also what the Creative Commons guys chose with
> CC0). It also makes it easy for corporate legal departments that have
> approved existing BSD licenses to rubber-stamp another.
> 
> I chose this name for a reason. In the "copyleft vs bsd" axis, this is
> more BSD than BSD. "Free" is the Free Software Foundation's rallying cry
> (and the reason OSI had to come up with "Open Source" to counter "Free
> Software"). Sticking the word "Free" on a public domain equivalent
> license (as far from copyleft as you can get) is either intentionally
> confusing or deeply clueless.
> 
> Part of my attraction to public domain licensing is trying to counteract
> the damage GPLv3 did to the community at large when it fragmented
> copyleft into incompatible factions. There's no such thing as "The GPL"
> anymore, Linux and Samba implement two 

CFP - FOSDEM 2016 Legal & Policy Issues DevRoom

[Richard Fontana]

FOSDEM 2016 (30-31 January, 2016, Brussels) will have a two-day legal
and policy issues track. In past years there have been SPDX-related
talks. CFP details here:
https://lists.fosdem.org/pipermail/fosdem/2015-October/002202.html

The deadline for submissions is Sunday 29 November 2015 at 23:00 UTC.
Speakers will be notified on or before Friday 4 December 2015.

Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New OSI-approved licenses

[Richard Fontana]

On Mon, Nov 16, 2015 at 10:24:34PM -0700, J Lovejoy wrote:

> > The OSI recently approved three licenses as Open Source:
> > 
> > 1) eCos License version 2.0 (under the 'Legacy Approval' process)
> > Text of approved license contained within:
> > https://lists.opensource.org/pipermail/license-review/2014-August/000853.html
> > 
> > Note that the interesting part of this license is identical to
> > http://spdx.org/licenses/eCos-exception-2.0.html#licenseExceptionText
> 
> The short identifier is already defined for SPDX using the “with” operator 
> and the exception identifier. It would be:
> 
>   GPL-2.0+ WITH eCos-exception-2.0

Ah, okay. That makes sense. The only issue is that for some time there
has been a desire for the URLs for licenses on the OSI website to
match the SPDX short identifier. I think we will probably use 'eCos'
for the URL rather than 'GPL-2.0+ WITH eCos-exception-2.0' and to that
extent we will have to change the current practice of honoring the
SPDX identifiers.
 
> Unless anyone thinks otherwise, I would think that license expression could 
> be noted on the OSI site in the same way the other SPDX identifiers are??

I believe what's currently done is that the SPDX identifier is used in
two contexts, in the general list of OSI-approved licenses and in the
URLs. I don't see a problem with using 'GPL-2.0+ WITH
eCos-exception-2.0' in the list but as noted I think it would be
problematic to use it in the URL.

> This does raise for us the question as to whether we need to add an “OSI 
> Approved” column to the exceptions list.  To my knowledge, this is the only 
> GPL exception that has been specifically approved by OSI, is that right?

There is one other, the wxWindows Library License:
http://opensource.org/licenses/WXwindows
Not to mention LGPL version 3.

> > 2) Free Public License 1.0.0
> > Text of approved license contained within:
> > https://lists.opensource.org/pipermail/license-review/2015-August/001104.html
> 
>  We have added as of v2.2 - http://spdx.org/licenses/0BSD.html -  although it 
> was submitted using a different name as suggested by the submitter (who I 
> think said he authored the license… or at least seemed to know a lot about 
> it’s origins and the suggested name, which we went with - see 
> http://lists.spdx.org/pipermail/spdx-legal/2015-June/001443.html for that 
> thread).
> 
> Would the OSI oppose the name we already went with??

Hmm, I think this is really a case of two people independently
inventing approximately the same thing at about the same time, where
'invention' means removing some language from an existing short
license. The one possible textual difference is that the Free Public
License does not normatively contain a copyright notice (at least, in
the discussion on the license-review list, it seemed to be assumed
that the license would be used without a copyright notice, and no
actual or template copyright notice was part of the text submitted by
the license submitter).

I can't see OSI wanting to identify this as '0BSD', in part because it
is not actually based directly on the BSD license contrary to what Rob
Landley seemed to be saying. I mean, I personally would be opposed to
OSI referring to this as '0BSD' because I think it can only possibly
be confusing. And this license is actually a relatively important one
as it fills a significant gap in the policy range of OSI-approved
licenses.

So with all respect to Mr. Landley I would like to ask the SPDX group
to consider changing '0BSD' to 'FPL' (if that's available) or else
something closer to 'Free Public License'. 

(From the SPDX perspective, I gather the presence or absence of the
copyright notice at the top does not affect whether it is treated as
the same license? Unlike the current situation with the BSD or MIT or
ISC licenses, when the Free Public License is published on the OSI
website there will not be a template copyright notice.)

> > 3) OSET Foundation Public License version 2.1
> > We don't quite have a canonical license document here yet (the license
> > that was approved was a conceptually-typo-corrected version of a
> > redline document).
> 
> Great - we’ll need the license text - do you want to just let us know when 
> you have the final version?

Sure, I'll have that ready soon.

Thanks,
Richard
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New OSI-approved licenses

[Richard Fontana]

On Tue, Nov 17, 2015 at 01:32:44AM -0500, Richard Fontana wrote:
> > > 2) Free Public License 1.0.0
> > > Text of approved license contained within:
> > > https://lists.opensource.org/pipermail/license-review/2015-August/001104.html
> > 
> >  We have added as of v2.2 - http://spdx.org/licenses/0BSD.html -  although 
> > it was submitted using a different name as suggested by the submitter (who 
> > I think said he authored the license… or at least seemed to know a lot 
> > about it’s origins and the suggested name, which we went with - see 
> > http://lists.spdx.org/pipermail/spdx-legal/2015-June/001443.html for that 
> > thread).
> > 
> > Would the OSI oppose the name we already went with??
> 
> Hmm, I think this is really a case of two people independently
> inventing approximately the same thing at about the same time, where
> 'invention' means removing some language from an existing short
> license.

Looks like Rob Landley was using it a year or more earlier:
https://lwn.net/Articles/608082/

Decided to copy in Rob Landley here. Rob: the license contained herein
https://lists.opensource.org/pipermail/license-review/2015-August/001104.html
was recently approved by the Open Source Initiative under the name
'Free Public License 1.0.0', and it has only now come to light (for
me, or anyone associated with the OSI) that you have been using an
essentially identical license (apart from presence/absence of an
initial copyright notice) which you call 'Zero Clause BSD'.

Richard

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal