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
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.
[-- 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 --]
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
[-- 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 --]
[-- 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 --]
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
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
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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.
[-- 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 --]