Re: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-15 Thread W. Trevor King
On Fri, Sep 15, 2017 at 12:01:32PM +, Zavras, Alexios wrote:
> Besides the case of GPL version numbers, isn't the issue similar to
> when we have cases like where you have a package that simply says
> "This program is under the BSD license"

This is definitely a similar case.  The difference is that the GPL
family have internal wording for this case [1], while the BSDs do not.

> The author "declared" something, but the SPDX spec is not really
> useful, since the value of the field is a license (or a license
> expression) and not a free form text. None of the licenses in the
> SPDX license list can be used as "PackageLicenseDeclared". Do we put
> a list of the 15 or so BSD variants, or disregard the declaration by
> stating "NOASSERTION"?

I would say NOSSERTION, because I don't think you're discarding much
information.  If you wanted to represent this case, you'd need a new
license expression operator for “or maybe they meant”.  That doesn't
seem particularly actionable to me, and I'd want to take a closer look
at a project if the best-estimate (a trusted conclusion when we have
one, and a declared call or unreliable conclusion when we don't)
involved such an operator.

> Taking it further, suppose that by looking at the actual wording of
> the license text in files, you might decide that the author is
> talking about BSD-3-Clause-No-Nuclear-License (in the nice case
> where all the files use the same text). But isn't this a "Concluded"
> rather than a "Declared" field?

If there are license terms in the header that match
BSD-3-Clause-No-Nuclear-License, then that seems like a pretty clear
declaration of BSD-3-Clause-No-Nuclear-License for those files, and
that would go in LicenseInfoInFile.  I think that could inform your
concluded package license, but it should not impact the declared
package license.

Cheers,
Trevor

[1]: 
https://github.com/spdx/license-list-XML/blob/f1522b5cc61bde64d9b38af05204fdb93c02eef8/src/GPL-1.0.xml#L167-L168

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


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal


RE: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-15 Thread Zavras, Alexios
Besides the case of GPL version numbers, isn't the issue similar to when we 
have cases like where you have a package that simply says
"This program is under the BSD license"

The author "declared" something, but the SPDX spec is not really useful, since 
the value of the field is a license (or a license expression) and not a free 
form text. None of the licenses in the SPDX license list can be used as 
"PackageLicenseDeclared". Do we put a list of the 15 or so BSD variants, or 
disregard the declaration by stating "NOASSERTION"?

Taking it further, suppose that by looking at the actual wording of the license 
text in files, you might decide that the author is talking about 
BSD-3-Clause-No-Nuclear-License (in the nice case where all the files use the 
same text). But isn't this a "Concluded" rather than a "Declared" field?

-- zvr -

-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Gisi, Mark
Sent: Friday, 15 September, 2017 13:19
To: Bradley M. Kuhn ; SPDX-legal 
Subject: RE: License identifiers sufficient to avoid loss of information in 
DeclaredLicense (was: GPLv2 - Github example)


Quick clarification:

>> I admit that I don't know how exactly to express such as Declarations. 
>> What is quite clear from this discussion, though, is that the 
>> Conclusions that people make about such Declarations vary.  Mark Gisi 
>> Concludes most of these examples as NOASSERTION.
>> I Conclude most of them are GPLv1-or-later.

The examples addressed Conclude License (files and package) but not the 
Declared License.
Furthermore, I only made a comment about Example 4. I agreed with the file 
Concluded License designations for Examples 1-3. Including Example 3 = GPL-1.0+.

And yes, for Example 4 I concluded NOASSERTION for each of the four files that 
have zero licensing info in them. There are many scenarios where those files 
could be something other than GPL. For example, one or more source files could 
have been copied from an Apache project or a commercial code based. I have 
encountered two cases in as many years where commercial code was copied  into a 
project with a GPL-2.0 file in the top directory. In one case the commercial 
license notice was retained in the file and in the other the notice was 
removed. Another situation I encountered ~5 years ago: someone admittedly 
removed the BSD license notices from several files he copied into his GPL 
project. He just assumed that they were now under the GPL-2.0 and the BSD 
notices were confusing and unnecessary! I had to explain he was violating the 
BSD license. 

As for Example 4, for me, hope is not a strategy. NOASSERTION.

>>
>> 3.15 Declared License
>>

The problem with this field does not lie with the LEL but with the values the 
"field" will accept. 

"This field lists the licenses  that have been declared by the authors 
of 
The package.  "
It should probably accept a list of LELs. For example if the top level 
directory had the following license files:

COPYING.GPL-2.0
COPYING.LGPL-2.0 

Then the declared license field should accept the "list" of LELs: GPL-2.0, 
LGPL-2.1

This approach is simple and probably handles 95% + cases.

- Mark


-Original Message-
From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Bradley M. Kuhn
Sent: Wednesday, September 13, 2017 11:47 AM
To: SPDX-legal
Subject: License identifiers sufficient to avoid loss of information in 
DeclaredLicense (was: GPLv2 - Github example)

Since the Legal call where we first began discussing what Jilayne has called 
the "Github examples", I've been thinking about this question regularly.

I do agree wholeheartedly with Richard Fontana's point that SPDX both has 
stakeholders who use the license identifiers outside of SPDX (and that SPDX as 
a project lauds such uses).  SPDX should indeed think about those users.
I'm primarily one of those users to the extent I use SPDX.

However, for the purposes of this discussion, I suggest we return to first 
principles in the SPDX specification.  So I asked myself, what job does SPDX 
expect license identifiers to do?  I went to the SPDX spec and looked at
this:
   3.15 Declared License
 3.15.1 Purpose: This field lists the licenses that have been declared by 
the
 authors of the package.  Any license information that
 does not originate from the package authors,
 e.g. license information from a third party repository,
 should not be included in this field.
   (URL: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys ) 

I began to think carefully about this question, what *is* the "Declared 
License" -- by the package authors -- in the examples at 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges
?

I admit that I don't know how exactly to 

Re: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-14 Thread W. Trevor King
On Thu, Sep 14, 2017 at 09:44:21AM -0700, Bradley M. Kuhn wrote:
> W. Trevor King wrote:
> > I don't think any of the examples there have a declared package
> > license.
>
> I believe putting a copy of GPL in a repository is declaring a
> package license.

You may be able to make that argument in some cases, but that cannot
be true in all cases.  For example, Gentoo's package tree is clearly
not under all of these licenses [1] nor are these packages under all
of the licenses they include [2,3].

> > > But, for *Declarations*, SPDX clearly needs some other
> > > identifier, which would usually only be used as Declared
> > > licenses.
> > 
> > This is not clear to me.  Can you elaborate?
>
> License theorist apparently disagree about what the concluded
> license is when I just put a copy of GPL in a directory in a
> package.  License theorists apparently disagree what when I say
> "this is GPL'd".  If there are disagreements, it seems me the SPDX
> spec is suggesting that SPDX should store the declaration somehow,
> and have the information available to those who must make
> conclusions.

Right, which is why there are separate SPDX fields to distinguish:

* Package declared/concluded: PackageLicenseDeclared [4] /
  PackageLicenseConcluded [5]
* File declared/concluded: LicenseInfoInFile [6] /
  LicenseConcluded [7]
* Snippet declared/concluded: LicenseInfoInSnippet [8] /
  SnippetLicenseConcluded [9]

But the *values* for all of those fields are license expressions.  So
whether or not we get an ‘only’ operator in license expressions seems
orthogonal to “who decided this was the license?” which is what
declared/concluded is about.

Tools like npm that give the package author one slot for a package
license [10] are collecting the declared package license.  Our own
SPDX-License-Identifier suggestion [11] is collecting the declared
file license.  Tools like licensee are taking a guess at a concluded
package license [12], and automated package-license conclusions
deserve all the caveats GitHub gives for them [13].

> > That means we *recommend* authors use SPDX License Expressions to
> > declare the license which applies to that file.  Do you feel that
> > is inadequate?  If so, how?
>
> This goes back to changing the outcome by observing it.  Some people
> chose to declare GPL using all the varied means that are
> contemplated in the text of the GPL about not specifying version
> numbers, etc.  SPDX should be flexible enough to allow such
> declarations that already exist in the wild, both at file and
> package level.

And doesn't it?  Your point that folks disagree about whether dropping
a copy of the GPL-2.0 into a repository counts as “declaring a project
license” or even “declaring a license for the other files in the
directory and its descendents” is fine.  I don't really care about
ambiguous author declarations.  What I care about is *unambiguous*
author declarations (e.g. including the recommended blurb at the top
of a file [14], or pointing out the package license in the docs [15]
or metadata file [16]).  I also care about the concluded license from
concluders I trust, because it resolves any ambiguity based on
ambiguous or incorrect declarations to my satisfaction.

If your policy is to count the presence of a local license as a
package license declaration, I'd expect you to mention that
possibly-contentious choice in PackageLicenseComments [17] (although
the docs for that field do not currently speak to ambiguities in
determining PackageLicenseDeclared).  And the weight that your
PackageLicenseDeclared and other calls have on others depends on how
much they trust your decisions.

So what information are you trying to express that doesn't already
have a home in the SPDX file?

Cheers,
Trevor

[1]: 
https://gitweb.gentoo.org/repo/gentoo.git/tree/licenses?id=c8d9adf62818774ab04531fb4f411c353891a54e
[2]: 
https://github.com/spdx/license-list-XML/tree/e0dc5826985ee29fbb103c1da607b4a62ac5ceb0/src
[3]: 
https://github.com/spdx/license-list/tree/3ac00adbaf162ba88f208ccee321fea4c8b7c643
[4]: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys
[5]: https://spdx.org/spdx-specification-21-web-version#h.ihv636
[6]: https://spdx.org/spdx-specification-21-web-version#h.111kx3o
[7]: https://spdx.org/spdx-specification-21-web-version#h.2lwamvv
[8]: https://spdx.org/spdx-specification-21-web-version#h.26o1yg500oc5
[9]: https://spdx.org/spdx-specification-21-web-version#h.4e2e263bk6wh
[10]: https://docs.npmjs.com/files/package.json#license
[11]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b
[12]: https://github.com/benbalter/licensee/blob/v9.2.1/docs/what-we-look-at.md
[13]: https://developer.github.com/v3/licenses/
[14]: 
https://github.com/angular/angular.js/blob/07849779ba365f371a8caa3b58e23f677cfdc5ad/docs/app/assets/js/angular-bootstrap/dropdown-toggle.js#L3-L23
[15]: 
https://github.com/angular/angular.js/blob/v1.6.6/docs/content/misc/faq.ngdoc#L194-L196
[16]: 

Re: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-14 Thread Bradley M. Kuhn
W. Trevor King wrote:
> I don't think any of the examples there have a declared package license.

I believe putting a copy of GPL in a repository is declaring a package
license.

Also, note that given that GPL is a strong copyleft, the file licensing data
both matters less, and also can impact the package license in ways that don't
happen in the permissive-MIT license example you gave.

> Declaring a package license looks like this FAQ entry [1]:

> > But, for *Declarations*, SPDX clearly needs some other identifier, which
> > would usually only be used as Declared licenses.

> This is not clear to me.  Can you elaborate?

License theorist apparently disagree about what the concluded license is when
I just put a copy of GPL in a directory in a package.  License theorists
apparently disagree what when I say "this is GPL'd".  If there are
disagreements, it seems me the SPDX spec is suggesting that SPDX should store
the declaration somehow, and have the information available to those who must
make conclusions.

> That means we *recommend* authors use SPDX License Expressions to declare
> the license which applies to that file.  Do you feel that is inadequate?
> If so, how?

This goes back to changing the outcome by observing it.  Some people chose to
declare GPL using all the varied means that are contemplated in the text of
the GPL about not specifying version numbers, etc.  SPDX should be flexible
enough to allow such declarations that already exist in the wild, both at
file and package level.
--
Bradley M. Kuhn
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal


Re: License identifiers sufficient to avoid loss of information in DeclaredLicense (was: GPLv2 - Github example)

2017-09-13 Thread W. Trevor King
On Wed, Sep 13, 2017 at 11:47:25AM -0700, Bradley M. Kuhn wrote:
> I began to think carefully about this question, what *is* the "Declared
> License" -- by the package authors -- in the examples at
> https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges

I don't think any of the examples there have a declared package
license.  Declaring a package license looks like this FAQ entry [1]:

  ### How is AngularJS licensed?

  The [MIT License](https://github.com/angular/angular.js/blob/master/LICENSE).

or this package.json entry [2]:

  "license": "MIT",

where the package maintainers are making an explicit claim about the
license for the whole package.

However, the files listed in the wiki examples which have the GPL
standard headers have a declared file license.  And the
license-text-of-the-GPL-2.0 has the same sort of declaration [3].

> But, for *Declarations*, SPDX clearly needs some other identifier,
> which would usually only be used as Declared licenses.

This is not clear to me.  Can you elaborate?

> Such an identifier would allow SPDX files (a) to better include all
> the information that was available to best inform those who look at
> the Declared license, (b) properly inform those making Conclusions,
> and (c) avoid the current situation that causes Conclusions about
> GPL licensing to appear in as a Declared license.
>
> I don't know what such an identifier should be, but it is *not*
> GPLvN-or-later; it's not GPLvN-only; it's not GPLvN+.  It's
> something else.

Since 2.1, the spec has had an appendix about SPDX-License-Identifier
comments in file headers with SPDX License Expression values [4].
That means we *recommend* authors use SPDX License Expressions to
declare the license which applies to that file.  Do you feel that is
inadequate?  If so, how?

Or are you on board with using SPDX License Expressions to express
both declared and concluded licenses, but have only have quibbles
about whether an ‘only’ operator is part of those expressions?  That
would be a much more narrowly scoped issue.  If this is what's going
on, can you explain why a header using the GPL-2.0's stock wording:

  Copyright (C)  name of author

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program; if not, write to the Free Software
  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
  02110-1301, USA.  Also add information on how to contact you by
  electronic and paper mail.

would not be clearly declaring GPL-2.0+?  And can you also explain
why a header that said:

  Copyright (C)  name of author
  SPDX-License-Identifier: GPL-2.0+

would not be clearly declaring GPL-2.0+?

Cheers,
Trevor

[1]: 
https://github.com/angular/angular.js/blob/v1.6.6/docs/content/misc/faq.ngdoc#L194-L196
[2]: https://github.com/angular/angular.js/blob/v1.6.6/package.json#L3
[3]: 
https://github.com/spdx/license-list-XML/blob/f3dc56f2424e8e93732f655637e0542c5557588c/src/GPL-2.0.xml#L26-L30
[4]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b

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


signature.asc
Description: OpenPGP digital signature
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal