Re: Compatibility of GPLv2 and Apache v2 (OpenSSL again)

2018-12-04 Thread Ben Finney
Sebastian Andrzej Siewior  writes:

> GPL software has an exception clause in order to link against OpenSSL
> which has the advertising clause.

This appears to be a statement that any work licensed under GNU GPL has
such an exception. That is not true, to my knowledge.

> Clamav for instance has this piece:

Right. That piece is not part of any version of the GPL; it is an
additional clause in the grant for recipients of that specific work
(ClamAV).

So each work needs to be examined for its specific grant, to see what
the full combination of effective license conditions are to the
recipient of that specific work.

> OpenSSL upstream now switched the license from BSD style to Apache
> License 2.0.

What can you cite for that change?

The official OpenSSL site contradicts that claim. According to
https://www.openssl.org/source/license.html>, OpenSSL is subject to
the conditions of the terms of both OpenSSL License and, simultaneously,
Original SSLEay License. Neither of these is Apache License 2.0.

-- 
 \   “I have always wished for my computer to be as easy to use as |
  `\   my telephone; my wish has come true because I can no longer |
_o__)  figure out how to use my telephone.” —Bjarne Stroustrup |
Ben Finney



Compatibility of GPLv2 and Apache v2 (OpenSSL again)

2018-12-04 Thread Sebastian Andrzej Siewior
Hi,

GPL software has an exception clause in order to link against OpenSSL
which has the advertising clause. Clamav for instance has this piece:

| In addition, as a special exception, the copyright holders give
| permission to link the code of portions of this program with the
| OpenSSL library under certain conditions as described in each
| individual source file, and distribute linked combinations
| including the two.

OpenSSL upstream now switched the license from BSD style to Apache
License 2.0.
My understanding is that GPLv2 software can not be linked against Apache
v2 software due to the patent issue. GPLv3 (or GPLv2 or alter) can be
linked but that is not the issue here.

Can such an exception in GPLv2 software be used in order to link against
Apache v2 software or is this not possible anymore?

Sebastian



Bug#915537: MongoDB SSPL v1 license and the DFSG

2018-12-04 Thread Apollon Oikonomopoulos
Package: ftp.debian.org
Severity: normal

[ Continuing the thread in debian-legal[0] and Cc'ing debian-legal as 
  well ]

Dear FTP masters,

I would like your opinion on whether MongoDB's new SSPL license is 
suitable for inclusion in the main archive. To give a bit of background, 
MongoDB was previously distributed under a mixed AGPL-3.0/Apache-2.0 
license. On 2018-10-15, upstream did a commit replacing AGPL-3.0 with 
the new Server Side Public License Version 1[1] — of which MongoDB is 
the steward. The same change was backported to two stable branches, with 
the 3.6.9 and 4.0.4 stable revisions carrying the new license.

MongoDB has submitted the license to OSI for review[2]; the discussion 
there is still ongoing, but the initial response seems to be negative.  
In essence, the license (at least v1 which is currently in use) is 
almost identical to AGPL-3.0, with the exception of Section 13, which 
states:

> 13. Offering the Program as a Service.
>
> If you make the functionality of the Program or a modified version 
> available to third parties as a service, you must make the Service 
> Source Code available via network download to everyone at no charge, 
> under the terms of this License. Making the functionality of the 
> Program or modified version available to third parties as a service 
> includes, without limitation, enabling third parties to interact with 
> the functionality of the Program or modified version remotely through 
> a computer network, offering a service the value of which entirely or 
> primarily derives from the value of the Program or modified version, 
> or offering a service that accomplishes for users the primary purpose 
> of the Program or modified version.
> 
> “Service Source Code” means the Corresponding Source for the Program 
> or the modified version, and the Corresponding Source for all programs 
> that you use to make the Program or modified version available as a 
> service, including, without limitation, management software, user 
> interfaces, application program interfaces, automation software, 
> monitoring software, backup software, storage software and hosting 
> software, all such that a user could run an instance of the service 
> using the Service Source Code you make available.

What this section says (at least to my eyes), is that the SSPL requires 
*all software* interfacing with MongoDB to form a "service" to be 
licensed under the SSPL too. This is a much broader restriction than 
linking, but still does not seem to violate DFSG #9. It is also not a 
universal restriction, but one that is based on use/field of endeavor:

 + The same ancillary software, when made part of a "MongoDB 
   service", must be licensed under the SSPL, while when used for 
   other purposes may carry any license.

 + Conversely, when building a service around MongoDB, you are only 
   allowed to use SSPL-licensed software to build that service, 
   something that may turn out to be impractical or even impossible.

Note that this does not violate DFSG #6, as it does not prohibit *using* 
MongoDB itself for specific purposes, but it places heavy restrictions 
on *other* software you are able to use alongside MongoDB to build a 
service (for instance you can use bacula to backup your personal MongoDB 
instance, but you can't use bacula to backup your MongoDB-as-a-service 
unless bacula switches to SSPL). This has been somewhat rectified
in v2, which was submitted to OSI for review[3], but the spirit remains.

Also note that judging whether something is a "MongoDB service" depends 
on how much of its value it derives from MongoDB, or whether its primary 
purpose is "MongoDB", criteria that are both rather vague in themselves.

Finally, I worry that "enabling third parties to interact with the 
functionality of the Program […] remotely through a computer network" 
could be interpreted to also include Debian packages, in which case the 
above restrictions would apply to the Debian infrastructure as well.

Given the above and the fact that I'm not aware of any similar precedent 
in the archive, I would like your opinion on the license's DFSG 
compatibility. My personal view is that while the license does not 
violate the DFSG directly, it also does not agree with the DFSG's spirit 
(esp. DFSG #6).

If we deem the license to be DFSG-incompatible, then MongoDB will most 
likely have to be removed from the archive eventually; keeping the last 
AGPL-licensed version around without the ability to cherry-pick commits 
from upstream is not viable (definitely so for inclusion in stable), 
given the size and the complexity of the codebase.

Regards,
Apollon


[0] https://lists.debian.org/debian-legal/2018/10/msg1.html
[1] https://www.mongodb.com/licensing/server-side-public-license
[2] 
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html
[3] 
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.ht

Re: Hacking License

2018-12-04 Thread Giacomo Tesio
Il giorno mar 4 dic 2018 alle ore 12:07 Xavier  ha scritto:
>
> Le 04/12/2018 à 11:17, Giacomo Tesio a écrit :
> >
> > To be honest, to my untrained eye the tentacle of evil test might be a
> > case against GNU License common use of "or (at your option) any later
> > version." because if a project moves to an _apparently_ good new
> > version of GPL and accept patches under it, and then turns out that
> > the upgrade had issues, they might have huge troubles to go back at a
> > previous version.
>
> No, the software you gave is usable with current license even if next
> version is more restrictive (you can then fork). "Tentacle of Evil test"
> forbids the author to restrict later what is covered now with the
> current license (see French difference between "gratuit" and "libre":
> both translated to "free").

No sorry I explained my doubt badly.

I'm thinking of a project X licensed as GPLv3+ that after the release
of GPLv4 decide to move to GPLv4+ (as happened to many GPLv2+
projects).

This is fine and expected, unless Hydra manages to infiltrate FSF with
a couple of cool lawyers and to corrupt the text in some overlooked
way.
In this case, if after a couple of years Hydra start suing people
according to such overlooked detail, people would have a hard issue to
go back to GPLv3 without discarging all the patches provided.

A corner case, I know... but pretty in line with the Tentacle of Evil
theme... :-)


Giacomo



Re: Hacking License

2018-12-04 Thread Xavier
Le 04/12/2018 à 11:17, Giacomo Tesio a écrit :
> Hi Xavier actually, before writing to the debian-legal list, I
> compared the license against the three tests
> (I've found the "The tentacle of evil test" on the Wikipedia page
> about DFSG, 
> https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance).
> 
> Il giorno mar 4 dic 2018 alle ore 10:41 Xavier  ha scritto:
>>
>> Le 04/12/2018 à 10:07, Giacomo Tesio a écrit :
>>> If, on the other hand, no new copyleft license is allowed to enter
>>> Debian, I'm fine with it, but I think this should be clearly stated
>>> somewhere in the social contract.
>>
>> No Debian accepts any license that are DFSG compliant (DFSG is just a
>> guidelines). You may use the 3 tests to understand what may be wrong :
>>  * https://wiki.debian.org/DesertIslandTest
> 
> The Hacking License only requires to distribute sources of Derived
> Works to the users of such Derived Work, so it passes this test.
> 
>>  * https://wiki.debian.org/DissidentTest
> 
> Same as above.
> 
>>  * The tentacle of evil test (not found in wiki, why ?):
>>"Imagine that the author is hired by a large evil corporation and,
>>now in their thrall, attempts to do the worst to the users of the
>>program: to make their lives miserable, to make them stop using the
>>program, to expose them to legal liability, to make the program non-
>>free, to discover their secrets, etc. The same can happen to a
>>corporation bought out by a larger corporation bent on destroying
>>free software in order to maintain its monopoly and extend its evil
>>empire. To be free, the license cannot allow even the author to take
>>away the required freedoms."
> 
> To be honest this puzzled me a bit: is "the author" here
> 1. the author of the software or
> 2. the author of the license?

The author of things covered by license

> In case of 1, if the authors of the software violates the right of
> users, his grants on any patch they received terminate, including the
> copyright assignment that let them update the license.
> In case of 2, if the author of the Hacking License get hired by a
> large evil corporation (trust me, very unlikely in practice...
> compared to me, Linus has been such a kind guy all these years... :-D)
> I cannot change the license of any software licensed under the Hacking
> License.
> 
> To be honest, to my untrained eye the tentacle of evil test might be a
> case against GNU License common use of "or (at your option) any later
> version." because if a project moves to an _apparently_ good new
> version of GPL and accept patches under it, and then turns out that
> the upgrade had issues, they might have huge troubles to go back at a
> previous version.

No, the software you gave is usable with current license even if next
version is more restrictive (you can then fork). "Tentacle of Evil test"
forbids the author to restrict later what is covered now with the
current license (see French difference between "gratuit" and "libre":
both translated to "free").



Re: Hacking License

2018-12-04 Thread Giacomo Tesio
Hi Xavier actually, before writing to the debian-legal list, I
compared the license against the three tests
(I've found the "The tentacle of evil test" on the Wikipedia page
about DFSG, 
https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance).

Il giorno mar 4 dic 2018 alle ore 10:41 Xavier  ha scritto:
>
> Le 04/12/2018 à 10:07, Giacomo Tesio a écrit :
> > If, on the other hand, no new copyleft license is allowed to enter
> > Debian, I'm fine with it, but I think this should be clearly stated
> > somewhere in the social contract.
>
> No Debian accepts any license that are DFSG compliant (DFSG is just a
> guidelines). You may use the 3 tests to understand what may be wrong :
>  * https://wiki.debian.org/DesertIslandTest

The Hacking License only requires to distribute sources of Derived
Works to the users of such Derived Work, so it passes this test.

>  * https://wiki.debian.org/DissidentTest

Same as above.

>  * The tentacle of evil test (not found in wiki, why ?):
>"Imagine that the author is hired by a large evil corporation and,
>now in their thrall, attempts to do the worst to the users of the
>program: to make their lives miserable, to make them stop using the
>program, to expose them to legal liability, to make the program non-
>free, to discover their secrets, etc. The same can happen to a
>corporation bought out by a larger corporation bent on destroying
>free software in order to maintain its monopoly and extend its evil
>empire. To be free, the license cannot allow even the author to take
>away the required freedoms."

To be honest this puzzled me a bit: is "the author" here
1. the author of the software or
2. the author of the license?

In case of 1, if the authors of the software violates the right of
users, his grants on any patch they received terminate, including the
copyright assignment that let them update the license.
In case of 2, if the author of the Hacking License get hired by a
large evil corporation (trust me, very unlikely in practice...
compared to me, Linus has been such a kind guy all these years... :-D)
I cannot change the license of any software licensed under the Hacking
License.

To be honest, to my untrained eye the tentacle of evil test might be a
case against GNU License common use of "or (at your option) any later
version." because if a project moves to an _apparently_ good new
version of GPL and accept patches under it, and then turns out that
the upgrade had issues, they might have huge troubles to go back at a
previous version.

But... you know... IANAL... ;-)


Giacomo



Re: Hacking License

2018-12-04 Thread Giacomo Tesio
Hi Andrej thanks for your objections.

Il giorno mar 4 dic 2018 alle ore 09:58 Andrej Shadura
 ha scritto:
> > In particular, I have
> > 1) removed requirement to change the logo (see [1] from Francesco Poli).
> >That requirements was not there to protect the brand of the authors but
> >to protect the users from being fooled to use a modified version
> >instead of the original;
>
> That still effectively forbids your software from being packaged.

Mind to elaborate why?
A package might help the user to interactively replace the file, use
Debian's "alternatives" (or equivalent) or simply create a symbolic
link.

Maybe I'm misreading DFSG 4?

> > 2) left requirement to change the name, because the definition of "use"
> >already allows the users to store a Derived Work in place of the Hack;
>
> So if I want to patch a security vulnerability, I have to bikeshed a
> name? Please no.

This is a good point, thanks!
As I said my goal is to protect people from being fooled to use (even
remotely, as a service) a modified version of the software in place of
the original.

I see two solutions to this interpretation issue:
1) s/Derived Work under this License but/Derived Work under this
License as either source patches or/
2) s/but with a different name/but clearly informing its users about
the differences with the Hack./

Solution 1 seems less prone to interpretations and easier to comply
unambigously.
OTOH, solution 2 is more general and clearly states the intent of the
hackers, so I would prefer this.

What your take?


Giacomo



Re: Hacking License

2018-12-04 Thread Xavier
Le 04/12/2018 à 10:07, Giacomo Tesio a écrit :
> Il December 4, 2018 6:04:59 AM UTC, Ben Finney  ha 
> scritto:
>> If you want to release a work of software compatible with Debian, please
>> do everyone – yourself included – a huge favour and choose an existing,
>> well-understood, known-by-copyright-experts-to-be-effective free
>> license already used for many existing software works.
> 
> Hi Ben thanks for your advice. I know you mean well.
> 
> 
> It's not my intention to abuse the debian-legal mailing list, I was
> really looking for compatibility issues between the Hacking License
> and the DFSG in the hope to address them before the widespread
> adoption of the software it cover and the license.
> 
> While the copyright attribution embedded in the Hacking License is
> designed to make updates to the license possible, I cannot be sure
> that the changes that Debian would require would be compatible with
> the rights granted to the users after the release, actually making the
> software incompatible with Debian (the upstream copyright attribution
> is terminated, like other grants, on violation of users rights).
> 
> I appreciate the feedbacks shared so far by Debian Legal volunteers,
> and integrated them in the new version of the license to this aim.
> 
> 
> If no further incompatibility exists between the Hacking License and
> the DFSG, I will not annoy the list anymore.
> If, on the other hand, no new copyleft license is allowed to enter
> Debian, I'm fine with it, but I think this should be clearly stated
> somewhere in the social contract.

No Debian accepts any license that are DFSG compliant (DFSG is just a
guidelines). You may use the 3 tests to understand what may be wrong :
 * https://wiki.debian.org/DesertIslandTest
 * https://wiki.debian.org/DissidentTest
 * The tentacle of evil test (not found in wiki, why ?):
   "Imagine that the author is hired by a large evil corporation and,
   now in their thrall, attempts to do the worst to the users of the
   program: to make their lives miserable, to make them stop using the
   program, to expose them to legal liability, to make the program non-
   free, to discover their secrets, etc. The same can happen to a
   corporation bought out by a larger corporation bent on destroying
   free software in order to maintain its monopoly and extend its evil
   empire. To be free, the license cannot allow even the author to take
   away the required freedoms."

> Same if this is a problem of license authorship (because I'm neither a
> lawyer nor a committee) or affiliation.
> 
> Ultimately, if "strongly discouraged" actually means "forbidden" I
> just need to know it.
> 
>> However, you are strongly seeking feedback not on the work of software,
>> but on your new license text.
> 
> No, let's be clear on this: I **welcome** all feedbacks about the
> license's text, but here I'm **seeking** just for
> _incompatibilities_with_DFSG_.
> I didn't release the software yet because it's innovative by itself
> and I need an appropriate license to more effectively protect the
> users' freedom in a strongly distributed computing platform.
> 
> Giacomo



Re: Hacking License

2018-12-04 Thread Andrej Shadura
On Tue, 4 Dec 2018 at 01:34, Giacomo Tesio  wrote:
>
> Hi, I've just published a new version of the Hacking License that
> receipts some of the objections proposed on debian-legal and on
> copyleft-next.
>
> In particular, I have
> 1) removed requirement to change the logo (see [1] from Francesco Poli).
>That requirements was not there to protect the brand of the authors but
>to protect the users from being fooled to use a modified version
>instead of the original;

That still effectively forbids your software from being packaged.

> 2) left requirement to change the name, because the definition of "use"
>already allows the users to store a Derived Work in place of the Hack;

So if I want to patch a security vulnerability, I have to bikeshed a
name? Please no.

> 3) clarified the permissions granted to organizations, that can only copy
>and/or distribute the Hack (see [2] from Paul Jakma);
> 4) slighly improved the Preamble
>
> The canonical url is still at http://www.tesio.it/documents/HACK.txt
> (SHA256: 8d1892282d2335d5b9bc3f4656123bc18cbb2ce479def922a896a75005b3d738)
>
> [1] https://lists.debian.org/debian-legal/2018/12/msg2.html
> [2] https://bit.ly/2BNJvkE
>
> I would really appreciate further feedbacks.

-- 
Cheers,
  Andrej



Re: Hacking License

2018-12-04 Thread Giacomo Tesio
Il December 4, 2018 6:04:59 AM UTC, Ben Finney  ha scritto:
>If you want to release a work of software compatible with Debian, please
>do everyone – yourself included – a huge favour and choose an existing,
>well-understood, known-by-copyright-experts-to-be-effective free
>license already used for many existing software works.

Hi Ben thanks for your advice. I know you mean well.


It's not my intention to abuse the debian-legal mailing list, I was
really looking for compatibility issues between the Hacking License
and the DFSG in the hope to address them before the widespread
adoption of the software it cover and the license.

While the copyright attribution embedded in the Hacking License is
designed to make updates to the license possible, I cannot be sure
that the changes that Debian would require would be compatible with
the rights granted to the users after the release, actually making the
software incompatible with Debian (the upstream copyright attribution
is terminated, like other grants, on violation of users rights).

I appreciate the feedbacks shared so far by Debian Legal volunteers,
and integrated them in the new version of the license to this aim.


If no further incompatibility exists between the Hacking License and
the DFSG, I will not annoy the list anymore.
If, on the other hand, no new copyleft license is allowed to enter
Debian, I'm fine with it, but I think this should be clearly stated
somewhere in the social contract.
Same if this is a problem of license authorship (because I'm neither a
lawyer nor a committee) or affiliation.

Ultimately, if "strongly discouraged" actually means "forbidden" I
just need to know it.

> However, you are strongly seeking feedback not on the work of software,
> but on your new license text.

No, let's be clear on this: I **welcome** all feedbacks about the
license's text, but here I'm **seeking** just for
_incompatibilities_with_DFSG_.
I didn't release the software yet because it's innovative by itself
and I need an appropriate license to more effectively protect the
users' freedom in a strongly distributed computing platform.


Giacomo