From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OMSWMHG2rGJCQQAAbAwnHQ (envelope-from ) for ; Fri, 17 Jun 2022 19:14:25 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id wGd/MHG2rGJdbwEA9RJhRA (envelope-from ) for ; Fri, 17 Jun 2022 19:14:25 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 59DBDDEA6 for ; Fri, 17 Jun 2022 19:14:25 +0200 (CEST) Received: from localhost ([::1]:58898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2FY7-0005S6-Os for larch@yhetil.org; Fri, 17 Jun 2022 13:14:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2FXl-0005QT-1e for guix-devel@gnu.org; Fri, 17 Jun 2022 13:14:01 -0400 Received: from baptiste.telenet-ops.be ([2a02:1800:120:4::f00:13]:43926) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o2FXj-0004hX-6P for guix-devel@gnu.org; Fri, 17 Jun 2022 13:14:00 -0400 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by baptiste.telenet-ops.be with bizsmtp id kHDw2700R4UW6Th01HDwmw; Fri, 17 Jun 2022 19:13:56 +0200 Message-ID: <5a9202b00b6eabfe3a065d86ca4ccb9044ecbad3.camel@telenet.be> Subject: Re: FSDG-compatibility of APSL-2.0 From: Maxime Devos To: Philip McGrath , Guix Devel Cc: "(" Date: Fri, 17 Jun 2022 19:13:56 +0200 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-xbKn1JDw+YN5lKX5QUfq" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1655486036; bh=IB2h9mO9vvCKU3yiR14oTmJ/efUapXQ7ka7lp6BAVhM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=n0DgyOIzfU0qfuDzQCbWNHDbTCZr5KLhepVWF5V8zC3EmfEmAK63VJu00/NhopFkU mcUXpfcRL73PsUwqHHbUgxYzW9oDMK+oyBsntgGR3VZT4oxuFPrT8j3o6f8h9G45jX 3LTChTOJZ9UEHzVdUGcFRTVw5gyjuUqg/Oxrbg/Y900TAoKqGxT1f/1STPdJomth4K VZiGKZlnyIG2mDHQZJvSsE7F2+HPP0V9kJXYHzT2+B/b/aPalcwYV7S4IaevfG2fCs /0hMtrVRueCX9C+i9KQK/qBZjszAFtwlpXkGCbwYz4+AtqOeIuDi9ObEi7ynjZUDqn VkV+7uXKqhJjQ== Received-SPF: pass client-ip=2a02:1800:120:4::f00:13; envelope-from=maximedevos@telenet.be; helo=baptiste.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1655486065; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=IB2h9mO9vvCKU3yiR14oTmJ/efUapXQ7ka7lp6BAVhM=; b=K7VxOOYv9rX5Fsu+uL1ECY3DCY9K+U/9pzRfR0TvAjmmEzBjjuD/V84WrcW8853+WyHCpY mYamkhGXnPnIyVF8MGW1CQiuVCoYutHh0XgKeIRjGQ7hvXdwMf7s+rUCeIOIkYHGSf4q6X xca6A6e5eeDoN4D62lK+3dtfoTcHVKZrAOgdq+zmxi3Wsl8BTc8LNm68OpB3D7mcUNbmx5 6bBVnOMr+HrQ10VbqwEhOtKblidUPPjWsel+tu7iTqVP9yTeZAlgaLuFH9MT9v5x//Qhrq HSRa9gkKiIpK85ODBb5Abzur+xGVPGTvYuT/DXjZcjI5X+Y0z+DXydZXD5ffnA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655486065; a=rsa-sha256; cv=none; b=oNBrliJMfe55nBW95VqDRA8UOZrhE9OCeNwDECD/5eEkkVQJnK++n8ghvr+jimh8tbgCkR NuauQSrS/mZ1Moln9N3sLHS+2rCB2Ft+XhldmPcfghGvJ1oGemwUF1CTHktGd3SkHDqOVV J98ez9f2ps5u2tPO8d3bGCK5WDSrsiZM5Ww+IkpHoOaYxaGZRLMYUM5uAbWbIZppKH3y9l rJahBgXrdnP3gO6APdSmTXdn2Wy8qKT78OXcUc+DypCaLRGq8MxVo6S62wSwDWMX/EgUva rLigDdAGprrpiRhAC5os262ZLJz/HW76xKeohae9/zu4LlEK6ISfz86DaDRBig== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=n0DgyOIz; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.19 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=n0DgyOIz; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 59DBDDEA6 X-Spam-Score: -6.19 X-Migadu-Scanner: scn1.migadu.com X-TUID: XizWqAtcGVwt --=-xbKn1JDw+YN5lKX5QUfq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (zimoun pointed out that I didn't actually send this mail, apparently it never left =E2=80=98drafts=E2=80=99. Anyway, just sending this e-mail f= or 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=20 > 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=20 > think the concrete impact is less than it might first seem. We accept=20 > choice-of-forum provisions like the one in MPL-2.0 ("Any litigation=20 > relating to this License may be brought only in the courts of a=20 > jurisdiction where the defendant maintains its principal place of=20 > business and such litigation shall be governed by laws of that=20 > jurisdiction, without reference to its conflict-of-law provisions.") [8]= =20 > 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=20 > currently-accepted licenses. My problem is not a =E2=80=98freedom to not litigate in $foo=E2=80=99, but = rather =E2=80=98no cherry-picking jurisdictions to whatever is convenient for limiting the freedom the most=E2=80=99. 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. --=-xbKn1JDw+YN5lKX5QUfq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYqy2VBccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7kruAQDwrxehyPnUphMrh5O1wkt9oX29 P7XmmvSE3Dlvkm+2rAD9HgkaHufga+l4Csd4YjQadj8Bw+cVNP3+s8JP3oau9g4= =AaR+ -----END PGP SIGNATURE----- --=-xbKn1JDw+YN5lKX5QUfq--