Re: Packaging text licenses

2019-12-21 Thread 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


pgpEHLEdfqgWK.pgp
Description: PGP signature


Re: Packaging text licenses

2019-12-17 Thread Paul Wise
On Tue, Dec 17, 2019 at 9:25 PM Thomas Goirand wrote:

> If we are already shipping the license (non-free) text as part of
> packages, what difference would it make to have them all shipped in a
> single package? Can't the exception also apply to that one package Jonas
> is suggesting?

One difference is that in the normal case, the license often says we
*must* ship a copy of the license when shipping a copy of the
software. In the case of a package that ships copies of licenses
without the licenses applying to anything in the package, that
obligation doesn't exist.

Personally, because of the above consideration, I consider that
probably collections of licenses shouldn't be shipped in main. OTOH,
base-files: /usr/share/common-licenses/ exists so perhaps Debian
already ignores this issue.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Packaging text licenses

2019-12-17 Thread Jonas Smedegaard
Quoting Thomas Goirand (2019-12-17 22:24:56)
> On 12/15/19 10:21 PM, Jonas Smedegaard wrote:
> > Quoting Andrey Rahmatullin (2019-12-15 21:02:19)
> >> On Sun, Dec 15, 2019 at 02:25:47PM +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".
> >> Where does it explicitly do that?
> >> We do that implicitly.
> > 
> > Yes you are right. Thanks for correcting me.
> > 
> >  - Jonas
> 
> If we are already shipping the license (non-free) text as part of 
> packages, what difference would it make to have them all shipped in a 
> single package? Can't the exception also apply to that one package 
> Jonas is suggesting?
> 
> After reading all of this thread, I'm still not convince as to why it 
> should be forbidden.

As I read it, only Francesco says in this thread that license fulltexts 
should be (or already are) forbidden.

In case that matters to your concerns.


 - 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

2019-12-17 Thread Thomas Goirand
On 12/15/19 10:21 PM, Jonas Smedegaard wrote:
> Quoting Andrey Rahmatullin (2019-12-15 21:02:19)
>> On Sun, Dec 15, 2019 at 02:25:47PM +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".
>> Where does it explicitly do that?
>> We do that implicitly.
> 
> Yes you are right. Thanks for correcting me.
> 
>  - Jonas

If we are already shipping the license (non-free) text as part of
packages, what difference would it make to have them all shipped in a
single package? Can't the exception also apply to that one package Jonas
is suggesting?

After reading all of this thread, I'm still not convince as to why it
should be forbidden.

Cheers,

Thomas Goirand (zigo)



Re: Packaging text licenses

2019-12-15 Thread Jonas Smedegaard
Quoting Andrey Rahmatullin (2019-12-15 21:02:19)
> On Sun, Dec 15, 2019 at 02:25:47PM +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".
> Where does it explicitly do that?
> We do that implicitly.

Yes you are right. Thanks for correcting me.

 - 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

2019-12-15 Thread Andrey Rahmatullin
On Sun, Dec 15, 2019 at 02:25:47PM +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".
Where does it explicitly do that?
We do that implicitly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Packaging text licenses

2019-12-15 Thread Andrey Rahmatullin
On Sun, Dec 15, 2019 at 09:05:19AM -0500, jrb3-beckenbach.us wrote:
> A subset of the more general “can Debian core ship non-free *data*”.
Officially no, as already mentioned in this thread.

> Perhaps an argument this is really shipping a convenience *cache* of 
> freely-available read-only texts.
Shipping a convenience cache of freely-available read-only RFCs is
known to be forbidden in Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Packaging text licenses

2019-12-15 Thread 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

2019-12-15 Thread 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

2019-12-15 Thread 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


pgpR9auFg4Jqe.pgp
Description: PGP signature


Re: Packaging text licenses

2019-12-14 Thread Andrey Rahmatullin
On Sat, Dec 14, 2019 at 05:22:09PM +0100, Francesco Poli wrote:
> 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.
Sure.

> License texts are usually [considered] the sole exception
They are just not considered. I don't think this exception is written
anywhere. And I don't think SC allows exceptions not mentioned in it.
There are many things in Debian which are just not talked about, this is one
of them.

> 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.
This, stronger, statement, is of course not written anywhere either.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Packaging text licenses

2019-12-14 Thread Russ Allbery
Francesco Poli  writes:

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

For example, the GNU General Public License.

 Copyright (C) 2007 Free Software Foundation, Inc. 
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

-- 
Russ Allbery (r...@debian.org)  



Re: Packaging text licenses

2019-12-14 Thread 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

2019-12-14 Thread 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


pgpmUAUFx6wpi.pgp
Description: PGP signature


Re: Packaging text licenses

2019-12-14 Thread 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

2019-12-14 Thread 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

2019-12-14 Thread 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

2019-12-14 Thread 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


Re: Packaging text licenses

2019-12-14 Thread Baptiste BEAUPLAT
On 12/14/19 12:27 PM, Andrius Merkys wrote:
> It's https://creativecommons.org/licenses/by/4.0/legalcode.txt. One just
> has to add .txt suffix to legal code link URL.

Ah thanks Andrius, I was completely oblivious to that.

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature


Re: Packaging text licenses

2019-12-14 Thread Andrius Merkys
Hi Baptiste,

On Sat, 14 Dec 2019, 13:04 Baptiste BEAUPLAT,  wrote:

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

It's https://creativecommons.org/licenses/by/4.0/legalcode.txt. One just
has to add .txt suffix to legal code link URL.

Andrius