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: 
<caf3y9oigadg-mal-pux7obfqxnykzenwn_yoy5zcysy452t...@mail.gmail.com>
[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

[Marc Jones]

Trevor,

Maybe I have missed it in the thread, but what are the terms the "Verbatim"
license would refer to?

Is it intended to refer to a specific set of licensing terms or just a
category of possible explicit or implicit licensing statements? For example
the licensing terms for redistributing the GPL as contained in the
GPL: "Everyone
is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed." (If we are moving past the
licensing of a license and talking about other kind of content, then that
is probably a bad example.)

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] And that licensing statement was supplemented with
commentary: “Our intention in using the phrase ‘verbatim copying in any
medium’ is not to require retention of page headings and footers or other
formatting features. Retention of weblinks in both hyperlinked and
non-hyperlinked media (as notes or some other form of printed URL in
non-HTML media) is required.” But now the FSF recommends the CC BY-ND 4.0
instead. If one were to tag the content on say the FSF website as
"verbatim," does that help us understand what license the content is being
offered under? Unless verbatim means something specific it appears its
meaning could shift over time or from context to context.

If we mark FSF content as "verbatim" I can see three different licensing
terms to consider. Perhaps the differences in language don't matter in most
cases, but I can't image that they would never matter.

Having raised that question. I do think you are right that people should be
mindful to not just focus on the license of the source code in the package.
In my experience FOSS producers are frequently interested in licensing the
content that accompanies  the source code under different terms then the
source code. I have found this to be especially true of web applications,
where the producer wants to provide a working demo, is comfortable sharing
the source code under a FOSS license, but for some reason does not want to
give blanket permission to use or modify images. The license of a package
is often more complicated than just the license of the source code, and if
package contains other kinds of content such as documentation or default
content that are distributed under different terms should be recorded (or
split into a different package.) 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]. (I am intentionally ignoring the
patent license and only referring to copyright licenses for sake of
simplicity.) Tagging all of the source code in the React git repo as being
under a permissive BSD copyright license since the examples are actually
under a really restrictive license.

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.

-Marc

[1] https://www.gnu.org/licenses/licenses.html#VerbatimCopying
[2] https://github.com/facebook/react/blob/master/LICENSE
[3] https://github.com/facebook/react/blob/master/LICENSE-examples
[4] https://github.com/facebook/react/blob/master/LICENSE-docs




On Tue, Sep 12, 2017 at 12:56 PM W. Trevor King  wrote:

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

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

[Andrew Katz]

My recollection is that Apache 2.0 is under Apache 2.0, also.

On 12 Sep 2017, at 14:04, Richard Fontana 
<rfont...@redhat.com<mailto:rfont...@redhat.com>> wrote:

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


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

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

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

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

Yes, this is an argumentum ad absurdum FWIW.

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


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

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

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

Re: New license proposal: Verbatim

[Matija Šuklje]

Dne torek, 12. september 2017 ob 15:04:10 CEST je Richard Fontana napisal(a):
> Not to detract from your general point but Creative Commons has, admirably,
> placed CC0 under CC0.  https://creativecommons.org/policies/#license

Neat! Good to know and thanks for digging this up :)

Also, re-reading my e-mail, I hope it didn’t come across too aggressively – it 
was not intended as such.


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

Re: New license proposal: Verbatim

[Richard Fontana]

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

- Original Message -

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

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

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

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

Yes, this is an argumentum ad absurdum FWIW. 

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


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

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

Re: New license proposal: Verbatim

[Matija Šuklje]

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

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

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

Yes, this is an argumentum ad absurdum FWIW.

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


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

RE: GPLv2 - Github example (was: Re: New license proposal: Verbatim)

[Gisi, Mark]

>> it’s the job of SPDX to provide a clear way to identify
>> what is found and a language to express that in.

I concur. Sometimes the best one can do is to document the lack of license 
information hence the existence of the NONE and NOASSERTION designations.   
Because a core SPDX principle is not to make legal determinations, focusing 
reporting the facts is the best one can do.

In Example 4  I would expect to see the following values:

Files # 1, 2, 3, 4:
​LicenseConcluded: NOASSERTION
​LicenseInfoInFile: NONE

COPYING file:
LicenseConcluded: GPL-2.0   /* by convention */
​LicenseInfoInFile: GPL-2.0

Package level:
PackageLicenseConcluded: NOASSERTION

A less conservative choice for the package license would be GPL-2.0 but I don’t 
see how one comes up with GPL-2.0+ based on the information provided. In this 
example what I find valuable about SPDX is that it allows one to describe 
licensing information in the best terms possible by reporting the facts. This 
is a benefit over not having SPDX in that - it makes it easy to determine that 
this is a poorly licensed package. The SPDX file analogous to a dentist’s x-ray 
in that - instead of illuminating tooth decay, it illuminates licensing decay – 
a typical consequence in both cases of bad practice (hygiene).

I do not see the “only” problem here. Files 1-4 are not even open source 
because there is no clear open source license grant. Beyond the fact that you 
can’t decisively determine whether the GPL-2.0 is applicable, how do you know 
one or more of the files where not copied from *another project* with just a 
LICENSE.txt (Apache-2.0 ) in the top directory. Or worst – copied from a 
project with zero licensing  info in the top level or a commercial offering. 
Because someone copies a file into a GPL-2.0 project does not make it GPL-2.0.

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.



- Mark




From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Friday, September 08, 2017 7:07 AM
To: Marc Jones
Cc: SPDX-legal
Subject: GPLv2 - Github example (was: Re: New license proposal: Verbatim)

Hi Marc,

Thanks so much for your thoughtful response to the examples set out to help 
with the only-operator proposal.  You are the first one to respond to this, and 
I hope that others will also chime in here.  Example 4 is indeed what we have 
been struggling with and is a common example in that the way Github repos are 
created, it’s easy to have only the license file with no other license info. I 
think your further examples of the kinds of responses you might get when asking 
for clarification are also very realistic in that you can’t count on getting a 
clear answer!  Some education and guidance on this is clearly needed, but may 
still run into these scenarios and it’s the job of SPDX to provide a clear way 
to identify what is found and a language to express that in.

I really hope you don’t go back to merely lurking!

Cheers,
Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com<mailto:opensou...@jilayne.com>

Also to chime in on the question of if only a copy of the GPLv2 text is include 
in a code base:

First I just want to offer my apologies for coming late to the party. I know 
from the meeting notes everyone involved has been working very hard and 
thoughtfully on this issue for months. My compliments to all of your hard word 
and appreciation for whoever is responsible for keeping such detailed meeting 
notes up to date. My comments are only meant to add to the conversation, not 
distract from it.

I agree with the conclusions of examples 1, 2 and 3. 
(https://wiki.spdx.org/index.php?title=Legal_Team/only-operator-proposal).

To address example 4. I think the solution is probably not intuitive (at least 
it was not to me,) but if you only include the text of the GPLv2 with no other 
licensing statements the plain meaning of the license text would require 
concluding that the code base is GPLv2 only. I can imagine buying into a theory 
where you get to any version of the GPL, and but at the moment I do not see how 
to get to "GPLv2 or any later version."

The GPLv2 says "If the Program does not specify a version number of this 
License, you may choose any version ever published by the Free Software 
Foundation." Not trying to be pedantic but the text of the GPLv2 clear refers 
to GPLv2. Being something seems to be the best w

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

[Brad Edmondson]

Hi Marc,

Great analysis, and I will echo Jilayne's call for you not to feel like you
have to return to lurking. This is open-source, and to get to the best
solution, we need everyone with thoughtful analyses and arguments to come
forward.


With respect to the copyright in the text of a license (the "Verbatim"
question), I don't think this is an issue SPDX needs to worry about or to
spec out how to describe in SPDX expressions. 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, 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. SPDX arguably has an implied license for
every open-source license, excepting perhaps those that are limited to a
specific project or company. But more than that, SPDX's license database is
almost certainly a fair use of the license text under copyright law. You
can go through the four factors and all their sub-factors if you want to,
but I think because SPDX is a meta-project to help identify the licenses in
question, SPDX itself is non-profit, and there is not "market" (in the
copyright sense) for original open-source license texts, I'd say the fair
use case is pretty slam-dunk.

TL;DR: I don't think we need to add licenses or change the spec to
represent any potential copyright in license text, as I rate the risk to be
minimal and we have a big enough challenge as it is with our primary goals
of identifying licenses and describing licensed files & packages.


Best,
Brad

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

On Fri, Sep 8, 2017 at 5:28 AM, Marc Jones  wrote:

> Sporadic lurker, first time poster.
>
> Many licenses require you to include an exact copy of the license in the code 
> base as a condition of the license. So if for example a code base is license 
> under 3-Clause BSD then you have to "must retain the above copyright notice, 
> this list of conditions and the following disclaimer." Similarly in GPLv2 if 
> you are redistributing an exact copy of the code base you must "give any 
> other recipients of the Program a copy of *this* License along with the 
> Program."
>
> 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. 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. Doing so would 
> violate a condition of the license to the code base. In which case the 
> simplest and most accurate thing to do would be to simple say that the code 
> base is 3-clause BSD. It both accurately states the license of the code and 
> your permissions to modify the 3-clause BSD file in that code base (i.e. you 
> aren't allowed to.) Similar argument could be made for GPL licensed programs 
> as well.
>
> >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. Which seems to 
> be entirely self defeating. And also I think taking the concern over a lack 
> of an explicit license on the license text itself too seriously. I think 
> there is a solid argument for implied license for all open source licenses to 
> at least copy them verbatim in a code base under that license. Certainly a 
> strong case for any license that has been approved by OSI.
>
> >>* 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 the point of SPDX is to accurately record the the license of the codebase, 
> then this just seems like a definitional issue: Is the license text of the 
> code base part of the code base that SPDX is describing? Personally I never 
> had any confusion about the fact that the license text was not subject to 
> same license of the source code. Rather when talking about the license of a 
> code base I have always assumed 

RE: New license proposal: Verbatim

[Wheeler, David A]

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

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

--- David A. Wheeler

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

GPLv2 - Github example (was: Re: New license proposal: Verbatim)

[J Lovejoy]

Hi Marc,

Thanks so much for your thoughtful response to the examples set out to help 
with the only-operator proposal.  You are the first one to respond to this, and 
I hope that others will also chime in here.  Example 4 is indeed what we have 
been struggling with and is a common example in that the way Github repos are 
created, it’s easy to have only the license file with no other license info. I 
think your further examples of the kinds of responses you might get when asking 
for clarification are also very realistic in that you can’t count on getting a 
clear answer!  Some education and guidance on this is clearly needed, but may 
still run into these scenarios and it’s the job of SPDX to provide a clear way 
to identify what is found and a language to express that in. 

I really hope you don’t go back to merely lurking!

Cheers,
Jilayne

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

> Also to chime in on the question of if only a copy of the GPLv2 text is 
> include in a code base:
> First I just want to offer my apologies for coming late to the party. I know 
> from the meeting notes everyone involved has been working very hard and 
> thoughtfully on this issue for months. My compliments to all of your hard 
> word and appreciation for whoever is responsible for keeping such detailed 
> meeting notes up to date. My comments are only meant to add to the 
> conversation, not distract from it.
> I agree with the conclusions of examples 1, 2 and 3. 
> (https://wiki.spdx.org/index.php?title=Legal_Team/only-operator-proposal 
> ).
> To address example 4. I think the solution is probably not intuitive (at 
> least it was not to me,) but if you only include the text of the GPLv2 with 
> no other licensing statements the plain meaning of the license text would 
> require concluding that the code base is GPLv2 only. I can imagine buying 
> into a theory where you get to any version of the GPL, and but at the moment 
> I do not see how to get to "GPLv2 or any later version."
> The GPLv2 says "If the Program does not specify a version number of this 
> License, you may choose any version ever published by the Free Software 
> Foundation." Not trying to be pedantic but the text of the GPLv2 clear refers 
> to GPLv2. Being something seems to be the best way to specify that thing. If 
> the only licensing information in a code base is the exact text of GPLv2 I 
> have three questions: 1) does the mere presence of the GPLv2 text imply that 
> the author intended the accompanying code to be licensed under the GPLv2? 2) 
> Since the only licensing statement for the code base is implied by the full 
> text of the GPLv2, is there anyway to argue that the version wasn't 
> specified? And 3) is there anyway to argue that "or any later version" was 
> specified?
> Q1: The answer to the first question is not obvious to me. To me the mere 
> presence of the license text in a file does not an explicit license make. I 
> think you need to rely on practice of the trade to get there, or at least an 
> implied license. Dropping the text of a license into a file called LICENSE or 
> even more specific to our industry COPYLEFT would not be obvious in all 
> situations that that is the intended license. It could just be a random file 
> with some other purpose that the copyright holder never noticed or intended 
> to give that kind of effect to. I know that flies in the face of a lot of 
> assumptions of the industry, but I think you would get a lot of mileage in 
> front of a judge who was not FOSS developer with that argument. The best 
> argument that it is a explicit license is that the name of the file 'LICENSE' 
> is the explicit license, but that leaves those folks using COPYLEFT out to 
> dry. At best including the text of a license is an implied license and is 
> supported by the practice of the trade so it is reasonable to rely on it.
> Q2: To address the second question, I think you need to at the very least 
> accept that the license include in the LICENSE file is the license of the 
> code base. But then it seems contradictory to me to look at the full text of 
> GPLv2 and conclude that means GPL but it doesn't specify which version of the 
> GPL. At best I would think the implied license created by including the text 
> of a license in a LICENSE file is "the license of this code base is as 
> specified in the LICENSE file." And that license file clearly specifies the 
> GPLv2, so by the terms of the GPLv2 it would not have left the version 
> unspecified allowing you to choose any version of the GPL. 
> If you do not buy the argument that the text of the license by its nature 
> specifies the version of the license, then I will argue that Section 0 of 
> GPLv2 states that "*This* License applies to any program or other work which 
> contains a notice placed by the copyright holder saying it may be distributed 
> under the terms of this 

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

[J Lovejoy]

Hi Trevor,

It took me a second, but now I see where you are going:

In my example, the text file with the license text of GPL-2.0 _is_ exactly that 
- the text of the license (hence identifying it as such), however that is not 
necessarily the license for the text of the license itself.  Hence, you 
suggestion to identify that accurately.  

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. The operative question in this case becomes: did the 
author intend by putting a copy of GPL-2.0 to " specif[ying] a version number 
of the license which applies to it” (in which case, I think everyone would 
agree that the project license and license for the source files would be 
GPL-2.0+) or does it not and is that not enough to specify a version number 
(thus, it is GPL-1.0+). Ideally, one would ask the author of the code for this 
clarification (and for them to add the standard license headers accordingly, 
like the license suggests!).   In absence, someone trying to figure out what 
license applies to the package here, is left to make some kind of reasonable 
conclusion.  Guidance as to the intent of the license from the FSF would be 
helpful here all around and perhaps could help dissuade from this example 
occurring.

In any case, I’m not sure we need to worry so much about identifying the 
license of the license. If we made a new identifier for the purposes here, as 
you suggest, where would the leave MIT, BSD-3-Clause, etc.?  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?

Thanks,
Jilayne

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


> On Sep 7, 2017, at 1:21 PM, W. Trevor King  wrote:
> 
> 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.
> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal

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

Re: New license proposal: Verbatim

[Richard Fontana]

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

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

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

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

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

Richard

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

Re: New license 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