RE: revised wording for top of exceptions page

[Wheeler, David A]

Perhaps the term “exceptions” is confusing & should be renamed.  If so, how 
about “additional terms”?

It seems to me that “exceptions” have both *add* or *remove* requirements, but 
it appears that others do not.

--- David A. Wheeler


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Richard Fontana
Sent: Monday, July 10, 2017 3:32 PM
To: W. Trevor King
Cc: SPDX-legal
Subject: Re: revised wording for top of exceptions page

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



From: "W. Trevor King" mailto:wk...@tremily.us>>
To: "Phil Odence" 
mailto:pode...@blackducksoftware.com>>
Cc: "SPDX-legal" mailto:spdx-legal@lists.spdx.org>>
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: Your license: full name and identifier - BSD-2-Clause-Patent?

[Wheeler, David A]

Is the final formal SPDX name for React, etc., going to be 
"BSD-2-Clause-Patent"?
That's what is listed here:
  https://opensource.org/licenses/BSDplusPatent

Thanks.

--- David A. Wheeler

> -Original Message-
> From: spdx-legal-boun...@lists.spdx.org [mailto:spdx-legal-
> boun...@lists.spdx.org] On Behalf Of Richard Fontana
> Sent: Friday, July 21, 2017 1:27 PM
> To: J Lovejoy
> Cc: McCoy Smith; SPDX-legal
> Subject: Re: Your license: full name and identifier
> 
> I created a redirect so that now both
> https://opensource.org/BSDplusPatent and https://opensource.org/BSD-2-
> Clause-Patent both go to https://opensource.org/node/865/ (or something
> functionally equivalent to that).
> 
> On Thu, Jul 20, 2017 at 04:45:22PM -0600, J Lovejoy wrote:
> > Richard,
> >
> > Can you update the OSI URL to the short identifier - I see it got added in 
> > the
> parenthetical, but the URL did not get updated as per usual process.
> > https://opensource.org/licenses/BSDplusPatent
> > 
> >
> > Jilayne
> >
> > SPDX Legal Team co-lead
> > opensou...@jilayne.com
> >
> >
> > > On Jun 22, 2017, at 9:27 AM, Richard Fontana
>  wrote:
> > >
> > > Hi Jilayne,
> > >
> > > Short identifier, yes - I will make those changes shortly. OSI has
> > > not been attempting to track the SPDX full names and has not been
> > > trying to replace the OSI-used names with SPDX full names, for
> > > example in listings of licenses or headings of license pages.
> > >
> > > In most cases I think the SPDX full name is either the same as the
> > > OSI-used name or is substantially the same. But, unlike the
> > > situation for the short identifiers which have been somewhat
> > > successful, I do not see any signs of a community or industry
> > > tendency to adopt the SPDX full names. In a few cases I think the
> > > full name used by SPDX would be impractical or confusing for OSI to
> > > use, and in a few cases I consider the SPDX full name to be wrong
> > > (for example, the name does not match the name of the license that
> > > is officially noted in the canonical license text). Anyway, I don't
> > > particularly see a benefit in non-SPDX adoption of the SPDX full names.
> > >
> > > I assumed McCoy was not requesting that the OSI change "BSD+Patent"
> > > to the SPDX full name for OSI purposes. I would recommend against
> > > this for reasons I've already stated -- most importantly I think
> > > "BSD+Patent" is a better name than " BSD-2-Clause plus Patent
> > > License", and "BSD-2-Clause" is not yet a standard *full* name for
> > > the 2-clause BSD license in the open source community. But if McCoy
> > > wants to change the OSI name of BSD+Patent he can request that by
> > > contacting the OSI or through license-review.
> > >
> > > Richard
> > >
> > >
> > > On Thu, Jun 22, 2017 at 09:02:52AM -0600, J Lovejoy wrote:
> > >> Thanks McCoy!  We’ll get this on the SPDX License List for the next
> release.  I trust OSI will update their page with the short identifier and 
> full
> name accordingly as well.
> > >>
> > >> Cheers,
> > >> Jilayne
> > >>
> > >> SPDX Legal Team co-lead
> > >> opensou...@jilayne.com
> > >>
> > >>
> > >>> On Jun 19, 2017, at 11:12 AM, Smith, McCoy 
> wrote:
> > >>>
> > >>> All:
> > >>>
> > >>> After some back and forth with Jilayne, we believe the best naming
> approach (for SPDX purposes) from the “BSD+Patent
> ” license recently added to
> the OSI list to be:
> > >>>
> > >>> Full name:   BSD-2-Clause plus Patent License
> > >>>
> > >>> SPDX Identifier: BSD-2-Clause-Patent
> > >>>
> > >>> [Note there is something that Facebook is using that they have recently
> started calling “ <>BSD+Patents
> ” but this isn’t on the
> OSI list nor is it a fully intact license, but a BSD 3-clause with a separate
> additional patent grant found elsewhere; I’m not sure how SPDX might (or
> has) handled that although I think you treat additional grants appended to
> existing OSI licenses differently].
> > >>>
> > >>> This approach is most consistent with naming conventions used by
> SPDX and OSI, and keeping in mind concerns about using special characters
> (“+”) in certain contexts in which mechanical/computerized review is used.
> > >>>
> > >>> Let me know if you have any questions on this.
> > >>>
> > >>> McCoy Smith
> > >>> Intel Corporation
> > >>> Law & Policy Group
> > >>> ___
> > >>> 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

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

[Wheeler, David A]

> From: Richard Fontana [mailto:font...@opensource.org]
> BSD+Patent is not the React license. React uses the 3-clause BSD
> license along with a patent license grant with some termination language in a
> separate file:
> https://github.com/facebook/react/blob/master/PATENTS (which has been
> controversial, in part because the scope of the termination is broader than
> what's seen in post-early-2000s open source licenses).
> 
> BSD+Patent is based on 2-clause BSD along with a patent license grant
> that is influenced by language in the Apache License 2.0 and EPL 1.0, and it
> has no termination language.

Ah!  Thanks so much for the clarification.

In that case, what *is* the SPDX license id or expression for the license used 
by many widely-used Facebook projects, including React.js?  If there isn't one, 
we need one ASAP.  It's widely-used *AND* subject to a lot of controversy, so a 
lot of people (including me!) want to know what to look for...!

--- David A. Wheeler

___
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?

[Wheeler, David A]

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.

--- David A. Wheeler

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

New License/Exception Request: ANY-PATENT-ASSERTION-TERMINATES-2.0 as a new exception

[Wheeler, David A]

INTRODUCTION:
Many Facebook projects, including the widely-used React.js, have a different 
license approach than others: They use a stock OSS license *with* a special 
patent-related rider (in the case of React.js, this is in a file named 
PATENTS).  This patent rider is asymmetric, which has led to the Apache 
Software Foundation requiring that *all* of the Apache projects stop 
incorporating any project with this rider, and it appears that other companies 
also have this policy.  Thus, for some organizations it is vital that they be 
able to *detect* this rider.

As far as I can tell SPDX currently has no way to report this information.  
That needs to change.  If SPDX *can* report it, please let me know - maybe I 
missed it!

McCoy Smith has noted that there’s an additional source of confusion:
➢ 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).

This rider is on a number of popular OSS projects, so I think it meets the 
conditions for inclusion.  Also, I think SPDX needs to add this information 
*soon* to eliminate the confusion.  I proposed the name 
“ANY-PATENT-ASSERTION-TERMINATES”.

This license is *NOT* already listed on the “licenses and exceptions under 
consideration”: 
https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681
Again, note that this is NOT the same as BSD-2-Clause-Patent.

Since this rider could be applied to many different kinds of licenses, and 
seems to normally be included as a separate file, I think this should be listed 
as an exception.  Then React's license would be "BSD-3-Clause WITH 
ANY-PATENT-ASSERTION-TERMINATES-2.0", which I think is fairly clear.

I made up the name.  As far as I know this was created by Facebook, but there's 
no reason to believe that it could only be used by Facebook, so I thought it'd 
be better to focus on its effect.  The React text says it's version 2, so I 
think that should be in the name.  I'm sure better names are possible, but I 
think it should be clear that it involves patent assertions leading to 
termination.  What's more, it's not just an assertion related to the software 
being distributed - even a patent assertion *unrelated* to the released 
software will terminate the license (which is why I said "ANY").

=




1. Provide a proposed Full Name for the license or exception: Additional Grant 
of Patent Rights where patent assertion terminates Version 2
2. Provide a proposed Short Identifier: WITH ANY-PATENT-ASSERTION-TERMINATES-2.0
3. Provide a functioning url reference to the license or exception text, either 
from the author or a community recognized source:  
https://github.com/facebook/react/blob/master/PATENTS
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: 
a. Information has not been lost or modified.
b. 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: Not OSI 
approved
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: See above.  It's in wide use, but organizations 
such as the Apache Software Foundation forbid including software licensed with 
this exception, so it's important to report its presence.

I'm attaching the text by copying it below from 
; users might replace 
"Facebook"/"Facebook, Inc." with someone else.

--- David A. Wheeler


=== LICENSE EXCEPTION TEXT ===

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or co

RE: New License/Exception Request: ANY-PATENT-ASSERTION-TERMINATES-2.0 as a new exception

[Wheeler, David A]

> From: W. Trevor King [mailto:wk...@tremily.us]
> There's some previous discussion in [1,2].  The current recommendation is to
> define a custom ID for the patent rider and use that [3], for
> example:
> 
>   BSD-3-Clause AND FB-Patents-2.0

I'm happy with that instead.. I just want a standard way to refer to it.
I'd prefer "Facebook-Patents-2.0" instead of "FB" because "FB" isn't as obvious,
but that is a nit, and either name (or many others) would resolve the problem.

HOWEVER:  This is name is NOT in either:
- https://spdx.org/licenses/
- https://spdx.org/licenses/exceptions-index.html

This id, whatever it is, needs to get into one of those lists *pronto*.
The bug report referenced here is from *2015*, which is ancient history:
> [3]: https://bugs.linuxfoundation.org/show_bug.cgi?id=1292#c2
"Use a licenseRef" is not a reasonable option for a lot of people.
Many tools *only* share license expressions, not entire SPDX files,
and this is an important situation.

Thanks so much!  This issue of "identifying a special patent rider"
is *exactly* the kind of thing that SPDX license expressions can help with...
SPDX just needs to add the necessary license or license exception
to handle it.

--- David A. Wheeler

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

New License Request: FB-Patents-2.0

[Wheeler, David A]

Based on feedback from W. Trevor King (thank you!!), here is round 2.
Here I propose this Facebook rider as a new *license* instead of separate 
license *exception*.
The proposal is below; I'm including a modified "INTRODUCTION" to give context.

INTRODUCTION:
Many Facebook projects, including the widely-used React.js, have a different 
license approach than others: They use a stock OSS license *with* a special 
patent-related rider (in the case of React.js, this is in a file named 
PATENTS).  This patent rider is asymmetric, which has led to the Apache 
Software Foundation requiring that *all* of the Apache projects stop 
incorporating any project with this rider, and it appears that other companies 
also have this policy.  Thus, for some organizations it is vital that they be 
able to *detect* this rider.

As far as I can tell SPDX currently has no way to report this information as a 
standard license or license exception.  That needs to change.  If SPDX *can* 
report it, please let me know - maybe I missed it!

McCoy Smith has noted that there’s an additional source of confusion:
➢ 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).
That OSI-approved license is now referred to as BSD-2-Clause-Patent, but since 
the React license is *different*, this leads to a lot of confusion.

This rider is on a number of popular OSS projects, so I think it meets the 
conditions for inclusion.  Also, I think SPDX needs to add this information 
*soon* to eliminate the confusion.

I had proposed the name “ANY-PATENT-ASSERTION-TERMINATES” as a license 
exception.  However, it has been previously agreed that this situation should 
be handled as a stand-alone license, and then used this way: "(BSD-3-Clause AND 
FB-Patents-2.0)".  Thus, this proposal formalizes the approach that has already 
been agreed to in principle:
https://bugs.linuxfoundation.org/show_bug.cgi?id=1292#c2
My thanks to W. Trevor King for this clarification!

This license is *NOT* already listed on the “licenses and exceptions under 
consideration”: 
https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681
Again, note that this is NOT the same as BSD-2-Clause-Patent.

I suggest this name because it's been referenced before.  There are good 
reasons for using "Facebook-Patents-2.0" instead, since that would be easier to 
find, so I'd be happy with that.  While it need not be used only by Facebook, 
Facebook is the first main user of the license, and many other licenses are 
named by their originator (e.g., MIT and BSD).  I just want to agree on a name.

=




1. Provide a proposed Full Name for the license or exception: Additional Grant 
of Patent Rights where patent assertion terminates Version 2
2. Provide a proposed Short Identifier: FB-Patents-2.0
3. Provide a functioning url reference to the license or exception text, either 
from the author or a community recognized source:  
https://github.com/facebook/react/blob/master/PATENTS
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: 
a. Information has not been lost or modified.
b. 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: Not OSI 
approved
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: See above.  It's in wide use, but organizations 
such as the Apache Software Foundation forbid including software licensed with 
this exception, so it's important to report its presence.

I'm attaching the text by copying it below from 
; users might replace 
"Facebook"/"Facebook, Inc." with someone else.

--- David A. Wheeler


=== LICENSE EXCEPTION TEXT ===

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable 
(subject to the termination provision below) license under any Necessary 
Claims, to make, have made, use, sell, offer to sell, import, and otherwise 
transfer the Software. For avoidance of doubt, no license is granted under 
Facebook's rights in any patent claims that are infringed by (i) modifications 
to the Software made by you or any third party or (ii) the Software in 
combination with any software or other techno

RE: minutes, summary, next steps

[Wheeler, David A]

W. Trevor King:
> Is this proposal different from [1]?  The only think I can see is that the old
> “GPL-2.0 by itself is unclear” issue is now being explicitly embraced (while 
> [1]
> listed it as a potential issue).
> 
> Also, do we have a preferred phrasing for a grant like:
> 
>   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) version 3 of the License.
> 
> Will that be:
> 
> a. GPL-2.0-only OR GPL-3.0-only

The "ONLY" would be an operator, so I'd expect to see:
  (GPL-2.0 ONLY OR GPL-3.0 ONLY)

That is pretty clear.

> b. GPL-2.0 OR GPL-3.0

That would be ambiguous as written, under the current proposal, but there's a 
simple fix that your question raises.

We haven't written the specifics yet, but if ONLY is an operator, we could 
define it to mean "all the licenses on the left-hand-side *only* allow those 
specified versions".  If we defined it that way, then this could be written as:
  (GPL-2.0 OR GPL-3.0) ONLY

I think *that* way of writing it is extremely clear; you don't have to know 
SPDX to figure that one out.  That's probably the clearer way of writing this 
case, if we allow it.

Note that in most cases with the GPL we don't need this at all; usually 
licenses are "GPL-2.0+" or "GPL-3.0+".  But clearly it's important to be able 
to capture the other cases.


> * Add fields to the license metadata and the license-list's XML for
>   “compatible with -only”, “compatible with +”, etc.  That would allow
>   us to report NPL-1.0-only as nonsensical and GPL-2.0 as ambiguous
>   (because it would allow both -only and +).

Not a bad idea.  More generally, hints to help detect bad information could be 
useful.  I know the FSF is concerned about identifying "ambiguous cases", so if 
there was a standard rule for identifying them, that might make them happier.

Note: the "ambiguous" case doesn't necessarily mean it's not *possible* to 
figure it out, just that whoever is *reporting* the information (often a tool) 
doesn't know more.  It may be truly ambiguous (perhaps even the copyright 
holder doesn't know!).  However, the problem is that we all must depend on 
tools to get things done, and tools often just don't have the ability to 
determine if something is "only" or "or later".

Aside: We should all strive to get authors to be clearer, but at this point I'm 
trying to get authors to clearly state a license at *all*.  Getting copyright 
holders to state "only" or "or later" is a degree of specificity that I often 
don't see :-(.  If SPDX can at least make it easier to see when we don't know 
(yet), that'd be a big help.

> * Add a ‘PROXY {TEXT}’ operator for the GPL-3.0's proxy clause [3].
>   This would be on the same footing as -only and +.

Handling arbitrary text embedded in a license expression is suddenly more 
complicated & doesn't seem terribly useful.  If I need to know who the proxy 
is, I'll need to read the license in more detail anyway.  The larger SDPX 
format can handle some of that too, once you've read the license in detail.

If you simply want to show that there *is* an identified proxy, I guess I can 
see that being useful.  Can we handle that as an exception, e.g., "GPL-3.0 WITH 
PROXY"?  I don't know if we should do that, but if we do, I think some more 
general mechanism to summarize things (like that) would be better.

--- David A. Wheeler

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

RE: minutes, summary, next steps

[Wheeler, David A]

Gary @ sourceauditor.com:
> Since "-" is an allowed character for a license ID, it would be more
> challenging to write a parser for the "-only" operator since we would have to
> determine if the "-" is part of the ID or is part of the operator.  BTW "+" 
> is not
> allowed in the license ID and "GPL-2.0 +" I believe is legal.  I have a strong
> preference for "ONLY" being the operator over "-only".

I think "ONLY" is clear, and we already have other alphabetic keywords ("AND", 
"OR", "WITH").  If you want to cuddle up an operator like "+", I suggested "!" 
earlier, which would still work.

--- David A. Wheeler

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

Two kinds of license version number ambiguity

[Wheeler, David A]

The call yesterday revealed to me that there are *two* kinds of license version 
ambiguity in SPDX license expressions.

I don't know if this is actually a problem, or if it is, that solving it is 
worth the trouble.  For many people the "second kind" is probably immaterial.  
However, I want to record the subtlety here for the record, and for discussion 
in case people think that this *is* a problem that needs solving.  I thought it 
should at least be captured somewhere, so that others can determine whether or 
not this subtlety is important.  Details below.

Thanks.

--- David A. Wheeler

=== DETAILS ===

In short, there are two different kinds of version number ambiguities in a 
license:
1. A particular version of a license is known to be acceptable, but it's 
unclear if later versions are acceptable.  This is what we've focused on.
2. A license name is referenced, but no particular version of it is identified, 
so it's unclear *which* version(s) of the license are acceptable.

I'm primarily concerned with case #1.  It's becoming quite common to copy a 
particular license (with a particular version) into a repository, and that is 
the *ONLY* information explaining what license is acceptable.  At that point, 
it's not always clear if "or later" is acceptable unless the license 
*specifically* says that later versions are automatically acceptable.  The FSF 
rep yesterday noted that people should be following license instructions on how 
to include the license, which is fair enough, but people don't always follow 
directions :-).  The current proposals (e.g., on an ONLY operator) focus on 
this issue, and I think this is the main concern today.

Case #2 is a different situation, where we have *no* idea what license version 
is being applied.  It can occur when (for example) someone says "This is 
licensed under the GPL" or "This is licensed under the CC-BY license".  SPDX's 
license expressions do not have a direct way to say "I don't know which 
version", and license identifiers are all tied to a specific version.

It's not clear that that case #2 is *really* a significant problem.  If all you 
care about is "what is acceptable", in many cases a SPDX license expression can 
capture the final result of what's acceptable, though that appears to depend on 
the text of the individual license.  In particular, all versions of the GPL 
license (so far!) say that if you don't specify a version, the recipient can 
use any version.  So you can express the rights granted by "GPL no version 
specified" as the license expression "GPL-1.0+".  However, this expression 
appears to depend on the specifics of the license, and I suspect that you 
cannot do this with all licenses.  There's also a small loss of information, as 
you can't distinguish between "This is licensed under any version of LICENSE" 
and "This is licensed under LICENSE (but I won't tell you which version)" - 
which is probably irrelevant for the GPL, but might be important for some other 
licenses.

If SDPX wanted to capture case#2, the situation where "version number 
completely unknown", one approach would be to allow license identifiers to 
*omit* the version number to mean "version number unknown".  E.g., "GPL" would 
mean "GPL, I don't know which version(s)".  However, that would create 
hardships for unversioned licenses like MIT - if there is ever an MIT license 
version 2.0, then "MIT-2.0" would suddenly render all the uses of "MIT" 
ambiguous.  I think that would be unacceptable.  In any case, it's a common 
mistake to just use "GPL" when a specific version *is* present, and we don't 
want to make it easy to make hard-to-detect mistakes.  So instead, I think 
replacing "-version" with a special marker like "-?" or "-UNKNOWN" would be the 
better approach.  You'd then capture this situation as "GPL-?" or 
"GPL-UNKNOWN".  That would expressly capture "version number uncertain". I 
think that'd be the way to go *if* this case #2 is worth capturing.

That said, it's not clear to me that this information of case#2 really needs to 
be captured.  Others may know of more critical cases, though, so I thought it'd 
be important to record this.

Thanks for reading all the way to the end...!

___
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

[Wheeler, David A]

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

RE: New License/Exception Request: EPL-2.0

[Wheeler, David A]

Regarding EPL-2.0 at ...

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. ...
> Thus I think SPDX could simply use an OR expression instead of coming up with 
> some special purpose notation. ...

I agree that the text in exhibit A, by itself, is just an "OR" if invoked.  It 
may be wordy but it looks like a simple dual license:
> This Source Code is also Distributed under one or more Secondary Licenses, as 
> those terms are defined by the Eclipse Public License, v. 2. ...

So a project that added a secondary license would just be notated as "(EPL-2.0 
OR GPL-2.0+)" under this understanding.  That sounds straightforward.  If 
that's true, then we should do that!


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

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.

If this is true, I *also* think we should avoid creating new operators.  I 
think the EPL-2.0 is better represented in SPDX as two parts:
1. The main EPL version 2.0 license, call that "EPL-2.0"
2. A constraint on secondary licenses imposed by the EPL-2.0 *when* secondary 
licenses are used; call that "EPL-SECONDARY-2.0".  Tools can be taught that 
"EPL-2.0 with GPL implies something special" if they're trying to figure it out.

Then, if you use the GPL-2.0+ secondary license with EPL-2.0, you can represent 
that as this SPDX license expression:
(EPL-2.0 OR (GPL-2.0+ AND EPL-SECONDARY-2.0))

If you're *confident* that GPL-2.0 and GPL-3.0 comply as-is, you can also write 
it as:
(EPL-2.0 OR GPL-2.0 OR GPL-3.0 OR (GPL-4.0+ AND EPL-SECONDARY-2.0))

So: If this is really just a dual-license, then let's PLEASE use simple 
expressions like "(EPL-2.0 OR GPL-2.0+)".  If it's more than that, then let's 
try to find a simple way to represent it in the existing system.

--- David A. Wheeler

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

RE: New license proposal: Verbatim

[Wheeler, David A]

J Lovejoy:
> I think this may be solving a problem we don’t have.  While you are precise
> here, I think the operative goal is to understand the license for the code...

I agree.  I think the point of SPDX is to enable people to understand the 
licenses of the software being used (or under consideration).  The "license of 
the license" is something that very few people need to worry about.  Trying to 
add this information to SPDX would, I think, distract from the main point.

--- David A. Wheeler

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

RE: GPLv2 - Github example

[Wheeler, David A]

W. Trevor King:
> >> But you can't define a LicenseRef in sitations (like npm [1]) where
> >> the only thing you can set is a license expression and you don't have
> >> access to the broader SPDX spec.
> >> [1]: https://docs.npmjs.com/files/package.json#license
> 


Gisi, Mark:
> This is not a problem with the license expression language. It is a problem
> with the SPDX identifier mechanism. LicenseRefs are SPDX's cornerstone way
> of handling the many many non-standard license notices found every day in
> source code. In the above example you don't need an "only" operator you
> need a way to include LicenseRefs when using SPDX identifiers. LicenseRefs
> are so important that they need to be addressed in the SPDX identifier
> mechanism independent of your situation.

I disagree.  LicenseRef is not a cornerstone, and for many use cases it's 
irrelevant.

Many tools and formats *only* support SPDX license expressions, so it's very 
useful to make it easy to express simple constructs like "*ONLY* version 2 of 
the GPL is acceptable".

If people think they "need" a LicenseRef, it's often one of two cases:
1. The SPDX license list has an important omission (time to report the license 
to SPDX, not to use a LicenseRef!)
2. There's a weird license in use by a third party.  As a developer or 
potential user, I'm probably going to just avoid using that software, in which 
case problem solved... I really don't need a "LicenseRef" to tell me more.  If 
not, I'm going to ask a lawyer to look at the REAL legal text, not the 
LicenseRef.  In that case, "OTHER" works just as LicenseRef to note that 
there's something different.  For people considering whether or not they should 
use some software, they just need to know if they might be in dangerous waters.

Yes, if you have a full SDPX file, more information can be useful.  But *lots* 
of people use SPDX license expressions separately.

--- David A. Wheeler

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

RE: GPLv2 - Github example

[Wheeler, David A]

Mark Gisi:
> LicenseRefs are critical for creating SPDX files.

I disagree, for at least two reasons:
1. A vast amount of software does *NOT* require weird special-case licenserefs.
2. Many people who use SPDX will never see nor use a SPDX file.  Instead, many 
people use SPDX *exclusively* for the SPDX license expression format.  I 
suspect the *majority* of SPDX users only use SPDX license expressions.

> the SPDX identifier model will need to accommodate a LicenseRef like 
> mechanism...

I'm not arguing to *remove* licenserefs, I agree they can be useful.

My point is different.  Since many users *only* use SPDX license expressions, 
it's important that SPDX license expressions have enough expressiveness (hah!) 
for common use cases WITHOUT using licencerefs.

> Case 1: Because they are writing their own code, they could stick with 
> standard licenses and avoid the rare CDDL "only" notices along with all the 
> other weird third party stuff. We don't want to encourage them to use 
> non-standard stuff anyway. Therefore there is no need to add the "only" 
> operator since the current license expression syntax is sufficient to address 
> any standard case (including GPL 2.0 only and GPL 2.0 or a later version).

Ah, I see.  I think you missed the earlier discussion, where the 
*INSUFFICIENCY* of the current license expression syntax was discussed.  I 
encourage you to go back to the archives to review the discussion about this.

Here's a quick summary: The problem is that tools often can only determine 
"there's a GPL-2.0 license here", and *NOT* whether or not "or later" applies.  
Because of scale, people *depend* on tools to provide license information.  So 
there's a mismatch between what SPDX license expressions allow you to express, 
compared to what tools can actually provide. In particular, the current license 
expression syntax is *NOT* sufficient to address the case "I saw GPL-2.0, but I 
don't know if 'or later' applies".  The license expression syntax instead 
insists that you report information that is *NOT* available.  The result is 
that in *practice* "GPL-2.0" often does *NOT* mean "exactly GPL 2.0", but "GPL 
2.0 at least and I don't know if other versions apply".  So "GPL-2.0" has one 
meaning in the spec, but two meanings in practice.  Thus, we need a way to 
express those 2 different situations, instead of being ambiguous.


> In a nutshell - The white elephant in the room is the package license.

This is not the elephant in the room.  It's the whole point of SPDX.  It's the 
primary goal.

When I look at a software package (as a user or developer) and ask, "do I want 
to use this software?", I need to know what I'm legally allowed to do.  From my 
point of view, that's the point of SPDX, specifically the SPDX license 
expression.

> An ill-defined concept that has plagued SPDX since its inception.

Again, it's not an ill-defined concept - it's the primary purpose.

> Everyone wants
> to be given a top level license designation  for every open source package
> they receive. Is it the license of the project?

Yes.  At least, that's what it is *supposed* to be.

> Is it the license in the top level license file?
> What happens if there is more than one top level license file? Is it
> the license most frequently found in the source files? Is it the AND of all 
> the
> licenses found in the package? Or is it simply someone's guesstimate?
> Different Linux distros will sometimes designate different top level licenses
> for the same package.

Which is why you need SPDX.  SPDX files allow exchange of legal analysis 
information, so information can be exchanged and analyzed.  The SPDX license 
expression that describes the entire package is the boiled-down summary of the 
analysis results, suitable for use by other tools & humans.  When you're 
downloading several thousand packages into your final system, you *need* a 
simple SPDX license expression for each package to help you comply with all the 
license requirements.

In the end, what matters as a *user* (customer) of software is, "what am I 
allowed to do?".  And that is normally at a *package* level.  It's not at the 
package level in all cases, true.  For example, I could extract an individual 
files.  But that is a rarer situation, because copying like that creates 
non-legal problems as well (e.g., I now get to "enjoy" larger maintenance 
costs).  SPDX can handle file-level as well (as you note).  Most of the time, 
though, users care about the *package* level license, which expresses "what am 
I allowed to do?"

> This is a far bigger problem than the "only" operator. In fact, it is the ill-
> conceived package license concept that is creating significant frustration and
> confusion over the GPL only issue. The problem is not at the file level. The
> license expression syntax is well suited for that. It is not well suited for 
> the
> package level. Until that is addressed we will continue to struggle.

It's not ill-conceived.  Pack

RE: GPLv2 - Github example

[Wheeler, David A]

Zavras, Alexios:
> I think I understand Mark's reservations about package-level licenses and I 
> agree with them...
> In all these cases, it seems that the “package-level license”, should simply 
> be the collection of all different licenses found in all the files of the 
> package. I think that Mark was wondering whether this is particularly useful…

It's useful, though the ability to be more precise would be nice.

A user or developer needs to know "what am I allowed to do?", in a *SIMPLE* 
way, when confronted with a package. Most software packages (however defined) 
have a relatively simple license expression that suffices to describe what 
you're allowed to do.  Historically people only used a few software packages, 
but today people routinely use much larger sets of software packages.

Clearly there are packages which have more complex licensing requirements.  In 
most cases today, all I really need is a *hint* that there's a potential issue, 
so I can focus on the packages where there MIGHT be an issue.  I suspect it'd 
be more productive to find ways to expand the license expression syntax to 
cover them, if that turns out to be important.

--- David A. Wheeler

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

RE: "unclear version" and OR-MAYBE operators (was: reminder: call Thursday)

[Wheeler, David A]

W. Trevor King:
> > ? = “unclear version” - this will be a new modifier to indicate there
> > is a lack of clarity as to the license version regarding if any
> > version, or later, or only applies, e.g., I found the text of GPLv2,
> > but I’m not sure if it’s “only “ or “or later” because there is no
> > other information.  Need further input on the exact word to use here,
> > i.e, “unclear” “maybe” “ambiguous"
> 
> The motivation for this operator seems to be a desire to say “I'm not actually
> comfortable drawing a conclusion, but here are some hints…”.

No, the issue is that there *is* some known information (e.g., GPL-2.0 at least 
is valid).
The problem is that some *other* information is *not* known (e.g., if GPL-3.0+ 
is valid for the package).


> Alexios raised the same concern in the “BSD” context [2].  I still think while
> there's not much point to concluding a licence if you're not willing to 
> actually
> make a call,

I disagree.  In many cases tools can't determine if "or later" is okay, and
99.999% of the time it doesn’t matter.  E.g., if I can't tell if it's
GPL-2.0 or GPL-2.0+, most of the time it makes no real difference.

> a good generic operator for representing this sort of thing would
> be “or maybe they meant” [3] (or some single-word form thereof).  That lets
> you represent all sorts of ambiguous declarations beyond the narrow “but
> I'm not sure which version operator they meant”.  For example, you can
> represent [4]:
> 
>   LGPL-2.0 OR-MAYBE LGPL-2.0 AND GPL-2.0 OR-MAYBE LGPL-2.0 OR GPL-2.0

That's an interesting idea. E.g., for the case previously discussed, we could 
say:

GPL-2.0 OR MAYBE GPL-2.0+

I'd be fine with a "MAYBE" operator.  That would address the primary problem I 
raised, and be even more flexible.  I don't know what others would think.

> We can provide warnings without an “unclear version” operator.  See the
> comments on metadata in [6,7].  What an “unclear version” (or “OR-MAYBE”,
> etc.) operator does is give you a way for the quasi-concluder to gripe about
> poor declarations (in a way that's obvious to human readers even without
> tooling) while still providing
> *some* information.  For example, if any possible GPL license grant is
> acceptable to you, maybe:
> 
>   GPL-2.0 unclear version
> 
> or:
> 
>   GPL-2.0 ONLY OR-MAYBE GPL-2.0+ OR-MAYBE GPL-1.0+
> 
> are acceptable to you without further digging.

I think the second version is much better.  It *looks* like a SPDX license 
expression.

--- David A. Wheeler

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

RE: only/or later and the goals of SPDX

[Wheeler, David A]

John Sullivan:
> A key part is missing in the description of the original FSF proposal here
> though -- which is deprecating the existing GPL-2.0 and similar "plain"
> identifiers for GNU licenses so that the identifiers used always indicate
> whether the version is "only" or "any later".
>
> As I understand it, people had concerns with deprecating the plain
> identifiers because of situations where they (for example) find a copy of
> GPLv2, but no clear statement about whether the program is actually
> licensed under its terms.

Not exactly.  In many cases it's clearly licensed under GPLv2.
The issue is that often we don't know if "or any later version" applies.

> To address this, we suggested still deprecating the plain identifier but
> adding an ambiguous/unclear identifier that still indicates a copy of the GPL
> was found but does not mislead observers into thinking that there are
> sufficiently clear licensing statements along with it.

The proposal, as I understand it, is these license expressions have the 
following meanings:
1. GPL-2.0 ONLY : GPL version 2.0 only.
2. GPL-2.0+ : GPL version 2 or any later version
3. GPL-2.0 : At least GPL version 2.0 applies. It may or may not be "or any 
later version".  In practice, this is all most tools can report, because all 
they can report is the presence of this license file (there may not *be* any 
other information).

It'd be possible to report case #3 in other ways, e.g.:
* GPL-2.0 OR MAYBE GPL-2.0+
* GPL-2.0?
* GPL-2.0 AT LEAST
I *do* think it would be very odd to deprecate the license identifier 
"GPL-2.0", especially since this license is in such active use AND is a basis 
for many license expressions.  The proposal has the advantage that it 
acknowledges reality - when people or tools report "GPL-2.0", in practice we 
don't really know if "or later" applies (the SPDX spec, versus practice, 
sometimes diverge on this point).

> I understand SPDX doesn't want to make legal judgments. Which is why it
> should indicate when there is uncertainty.

I agree that SPDX should *not* require people and tools to make *false* claims. 
 So we need a way to not *force* people to make claims they don't believe.  
Interpreting "GPL-2.0" as "GPL version 2 at least, not sure if it 'or later' 
applies" seems like it gets there for the case under discussion.  I'd be happy 
with other solutions too.

...
> We haven't changed our mind about what we do and don't support here;
> and I think we'd be open to other ways to indicate ambiguity/uncertainty,
> including possibly using NOASSERTION.

I disagree with using NOASSERTION in this case; that loses important 
information.  99% of the time, knowing that it's licensed under the GPL version 
2 at least is *more* than good enough.  There are cases where I care, of course 
(e.g., if I'm linking it with Apache 2.0 licensed software).  But every legal 
analysis costs time & money; people only want to invest where they *must* do 
so.  If tools can report "I know GPL-2.0 at least is okay, and later versions 
might be okay", that'd be best.

I do agree that it'd be great if projects would provide better licensing 
information.  But I'm currently trying to convince people to add licensing 
statements at *all*, due in part to complete obliviousness.  Adding license 
files of *any* kind is a win right now.  Given that starting point, we should 
not expect perfect licenses any time soon :-).

Thanks for your time!

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

RE: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

[Wheeler, David A]

Bradley M. Kuhn:
> Could you explain a bit further why the extra parenthesis grouping is
> needed when only ORs are involved?

As you guessed, the parentheses are not *needed*.  The SPDX spec says that 
parentheses SHOULD be used when there are multiple license identifiers or 
license refs, but this is a SHOULD not a MUST.

The section you want to consult is SPDX specification version 2.1, Appendix IV 
("SPDX License Expressions"):
https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60

Subsection "Composite License Expressions" says:
"More expressive composite license expressions can be constructed using "OR", 
"AND", and "WITH" operators similar to constructing mathematical expressions 
using arithmetic operators. For the Tag:value format, any license expression 
that consists of more than one license identifier and/or LicenseRef, should be 
encapsulated by parentheses: "( )". This has been specified to facilitate 
expression parsing. Nested parentheses can also be used to specify an order of 
precedence which is discussed in more detail in subsection (4)."

So the spec recommends using parentheses when there are multiple license 
identifiers.  Again, this is only a SHOULD, not a MUST.  I view this as a 
stylistic recommendation.

--- David A. Wheeler

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

RE: signifigance of nested parenthesis with only ORs? (was: OpenJ9 license)

[Wheeler, David A]

Bradley M. Kuhn:
> So you can confirm there is *absolutely* no semantic licensing difference
> between a series of OR expressions with or without parenthetical
> groupings?

I don't speak for SPDX :-).  But I can read, and hopefully that's something :-).
I don't see anything in the SPDX specification that suggests a difference in 
the cases being discussed.

I consulted the Book of Armaments, I mean,
SPDX specification version 2.1, Appendix IV ("SPDX License Expressions"):
https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
which says:
simple-expression = license-id / license-id"+" / license-ref
compound-expression =  1*1(simple-expression /
 simple-expression "WITH" license-exception-id /
 compound-expression "AND" compound-expression /
 compound-expression "OR" compound-expression ) /
 "(" compound-expression ")" )

The last part says that you can always take a compound-expression, and surround 
it with parentheses.  There's no indication that this would *mean* anything 
different.

So the following are all syntactically legal, and there's no indication that 
they mean anything different:
1. MIT OR GPL-2.0
2. (MIT OR GPL-2.0)
3. ((MIT) OR (GPL-2.0))
4. (MIT))) OR (GPL-2.0)))

Of course, not all syntactically legal expressions are examples of good taste 
:-).  The style recommendation from the spec is to use parentheses to surround 
expressions with multiple license identifiers and license refs (example #2).  
Many people use #1, because it's shorter.  Examples #3 and #4 are clearly bad 
style, but they're unambiguous so there's no strong reason to forbid them.

Also, clearly "((X OR Y) AND Z)" is very different from "(X OR (Y AND Z))".  
There, the location of parentheses is *vital*.  But I think everyone already 
understands that.

--- David A. Wheeler

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

RE: Spec recommendation for paren encapsulation? (was: signifigance of nested parenthesis with only ORs?)

[Wheeler, David A]

W. Trevor King [mailto:wk...@tremily.us]:
> The Appendix V wording for that is:
> 
>   Representing Multiple Licenses
> 
>   Multiple licenses can be represented using a SPDX license expression
>   as defined in Appendix IV.  A set of licenses must be enclosed in
>   parentheses (this is a convention for SPDX expressions).
> 
> which is a strange combination of “must” and “convention”.  But it sounded
> to me like a requirement for parens around the whole license expression,
> and not a suggestion for additional parens within the license expression.  In
> [2], I tried to express that with the ‘enclosed-license-expression’ rule [3]
> and its explanatory paragraph [4].

Appendix V only applies to license expressions within files, not license 
expressions generally.
If we interpret "must" as a real requirement, then within files you must use 
(...) in these cases.
In contrast, Appendix IV applies in all cases.

I think the Appendix V additional requirement should be dropped, frankly.
That is, I think we should remove the statement, "A set of licenses must be 
enclosed in
parentheses (this is a convention for SPDX expressions)."
I'm fine with a style recommendation as a "should" in appendix IV, which is 
already there.  But if someone forgets the parentheses, the license expression 
should still be accepted because it's unambiguous and has been historically 
allowed by the specification.

--- David A. Wheeler

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

RE: Spec recommendation for paren encapsulation? (was: signifigance of nested parenthesis with only ORs?)

[Wheeler, David A]

Gary O'Neall [mailto:g...@sourceauditor.com]:
> If we have more than one line for a compound set of licenses, it would be
> ambiguous if the text following the first line of a compound license is part
> of the license expression or just some other text.  To solve this ambiguity,
> we introduced the parenthesis requirement for compound licenses only.
> When this was discussed, we also considered requiring compound licenses
> to be restricted to a single line, but we decided that would be too limiting.

Good to know!  But you still don't need parentheses when the entire expression 
fits on a line (e.g., "MIT OR BSD-3-Clause"), and such expressions are used in 
the wild anyway, so tools should correctly interpret data in this form.  In 
addition, if the purpose is to unambiguously find the end, you only need 
parentheses at the outermost layer.  That is, "(A OR B OR C)" is more than 
enough for this case; you don't need "(A OR (B OR C))".

I think the spec already says that "(A OR B OR C)" is the recommended form, not 
"(A OR (B OR C))", because the spec only says you should encapsulate *license 
expressions*.  The spec *never* says you should parenthesize *compound 
expressions*.  The spec *permits* this, but it *never* says you should do it.

For clarity, I think that the spec should be tweaked to make this a little more 
obvious.  Basically, "license expression" should be changed to 
"license-expression" (note the additional hyphen) in this sentence:
> For the Tag:value format, any license expression that consists of more than 
> one license identifier and/or LicenseRef, should be encapsulated by 
> parentheses: "( )".
I don't think this is a change in meaning, since it's clear that a "license 
expression" is a "license-expression", but it might help the reader go back and 
look at the actual syntax rules.

Tools still need to be *able* to parse SDPX license expressions that aren't 
completely surrounded by parentheses.  People are likely to provide data 
without parentheses, and tools need to be able to correctly parse those cases.  
Many SPDX license expressions occur outside SPDX files (e.g., in package 
manager data), and in some of those formats it's not possible to have 
multi-line data anyway.  Even if they do, we're often handling data provided by 
humans, and those darn humans don't always surround compound expressions with 
parens.

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

Jilayne Lovejoy :
> Do NOT add a identifier or operator, etc. for the found-license-text-only 
> scenario where you don’t know if the intent of the copyright holder was “only 
> or “or later” and are thus left to interpret clause 9 

This "resolution" doesn't solve the problem.

Since tools are not yet sentient, tools often *cannot* determine if "or later" 
was intended.  Yet "don't know" makes a tool useless, and it *did* see a copy 
of a license, so the tool *will* report something.  Tools will probably report 
"GPL-2.0-only" when they only see the GPL-2.0.  As a result, soon 
"GPL-2.0-only" will not IN PRACTICE mean "only GPL-2.0".

I'm fine with "GPL-2.0-only" and special-casing "GPL-2.0+", but we *STILL* need 
a way to indicate "GPL-2.0 at least and I don't know if later versions are 
okay".

People depend on automated tools, and automated tools often CAN'T figure out 
the "or later" question.  There are a million ways to indicate "I don't know if 
a later version is okay", e.g., "AT LEAST" or "?" suffix, MAYBE operation, etc. 
 But if SPDX can't represent this common case, then people will overload 
*other* expressions with this alternative meaning, meaning that the "only" soon 
won't have that meaning.

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

J Lovejoy:

> Do NOT add a identifier or operator, etc. for the found-license-text-only 
> scenario where you don’t know if the intent of the copyright holder was “only 
> or “or later” and are thus left to interpret clause

I disagree, sorry.

> - we don’t need to solve this right now and we can always add this option 
> later
> - without adding a third option, we are in the same position we have been in 
> since the birth of the SPDX License List. incremental changes have always 
> been our go-to strategy; let’s take a first step to clarify the current 
> identifiers in a way that the FSF can get behind. If, for a later release, we 
> think we need this third option, then we can discuss that further once we 
> have some time under our belts with this change. 

No, this is the *reason* that there's a problem.  The *reason* that "GPL-2.0" 
isn't working is, in part, because it overloads two notions.  "GPL-2.0" is 
supposed to mean "Only 2.0" (per the spec) .  But tools only know "I saw a 
GPL-2.0 license", so how can they represent that information?  The obvious way 
is "GPL-2.0", so that same identifier can mean "2.0 at least, and I don't know 
if there are other versions allowed".  That's not good.

If we wait to "add this option later", "GPL-2.0-only" will probably have 
morphed in *practice* into "GPL-2.0 at least, and I don't know if it's the only 
version".  So while everyone can congratulate themselves about the clarity of 
the spec, very soon it will predictably be *unclear* in practice.  If we want 
to be able to express "exactly this version", we also need to be able to 
represent "at least this version".

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

Brad Edmondson [mailto:brad.edmond...@gmail.com] 
> I think your points are good ones, but it seems to me they go to the separate 
> issues of "file:detected license" and "package:concluded license." 
> The clarity of the spec argument is aimed at making the "file:detected 
> license" case more explicit, and if it leaves tools with NOASSERTION for 
> "package:concluded license," then I think that's OK, no?

No, it fails to work for multiple reasons:
1. "NOASSERTION" is basically useless, because it provides no information.  In 
many cases, all I need to know is "there's a version of the GPL here", and I 
can make a decision.  Being able to provide *some* information is often all 
that's needed , while providing *no* information creates a lot of unnecessary 
work for tool users.
2. Tools, lacking sentience, often cannot determine whether or not "or later 
versions" applies.  So they're unable to be "more explicit" in 
package:concluded.  The current structure requires that conclude either "only 
2.0" or "2.0 or later"... even though tools typically CANNOT make that 
determination.  SPDX should make it possible report the information *actually* 
available.
3. The majority of SPDX users do not use SPDX files.  Instead, they *only* use 
SPDX license expressions (as available in package managers, file content 
declarations, etc.).  So there's no "file:detected" vs. "package:concluded" 
entries to compare anyway.

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

J Lovejoy [mailto:opensou...@jilayne.com]:
> If this is a potential problem once GPL-2.0 is changed to GPL-2.0-only, then 
> it is currently a problem.

Yes indeed, that's my point :-).

> And perhaps by altering the current identifier (GPL-2.0) to be more explicit 
> (GPL-2.0-only) we will expose just how often GPL-2.0 has been used 
> incorrectly.

The tools are currently *required* to be incorrect, because they cannot report 
the information they have ("I have GPL-2.0, and I don't know if 'or later' 
applies").  Neither the proposed "GPL-2.0-only" nor "GPL-2.0+" correctly 
represents the information they have.  Tools will have to output *something*, 
and whatever they produce will dilute in *practice* the strict meanings of 
those license identifiers.

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

Philippe Ombredanne:
> I think there is no contention there at all.

Respectfully: There *IS* contention.  I'm contending.

> A summary (e.g. a license expression) cannot ever capture all the nuances
> of the details This is a lossy "compression" by construction...

Sure, but all summaries, and all models, omit something.  Indeed,
a SPDX license file *also* cannot capture all the nuances.

The correct question is, "is this model adequate for its uses?"
In most cases people want to know, "is this package legal to use?".
To answer that question, "it's at least GPL-2.0, and might be more"
s important information, and I think it's information that the SPDX
license expression should include.

> Speaking as the author of a fine license detection engine, I think this is a
> red herring.
> A license detection result can be: "I am 95% sure this is GPL-2.0-only but it
> could be GPL-2.0+: please review me to fill in your conclusion."

This inability to indicate the "in-between" state within a license expression
greatly increases the number of cases where an unnecessary review must occur.
Every unnecessary review is a significant increase in time and money.
In many cases, it's *NOT* necessary to make a decision, but in some cases it is.
If organizations can do the analysis *ONLY* when they need to,
they'd save a lot of time and money... and that is greatly aided by
having SPDX license expressions able to indicate this information.

> So detection does not have to be binary as in either 100% right or 100%
> wrong. If a tool can only report red or blue binary results, that's a possibly
> fine but weak tool.

But that's what I'm saying.  Most tools CAN provide more than 2 answers.
The problem is that the SPDX license expressions don't allow tools to report
more than the 2 answers within a license expression.  So the tool doesn't have
to give a binary answer, but SPDX forces the tools to do so when they output
SDPX license expressions.

> For instance scancode-toolkit can cope with ambiguity alright and surface
> this for review when it cannot come with a definitive detection answer.

But it CANNOT surface this information via SPDX license expressions.
For most people, that's the ONLY thing that matters.  I suspect at most 0.1% of
SPDX users use SPDX files, everyone else ONLY uses SDPX license expressions.
The percentage of SPDX users who use SPDX files may not be that high :-).

> Therefore I have no issue whatsoever to implement Jilyane's comprehensive
> proposal and I can always output something on my side.

You can always output something nonstandard that cannot be shared, sure,
and for many detailed analyses that's a good thing.
But that's less helpful for sharing compared to a standard format.

> So since this can be done by one tool alright this is NOT an issue for the
> SPDX spec to worry about and tools should adjust: that's for tools
> implementors to cope with ambiguity, not something to specify here.
> 
> Please let's keep this spec simple!

Well, empty specs are the simplest possible :-).
Specs need to be as simple as possible... but no simpler.

There's also the long-term damage this decision will cause.
In practice, I expect failing to add this capability is going to make
"GPL-2.0-only" mean the same thing as "I saw a GPL-2.0 and I don't
know if 'other later' applies" - and as a result "GPL-2.0-only" will
NOT mean "GPL-2.0-only" as intended.  The case of "I see a license
and no other information" is relatively common, and is *important*
for determining what is legal to do.

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

David A. Wheeler:
> > To answer that question, "it's at least GPL-2.0, and might be more"
> > s important information, and I think it's information that the SPDX
> > license expression should include.

Philippe Ombredanne [mailto:pombreda...@nexb.com]
> Is this really important to know this fact in the general case?

Yes, there are a number of cases where it's important.
The usual reason is because I'm trying to link Apache-2.0 licensed code with
other code, a non-problem for GPL-2.0+ but widely considered a problem for
GPL-2.0 only.  The Apache-2.0 license is extremely common.

On the other hand, there are many other cases where it's not important.

Which is why it's important to know in cases, and important to *not* track it
down when it's unimportant.

> Making this careful decision solely on the few characters of a license
> expression would be insanely foolish IMHO.

Not at all.  What matters in many circumstances is just being able to show
some sort of due diligence.

In many cases, the "usual" situation is to copy & paste code, regardless of 
license or legality.
Any improvement over *that* is a big win.

> Now, I could not agree more with you: inaccurate and clear licensing
> information means that a user will need to review this to ensure this is
> clear
> This is something that needs to fixed by working with every project author...
> [e.g.]... tickets I routinely file with projects that lack a clear license.

I *heartily* endorse that work, thank you!  But for every license you add,
someone creates another project with unclear licensing.

The *real* root causes are going to be difficult to fix:
* A large proportion of software developers are self-taught (& so don't know 
about
  the laws), and of the rest,  schools typically fail to teach CS students 
about software-related laws.
  You can teach one, but the next developer will do the same thing.
* We have a VC/business culture that often values speed of development over 
legality.
* Many software developers are young & only know other young developers,
  so they don't have anyone more experienced to learn from (or discount
  the knowledge of those who *have* suffered the problems before).
* Many software developers, especially young/inexperienced developers,
  incorrectly think that laws don't apply to software; I blame in part
  the RIAA, who have successfully convinced the latest software developers
  that copyright is not a real law.
* Copyright law as-written is very complex, and
  is so obviously bought off by special interests, that it's difficult to 
defend,
  and that makes it difficult to get many developers to take it seriously.

You can fix a few egregious cases with tickets, and please do.
But you're *not* to fix these root causes with a few tickets.

Education is *great*, but for the foreseeable future we're going to continue to 
have problems.


> It surely could (NB: it does not yet). that's a minor change.
> e.g. something like a list of license expressions with a confidence:
> 
> - confidence: 100% , expression: GPL-2.0-only
> - confidence: 60% , expression: ((GPL-2.0-only or GPL-2.0+) and MIT)

That's not a standard SPDX license expression.

SPDX license expression syntax could add a "confidence" value - but that's
more complex, and I don't think you're seriously proposing it.
Why not just a simple expression that indicates uncertainty of new versions?


> 
> Each expression is valid, right?
> 
> > I suspect at most 0.1% of
> > SPDX users use SPDX files, everyone else ONLY uses SDPX license
> expressions.
> > The percentage of SPDX users who use SPDX files may not be that high :-).
> 
> Would you have data or pointers to support these assertions about SPDX
> usage? That would be mighty useful!

I agree that'd be useful - I don't have anything great.
Here's one try.

A Google search of "filetype:spdx" returns 164 results.
Clearly ".spdx" files are not lighting the world on file.

Contrasting this to SPDX license expressions, we have to look at their
uses, which include package managers, in-file statements, and simple
tools that just report SDPX license expressions (e.g., Ruby's LicenseFinder).

Many package managers use SPDX license expressions
to indicate the package license.  E.g., NPM does:
  https://docs.npmjs.com/files/package.json
by using the "license:" field - which is *NOT* a SPDX license file.
According to , *just* the NPM ecosystem
has 550,951 modules as of Nov 24, with 535 new packages a day on average.
I don't know what percentage of modules have a "license:" entry
(is someone willing to find out?) - but for discussion, I'll guess it's at 
*least* 10%..
That would mean that there are 55,095 NPM packages that use
SDPX license expressions.

This is a quick try, it'd be possible to get a more accurate estimate. But if 
you
add all the other package managers where
SPDX license expressions get used, and the per-file entries, and I think
It's clearly that SPDX use is *primarily* the use of SP

RE: Keep partial conclusions out of license expressions (was: update on only/or later etc.)

[Wheeler, David A]

g...@sourceauditor.com [mailto:g...@sourceauditor.com]
> David - I'm curious if the "OR-MAYBE" proposal solves the issue you are
> raising as well.

Yes, it does.

--- David A. Wheeler

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

RE: update on only/or later etc.

[Wheeler, David A]

Sorry for the long email, but I was asked for evidence... so I went and got 
some.

David A. Wheeler:
> > The usual reason is because I'm trying to link Apache-2.0 licensed
> > code with other code, a non-problem for GPL-2.0+ but widely considered
> > a problem for
> > GPL-2.0 only.  The Apache-2.0 license is extremely common.

Philippe Ombredanne [mailto:pombreda...@nexb.com]
> I understand your point, but __how many times__ did you ever encounter
> this case in the real world? ...
> An issue of Apache-2.0 compatibility with the GPL-2.0 has never showed
> up: zero cases, not one single time.

The issue of having to *check* for Apache-2.0 & GPL-2.0 ONLY problems
has happened a number of times in just the BadgeApp project that I lead,
and I don't think that's unusual.  In just that small project I think I've had 
to check ~10 times.
An actual *problem* is less common, because it's often the case that the
GPL code is really "GPL-2.0+" or that the GPL-2.0 ONLY code is not linked with 
Apache code.
I've seen both situations in the BadgeApp.  (My biggest concern was with a 
GPL-2.0 ONLY
library that was a deep transitive dependency that provided text coloring of 
test results,
but it turned out to be linked into a *different* executable from my Apache-2.0 
libraries,
so there was no legal problem.)
However, one of the reasons I use SPDX is *specifically* to make sure that 
there's no problem.

In some cases, the GPL'ed code is in a separate executable, so I don't need to
examine "is 'or later' true?".  If they *are* linked together, then I need to 
investigate.

> > Not at all.  What matters in many circumstances is just being able to
> > show some sort of due diligence.
> 
> Are you serious there? Where in the actual real world anyone is looking
> after  "being able to show some sort of due diligence" and consider this
> enough? That does not sound reasonable. Who does this? I would have a
> field day looking as such a codebase.

Yes, I'm very serious.  Enjoy your field day :-).  Warning: it gets less fun 
over time :-(.

The people here on SPDX-legal generally try to
meet legal requirements seriously, and are often involved in corporate efforts
to ensure that the entire organization complies with various legal requirements.

I'm grateful to all of you; you're the good guys.  Wear that white hat proudly.

But not all organizations are this way.  In particular, small organizations 
often can't
afford in-house lawyers and often don’t understand the law very well anyway.
"Doing your best" (as they perceive it) without expertise is very common in 
*practice* -
though perhaps since they're smaller organizations you don't see them.
Small organizations make a lot of software.

Magma claims that   
"75% of Mergers and Acquisitions Fail Due to Unsuccessful Software System 
Integration"
http://www.magmadigital.co.uk/2016/failed-mergers-and-acquisitions-software/
- that isn't just licensing, but licensing is one of the factors.

Maya Rotenberg (WhiteSource) says that
"On the Verge of an M&A? Don’t Ignore Open Source Due Diligence" (11 August 
2015)
https://www.whitesourcesoftware.com/whitesource-blog/verge-ma-dont-ignore-open-source-due-diligence/
says "only 27% of companies have a formal open source policy
to approve new components that are added to their software." and that
20% of M&As fail (though it's not clear how often licensing specifically is the 
problem).

I believe WhiteSource & Magma have economic reasons to emphasize the problem.
Even so, I think that's enough evidence to suggest that there is a real problem.

> > In many cases, the "usual" situation is to copy & paste code, regardless of
> license or legality.
> Where do you get that the "usual" situation is to copy & paste code?
> Based on my long experience, copy/paste of snippets is a rare event and
> usually account for only a handful of items even in very large product
> codebases.

My own observation, and those of others, is that copy/paste from others' work 
happens often.
It is often not obvious, because it's hard to detect unless you use a tool 
specifically
to detect it.  Many organizations do not use such tools, so it's unsurprising
that many organizations are unaware of it.

First, a personal experience.
I talked with a NASA contractor years ago, who asserted that he just
copied code from the Internet, wherever it was useful, and pasted it in.  He 
indicated
that this was common at his company.  His rationale:
"if it's on the Internet anyone can use it" (!).  This was at a conference 
where the
NASA lawyers & NASA software developers were trying to understand each other!
The NASA lawyers, of course, knew this was not okay & did everything they could 
to educate
developers to prevent *exactly* this sort of thing.  I also tried to explain to 
this person that
doing so was *not* acceptable.  But when people are told to *NOT* do something,
they do not always comply, especially since copying & pasting means they can go 
home
and spend more time w

RE: Some problems discovered with CC BY-SA license identifiers

[Wheeler, David A]

Bradley M. Kuhn:
> I therefore suggest two changes to the SPDX License List:
> 
>  * Change existing Full Names to:
>   "Creative Commons Attribution Share Alike 4.0 International"
>   for the 4.0 version and,
>   "Creative Commons Attribution Share Alike  Unported"
>   for the older ones.
> 
>It seems that would be an uncontroversial change -- it just involves
>adding "International" and "Unported" into the Full Name field.  Does
>anyone have an argument why that *shouldn't* be done?

I agree.

>  * It *would* surely be controversial to add *every* version of *every*
> jurisdiction-specific CC license in the SPDX license list.  Instead of
> suggesting that, for the moment I suggest that "-Unported" should be
> added to identifier for the pre-4.0 ones (i.e., "CC-BY-SA-3.0" becomes
> "CC-BY-SA-3.0-Unported") so that no is confused by this situation.

I disagree, for several reasons.
* Version numbers are normally at the end.
* In practice, I think in almost all cases what is intended is the 
*unported*/*international* version, since these materials normally go out 
around the world.  SPDX license names are long enough; the "short" version 
should be the "normal" version.
* This creates yet-another transition problem, and in this case I think an 
unnecessary one.  Many people already use CC-BY-SA-3.0 to mean the unported 
one, so let's just clarify that.

I actually do *NOT* think it'd be very controversial to add all the 
jurisdiction-specific CC licenses that are actually used:
* There's an easy stopping requirement: You have to show that something was 
actually *distributed* under that license.  Almost all of the possible license 
+ countries combinations have never been used.
* There are SPDX license identifiers for licenses used by relatively few 
programs.
* You could create a convention, e.g., -PORTED-< ISO 3166-1 alpha-2 
country code>-.  The SPDX license identifier list could even 
standardize that as a convention, instead of listing them all out.  A few lines 
of text... and you're done.  E.g., the US ported version would be 
"CC-BY-SA-PORTED-US-3.0".  I add the "-PORTED-" because "SA" means "Saudi 
Arabia"; without some special keyword it wouldn't be obvious what "CC-BY-SA" 
meant.  I suggest the 2-character code, that's what most people use.  We could 
use the "2-character codes as assigned by the Internet Assigned Numbers 
Authority".  The alpha-2 code for the UK is "GB", but "UK" is used in domain 
names & it might be clearer to use that.

--- David A. Wheeler

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

RE: The unlicense

[Wheeler, David A]

Philip Odence:

> The name is unfortunate. The world will have to deal with the distinction 
> between Unlicensed software and and unlicensed software.



Just wait until you process the "Do What The F* You Want To Public License" 
(http://www.wtfpl.net/); http://www.wtfpl.net/showcase/ lists some software 
released under it :-).



--- David A. Wheeler





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

RE: GNU [?] Affero General Public License v1.0

[Wheeler, David A]

The confusion may be that for at least version 3.0, it *is* the "GNU AFFERO 
GENERAL PUBLIC LICENSE" as documented here: 
http://www.gnu.org/licenses/agpl-3.0.html

I believe you mean that version 1.0 doesn't begin with "GNU".  That sounds 
correct; I believe Affero had an idea, drafted it (with some help from GNU), 
and then put it out... but as their own license.  Later it got folded in as a 
GNU license.  Anyway, that's the history as I (poorly?) remember it.

The text of of the GNU Affero General Public License seems to be consistent 
with my recollections:
"An older license, called the Affero General Public License and published by 
Affero, was designed to accomplish similar goals. This is a different license, 
not a version of the Affero GPL, but Affero has released a new version of the 
Affero GPL which permits relicensing under this license."

--- David A. Wheeler


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Camille Moulin
Sent: Monday, September 30, 2013 11:31 AM
To: SPDX-legal
Subject: GNU [?] Affero General Public License v1.0

Hi all,

The spdx license list in its latest version (1.19) mentions the "GNU Affero 
General Public License v1.0", but AFAIKT it's not a GNU license and the full 
name should just be "Affero General Public License v1.0".

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

RE: License: spdx-license=IDENTIFIER

[Wheeler, David A]

Jilayne Lovejoy:
>yes, I actually agree.  I have long thought that the short identifiers would 
>be better served as:
>GPL-2.0+
>and
>GPL-2.0-only

>And logged this as something to bring up, but we have been busy with trying to 
>finish other tasks and it hasn't risen to the surface.  Of course, the worry 
>is that changing the short identifiers will screw up people who are already 
>using the SPDX License List (we endeavored to try to never change them...) 
>There is a good number of companies already using it and probably more than we 
>even know of. In any case, if it is going to help reduce confusion or 
>ambiguity and we can figure out a way to make sure this change is well 
>documented, then we need to consider making the change.  I will be sure to 
>bring this up at the General Meeting tomorrow and on the next legal call (next 
>Thursday) 

I agree that once an identifier is given a specific meaning, that meaning MUST 
not change.  But I don't see a big harm in creating a new, clearer SPDX 
identifier for a given license.

There should be only one "recommended" identifier for a given license, but you 
could record older identifiers marking what license they refer to, noting that 
it's a deprecated identifier and listing the "better" ones instead.

The GPL and LGPL are the most widely used OSS licenses, by most measures, and 
its version distinctions really matter for many people.  Having good, clear 
identifiers for this especially common use case seems like a reasonable thing 
to do.

--- David A. Wheeler


Cheers,


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.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

RE: meta-tag page

[Wheeler, David A]

I really like this idea of one special line I can quickly search for.  It makes 
the SPDX list a lot easier to use.

I have a comment on the justification: "The license list for SPDX is immutable 
and will never change."
Well, that's not true, hopefully it'll keep getting larger.  How about:
"The meaning of a given SPDX license identifier is immutable and will never 
change".

--- David A. Wheeler


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Jilayne Lovejoy
Sent: Thursday, October 03, 2013 1:09 PM
To: SPDX-legal; SPDX-biz; spdx-t...@lists.spdx.org
Subject: meta-tag page

I just updated the meta-tag proposal page on the Wiki in the introduction 
section.  We had discussed on the general meeting this morning, that this was 
needed.  Have a look and see what you think.

http://wiki.spdx.org/view/Technical_Team/SPDX_Meta_Tags


Jilayne Lovejoy
SPDX Legal Team lead
lovejoyl...@gmail.com



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

RE: meta-tag page

[Wheeler, David A]

Dmg:
> Following this rational, would it be possible to recommend something in the 
> line of:
> BEGIN_LICENSE
> This file is licensed under the 
> For more information see URL-TO-SPDX-WEB-SITE-WITH-iNFO
> END_LICENSE
> that makes three things explicit:
>
> * It says where the license info in -file is (BEGIN, END_LICENSE)
> * It explicitly states the file is licensed under the given licence
> * It says where to get more information to understand what it means.

> Jack's way of doing it, by just naming the license feels too cryptic to me if 
> I am reading the header, and does not explicitly state it is the license 
> under which the file is made available to others

>From a programmer's perspective I think the "cryptic" approach is FAR 
>superior.  There are lots of tools that can quickly examine files and return 
>text with the pattern "SPDX-License-Identifier:  ", and other tools that can 
>trivially process the stuff after it.  The above alternative is more work to 
>process, and humans don't like unnecessary work :-).

If you want more boilerplate with the goal of enforceability, you might try a 
format that's trivial to process, e.g.:

SPDX-License-Notice:  This file is licensed under the following license(s):
SPDX-License-Identifier:  MIT
SPDX-License-More-Information:  http://wiki.spdx.org/

--- David A. Wheeler


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

RE: meta-tag page

[Wheeler, David A]

If there can be agreement on a very short license "meta-tag" - and I have a 
strong preference for a version that lets me do it in 1-line- then I'll start 
using it.  I suspect others would do so too.  After all, it's easy to add this 
kind of line to a source code file:
  SPDX-License-Identifier: MIT

--- David A. Wheeler

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

RE: meta-tag page - part II

[Wheeler, David A]

Gisi, Mark [mailto:mark.g...@windriver.com]:
> My main concern is: if we don't choose a sufficiently expressive syntax, and 
> end up losing information, then we will have done more damage to SPDX than 
> good. It needs to represent NOTICES and not just a single license.

Fair enough.

I very much like the idea of permitting a license *expression*, instead of one 
license.  Fedora and Debian already do this, so this is a well-understood area. 
 But that's not too difficult, just permit expressions with parentheses, "AND", 
and "OR".  In many cases this would still be simple; here's an example of what 
I have in mind:

SPDX-License-Notice:  This file is licensed under the following terms:
SPDX-License-Identifier:  LGPL-2.1 OR MPL-1.1
SPDX-License-More-Information:  http://wiki.spdx.org/licenselist/spdx-1.1

In general, we all want both simplicity (so people will USE it) and 
expressiveness (so it can be USEFUL).  The trick is getting there...


--- David A. Wheeler

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

RE: meta-tag page

[Wheeler, David A]

I said:
David> From a programmer's perspective I think the "cryptic" approach is FAR 
superior.  There are lots of tools that can quickly examine files and return 
text with the pattern "SPDX-License-Identifier: ", and other tools that can 
trivially process the stuff after it.  The above  alternative is more work to 
process, and humans don't like unnecessary work :-).

D M German:
>When you say "programmer" who do you mean? The author of the software, the one 
>who is thinking about using the file, or a large organization who wants to 
>scan massive amounts of code?

I was focusing on the first two, and I agree with Wolfgang Denk:
"For a software developer, there is no sharp line here.  While creating new 
software, we frequently borrow from existing code, so we are creators and 
consumers at the same time.

However, the "large organization" case is also plausible.  Large organizations 
in practice will depend on technical people to get the information; it helps to 
make a common task easy for the technical people.

--- David A. Wheeler


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

RE: meta-tag page - part II

[Wheeler, David A]

Wolfgang Denk [mailto:w...@denx.de]:
> But this example doesn't work either.  If you mix a license that allows 
> "modify and keep the modified code closed" with GPL, the only legally 
> possible result is GPLed code.
> I see little value in constructing such more or less artificial examples.

This is not artificial.  Here's code that I wrote:
http://sourceforge.net/p/readable/code/ci/master/tree/src/sweet-clisp

Note this comment:
# Except as otherwise marked, this code is licensed under the "MIT license".
# However, the "override" code that patches clisp is derived
# from clisp, which is GPLv2.
# Thus consider the work as a whole as "MIT and GPLv2".

I agree with you that, from a *legal* standpoint, if you accept the WHOLE file 
you end up with just the GPLv2 requirements.  But knowing that there's a 
variance matters; it's quite possible to extract a part and end up with just 
the MIT portions.

This one file is part of a larger system that is mostly MIT, but has this one 
GPLv2 file.  Claiming it's just "GPLv2" would be very misleading.  Being able 
to report the options, collected with AND and OR, is very helpful.

--- David A. Wheeler

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

RE: meta-tag page - part II

[Wheeler, David A]

Wolfgang Denk [mailto:w...@denx.de] 
> But there there is no actual choice.  Yes, you take the parts of the project 
> that do not include the GPL code - and you can use this code under the MIT 
> license for other purposes.  But as soon as we talk about the thing as a 
> whole (say, the linked binary), then you do not have any choice, then it's 
> GPL.  GPL without any ORs or ANDs.

Ah, but these are not linked binaries.  These are scripts, and it's trivial to 
remove one of the scripts & the rest of the software is straight-up MIT.  Even 
for the MIT+GPLv2 script, it's trivial to remove a certain set of lines to make 
it MIT-only.

Also: We agree that the effect of "MIT AND GPLv2", legally, is just "GPLv2"... 
but some other license combinations do not simplify so easily.

Anyway, I think it's important to be able to express more complex situations 
than "this file has license X".  In many cases, a file has multiple licenses, 
not one license; being able to express that situation is very helpful.

-- David A. Wheeler

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

RE: SPDX meta-tag for implicit license terms

[Wheeler, David A]

Gisi, Mark:
> All in all, from a compliance perspective - THERE IS NO BETTER PRACTICE THEN 
> INCLUDING A CLEAR LICENSE NOTICE IN EVERY FILE.

Sure.  However, in a world where a LARGE number of people intentionally include 
NO LICENSE and wrongly assert that "no license"=="I can do anything I want", 
I'm delighted to have *one* well-understood license with the software package.  
Github has since made major improvements, but this is still useful for context: 
http://www.infoworld.com/d/open-source-software/github-needs-take-open-source-seriously-208046.
  My "thanks" to the people at RIAA et al who have successfully convinced many 
in a generation that copyright is a no-longer-relevant or evil law and that 
"all the cool kids" ignore it :-(.

At this point I'm trying to get people to include a well-understood 
lawyer-and-OSI-approved OSS license SOMEWHERE in their project if they intend 
to release software as OSS.  Getting license text into every file is lower in 
my priority list.  It's hard to water the plants when the building is on fire.

But I agree that per-file is best.  If you want a clear license notice in every 
file, it needs to be REALLY EASY to add. Adding a lot of text in a large number 
of files is less likely to happen.

--- David A. Wheeler


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

RE: SPDX ID for GPL-2.0+ with addendum ?

[Wheeler, David A]

Perhaps there's a need to treat the "license text" not as a single string, but 
as a set.
E.G., "GPL-2.0+,preferred-form,link-exception".

--- David A. Wheeler


-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of RUFFIN, MICHEL (MICHEL)
Sent: Wednesday, January 22, 2014 8:05 AM
To: Wolfgang Denk; spdx-legal@lists.spdx.org
Subject: RE: SPDX ID for GPL-2.0+ with addendum ?

This look like the Guile license
http://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Guile-License.html

michel.ruf...@alcatel-lucent.com, PhD
Software Coordination Manager, N&P IS/IT Distinguished Member of Technical 
Staff Tel +33 6 75 25 21 94 Alcatel-Lucent International, Centre de Villarceaux 
Route De Villejust, 91620 Nozay, France 


-Message d'origine-
De : spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] De la part de Wolfgang Denk
Envoyé : mercredi 22 janvier 2014 12:42
À : spdx-legal@lists.spdx.org
Objet : Re: SPDX ID for GPL-2.0+ with addendum ?

Hello,

I wrote:

> I ran into a number of source files which include the standard 
> GPL-2.0+ license header, but augmented with the following addendum:
> 
> For the avoidance of doubt the "preferred form" of this code is one which
> is in an open non patent encumbered format. Where cryptographic key 
> signing
> forms part of the process of creating an executable the information
> including keys needed to generate an equivalently functional executable
> are deemed to be part of the source code.
> 
> I think we will need a new License tag for this, right?
> 
> Do you have any suggestion for this?


I found more "augmented" versions of GPL-2.0+ ; some libgcc files add this 
clause:

In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combined
executable.)

Others include this above addendum, and additionally this one:

As a special exception, if you link this library with files
compiled with GCC to produce an executable, this does not cause
the resulting executable to be covered by the GNU General Public License.
This exception does not however invalidate any other reasons why
the executable file might be covered by the GNU General Public License.


Is it correct to assume that we need special license tags for these two cases, 
too?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
G's Third Law: In spite of all evidence  to  the  contra-
ry,  the  entire  universe  is composed of only two basic substances:
magic and bullshit.
H's Dictum:There is no magic ...
___
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: call today!

[Wheeler, David A]

I’m glad to see the new expression syntax, including “+”, “with”, “and”, “or”, 
and “;”.  Big improvement.

However, I suggest NOT requiring that expressions be surrounded with 
parentheses when there is no ambiguity (e.g., a single list of “and” or “or” at 
the top level).  All the examples  http://wiki.spdx.org/view/FileNoticeExamples 
include parentheses even in cases like “(GPL-2.0+ WITH Bison-Exception)”, which 
is more annoying for humans to type.  By all means support parens, just make 
them optional in such cases.

Thanks.

--- David A. Wheeler


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Thursday, December 11, 2014 12:44 PM
To: SPDX-legal
Subject: call today!

Please note this is the correct dial-in info:


Call this number: (United States): +1-857-216-2871

 User PIN: 38633

 International: visit the URL at http://uberconference.com/SPDXTeam

Agenda items as follows:
1) Dennis drafted some text for defining "deprecation" to be included at the 
top of the list of deprecated licenses, please review here:
Release 2.0 of the SPDX Specification introduces license expression syntax that 
supports the ability to identify common variations on standard licenses without 
the need to define each potential variation as a distinct license on the SPDX 
License List. This new syntax supports the ability to use a simple “+” operator 
after a license short identifier to indicate “or later version” (e.g. 
GPL-2.0+), and it also supports the ability to declare a standard license 
exception using the “WITH” operator (e.g. GPL-2.0+ WITH 
Autoconf-exception-2.0). SPDX has defined a list of standard License Exceptions 
to use after the “WITH” operator. A number of the standard License Exceptions 
were formerly included in the standard SPDX License List, but they have been 
deprecated as licenses, and correct usage employs the new license expression 
syntax. Note that for compatibility, the URL to each deprecated license still 
exists, but links to those deprecated licenses have been removed from the 
standard License List in order to clarify the currently recommended syntax.
2) license expression syntax FAQs (Mark) - please review: 
http://wiki.spdx.org/view/LicenseExpressionFAQ - for review and feedback
3) examples for license expression syntax on wiki page: 
http://wiki.spdx.org/view/FileNoticeExamples - for review and feedback

Thanks,
Jilayne & Paul
SPDX Legal Team co-lead


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

RE: Should LGPL-3.0 be an exception rather than a main license?

[Wheeler, David A]

I agree that the LGPL 3.0 absolutely *should* be on the license list.

--- David A. Wheeler


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Alan Tse
Sent: Monday, March 23, 2015 7:20 PM
To: Dennis Clark; J Lovejoy
Cc: SPDX-legal
Subject: RE: Should LGPL-3.0 be an exception rather than a main license?

I think most people will be confused if they’re looking at the License List and 
don’t find the LGPL3.

I might have missed what we consider an exception (didn’t find a definition on 
the webpage) but I always considered exceptions as small use case exceptions to 
an existing license.  The LGPL on the other hand seems more than just a small 
exception to the GPL and like a whole other license.

To digress a bit more, I always felt it was a marketing strategy to incorporate 
the GPL so people had to go look and realize there’s a “preferred” license over 
the LGPL.

Alan Tse
Copyright and Open Source Licensing Director
Western Digital Technologies, Inc.
3355 Michelson Dr., Suite 100, Irvine, CA 92612
T:  949-672-7759
F:  949-672-6604


From: 
spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Dennis Clark
Sent: Monday, March 23, 2015 4:09 PM
To: J Lovejoy
Cc: SPDX-legal
Subject: Re: Should LGPL-3.0 be an exception rather than a main license?

Legal Team,

I think that Sam's points about the LGPL 3.0 are technically correct, but given 
that OSI treats LGPL 3.0 as a license 
(http://opensource.org/licenses/LGPL-3.0), I think we can also treat it as "an 
exception to the exceptions" and continue to include it in our license list.  
It has become a very popular license (for mysterious reasons) and I think it 
would just seem really strange to handle it otherwise.  On the other hand, I'm 
cautiously open to the alternative view if most of the group prefers to 
redefine LGPL 3.0 as an Exception.

Regards,
Dennis Clark


On Mon, Mar 23, 2015 at 2:59 PM, J Lovejoy 
mailto:opensou...@jilayne.com>> wrote:
Hi Sam,

Hmm… great point.  This has not been considered previously and did not really 
need to be pre-2.0 discussions because the exceptions were not separated out, 
etc.

Our next legal call is on the day we are hoping to go live with 2.0, I think.  
So, we can discuss it then (it’s not a lengthy change), but can we get some 
thoughts on this topic via the email list in the meantime?

I think that, technically, this is right and LGPLv3 should probably be on the 
exception list, instead of listed as a separate license in and of itself.  But 
that’s just my gut…

thoughts???

Jilayne

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

On Mar 23, 2015, at 10:04 AM, Sam Ellis 
mailto:sam.el...@arm.com>> wrote:

Hi,

In relation to the SPDX-LL and exceptions, I note that LGPL-3.0 is listed as a 
full license (http://spdx.org/licenses/preview/LGPL-3.0.html). However the 
wording of LGLP-3.0 is such that it does not stand alone; it refers to and 
depends on GPL-3.0 and uses terms such as "supplemented by the additional 
permissions" and "Exception to Section 3 of the GNU GPL". I therefore wish to 
raise the question of whether LGPL-3.0 should be on the exception list rather 
than on the full list. Logically, it seems to be an exception, and yet it is 
such a mainstream license that I can see an argument for it to be on the full 
license list. Has this been considered previously?

--
Sam Ellis (ARM)

-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782
___
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: Should LGPL-3.0 be an exception rather than a main license?

[Wheeler, David A]

J Lovejoy:
>   GPL-3.0 WITH LGPL-3.0 (this feels a bit odd, but it would be accurate 
> technically speaking…) [or]
>   LGPL-3.0

I strongly believe “LGPL-3.0” is the correct answer.   "LGPL-3.0" is much 
simpler, it's much clearer to non-lawyers, and referring to it as its own name 
matches historical practice.

In *practice* the LGPL is practically always referred to as its own license, 
not as a tweak to another license.  Historically the LGPL was implemented as a 
separate license, and the “tweak” is not a small one either (exceptions are 
usually small).  All other license list systems (such as Debian and Fedora's) 
treat it as a separate license, so there is strong historical precedence to 
treating it as its own license (if no other reason than backwards 
compatibility).

--- David A. Wheeler

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

RE: [Bug 1292] New: What is the correct license expression for a project with an additional patent license?

[Wheeler, David A]

Perhaps the "WITH" operator's definition needs to be extended.  Instead of this 
definition: 
> The WITH operator semantically implies that a given license applies 
> except under certain special circumstances

Perhaps "WITH" should mean "Modify the license listed on the left, by appending 
the text referenced on the right".  In short, "WITH" could be used for 
exceptions, but also for clarifications and other modifications.  There are 
many common "riders" on licenses that are not licenses themselves, but common 
modifications/clarifications to them.

Then "AND" continues to mean "must comply with both licenses on the left and 
right", while "OR" continues to mean "must comply with one of the licenses 
listed on the left or right".   These don’t modify licenses. 

--- David A. Wheeler



-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Kyle E. Mitchell
Sent: Tuesday, June 16, 2015 1:23 PM
To: Gisi, Mark
Cc: spdx-t...@fossbazaar.org; spdx-legal@lists.spdx.org
Subject: Re: [Bug 1292] New: What is the correct license expression for a 
project with an additional patent license?

Mark,

Many thanks for your response!

React
-

In their defense, Facebook's licensing hygiene is actually well above the norm 
in the JavaScript/Node.js community, which tends to use a single LICENSE file 
and SPDX ID per project. (Copy-and-paste reuse is also less of a concern. 
Packages are often << 1KLOC.) The files that end up in the tarball for 
distribution via package manager are consistently marked:

```bash
$ cd /tmp
$ mkdir react-audit
$ cd react-audit
$ # Install the React package from repository.
$ npm install react
$ # Change to the installation directory.
$ cd node_modules/react
$ # Recursively search for files without "BSD".
$ fgrep -riL BSD .
./addons.js
./lib/EventListener.js
./README.md
./react.js
```

EventListener has an Apache-2.0 header. The other source files are one-line 
`require` calls, akin to `#import ` in the C world.
They're really just shims to make paths work.

The files in the Git repository without license headers are mostly build chain 
configuration and tests. There are also some code examples under a non-open 
source license and documentation under a CC license.


SPDX Expression
---

It sounds like we're agreed that BSD-3-Clause plus an additional patent grant 
is a fundamentally different kind of combination of reusable license terms than 
AND and OR. Is that a case for another combination operator in SPDX expressions?

To try and put a finer point on it:

x AND y := contains code licensed per and code licensed per y

x OR y := contains code licensed per choice of x or y

x PLUS y := contains code licensed per combination of x and y

"PLUS" is just a stand-in here. Another name may be appropriate.

K

On Tue, Jun 16, 2015 at 07:46:13AM +, Gisi, Mark wrote:
> From a compliance perspective Facebook/React project presents a common 
> nightmare situation. For example some files explicit state (e.g.,
> React.js):
>
>  * Copyright 2013-2015, Facebook, Inc.  All rights reserved.
>  *
>  * This source code is licensed under the BSD-style license found in 
> the
>  * LICENSE file in the root directory of this source tree. An 
> additional grant
>  * of patent rights can be found in the PATENTS file in the same directory.
> 
> While other files have no copyright/license notice (e.g., 
> Gruntfile.js, vendor/jasmine/diff.js, jasmine.js, src/test/all.js,
> ...) . Does that mean the Patent license is only available to some 
> files but not others. The project's license hygiene is questionable.
>
> >> Better to roll the BSD-3-Clause and additional patent grant into 
> >> one "Facebook BSD License", akin to the Apple MIT variant (AML)?
> 
> This would be preferred if such a list identifier existed. Until that 
> days comes, one could roll both licenses up into a single license 
> reference (e.g., LicenseRef-Facebook-BSD-Patent).
>
> The WITH operator semantically implies that a given license applies 
> except under certain special circumstances. Therefore I am not sure an 
> exception makes sense here.
>
> AND typically implies two sets of license terms apply. Not sure yet if 
> it makes sense to make FB-Patents-2.0 a full-fledged license (a 
> decision for the legal team). Alternatively one could use BSD-3-Clause 
> AND LicenseRef-FB-Patent.
>
> For now I think LicenseRef-Facebook-BSD-Patent is an adequate 
> representation.
>
> - Mark
> 
> -Original Message-
> From: spdx-tech-boun...@lists.spdx.org 
> [mailto:spdx-tech-boun...@lists.spdx.org] On Behalf Of Kyle E. 
> Mitchell
> Sent: Monday, June 15, 2015 12:01 PM
> To: Sam Ellis
> Cc: spdx-t...@fossbazaar.org; spdx-legal@lists.spdx.org
> Subject: Re: [Bug 1292] New: What is the correct license expression for a 
> project with an additional patent license?
> 
> Many thanks for your generous reply, and for sending so quickly.
> 
> Forgive me if I'm behind

RE: Is "+" a valid character of a LicenseRef idstring?

[Wheeler, David A]

Schuberth, Sebastian  wrote:

> Using a  + is a whart. Licenses that allow the use of other versions do so 
> explicitly in their texts, the GPL being the most prominent but the EPL comes 
> to mind too. So there is no such thing as GPL-2.0 or another version: these 
> are the plain default GPL terms.

The issue is how the software is licensed, not what the text of the GPL (or 
anything else) is.  The use of "+" to mean "or later" is a long-standing 
convention preceding SPDX.

> Essentially GPL-2.0 and GPL-2.0+ mean exactly the same the thing.

No, there's a need to distinguish between "exactly this version" or "this 
version of later".  Some software, such as the Linux kernel, are GPL version 
2.0 only.

--- David A. Wheeler

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

RE: Is "+" a valid character of a LicenseRef idstring?

[Wheeler, David A]

Philippe Ombredanne:
> This + is a suffix and not a freestanding character, right?
> Then again we would be better off to get rid of the plus entirely!

You may be confusing a SPDX "license identifier" and a SPDX "license 
expression".  It's a subtle point.

The purpose of a "license identifier" is to identify a specific text of a 
specific license text, using a short name.  In SPDX 2.0 there is no "+" in a 
standard license identifier.  In particular, "GPL-2.0" is a license identifier, 
and "GPL-2.0+" is *NOT*.  If all you want to do is identify a particular 
license text, use a license identifier.  No "+" exists at the end of a license 
identifier.

However, a "license identifier" is often inadequate for describing the 
licensing requirements imposed on users and later developers.  Many packages 
have different subcomponents with different licenses.  Many packages include 
the text of some license (such as the GPL version 2.0), but there are often two 
possible cases:
- You must use this particular version of the license.
- You may use this or any later version of the license.

Thus, SPDX 2.0 defines a "license expression" for describing how license texts 
apply to software packages,.  A license expression is built out of license 
identifiers but adds ways to describe how the license texts are used. A "+" 
appended after the name of a license identifier means "or any later version may 
also be used".  E.G., the license expressions "(GPL-2.0+ WITH 
Classpath-Exception-2.0)" and "(MIT AND BSD-3-CLAUSE)" express how the license 
text requirements are imposed on recipients (users and developers).  License 
expressions use the long-standing convention is that if software is licensed 
using "this or any later version" you add a "+" to the name of the license.   
You can argue that the "+" should be the default, but standards typically work 
best if they build on pre-existing conventions, and that was certainly the case 
here.

--- David A. Wheeler

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

RE: Is "+" a valid character of a LicenseRef idstring?

[Wheeler, David A]

I said:
> In particular, "GPL-2.0" is a license identifier, and "GPL-2.0+" is *NOT*.

Just a few nitpicks on my previous email:
* I realize that "GPL-2.0+" is in the list of "deprecated" license identifiers, 
so in some sense there is a  "GPL-2.0+" license identifier.  But I think it's 
clear what the *intent* is; the deprecated entry is only for legacy use.
* I only talked about pre-defined license identifiers with short forms.  I 
realize that there can be licenses not in the list, and those are handled 
differently. 

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

RE: Is "+" a valid character of a LicenseRef idstring?

[Wheeler, David A]

Philippe Ombredanne:
> I am not confusing these at all. The gist of what I am saying is that the 
> plus is a legacy that should not be there. It does not make sense to add to 
> the large majority of GPL in the wild a + just to deal with a few exceptions 
> that do not allow other versions. Exceptions should be dealt with an 
> exception not with an extra + in an expression.   What you saying in 
> substance is that every time I want state that code is licensed under the GPL 
> 2.0 or any other version (which is the default), you want me to craft a 
> special license expression with a plus. And If do not craft that expression, 
> then the SPDX meaning is that only the current version applies and not any 
> later version.
> I am saying this instead: Since the default for the GPL is to allow later 
> versions, we should by default state the opposite: The few times that "only 
> the current version" should be used, state this explicitly with an exception.
> You say:
> GPL-2.0 ==> implies  GPL 2.0 only
> GPL-2.0+ ==> implies  GPL 2.0 or later

That's not just what I say.  That's what the spec says, and has clearly stated 
since circa 2010. 

> I say:
> GPL-2.0 ==> implies  GPL 2.0 with its defaults (including later versions)
> GPL-2.0 with no-other-version  ==> implies GPL 2.0 and no other version
> Explicit is better than implicit.
> My rationale:
> Practically the use of a GPL version "only" is much less frequent than the 
> default "or later" and therefore forcing me to add a plus is a source of 
> confusion.
> The most common use case should be the default and should not require a 
> special addition of a character in an expression.
> "only" should be an exception and not the default, because it is not the 
> default, nor the prevalent usage of the GPL: it is exceptional.
> The fact that the + convention has been used by Linux distros package 
> maintainers and neither always strictly nor consistently does not make this 
> right and something that should be endorsed blindly.
> I am arguing about the essence of the meaning of the plain GPL-2.0 license 
> key in a simple expression.
> The mere use of a GPL-2.0 identifier should convey that the license is 
> GPL-2.0 or any other version.
> We should have an exception to convey the rarer cases when only the stated 
> version applies.

This would have been a useful argument to raise in 2010 (when SPDX was 
drafted).  But this group doesn't exist to create a new spec where none has 
existed. For more than 5 years SPDX has consistently stated that "GPL-2.0" 
means ONLY GPL-2.0 and nothing else.  This builds on previous history of Fedora 
and Debian, who also use "+" this way, e.g., see: 
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing .  While I know 
you're focusing on the GPL, there are many other licenses, and most licenses do 
NOT have a "this or later version" clause; having the default be what's common 
in MOST licenses is actually sensible.

Changing the meaning of "GPL-2.0" now, 5 years after the original version was 
released in beta, would be a terrible idea. This would be a broadly 
backwards-incompatible change. Even worse, it's a backwards-incompatible change 
that cannot be easily detected by tools.  The result would be that no one would 
know what "GPL-2.0" actually meant - does it mean "2.0 or later" or "exactly 
2.0"?  Many existing SPDX license expressions could be subtly wrong.  That is 
*NOT* a good direction.

> The benefits are:
> 1. no ambiguity about the meaning of widely used licenses such as the GPL.
> 2. simpler spec
> 3. simpler expressions in most cases, more verbose and more explicit 
> expressions when needed in some rarer cases.

I disagree, in fact, it would create widespread ambiguity.  People already use 
SPDX, with the terms as stated; there are many tools that build on it.  It 
*might* have been better to have defined it some other way many years ago, but 
that ship has sailed.

Standards have to pick some common agreement that most people can live with.  
Adding a "+" suffix to a particular license name does not seem like a serious 
burden.

--- David A. Wheeler

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

RE: Is "+" a valid character of a LicenseRef idstring?

[Wheeler, David A]

Philippe Ombredanne:
> The focus is not only on the GPL: well over 25% of the SPDX licenses DO HAVE 
> a "this or later version" clause
> In the grand scheme of things, "only" and "or later" are minute 
> technicalities that the large majority of software users do not care for. The 
> licenses requirements are essentially the same and "later or not later" is 
> not the question. Only a few licensing mavens care about this and they know 
> how to deal with it.

These are not minor technicalities from a legal point of view; versions are 
important.  They control what is allowed and not allowed.

It's true that many developers don't care about license versions, but many 
developers don't care about licensing or if what they're doing is legal.  I 
know we *do* agree that we should work for a higher standard :-).

> But SPDX is likely stuck with this inconsistent legacy and yes this is hard 
> to escape without creating more mess. It does not mean that we cannot try to 
> clarify and improve things.

Sure, but I think "GPL-2.0" MUST continue to mean "GPL version 2.0 and no other 
version", because that's the spec that everyone is depending on, this is a 
common case, and this is the convention that all other license naming systems 
also.  Changing a key existing meaning in a standard is a bad thing. 

Perhaps SPDX should add an additional postfix operation like "!" to mean 
"exactly this version and no other".  Then encourage always using the postfixes 
"+" or "!" in license expressions for licenses that have "or any later version" 
text.  E.G., "GPL-2.0!" might be the preferred way to express "exactly GPL 
version 2.0" while "GPL-2.0+" would continue to mean "GPL version 2.0 or 
later". Then you can deprecate license expressions where a license uses "or any 
later version" text and omits a postfix (e.g., "GPL-2.0" is a legal name of a 
license but a deprecated license expression).  You could even allow postfix "?" 
to mean it's unknown if later versions are allowed or not, a plausible tool 
result.  This would mean that SPDX would need to track which licenses have "or 
later version" text, to encourage people add the postfix operation, but that's 
easily done.

--- David A. Wheeler


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

RE: TPP software provisions

[Wheeler, David A]

Dennis Clark:
> I would be very interested to know if any of you have any thoughts about the 
> TPP provisions that impact software distribution, particularly source code 
> redistribution obligations:
> http://www.keionline.org/node/2363

The TPP appears to make copylefted software illegal, e.g., no more Linux, no 
more git.  Or at least governments are suddenly obligated to create new laws to 
invalidate them.  Am I reading this correctly? (I hope not.)

--- David A. Wheeler

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

RE: TPP software provisions

[Wheeler, David A]

Dennis Clark:
> I would be very interested to know if any of you have any thoughts about the 
> TPP provisions that impact software distribution, particularly source code 
> redistribution obligations: 
> http://www.keionline.org/node/2363 

I asked someone else whose legal opinion I respect about this. (I don't have 
permission to share his name, so I won't do that here.)  He said that the view 
of that article is misleading; instead, this provision precludes conditioning 
territorial market access on mandatory source code disclosure.  In other words, 
as I understand it, a country can't require that ALL software from outside 
provide the source code to just that country.

If *that* is the correct interpretation then I'm fine with this text; I don't 
see that as restraining trade or FLOSS.  That said, if that interpretation is 
wrong, please let me & others know.

--- David A. Wheeler

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

RE: New OSI-approved licenses

[Wheeler, David A]

Jilayne:
> That sounds like a reasonable result, all things considered.

I agree.  In fact, I think listing both "0BSD" and "FPL-1.0.0" is a great 
solution, especially if the SPDX website includes notices with each similar to 
the text at https://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 is used without a copyright notice.

I think this is a fine result:
- People who know the name of either license can now look it up
- Both sides who strongly prefer their name get their name
- For those who care, we now have documentation about the subtly different way 
they're typically used.

--- David A. Wheeler

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

Please add fields for FSF-approved, Debian-acceptable, and Fedora-good

[Wheeler, David A]

Can there please *ALSO* be standard fields to report if the license is:
* a free license as approved by the Free Software Foundation (FSF)  [Proposed 
field name: “FSF-approved”]
* a free license acceptable to Debian main [Proposed field name 
“Debian-acceptable”]
* a "good" license according to Fedora [Proposed field name “Fedora-good”]

This would be in *addition* to the OSI-approved list.

This isn’t an idle request. The “Best Practices” badge currently determines if 
a license is FLOSS if it is OSI approved *OR* if the license is on one of those 
other three lists.  You can see this here:
https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#floss_license

We also specifically *suggest* that the license be OSI-approved, but don’t 
mandate it:
https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#floss_license_osi

--- David A. Wheeler

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

RE: New License/Exception Request: BSD-3-Clause-NoNuclear

[Wheeler, David A]

Die 30. 03. 16 et hora 11.12.46 Sam Ellis quoted this “NoNuclear” license:
> “You acknowledge that this software is not designed, licensed or intended
> for use in the design, construction, operation or maintenance of any nuclear 
> facility.”.

Matija:
> FWIW, this would most probably fail the freedom 0 of the Free Software 
> definition – the freedom of everyone to run it – and be considered a “further 
>  restriction”.

Phil:
> I agree with your assessment; it is restrictive. On the other hand it seems 
> to me that in this case the restriction is a practical one motivated by 
> liability reasons, not a philosophical one which I believe the freedoms are 
> intended to protect.

To me, that’s a distinction without a difference.  *All* license selections are 
based on philosophical reasons; there are no exceptions.  Even saying you’re 
“just making a pragmatic decision” is itself a philosophy.  If the license just 
said, “You acknowledge that this software is not designed or intended for use…” 
then I could see the claim that it’s primarily just liability protection, but 
the license text specifically says it is not *licensed* for a use.  That goes 
*way* beyond just warning users for purposes of liability protection - that 
forbids *use*.

This example is *not* an open source software license, or a Free software 
license.  It fundamentally fails the Free Software Definition and it 
fundamentally fails the Open Source Definition.  Do not pass go, do not collect 
$200.

But I *do* think it’s reasonable to have SPDX license identifiers for licenses 
like this.  I wouldn’t want such a license in my dependency tree, so having a 
specific identifier for it (so I can discuss and avoid it) is very valuable.  
Too many people would label that a "BSD-ish" license; the more exacting SPDX 
license id could help me identify and root that license out.

I think the problem is that the “SPDX License List” is *NOT*, at this point, a 
list of open source software licenses.  Perhaps that was its original purpose, 
but things have changed.  Instead, it’s a list of useful shorthand license 
identifiers, for use in license expressions, which are primarily open source 
software licenses or licenses similar to open source software licenses.  This 
was made clear in the text shown earlier:
> the SPDX Legal Team does not require (1) strict compliance…

Since the SPDX legal team isn't requiring strict compliance with the 
definitions of "open source software" or "Free software", then it should *NOT* 
be making any statements that imply that it is.  Besides, there are at least 4 
other groups that do that kind of license analysis to determine if a license 
meets the OSD or FSD: OSI, FSF, Debian, and Fedora. Instead of redoing their 
analysis, the SPDX legal team should focus on determining canonical texts, 
determining what is the "same" or "different", and giving each license a unique 
canonical license identifier (with matching license text).  That is a very 
*valuable* service.

I recommend that the "SPDX License List" text be changed from:
> The SPDX License List is a list of commonly found open source licenses and 
> exceptions for the purposes of being able to easily and efficiently identify 
> such licenses and exceptions in an SPDX document (or elsewhere)...
to:
> The SPDX License List is a list of commonly found licenses and exceptions, 
> including many open source software licenses and licenses similar to open 
> source software licenses, for the purposes of being able to easily and 
> efficiently identify such licenses and exceptions in an SPDX document (or 
> elsewhere)...

You might also rename the "SPDX License List" to the "SPDX License Identifier 
List".

--- David A. Wheeler

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

RE: New License/Exception Request: BSD-3-Clause-NoNuclear

[Wheeler, David A]

> [1] https://www.google.com/search?q="intended for use in the design%2C 
> construction%2Coperation or maintenance of any nuclear facility"

That's a completely different legal text.  I agree that "not intended for use 
in the design, construction, operation, or maintenance of any nuclear facility" 
is not a licensing term, it's a notification of fact that is intended to 
counter warranty claims.  It doesn't say you CAN'T do it, it's just a warning 
that it wasn't intended for the purpose.

Perhaps *that* clause (not the previous one noted) should be a standard 
"exception" clause, like the CLASSPATH exception.

However, a text that says "This is not LICENSED for " is a completely 
different ballgame.  Since by default copyright doesn't allow use (under many 
interpretations), that says that you are NOT permitted to use the software for 
some purpose, and *ALL* definitions of FOSS unanimously agree that is *NOT* 
acceptable.

It's not really different from the "You may not use this for commercial 
purposes" or "You may only use this for research" riders that are often seen.  
Those are common, and also non-FOSS.


> It’s about value, not FOSS purity.

No, it's about truth.  Either the license list is a list of FOSS licenses, or 
it's a list of licenses including FOSS licenses.  The group needs to make a 
choice, and state that clearly.

I think it'd be fine to include non-FOSS or "FOSS-like" licenses (like this 
one) in the license list.  However, if it does, it must NOT say that this is a 
list of FOSS licenses, because this "non-nuclear" example is NOT a FOSS 
license.  Instead, it should say what the list is (e.g., "This is a list of 
FOSS and FOSS-like licenses").  SPDX is supposed to help people be legally 
precise; having false statements (especially in something so visible) will give 
people immediate pause.

--- David A. Wheeler

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

RE: New License/Exception Request: BSD-3-Clause-NoNuclear

[Wheeler, David A]

Eric Weddington [mailto:eric_wedding...@trimble.com]:
> Where SPDX is at now, is that it says one thing, but does another.
> Yes, the website says that the SPDX License List is a list of "commonly found 
> open source licenses".  But if we're going to talk about restriction use then 
> it's too late. The list already has these:
> CC-BY-NC-1.0 ...

Excellent point, and these are clearly *not* open source software licenses as 
well.

> The value, to me, that SPDX has is that it lists common licenses, that also 
> happen to include all the Open Source licenses too. They list a superset.
> The SPDX is not the OSI, or the FSF, and should never aim to be. Change the 
> website language to read "commonly found licenses, including open source".

Agreed.

--- David A. Wheeler

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

RE: FW: Please add fields for FSF-approved, Debian-acceptable, and Fedora-good

[Wheeler, David A]

Thanks for the support for this proposal.  I’m also realizing that these really 
shouldn’t be Boolean.  For example, Fedora’s license list identifies both 
“good” and “bad” licenses – so the field should allow both “good” and “bad”.  I 
also suggest that the field be optional – Fedora doesn’t comment about all 
licenses, and if it’s optional it will be *much* easier to distribute the work.

--- David A. Wheeler


From: Kate Stewart [mailto:kstew...@linuxfoundation.org]
Sent: Friday, April 01, 2016 2:21 PM
To: Gary O'Neall
Cc: J Lovejoy; SPDX-legal; Wheeler, David A
Subject: Re: FW: Please add fields for FSF-approved, Debian-acceptable, and 
Fedora-good

I support David's request as well,  and Gary's suggestion to reach out to the 
communities and get an expert from one of them to help fill out which of the 
lists associated with their projects (and keep an eye on it over tome.)

On Fri, Apr 1, 2016 at 12:58 PM, Gary O'Neall 
mailto:g...@sourceauditor.com>> wrote:
Let me know if this is scheduled for one of the upcoming legal team meetings - 
I would like to participate in this discussion.

I would like to support David's request, but I understand the challenges in 
maintaining the list.  I'm wondering if we could get some community support 
once we have the XML files out there to more easily distribute the workload.  
It would be very helpful if these other organizations included the SPDX ID's in 
their list and made them available in some machine parseable form.  If this 
were the case, we could do some tooling to automate the updates of these 
fields.  I haven't researched this, so it may already be implemented to some 
extent.

On the technical side, I would propose we add the three fields suggested by 
David with a slight change in naming to be consistent with other tag/property 
names.  Rather than being a Boolean, I would suggest 3 values - true, false, 
and unknown.  The addition of unknown would allow for the information to be 
added incrementally.

Gary

-Original Message-
From: 
spdx-legal-boun...@lists.spdx.org<mailto:spdx-legal-boun...@lists.spdx.org> 
[mailto:spdx-legal-boun...@lists.spdx.org<mailto:spdx-legal-boun...@lists.spdx.org>]
 On Behalf Of Wheeler, David A
Sent: Wednesday, March 30, 2016 6:40 AM
To: Philip Odence; Matija Šuklje; 
spdx-legal@lists.spdx.org<mailto:spdx-legal@lists.spdx.org>
Subject: Please add fields for FSF-approved, Debian-acceptable, and Fedora-good

Can there please *ALSO* be standard fields to report if the license is:
* a free license as approved by the Free Software Foundation (FSF)  [Proposed 
field name: “FSF-approved”]
* a free license acceptable to Debian main [Proposed field name 
“Debian-acceptable”]
* a "good" license according to Fedora [Proposed field name “Fedora-good”]

This would be in *addition* to the OSI-approved list.

This isn’t an idle request. The “Best Practices” badge currently determines if 
a license is FLOSS if it is OSI approved *OR* if the license is on one of those 
other three lists.  You can see this here:
https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#floss_license

We also specifically *suggest* that the license be OSI-approved, but don’t 
mandate it:
https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#floss_license_osi

--- David A. Wheeler

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

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org<mailto: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: Software Package Data Exchange (SPDX) specification for Public Domain, Government Works? Possible New License/Exception Request

[Wheeler, David A]

Gisi, Mark:
> The absence of Public Domain from the license list was not an oversight. A 
> fair amount of discussion took place to decide how to handle a public domain 
> designation. The current practice is to create a LicenseRef (a user defined 
> license reference that is local to an SPDX file).

I think that public domain designations should be handled *exactly* the same 
way by SPDX as all other common licenses - just create SPDX license identifiers 
for common ones.  Indeed, SPDX already *has* license identifiers for the public 
domain, through the license identifiers CC0-1.0, PDDL-1.0, and SAX-PD.  If a 
license statement is common, it should be in the License List.  A "license" is 
just "permission to do something".  Statements from the US government declaring 
that software is in public domain are simply license statements, and should be 
treated identically as any other license.

> [I suggest] that the government, like the SQLite project,   consider 
> including a standard government public domain notice in the header of every 
> source file. This would make it easy for one to understand the intent and to 
> create License references.

You mean the US government should get its act together and act as a single 
organization?  That sounds reasonable enough, but you will be disappointed :-). 
 Some government organizations use CC0 (already on the list), but many projects 
do not.  CENDI is usually the US government group that would recommend text 
like this, but I didn't see a particular suggestion here: 
http://www.cendi.gov/publications/

Besides, that same "should" applies to industry, as well as government, and 
industry doesn't meet that standard either.  Simple example: At a practical 
level the MIT license and BSD-2-Clause licenses are legally similar, but they 
have different legal texts, so they get different SPDX license ids.

If a license text is in use by a number of projects, it should get a license 
id.  I think software from the government should NOT be excluded.  Yes, its 
legal texts are different, and they often grant all rights (at least within the 
country).  So what?  That's exactly what SPDX is good for - capturing common 
legal text statements.

--- David A. Wheeler

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

RE: HPND & NTP

[Wheeler, David A]

Jilayne’s recommendation makes sense to me…!

--- David A. Wheeler


From: spdx-tech-boun...@lists.spdx.org 
[mailto:spdx-tech-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Friday, October 07, 2016 4:21 AM
To: SPDX-legal
Cc: spdx-t...@lists.spdx.org
Subject: HPND & NTP

Hi All,

During the SPDX bake-off it came up that NTP https://spdx.org/licenses/NTP.html 
can match to HPND https://spdx.org/licenses/HPND.html due to the template 
nature of HPND.  The folks in the bakeoff wanted to know if we ought to 
deprecate one of these licenses in favor of using the other or how a tool 
should reconcile which license to “pick” where both could be a valid answer.  
Talking about this here in Berlin and looking at the licenses, can we please 
discuss the following items on the next legal call:

1) Both of these licenses are OSI-approved, which is why they are both on the 
SPDX License List. Given that we endeavor to have all OSI-approved licenses on 
the SPDX License List (even if they are old or have been voluntarily deprecated 
by the author, as has HPND), so I don’t view deprecation as an option.  All 
agree?

2) As to HPND, we did not have markup for this license, but it needs it - Sam 
has added markup to the XML template and Brad has reviewed. It is flagged for 
review by the legal team: 
https://github.com/spdx/license-list-XML/pull/89/files  - can we get another 
set of eyes on this, both from the legal perspective and to check the markup?

3) OSI has comments as to how to “match” this license at the bottom of their 
page - 
https://opensource.org/licenses/HPNDl - 
should we add this to the Notes field, as is suggested in the XML file (do we 
really need it, especially if we have the markup and since the line about white 
space and capitalization merely repeats a couple of our matching guidelines?)

4) I would recommend adding a comment in the Notes field for each license along 
the lines of the following:
- for NTP: "This license is the same as HPND, when taking into consideration 
the templatizing options given in that license.  This is included as a separate 
license on the SPDX License List because it is separately approved by the OSI.”

- HPND: “Due to the templatization options of this license, it can be the same 
text as NTP license. This is included as a separate license on the SPDX License 
List because it is separately approved by the OSI.”

Please edit as needed.  Perhaps we can then ask the OSI to add similar language 
on their pages as well, so it is all consistent.


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

RE: New License Request: The Glasgow Haskell Compiler License

[Wheeler, David A]

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

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

[Wheeler, David A]

J Lovejoy:
> Thanks Bradley.  Your point re: other licenses building in a de facto “or 
> later”
> clause versus the GPL family of licenses leaving the choice to the copyright
> holders is exactly the thing I wanted to confirm and is also (I think, but 
> need
> to do more thinking on this) why the GPL family may indeed need it’s own
> unique treatment.
> 
> Deprecating “GPL-2.0” for use of  “GPL-2.0-only”, along with the use of the
> existing “GPL-2.0+” is what I’m leaning towards

Please DO NOT deprecate "GPL-2.0". DO NOT DO THIS.  If you do, we'll have 
*exactly* the same problem again in a few years.

We need at least *3* cases.  Here they are, with potential names/expressions:
* GPL-2.0-only.  I *know* that *only* the GPL version 2.0 is acceptable.  I had 
originally proposed a "!" suffix.
* GPL-2.0+.  I *know* that GPL version 2.0, or later, is acceptable.
* GPL-2.0.  I *know* that at least GPL version 2.0 is acceptable (e.g., I found 
its license text).  However, I'm not entirely certain whether or not later 
versions are acceptable, so I make *no* assertion either way.  This appears to 
be what "GPL-2.0" has become, in some cases, in spite of the spec.  Which is 
why we need a way to mark certainty vs. uncertainty.  If you prefer, you could 
label this "GPL-2.0-at-least", or add a "?" suffix to mean "I don't know if 
later/other versions are acceptable".

The problem is that while tools can detect the presence of a license, it's 
often difficult for them to determine if an "or later" clause is valid in some 
cases.  In many cases SPDX is capturing tool output, so we need for there to be 
a valid expression for tools to output.  My understanding is that some tools 
that find GPL version 2.0 will currently report "GPL-2.0"... even if a later 
version is also acceptable... and as a result, "GPL-2.0" is not being 
interpreted as originally intended.

What's more, without a third case, it'll just happen again.  Tools can't easily 
determine if "or later" applies, and in many cases you do *NOT* need more 
information than this.  It can take a lot of effort ($) to determine if it's 
really "GPL-2.0-only" or "GPL-2.0+", and if the spec only supports those two 
options, then that's a problem.. because people are *not* going to spend effort 
unnecessarily.

If "GPL-2.0" is deprecated, then tools will start reporting "GPL-2.0-only" when 
they're not sure if later versions apply, because in many cases they can't 
easily determine it.  Then we'll be back to the original problem, where 
"GPL-2.0-only" may mean "I found GPL 2.0 but maybe later versions will be 
okay".  Ugh.  Since many tools can only determine "at least this version", 
there needs to be a standard way to report it.

Same argument applies to GPL version 3, LGPL, AGPL, and perhaps MPL.

> but again, we need to vet all
> options, think through all possible pros and cons, and ensure a clear path
> (with limited pain) for existing users before coming to a conclusion.

I wholeheartedly agree.

--- David A. Wheeler

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

RE: New OSI approved license (BSD+Patent)

[Wheeler, David A]

> So basically “use an exception when the author asks for it, otherwise use a
> new license”.

Typically the "WITH" clauses are for a separate fragment of text that can be 
added to the "end" of a base license as a "rider".  It looks like this license 
text has it all merged in a single document.  Perhaps it might have been better 
if it had been written as a "rider", but it wasn't, and SPDX normally 
identifies licenses as they are (not as someone might have wanted them to be).

--- David A. Wheeler

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

RE: New OSI approved license (BSD+Patent)

[Wheeler, David A]

J Lovejoy:
> Specifically, when adding other BSD-x-Clause licenses, we have tried to 
> follow the same pattern for the identifiers as it aids in identifying what 
> exactly the license is, which I think everyone finds helpful!  Hence the use 
> of BSD-x-Clause- was intentional and thus, why I suggested such a 
> pattern here. I suppose we could add a more generalized note to that effect 
> in the guidelines as well.

I agree, I think something like "BSD-2-Clause-Patent" would be the better 
choice:
* It's more consistent with the other licenses
* All the existing tools can handle that, even if they can only handle 
identifiers (not expressions)
* Using "-with-" is hard to distinguish from the operator "... WITH ..." when 
spoken
* Using "...plus..." is hard to distinguish from terminating "+" when spoken

I hope that SPDX & OSI will agree on a short name, too...!

--- David A. Wheeler

___
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

[Wheeler, David A]

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!

--- David A. Wheeler

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