From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Tue, 15 Sep 2015 06:18:58 -0700 Message-ID: <55F81AC2.2080102@dancol.org> References: <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> <55F6E43E.9030502@dancol.org> <8737ygz8z3.fsf@uwakimon.sk.tsukuba.ac.jp> <55F789D5.3080005@dancol.org> <87zj0oxflr.fsf@uwakimon.sk.tsukuba.ac.jp> <87k2rsul36.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qjLd4duv0TcR1CQnj8bweNGNSveVi7gMS" X-Trace: ger.gmane.org 1442323317 24122 80.91.229.3 (15 Sep 2015 13:21:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 13:21:57 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , Tom Tromey , Stephen Leake To: David Kastrup , "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 15 15:21:45 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZbqB5-00078B-4N for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 15:21:43 +0200 Original-Received: from localhost ([::1]:42682 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbqB3-00073B-UD for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 09:21:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbqAz-0006ar-Gp for emacs-devel@gnu.org; Tue, 15 Sep 2015 09:21:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zbq8q-0003A3-F1 for emacs-devel@gnu.org; Tue, 15 Sep 2015 09:19:25 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:42837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbq8q-00039p-3n for emacs-devel@gnu.org; Tue, 15 Sep 2015 09:19:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=ozTaL6GrcgSgx8L8KyosvzF5jgKHx8ushK1+e6ioWJ0=; b=bd4wkFxqMN3FBgVVaydBDJ3OTxyjWj9xo8a13vSC8kkURWOeZGAZStk8v4HW6PQUozODWWJzxfYIT/7l1uMt/kDR4DUZGhFfYUAWtQgTR0Rqnmyn9BgLoJ6tVkhQvQt+H/wQYZ9DnIO8LkFZG9vPX8QOKTsNox3plNIVRKgpOi1Syf10MGLeVuV22YVOW4YYtB9no7fvEWocYbuBC0Xa60PkWpkfOXo5iHZLdHaHqzsxA4S08uOgVDaGAuPBlhmZ4Uy78vJ1keWdGUt4a8ZrIx8dYe4RW+0oDvT5q2Rr9+kRzMMkdZQS252uFFHIJ9ae/fTxWQh/a913NLSbbmKwOA==; Original-Received: from [2620:10d:c090:180::1:6bf3] (helo=[IPv6:2620:10d:c081:1101:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1Zbq8X-0007KE-Dz; Tue, 15 Sep 2015 06:19:05 -0700 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <87k2rsul36.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189971 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qjLd4duv0TcR1CQnj8bweNGNSveVi7gMS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/15/2015 01:45 AM, David Kastrup wrote: > So having our binary interfaces and calling conventions and > memory/exception handling default to "like Emacs does" is not just > Lisp-friendly but is also keeping our license enforcement options more > conservative.=20 I don't see how. Once we have a module that allows general-purpose loading of code not intended for use in Emacs (no matter how hard that initial module is to write), there will be literally nothing preventing users making arbitrary GPLv3-compatible modules that allow users to chain-load non-GPLv3-compatible code. There's no way to require that everything in the Emacs address space be licensed under the GPL. And that's a good thing, because equating sharing an address space with a "derivative work" boundary is ridiculous. Even if Emacs were to look for some I_LOAD_ONLY_GPLV3=3D1 export from loaded modules, the GPL does not prohibit a module simply lying. The GPLv3 does not require the implementation of technical license enforcement mechanisms. (If it did, it would violate freedom 0.) --qjLd4duv0TcR1CQnj8bweNGNSveVi7gMS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV+BrDAAoJEN4WImmbpWBlpGIP/jdKBr0Zy6x/gr/F0wcxD4y4 tXRIZKaNvektxLZEYzvtSWUkkRXJVtQy6iQqwYhYr/n4Xpkll2tPvoRkwWCPnTa9 4zslK0UUghzFq2enJ4Eqxw/gqfyqh2tuZz3IH/IYVR26jm3v+rmoz92/IgZjA0QO VhDCVguZP/Kv4Rb1wAErBae7uVNrSzua12kvkCJCTiZhnY6Alk7WCqcPVwDLYP7u ZsgsyiIm81x1yq4PjVPJ/sLsEmlq8Pf57Vjg8AIAzzp+r8XKNG9fmpYELYsjZPxq jJs3ijmwT/IgMgmTICxBttcnp5yGr/U7z6OLvKXxi8o8AaNFG6kk7asvPvg+BMKS irKxDWNELtTGvFJxliFgnbfycUObuP1utDt+pHOpF2N4iRGhjNmqqdcRn5kF2zL2 slAlpPgp10P72QQyi7jDBwPE3m0w8cfCJPzddXnHpXn4R8AULQ6PSHsgrX+EQ2zy HKFKKyFmGXwh7CbpJ5kmvclHtEcqYBoB9TIxHkVKJhoy1Ua6HIIvNBsAozFQOBGQ LNHUrLneHMEDOnCF5sSSPyGA7nLDNGUu9jgcvQE7tf7K25hHbMpQwf8MPVysM+v4 Crmkn70Zh9bM2Qt0zJpgC8TFTOwjNlLHgazXt3paX6ggS4FQszmrrQb2q3DBtH4Y m6VHID8R1UNPD/lnTm0T =879q -----END PGP SIGNATURE----- --qjLd4duv0TcR1CQnj8bweNGNSveVi7gMS--