Re: Packaging text licenses

[Francesco Poli]

On Sun, 15 Dec 2019 14:25:47 +0100 Jonas Smedegaard wrote:

[...]
> As others in this thread have pointed out, Debian explicitly omits 
> classifying license fulltexts as "free software" or "non-free software".

Frankly speaking, I cannot find a message in this thread where others
pointed out that license texts are not software.

But anyway...

> 
> As I understand it, you personally classify license fulltexts as 
> "non-free software" and then add a rule that they are exceptionally 
> accepted in main under specific narrow circumstances.
> 
> If you agree with above, Francesco, then I suggest going forward that we 
> talk about the "license fulltexts are non-free software but accepted 
> narrowly in main" as being a _proposal_ rather than current rules in 
> Debian.

Actually, I have always thought this as the accepted Debian practice,
not as a proposal of mine!
The already cited [message by Glenn Maynard] shows that other people
viewed it that way back in 2005.

[message by Glenn Maynard]: 


I am quite convinced that the same idea has been expressed on
debian-legal more than once, since 2004 (the time when I became an
active participant).
It's just not easy to search for the evidence, since searching for
keywords such as "license" and "exception" on the debian-legal archive
results in an overwhelming number of false positives (where the topic
under discussion was the GNU GPL and appropriate linking exceptions,
e.g. to allow linking a GPL-licensed work with the OpenSSL library!).

> 
> Perhaps that shift might also help you being less perplexed? :-)

No, I am even more perplexed, after reading your reply...   :-/


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpM5_ztxgwnF.pgp
Description: PGP signature

Re: Packaging text licenses

[MJ Ray]

2019-12-15 1:26:28 PM Jonas Smedegaard : [...]
> As others in this thread have pointed out, Debian explicitly omits
> classifying license fulltexts as "free software" or "non-free software".
>
> As I understand it, you personally classify license fulltexts as
> "non-free software" and then add a rule that they are exceptionally
> accepted in main under specific narrow circumstances. [...]

I think personalising this discussion does not help anything.

How could one classify licence fulltexts that would enable them to be included 
in Debian under current rules otherwise?

Those packages using licence texts feel a bit like ones that display an 
included non-free image in response to certain actions and I am fairly sure 
that has not been acceptable in the past.

-- 

MJR - please excuse brevity because this was sent while mobile

Re: Packaging text licenses

[jrb3-beckenbach.us]

Greetings, all!

[Lurker in the Debian space, decloaking to ask a clarification.]

On 15 Dec 2019, at 07:01, Francesco Poli  wrote:
> 
> But can DFSG-free data be prepared for the test suite of a program
> intended to identify licenses?!? How can I test whether the program is
> able to identify CC-by-nc-nd-v1.0 *without* feeding it the actual text
> of that same license?!?

A subset of the more general “can Debian core ship non-free *data*”.
Is this not already addressed, eg by games which can use paid-for data but ship 
in Debian with replacement assets?
If so, the whole-as-one-package of licensecheck should ship analogously, 
barring exception for “fair use”/non-US-equivalents.
What am I missing here?

Perhaps an argument this is really shipping a convenience *cache* of 
freely-available read-only texts.
(You’re not being bound to anything if you download license texts from eg 
choosealicense.com  or Apple’s legal site ….)
Are there existing Debian packages which perform this role already?
If so, analogize from those?

If licensecheck would thus ship as contrib or non-free, maybe split off the 
contrib and non-free data portions
into separate plug-in packages, which depend on licensecheck and which the core 
licensecheck could “suggest”?

Thanks!

Joseph

Re: Packaging text licenses

[Jonas Smedegaard]

Quoting Francesco Poli (2019-12-15 13:01:16)
> On Sat, 14 Dec 2019 17:41:14 +0100 Jonas Smedegaard wrote:
> 
> > Quoting Francesco Poli (2019-12-14 17:22:09)
> [...]
> > > I don't think the exception may also apply when the license text 
> > > is the *actual payload* of the package (for instance, a package 
> > > shipping the text for CC-by-nc-nd-v1.0, when nothing in the 
> > > package itself is released under that license).
> [...]
> > 
> > That's an interesting view.
> > 
> > Several packages now in Debian main contain license fulltexts 
> > without those licensing terms being applied at all to the project 
> > covered by that package.
> > 
> > Examples:
> > 
> >   * licensecheck - includes license fulltexts in its testsuite
> 
> I am perplexed: I fully understand the usefulness of packages such as 
> licensecheck, decopy, and so forth, and I acknowledge the need for 
> actual data in their test suites...
> 
> But on the other hand, can non-free data be shipped in the test suite 
> of a source package in Debian main?

Evidently it can - question is if we are breaking a rule by doing so.

As others in this thread have pointed out, Debian explicitly omits 
classifying license fulltexts as "free software" or "non-free software".

As I understand it, you personally classify license fulltexts as 
"non-free software" and then add a rule that they are exceptionally 
accepted in main under specific narrow circumstances.

If you agree with above, Francesco, then I suggest going forward that we 
talk about the "license fulltexts are non-free software but accepted 
narrowly in main" as being a _proposal_ rather than current rules in 
Debian.

Perhaps that shift might also help you being less perplexed? :-)

[ dropping remaining questions until surreounding logic is clarified ]


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Packaging text licenses

[Francesco Poli]

On Sat, 14 Dec 2019 17:41:14 +0100 Jonas Smedegaard wrote:

> Quoting Francesco Poli (2019-12-14 17:22:09)
[...]
> > I don't think the exception may also apply when the license text is 
> > the *actual payload* of the package (for instance, a package shipping 
> > the text for CC-by-nc-nd-v1.0, when nothing in the package itself is 
> > released under that license).
[...]
> 
> That's an interesting view.
> 
> Several packages now in Debian main contain license fulltexts without 
> those licensing terms being applied at all to the project covered by 
> that package.
> 
> Examples:
> 
>   * licensecheck - includes license fulltexts in its testsuite

I am perplexed: I fully understand the usefulness of packages such as
licensecheck, decopy, and so forth, and I acknowledge the need for
actual data in their test suites...

But on the other hand, can non-free data be shipped in the test suite
of a source package in Debian main?
For many kinds of package, DFSG-free data may be specifically prepared
for the test suite.
But can DFSG-free data be prepared for the test suite of a program
intended to identify licenses?!? How can I test whether the program is
able to identify CC-by-nc-nd-v1.0 *without* feeding it the actual text
of that same license?!?

This looks like a really hard problem.

>   * libsoftware-license-perl - purpose of project is to emit licenses

This seems to be even more troublesome: here the license texts are not
just shipped in the source package as test suite data. They are
included in the package as "functional" data, without which the package
cannot accomplish its goal.
Yet, a number of those license texts are non-free texts...

I understand the convenience of this library, but is it really
DFSG-free?!?

> 
> I have several times discovered projects shipping with e.g. GPL-3 but 
> nothing in the project was licensed under that license.  I find it 
> highly likely that there are plenty of such cases still in Debian - 
> including ones where the "stray" license contain a non-modification 
> clause (which I guess is the most likely non-Freeness in license 
> fulltexts.

These cases really look like bugs to be fixed.

If nothing in the project is licensed under the terms of the
GNU GPL v3, then why does the project include the text of that
license at all?!?

> 
> Are all such packages in violation of DFSG?

That's a hard question.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpdnQnnf192R.pgp
Description: PGP signature

Re: Packaging text licenses

[Jonas Smedegaard]

Quoting Francesco Poli (2019-12-14 17:22:09)
> On Sat, 14 Dec 2019 14:01:18 +0100 Baptiste BEAUPLAT wrote:
> 
> > On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
> > > A rich collection of Free license fulltexts is relevant, not only 
> > > for our users to pick from (even on a lonely island) and copy into 
> > > new development project, but also as reference e.g. for testing 
> > > license checkers.
> > > 
> > > What is _not_ helpful in my opinion, however, is yet another 
> > > manually curated selection of random license texts.  What I see 
> > > generally useful is to package this: 
> > > https://github.com/spdx/license-list-XML
> > 
> > That looks like a great list to package. I'll need input on the 
> > repository license status from the legal team as it could be 
> > ambiguous
> 
> I would be extremely cautious before including license texts as 
> content to be shipped by a Debian package.
> 
> A number of license texts are not themselves licensed under DFSG-free 
> terms.
> 
> And Debian promises to remain 100 % free, see [SC] #1. Any content of 
> a Debian package (in main) must be free according to the DFSG.
> 
> [SC]: 
> 
> License texts are usually [considered] the sole exception, but I think 
> the exception only applies when the license text is included in the 
> package *for the sole purpose* of documenting the legal terms under 
> which some part of the package is released.
> I don't think the exception may also apply when the license text is 
> the *actual payload* of the package (for instance, a package shipping 
> the text for CC-by-nc-nd-v1.0, when nothing in the package itself is 
> released under that license).
> 
> [considered]: 

That's an interesting view.

Several packages now in Debian main contain license fulltexts without 
those licensing terms being applied at all to the project covered by 
that package.

Examples:

  * licensecheck - includes license fulltexts in its testsuite
  * libsoftware-license-perl - purpose of project is to emit licenses

I have several times discovered projects shipping with e.g. GPL-3 but 
nothing in the project was licensed under that license.  I find it 
highly likely that there are plenty of such cases still in Debian - 
including ones where the "stray" license contain a non-modification 
clause (which I guess is the most likely non-Freeness in license 
fulltexts.

Are all such packages in violation of DFSG?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Packaging text licenses

[Francesco Poli]

On Sat, 14 Dec 2019 14:01:18 +0100 Baptiste BEAUPLAT wrote:

> On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
> > A rich collection of Free license fulltexts is relevant, not only for 
> > our users to pick from (even on a lonely island) and copy into new 
> > development project, but also as reference e.g. for testing license 
> > checkers.
> > 
> > What is _not_ helpful in my opinion, however, is yet another manually 
> > curated selection of random license texts.  What I see generally useful 
> > is to package this: https://github.com/spdx/license-list-XML
> 
> That looks like a great list to package. I'll need input on the
> repository license status from the legal team as it could be ambiguous

I would be extremely cautious before including license texts as content
to be shipped by a Debian package.

A number of license texts are not themselves licensed under DFSG-free
terms.

And Debian promises to remain 100 % free, see [SC] #1. Any content of a
Debian package (in main) must be free according to the DFSG.

[SC]: 

License texts are usually [considered] the sole exception, but I think
the exception only applies when the license text is included in the
package *for the sole purpose* of documenting the legal terms under
which some part of the package is released.
I don't think the exception may also apply when the license text is the
*actual payload* of the package (for instance, a package shipping the
text for CC-by-nc-nd-v1.0, when nothing in the package itself is
released under that license).

[considered]: 



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp450RHm8WTt.pgp
Description: PGP signature

Re: Packaging text licenses

[Jonas Smedegaard]

Quoting Baptiste BEAUPLAT (2019-12-14 15:12:38)
> On 12/14/19 2:01 PM, Baptiste BEAUPLAT wrote:
> > On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
> >> A rich collection of Free license fulltexts is relevant, not only 
> >> for our users to pick from (even on a lonely island) and copy into 
> >> new development project, but also as reference e.g. for testing 
> >> license checkers.
> >>
> >> What is _not_ helpful in my opinion, however, is yet another 
> >> manually curated selection of random license texts.  What I see 
> >> generally useful is to package this: 
> >> https://github.com/spdx/license-list-XML
> 
> I had another look around the repository. The tool used to "compile" 
> those XML files into text, html, json and so on is written in java 
> with a lot of dependencies that are not present in Debian yet.
> 
> I am not willing to introducing dozens of new packages just to produce 
> a text result of those sources files.
> 
> I'm wondering if packaging the "data" repository[1] would be 
> acceptable? On one hand it is generated, but one the other, it is 
> still plain text files.

That's similar pain as for many JavaScript packages and fonts...

Sure, you can try convince Debian that this project is special and don't 
need source.  That has been tried numerous times e.g. for JavaScript 
packages and fonts, and I don't recommend going down that route...

What I recommend i to try piece together an alternative XML processing 
which produces same output as the Java-based ones used upstream.

I'd be happy to help with that.  My preferred hacking environments are 
shell and perl.  If yours is different then I will be of less help.  
Let's discuss further in the #licenses channel if interested.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Packaging text licenses

[Baptiste BEAUPLAT]

On 12/14/19 2:01 PM, Baptiste BEAUPLAT wrote:
> On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
>> A rich collection of Free license fulltexts is relevant, not only for 
>> our users to pick from (even on a lonely island) and copy into new 
>> development project, but also as reference e.g. for testing license 
>> checkers.
>>
>> What is _not_ helpful in my opinion, however, is yet another manually 
>> curated selection of random license texts.  What I see generally useful 
>> is to package this: https://github.com/spdx/license-list-XML

I had another look around the repository. The tool used to "compile"
those XML files into text, html, json and so on is written in java with
a lot of dependencies that are not present in Debian yet.

I am not willing to introducing dozens of new packages just to produce a
text result of those sources files.

I'm wondering if packaging the "data" repository[1] would be acceptable?
On one hand it is generated, but one the other, it is still plain text
files.

[1]: https://github.com/spdx/license-list-data

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Re: Packaging text licenses

[Baptiste BEAUPLAT]

On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
> A rich collection of Free license fulltexts is relevant, not only for 
> our users to pick from (even on a lonely island) and copy into new 
> development project, but also as reference e.g. for testing license 
> checkers.
> 
> What is _not_ helpful in my opinion, however, is yet another manually 
> curated selection of random license texts.  What I see generally useful 
> is to package this: https://github.com/spdx/license-list-XML

That looks like a great list to package. I'll need input on the
repository license status from the legal team as it could be ambiguous
from what I read in issues:

[Add top level license to license list code and files][1]
and
[Clarify under which license the license list itself is licensed][2].

> If you are interested in license checkers, then please consider joining 
> others with same interest at the irc channel #licenses on OFTC.net.
> 
> Related is also https://wiki.debian.org/CopyrightReviewTools

Thanks for the pointers. Although my particular use case stops to new
projects, it could certainly be expended to benefit license checkers.

[1]: https://github.com/spdx/license-list-XML/issues/683
[2]: https://github.com/spdx/license-list-XML/issues/648

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Re: Packaging text licenses

[Jonas Smedegaard]

Hi Baptiste,

Quoting Baptiste BEAUPLAT (2019-12-14 11:55:40)
> Yesterday, I was looking for the CC-BY license text to start a new 
> project.
> 
> I had to dig up to CreativeCommons's github repository to find the 
> text version. (I didn't want to copy/paste the HTML version on their 
> website).
> 
> My question to you is: "Would it be interesting for others if I were 
> to create a package with missing text version of licenses?"
> 
> Currently, in debian, we have the /usr/share/common-licenses/ that 
> includes a couple of one, but is missing CC- and MIT for instance. I 
> would find it useful to just cp the file to new projects.
> 
> @debian-legal: How text license are qualified regarding their 
> licenses? Can 'legal text' can be considered as public domain and 
> packaged with whatever license (MIT/GPL) ?

A rich collection of Free license fulltexts is relevant, not only for 
our users to pick from (even on a lonely island) and copy into new 
development project, but also as reference e.g. for testing license 
checkers.

What is _not_ helpful in my opinion, however, is yet another manually 
curated selection of random license texts.  What I see generally useful 
is to package this: https://github.com/spdx/license-list-XML

If you are interested in license checkers, then please consider joining 
others with same interest at the irc channel #licenses on OFTC.net.

Related is also https://wiki.debian.org/CopyrightReviewTools


Kind regards,

 - Jonas

Maintainer and current upstream author of Licensecheck

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature