unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* FSDG-compatibility of APSL-2.0
@ 2022-06-16  6:21 Philip McGrath
  2022-06-16  7:43 ` Liliana Marie Prikler
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Philip McGrath @ 2022-06-16  6:21 UTC (permalink / raw)
  To: Guix Devel; +Cc: Maxime Devos, (

Hi Guix,

Is the Apple Public Source License 2.0 (APSL-2.0 [1]) a free license 
according to Guix's standards?

In <https://issues.guix.gnu.org/55998>, I sent a patch adding a package 
under this license, and Maxime Devos pointed out this choice-of-forum 
provision, which I agree is quite one-sided:

 > 13.6 Dispute Resolution. Any litigation or other dispute resolution
 > between You and Apple relating to this License shall take place in the
 > Northern District of California, and You and Apple hereby consent to
 > the personal jurisdiction of, and venue in, the state and federal
 > courts within that District with respect to this License. The
 > application of the United Nations Convention on Contracts for the
 > International Sale of Goods is expressly excluded.

We thought this list was a better place for any discussion of Guix's 
policy that needs to happen.

As I understand it, Guix's current policy is the Free System 
Distribution Guidelines published at [2], which links to [3] for its 
definition of "free license". That definition says (at [4]), "It is 
acceptable for a free license to specify which jurisdiction's law 
applies, or where litigation must be done, or both."

The revision notes [5] say that paragraph was added in version 1.129, 
from 2012, but that "this was always our policy".

The FSF has issued an opinion [6] that APSL-2.0 is a free software 
license: they say that "Apple's lawyers worked with the FSF to produce a 
license that would qualify" (after problems with earlier versions of the 
license).

Is this satisfactory for Guix? Or does Guix want to forbid such 
choice-of-forum provisions? In the latter case `apsl2`, and maybe other 
definitions, presumable would need to be removed from `(guix licenses)`.

My personal view:

I wouldn't recommend using this license: indeed, even Apple seems to 
have moved away from it for newer projects (often to Apache-2.0). If 
established guidelines *hadn't* allowed this kind of one-sided 
choice-of-forum provision, I wouldn't have found it particularly 
surprising. I think there are important community governance questions 
around how questions like this ought to be answered (basically, I agree 
with [7]).

Still, I'm in favor of the status quo. I think fragmentation over 
license policies has a significant cost for the community, and this does 
not seem to be sufficiently problematic to be worth a schism.

I'm not a lawyer, so take this paragraph lease seriously, but I also 
think the concrete impact is less than it might first seem. We accept 
choice-of-forum provisions like the one in MPL-2.0 ("Any litigation 
relating to this License may be brought only in the courts of a 
jurisdiction where the defendant maintains its principal place of 
business and such litigation shall be governed by laws of that 
jurisdiction, without reference to its conflict-of-law provisions.") [8] 
which would require you to sue Apple in California. We also accept 
licenses like the GPL that don't have any choice-of-forum provisions: 
the law of "personal jurisdiction" and venue is complex, but I would not 
be shocked if Apple could sue you in California in this case. My 
impression is that it would be very difficult to require something like 
a "freedom not to litigate in California" (especially so for all 
possible values of "California") without rejecting many 
currently-accepted licenses.

-Philip

[1]: https://spdx.org/licenses/APSL-2.0.html
[2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html
[3]: https://www.gnu.org/philosophy/free-sw.html
[4]: https://www.gnu.org/philosophy/free-sw.html#legal-details
[5]: 
https://web.cvs.savannah.gnu.org/viewvc/www/www/philosophy/free-sw.html?r1=1.128&r2=1.129
[6]: https://www.gnu.org/philosophy/apsl.html
[7]: https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/
[8]: https://spdx.org/licenses/MPL-2.0.html


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-16  6:21 FSDG-compatibility of APSL-2.0 Philip McGrath
@ 2022-06-16  7:43 ` Liliana Marie Prikler
  2022-06-16 22:02   ` Philip McGrath
  2022-06-17 17:11 ` Maxime Devos
  2022-06-17 17:13 ` Maxime Devos
  2 siblings, 1 reply; 14+ messages in thread
From: Liliana Marie Prikler @ 2022-06-16  7:43 UTC (permalink / raw)
  To: Philip McGrath, Guix Devel; +Cc: Maxime Devos, (

Hi Philip,

Am Donnerstag, dem 16.06.2022 um 02:21 -0400 schrieb Philip McGrath:
> Hi Guix,
> 
> Is the Apple Public Source License 2.0 (APSL-2.0 [1]) a free license 
> according to Guix's standards?
While it isn't included in the free licenses list the FSF publishes,
from your note [6] I would guess that it is a GPL-incompatible free
software license.

> I'm not a lawyer, so take this paragraph lease seriously, but I also 
> think the concrete impact is less than it might first seem. We accept
> choice-of-forum provisions like the one in MPL-2.0 ("Any litigation 
> relating to this License may be brought only in the courts of a 
> jurisdiction where the defendant maintains its principal place of 
> business and such litigation shall be governed by laws of that 
> jurisdiction, without reference to its conflict-of-law provisions.")
> [8] which would require you to sue Apple in California. We also
> accept licenses like the GPL that don't have any choice-of-forum
> provisions: the law of "personal jurisdiction" and venue is complex,
> but I would not be shocked if Apple could sue you in California in
> this case. My impression is that it would be very difficult to
> require something like a "freedom not to litigate in California"
> (especially so for all possible values of "California") without
> rejecting many currently-accepted licenses.
While this clause exists, it might be unenforcible in practice. 
Suppose you did violate the APSL, for instance, by linking to GPL code.
If you are already in California, Apple can draw you before the
Californean court, but if you don't and simply decide to not heed their
call, Apple needs to appeal to international law enforcement or your
country in particular, whichever is easier.  I doubt that this will
make any difference in the US (safe for travel expenses), but if they
have to cross either ocean, things become more difficult.

In general, free software licenses presuppose a copyright law, which 1)
is active by default and 2) allows for the exemptions specified in
them.  As such, licenses like the WTFPL, while fun, might not hold up
in court if you live in a jurisdiction where "rights" can not be
disclaimed, or have to be disclaimed without resorting to expletives.

IANAL, but I think incompatibility with the GPL might be a bigger issue
when thinking about APSL-licensed packages.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-16  7:43 ` Liliana Marie Prikler
@ 2022-06-16 22:02   ` Philip McGrath
  2022-06-17  9:06     ` zimoun
  0 siblings, 1 reply; 14+ messages in thread
From: Philip McGrath @ 2022-06-16 22:02 UTC (permalink / raw)
  To: Guix Devel, Liliana Marie Prikler; +Cc: Maxime Devos, (

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

Hi,

On Thursday, June 16, 2022 3:43:39 AM EDT Liliana Marie Prikler wrote:
> Hi Philip,
> 
> Am Donnerstag, dem 16.06.2022 um 02:21 -0400 schrieb Philip McGrath:
> > Hi Guix,
> > 
> > Is the Apple Public Source License 2.0 (APSL-2.0 [1]) a free license
> > according to Guix's standards?
> 
> While it isn't included in the free licenses list the FSF publishes,
> from your note [6] I would guess that it is a GPL-incompatible free
> software license.
> 

In fact, it is on the list at <https://www.gnu.org/licenses/license-list.html#apsl2>:

> Apple Public Source License (APSL), version 2 (#apsl2)
> 
>     This is a free software license, incompatible with the GNU GPL. We
>     recommend that you not use this license for new software that you
>     write, but it is ok to use and improve the software released under this
>     license.

I don't want to speak for Maxime, but AIUI the question was whether Guix ought 
to continue to accept all licenses on that list, or instead ought adopt some 
different (more stringent?) license policy.

-Philip

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-16 22:02   ` Philip McGrath
@ 2022-06-17  9:06     ` zimoun
  2022-06-17  9:39       ` Maxime Devos
  2022-06-17  9:40       ` Maxime Devos
  0 siblings, 2 replies; 14+ messages in thread
From: zimoun @ 2022-06-17  9:06 UTC (permalink / raw)
  To: Philip McGrath, Guix Devel, Liliana Marie Prikler; +Cc: Maxime Devos, (

Hi,

On Thu, 16 Jun 2022 at 18:02, Philip McGrath <philip@philipmcgrath.com> wrote:

> I don't want to speak for Maxime, but AIUI the question was whether Guix ought 
> to continue to accept all licenses on that list, or instead ought adopt some 
> different (more stringent?) license policy.

FWIW, I think that adopting a different (more stringent) license policy
hits two issues:

 1. Where do you draw the line?  Based on which concrete principles to
 decide for this or for that?

 Here, each time we discuss license policy, it is some WANL sessions
 [1].  Therefore, the line cannot be drawn using legal consideration (as
 FSF does and then used by the GNU project).

 How to draw the line?  Using my personal perception?  Using yours?  How
 do we resolve the disagreements?

 I think it is not affordable to adopt a different license policy than
 the one listed by the GNU project [2].  It is a pragmatical line
 because the Guix project does not have the manpower nor the structure
 to do differently.


 2. The GNU project is already strict on what is accepted; for good
 reasons.  The Guix project is a niche and being more stringent would
 lead to be an even more niche.  And I miss what aim it would serve.


1: <https://logs.guix.gnu.org/guix/2021-11-24.log#172129>
2: <https://www.gnu.org/licenses/license-list.html>


Cheers,
simon


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17  9:06     ` zimoun
@ 2022-06-17  9:39       ` Maxime Devos
  2022-06-17 10:00         ` Liliana Marie Prikler
  2022-06-17 14:37         ` zimoun
  2022-06-17  9:40       ` Maxime Devos
  1 sibling, 2 replies; 14+ messages in thread
From: Maxime Devos @ 2022-06-17  9:39 UTC (permalink / raw)
  To: zimoun, Philip McGrath, Guix Devel, Liliana Marie Prikler; +Cc: (

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

TBC, did you see my previous mail about cherry-picking and power
assymetry.


> FWIW, I think that adopting a different (more stringent) license
> policy hits two issues:
> 
>  1. Where do you draw the line?  Based on which concrete principles
>     to decide for this or for that?

I would like to refer to some blog article about something along the
lines ’free software is not about licenses, but about ???’, but I
cannot find it anymore.

zimoun schreef op vr 17-06-2022 om 11:06 [+0200]:
>  I think it is not affordable to adopt a different license policy than
>  the one listed by the GNU project [2].  It is a pragmatical line
>  because the Guix project does not have the manpower nor the structure
>  to do differently.
>
> And I miss what aim it would serve.

That page mentions:

> We classify> license according to certain criteria:
> [...]
> * Whether it causes any particular practical problems.
> [...]

Being forced to go to the US as a defendant seems like a very practical
problem to me.  E.g., apparently being imprisoned for 5 years or being
fined for $250 000 or such is a thing in the US[0], and the prison
situation in the US is reportedly bad.

The clause is also rather extra-territorial: what if $local_country
reforms copyright to make all sofware free, if we accepted ‘go to this
jurisdiction clauses’, then opponents could effectively block the
legally-enforced freeing of software by adding such a clause.   Such a
clause could potentially also be used to enforce a particular
jurisdiction that has forbidden modifying otherwise free software
entirely or somehting.

[0]
https://www.justice.gov/archives/jm/criminal-resource-manual-1852-copyright-infringement-penalties-17-usc-506a-and-18-usc-2319

>  2. The GNU project is already strict on what is accepted; for good
>  reasons.  The Guix project is a niche and being more stringent would
>  lead to be an even more niche.

Not being subject to the US seems worth some extra niche-ness to this
non-US person.  Also:

>  I think it is not affordable to adopt a different license policy
>  than the one listed by the GNU project [2].  It is a pragmatical
>  line because the Guix project does not have the manpower nor the
>  structure to do differently.

... currently Guix isn't using the APSL2.0 anywhere (according to git
grep -F aspl), so it seems quite practical and effortless to just
remove apsl2 from (guix licenses).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17  9:06     ` zimoun
  2022-06-17  9:39       ` Maxime Devos
@ 2022-06-17  9:40       ` Maxime Devos
  1 sibling, 0 replies; 14+ messages in thread
From: Maxime Devos @ 2022-06-17  9:40 UTC (permalink / raw)
  To: zimoun, Philip McGrath, Guix Devel, Liliana Marie Prikler; +Cc: (

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

zimoun schreef op vr 17-06-2022 om 11:06 [+0200]:
> [...] How do we resolve the disagreements?

By talking on guix-devel.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17  9:39       ` Maxime Devos
@ 2022-06-17 10:00         ` Liliana Marie Prikler
  2022-06-17 17:06           ` Maxime Devos
  2022-06-17 14:37         ` zimoun
  1 sibling, 1 reply; 14+ messages in thread
From: Liliana Marie Prikler @ 2022-06-17 10:00 UTC (permalink / raw)
  To: Maxime Devos, zimoun, Philip McGrath, Guix Devel; +Cc: (

Am Freitag, dem 17.06.2022 um 11:39 +0200 schrieb Maxime Devos:
> The clause is also rather extra-territorial: what if $local_country
> reforms copyright to make all sofware free, if we accepted ‘go to
> this jurisdiction clauses’, then opponents could effectively block
> the legally-enforced freeing of software by adding such a clause.
No, they can't.  If $local_country makes all software free, such a
clause would likely be illegal in $local_country and thus unenforcible.
If Apple did try to sue a $local_country citizen, $local_country could
sue Apple for breaking $local_country law.

> ... currently Guix isn't using the APSL2.0 anywhere (according to git
> grep -F aspl), so it seems quite practical and effortless to just
> remove apsl2 from (guix licenses).
It actually does, through the ungoogled-chromium bundle.

Cheers


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17  9:39       ` Maxime Devos
  2022-06-17 10:00         ` Liliana Marie Prikler
@ 2022-06-17 14:37         ` zimoun
  2022-06-17 15:52           ` Philip McGrath
  1 sibling, 1 reply; 14+ messages in thread
From: zimoun @ 2022-06-17 14:37 UTC (permalink / raw)
  To: Maxime Devos, Philip McGrath, Guix Devel, Liliana Marie Prikler; +Cc: (

Hi,

On Fri, 17 Jun 2022 at 11:39, Maxime Devos <maximedevos@telenet.be> wrote:

> TBC, did you see my previous mail about cherry-picking and power
> assymetry.

No.  And I do not see it in the public archive.


> I would like to refer to some blog article about something along the
> lines ’free software is not about licenses, but about ???’, but I
> cannot find it anymore.

On one hand, I agree: free software is more than just about licenses,
because it is about quality of code, good documentation, nice community,
etc.

On the other hand, I refuse to judge the intent behind a software.  It
appears to me a slippery slope.  The only way is to set a clear frame
and then scrutinize using this very frame.  Debian defines a frame, GNU
defines another frame, etc. and each project qualifies via this frame.

Guix is part of GNU and the GNU project lists the acceptable and
unacceptable licenses.

Again, if the Guix project would like to apply a more stringent license
policy than the GNU one, then the question is according to which frame.


> Being forced to go to the US as a defendant seems like a very practical

[...]

> Not being subject to the US seems worth some extra niche-ness to this
> non-US person.

Bah, it is the same for any license.  Even the GPL.  For instance, the
concept of Copyright under the US Law does not have a one-to-one
equivalent under the French Law.  (See the case Entr’ouvert vs Orange.)

Law, especially international one, is very complex.  We should focus on
what we are doing the best: package, service and distro. :-)  And I
trust enough FSF and others as Software Freedom Conservancy for doing
the best in the legal field.


> ... currently Guix isn't using the APSL2.0 anywhere (according to git
> grep -F aspl), so it seems quite practical and effortless to just
> remove apsl2 from (guix licenses).

It is maybe used by Chromium.

I have nothing against removing APSL2.0 if it is not currently used.
However, I think the Guix project should continue to accept all software
using the licenses on GNU list [1].

About patch#55998, the question is about dependencies and linking
because APSL is incompatible with the GPL.  If all is fine, then let
include ’cctools’ in Guix.


1: <https://www.gnu.org/licenses/license-list.html>
2: <https://issues.guix.gnu.org/55998>


On Fri, 17 Jun 2022 at 11:40, Maxime Devos <maximedevos@telenet.be> wrote:
> zimoun schreef op vr 17-06-2022 om 11:06 [+0200]:
>> [...] How do we resolve the disagreements?
>
> By talking on guix-devel.

Talk does not cook the rice. ;-)

Well, discussions do not always resolve some disagreements, sadly.  If
you consider that A is acceptable and I consider that B is unacceptable,
then we discuss at length and at the end we do not reach any consensus;
you are still on A-side and I am still on B-side.  How would we resolve
at the project level?

Today, the Guix project uses a do-ocracy system where disagreements are
resolved by Guix maintainers.  Enough burden and discussions are already
around without hypothetically adding one about resolving potential
disagreements on license policy, IMHO.  Without mentioning the WANL
sessions. :-)


Cheers,
simon



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17 14:37         ` zimoun
@ 2022-06-17 15:52           ` Philip McGrath
  0 siblings, 0 replies; 14+ messages in thread
From: Philip McGrath @ 2022-06-17 15:52 UTC (permalink / raw)
  To: Maxime Devos, Guix Devel, Liliana Marie Prikler, zimoun; +Cc: (

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

Hi,

On Friday, June 17, 2022 10:37:07 AM EDT zimoun wrote:
>  
> On the other hand, I refuse to judge the intent behind a software.  It
> appears to me a slippery slope.  The only way is to set a clear frame
> and then scrutinize using this very frame.  Debian defines a frame, GNU
> defines another frame, etc. and each project qualifies via this frame.
> 
> Guix is part of GNU and the GNU project lists the acceptable and
> unacceptable licenses.
> 
> Again, if the Guix project would like to apply a more stringent license
> policy than the GNU one, then the question is according to which frame.
> 

Yes: I think the most ideal license policy has yet to be invented, and I'm 
glad the Debian Free Software Guidelines and the Free System Distribution 
Guidelines both exist and provide some valuable critiques of each other. 
(Neither is a subset of the other!) I do think the guidelines should be open 
to (good faith) discussion and debate. But forking the license standards 
caries big costs: maybe even some literal ones, but certainly in terms of 
effort—from idealists who think about these principles, from distributions who 
have a smaller set of collaborators among whom to share the work of evaluating 
license issues, and from freedom-loving upstream developers who want to 
publish software everyone can accept without patching. At least for me, 
whatever marginal improvement could be made (with respect to my idiosyncratic 
opinion) just doesn't seem worth it.

>
> On Fri, 17 Jun 2022 at 11:39, Maxime Devos <maximedevos@telenet.be> wrote:
> > ... currently Guix isn't using the APSL2.0 anywhere (according to git
> > grep -F aspl), so it seems quite practical and effortless to just
> > remove apsl2 from (guix licenses).
> 
> It is maybe used by Chromium.
> 
> I have nothing against removing APSL2.0 if it is not currently used.
> However, I think the Guix project should continue to accept all software
> using the licenses on GNU list [1].
> 
> About patch#55998, the question is about dependencies and linking
> because APSL is incompatible with the GPL.  If all is fine, then let
> include ’cctools’ in Guix.
> 

I'll say just a bit about the practical motivation for this patch.

Assuming we agree that it's beneficial for at least some free software to be 
able to run on non-free operating systems, that means some free software 
developers have to build software for those systems. For Windows, MinGW lets 
us do so without having to leave the free world. For Apple platforms, the 
status quo is that someone has to buy or get access to a piece of hardware 
sold the nonfree os. Maybe, with a lot of effort, you can cross-compile by 
downloading a nonfree binary bundle.

Patch 55998 doesn't solve that problem, but it at least takes a step toward 
being *less* reliant on a nonfree toolchain. The particular utility that I've 
used so far [1] is significant enough that part of its functionality 
(unfortunately not the part I needed) had been implemented in Racket [2], and 
I believe other compilers or package managers have done similarly.

(I plan to write more about how this experiment worked out once various loose 
ends have been tied up.)

This is possible because we *do* have the freedom to use, study, modify, and 
distribute major components of the toolchain and operating system kernel. 
Requiring something other than those freedoms would perversely increase the 
reliance on nonfree systems for building free software.

I think the dependency and linking issues, to whatever extent they existed, 
are resolved by v2 of the patch. The only GPL file was a header from GDB which 
seemed to be left over from before Apple switched to an LLVM/Clang toolchain: 
it wasn't actually used by anything, so just deleting the file worked out fine. 
(Not being a lawyer, I can only speculate about whether it might have been 
fair use anyway under Google v. Oracle.) There are a few files or parts of them 
under miscellaneous permissive Expat- or BSD-like licenses. The only linking 
is with things like libc that have sufficiently permissions.

-Philip

[1]: https://github.com/LiberalArtist/native-libgit2-pkgs/tree/build-scripts
[2]: https://github.com/racket/racket/blob/master/racket/src/mac/
install_name_tool.rkt
[3]: https://issues.guix.gnu.org/55998#23


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17 10:00         ` Liliana Marie Prikler
@ 2022-06-17 17:06           ` Maxime Devos
  2022-06-17 20:11             ` Felix Lechner
  0 siblings, 1 reply; 14+ messages in thread
From: Maxime Devos @ 2022-06-17 17:06 UTC (permalink / raw)
  To: Liliana Marie Prikler, zimoun, Philip McGrath, Guix Devel; +Cc: (

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

Liliana Marie Prikler schreef op vr 17-06-2022 om 12:00 [+0200]:
> Am Freitag, dem 17.06.2022 um 11:39 +0200 schrieb Maxime Devos:
> > The clause is also rather extra-territorial: what if $local_country
> > reforms copyright to make all sofware free, if we accepted ‘go to
> > this jurisdiction clauses’, then opponents could effectively block
> > the legally-enforced freeing of software by adding such a clause.
> No, they can't.  If $local_country makes all software free, such a
> clause would likely be illegal in $local_country and thus unenforcible.
> If Apple did try to sue a $local_country citizen, $local_country could
> sue Apple for breaking $local_country law.

It's unenforcable in $local_country, yes, but the due to the ‘Dispute
Resolution clause’, the sueing happens in California, not
$local_country, which is the potential issue I wanted to highlight. 
Though possibly ...

> While this clause exists, it might be unenforcible in practice. 
> Suppose you did violate the APSL, for instance, by linking to GPL
> code.
>
> If you are already in California, [...], but if you don't and simply
> decide to not heed their call, Apple needs to appeal to international
> law enforcement or your country in particular, whichever is easier. 
> I doubt that this will make any difference in the US [...], but if
> they have to cross either ocean, things become more difficult.

... yes, but I wouldn't know whether it will be to difficult or not for
Apple and whether $local_country would agree/disagree, so I'm inclined
to assume the worst for safety, unless informed by a reliable expert.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-16  6:21 FSDG-compatibility of APSL-2.0 Philip McGrath
  2022-06-16  7:43 ` Liliana Marie Prikler
@ 2022-06-17 17:11 ` Maxime Devos
  2022-06-17 17:13 ` Maxime Devos
  2 siblings, 0 replies; 14+ messages in thread
From: Maxime Devos @ 2022-06-17 17:11 UTC (permalink / raw)
  To: Philip McGrath, Guix Devel; +Cc: (

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

Doesn't seem to reach some kind of consensus, or maybe there's actually
some consensus for considering APSL-2.0 acceptable (albeit suboptimal)
for Guix but I'm to biased to see it :p, so I suppose continue with
status quo (i.e.: allow APSL-2.0)?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-16  6:21 FSDG-compatibility of APSL-2.0 Philip McGrath
  2022-06-16  7:43 ` Liliana Marie Prikler
  2022-06-17 17:11 ` Maxime Devos
@ 2022-06-17 17:13 ` Maxime Devos
  2 siblings, 0 replies; 14+ messages in thread
From: Maxime Devos @ 2022-06-17 17:13 UTC (permalink / raw)
  To: Philip McGrath, Guix Devel; +Cc: (

[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

(zimoun pointed out that I didn't actually send this mail, apparently
it never left ‘drafts’.  Anyway, just sending this e-mail for
completeness; unless someone comes with a new insight or something the
discussion appears to be done for now.)

Philip McGrath schreef op do 16-06-2022 om 02:21 [-0400]:
> Still, I'm in favor of the status quo. I think fragmentation over 
> license policies has a significant cost for the community, and this
> does not seem to be sufficiently problematic to be worth a schism.

Maybe, but I'm not aware of any method to revise the decisions of the
FSF.

Philip McGrath schreef op do 16-06-2022 om 02:21 [-0400]:
> I'm not a lawyer, so take this paragraph lease seriously, but I also 
> think the concrete impact is less than it might first seem. We accept 
> choice-of-forum provisions like the one in MPL-2.0 ("Any litigation 
> relating to this License may be brought only in the courts of a 
> jurisdiction where the defendant maintains its principal place of 
> business and such litigation shall be governed by laws of that 
> jurisdiction, without reference to its conflict-of-law provisions.") [8] 
> which would require you to sue Apple in California

I consider this to be a much milder clause than the clause in APSL-2.0:
also IANAL, but what it looks like to me:

1. APSL-2.0: Apple can legally drag you (*) to California to be sue you
   there under California's law and everything that entails.
2. APSL-2.0: Likewise, you can drag Apple to the California to sue
   Apple there.

I don't see any reason to do (2) here.
What I consider problematic here, is (1).

Contrast this to MPL-2.0 (for simplicity, this assumes Apple uses the
MPL, feel free to replace by Mozilla or whatever):

1. If Apple sues you, they have to sue you in _your_ country.
2. If you sue Apple, you have to sue in Apple's country.

This seems rather symmetric to me, and while sometimes I might disagree
with $foreign_country's or $local_country's laws, this seems a rather
reasonable system to me.

(*) unless $your_country's legal system disagrees on this choice of
forum provision.

> We also accept licenses like the GPL that don't have any choice-of-
> forum provisions:
>
> the law of "personal jurisdiction" and venue is complex, but I would
> not be shocked if Apple could sue you in California in this case. My
> impression is that it would be very difficult to require something
> like a "freedom not to litigate in California" (especially so for all
> possible values of "California") without rejecting many 
> currently-accepted licenses.

My problem is not a ‘freedom to not litigate in $foo’, but rather ‘no
cherry-picking jurisdictions to whatever is convenient for limiting the
freedom the most’.

Sure, if it comes to a conflict between party X and Y, the legal system
will need to somehow decide on a forum, but no need for this power
asymmetry.

In this case, MPL-2.0's clause seems acceptable to me, but APSL-2.0's
doesn't.

TBC, if two parties of about equal power choose a forum to avoid
potential future problems, ok, but this doesn't seem to be the case for
the APSL-2.0.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17 17:06           ` Maxime Devos
@ 2022-06-17 20:11             ` Felix Lechner
  2022-06-17 21:14               ` Maxime Devos
  0 siblings, 1 reply; 14+ messages in thread
From: Felix Lechner @ 2022-06-17 20:11 UTC (permalink / raw)
  To: Guix Devel

Hi,

On Fri, Jun 17, 2022 at 10:07 AM Maxime Devos <maximedevos@telenet.be> wrote:
>
> If $local_country makes all software free, such a
> clause would likely be illegal in $local_country and thus unenforcible.

A country would likely engage in such a wholesale disenfranchisement
as a last step, and not the first, after refusing to enforce Apple's
judgments obtained in the US.

> If you are already in California, [...], but if you don't and simply
> Apple needs to appeal to international
> law enforcement or your country in particular, whichever is easier.

I generally think of license violations as civil matters. With some
small exceptions, law enforcement focuses on criminal cases.

> they have to cross either ocean, things become more difficult.

Apple would probably try to obtain a default judgment, which is often
issued after a counterparty was served (not always easy abroad) but
did not respond in court. If and how that judgment affects someone's
situation in another country depends on many factors, including
international treaties and the local political environment.

> ... yes, but I wouldn't know whether it will be to difficult or not for
> Apple and whether $local_country would agree/disagree, so I'm inclined
> to assume the worst for safety, unless informed by a reliable expert.

The safest route for free software activists is always to comply with
the stated license terms. Folks in the free software community, at
least those of us preferring licenses with strong copylefts, expect
the same.

As a resident of Northern California, I personally like the local
legal environment. You would have to talk to a lawyer to see if the
Ninth Circuit (copyright claims are Federal) would honor the clause
about ignoring the UN Convention after considering the relative
strength of the parties, as a matter of sound public policy.

Perhaps the weighing of those factors played a role in why Apple's
attempt to stipulate a venue did not render the license unfree.

Kind regards,
Felix Lechner

P.S. To my knowledge, I do not use or own any Apple products.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: FSDG-compatibility of APSL-2.0
  2022-06-17 20:11             ` Felix Lechner
@ 2022-06-17 21:14               ` Maxime Devos
  0 siblings, 0 replies; 14+ messages in thread
From: Maxime Devos @ 2022-06-17 21:14 UTC (permalink / raw)
  To: Felix Lechner, Guix Devel

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Felix Lechner schreef op vr 17-06-2022 om 13:11 [-0700]:
> > If you are already in California, [...], but if you don't and
> > simply
> > Apple needs to appeal to international
> > law enforcement or your country in particular, whichever is easier.
> 
> I generally think of license violations as civil matters. With some
> small exceptions, law enforcement focuses on criminal cases.

I thought that copyright violations were a criminal matter in the US,
but after some cursory searching, it appears to be more complicated. 
Apparently there's both a civil part and a criminal part, where
apparently the criminal part is for some cases of willful copyright
infringement.

> As a resident of Northern California, I personally like the local
> legal environment. You would have to talk to a lawyer to see if the
> Ninth Circuit (copyright claims are Federal) would honor the clause
> about ignoring the UN Convention after considering the relative
> strength of the parties, as a matter of sound public policy.

I don't know California but sounds nice.  Also I guess I'd need to do
the same to see if $local_country would do such a thing too.

> Perhaps the weighing of those factors played a role in why Apple's
> attempt to stipulate a venue did not render the license unfree.

Maybe, yes, I dunno.

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-06-17 21:14 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-16  6:21 FSDG-compatibility of APSL-2.0 Philip McGrath
2022-06-16  7:43 ` Liliana Marie Prikler
2022-06-16 22:02   ` Philip McGrath
2022-06-17  9:06     ` zimoun
2022-06-17  9:39       ` Maxime Devos
2022-06-17 10:00         ` Liliana Marie Prikler
2022-06-17 17:06           ` Maxime Devos
2022-06-17 20:11             ` Felix Lechner
2022-06-17 21:14               ` Maxime Devos
2022-06-17 14:37         ` zimoun
2022-06-17 15:52           ` Philip McGrath
2022-06-17  9:40       ` Maxime Devos
2022-06-17 17:11 ` Maxime Devos
2022-06-17 17:13 ` Maxime Devos

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).