Re: OpenJ9 license

[Philippe Ombredanne]

On Thu, Oct 12, 2017 at 11:32 AM, Wayne Beaton
 wrote:
> My understanding is that the Secondary Licensing provision in the EPL-2.0 is
> not the same as dual licensing using an OR. From our FAQ (which we're still
> working on):
>
>> The notion of Secondary Licenses is intended to permit combining content
>> licensed under the EPL-2.0 with an otherwise incompatible license,
>> specifically the GNU General Public License, v2.0 or greater. This means
>> that the content that includes a Secondary License clause may be combined
>> with content distributed under the terms of that Secondary License, and the
>> combined content can be then be collectively distributed under the terms of
>> that Secondary License.
>
> Further,
>
>> Is EPL-2.0 with the Secondary License clause considered dual licensing?
>> It is extremely close to dual licensing.  The EPL-2.0 is the only license,
>> until such time as it is combined and distributed with a work under the
>> Secondary License. After such time, any recipient of the combined work can
>> consider the content licensed under the Secondary License. The original work
>> remains under the EPL-2.0 and is never really dual-licensed. Once a
>> downstream adopter has received the content under the Secondary License,
>> they can modify and further distribute it solely under the terms of the
>> Secondary License.
>
> Does this help?
>
> I hope to make our FAQ public later today or earlier tomorrow. That may
> provide further context.

Wayne:
This helps a lot to better understand the EPL terms.

My understanding:

I cannot use EPL 2.0-licensed code under a Secondary license
unless I combine it with some other code using that Secondary license.
And only its is only when I combine that the Secondary license terms may
apply to the combo. Otherwise, only the the EPL-2.0 applies.

My take is that a license expression can never replace nor capture all
the specific
details of licensing. This what the license texts are for. The license
expression is
just a concise, imperfect but mightily handy summary of the licensing.

Therefore, even though this may not be it exactly, I still think we
can use existing
license expressions OR constructs for this case and with no change needed.

An expression such as EPL-2.0 OR GPL-2.0 is enough to tell me there is some
choice. Then when I read the actual text and notice, I get the details
and specific
terms. If I elect the GPL-2.0 choice without reading the licensing
first then I am
foolish at best. We cannot prevent foolishness. If I build a tool that automates
such a choice, I can easily have a special case where the EPL-2.0 shows up
as a choice with another license and process this as a special case.

Be it here or in the much-talked-about case of FSF or-later-or-only-or-may-be
licensing nuances, an expression can never entirely replace the actual
license texts
and notices. I think this is just fine this way: a name alone can
never capture nor
convey all the nuances and attributes of a thing.

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

RE: Providing access to FSF license metadata

[Gary O'Neall]

> -Original Message-
> From: W. Trevor King [mailto:wk...@tremily.us]
> Sent: Friday, October 13, 2017 12:44 PM
> To: Richard Fontana; J Lovejoy
> Cc: Gary O'Neall; spdx-t...@lists.spdx.org; SPDX-legal
> Subject: Re: Providing access to FSF license metadata
> 
> 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;
>   }
> ]
>   }
> 

Added an issue to the SPDX tools to generate the isOsiApproved flag based on 
the OSI provided API: https://github.com/spdx/tools/issues/111

Gary

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

Re: Providing access to FSF license metadata

[Richard Fontana]

W. Trevor King wrote:

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

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

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

Richard

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

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

Supporting existing users is important, which is why the old fields
should stay in license-list-data.  But nobody's relying on
license-list-XML (yet), so we aren't constrained by backwards compat
there.  As long as we can recover the old information when compiling
license-list-data (and I think we can), I don't see a backwards-compat
issue.

> if there is some 

Re: Providing access to FSF license metadata (was: Issues added based on this weeks Legal Call)

[J Lovejoy]

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


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

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. if there is some improved way to get to the same end 
point (of identifying on the SPDX license list, which licenses have been 
OSI-approved), then we can look into that, but I’d think it’d take some work 
from both SPDX and OSI to do so. 

> 
> And the OSI API [2] *already* supports lookups by SPDX ID [3]:
> 
>  $ curl -s https://api.opensource.org/license/SPDX/BSD-3-Clause | jq .keywords
>  [
>"osi-approved",
>"popular",
>"permissive"
>  ]
> 
> I think the FSF should provide a similar API to expose its
> license-categorization information in a structured way.  Then we can
> include FSF IDs in our license metadata (ideally generated through
> automated matching [4]) and/or they can provide SPDX IDs in their
> license metadata.  User agents could ask the FSF if they consider a
> license GPL-compatible, GPL-incompatible, free, non-free,
> for-a-viewpoint, etc., etc. [5] in a machine-readable way.

This sounds like a nice idea… but we have to work with what we have and FSF 
does not have such an API - what they have is what you see on the HTML page 
with the list of licenses they consider free/libre. 

> 
>> The field will be accessible in the JSON, RDFa, RDF/Turtle, RDF/XML,
>> and RDFa formats of the license in addition to being exposed through
>> the SPDX Tool Java libraries.
> 
> I'm fine with exposing whatever you want downstream for convenience,
> but I think the only thing that should go in license-list-XML and
> spdx-spec is the FSF license ID.
> 
> Cheers,
> Trevor
> 
> [1]: https://github.com/spdx/license-list-XML/issues/417
> [2]: https://opensource.org/node/822
> [3]: 
> https://github.com/OpenSourceOrg/api/blob/master/doc/endpoints.md#licenseschemeidentifier
> [4]: https://github.com/spdx/license-list-XML/issues/418
> [5]: https://www.gnu.org/licenses/license-list.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
> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal

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

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

[Richard Fontana]

W. Trevor King wrote:

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

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

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

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

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

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

Issues added based on this weeks Legal Call

[Gary O'Neall]

Greetings tech team,

 

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 was going to add a pull request to the spec when I realized we don't
really document other listed license properties which are used, so I added
an issue to document the new property as well as the older fields already in
use (e.g. isOsiApproved): https://github.com/spdx/spdx-spec/issues/46

 

Please let me know by Tuesday if you have any concerns about the new
property name.  You can either comment on the issue or reply to this thread.
The field will be accessible in the JSON, RDFa, RDF/Turtle, RDF/XML, and
RDFa formats of the license in addition to being exposed through the SPDX
Tool Java libraries.

 

There was also a discussion on the legal team distribution about use of
parentheses in license expressions.  The consensus on the thread was that
the spec is not clear on the use of linefeeds, so I added two new issues to
track the documentation updates.  Trevor has volunteered to create a pull
request for this as well as other improvements in the license expression
documentation - please see the following issues for more detail:

https://github.com/spdx/spdx-spec/issues/45

https://github.com/spdx/spdx-spec/issues/44

https://github.com/spdx/spdx-spec/pull/37

 

 

Gary

 

-

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email:   g...@sourceauditor.com

 

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