From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Sv: as for Calc and the math library Date: Thu, 15 Aug 2024 20:09:56 +0000 Message-ID: References: <864j7qhup6.fsf@gnu.org> <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <86jzgjfwqp.fsf@gnu.org> <87sev78arx.fsf@gmail.com> <86le0z89u1.fsf@gnu.org> <87o75v87n1.fsf@gmail.com> <86frr786k7.fsf@gnu.org> <861q2q8e18.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_DU2PR02MB1010910FA801C8AF7B41F973496802DU2PR02MB10109eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29274"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "suhailsingh247@gmail.com" , "gerd.moellmann@gmail.com" , "nicolas@n16f.net" , "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 16 07:27:32 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sepUp-0007Sb-2j for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Aug 2024 07:27:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sepTo-0006Oh-Qg; Fri, 16 Aug 2024 01:26:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1segnO-0000mI-Nl for emacs-devel@gnu.org; Thu, 15 Aug 2024 16:10:06 -0400 Original-Received: from mail-northeuropeazolkn19013065.outbound.protection.outlook.com ([52.103.32.65] helo=DUZPR83CU001.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1segnJ-00088t-9r; Thu, 15 Aug 2024 16:10:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LVxE4sk7kcz7/j9UECd3VEKrKdSbMPb4aKkA2sLpmbz6iMafUeaVKjebwR2yr/cL04ngaNFJXJ/H1+0epdwi4SJ2dLFkZI0kLM8v3YXq/D7EPhfY+SuR4n5pyVxBCo3/tYFC6DxX23ffecT9/Vi8MdBFJWIaQfNe1lpc2ktsubznGCILlhhJTY9l/xxyGN41BDnNx3HRUG5hYURzWybiHO/RCiBOvznZFukpFw3x8+JrlvomlAj4xGK1BsZ7m0z30+fe+2hurK4hKE7yhfiJNG6biDeTNz5da7pFdGMOzw2R5kpeICUCBTcIbEDmlqNN2sZM9cYBvH/PbDJ8VGNGow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M9rKjhE9EX9D22NLUoE32V/Zq+MhU0rl2iyAwr+4eIo=; b=XMU03aR1olTL6Yhkz+EX2UlK5feViiQidcYtdAaqa+1s/4W7TMIlYrheR4bPtFgbbL7gH7VyU93GFT5Meum0YqJK/E6kztnyQUTQonViWbTk10VgTs3STqp5/9RBCMuiSPjTgFas+nFVoHS74pD08akdAZETnSeI042ZHWluQFihRRP2875/UtzEYRs1q02gSAVvV+840j7cEZYc26UwMT18LU/Y3OWdyizcv7PUblS/n1Qnw6XYSvSYNu+Sddp2BqpjgS+osKTEHxW7YcF1+jP+1NTXvb2sM+mpINmoLCKDpsoy2cq60qehLDqh6U2LNiok9Awh6z2nhsVt+WvWyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M9rKjhE9EX9D22NLUoE32V/Zq+MhU0rl2iyAwr+4eIo=; b=GIPW3jJ9xjoM35VftM0A8GKl2f5mNnC2O2oCxSVmJrf/jTE2g6gpya7Sg8eFURNdNMvDEbFVOSh6YOb6TzPKPK30vjW+pC3ErWvzIorn0WjP5ZlDLxKGcRZjxtqqjCGNru3WN47rmI+03GA+dUGjTd+z5mbf/pUwrxjwsrIXL0YFo3AoSW6krlXimNzhw5jeX1vRuVQ6KGOgk8myVcrry7Pu/kTeLfqGveUcgueW5u99K7L0ZZs/SoGDxKSGb17a9Y5p2qxRO9RmYIuNYgtjAuks5mIQMRcTgicymZoEgY4uWZBlS4eRKMzrLCnuh3YVsIfi6yHeaDikoZZSu6ReOQ== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by GV1PR02MB11083.eurprd02.prod.outlook.com (2603:10a6:150:213::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.19; Thu, 15 Aug 2024 20:09:57 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487%4]) with mapi id 15.20.7875.016; Thu, 15 Aug 2024 20:09:57 +0000 Thread-Topic: as for Calc and the math library Thread-Index: AQHa7HhyCr4HNzb0tkSg9b4Ke04UmbIjdNFDgAAGX1aAAAZxKoABK62BgAF5touAACUuyYAAf3mkgAAFtHaAAA08XIAABoVEgADg0DCAACNJHoAA28K+ In-Reply-To: <861q2q8e18.fsf@gnu.org> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [LFyNlP1S/bmDLKOpXc0kQhnNCEH0Vi1O] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU2PR02MB10109:EE_|GV1PR02MB11083:EE_ x-ms-office365-filtering-correlation-id: 859f5fda-9527-4970-e9da-08dcbd663bdf x-microsoft-antispam: BCL:0; ARA:14566002|19110799003|15030799003|15080799003|8060799006|461199028|3412199025|440099028|102099032; x-microsoft-antispam-message-info: 7rZjAEDbyD0TCPCuPxZyqQ9Rf9BZ9BVTCUbECJoDTFqaUdHpRjHGdsa14NqG5a8sa+pBVZFtwRY0BUbLy04TS1aXQAHsqqgjbbw9Ysw8jn7KUKi8ApQvYDguK4oa3T18vaEEOEg6mgo57zL8bcwIplOaxO8pbeBwzOwxLehLByYv2l10bvCHiyMiJ4ojkcK5DQXlE5/FeYqvLp1euZxnQoi0K0TzmVF14oL9D8DIKqjLAIXYp70R6V/q7SyNQvxr4N3+8fi+n6wLqqjdoe40bIKDR79ZqxtpoF20ItypGwwRdk0FpQ7tIwXR8Oa0uHKFIps+zkxH58/b5T+eeMX0c4yJIRUus9h+nicuGYHppTywWxBnlXQBx/3BBp7422nlYKZWn/8TyIgPbyE7AlpAO+/edDdkqVSzIyHgZ925BMF7aFdhwfaKlFQd4ukbTE5MF58A0XxrZo+iui+qZV/VpHPJmZajhF0Cba20W8vi4nMab0jwxGEX6jeUejJrCaTfKZCGQb48NHgtznyjkI9XV9gNKPn8B/xHqo7ozoqvi467ZFxYf1fMIDmcwnKhrlj9D+r8XbRZwNCiv7fj0OpgBHGctoa6uQLd2pmVQFOm/bKHUEiU1zPSPGPRySh19L2lDDQLTC46b0acZfAj8EZIdmh2P4WeuChaHF4xQLpudgXj06PHozso3hAmURrXtWRZgOv27GpHpS1vRLuQA3dnqw== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ONIS3HtK62w7t94fg3vdClPBYIbzCKL23RKTaeQIGK+qlkWuUAiRRRzaCG?= =?iso-8859-1?Q?t9OztYI6JRHB0Ud452fcbgW4+TVXnUbiVmytmDY1A8PsgIEPCafP/Oxaz+?= =?iso-8859-1?Q?cv81tgalqyzRk7P0+0FKQrJR22PU9FU57LOzdcvLtP2DO8ekszNX1c7s67?= =?iso-8859-1?Q?CBRtt13nGrkJ8HLhUn3CKp0/7J4yyULS/jpVxhumXedEx4hw+nrGvX2yjN?= =?iso-8859-1?Q?BEGieZYwxVbOEiX1CTS20EArGCe0WeO41a4gV4gIHccqSWO05ew35tl4pU?= =?iso-8859-1?Q?B/uIAYBJiAgv56ELVLr5Aj+lLHjrSLDeBv8A+C5oQeerrgCNw6oRW91yxZ?= =?iso-8859-1?Q?rzU3l69CopviV+YO2YJimCaRlrpYMaXlizSSYXo0OPqO0ikxpnUfv4RWE6?= =?iso-8859-1?Q?mkNZRt+ldNKmfyN3Z1ABeV0TYlpfJnpQtEaTOphHXHIv51li8Wq6A8R5B4?= =?iso-8859-1?Q?O8FCXoAiUesUfJShqb/GeTj7ksg/fRO2ycmGEldnDUMjeieDLlJHohKgFi?= =?iso-8859-1?Q?n5jvYQigA39twCNy0gLE6TZr+yz/Grv8FQXX18jZ0c9yTrW1HxtXbpLcge?= =?iso-8859-1?Q?HFSIzqcc4WYbUyvVvPU+kOZkr2rAMo81caoqlfE5zN9IQgwHup31nyASTJ?= =?iso-8859-1?Q? X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 859f5fda-9527-4970-e9da-08dcbd663bdf X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2024 20:09:56.8375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR02MB11083 Received-SPF: pass client-ip=52.103.32.65; envelope-from=arthur.miller@live.com; helo=DUZPR83CU001.outbound.protection.outlook.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 16 Aug 2024 01:26:27 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322794 Archived-At: --_000_DU2PR02MB1010910FA801C8AF7B41F973496802DU2PR02MB10109eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> > > Specifically, modify the `define-ffi-library' macro that emacs-ffi >> > > provides. >> > > >> > > Presently, it takes two arguments: a SYMBOL and a NAME. I am propos= ing >> > > that it be updated to take three arguments: a SYMBOL, a NAME and a >> > > GPL-COMPATIBLE-P token. A value of `t' would be necessary for creat= ing >> > > a reference to the library. >> > >> > And if the value is not t, then the load will fail? If so, then this >> > additional argument makes very little sense: you could instead say >> >> It makes as much sense as it makes in C library. The token is basically = an >> agreement between Emacs developers and the user not to load (link) close= d >> source libraries into Emacs. > >No. What we need is the declaration _by_the_library_ being loaded >that it complies. It is not an agreement between Emacs and the >library, it's a _requirement_ on our part that only the library itself >can fulfill. I have seen your previous answers to others, and I do understand the point = you make, but I think the argument fails because a module can be just a proxy t= o a non-free library. If I can put it in other words, I wonder if it is a "fals= e sense of security", because it is a guarantee by the person who writes the = C module, not the 3rd party library they link to. Of course they are violatin= g the license if they link to a non-free library, but that we are agreeing about = we can't prevent. >> > that just by loading the library, the Lisp program which uses >> > emacs-ffi "declares" the loaded library to be GPL-compatible. And we >> > are back where we began. >> >> Yes, you could. It would just completely remove the barrier. However, >> the token is an explicit acknowledgment of Emacs policy and license term= s, by >> the person who loads the library into Emacs. > >No, see above. > >> > The way we do it when loading modules requires the _loaded_ library to >> > declare itself compatible, by exporting a symbol of a certain name. >> > That is an action by the library we load, not by the Lisp program >> > which loads it. >> >> True. But as you said yourself, a malicious user can easily cicrumvent i= t, >> even >> in C and there is nothing we can do to prevent them other than possibly = taking >> legal actions against them. > >Malicious agents can do all kinds of bad and even unlawful things, but >we are not under any obligations to cater to them. They can always >change the Emacs source code to do whatever they like, but why do you Exactly. >expect _us_ to do it for them, or make it easier for them to do it? No, of course I don't expect that from you. My point was (is?) that it is a trade-off between convinience for Emacs users who would use it as intendend= ed, only with free software, vs the inconvience it causes. If you look at some other projects which are more interesting than Emacs to= use as front-ends for non-free software, do we see influx of companies misusing them? I am thinking of Gtk, KDE/Gnome libs and Libre/OpenOffice for example= . All of those projects could be used to plug-in proprietary software, yet, there= are not so many cases, if any? Even Qt which comes as a dual licensed does not = seem to be misused that way. Perhaps I am just uninformed? You have mentioned llvm, but I am not familiar enough with them. As I under= stand they are financied by Apple, Nvidia and few other big tech companies with explicit goal to have an alternative to GCC just for the more permissive licensing. >> If some company or a state would use Emacs or any other GNU program, as = a >> front-end to closed-source software, there is very little one can do >> technically. It is only the license and the agreement that actually prot= ects >> it. > >That's a separate issue, although it could be related. What is at >stake here is the fact that we don't want to encourage use of Emacs as >such a front-end. That policy of the project is not new, it has many >different expressions, as already mentioned in this thread. We don't >mention non-free software or fonts in our documentation, we don't >install changes that specifically favor or are designed to support >non-free programs, we don't link against non-free libraries except if >they are system libraries, we don't install functionality enhancements >on non-free systems if there's no equivalent on free systems, etc. >etc. So I wonder what is this particular fuss all about. Its I said it in the beginning: sometimes it is useful to revisit policies when circumstancies have changed. >only effect is to waste maintainers' time and energy on replying to >these posts, and I very much doubt this was the intent. So could we Have I ever trolled you before? Why would I want to waste your time and ene= rgy? I am certainly the last person in the world to do that, and you should know= that. I understand it takes time and energy, and I appologize for that, but it is useful to learn why you consider FFI unnaceptable, and to hear the argument= s from the first hand. For the record: I have never brought up this issue bef= ore. >please stop this Nth instance of the same discussions? I cannot >change the project policies even if I wanted, because I promised to >uphold them when Richard nominated me. I wouldn't expect you to change policy on your own neither. I did hope for = RMS, you and other experienced developers to perhaps take a look at the history, perhaps at other software and how Emacs development could be, and reflect o= ver the policy if it is still worth keeping or perhaps it can be changed. ________________________________ Fr=E5n: Eli Zaretskii Skickat: den 15 augusti 2024 09:02 Till: arthur miller Kopia: suhailsingh247@gmail.com ; gerd.moellmann@= gmail.com ; nicolas@n16f.net ; = emacs-devel@gnu.org =C4mne: Re: as for Calc and the math library > From: arthur miller > CC: "gerd.moellmann@gmail.com" , "nicolas@n16f.= net" > , "emacs-devel@gnu.org" > Date: Thu, 15 Aug 2024 05:00:06 +0000 > > > > Specifically, modify the `define-ffi-library' macro that emacs-ffi > > > provides. > > > > > > Presently, it takes two arguments: a SYMBOL and a NAME. I am proposi= ng > > > that it be updated to take three arguments: a SYMBOL, a NAME and a > > > GPL-COMPATIBLE-P token. A value of `t' would be necessary for creati= ng > > > a reference to the library. > > > > And if the value is not t, then the load will fail? If so, then this > > additional argument makes very little sense: you could instead say > > It makes as much sense as it makes in C library. The token is basically a= n > agreement between Emacs developers and the user not to load (link) closed > source libraries into Emacs. No. What we need is the declaration _by_the_library_ being loaded that it complies. It is not an agreement between Emacs and the library, it's a _requirement_ on our part that only the library itself can fulfill. > > that just by loading the library, the Lisp program which uses > > emacs-ffi "declares" the loaded library to be GPL-compatible. And we > > are back where we began. > > Yes, you could. It would just completely remove the barrier. However, > the token is an explicit acknowledgment of Emacs policy and license terms= , by > the person who loads the library into Emacs. No, see above. > > The way we do it when loading modules requires the _loaded_ library to > > declare itself compatible, by exporting a symbol of a certain name. > > That is an action by the library we load, not by the Lisp program > > which loads it. > > True. But as you said yourself, a malicious user can easily cicrumvent it= , even > in C and there is nothing we can do to prevent them other than possibly t= aking > legal actions against them. Malicious agents can do all kinds of bad and even unlawful things, but we are not under any obligations to cater to them. They can always change the Emacs source code to do whatever they like, but why do you expect _us_ to do it for them, or make it easier for them to do it? > If some company or a state would use Emacs or any other GNU program, as a > front-end to closed-source software, there is very little one can do > technically. It is only the license and the agreement that actually prote= cts it. That's a separate issue, although it could be related. What is at stake here is the fact that we don't want to encourage use of Emacs as such a front-end. That policy of the project is not new, it has many different expressions, as already mentioned in this thread. We don't mention non-free software or fonts in our documentation, we don't install changes that specifically favor or are designed to support non-free programs, we don't link against non-free libraries except if they are system libraries, we don't install functionality enhancements on non-free systems if there's no equivalent on free systems, etc. etc. So I wonder what is this particular fuss all about. Its only effect is to waste maintainers' time and energy on replying to these posts, and I very much doubt this was the intent. So could we please stop this Nth instance of the same discussions? I cannot change the project policies even if I wanted, because I promised to uphold them when Richard nominated me. --_000_DU2PR02MB1010910FA801C8AF7B41F973496802DU2PR02MB10109eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>> > > Specifically, modify the `define-ffi-library' macro that= emacs-ffi
>> > > provides.
>> > >
>> > > Presently, it takes two arguments: a SYMBOL and a NAME. =  I am proposing
>> > > that it be updated to take three arguments: a SYMBOL, a = NAME and a
>> > > GPL-COMPATIBLE-P token.  A value of `t' would be ne= cessary for creating
>> > > a reference to the library.
>> >
>> > And if the value is not t, then the load will fail?  If = so, then this
>> > additional argument makes very little sense: you could instea= d say
>>
>> It makes as much sense as it makes in C library. The token is basi= cally an
>> agreement between Emacs developers and the user not to load (link)= closed
>> source libraries into Emacs.
>
>No.  What we need is the declaration _by_the_library_ being loaded=
>that it complies.  It is not an agreement between Emacs and the
>library, it's a _requirement_ on our part that only the library itself<= /div>
>can fulfill.

I have seen your previous answers to others, and I do understand the point = you
make, but I think the argument fails because a module can be just a proxy t= o a
non-free library. If I can put it in other words, I wonder if it is a "= ;false
sense of security", because it is a guarantee by the person who writes= the C
module, not the 3rd party library they link to. Of course they are violatin= g the
license if they link to a non-free library, but that we are agreeing about = we
can't prevent.

>> > that just by loading the library, the Lisp program which uses=
>> > emacs-ffi "declares" the loaded library to be GPL-c= ompatible.  And we
>> > are back where we began.
>>
>> Yes, you could. It would just completely remove the barrier. Howev= er,
>> the token is an explicit acknowledgment of Emacs policy and licens= e terms, by
>> the person who loads the library into Emacs.
>
>No, see above.
>
>> > The way we do it when loading modules requires the _loaded_ l= ibrary to
>> > declare itself compatible, by exporting a symbol of a certain= name.
>> > That is an action by the library we load, not by the Lisp pro= gram
>> > which loads it.
>>
>> True. But as you said yourself, a malicious user can easily cicrum= vent it,
>> even
>> in C and there is nothing we can do to prevent them other than pos= sibly taking
>> legal actions against them.
>
>Malicious agents can do all kinds of bad and even unlawful things, but<= /div>
>we are not under any obligations to cater to them.  They can alway= s
>change the Emacs source code to do whatever they like, but why do you

Exactly.

>expect _us_ to do it for them, or make it easier for them to do it?

No, of course I don't expect that from you. My point was (is?) that it is a=
trade-off between convinience for Emacs users who would use it as intendend= ed,
only with free software, vs the inconvience it causes.

If you look at some other projects which are more interesting than Emacs to= use
as front-ends for non-free software, do we see influx of companies misusing=
them? I am thinking of Gtk, KDE/Gnome libs and Libre/OpenOffice for example= . All
of those projects could be used to plug-in proprietary software, yet, there= are
not so many cases, if any? Even Qt which comes as a dual licensed does not = seem
to be misused that way. Perhaps I am just uninformed?

You have mentioned llvm, but I am not familiar enough with them. As I under= stand
they are financied by Apple, Nvidia and few other big tech companies with
explicit goal to have an alternative to GCC just for the more permissive
licensing.

>> If some company or a state would use Emacs or any other GNU progra= m, as a
>> front-end to closed-source software, there is very little one can = do
>> technically. It is only the license and the agreement that actuall= y protects
>> it.
>
>That's a separate issue, although it could be related.  What is at=
>stake here is the fact that we don't want to encourage use of Emacs as<= /div>
>such a front-end.  That policy of the project is not new, it has m= any
>different expressions, as already mentioned in this thread.  We do= n't
>mention non-free software or fonts in our documentation, we don't
>install changes that specifically favor or are designed to support
>non-free programs, we don't link against non-free libraries except if
>they are system libraries, we don't install functionality enhancements<= /div>
>on non-free systems if there's no equivalent on free systems, etc.
>etc.  So I wonder what is this particular fuss all about.  It= s

I said it in the beginning: sometimes it is useful to revisit policies
when circumstancies have changed.

>only effect is to waste maintainers' time and energy on replying to
>these posts, and I very much doubt this was the intent.  So could = we

Have I ever trolled you before? Why would I want to waste your time and ene= rgy?
I am certainly the last person in the world to do that, and you should know= that.
I understand it takes time and energy, and I appologize for that, but it is=
useful to learn why you consider FFI unnaceptable, and to hear the argument= s
from the first hand. For the record: I have never brought up this issue bef= ore.

>please stop this Nth instance of the same discussions?  I cannot
>change the project policies even if I wanted, because I promised to
>uphold them when Richard nominated me.

I wouldn't expect you to change policy on your own neither. I did hope for = RMS,
you and other experienced developers to perhaps take a look at the history,=
perhaps at other software and how Emacs development could be, and reflect o= ver
the policy if it is still worth keeping or perhaps it can be changed.
Fr=E5n: Eli Zaretskii <e= liz@gnu.org>
Skickat: den 15 augusti 2024 09:02
Till: arthur miller <arthur.miller@live.com>
Kopia: suhailsingh247@gmail.com <suhailsingh247@gmail.com>; ge= rd.moellmann@gmail.com <gerd.moellmann@gmail.com>; nicolas@n16f.net &= lt;nicolas@n16f.net>; emacs-devel@gnu.org <emacs-devel@gnu.org> =C4mne: Re: as for Calc and the math library
 
> From: arthur miller <arthur.miller@live.co= m>
> CC: "gerd.moellmann@gmail.com" <gerd.moellmann@gmail.com&= gt;, "nicolas@n16f.net"
>        <nicolas@n16f.net>, &q= uot;emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 15 Aug 2024 05:00:06 +0000
>
> > > Specifically, modify the `define-ffi-library' macro that ema= cs-ffi
> > > provides.
> > >
> > > Presently, it takes two arguments: a SYMBOL and a NAME. = ; I am proposing
> > > that it be updated to take three arguments: a SYMBOL, a NAME= and a
> > > GPL-COMPATIBLE-P token.  A value of `t' would be necess= ary for creating
> > > a reference to the library.
> >
> > And if the value is not t, then the load will fail?  If so, = then this
> > additional argument makes very little sense: you could instead sa= y
>
> It makes as much sense as it makes in C library. The token is basicall= y an
> agreement between Emacs developers and the user not to load (link) clo= sed
> source libraries into Emacs.

No.  What we need is the declaration _by_the_library_ being loaded
that it complies.  It is not an agreement between Emacs and the
library, it's a _requirement_ on our part that only the library itself
can fulfill.

> > that just by loading the library, the Lisp program which uses
> > emacs-ffi "declares" the loaded library to be GPL-compa= tible.  And we
> > are back where we began.
>
> Yes, you could. It would just completely remove the barrier. However,<= br> > the token is an explicit acknowledgment of Emacs policy and license te= rms, by
> the person who loads the library into Emacs.

No, see above.

> > The way we do it when loading modules requires the _loaded_ libra= ry to
> > declare itself compatible, by exporting a symbol of a certain nam= e.
> > That is an action by the library we load, not by the Lisp program=
> > which loads it.
>
> True. But as you said yourself, a malicious user can easily cicrumvent= it, even
> in C and there is nothing we can do to prevent them other than possibl= y taking
> legal actions against them.

Malicious agents can do all kinds of bad and even unlawful things, but
we are not under any obligations to cater to them.  They can always change the Emacs source code to do whatever they like, but why do you
expect _us_ to do it for them, or make it easier for them to do it?

> If some company or a state would use Emacs or any other GNU program, a= s a
> front-end to closed-source software, there is very little one can do > technically. It is only the license and the agreement that actually pr= otects it.

That's a separate issue, although it could be related.  What is at
stake here is the fact that we don't want to encourage use of Emacs as
such a front-end.  That policy of the project is not new, it has many<= br> different expressions, as already mentioned in this thread.  We don't<= br> mention non-free software or fonts in our documentation, we don't
install changes that specifically favor or are designed to support
non-free programs, we don't link against non-free libraries except if
they are system libraries, we don't install functionality enhancements
on non-free systems if there's no equivalent on free systems, etc.
etc.  So I wonder what is this particular fuss all about.  Its only effect is to waste maintainers' time and energy on replying to
these posts, and I very much doubt this was the intent.  So could we please stop this Nth instance of the same discussions?  I cannot
change the project policies even if I wanted, because I promised to
uphold them when Richard nominated me.
--_000_DU2PR02MB1010910FA801C8AF7B41F973496802DU2PR02MB10109eu_--