Re: explanation for ensuring no duplicate identifiers

[W. Trevor King]

On Thu, Jul 05, 2018 at 06:16:56PM -0600, J Lovejoy wrote:
> Back to the Short Identifier additions are: characters, given the
> various feedback on this thread, here is an updated suggestion.

I'm fine with this proposal going out as you have it, but I've put a
few suggestions inline in case you want to pick them up.

> • Short identifier to be used to identify a license or exception
>   match to licenses or exceptions contained on the SPDX License List
>   in the context of an SPDX file, in source file, or elsewhere

This matches what's currently live [1], but it could probably be
tightened up to something like:

  Short identifiers identify licenses and exceptions from the SPDX
  License List in the context of an SPDX file, a source file, or
  elsewhere

> • Short identifiers have no spaces in them consist of ASCII letters
>   (A-Za-z), digits (0-9), full stops (.) and hyphen or minus signs
>   (-)

I think it is sufficient to list the allowed characters:

  Short identifiers consist of ASCII letters (A-Za-z), digits (0-9),
  full stops (.), and hyphen/minus signs (-).

And then, if you want to draw attention to spaces in particular, add a
second sentence to that list item:

  They do not contain spaces or other characters except those
  mentioned in the previous sentence.

> • Where applicable, the abbreviation will be followed by a dash and
>   then the version number, in X.Y format

This line is currently live [1], but do we need to keep it?  Not all
of our versions are X.Y.  For example, W3C-19980720 [2] is in MMDD
format.  Perhaps that falls under "where applicable", but why call out
one specific versioning approach?

> • Short identifiers must not be duplicative and must be different
>   from all pre-existing short identifiers.
> • While short identifiers can be treated as case insensitive, it is
>   encouraged to use the canonical short identifier casing.

These cover the two points I think need to get covered.  So while I
prefer my previously-suggested wording [3], I'm fine with this
wording.

Cheers,
Trevor

[1]: https://spdx.org/spdx-license-list/license-list-overview
[2]: https://github.com/spdx/license-list-XML/blob/v3.1/src/W3C-19980720.xml
[3]: Subject: Re: explanation for ensuring no duplicate identifiers
 Date: Mon, 18 Jun 2018 11:18:34 -0700
 Message-ID: <20180618181834.GD25466@valgrind>

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

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

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



signature.asc
Description: OpenPGP digital signature

Re: explanation for ensuring no duplicate identifiers

[W. Trevor King]

On Thu, Jun 14, 2018 at 01:28:11PM -0600, J Lovejoy wrote:
> • Short identifiers must not be duplicative: newly added short
>   identifiers will be checked to ensure they are different from all
>   pre-existing short identifiers, regardless of upper/lower case

Wherever we put this commitment, I think we also want something like
[1]:

  List consumers are enouraged to use the canonical identifier casing,
  but this uniqueness commitment ensures that case-insensitive
  comparison with listed identifiers will be unambiguous.

In a spec, I'd make that a SHOULD recommendation [2].  Encouraging the
use of canonical casing reduces the need for a case-canonicalizer [3],
by giving tools that choose not to implement a canonicalizer something
to point at if/when users complain about unrecognized, non-canonical
identifiers.  It also makes it less likely that tools decide to change
the case without thinking about downstream compatibility (e.g. [4]).

I also prefer focusing on the list state (across versions) instead of
using "newly added" to focus on changes to the list state.  For
example, my earlier wording [5]:

  This project commits to never, in any past or future version,
  contain identifiers which differ only in case but have different
  semantics.

makes it clear that the current list is already free of case-insentive
ambiguity.  With the "newly added" wording, we could already have
case-insentive ambiguous IDs and just be committing to not adding
more.

Cheers,
Trevor

[1]: 
https://github.com/spdx/license-list-XML/pull/651/files#diff-04c6e90faac2675aa89e2176d2eec7d8R16
[2]: https://tools.ietf.org/html/rfc2119#section-3
[3]: https://github.com/spdx/spdx-spec/issues/63#issuecomment-366370691
[4]: https://github.com/benbalter/licensee/issues/282
[5]: 
https://github.com/spdx/license-list-XML/pull/651/files#diff-04c6e90faac2675aa89e2176d2eec7d8R14

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

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

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



signature.asc
Description: OpenPGP digital signature

Re: EPL-2.0 and Exception

[W. Trevor King]

On Wed, Apr 18, 2018 at 11:05:31AM -0400, Wayne Beaton wrote:
> FWIW, it is the perspective the Eclipse Foundation that, from the
> point of view of a consumer, the notion of secondary license is
> effectively the same as dual licensing. We therefore encourage our
> projects to use the disjunctive OR when expressing licenses.

I've filed [1] to make that recommendation more discoverable for SPDX
consumers.

Cheers,
Trevor

[1]: https://github.com/spdx/license-list-XML/pull/639

-- 
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: EPL-2.0 and Exception

[W. Trevor King]

On Mon, Apr 16, 2018 at 01:46:26PM +0200, Till Jaeger via Spdx-legal wrote:
> EPL-2.0 exists in two forms as well (with or without Exhibit A
> making it compatible to the GPL).

My understanding is that the recommended approach is to use OR [1],
e.g.:

  EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0

Perhaps this should be addressed in a  entry in EPL-2.0.xml?
Phil had called for that not in [1] but it hasn't happened yet.  I'm
happy to file a pull request adding the note later in the week if
nobody else beats me to it ;).

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002150.html
 Subject: Re: New License/Exception Request: EPL-2.0
 Date: Tue, 29 Aug 2017 12:33:22 +
 Message-ID: 

-- 
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: Last call for version 3.1 website review

[W. Trevor King]

On Thu, Apr 12, 2018 at 05:48:07PM -0500, g...@sourceauditor.com wrote:
> Please let me know if you know of any issues with the preview
> website that could potentially hold up the release.

I'd really like to have obsoletedBy exposed [1] to downstream
consumers.  For example, obsolete-license suggestions in Ruby are
blocked by the lack of stable, canonical access to this data [2].  If
we can get that information exposed in the next week, I think it's
worth pushing the release back.  Otherwise, I guess we'll survive for
a few more months without it ;).

Comparing the license-list-data diff between v3.0 and the current
31f52f1, I have two minor concerns:

* There seems to be missing  around the first lines in html/*.html [3]
  html/0BSD.html seems to have lost a  on its first line [3]

* While GPL-3.0-only [4] and GPL-3.0-or-later [5] both have isFsfFree
  true, the deprecated GPL-3.0 [6] and GPL-3.0+ [7] have it false.  It
  looks like I need to add the deprecated + identifiers to the fsf-api
  repo, but that repo *is* currently showing GPL-3.0 as libre:

$ curl -s https://wking.github.io/fsf-api/spdx/GPL-3.0.json | jq .tags
[
  "gpl-3-compatible",
  "libre"
]
$ curl -s https://wking.github.io/fsf-api/licenses-full.json | jq 
'.licenses.GNUGPLv3 | {tags, identifiers}'
{
  "tags": [
"gpl-3-compatible",
"libre"
  ],
  "identifiers": {
"spdx": [
  "GPL-3.0-or-later",
  "GPL-3.0-only",
  "GPL-3.0"
]
  }
}

Cheers,
Trevor

[1]: https://github.com/spdx/LicenseListPublisher/issues/12
[2]: https://github.com/rubygems/rubygems/pull/2259#issuecomment-377790912
[3]: https://github.com/spdx/license-list-data/issues/32#issuecomment-381024177
[4]: 
https://github.com/spdx/license-list-data/blob/master/json/details/GPL-3.0-only.json#L3
[5]: 
https://github.com/spdx/license-list-data/blob/master/json/details/GPL-3.0-or-later.json#L3
[6]: 
https://github.com/spdx/license-list-data/blob/master/json/details/GPL-3.0.json#L3
[7]: 
https://github.com/spdx/license-list-data/blob/master/json/details/GPL-3.0%2B.json

-- 
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: Past and preview License List releases (was: 3.1 release)

[W. Trevor King]

On Thu, Apr 05, 2018 at 03:04:05PM -0400, Brad Edmondson wrote:
> I'm in favor of solving this (making html available for old versions
> of the license list). I think it will help with adoption too,
> especially as we move back to a more frequent release cadence.
>
> Perhaps add to the errata issue? Or file a separate issue?

I think the existing [1] (from last week) covers this issue.  I'm
arguing against addressing this in LicenseListPublisher, but I don't
think we want multiple GitHub issues about past/preview HTML going at
once ;).

Cheers,
Trevor

[1]: https://github.com/spdx/LicenseListPublisher/issues/11

-- 
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: Past and current License List releases

[W. Trevor King]

On Wed, Mar 28, 2018 at 02:55:22PM -0500, g...@sourceauditor.com wrote:
> I probably won't have time to get this working before 3.1…

Is this an argument for moving the archives out of “admin-only
WordPress activity” and into a public Git repository/branch (like
[1])?  That way non-admins can contribute improvements and admins only
have to merge(/deploy).

There's some previous discussion on this starting at [2], which seems
to have concluded with admin-only WordPress activity [3].  If you're
comfortable with that here too, that's fine ;).

Cheers,
Trevor

[1]: https://wking.github.io/license-list-data/
[2]: https://github.com/spdx/spdx-spec/pull/42#issuecomment-344677633
[3]: https://github.com/spdx/spdx-spec/pull/42#issuecomment-345131418

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

Past and current License List releases (was: 3.1 release)

[W. Trevor King]

On Mon, Mar 26, 2018 at 06:10:06AM -0700, Mark D. Baushke wrote:
> An alternative would be to use an ISO 8601 to express time.
> See https://en.wikipedia.org/wiki/ISO_8601
> 
> Version: 3.0 published on 2017-12-28
> 
> Version: 3.0 of 2017-12-28

+1 to using ISO dates.

It would also be nice to be able to link to [1] in a way that will
survive 3.1 getting cut.

About the URL template itself, I'd rather not repeat “archive”, and
“archive” no longer feels quite right once you have an entry for the
current release.  I also think the /licenses/ prefix already covers
“ll” (which I'm guessing is for “License List”).  Wouldn't it be
sufficient to use:

  https://spdx.org/licenses/v3.0/

or at most:

  https://spdx.org/licenses/release/v3.0/

Cheers,
Trevor

[1]: https://spdx.org/licenses/archive/archived_ll_v3.0/

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

Past and preview License List releases (was: 3.1 release)

[W. Trevor King]

On Fri, Mar 23, 2018 at 12:14:03PM -0700, Philippe Ombredanne wrote:
> We are pushing new versions of the license lists but we are NOT
> keeping online the previous versions. They are only in git repos.
> I think it would help a lot adopters to have all the versions (at
> least starting with 2.6 and up) available online on the license list
> web page(s).

An easy way to do this would be to push our website HTML (e.g. [1]) to
the gh-pages branch of license-list-data.  I've mocked that up in
[2,3], and you can see old versions of the list in [4,5,…].

> It could also make sense as a further refinement to publish a
> preview of a new version list for comments/heads up before it
> becomes the latest.

You can do this with the gh-pages approach too [6,7], although someone
(possibly a robot) would need to bump gh-pages after each master
commit (or at least whenever you wanted to refresh the preview).

If this approach seems useful, someone with license-list-data write
access just needs to push my gh-pages branch [8] to the main
repository.

Cheers,
Trevor

[1]: https://github.com/spdx/license-list-data/blob/v2.6/website/0BSD
[2]: https://wking.github.io/license-list-data/
[3]: 
https://github.com/wking/license-list-data/commit/c112d15c76e8c2f0a5c15eca8719a81a765a631f
[4]: https://wking.github.io/license-list-data/v2.6/website/
[5]: https://wking.github.io/license-list-data/v3.0/website/
[6]: https://wking.github.io/license-list-data/dev/website/
[7]: 
https://github.com/wking/license-list-data/commit/1f7322894a9e3a2a233eca9250549d3cd59f5eeb
[8]: https://github.com/wking/license-list-data/tree/gh-pages

-- 
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: 3.1 release

[W. Trevor King]

On Fri, Mar 23, 2018 at 02:28:57PM -0400, Steve Winslow wrote:
> Apologies for any confusion from submitting as a separate PR, I'm
> not sure how to modify or add commits to the existing PR at #551...

You can stack your commits on top of the original PR's branch and then
set that branch as the base of your pull request [1,2].  In this case
that would mean filing the pull request against the branch in Wayne's
repository.

But for something short and simple like this, filing parallel requests
like you did is probably fine too ;).

Cheers,
Trevor

[1]: 
https://help.github.com/articles/creating-a-pull-request/#changing-the-branch-range-and-destination-repository
[2]: 
https://help.github.com/articles/changing-the-base-branch-of-a-pull-request/

-- 
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: New License/Exception Request: Qt-LGPL-exception-1.1

[W. Trevor King]

On Fri, Mar 23, 2018 at 03:39:54PM +, Kai Koehne wrote:
> Short-name: Qt-exception-LGPL-1.1

I've filed a pull request implementing this [1], although I went with
the short ID from your subject instead of the one I'm quoting here
(more on why in the PR).

Cheers,
Trevor

[1]: https://github.com/spdx/license-list-XML/pull/627

-- 
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: PRs v. Issues for new licenses/exceptions

[W. Trevor King]

On Thu, Mar 22, 2018 at 01:54:01PM -0500, Kate Stewart wrote:
> Its currently just asking for an email on
> https://spdx.org/spdx-license-list/request-new-license

I think the canonical docs should be in-repo [1] and that external
docs should link there.  Folks are unlikely to create an issue/PR
without GitHub telling them about that CONTRIBUTING file (currently
“Helpful resources… Contributing” on the right in [2]).  But it's
certainly possible to file a new issue/PR without hitting [3].

Cheers,
Trevor

[1]: 
https://github.com/spdx/license-list-XML/blob/master/CONTRIBUTING.md#request-a-new-license-or-exception-be-added-to-the-spdx-license-list
[2]: https://github.com/spdx/license-list-XML/issues/new
[3]: https://spdx.org/spdx-license-list/request-new-license

-- 
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: Update FAQ after license list 3.0

[W. Trevor King]

On Wed, Mar 07, 2018 at 10:53:41AM +0100, Matija Šuklje wrote:
> I was browsing through the FAQ and found out that since we
> (re)renamed the GPL family in license list 3.0, we haven’t updated
> the texts in the FAQ yet.

+1 on updating the FAQ.  I think we also want to explicitly list the
spec and license-list versions we're talking about as well, to help
folks during transitions (some folks may still be using license-list
2.x tools and would appreciate access to FAQ discussion about those
identifiers).  And I think the spec could use more specifics about the
default value for LicenseListVersion [1].  Currently it's not clear to
me which version of the license-list is implied when the optional
LicenseListVersion is not set.

Cheers,
trevor

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

FSF status for FSF licenses (was: meeting minutes)

[W. Trevor King]

On Tue, Feb 27, 2018 at 06:21:21PM +, Zavras, Alexios wrote:
> … on the subject of FSF “free” field: let’s make sure that FSF’s own
> licenses (GPL*, LGPL*, GFDL*, etc.) are marked as “free”.  I think
> their site lists only licenses by others, but our table seems…
> strange having an empty field for GPL’s free bit.

The FSF lists some of their own licenses, e.g. GPL-3.0 [1] but not
GPL-1.0 [2].  That's part of the reason for missing entries.  The
other part of the reason is that the versioning for the FSF API is
currently in flux [3], and until that gets sorted I think Gary is
holding off on updating the tools (but it's been a while since I've
checked, maybe my understanding is stale).

Cheers,
Trevor

[1]: https://www.gnu.org/licenses/license-list.html#GNUGPLv3
[2]: https://github.com/wking/fsf-api/issues/7
[3]: https://github.com/wking/fsf-api/issues/10

-- 
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: JPNIC / BIND license text - not quite Sendmail

[W. Trevor King]

On Mon, Feb 05, 2018 at 11:01:03AM -0800, Dennis Clark wrote:
> Others may disagree (naturally) but I think the license notice
> matches the SPDX "Apache-1.1" license.

There are numerous differences vs. our Apache-1.1 template.  For
example, the JNIC license [1] does not include Apache-1.1's “Products
derived from this software may not be called…” language [2].

And the JNIC license does not include Sendmail's “Redistributions
qualify as "freeware" or…” language [3].

So if we want to treat this as equivalent to existing license, we'd
need to adjust the templates.  Sendmail is our only license with “Use,
Modification and Redistribution”, so I agree with Wilcox that Sendmail
is probably the best choice if we decide to expand an existing
template to cover the JNIC wording.  And regardless of semantic
similarity, I think that there are enough wording differences that it
would probably be easiest/safest to mint a new license identifier.

Cheers,
Trevor

[1]: 
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=COPYRIGHT;h=3dffc132959d260ed8ed92d0d794a231b5447595;hb=HEAD#l364
[2]: 
https://github.com/spdx/license-list-XML/blob/v3.0/src/Apache-1.1.xml#L50-L55
[3]: https://github.com/spdx/license-list-XML/blob/v3.0/src/Sendmail.xml#L22-L23

-- 
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: Documenting the Pull Request process

[W. Trevor King]

On Wed, Jan 03, 2018 at 09:36:30AM -0800, g...@sourceauditor.com wrote:
> At some point, these issues will likely turn into a pull request
> created by someone quite familiar with the current license XML
> format.  There currently isn't much documentation on the specifics
> for the pull request process itself.
> …
> The document would be technical in nature and provide guidance on
> creating new license XML files…

I think you're going both ways for “these contributors are familiar
with the current license XML format”.  But regardless of how familiar
folks are, documenting that format is good for onboarding new
contributors and keeping existing contributors on the same page.  I've
just finished the initial work on [1], which adds documentation for
the schema semantics to our XSD file.  I think that's the best place
for those docs, because it makes it easier to keep them up to date as
the schema evolves.

> … process for reviewing and accepting pull requests, use of tags…

These sound like maintainer docs.  Other projects I'm involved with
have a separate MAINTAINERS_GUIDE.md [2] or similar for this sort of
thing.

> … best practices for license matching markup, limitations in the
> current tools, pointers to the XML schemas…

This sounds like useful information for anyone reading the XML.  I'd
rather document the best-practices and tool limitations in the XSD,
along side the semantics.  That gives XML authors and readers a single
place to look to understand a given element or attribute.

> … tips on debugging license match failures…

This sounds like useful information for both XML authors and matching
consumers.  But I'm not clear on what sort of content you'd include.
This seems more like “we should update the tooling to provide better
diagnostics for failed matches”.

> … and anything else we can think of that would help technical
> contributors to the repository.

I'm certainly in favor of improving our documentation, as long as we
don't add more documentation than we are able to maintain.

Cheers,
Trevor

[1]: https://github.com/spdx/license-list-XML/pull/586
[2]: 
https://github.com/opencontainers/project-template/blob/8e4c7e3dbea403c727d7fc526b8dcd53d6c98202/MAINTAINERS_GUIDE.md

-- 
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: Proposed addition to the license matching guidelines

[W. Trevor King]

On Wed, Jan 03, 2018 at 09:20:54AM -0800, g...@sourceauditor.com wrote:
> If we were to update the license matching guidelines to explicitly
> ignore these, the tools could skip them without having to add the
> alt and/or optional tags to the license XMLs.

Alt/optional aren't all that difficult, and we need them anyway for
variations in potentially-substantive text.  I'm in favor of
continuing to use them explicitly in the XML for this case, and would
like to see us gradually *reduce* the size of the matching guidelines
[1].  A handful of [2]:

  Bootloader Exception

and similar in our XML doesn't seem like it would be hard to add,
review, or maintain.  And by not special-casing this issue, we make
life easier on folks implementing matching tools, since they have one
fewer guideline to handle.

Cheers,
Trevor

[1]: https://spdx.org/spdx-license-list/matching-guidelines
[2]: 
https://github.com/spdx/license-list-XML/blob/v3.0/src/exceptions/Bootloader-exception.xml#L9

-- 
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: SPDX License List 3.0 is now live!

[W. Trevor King]

On Fri, Dec 29, 2017 at 03:26:47PM -0500, Neal Gompa wrote:
> Aww man, you've got to be kidding? You got rid of the "+" signifier
> and now we have to write out words?!
> 
> I really don't like this change. It makes things more verbose for no
> benefit.

This issue has seen a a lot of discussion over the past year (going
back at least as far as May [1]).  I'm also not wild about the change
(although there are *some* benefits), but discussing it should
probably be an issue for the spdx-legal@ list only (no need to drag in
spdx@ or spdx-biz@, and the spdx-tech@ folks are probably all
listening on spdx-legal@ anyway).  I propose we continue this
discussion on spdx-legal@ only, and have only included the other
spdx-*@ in my message in case folks there are wondering where the
conversation went ;).

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-May/001975.html
 Subject: various threads on "only" suffix (for GPL)
 Date: Fri, 26 May 2017 11:01:44 -0600  
 
 Message-ID: 

-- 
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 list release 2.7 or 3.0? (was: update on license list release)

[W. Trevor King]

On Fri, Dec 29, 2017 at 02:27:19PM -0500, Brad Edmondson wrote:
> We discussed on the Dec. 7 call and landed on 3.0 -- I think partly
> because the spec was leaning toward 3.0 as well…

Are we planning on breaking backwards compat with the spec?  That
would be fun for me when I'm wearing my spec-editor hat, but less fun
for me when I'm wearing my SPDX-consumer hat ;).  Are there any
breaking changes in particular that are driving a 3.0 spec?

Cheers,
Trevor

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

License list release 2.7 or 3.0? (was: update on license list release)

[W. Trevor King]

On Thu, Dec 21, 2017 at 11:44:44PM -0700, J Lovejoy wrote:
> A handful of us have been working away on the 3.0 release of the
> SPDX License List.

I think this can be a 2.7 release, with 3.0 to follow if/when some
currently-deprecated identifiers are finally dropped.  Are there any
breaking changes being made?  The spreadsheet → XML transition is big,
but shouldn't impact most downstream consumers (was the spreadsheet
format ever described as a stable, authoritative list API?).  We don't
explicitly claim Semantic Versioning [1] for the list, but I don't
want to startle consumers with a major version bump if we don't expect
major consumer-side changes.

Is there a 2.7 vs. 3.0 discussion somewhere where I can read up on the
existing discussion?  Or is this email the beginning of that
discussion?

Cheers,
Trevor

[1]: https://semver.org/

-- 
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: [spdx-tech] Proposed topic for this week's tech call: Extend license expressions to include OR-MAYBE

[W. Trevor King]

On Mon, Nov 27, 2017 at 10:17:22PM -0800, Gary O'Neall wrote:
> >   binary-confidence-expression-operator = "AND"
> >   confidence-expression = license-expression space "CONFIDENCE" space "0." 
> > 1*DIGIT
> >   confidence-list = confidence-expression *(space confidence-expression) 
> > [space license-expression]
> >   / confidence-list space 
> > binary-confidence-expression-operator space confidence-list
> >   / license-expression
>
> [G.O.] My preference is for the "OR-MAYBE" approach just due to the
> simplicity.  In the audit use case, it is difficult to assign a
> confidence that has any precision.  The weighting would work for a
> tool where there is some algorithm that results in a weighting or
> confidence measure.

I agree that getting consistent confidence numbers is going to be
hard, and that without that (and maybe even with that), confidence
weights may not be very useful.  But with two license tools returning
confidence-weighted alternatives, I want to make sure we understand
their intended use cases before we commit to backwards-compat for a
binary OR-MAYBE.

Cheers,
Trevor

-- 
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: "unclear version" and OR-MAYBE operators

[W. Trevor King]

On Tue, Nov 21, 2017 at 09:51:27PM -0800, W. Trevor King wrote:
> [2]: https://lists.spdx.org/pipermail/spdx-legal/2017-November/002317.html
>  Subject: Re: only/or later and the goals of SPDX
>  Date: 
>  Message-ID: <20171109195414.ga11...@valgrind.us>
> …
> [5]: 
>  Subject: Re: only/or later and the goals of SPDX
>  Date: Thu, 12 Oct 2017 10:31:47 -0700
>  Message-ID: <20171012173147.gd11...@valgrind.tremily.us>

Sorry, hit send too soon :/.  [2] was sent on Thu, 9 Nov 2017 11:54:14
-0800.  [5] is at
https://lists.spdx.org/pipermail/spdx-legal/2017-October/002265.html

Cheers,
Trevor

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

"unclear version" and OR-MAYBE operators (was: update on only/or later etc.)

[W. Trevor King]

On Tue, Nov 21, 2017 at 08:10:02AM -0700, J Lovejoy wrote:
> Just a reminder to all: when someone places a copy of the GPL,
> version 2 alongside source code files this does not make the
> licensing ambiguous; clearly there is a valid license…
>
> Any scenario you could interpret, we have a way to express that
> currently and would still under the proposal.
>
> … https://opensource.com/article/17/11/avoiding-gpl-confusion …

I think a copy of the GPL alongside source code (e.g. [1]) is
ambiguous.  And the article you link mentions “confusion” in the URL,
“foggy” in the title, and “ambiguity” in the subtitle.  I agree that
you can, like Fedora, decide that you are comfortable enough with one
interpretation.  But I think Gary has volunteered himself for the “I'd
write partially-concluded license expressions, but there's no syntax
for it yet” camp [2].  The FSF itself is unwilling to commit to a
public position on this situtation (as far as I'm aware).  So I think
there is likely to be a substantial set of license-expression authors
who are unwilling to claim a complete conclusion.  Is this point still
under contention?

If we accept a substantial set of partial-concluders, the SPDX needs
to decide what to suggest to them.  Folks using SPDX documents can
already use comment sections, but those are unstructured [3].  And
folks using bare license expressions obviously don't have access to
the SPDX-document comment field.  We can tell them:

a. That they cannot pass the partial conclusion along, and can only
   bail out with NOASSERTION (I've filed [4] to add that to license
   expressions).
b. That they can pass the partial conclusion along, using:

   i. an AMBIGUOUS[-VERSION] operator, or
   ii. an OR-MAYBE operator,

   as discussed in [5].

I see no upside to (a), but I'm not an SPDX maintainer.  I strongly
prefer b.ii to b.i, as discussed in [5].

The OR-MAYBE operator (b.ii) is completely independent of how the
or-later business shakes out.

The AMBIGUOUS[-VERSION] operator (b.i) overlaps slightly, because
you'd have to choose which GPL short identifier to use with
AMBIGUOUS-VERSION.  If (b.i) has no surviving supportors, we don't
have to worry about that at all.

Cheers,
Trevor

[1]: 
https://github.com/javierwilson/tonto/tree/75be0678be565872cbe7b99d5af4a1946393ee77
[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-November/002317.html
 Subject: Re: only/or later and the goals of SPDX
 Date: 
 Message-ID: <20171109195414.ga11...@valgrind.us>
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-October/002259.html
 Subject: Re: only/or later and the goals of SPDX   

 Date: Wed, 11 Oct 2017 23:12:39 -0700  

 Message-ID: <20171012061239.ga11...@valgrind.tremily.us>
[4]: https://github.com/spdx/spdx-spec/issues/50
[5]: 
 Subject: Re: only/or later and the goals of SPDX
 Date: Thu, 12 Oct 2017 10:31:47 -0700
 Message-ID: <20171012173147.gd11...@valgrind.tremily.us>

-- 
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: update on only/or later etc.

[W. Trevor King]

On Thu, Nov 16, 2017 at 05:37:50PM -0700, J Lovejoy wrote:
> Deprecate the "GPL-2.0" identifier and add the word “only” for GPL
> version 2 only, e.g., "GPL-2.0-only"
> - this should not be problematic as it does not change the meaning
>   of the identifier. GPL-2.0 has meant ‘version 2 only’ since the
>   SPDX License List was born. We are simply adding explicit language
>   for the identifier. No backwards compatibility issues in terms of
>   the meaning.
> - we can do a “warning” for people using the deprecated identifier
>   for a period before “GPL-2.0" becomes invalid to give people a
>   chance to update. This will also encourage people who have been
>   sloppy to fix their sloppiness.

I think this “deprecation with an eventual removal” approach is part
of all of the proposals, and is not unique to the “coin new
per-version license identifiers” approach.

> Keep the + modifier in the license expression language
> - this allows use of + with other licenses as always, no change, no
>   backwards compatibility

I am strongly against having both a ‘GPL-2.0+’ license ID and a ‘+’
operator.  I think committing to a ‘GPL-2.0+’ license ID is an
unfortunate but tenable postition.  And if we go that way, I'd rather
remove the ‘+’ operator entirely.

I'd be ok with ‘GPL-2.0-or-later’ while preserving the ‘+’ operator
for other licenses.  But if a ‘+’ operator is deemed not good enough
for the GPL, which licenses would it be good enough for?  This feels
like “we don't know when we'd recommend ‘+’, but didn't have the heart
to kill it”.

Personally, I think the ‘+’ operator *is* good enough for the GPL, but
if that view was universal we wouldn't be adding an or-later license
ID.  If we cannot build a consensus around using ‘+’ for the GPL, I'd
rather drop it entirely.  My concern with coining license identifiers
for ‘GPL-2.0-or-later’ and similar is the combinatoric increase in
license identifiers, and that's more of an aesthetic concern than a
technical concern (although there are some technical impacts, e.g. the
size of license-list-XML and license-list-data will grow).

Cheers,
Trevor

-- 
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: Jilayne Lovejoy invited you to “SPDX tech/legal call”.

[W. Trevor King]

On Wed, Nov 15, 2017 at 02:56:00PM +, Jilayne Lovejoy wrote:
> UID:F31FBFD4-9300-4B60-BEC6-81CB9A3EFDCD
> DESCRIPTION:Web conference: http://uberconference.com/SPDXTeam\n Optional 
>  dial in number: 415-881-1586\n No PIN needed
> SEQUENCE:0
> SUMMARY:SPDX tech/legal call
> DTSTART;TZID=America/Denver:20171121T11

Instead of creating a new event for this joint session, folks who have
imported the legal-team meeting may find it more convenient if we add
the new time to an existing, recurring legal-team meeting.  RFC 5545
provides RDATE for that [1], and an update to drop Thanksgiving and
add the 21st to the legal-team meeting looks like [2].

On the other hand, importing a new, one-off meeting from email isn't
that hard either, so perhaps an RDATE entry is over engineered ;).

Cheers,
Trevor

[1]: https://tools.ietf.org/html/rfc5545#section-3.8.5.2
[2]: 
https://github.com/spdx/spdx-spec/pull/42/commits/bb7ee2c9f9b7fed6cbff8d748b375bd199fb878b

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

Partial conclusions and ambiguous grants (was: only/or later and the goals of SPDX)

[W. Trevor King]

On Thu, Nov 09, 2017 at 01:55:55PM -0700, J Lovejoy wrote:
> On Nov 9, 2017, at 12:54 PM, W. Trevor King wrote:
> > On Wed, Oct 11, 2017 at 11:12:39PM -0700, W. Trevor King wrote:
> >> The ambiguous operator (first floated as “unclear version” in
> >> [3]) and my OR-MAYBE proposal [4] are both attempts to allow an
> >> SPDX License Expression authors to handle those situations they
> >> consider too ambiguous for a complete conclusion, but where they
> >> can provide more structure than NOASSERTION.  The ambiguous and
> >> OR-MAYBE operators are both providing a way to express partial
> >> conclusions *without* recourse to a full SPDX document and its
> >> unstructured comment fields.  This may be useful in general, and
> >> David has said he would be satisfied with:
> >>
> >>  GPL-2.0 OR-MAYBE GPL-2.0+
> >>
> >> most of the time [5].  I still don't have anyone stepping up to
> >> say they'll produce such expressions though [6], and I doubt its
> >> worth writing up a spec for it without someone saying “I (or my
> >> tool) wants to write partially-concluded license expressions but
> >> there's no syntax for it”.  But “nobody has told us they'd write
> >> this yet” is a much narrower rejection than “the proposals are
> >> incongruent with the goals of SPDX”.
> >
> > On today's legal call, it sounded like Gary might have volunteered
> > himself for the “I'd write partially-concluded license
> > expressions, but there's no syntax for it yet” camp.  If so, we
> > have both producers and consumers for some kind of
> > partial-conclusion license expression syntax.  Do we need to
> > collect further producer/consumer commitments, or is this enough
> > to move forward with preliminary specifications for OR-MAYBE,
> > AMBIGUOUS-VERSION, or one of those operators?
>
> I don’t think “partially-concluded” is the right term here: the bit
> we are stuck on is a way to express: I found a copy of one of the
> GNU licenses, but no other information. Period.  - should that have
> it’s own license identifier? should that scenario have it’s own
> operator? TBD

I don't think that's a valid license, and the FSF reservations about a
bare ‘GPL-2.0’, etc. makes it sound like they agree.  So you have some
information, but not enough to conclude an actual license, which seems
like a partial conclusion to me.

I do agree that you could choose to represent that partial conclusion
with something generic (e.g. an OR-MAYBE operator), something sort-of
generic (e.g. an AMBIGUOUS-VERSION or LICENSE-TEXT-BUT-NO-GRANT
operator), or something extremely narrow (e.g. a
GPL-2.0-text-but-no-grant license-list entry).

> Keep in mind: it doesn’t now. The license list and expression
> language currently provides for the “only” and “or later” options
> via GPL-2.0 and GPL-2.0+.  To paraphrase Philippe’s earlier post: no
> one using SPDX has had a major issue with this and tool makers have
> managed to work with is. I believe David Wheeler was the first
> person to raise this as a potential gap (David, please correct me if
> I’m wrong), aside from the FSF.

And in today's call, Gary was expressing concern about not having a
structured way to represent this in license expressions.  I agree that
SPDX could be internally-consistent with both postitions:

a. Only allow a complete conclusion or NOASSERTION in license
   expressions, or
b. Extend (a) to also allow structured partial conclusions in license
   expressions.

> Anyone doing audit work can benefit from a way to specify that a
> license is found and be specific about what license was found. We do
> have that now. The question on the table is if/how to accommodate
> that in a different, preferably more specific way.

I'm not aware of a way to say “I found a copy of the GPL-3.0 text in
the repository but no explicit grants, and am concluding that tonto.sh
is either under the GPL-2.0 ONLY or it's under the GPL-1.0+” for [1]
using just license expressions.  I think you have to fall back to the
comment property [2], which is great, but it's:

* Not structured, and therefore not easily machine readable.
* Not available to folks who have only license-expressions to work
  with, and therefore can't use the SPDX-file's comment property.

> > Am I misrepresenting anyone?
>
> I don’t think David was on this call, not sure if you were implying
> that here, but sort of sounded like it ;)

Sorry!  David is getting looped in via his previous email, linked
below:

> >> [5]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002235.html
> >> Subject: RE: "unclear version" and OR-MAYBE operators (was: reminder: 
> >> call Thursday)
> >> Date: Thu, 

Re: only/or later and the goals of SPDX

[W. Trevor King]

On Tue, Nov 07, 2017 at 11:31:07AM -0700, J Lovejoy wrote:
> https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses

And they have an official position on the javierwilson/tonto case,
where the GPL-3.0 text is in LICENSE, but no other file in the
repository contains copyright or licensing information.  From the
Fedora wiki:

  Full Name: GNU General Public License (no version)
  Short Name: GPL+
  FSF Free? Yes
  GPLv2 Compat? Yes
  GPLv3 Compat? Yes
  Notes (stuffed into the “Upstream URL” column):
A GPL or LGPL licensed package that lacks any statement of what
version that it's licensed under in the source code/program
output/accompanying docs is technically licensed under *any*
version of the GPL or LGPL, not just the version in whatever
COPYING file they include.

so their position is that the presence of a particular version of the
text in the COPYING (or presumably LICENSE, etc.) does not count as
the program specifying a version of the license [2].

Cheers,
Trevor

[1]: 
https://github.com/javierwilson/tonto/tree/75be0678be565872cbe7b99d5af4a1946393ee77
[2]: 
https://github.com/spdx/license-list-XML/blob/4aac6f8459901a6061c243cbfa3970afb39e3879/src/GPL-1.0.xml#L169-L170

-- 
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: only/or later and the goals of SPDX

[W. Trevor King]

On Tue, Nov 07, 2017 at 10:19:31AM +0100, Philippe Ombredanne wrote:
> I think that whatever is done on the SPDX side to be
> precise vs. being accurate-enough and good-enough will unlikely ever
> be adopted as the magnitude of the education and changes required
> would be immense…

Backwards compat is certainly important, and the plan with a new ONLY
operator would be to have tooling warn, but not error, on ambiguous
declarations like ‘GPL-2.0’ for the next few years [1].  Then when
SPDX cuts a 3.0, we'd start erroring on ‘GPL-2.0’ and only support
‘GPL-2.0+’ or ‘GPL-2.0 ONLY’.  And depending on how the rest of this
works out, ‘GPL-2.0 AMBIGUOUS’ or ‘GPL-2.0 OR-MAYBE GPL-2.0+’.

Being able to warn/error on ambiguously versioned declarations is why
I want to compatibleWith… metadata.

And to keep supporting folks who will never update their declarations,
we just need to version the license-expression-consuming fields.  For
example, we could explicitly make ‘SPDX-License-Identifier’ [2] mean
“a 2.x SPDX license expression” and create a new field
(SPDX-License-Identifier-3?) for “a 3.x SPDX license expression”.

External consumers could do the same thing.  For example, npm's
package.json is already explicitly an SPDX 2.0 license expression [3].
That means they only have access to the 2.0 license list (2015-04
[4]), not SPDX 2.1's 2.5 license list (2016-07 [5]).  Which means they
cannot use 0BSD or other identifiers which were added between list 2.0
and list 2.5.  If/when the npm community wants to explicitly support
those newer expressions, they can bump their supported SPDX version.
And it will be up to them whether they decide to do that with a new
field or whether they'd rather change the semantics of their existing
field.  [3] discusses a previous ‘licenses’ which had different
semantics, so they've used the new-field approach in the past.

> … for minuscule benefits…

I think the FSF has a reasonable point that ‘GPL-2.0’ by itself isn't
immediately obvious to folks who don't bother to look it up in the
spec.  If they do look it up, they can see that we intend it to be
‘GPL-2.0 ONLY’.  But in 2015, you guessed it to be ‘GPL-2.0+’ [6].
Suggesting (and, in a few years and/or with SPDX 3.0, requiring) an
explicit versioning operator will make the semantics much more clear
to casual readers.  I think that's a more-than-miniscule benefit.

> … and hyper confusion.

Can you go into more details about the confusion you expect?  There
will certainly be a maintenance *cost*, as current ‘GPL-2.0’ users
update their strings to use the new ONLY operator (or another
versioning operator, if they hadn't realized that ‘GPL-2.0’ meant
‘GPL-2.0 ONLY’).  But I don't see a new source of confusion.

Cheers,
Trevor

[1]: https://wiki.spdx.org/view/Technical_Team/Minutes/2017-08-07
[2]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b
[3]: https://docs.npmjs.com/files/package.json#license
[4]: https://spdx.org/sites/cpstandard/files/pages/files/spdx-2.0.pdf#page=64
[5]: https://spdx.org/spdx-specification-21-web-version#h.1jlao46
[6]: https://lists.spdx.org/pipermail/spdx-legal/2015-November/001537.html
 Subject: Is "+" a valid character of a LicenseRef idstring?
 Date: Mon Nov 2 09:56:47 UTC 2015

-- 
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: Providing access to FSF license metadata

[W. Trevor King]

On Fri, Oct 13, 2017 at 02:30:18PM -0400, Richard Fontana wrote:
> By the bye, one thing I'd find useful, either inside or outside of
> SPDX, is some notion of correspondence of an FSF-approved license
> with a counterpart OSI-approved, or SPDX-recognized, license.
>
> To illustrate, consider the MIT license. There is no MIT license
> steward; the de facto standard text (basically for historical
> reasons) is that on the OSI website,
> https://opensource.org/licenses/MIT

I agree, and think the best way to maintain that sort of information
is with automated SPDX license matching [1].  Then, everyone with
license opinions (the OSI, FSF, etc.) publishes a list of reviewed
license IDs (using SPDX IDs or their own custom IDs, e.g. [2]):

  $ curl -s https://api.opensource.org/licenses/ | jq '[.[] | .id]'
  [
"AAL",
"AFL-3.0",
"AGPL-3.0",
…
  ]

Then for each reviewed license, they provide a way to get the
metadata.  For example [3]:

  $ curl -s https://api.opensource.org/license/AAL | jq .
  {
"id": "AAL",
"identifiers": [
  {
"identifier": "AAL",
"scheme": "SPDX"
  },
  …
],
…
"text": [
  {
"media_type": "text/html",
"title": "HTML",
"url": "https://opensource.org/licenses/AAL;
  }
]
  }

And the text.  The OSI doesn't have a good example of this at the
moment; you'd have to scrape the wrapping markup off of [4].

Then you can use regular SPDX matching to determine the SPDX ID for
the license in question to determine an objective (and verifiable)
match (modulo wiggle room in the SPDX matching definition ;).

Individual providers may suggest their own ID mappings (as in the OSI
example above, where the OSI asserts their AAL license has the ‘AAL’
SPDX ID), and downstream consumers could either trust those mapping
assertions, verify the asserted mapping, or come up with their own
mapping.

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

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

On Fri, Oct 13, 2017 at 01:09:43PM -0600, J Lovejoy wrote:
> On Oct 13, 2017, at 12:02 PM, W. Trevor King wrote:
> > On Fri, Oct 13, 2017 at 10:20:33AM -0700, Gary O'Neall wrote:
> >> There is a request by the FSF and approved by the legal team to
> >> add a property to the listed licenses isFsfFree to indicate if a
> >> license is identified by the Free Software Foundation as a Free /
> >> Libre license.  This would be a simple Boolean type.
> >
> > I am against this in license-list-XML, for the same reasons I am
> > against our current osi-approved type: SPDX should not be a
> > canonical source of whether *someone else* has approved a license
> > or not.  I'd much rather provide tools for Alice to start with an
> > SDPX ID and lookup Bob's notes for a given license.  More on this
> > in [1].
> 
> This is not really a for or against issue :)
>
> It is something that has been asked for by the SPDX community (David
> Wheeler, last person who asked) and discussed as something that
> would be nice to have, but we’d need help from the FSF to organize
> and maintain.  Now that the FSF has asked for this directly, we are
> adding it. SPDX is not claiming to be a canonical source here, just
> reflect the same info found elsewhere.  Given anyone will be able to
> submit a pull request, the expectation once the initial work is
> done, will be that the FSF will help keep this current if there are
> changes.

Right.  I'm not calling for “never document this anywhere”.  I'm
calling for only documenting the OSI ID, FSF ID, etc. for each license
in license-list-XML and maintaining those mappings with automated
tooling.  Then downstream resources built from license-list-XML (like
license-list-data [7]) can bake in whatever OSI-provided and
FSF-provided metadata they want for their consumer's convenience
without worrying about maintaining it in license-list-XML.

> As for the OSI information - this was decided to be included very
> very early on (probably 2010, or 2011 - SPDX License List got going
> in fall of 2010, if memory serves) and again as a joint decision
> with the OSI.  At that time, they did not have the API.

Re: Spec recommendation for paren encapsulation?

[W. Trevor King]

On Thu, Oct 12, 2017 at 08:33:18PM +, Wheeler, David A wrote:
> 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")…

But how do you determine “fits on one line” without either clear rules
for folding whitespace or a requirement for encapsulating parens?

> …and such expressions are used in the wild anyway, so tools should
> correctly interpret data in this form.

Wild example [1].  I haven't been able to turn up a multi-line example
yet.  If we can't find one, perhaps we can safely replace the old
encapsulating-paren requirement with a folding-whitespace requirement.

> In addition, if the purpose is to unambiguously find the end, you
> only need parentheses at the outermost layer…

I agree with this and the next paragraph.

> For clarity, I think that the spec should be tweaked to make this a
> little more obvious.

Yes please :).  [2] is my attempt to start on that.

> > 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 issue isn't really quantity, it's whitespace.  For example:

  SPDX-License-Identifier: LicenseRef-Muahahahahahahahahahaha-1.0
WITH u-boot-exception-2.0

only has a single LicenseRef.

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

If we can get specific rules for them, then sure.  Otherwise I think
parsing malformed data is up to the tool on a best-effort basis.  And
some tools are going to want to be more conservative than others.

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

A benefit to folding at the tag:value layer is that the *license
expression* is still a single logical line.

Cheers,
Trevor

[1]: 
https://github.com/DataSoft/u-boot/blob/793fd86f722f5c5e13290be2074816b001359b76/arch/arm/dts/vf-colibri.dtsi#L4
[2]: https://github.com/spdx/spdx-spec/pull/37

-- 
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: Spec recommendation for paren encapsulation?

[W. Trevor King]

On Thu, Oct 12, 2017 at 01:08:28PM -0700, Gary O'Neall wrote:
> The current definition for a file license expression allows for more than one 
> line:
> "... The SPDX License Identifier syntax may consist of a single
> license (represented by a short identifier from the SPDX license
> list) or a compound set of licenses (represented by joining together
> multiple licenses using the license expression syntax)..."

I don't see anything about newlines in there.  What I'm wondering is
whether:

  APACHE-2.0 OR
   GPL-3.0

is a valid license expression, and whether:

  SPDX-License-Identifier: (APACHE-2.0 OR
   GPL-3.0)

is a valid SPDX-License-Identifier entry.

I *do* see [1]:

  The tag should appear on its own line in the source file…

which is using the singular ‘line’, although it's not clear to me
whether that was intention, or whether it should have been line(s).

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

Email addresses this with folding headers [2,3,4]:

  FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
  obs-FWS = 1*WSP *(CRLF 1*WSP)

compare the ABNF spec's [5]:

  LWSP=  *(WSP / CRLF WSP)

and you can see that LWSP allows the consecutive-folds problem
discussed in [4].

As long as something like:

  FWS'= ([*WSP CRLF] 1*WSP)

was used in our spec (for tag:value?  Maybe just use RFC 5322 for
tag:value?), I don't see any ambiguity.  We'd probably want a more
relaxed newline:

  FWS"= ([*WSP NL] 1*WSP)
  NL  = CR LF / CR / LF

because we're not always looking at internet-standard-newline files,
but that's not a big pivot.

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

I don't actually see anything in the spec about allowing multiple
lines.  Can you point at the wording?  Or maybe there is no such
wording in the spec, and we should add it (for 2.2?).

Cheers,
Trevor

[1]: 
https://github.com/spdx/spdx-spec/blame/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/appendix-V-using-SPDX-short-identifiers-in-source-files.md#L25
[2]: https://tools.ietf.org/html/rfc5322#section-2.2.3
[3]: https://tools.ietf.org/html/rfc5322#section-3.2.2
[4]: https://tools.ietf.org/html/rfc5322#section-4.2
[5]: https://tools.ietf.org/html/rfc5234#page-14

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

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

[W. Trevor King]

On Thu, Oct 12, 2017 at 06:21:05PM +, Wheeler, David A wrote:
> 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.

Hmm, I'd read that differently, based on:

  SPDX-License-Identifier: (GPL-2.0 OR MIT)

and similar examples in [1].  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].

With that SPDX-License-Identifier background, I'd read the wording as
recommending:

  Whatever-A: (EPL-2.0 OR LicenseRef-GPL-2.0-with-Assembly-exception OR GPL-2.0 
WITH Classpath-exception-2.0 OR Apache-2.0)

Grudgingly accepting the unenclosed ‘OR Apache-2.0’ in:

  Whatever-B: (EPL-2.0 OR (LicenseRef-GPL-2.0-with-Assembly-exception OR 
GPL-2.0 WITH Classpath-exception-2.0)) OR Apache-2.0

as long as ‘Whatever-B’ wasn't ‘SPDX-License-Identifier’.  And not
distinguishing at all between Whatever-A and:

  Whatever-C: ((EPL-2.0 OR (LicenseRef-GPL-2.0-with-Assembly-exception OR 
GPL-2.0 WITH Classpath-exception-2.0)) OR Apache-2.0)

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b
 Appendix V: Using SPDX short identifiers in Source Files
[2]: https://github.com/spdx/spdx-spec/pull/37
 Subject: appendix-IV: Refactor the license expression appendix
[3]: 
https://github.com/spdx/spdx-spec/pull/37/files#diff-f006efd0d473205cd5b1f2fee088e3f1R27
[4]: 
https://github.com/spdx/spdx-spec/pull/37/files#diff-f006efd0d473205cd5b1f2fee088e3f1R36

-- 
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: only/or later and the goals of SPDX

[W. Trevor King]

On Thu, Oct 12, 2017 at 10:44:54AM -0400, John Sullivan wrote:
> I understand SPDX doesn't want to make legal judgments.  Which is
> why it should indicate when there is uncertainty.

While SPDX should avoid making legal judgements, I don't think it
necessarily follows that they need to enable others to avoid making
legal judgements.  Concluded licenses are really all about legal
judgements, and I think everyone agrees we want SPDX to continue to
specify ways to declare license conclusions [1,…].

> Situations like "found a copy of the license but not clear licensing
> statement" should be flagged as things to be fixed, if SPDX wants to
> achieve its goal of successfully communicating reliable license
> information.

And you can already do that in an SPDX document via
PackageLicenseComments [2] and similar.  What you can't do at the
moment is declare a partial conclusion in a structured way.

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

Allowing this in general license expressions [3] (vs. the current
special case in places where license expressions are used [1]) may be
a reasonable pivot.  Although note that license-expression consumers
don't always agree on the meaning of NOASSERTION [1,4].  In most
situations you can achieve effectively the same results as NOASSERTION
by just refusing to provide a license-expression.

> Can we get a list of all of the options on the table for dealing
> with the case of "found a copy of the GPLv2, but no licensing
> statement anywhere"?

a. Add an ‘ONLY’ operator, remove ‘only’ from GPL-2.0, etc. names,
   clarify that the absence of a versioning operator means that
   versioning was not explicitly addressed in the license grant [5].
   This would allow for ‘GPL-2.0+’, ‘GPL-2.0 ONLY’, and ‘GPL-2.0’,
   etc.

   a. Also add operator-compatibility metadata to each license, so
  tooling can tell if the lack of a versioning operator is a sign
  of an ambiguous grant (e.g. a bare ‘GPL-2.0’) or nonsense grant
  (e.g. ‘NPL-1.0 ONLYy’) [6].

   b. Also add an ‘AMBIGUOUS’ operator [7] so license-expression
  authors can mark in an obvious-to-casual-readers way that they
  were not comfortable making an unambiguous conclusion
  (e.g. ‘GPL-2.0 AMBIGUOUS’).  Or maybe 

   c. Also add an ‘OR-MAYBE’ operator so license-expression authors
  can mark in an obvious-to-casual-readers way the set of license
  expressions that are still in the running for their conclusion
  [8], even though they haven't narrowed that down enough to pick
  a single one (e.g. ‘GPL-2.0 ONLY OR-MAYBE GPL-2.0+’).

Mark's called for actual examples where you'd use these [9], so here
are some:

* Linux's block/bio.c is [10,11]:

GPL-2.0 ONLY WITH Linux-syscall-note

* public-inbox is [12]:

AGPL-3.0+ WITH LicenseRef-OpenSSL-linking-permission

* javierwilson/tonto is [13] (with just (a)):

GPL-3.0

  or with (a.b):

GPL-3.0 AMBIGUOUS

  or with (a.c):

GPL-3.0 ONLY OR-MAYBE GPL-3.0+

I don't hear anyone arguing against (a), excepting from a
backwards-compat standpoint.  And I think folks were on-board with
(a.a) and tooling that allowed folks to keep using ‘GPL-2.0’ with
“ambiguous version” warnings for a year or two, followed by errors in
strict parsers after the deprecation period ends

(a.c) seems more clear and more powerful than (a.b), but I haven't
heard much discussion comparing the two.  And while (a) alone is
sufficient to express these partial conclusions, without at least one
of the sub-options it's very hard to tell from the license expression
alone whether a missing version operator was an intentional statement
of ambiguity or an accidental mistake.  (a.a) allows tooling to warn
about such cases, which may make mistakes less likely.  And (a.b) or
(a.c) will allow the careful to type in some extra characters, making
both mistaken-writes and casual-read-misunderstandings less likely.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.ihv636
[2]: https://spdx.org/spdx-specification-21-web-version#h.41mghml
[3]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
[4]: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys
[5]: 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Proposed_Solution:_add_only_operator
[6]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html

 
 Subject: Re: minutes, summary, next steps  

 
 Date: Thu, 17 Aug 2017 14:37:22 -0700  

 
 Message-ID: 

Re: only/or later and the goals of SPDX

[W. Trevor King]

On Wed, Oct 11, 2017 at 11:13:56PM -0600, J Lovejoy wrote:
> But this missed a key part of the core goals of SPDX: Implicit in
> those above goals is that the SPDX License List (including the
> license short identifiers and the license expression language) aim
> to provide a “language” to identify what we know, what we find - not
> what we don’t know or find. Having some kind of “ambiguous” operator
> (however we might decide to express that) is incongruent with this
> and the goals of SPDX. The original proposal as we came up with
> allows for an accurate description of what is found, including in
> the case of finding only the text of a license.

This may be cutting it to cleanly.  For full SPDX documents, there are
comment fields (e.g. PackageLicenseComments [1]) for motivating your
concluded license.  I think that motivation is especially important
when you're stretching a bit to bridge a gap between a declared
license (or lack thereof) and your conclusion.  That all works fine in
SPDX documents, and I think we want to keep allowing SPDX authors to
explicitly say “this situation was confusing, but I've eventually
decided that the license is … based on …”.  And for the really hairy
situations, you can always bail to NOASSERTION [2], folks can still
read about your partial conclusion in the comments.

The ambiguous operator (first floated as “unclear version” in [3]) and
my OR-MAYBE proposal [4] are both attempts to allow an SPDX License
Expression authors to handle those situations they consider too
ambiguous for a complete conclusion, but where they can provide more
structure than NOASSERTION.  The ambiguous and OR-MAYBE operators are
both providing a way to express partial conclusions *without* recourse
to a full SPDX document and its unstructured comment fields.  This may
be useful in general, and David has said he would be satisfied with:

  GPL-2.0 OR-MAYBE GPL-2.0+

most of the time [5].  I still don't have anyone stepping up to say
they'll produce such expressions though [6], and I doubt its worth
writing up a spec for it without someone saying “I (or my tool) wants
to write partially-concluded license expressions but there's no syntax
for it”.  But “nobody has told us they'd write this yet” is a much
narrower rejection than “the proposals are incongruent with the goals
of SPDX”.

> So, I’d like to bring everyone attention back to the original
> proposal (see link above) and if there are any further concerns
> about it, now is the time to raise them.  Meanwhile, Kate and I will
> follow-up with John and Richard at the FSF to better understand
> their concerns as well.

I'm on board with that proposal (especially if it includes the
compatibility metadata mentioned on the wiki page and earlier on this
list in [7]).  And I think it can move ahead independently of any
ambiguous, OR-MAYBE, or PROXY [8] operators.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.41mghml
[2]: https://spdx.org/spdx-specification-21-web-version#h.ihv636
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002230.html
 Subject: reminder: call Thursday
 Date: Wed, 27 Sep 2017 16:49:46 -0600
 Message-Id: <9216ca28-7f42-452a-913f-8bcc0cfe1...@jilayne.com>
[4]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002233.html
 Subject: "unclear version" and OR-MAYBE operators (was: reminder: call 
Thursday)
 Date: Wed, 27 Sep 2017 22:15:23 -0700
 Message-ID: <20170928051523.gn20...@valgrind.tremily.us>
[5]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002235.html
 Subject: RE: "unclear version" and OR-MAYBE operators (was: reminder: call 
Thursday)
 Date: Thu, 28 Sep 2017 16:43:46 +
 Message-ID: <33f120c1096a4cada022389754cd4...@exch13-m1.ida.org>
[6]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002238.html
 Subject: Re: "unclear version" and OR-MAYBE operators
 Date: Thu, 28 Sep 2017 11:22:27 -0700
 Message-ID: <20170928182227.gp20...@valgrind.tremily.us>
[7]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002126.html

 
 Subject: Re: minutes, summary, next steps  

 
 Date: Thu, 17 Aug 2017 14:37:22 -0700  

 
 Message-ID: <20170817213722.gk23...@valgrind.tremily.us>   

 
[8]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002110.html
 Subject: Re: joint call legal/tech team - Tuesday, Aug 8   

  
 

Re: Meeting times and daylight savings

[W. Trevor King]

On Thu, Sep 28, 2017 at 10:48:17PM -0700, W. Trevor King wrote:
> On Thu, Sep 28, 2017 at 11:29:41PM -0600, J Lovejoy wrote:
> > What do you need to make this happen - a new repo in the SPDX
> > Github account to store the ICS file(s)?  Name for such repo?
> 
> We could do that, and if we did, something like ‘meta’ might be a
> good name.  But this is going to be a tiny thing that is rarely
> touched.  It might be better to just put it in spdx-spec (as our
> flagship repo), along with a link from [1].

Where the file lives doesn't matter much to me, so I just went ahead
and worked up [1].  If you want this to land in a different location,
just point me at it and I'll open a PR against the alternative
repository.  The only things that would need to change are the URL
entries [2,3].

Is there still an outreach team [4]?  If so, they're a ways behind on
their minutes [5] ;).

Cheers,
Trevor

[1]: https://github.com/spdx/spdx-spec/pull/42
[2]: 
https://github.com/spdx/spdx-spec/pull/42/files#diff-8d82896d19452d9683ef694c1b7642d8R35
[3]: https://tools.ietf.org/html/rfc5545#section-3.8.4.6
[4]: https://wiki.spdx.org/view/Outreach_Team
[5]: https://wiki.spdx.org/view/Business_Team/Minutes

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

Meeting times and daylight savings (was: reminder: call Thursday)

[W. Trevor King]

On Wed, Sep 27, 2017 at 04:49:46PM -0600, J Lovejoy wrote:
> This is a reminder for our call tomorrow (Thursday) at the usual
> time: https://wiki.spdx.org/view/Legal_Team

With the first Sunday in November [1] in the not terribly-distant
future, I was curious about how that page's:

  … every other Thursday at 18:00 GMT (10:00AM PT, 11:00 MT, 12:00 CT,
  1:00PM ET)

works with DST transitions, since the 10am PDT meeting today was
actually at 17:00 UTC.  Searching through the list archives turned up
[2], which also suggests the meetings are pinned to PT instead of UTC.
A more accurate description might be:

  … every other Thursday at 10:00 am Pacific Time, (11am MT, noon CT,
  1pm ET, either 18:00 or 19:00 UTC depending on US DST).

Although if the intention is really to pin to UTC, it would be:

  … every other Thursday at 17:00 UTC (9am PST, 10am PDT/MST, 11am
  MDT/CST, noon CDT/EST, 1pm EDT).

There is similar nominally-UTC-pinned wording in [3,4], and possibly
in other places on the list.  I think we want to use consistent
language that addresses DST in all of those places so folks can
clearly tell if the meetings track US DST or not.

To avoid ambiguity and make consuming this information easier, can we
publish an iCalendar [5] file somewhere which folks can import into
whichever calendar software they use?  The Opencontainers folks do
this for their Pacific-pinned meetings [6], and being able to see
those on my phone is nice :).  I'm happy to contribute to managing the
iCalendar manually in GitHub (like [6], which you can import from
[7]).  But I expect most calendar apps have a way to export *.ics, so
if an SPDX admin want to setup a calendar and just post exports at a
public URL, that would be fine too.  For example, here are
instructions for exporting *.ics from Google Calendar [8].

Cheers,
Trevor

[1]: https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
[2]: https://lists.spdx.org/pipermail/spdx/2015-March/000960.html
 Subject: Rescheduling important SPDX General Meeting
 Date: Wed Mar 4 20:01:10 UTC 2015
[3]: https://wiki.spdx.org/view/General_Meeting
[4]: https://wiki.spdx.org/view/Technical_Team
[5]: https://tools.ietf.org/html/rfc5545
[6]: https://github.com/opencontainers/runtime-spec/blob/master/meeting.ics
[7]: 
https://raw.githubusercontent.com/opencontainers/runtime-spec/master/meeting.ics
[8]: https://support.google.com/calendar/answer/37648?hl=en

-- 
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: "unclear version" and OR-MAYBE operators

[W. Trevor King]

On Thu, Sep 28, 2017 at 04:43:46PM +, Wheeler, David A wrote:
> 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).

Right.  The information you're trying to transmit are the hints.  But
you haven't concluded a single, specific license expression.

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

Yeah, that's a situation where a partial conclusion (e.g. narrowing
down to a handful of possible license expressions) is useful.  And
that means at least you are happy to *consume* some
partially-concluded license expressions.

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

Yeah, I'd be interested in hearing more opinions on it.

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

I like OR-MAYBE (or whatever we call it) if folks want a way to
express partial conclusions in license expressions.  As was discussed
on the call today (and several times before, on the list and
elsewhere), in an SPDX file you can conclude NOASSERTION and then add
freeform comments describing your partial conclusion.  Having a way to
express partial conclusions in an SDPX identifier may be useful for
tools like Licensee [1], although those tool might also be ok just
jumping to a complete conclusion.

You've said that in some cases you'd rather consume these partial
conclusions instead of having to deal with missing conclusions.  But
I'm not aware of anyone who would be expressing partial conclusions in
a stand-alone license expression.  Can somebody point to a project (or
human license expression author) that is looking for this
functionality?  There's not much point in a spec with consumers but no
producers ;).

Cheers,
Trevor

[1]: https://github.com/benbalter/licensee

-- 
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: [v2] New license proposal: GPLVerbatim (was: GNUVerbatim)

[W. Trevor King]

On Wed, Sep 27, 2017 at 11:30:21PM -0400, John Sullivan wrote:
> Wary of confusion here. There is a license called the GNU Verbatim
> Copying License, see:
> 
> 
> Its text is: "Verbatim copying and distribution of this entire article
> are permitted worldwide, without royalty, in any medium, provided this
> notice is preserved."

Ah.  I'd only seen that text under the ‘VerbatimCopying’ tag in [1].

> The notice you are pointing to in your footnotes is: "Everyone is
> permitted to copy and distribute verbatim copies of this license
> document, but changing it is not allowed."

Yeah, which is different (as discussed in my initial post to this
thread).  With the FSF already using both VerbatimCopying and
GNUVerbatim for [1], perhaps GPLVerbatim would be a better choice for
“Everyone is permitted to copy…”.

Cheers,
Trevor

[1]: https://www.gnu.org/licenses/licenses.html#VerbatimCopying

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

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

[W. Trevor King]

On Wed, Sep 27, 2017 at 04:49:46PM -0600, J Lovejoy wrote:
> Kate and I have discussed our last proposal (which was summarized
> here: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal)
> with Richard Stallman and John Sullivan as to concerns the FSF, as
> steward of the GNU licenses, had with that and how to mitigate.

Does this mean we now have an official position on what the FSF for
the concluded license of the “1 license file with GPL-2.0 license
text; 4 source files with no license information whatsoever” case [1]?
My impression from the rest of your message is that it is:

  GPL-2.0 unclear version

(or whatever that operator ends up being named).  That means that they
would consider GPL-1.0+ to be an invalid interpretation, although
GPL-1.0+ was at least floated as a possible interpretation in the
2017-08-08 meeting (among many other possible interpretations ;).

> There are two sets listed: one that involves a single character (to
> be consistent with existing +) and one that is more human-readable:

I'm personally in favor of grandfathering in +, but using separate,
single-word identifiers for any new operators.

> ? = “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…”.
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, 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

if you didn't feel comfortable enough to conclude LGPL-2.0 based
solely on the presence of the usual COPYING and COPYING.LESSER pair
[5].

> # = "only" - this will be a new modifier to indicate ‘this version
> only’.  Need further input as to one character configuration, if
> needed

I really hope we don't get a single-character version of this
operator, but if we do, I think it should be ‘=’.

> I think this will provide a better path for backwards compatibility
> and moving people using old versions SPDX to use the current
> version, as use of GPL-2.0 when validated against the current
> version will get a warning - thus allowing visibility and
> (hopefully) encouraging adoption of current version/use of modifiers
> as per above.

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.

> Also, I think it will also prevent the need to make any kind of
> interpretation of other licenses with or later clauses, as it allows
> SPDX uses to use the modifiers as they see fit (or not) for such
> licenses.

Whatever versioning we decide to require for the GPL family, I think
we want to require the same versioning for the CDDL family.  The CDDL
also allows a grant-time choice between + and ONLY, and the only
difference from the GPL is that the CDDL requires grant wording to
choose ONLY [9], while the GPL requires you to specify a version to
avoid GPL-1.0+ [10] and for grants specifying a version to include
“any later version” to choose + [11].  If you actually have a
license-grant blurb to look at, it will be pretty obvious whether the
CDDL ONLY or GPL+ language was included.  If you have no license grant
blurb you're still welcome to guess, but things become much more
murky.

Cheers,
Trevor

[1]: 
https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Examples_.2F_Challenges
[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002211.html
 Subject: RE: License identifiers sufficient to avoid loss of
   information in DeclaredLicense (was: GPLv2 - Github example)
 Date: Fri, 15 Sep 2017 12:01:32 +
 Message-ID: 
<27e3b830fa35c7429a77daeedeb7344770e82...@irsmsx103.ger.corp.intel.com>
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002213.html
 Subject: RE: License identifiers 

Git's COPYING preface (was: [v2] New license proposal: GNUVerbatim)

[W. Trevor King]

On Wed, Sep 27, 2017 at 02:26:10PM -0500, Kate Stewart wrote:
> On Wed, Sep 27, 2017 at 2:15 PM, W. Trevor King wrote:
> > I have a repository that contains two files with content under the
> > GNUVerbatim license [1,2] (as well as some content by Linus,
> > presumably under the GPL-2.0 or a later version at the discretion
> > of Linus) [3].  I'd like to track the licensing information for
> > those files/snippets without using LicenseRef-*.  Is that a
> > use-case the SPDX wants to enable or not?
> 
> The legal team reviewed and approved "Linux-syscall-note" to be used
> "WITH" licenses, that should be able to handle the kernel case.  ie.
> 
> SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note

The syscall note is from the kernel [1] (“NOTE! This copyright does
*not* cover user programs…”).  The extra information in my repository
is originally from Git [2] (“Note that the only valid version of the
GPL as far as this project is concerned…).  It's basically suggested
wording for “GPL-2.0 OR GPL-3.0+ PROXY "Linus Torvalds"” declarations
if authors want to declare that.  An example of that declaration in
the wild is in [3].  As far as I known, none of the content in my
signed-off-by repository falls under it, although obviously Linus is
free to offer any of his content (some of which is in signed-off-by)
under whichever licenses he wants without needing an explicit PROXY
declaration.

Cheers,
Trevor

p.s. In the above, I've used the PROXY syntax which I'd floated in
[4].  That's not a legal license expression (yet?), and I'm holding
off on further pushing in that direction until the ONLY operator lands
in the spec (which may be never, who knows).  But hopefully the idea
is clear even without a formal doc for PROXY ;).

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/COPYING?h=v4.13.4#n2
[2]: https://github.com/git/git/blob/v2.14.2/COPYING#L2-L18
[3]: https://github.com/git/git/blob/v2.14.2/git-request-pull.sh#L4-L5
[4]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002110.html
 Subject: Re: joint call legal/tech team - Tuesday, Aug 8   

  
 Date: Fri, 04 Aug 2017 17:03:26 -0700  

  
 Message-ID: <20170805000326.gw23...@valgrind.tremily.us>

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

[v2] New license proposal: GNUVerbatim

[W. Trevor King]

Discussion spawned by my v1 Verbatim proposal [1] seems to have died
down, so here's a v2.  Changes since v1:

* Renamed from ‘Verbatim’ to ‘GNUVerbatim’ to allow for other verbatim
  names in the future (e.g. if someone wants to register [2] as
  GNUVerbatimWeb [3] or wants to register non-GNU verbatim license).
* Suggested  tags to match the wording used by the GNU CC General
  Public License [4,5] or non-license documents.

# Motivation

The GPL family of licenses (e.g. [6]) and some other documents
(e.g. [7]) are licensed under a verbatim license (canonical text
attached).  The GNU CC General Public License (1988) was also released
under very similar language [4].  I propose we add this license with
markup like:

  …copies of this license document, but …

so we can express all of those closely related licenses with the
GNUVerbatim short ID without resorting to custom LicenseRef-*.

# Scope

I believe [2] is sufficiently different, e.g. mentioning royalties and
medium.  If/when it gets an SPDX ID, I think that ID should be
distinct from the one I'm proposing here.

In my v1 proposal [1], I'd also floated adding a field to our license
XML to express the license which applies to the license itself, as
concluded by the SPDX legal team.  That opened up significant
subsequent discussion, which was interesting, but fairly tangential to
this proposal.  I'd like to keep the v2 discussion focused on whether
we want a GNUVerbatim entry in the SPDX license list, and we can
circle back around and decide whether we want to use that identifier
ourselves in follow-up work.

# Registration metadata

Proposed full name: GNU Verbatim License
Proposed short identifier: GNUVerbatim
OSI approved: no (and it clearly does not support the OSI's derived
  works condition [8]).

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002156.html
 Subject: New license proposal: Verbatim
 Date: Thu, 7 Sep 2017 12:21:43 -0700
 Message-ID: <20170907192143.gw4...@valgrind.tremily.us>
[2]: https://www.gnu.org/licenses/licenses.html#VerbatimCopying
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002189.html
 Subject: Re: New license proposal: Verbatim
 Date: Tue, 12 Sep 2017 11:42:31 -0700
 Message-ID: <20170912184231.gk30...@valgrind.tremily.us>
[4]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002158.html
 Subject: Re: New license proposal: Verbatim
 Date: Thu, 7 Sep 2017 16:41:23 -0400
 Message-ID: <20170907204122.GA31923@clifford>
[5]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002160.html
 Subject: Re: New license proposal: Verbatim
 Date: Thu, 7 Sep 2017 15:43:59 -0700
 Message-ID: <20170907224359.gz4...@valgrind.tremily.us>
[6]: 
https://github.com/spdx/license-list-XML/blob/f3dc56f2424e8e93732f655637e0542c5557588c/src/GPL-2.0.xml#L29-L30
[7]: https://developercertificate.org/
[8]: https://opensource.org/osd#derived-works

-- 
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
Everyone is permitted to copy and distribute verbatim copies of this license 
document, but changing it is not allowed.


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

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

[W. Trevor King]

On Fri, Sep 15, 2017 at 06:02:00AM +, Gisi, Mark wrote:
> How does one define “accurate and complete” when a package’s “top
> level” license does not represent all the files contained within the
> package (think license diversity).  Although there was no standard
> agreement on what “accurate and complete” meant, I got the strong
> impression looking at the customer’s spreadsheet that a package’s
> top level license was not enough.

If you're going to look through the package an conclude licenses for
each file (a good idea when you need this level of detail), then
you'll have declared/concluded licenses for each file (or parts of
files, if you use snippets).  Once you've collected that, an “accurate
and complete” license for the package would be the AND-ed combination
of all the file/snippet licenses.

However, in many cases there will be content in those packages that is
not ending up in the final device (e.g. documentation, some license
files, project management and policy information, …) that someone
shipping a device does not care about.  Those file/snippet licenses
won't matter to them (unless they are interested in pushing doc
patches back upstream, or some such).

So I'd recommend just providing those customers with file/snippet
granularity and find a workflow that does not bother with “package
licenses”.

If they can't support that level of granularity, ask them to provide
you with a list of files/snippets they care about and only AND their
licenses to conclude a selected-project-subset license.

If they can't provide a list of files/snippets they care about and can
only accept conclusions at the package level, then they're going to
get things like “GPL-3.0 AND Verbatim” for a package that includes
GPL-3.0 code and the text of the GPL 3.0.  But the Verbatim license
contains no onerous conditions for someone shipping devices, so they
probably won't mind.

> There are obviously other types of open source users who do not
> share the same compliance challenges as Stakeholder #1. Consider
> businesses that provides Software as a Service (SaaS) where the lion
> share of the open source runs in the data center as opposed to being
> distributed on millions of devices. Think of Facebook, Netflix,
> Airbnb, and Lyft. For SaaS provider’s software distribution is
> typically not a consideration (except perhaps for the apps you
> download onto your phone). The license compliance complexity and
> risk profile for a SaaS provider is very low compared to device
> makers, their need for SPDX file level licensing information tends
> to very low, if at all.

Maybe the risk is lower, but they have the same issue.  For example,
the AGPL-3.0 has explicit requriments for this use case [1].  Where
detailed licensing is expensive, SaaS providers end up cutting
corners.  But if everyone was doing things right, SaaS providers would
have the same audit-trail robustness that you attribute to device
shippers.

> Many of the products you use (or drive) are created by Stakeholder
> #1. If they lack sufficient file level licensing information…

And nobody is arguing for removing file/snippet granularity (just like
nobody is arguing for removing LicenseRef [2]).  So what problems does
SPDX not address for either of these use cases?

Cheers,
Trevor

[1]: 
https://github.com/spdx/license-list-XML/blob/f1522b5cc61bde64d9b38af05204fdb93c02eef8/src/AGPL-3.0.xml#L480-L494
[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002184.html
 Subject: Re: GPLv2 - Github example
 Date: Tue, 12 Sep 2017 09:45:38 -0700
 Message-ID: <20170912164538.gg30...@valgrind.tremily.us>

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

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

[W. Trevor King]

On Fri, Sep 15, 2017 at 01:10:44PM -0400, Wayne Beaton wrote:
> Exhibit A - Form of Secondary Licenses Notice
> 
> "This Source Code may also be made available under the following 
> Secondary Licenses when the conditions for such availability set forth 
> in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
> version(s), and exceptions or additional permissions here}."

This seems like the new version.  The OSI still hasn't published their
approved text [1], although they were originally considering the “This
Source Code is also Distributed under” wording [2] and that's what
they approved [3].  The text change is under OCI discussion in [4],
but that just started yesterday.  We probably want to wait and see how
the change shakes out in the OSI before stamping an ID for the final
text.

Cheers,
Trevor

[1]: https://opensource.org/licenses/alphabetical
[2]: https://lists.opensource.org/pipermail/license-review/2017-June/003048.html
 Subject: [License-review] For Approval: Eclipse Public LIcense version 2.0
 Date: Thu Jun 15 19:50:51 UTC 2017
[3]: 
https://lists.opensource.org/pipermail/license-review/2017-August/003074.html
 Subject: [License-review] For Approval: Eclipse Public LIcense version 2.0
 Date: Thu Aug 10 17:11:18 UTC 2017
[4]: 
https://lists.opensource.org/pipermail/license-review/2017-September/003082.html
 Subject: [License-review] New Exhibit A for EPLv2
 Date: Thu Sep 14 21:11:06 UTC 2017

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


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

[W. Trevor King]

On Fri, Sep 15, 2017 at 11:19:04AM +, Gisi, Mark wrote:
> >> 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

I don't consider the presence of a license file to be a declaration of
package license [1].  A package which includes those files might
declare (in a README, or package.json, etc.) that it is:

  LGPL-2.0

Or it might contain a LGPL-2.0 library and a GPL-2.0 tool which
consumes that libary, and declare somewhere else that it is:

  LGPL-2.0 AND GPL-2.0

Or maybe they've decided to allow downstream consumers to choose to
fork off more-viral projects and dual licensed:

  LGPL-2.0 OR GPL-2.0

Without an explicit package license declaration (in a README,
package.json, etc.) the declared package license is NOASSERTION.  If
you can tell consumers “The author wasn't clear, but I've concluded
that this package is ‘LGPL-2.0 AND GPL-2.0’”, that's useful
information.  If you can tell consumers “I haven't checked, but the
package author claims this is ‘LGPL-2.0 AND GPL-2.0’” that's useful
information.  If all you can tell consumers is “I found text for the
LGPL-2.0 and GPL-2.0 licenses but haven't concluded anything” that is
less useful.

Licensee, which only looks for stand-alone license files [2], at least
attempts to avoid concluding a license when it finds multiple licence
files [3] although it has a special case for the LGPL family, since
that license is usually split over two files [4].  And that sort of
heuristic is fine for calculating the concluded licenses, especially
when the results come with big as-is caveat [5].  They're not saying
that the presence of the license files constitutes a license
*declaration*.

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002205.html
 Subject: Re: License identifiers sufficient to avoid loss of
   information in DeclaredLicense (was: GPLv2 - Github example)
 Date: Thu, 14 Sep 2017 13:10:36 -0700
 Message-ID: <20170914201036.gd30...@valgrind.tremily.us>
[2]: https://github.com/benbalter/licensee/blob/v9.2.1/docs/what-we-look-at.md
[3]: https://github.com/benbalter/licensee/issues/114
[4]: https://github.com/benbalter/licensee/pull/203
[5]: https://developer.github.com/v3/licenses/

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

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

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

Re: meeting tomorrow, general update

[W. Trevor King]

On Thu, Sep 14, 2017 at 02:36:01PM -0400, Richard Fontana wrote:
> Note that the EPL-2.0 text, at the canonical eclipse.org URL, and
> specifically Exhibit A, has been changed since this was first
> discussed on spdx-legal…

Unversioned license changes… exciting :p.  I also see that the initial
post to spdx-legal@ [1] didn't include the license text as an
attachment (part of the official submission policy [2]), which makes
it hard to ensure that everyone is talking about the same thing.
Comparing the current content of [3] with [4], the differences are:

  $ diff -u EPL-2.0-GitHub EPL-2.0-canonical
  --- EPL-2.0-GitHub 2017-08-21 19:58:57.0 -0700
  +++ EPL-2.0-canonical  2017-09-06 12:03:33.0 -0700
  @@ -261,10 +261,10 @@

   Exhibit A - Form of Secondary Licenses Notice

  -"This Source Code is also Distributed under one
  -or more Secondary Licenses, as those terms are defined by
  -the Eclipse Public License, v. 2.0: {name license(s),version(s),
  -and exceptions or additional permissions here}."
  +"This Source Code may also be made available under the following
  +Secondary Licenses when the conditions for such availability set forth
  +in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
  +version(s), and exceptions or additional permissions here}."

 Simply including a copy of this Agreement, including this Exhibit A
 is not sufficient to license the Source Code under Secondary Licenses.

and a lack of a trailing newline in [3].

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002134.html
 Subject: New License/Exception Request: EPL-2.0
 Date: Mon, 21 Aug 2017 20:52:44 -0400
 Message-ID: 

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

[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

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

[W. Trevor King]

On Wed, Sep 13, 2017 at 11:07:52AM -0400, Richard Fontana wrote:
> The other SPDX is the use of something that *superficially* looks
> like SPDX-conformant license expressions to describe licensing in a
> way that is, I guess, outside the intended scope of SPDX. Examples
> of this nonconformant use of SPDX license expressions include
> developers annotating the licensing of their own software as well as
> distributors annotating the licensing of things they distribute.

That's officially supported by the spec with Appendix V (Using SPDX
short identifiers in Source Files [1], new in 2.1 [2]).

> In particular I would assert that these two uses of SPDX are
> fundamentally in conflict.

Can you go into more details about the conflict you see?  License
expressions seem like they're designed to express the license of a
(possibly combined) work, including the declared license of a package
[3] or file [4].  Both of those fields take license-expression values,
with additional ‘NONE’ and ‘NOASSERTION’.  That sounds like the exact
same use case to me as the SPDX-License-Identifier use case (which
also takes license-expression values [1]), with the differnce being
that an SPDX-License-Identifier entry in the file is the file author
declaring the license, and the PackageLicenseDeclared and
LicenseInfoInFile entries in an external SPDX file may have been
written by someone else.  But in both cases, they're trying to express
a declared license for the file.  The npm package.json license field
[5] is just like SPDX-License-Identifier, except it's the author
declaring a package-level license.  All of these use cases need a
compact, machine-readable way to express the license of a work, and
license expressions seem like a good fit for all of them to me.

There is the difficulty that outside of an SPDX file, there's no way
to define custom licenses (LicenseRef-*).  For most projects, the
licenses and exceptions they need are already in the SPDX license
list, so they don't need that functionality.  For projects who need a
license that's not in the SPDX list in a license-expression-only
context, submitting the license for SPDX inclusion is fairly
straightforward.  The only issue with submission is that sometimes the
license is rejected (although I don't have a link I can cite for this)
and sometimes it is judged sufficiently similar with an existing
license (e.g. “and” vs. “and/or” in ISC-ish licenses [6,7]).  But
that's not an insurmountable problem.  We can always add a:

   LicenseURI "${URI}"

operator to license expressions that supports RFC 3986 URIs [8] to
provide folks with a way to reference not-in-the-SPDX-list licenses
(with a similar ExceptionURI for exceptions?).

You're obviously not going to have all the expressive power of a full
SPDX file in the license expression, but if all you're aiming for is
declaring a license, I don't see why you would need more structure
than license expressions.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b
[2]: https://spdx.org/spdx-specification-21-web-version#h.1sh8jn1fc5zw
[3]: https://spdx.org/spdx-specification-21-web-version#h.1hmsyys
[4]: https://spdx.org/spdx-specification-21-web-version#h.111kx3o
[5]: https://docs.npmjs.com/files/package.json#license
[6]:  https://lists.spdx.org/pipermail/spdx-legal/2015-April/001398.html
  Subject: New License/Exception Request
  Date: Thu Apr 30 17:56:52 UTC 2015
[7]: 
https://github.com/spdx/license-list-XML/pull/423/commits/233ae572d9e30cf48bd4c887e9c069626e76a93b
[8]: https://tools.ietf.org/html/rfc3986

-- 
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: New license proposal: Verbatim

[W. Trevor King]

On Tue, Sep 12, 2017 at 05:36:45PM +, Marc Jones wrote:
> Maybe I have missed it in the thread, but what are the terms the
> "Verbatim" license would refer to?

It looks like you may have broken the thread with [1].  It initially
started with [2], which has the formal proposal, including the license
text.  Richard pointed out an earlier flavor of the license [3], so my
current proposal includes an  section [4].

> Nonetheless FSF use to recommend the following "Verbatim Copying and
> Distribution" licensing statement for use with works that express an
> opinion: "Verbatim copying and distribution of this entire article are
> permitted worldwide, without royalty, in any medium, provided this notice
> is preserved." [1]
> …
> [1] https://www.gnu.org/licenses/licenses.html#VerbatimCopying

That's a different license, although the intent looks similar.  I'm
not sure why the FSF does not use that license for their GPL family,
or why the LF decided to use the GPL verbatim language for the DCO
[5].  I'm not clear on how we should namespace those two licenses,
although we probably want them under separate entries.  Maybe
VerbatimGNU for the GPL's verbatim wording and VerbatimGNUWeb for the
text you link?  We can punt on a license identifier for the text you
link for now (I'm not involved in any projects that need it ;), but I
think we should have a guess at how we plan to namespace similar
verbatim licenses in case we want to add identifiers for others in the
future.

> For example Facebook's React project provides the source code for
> the library under a BSD copyright license [2] but the example code
> under a non-FOSS license. [3] And the React documentation is under a
> CC license [4].

And I think documenting that sort of thing is important.

> As I said before though I continue to agree with other commenters that the
> license of the license seems to me to be outside of the scope of SPDX.

I don't see why you'd want to explicitly cover the code, examples, and
docs but *not* cover local license files when working up SPDX for
React.

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002161.html
 Subject: New license proposal: Verbatim
 Date: Fri, 08 Sep 2017 09:28:02 +
 Message-ID: 

[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002156.html
 Subject: New license proposal: Verbatim
 Date: Thu, 7 Sep 2017 12:21:43 -0700
 Message-ID: <20170907192143.gw4...@valgrind.tremily.us>
[3]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002158.html
 Subject: Re: New license proposal: Verbatim
 Date: Thu, 7 Sep 2017 16:41:23 -0400
 Message-ID: <20170907204122.GA31923@clifford>
[4]: https://lists.spdx.org/pipermail/spdx-legal/2017-September/002160.html
 Subject: Re: New license proposal: Verbatim
 Date: Thu, 7 Sep 2017 15:43:59 -0700
 Message-ID: <20170907224359.gz4...@valgrind.tremily.us>
[5]: https://developercertificate.org/

-- 
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: New license proposal: Verbatim

[W. Trevor King]

On Tue, Sep 12, 2017 at 04:38:57PM +, Andrew Katz wrote:
> My recollection is that Apache 2.0 is under Apache 2.0, also.

All explicitly-licensed licenses are going to eventually end up in
some sort of loop like this (although you could have an A → B → A…
cycle, etc.).  Doesn't it seem like we'd want to record that
information?  For licenses that are not explicitly licensed, the right
to distribute and/or modify them is going to be based on fair use,
estoppel, etc.  I'm not sure we have a way to represent that in SPDX
license expressions.

However, regardless of whether we decide to record the license for
each of our licenses, I think adding a Verbatim license to the license
list is a useful addition.  That would allow other SPDX authors/tools
to record the license of Verbatim content if *they* wanted to give the
terms under which their Verbatim license content [1] or DCO copies
[2,3] were distributed.  Then SPDX can, like other SPDX authors/tools,
decide where it wants to apply the Verbatim license without relying on
a LicenseRef.

Cheers,
Trevor

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING?h=v4.13#n17
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n429
[3]: https://developercertificate.org/

-- 
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: GPLv2 - Github example

[W. Trevor King]

On Tue, Sep 12, 2017 at 02:52:26PM +, Wheeler, David A wrote:
> Mark Gisi:
> > 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.

Agreed.  I don't think anyone is arguing for removing LicenseRef.  A
new ‘only’ operator allows you to express ‘CDDL-1.0 only’ as a vanilla
license expression where you currently need to use a LicenseRef, but
there are obviously lots of other LicenseRef use cases that an ‘only’
operator will not replace.

> > 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.  Package-level results are the WHOLE POINT.

I don't know if I'd go as far as that; being able to drill down to
find the license for a particular file or snippet is useful too.  But
I certainly don't see a reason why license expressions would not work
fine for projects given that they work fine for files; projects are
just collections of files.  Similarly, files are collections of
snippets.  SPDX license expressions can (and do?) allow to you state
the license terms of any work, regardless of whether that work is a
snippet, file, project, distro, ….  What the ‘only’ operator is about
is making vanilla license expressions (which do not reference custom
LicenseRefs and such) more expressive.  That will help folks who are
restricted to vanilla license expressions, regardless of what they
happen to be licensing.

Cheers,
Trevor

-- 
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: GPLv2 - Github example

[W. Trevor King]

On Mon, Sep 11, 2017 at 08:26:56PM +, Gisi, Mark wrote:
> >> 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
>
> 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.

Perhaps, but having an explicit ‘only’ is a cheap way to avoid a
LicenseRef in cases like ‘CDDL-1.0 only’.  Inlining LicenseRefs in
license expressions (or talking external projects like npm into using
the full SPDX spec) are both much larger changes.  And…

> In the above example you don't need an "only" operator…

You *do* need this if you want separate license expressions for “I
just found the GPL-2.0 text in a separate file, but am not clear on
the intended grant” (GPL-2.0) and “this file is GPL-2.0 only” (GPL-2.0
only).  There's no way to address that with LicenseRef.  You might be
able to cover that distinction with PackageLicenseComments [1], but
that's not structured.  So I see two use cases that a structured ‘only’ 
operator allows:

a. ‘GPL-2.0 only’ is a fairly common license, so having a structured
   way to declare it seems useful to me (and it's nice to have that
   structured way be obvious from the license expression).

b. Tools that do not look at grants (e.g. licensee, as I linked
   earlier) are also deployed in high-visibility areas (e.g. GitHub's
   auto-detected license API [2]), so having a structured way for them
   to *not* claim “only” vs. “or later” seems useful to me too.

Do you believe that one or the other of those cases are not worth
supporting?  Or do you want to support both, but you prefer a
different approach than an ‘only’ operator?

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.41mghml
[2]: https://developer.github.com/v3/licenses/

-- 
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: GPLv2 - Github example

[W. Trevor King]

On Mon, Sep 11, 2017 at 07:04:57PM +, Gisi, Mark wrote:

> >> With the ‘only’ operator proposal [1], this situation can be
> >> represented by ‘CDDL-1.0 only’.
> 
> … Finally this case can be elegantly handled with a LicenseRef…

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.

> That is, the example represents a rare edge case that does not
> present a situation that can't be express with today's current
> constructs. Therefore it does not represent a good example
> (justification) for adding the "only" operator.

It's not the only justification.  Having an ‘only’ operator also lets
you give a very clear license expression (e.g. ‘GPL-2.0 only’) for
grants like:

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License version 2 as
  published by the Free Software Foundation.

which is one of the goals listed in [2].

That's a distinct license expression from ‘GPL-2.0’ for cases like “I
found this license text in a separate file, but no clear grant
applying it to this project” which is the “GitHub example” that
spawned this thread.  Although as discussed in this thread, some SPDX
authors and tools may feel uncomfortable making a concluded-license
call in that case.  However, I expect tools like licensee, which only
look for stand-alone license files and ignore grant comments [3], will
be concluding ‘GPL-2.0’ and similar, and having an explicit ‘only’
operator allows consumers to distinguish those ambiguous conclusions
from an explicit ‘GPL-2.0+’ or ‘GPL-2.0 only’.

Cheers,
Trevor

[1]: https://docs.npmjs.com/files/package.json#license
[2]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal#Goals
[3]: 
https://github.com/benbalter/licensee/blob/v9.2.0/docs/what-we-look-at.md#what-about-checking-every-single-file-for-a-copyright-header

-- 
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: GPLv2 - Github example

[W. Trevor King]

On Mon, Sep 11, 2017 at 03:40:05PM +, Gisi, Mark wrote:
> I know that the following CDDL was discussed with respect to the
> “only” problem:
>
> * This file and its contents are supplied under the terms of the
> * Common Development and Distribution License ("CDDL"), version 1.0.
> * You may only use this file in accordance with the terms of version
> * 1.0 of the CDDL.
>
> But this is handle by the LicenseRef construct (e.g.,
> LicenseRef-CDDL-1.0-only).  Because this is not a common use of the
> CDDL-1.0, I prefer to encourage the software recipient/customer take
> an additional look which is achieved by the use of a LicenseRef.

With the ‘only’ operator proposal [1], this situation can be
represented by ‘CDDL-1.0 only’.  There will no longer be a need for
LicenseRef for that case, which is nice for folks looking to represent
that license grant using only a vanilla licence expression.

Cheers,
Trevor

[1]: https://wiki.spdx.org/view/Legal_Team/only-operator-proposal

-- 
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: New license proposal: Verbatim

[W. Trevor King]

On Fri, Sep 08, 2017 at 09:28:02AM +, Marc Jones wrote:
> It is not clear to me that it makes sense to say a code base is both
> GPLv2 and verbatim, simply because the text of the license is
> copyrighted and you do not have permission to modify the license
> text.

So let's replace “license” with “documentation”.  You generally get
both alongside the source code in a package tarball.  And many
programs compile to executables or libraries that include neither the
license nor documentation content.  Are you suggesting that the
license of the documentation (which may differ from the source,
e.g. GFDL docs with GPL source) does not impact the concluded package
license?

> I don't actually think it is much different from the 3-Clause BSD
> license regardless of if the 3-clause BSD license is in the public
> domain. It seems to me that even if the 3-Clause license is in the
> public domain, you still do not have permission to modify it in a code
> base licensed under the 3-clause BSD license.

But you *would* have permission to copy/paste just the BSD-3-Clause
wording, make your own edits, and distribute the result.  The SPDX way
of representing a file containing different sections under different
licenses is via snippets [1], although by the time you're marking out
BSD-3-Clause blurbs as Verbatim snippets (or whatever), I think you're
past the point of diminishing returns.  But for licenses that usually
live in a separate file (like the GPL), having a Verbatim license
seems like a useful addition.

> > For license where we do not feel comfortable concluding a license,
> > we probably want to stop distributing local copies until we figure
> > out what license applies to them (or whether we think they are not
> > copyrighted, or if our complete copy of their text falls under
> > fair use, or whatever).
> 
> The problem with not including local copies of licenses is that
> including a local copy of licenses is actually a condition of a lot
> of licenses. So essentially one would have to say that unless the
> copyright status of the license text is clear, we can not use SPDX
> with that license.

Right.  But if you're comfortable saying “we're at least allowed to
distribute verbatim copies of these because… estoppel… mumble mumble”,
then you can go ahead distributing them even without an explicit
license.  That's not as nice as having an explicit license, clear
copyright status, etc., but it's probably good enough.

> What value is added if we simply end up tacking onto every SPDX
> license code "+Verbatim."

You get a more accurate view of the licenses covering the included
content.  Maybe the Verbatim part ends up being a part that you care
about, and maybe it doesn't.  Like all composites, it will depend on
which content you're interested in.  If we are sure that nobody will
ever be interested in the license of a license, then we should call
that out in the spec (and there's already an ‘excludes’ bit in the
spec for when you want to do this sort of thing with file
granularity).  But I'm not sure that's the case.  And I'm really not
sure that nobody ever cares about the license that the documentation
comes under.  And sometimes distinguishing between “code” and
“documenation” is tricky (although I expect it's easier to distinguish
“license text” from the other two).

On Fri, Sep 08, 2017 at 03:44:52PM +, Wheeler, David A wrote:
> I think the point of SPDX is to enable people to understand the
> licenses of the software being used (or under consideration).

Do you place documentation inside or outside your “software” box?
What about code snippets in that documentation?  What about comments
in code (which are in the source files, but don't end up in the
compiled executable for compiled languages)?  I'd rather dodge all of
that and give users the tools they need to express the license of all
of their content.  Then the individual SPDX authors and tools can
decide how detailed they want to be.

On Fri, Sep 08, 2017 at 11:54:52AM -0400, Brad Edmondson wrote:
> It's my understanding that there are varying opinions on the
> question of the copyrightability of a license text (or any legal
> contract). I tend to think no license text is protectable under
> copyright…

I expect the FSF folks disagree with you, or they wouldn't have a
copyright claim and Verbatim license inlined in their licenses.  Is
the official SPDX position going to be that licenses aren't
copyrightable?  Or will we have a Verbatim license so folks who want
can use it, and folks who don't feel like licenses are copyrightable
can conclude ‘NONE’ (or whatever you're supposed to use for “not
copyrightable” for the license file [3] or snippet [4].  I'd rather
punt that call to individual SPDX authors and tools.

> … but even assuming *arguendo* that it is protectable, recall that
> copyright protection is "thin" (as opposed to "thick" protection in
> patent or, less so, trade secret) and doesn't bar *all*
> copying/distributing/etc.

This is 

Re: New license proposal: Verbatim

[W. Trevor King]

On Thu, Sep 07, 2017 at 04:41:23PM -0400, Richard Fontana wrote:
> Out of curiosity I searched a bit just now and found in the earliest
> extant GCC release, apparently from 1988, the license (GNU CC General
> Public License) has this slightly different meta-license:
> 
> Copyright (C) 1987 Richard M. Stallman
>  Everyone is permitted to copy and distribute verbatim copies
>  of this license, but changing it is not allowed.

So we probably want to use:

  …copies of this license
  document, but …

> IHTBTG but ... if you want to go down this path, do you want to
> consider such things as, say, the fact that the vast majority of the
> other license texts recognized by SPDX have no explicit metalicense?

In that case, how are we allowed to share copies of their text via
license-list-XML repository [1], our published license list [2], etc.?
If the material is copyrightable (seems likely for most of the
licenses we carry), we need some justification for that.  In most
cases, I expect something like the Verbatim license is implicit as
part of somebody (often the license author?) submitting the license to
us for inclusion.  In those cases we can conclude a Verbatim license
and move on.

For license where we do not feel comfortable concluding a license, we
probably want to stop distributing local copies until we figure out
what license applies to them (or whether we think they are not
copyrighted, or if our complete copy of their text falls under fair
use, or whatever).

On Thu, Sep 07, 2017 at 02:47:16PM -0600, J Lovejoy wrote:
> 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 - at the project level and the file level, as
> appropriate (or both) and I was using the file-level breakdown to
> illustrate the challenging (but acknowledged as potentially common)
> scenario where there is the license text and then no further
> information.

I agree that the license of the GPL-2.0 text has only a limited impact
on the project license.  Although if a project with only GPL-2.0+ code
includes a local copy of the GPL-2.0, I think the accurate SPDX
identifier for a tarball containing the whole package would be
‘GPL-2.0+ AND Verbatim’.  Compiled output, installed packages, etc.,
which don't include the full GPL-2.0 text would just be GPL-2.0+.

> In any case, I’m not sure we need to worry so much about identifying
> the license of the license.

Why not?  They're generally copyrightable content that we copy and
distribute, just like code.

> If we made a new identifier for the purposes here, as you suggest,
> where would the leave MIT, BSD-3-Clause, etc.?

Good question.  Wikipedia claims BSD-3-Clause is in the public domain
[3], although I'm not clear on their reasoning for that.  For other
licenses, I'm not sure who owns copyright on them or whether they're
creative enough (vs. prior art?) to be copyrightable.  Since many,
many people have copied them verbatim, distributed those copies, and
not been sued, I expect we at least have the “distribute verbatim
copies” permission (possibly via some estoppel thing, but I'm not a
lawyer).  I'm not clear on whether I'm allowed to tweak their wording
or not.

> We want scanners to be able to identify the exact license text where
> it exists for what it actually is - that is the key piece of
> information for determining the license for the code. If we start to
> boil down to the license of the license, we seem to be missing the
> key goal?

I don't think so.  If I get a tarball for a package, I want to know
the licensing information for the contents of that tarball.  If some
of the content in that tarball is GPL-2.0+ (e.g. main.c), I want to
know that.  If some of the content in that tarball is Verbatim
(e.g. COPYING), I want to know that too.

Cheers,
Trevor

[1]: http://github.com/spdx/license-list-XML
[2]: https://spdx.org/licenses/
[3]: 
https://en.wikipedia.org/wiki/BSD_licenses#3-clause_license_.28.22BSD_License_2.0.22.2C_.22Revised_BSD_License.22.2C_.22New_BSD_License.22.2C_or_.22Modified_BSD_License.22.29

-- 
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: New license proposal: Verbatim

[W. Trevor King]

On Thu, Sep 07, 2017 at 12:21:43PM -0700, W. Trevor King wrote:
> There are also other works under that license, e.g. [4], which use the
> exact same language.
> 
>   Everyone is permitted to copy and distribute verbatim copies of this
>   license document, but changing it is not allowed.
> …
> [4]: https://developercertificate.org/

Looking over this again, I was somewhat surprised that
developercertificate.org used “this license document” is a
certification and/or grant and not really a license.  If this gets
added to our official license list, I recommend making “license”
optional in the adopted form, so folks could cleanly use it for
non-licenses as well.  Using our current XML syntax, the Verbatim
entry would look something like:

  

  https://www.gnu.org/licenses/old-licenses/gpl-1.0.html


  Verbatim License
  
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is
not allowed.
  

  

It's not clear to if the Verbatim license is long enough to be
copyrightably, but if it is I'd guess it's copyright 1989 by the FSF
and self-licensed under the Verbatim license as a subset of the GPL
1.0 (unless someone can turn up an earlier reference).

We probably also want to contact the FSF for permission to extract
this license text from the GPL-1.0 (or any of the other documents
where it occurs) to be extra clear we aren't violating the GPL-1.0's
Verbatim license.  And as the presumed authors, they're probably
interested in whether or not it gets a SPDX identifier.

Cheers,
Trevor

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

New license proposal: Verbatim

[W. Trevor King]

While reviewing [1], I noticed:

  1 text file with license text of GPL-2.0 = GPL-2.0

That makes sense if we're talking about the estimated project license,
but the license for the GPL-2.0 content itself (which would go in the
*file's* LicenseConcluded [2]) for the is “verbatim copies only” [3].
There are also other works under that license, e.g. [4], which use the
exact same language.

  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.

I recommend we add a new license identifier for that license so we can
write SPDX for the license-list-XML repository without having to go
beyond official short identifiers.

And we may want to add a field to our license XML to express the
license which applies to the license itself, as concluded by the SPDX
legal team.

Proposed full name: Verbatim License
Proposed short identifier: Verbatim
OSI approved: no (and it clearly does not support the OSI's derived
  works condition [5]).

Cheers,
Trevor

[1]: https://wiki.spdx.org/index.php?title=Legal_Team/only-operator-proposal
[2]: https://spdx.org/spdx-specification-21-web-version#h.2lwamvv
[3]: 
https://github.com/spdx/license-list-XML/blob/f3dc56f2424e8e93732f655637e0542c5557588c/src/GPL-2.0.xml#L29-L30
[4]: https://developercertificate.org/
[5]: https://opensource.org/osd#derived-works

-- 
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
Everyone is permitted to copy and distribute verbatim copies of this license 
document, but changing it is not allowed.


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

Re: minutes, summary, next steps

[W. Trevor King]

On Thu, Aug 17, 2017 at 04:22:51PM -0700, Gary wrote:
> > > > 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's certainly possible as well, and it would be easier to parse
> > with the space.  But you could also have an ‘-only’ operator with
> > no space (like we currently use ‘GPL-2.0+’ instead of ‘GPL-2.0
> > +’).  Aside from ease-of-parsing, I don't see a technical reason
> > to prefer one over the other.
>
> 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".

If we go with the ‘-only’ operator, I expect we'd want to forbid short
identifiers which ended with ‘-only’.  That would make parsing
unambiguous, and while you'd have to look a few characters ahead to
make the call, I don't think it would be a large technical burden.
But yeah, parsing would be easier if you could rely on space
separators before most operators, with ‘+’ as a special case because
the character is already forbidden in short identifiers, that makes
life easier.  So I'd prefer ‘FOO ONLY’ if the legal team is ok with
it, but feel like ‘FOO-only’ is achievable if the legal team has a
strong preference for it.

Cheers,
Trevor

-- 
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: minutes, summary, next steps

[W. Trevor King]

On Thu, Aug 17, 2017 at 06:00:22PM -0400, Wheeler, David A wrote:
> 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's certainly possible as well, and it would be easier to parse
with the space.  But you could also have an ‘-only’ operator with no
space (like we currently use ‘GPL-2.0+’ instead of ‘GPL-2.0 +’).
Aside from ease-of-parsing, I don't see a technical reason to prefer
one over the other.

> 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

That works too, although if ONLY applies to a license expression
(vs. applying to a license short identifier) there's no place to store
“does ONLY apply” metadata.  For example, it becomes more complicated
to report

  (GPL-2.0 OR MIT) ONLY

as nonsensical (because MIT is unversioned).

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

And to bring in a more complicated case where a distributable ONLY
doesn't help, consider a slightly altered version of the KDE example
that skips LGPL-2.1 [1]:

  LGPL-2.0 OR LGPL-3.0+

It's clear that versioning has been taken into account, and none of
those licenses are the ONLY allowed choice.  Do we want to require
users to say:

  LGPL-2.0 ONLY OR LGPL-3.0+

or do we want to document that any LGPL expression which addresses
versioning is sufficient without the explicit (and somewhat
misleading in the expression context) ONLY?

> If SPDX can at least make it easier to see when we don't know (yet),
> that'd be a big help.

SPDX (the spec) allows this distinction.  SPDX license expressions do
not.  More on this in [2] and the “I just found this license text and
am not sure about the grant” entry in [3].

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

If the proxy was included in the license expression, then why would
you need to read the license (grant) in more detail?  You'd use the
PROXY operator when the grant invoked the proxy clause in the usual
way, just as we currently have + when the grant invokes the “any later
version” clause in the usual way.  Non-standard invocations would need
custom entries (like folks currently do for KDE [4]).

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

If the consensus is that including the proxy information is too much,
I'd at least like to see this form.  Knowing that future versions may
be marked as allowable in the future seems important, regardless of
whether the grantor is the FSF (in which case you'd use ‘GPL-3.0+’) or
someone else (in which case you'd use ‘GPL-3.0 PROXY…’).

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx/2011-May/000390.html
 Subject: license name question
 Date: Wed May 25 09:43:56 MDT 2011
[2]: 
https://wiki.spdx.org/view/Legal_Team/or-later-vs-unclear-disambiguation#Issue
[3]: 
https://wiki.spdx.org/view/Legal_Team/or-later-vs-unclear-disambiguation#Alternative_Solution_-_create_-only_and_PROXY_.7BTEXT.7D_operators_for_licenses_that_explicitly_declare_their_compatibility
[4]: https://lists.spdx.org/pipermail/spdx/2011-May/000395.html
 Subject: license name question
 Date: Wed May 25 10:35:40 MDT 2011

-- 
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: New License Request: FB-Patents-2.0

[W. Trevor King]

On Thu, Aug 10, 2017 at 10:53:47AM -0400, Wheeler, David A wrote:
> Based on feedback from W. Trevor King (thank you!!), here is round 2.

Cross-linking round 1 [1].

> Here I propose this Facebook rider as a new *license* instead of
> separate license *exception*… 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)".

This proposal is for a license ID for the patent grant (not including
the BSD-3-Clause).  In previous discussion, a license that included
*both* the BSD-3-Clause and the patent rider was also floated (maybe
Facebook-BSD-Patent-2.0) [2,3], I think mostly due to concerns about
whether the explicit patent rider impacts the BSD's implicit patent
grant (if the “implicit patent grant” has legs at all) [2,4].  If the
legal team is not concerned about interactions like that, then minting
a new license/exception ID for just the patent grant is fine.  If the
legal team is concerned about the BSD-3-Clause / Facebook-Patent-2.0
interaction, then that single Facebook-BSD-Patent-2.0 license is one
viable approach.  Alternatively, the previous discussion of this issue
turned up some systemic adjustments to represent these potential “read
together” issues more generally:

* Splitting the current AND operator into AND and PLUS, where [5]:

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

  The advantage of this would be that PLUS may be impacted by these
  “read together” issues while AND would not.  Folks who are not
  worried about those sort of impacts can ignore the distinction.

* Generalizing WITH to mean “append this text” [6] without implying
  something about what an “exception” means [7,8].  This is similar to
  the AND/PLUS split, but the PLUS case is squashed into WITH.

  The advantage of this would be that WITH becomes much more powerful
  and the legal team can become much less opinionated once it doesn't
  need to distinguish “stand-alone licenses” from “riders granting
  execptions” from “other types of riders”.  The drawback is that
  users who trusted the legal-team's calls on that would no longer
  have programmatic access to the legal team's positions.

Other benefits to all the composite approaches are that React's
license expression will include ‘BSD-3-Clause’ and you can have a
one-to-one mapping between files and entries in the
PackageLicenseInfoFromFiles field [9].

I don't have a personal opinion on all of this other than a vague
concern that the patent grant may be too broad to qualify for the 2.1
spec's WITH scope [10], and the license ID for the Facebook patent
grant (as proposed in this thread) avoids that concern.

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002119.html
 Subject: New License/Exception Request: 
ANY-PATENT-ASSERTION-TERMINATES-2.0 as a new exception
 Date: Wed, 9 Aug 2017 18:22:37 -0400
 Message-ID: 
<9f8e44bc27e22046b84ec1b9364c66a1b75b6f3...@exch07-4850.ida.org>
[2]: https://lists.spdx.org/pipermail/spdx-tech/2015-June/002720.html
 Subject: [Bug 1292] New: What is the correct license expression
   for a project with an additional patent license?
 Date: Mon Jun 15 19:00:37 UTC 2015
[3]: https://lists.spdx.org/pipermail/spdx-tech/2015-June/002722.html
 Subject: [Bug 1292] New: What is the correct license expression
   for a project with an additional patent license?
 Date: Tue Jun 16 07:46:13 UTC 2015
[4]: https://lwn.net/Articles/728178/
 Subject: Apache disallows the Facebook BSD+patent license
 Date: 2017-07-18
[5]: https://lists.spdx.org/pipermail/spdx-tech/2015-June/002723.html
 Subject: [Bug 1292] New: What is the correct license expression
   for a project with an additional patent license?
 Date: Tue Jun 16 17:22:46 UTC 2015
[6]: https://lists.spdx.org/pipermail/spdx-tech/2015-June/002727.html
 Subject: [Bug 1292] New: What is the correct license expression
   for a project with an additional patent license?
 Date: Wed Jun 17 12:37:48 UTC 2015
[7]: https://lists.spdx.org/pipermail/spdx-legal/2017-July/002036.html
 Subject: revised wording for top of exceptions page
 Date: Thu, 6 Jul 2017 23:35:40 +0100
 Message-Id: <5F1D2C18-6D14-4CCD-80D3-6008588BB893 at jilayne.com>
[8]: https://lists.spdx.org/pipermail/spdx-legal/2017-July/002078.html
 Subject: revised text for top of exceptions page
 Date: Thu, 27 Jul 2017 22:34:12 -0600
 Message-Id: 
[9]: https://spdx.org/spdx-specification-21-web-version#h.32hioqz
[10]: 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.o

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

[W. Trevor King]

On Wed, Aug 09, 2017 at 06:22:37PM -0400, Wheeler, David A wrote:
> As far as I can tell SPDX currently has no way to report this
> information.

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

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

There's been recent discussion about what counts as an “exception”
[4,5].  The currently favored wording limits exceptions to things that
grant *additional* permissions.  It's not clear to me if the
Facebook/React patent rider meets that condition.  I'm personally in
favor of a less-opinionated operator for attaching riders, but this is
probably not the right thread to re-open that discussion.

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

And the BSD licenses were originally by Berkeley, but folks commonly
refer to them as BSD licenses, not “A-Short-Lax-Permissive-License”
;).  Ideally the name would be compact, intuitive, and easily
distinguished from other identifiers.  Facebook-Patent-2.0 is compact
and easily distinguished.  Your proposal is more intuitive, but
potentially less easily distinguished as the number of patent-related
riders grows.  And obviously folks can always pull up the full text if
they have questions.

Cheers,
Trevor

[1]: https://bugs.linuxfoundation.org/show_bug.cgi?id=1292
 https://lists.spdx.org/pipermail/spdx-tech/2015-June/002717.html
 Subject: [Bug 1292] New: What is the correct license expression
   for a project with an additional patent license?
 Date: Mon Jun 15 03:58:53 UTC 2015
[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-June/002008.html
 Subject: New OSI approved license
 Date: Sun Jun 4 03:47:02 UTC 2017
[3]: https://bugs.linuxfoundation.org/show_bug.cgi?id=1292#c2
[4]: https://lists.spdx.org/pipermail/spdx-legal/2017-July/002036.html
 Subject: revised wording for top of exceptions page
 Date: Thu, 6 Jul 2017 23:35:40 +0100
 Message-Id: <5f1d2c18-6d14-4ccd-80d3-6008588bb...@jilayne.com>
[5]: https://lists.spdx.org/pipermail/spdx-legal/2017-July/002078.html
 Subject: revised text for top of exceptions page
 Date: Thu, 27 Jul 2017 22:34:12 -0600
 Message-Id: 

-- 
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: Your license: full name and identifier - BSD-2-Clause-Patent?

[W. Trevor King]

On Wed, Aug 09, 2017 at 05:51:45PM -0400, Wheeler, David A wrote:
> 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.

There's some previous discussion of that license in [1,2].

Cheers,
Trevor

[1]: https://bugs.linuxfoundation.org/show_bug.cgi?id=1292
 https://lists.spdx.org/pipermail/spdx-tech/2015-June/002717.html
 Subject: [Bug 1292] New: What is the correct license expression
   for a project with an additional patent license?
 Date: Mon Jun 15 03:58:53 UTC 2015
[2]: https://lists.spdx.org/pipermail/spdx-legal/2017-June/002008.html
 Subject: New OSI approved license
 Date: Sun Jun 4 03:47:02 UTC 2017

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


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

Re: joint call legal/tech team - Tuesday, Aug 8

[W. Trevor King]

On Fri, Aug 04, 2017 at 04:54:34PM -0600, J Lovejoy wrote:
> There is a summary of the background and issue here:
> https://wiki.spdx.org/view/Legal_Team/or-later-vs-unclear-disambiguation

I've spend some time today using my new wiki account to shuffle things
around there and on [1].  If it's better to push things through a talk
page before doing that sort of thing, feel free to revert my changes
and I'll post something to their talk pages (or this thread?  Or
somewhere else?).

But new (to me and the wiki pages) information from today includes:

* The CDDL family seems to be the only other license (that we've found
  so far) with explicit wording about only vs. or-later [2].  It's
  like the GPL, except the GPL requires explicit grant wording to
  switch from “only” to “or later” [3] while the CDDL requires
  explicit grant wording to switch from “or later” to “only” [2].

  And there is CDDL code in the wild going both ways [4,5].

* The GPL-3.0 and other GNU v3 licenses have explicit wording about
  designating a proxy to approve future versions [6].  But even
  without that wording, we've seen explicit proxy designation in
  license grants [7,8].  We may want formal syntax for recording these
  proxy grants.  Something like:

LGPL-2.1 OR
LGPL-3.0 OR
LGPL-3.0 PROXY "membership of KDE e.V. (or its successor approved by the 
membership of KDE e.V.)"

I'm still trying to figure out where this leaves me on the only/+
front.

Cheers,
Trevor

[1]: https://wiki.spdx.org/view/Legal_Team/later-version-clauses
[2]: 
https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/CDDL-1.0.xml#L276-L286
[3]: 
https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L503-L514
[4]: 
https://github.com/freebsd/freebsd/blob/2c31a4b74c2e41b0c7407c9830e22bfd07150af0/uts/common/fs/zfs/abd.c#L2-L5
[5]: 
https://github.com/illumos/illumos-gate/blob/a9bfd41d542f15c474711abb8b0ca66a4cef9918/usr/src/common/acl/acl_common.h#L2-L19
[6]: 
https://github.com/spdx/license-list-XML/blob/7ecb7363bc82aedd0e293ca8825e348181619e6a/src/GPL-3.0.xml#L515-L517
[7]: https://lists.spdx.org/pipermail/spdx/2011-May/000389.html
[8]: 
https://wiki.spdx.org/view/FileNoticeExamples#.28LGPL-2.1_OR_LGPL-3.0_OR_LicenseRef-KDE-Accepted.29

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

Version the matching guidelines

[W. Trevor King]

The spec currently links to the matching guidelines by guideline
number.  For example, [1]:

  type: indicates whether the text is replaceable or omitable as per
Matching Guideline #2 (“Substantive Text”).

That seems brittle with the guidelines unversioned.  For example, that
reference will go stale if guideline changes move that suggestion to
be guideline 4.  There is currently a “v2.0” in the header of [2], but
the spec does not require that version, and I don't see links to
earlier versions on spdx.org.  Digging around in the Internet Archive
turns up an earlier version on 2013-04-30 [3] (where the “Substantive
Text” section was guideline 1).  Then a new “How These Guidelines Are
Applied” section came in between 2013-05-19 [4] and 2013-12-07 [5].
The v2.0 label landed between 2015-04-25 [6] and 2015-05-25 [7].  And
there don't seem to have been any changes since then.

Is there a reason why these guidelines are not part of the spec
itself?  It seems like a new appendix in [8] would avoid confusion
like “I thought I'd implemented SPDX 2.2, but now the matching
guidelines have changed on me”.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.2mjng0vqrghe
[2]: https://spdx.org/spdx-license-list/matching-guidelines
[3]: 
http://web.archive.org/web/20130430090750/https://spdx.org/spdx-license-list/matching-guidelines
[4]: 
http://web.archive.org/web/20130519043548/http://spdx.org/spdx-license-list/matching-guidelines
[5]: 
http://web.archive.org/web/20131207063710/http://spdx.org/spdx-license-list/matching-guidelines
[6]: 
http://web.archive.org/web/20150425023643/http://spdx.org/spdx-license-list/matching-guidelines
[7]: 
http://web.archive.org/web/20150525115354/http://spdx.org/spdx-license-list/matching-guidelines
[8]: https://github.com/spdx/spdx-spec

-- 
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 checking tool available

[W. Trevor King]

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

Ah, there is also guideline 4 saying that case is not significant.
Presumably that also applies to these equivalent replacements.

Cheers,
Trevor

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

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


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 checking tool available

[W. Trevor King]

On Fri, Aug 04, 2017 at 11:12:54AM -0700, Gary wrote:
> I feel we need another tool to compare text to a specific SPDX
> license and indicate exactly where the 2 licenses do not match.

Having this be part of the online tool would be great.  But a
quick-and-dirty way to accomplish this is to use Git's --word-diff
argument.  For example, from a local checkout of [1]:

Strip XML tags, leading space, and trailing space:

  $ sed -i 's/<[^>]*>//g;s/^[[:space:]]*//;s/[[:space:]]$//' src/GPL-3.0.xml

Replace some XML entities:

  $ sed -i 
"s//>/g;s//src/GPL-3.0.xml

Stage those changes:

  $ git add src/GPL-3.0.xml

Clobber with the GNU text:

  $ curl -s https://www.gnu.org/licenses/gpl.txt >src/GPL-3.0.xml

Strip leading/trailing space again:

  $ sed -i 's/^[[:space:]]*//;s/[[:space:]]$//' src/GPL-3.0.xml

Replace newlines with spaces again:

  $ CONTENT="$(tr '\n' ' ' src/GPL-3.0.xml

See what's changed vs. the staged version:

  $ git diff --word-diff

The only difference that turned up in the license text is:

  Copyright [-©-]{+(C)+} 2007 Free Software Foundation, Inc.

Our guideline for equating copyright symbols includes (c) but not (C)
[2].  Maybe that's what's going on?

Or maybe the SPDX template you're using doesn't match the current
license-list-XML master.  Or maybe there's some other problem I'm
missing because I'm ignoring the XML tags ;).

Cheers,
Trevor


[1]: https://github.com/spdx/license-list-XML
[2]: https://spdx.org/spdx-license-list/matching-guidelines

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


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

Re: SPDX full names of GPL family licenses

[W. Trevor King]

On Thu, Jul 27, 2017 at 03:24:20PM -0400, Richard Fontana wrote:
> Traditionally of course (I mean outside of SPDX) the full name of
> that sort of license would have been something like "GNU Lesser
> General Public License version 2.1 or any later version", i.e. the
> "only" would of course only be used in the name of a GPL family
> license if the "or later" permission wasn't present.

I'm still also in favor of removing “only” from those names.

The last thread on this list that atttempted to resolve (or at least
summarize) the “only” issue is [1].  There are also some GitHub issues
around this [2,3] and a wiki page [4].  Some of those are focused on
the short identifiers, but I think that, regardless of how things work
out with the short identifiers, we can remove “only” from the names of
licenses that specifically include the or-later clause in the HOWTO
[5].  And we're currently including the or-later HOWTO in our GPL-3.0
XML [6], GPL-2.0 XML [7], etc.

Later if we want to define a GPL-3.0-only short identifier, or
whatever, we can add “only” to *it's* long name.

Cheers,
Trevor

[1]: https://lists.spdx.org/pipermail/spdx-legal/2017-May/001973.html
 https://lists.spdx.org/pipermail/spdx-tech/2017-May/003351.html
 Subject: various threads on "only" suffix (for GPL)
 Date: Fri, 26 May 2017 11:01:44 -0600
 Message-Id: 
[2]: https://github.com/spdx/license-list/issues/6
 Subject: Inconsistent use of "only" in "Full Name of License" column
[3]: https://github.com/spdx/license-list-XML/issues/398
 Subject: Remove "only" from GPL license titles?
[4]: https://wiki.spdx.org/view/Legal_Team/or-later-vs-unclear-disambiguation
[5]: https://github.com/spdx/license-list/issues/6#issuecomment-307295257
 Subject: Inconsistent use of "only" in "Full Name of License" column
[6]: 
https://github.com/spdx/license-list-XML/blob/b2fc0db6a735e3b4f2c31f938edbd910e832ed1d/src/GPL-3.0.xml#L568-L570
[7]: 
https://github.com/spdx/license-list-XML/blob/b2fc0db6a735e3b4f2c31f938edbd910e832ed1d/src/GPL-2.0.xml#L283-L284

-- 
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: Your license: full name and identifier

[W. Trevor King]

On Fri, Jul 21, 2017 at 01:27:23PM -0400, Richard Fontana wrote:
> 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).

More details on that:

  $ curl -sI https://opensource.org/licenses/BSD-2-Clause-Patent | grep 
'HTTP\|Location'
  HTTP/1.1 301 Moved Permanently
  Location: https://opensource.org/licenses/BSDplusPatent
  $ curl -sI https://opensource.org/licenses/BSDplusPatent | grep 'HTTP\|Link'
  HTTP/1.1 200 OK
  Link: ; rel="shortlink",; rel="canonical"
  $ curl -sI https://opensource.org/node/865 | grep 'HTTP\|Link'
  HTTP/1.1 200 OK
  Link: ; rel="shortlink",; rel="canonical"

So /licenses/BSDplusPatent is still the canonical link, and /node/865
is a shortlink [1] (notes on the Link header in [2]).

Does it matter which link is canonical and which is the 301?  The only
impact I can see is that it's easier to go back and forth between the
OSI API and the SPDX API if we're using the same identifiers in
[3,4,5].

Cheers,
Trevor

[1]: https://code.google.com/archive/p/shortlink/wikis/Specification.wiki
[2]: https://tools.ietf.org/html/rfc5988#section-5.5
[3]: https://github.com/OpenSourceOrg/licenses
[4]: https://github.com/spdx/license-list
[5]: https://github.com/spdx/license-list-XML

-- 
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: revised wording for top of exceptions page

[W. Trevor King]

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


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

Re: New OSI approved license (BSD+Patent)

[W. Trevor King]

On Thu, Jun 01, 2017 at 05:29:52PM -0400, Wheeler, David A wrote:
> > 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.

The patent grant and disclaimer looked like they could be permuted
without changing the meaning.  And the “DISCLAIMER” header could be
added to an  group on the vanilla BSD-2-Clause.  If there is any
doubt for either of those, then yeah, the WITH “exception” approach is
not an option.

But say the BSD+Patent license had just been “append this text to the
vanilla BSD-2-Clause”, I think Jilayne's policy would *still* call for
a new license.  Is that not how you read “take them as we find them”?

Cheers,
Trevor

-- 
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: New OSI approved license (BSD+Patent)

[W. Trevor King]

On Thu, Jun 01, 2017 at 11:39:21AM -0600, J Lovejoy wrote:
> This would not be treated as an exception because it was drafted
> (and submitted to the OSI) as a complete license, not as an
> exception or separate, add-able text to BSD-2-Clause. While you
> raise a good point about the potential different ways one might
> express such a situation as this, I think we need to generally ‘take
> them as we find them’ and no re-interpret the intent of the
> (license) author.

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

> As for an identifier, there is no reason to use “OSI” in the
> identifier - we have all of the OSI-approved licenses included on
> the SPDX License List.

Right.  I was hunting for a tag to identify the patent grant.  The
author of the grant seemed like a reasonable choice (especially since
the author or current license owner is important for things like
deprecation notes [1]), and I didn't see anything on the OSI page [2]
about them getting the text from somewhere else.  The the first
project to use the grant would also be a good choice.  But some
identifier that's unlikely to lead to confusion if/when someone else
writes a BSD flavor with a different patent grant.

> • Where applicable, and if possible, the short identifier should be
>   harmonized with other well-known open source naming sources (i.e.,
>   OSI, Fedora, etc.)

This is important too, and is a good reason to use BSDplusPatent [2],
even if there is some ambiguity or a risk of future collisions there.

Cheers,
Trevor

[1]: https://github.com/spdx/license-list-XML/pull/83#discussion_r102831403
[2]: https://opensource.org/licenses/BSDplusPatent

-- 
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: New OSI approved license (BSD+Patent)

[W. Trevor King]

On Wed, May 31, 2017 at 9:57PM -0600, J Lovejoy wrote:
> Following our existing pattern for variations on BSD (listed below
> for reference), we might want to consider:
> Full name: BSD 2-clause plus Patent (could also be BSD 2-Clause with
>   Patent - as the use of with in the full name is not problematic,
>   although arguably not ideal either)
> Short Identifier: BSD-2-Clause-Patent

Since most of the text is the same as the current BSD-2-Clause [1],
you could put the grant (“Subject to the terms and conditions of this
license… estoppel or otherwise.”) in a license exception (and maybe
generalize “exception”?) and users could use:

  BSD-2-Clause WITH BSD-Patent

or whatever if there's a better identifier for the patent grant (who
wrote it?  Maybe it should be OSI-Patent?).

I'm not sure if there's a clear policy for whether a new license that
only adds text to an existing license should be a new SPDX license or
a new SPDX exception, but it's probably worth documenting some
guidelines if there is such a policy.

Cheers,
Trevor

[1]: https://spdx.org/licenses/BSD-2-Clause.html

-- 
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: [spdx-tech] various threads on "only" suffix (for GPL)

[W. Trevor King]

On Fri, May 26, 2017 at 03:15:44PM -0400, Wheeler, David A wrote:
> 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.

How could you know this before GPL-4.0 has been written?  Maybe I'm
just not clear on what your “acceptable” means.

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

If you've audited both GPL-2.0 and GPL-3.0 for your package and want
the "or later" language to include GPL-4.0, etc. when they get
written, you could say [1]:

  GPL-2.0+ OR GPL-3.0+

but whether you've read the license or deem it “acceptable” seems
orthogonal to whether you're granting the “or any later version”
choice defined in the GPL (§14 as of GPL 3.0 [2]).

Back in 2013, Mark pointed out that GPL-2.0+ is not a license [3],
which means you're not going to be able to distinguish between
GPL-2.0+ and GPL-2.0-only (or whatever) by scanning for license text
[4].  So I'd rather:

* Leave GPL-2.0 as the license identifier.

* Add '+' and '-only' suffixes to support folks who want to be
  explicit (e.g. who don't trust readers to be familar with baked-in +
  semantics).

  CC-BY-SA-3.0+ would be a synonym for CC-BY-SA-3.0 [6], but I don't
  see a problem with that.  It would probably be useful to call that
  out in the wording that forbids the -only suffix for CC-BY-SA-3.0…

* Forbid '-only' for licenses that bake in some forbidding wording
  (e.g. the “Adapter’s License” conditions in CC-BY-SA-4.0's §3.b
  [5]).

  You'd need a formal exception to get around that wording
  (e.g. CC-BY-SA-4.0 WITH CC-only-this-version-exception) or your own
  name if the CC's alteration wording would not allow ‘CC-BY-SA-4.0
  WITH additional-restrictions’ [7].

Then tools like [4] can cleanly say that they're guessing the
appropriate license identifier (e.g. “we found GPL-2.0”), but are not
attempting to construct the appropriate license expression for the
package (e.g. “this package is GPL-2.0+” or “this package is
GPL-2.0[-only]”).  To distinguish between *those* you'd need to look
for the “or any later version” grant.

Cheers,
Trevor

[1]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
[2]: https://www.gnu.org/licenses/gpl-3.0.txt
[3]: https://lists.spdx.org/pipermail/spdx-legal/2013-October/000949.html
[4]: https://github.com/benbalter/licensee
[5]: https://creativecommons.org/licenses/by-sa/4.0/legalcode
[6]: 
https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/
[7]: 
https://creativecommons.org/faq/#can-i-change-the-license-terms-or-conditions

-- 
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: extra field for license exceptions

[W. Trevor King]

On Mon, Feb 27, 2017 at 03:58:38PM -0700, J Lovejoy wrote:
> In the course of implementing the license expression syntax and
> deciding to put license exceptions in their own sub-list, we thought
> we might as well be thorough about it, and a few brave souls set
> about to find as many license exceptions as possible (mostly of the
> GPL variety) and put them into a spreadsheet. This info included
> “examples of use”. We then added all the most obviously used
> exceptions over the next few releases of the SPDX License List…  As
> we added those license exceptions to the SPDX License List, I think
> we all felt a bit odd about dumping the “examples of use” info and
> so we simply made this a field for exceptions.

That makes sense, but I don't think it really matters who did the
research.  I agree that it's worth keeping the information around
(even if it has since gone stale), but think a link to the request
will cover that and make it more obvious that consumer information may
be stale.  Folks can always post to the request thread with updated
information if they want to correct stale information.

> The [source/url] field - both for exceptions and licenses - for URLs
> is supposed to capture the text somewhere else, where it originated
> in many cases, or a link to the OSI page if OSI-approved.  Slightly
> different context.

Right.  Distinguishing between consumer projects and canonical license
source makes sense.

> As you can also see: there won’t be a link to the submission thread
> for every license (and I don’t think anyone wants to try and back
> fill that for the 300+ licenses we have…), so there’s also that.

If stuff came in without a formal request, then either the request-URL
property would have to be optional, or we'd need to create dummy
entries for grandfathered requests.  The current list archives are a
bit hard to search, but if you're only using an ‘extra’ field for some
exceptions now, it shouldn't be too hard to at least cover those
entries with dummy threads.  That way we can switch to a request-URL
approach without losing information.  And going forward we can track
request URLs for all entries (both licenses and exceptions) without
having an exception-specific field.

Cheers,
Trevor

-- 
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: extra field for license exceptions

[W. Trevor King]

On Mon, Feb 27, 2017 at 02:18:55PM -0700, J Lovejoy wrote:
> Information related to who, when, how, why a license or exception
> was requested to be added is maintained here:
> https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681
> for purposes of tracking while a license is under review.  Once it’s
> added to the list, it’s added.  We have never included any such
> information related to the original request to add in any of the
> fields that make up the SPDX License List, and I don’t see any
> reason to start now. ??

Because the original request includes the “Example of Use” information
you're currently putting in the ‘extra’ field.  For example, the Open
CASCADE row includes links to both [1] (for the OCCT-PL license) and
[2] (for the OCCT-exception-1.0 exception) and both of those were in
the original mailing-list request [3].  Since the original request
contains *additional* information beyond the example consumers
(submission date, occasionally the license author, …), I think linking
to the submission thread is a better approach than linking to
examples.  That also gets you off the hook for maintaining these
consumer references, which presumably bit-rot after the initial
submission (although the Open CASCADE links still work at the moment).

Cheers,
Trevor

[1]: https://www.opencascade.com/content/occt-public-license
[2]: https://www.opencascade.com/content/licensing
[3]: https://lists.spdx.org/pipermail/spdx-legal/2015-October/001519.html

-- 
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: extra field for license exceptions

[W. Trevor King]

On Thu, Feb 23, 2017 at 10:41:50AM -0700, J Lovejoy wrote:
> The license exceptions have an “extra” field that we don’t use for
> the licenses, which is “Example of Use”. I think this is from info
> we captured when collecting exceptions to add to the list.

Potentially more useful information would be a link to the list thread
where the license/exception was proposed.  We should have that for all
licenses/exceptions, because it's part of the new-license/exception
workflow [1] (for example, see [2]).  That would capture the
information from the initial request, including “identifying at least
one program that uses this license” [1], and also capture as much of
the acceptance discussion as was recorded in the list thread.

I'm not sure how long that policy has been in place; if there are a
significant number of licenses/exceptions without a proposal on the
mailing list, then maybe just a URL pointing at the proposal (wherever
it happens to live)?

Cheers,
Trevor

[1]: https://spdx.org/spdx-license-list/request-new-license
[2]: https://lists.spdx.org/pipermail/spdx-legal/2016-November/001869.html

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