From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: as for Calc and the math library Date: Thu, 15 Aug 2024 19:39:18 +0300 Message-ID: <867cch7nbd.fsf@gnu.org> References: <864j7qhup6.fsf@gnu.org> <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <875xs60wmc.fsf@valhala.localdomain> <86wmklho4m.fsf@gnu.org> <864j7m8ewk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8642"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org To: Christopher Dimech Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 15 18:40:16 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 1sedWK-00025F-Kd for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Aug 2024 18:40:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sedVa-0005u3-P1; Thu, 15 Aug 2024 12:39:30 -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 1sedVZ-0005tt-9Y for emacs-devel@gnu.org; Thu, 15 Aug 2024 12:39:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sedVY-0000VC-Ud; Thu, 15 Aug 2024 12:39:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=wihfo66oPNs5TKUOKoA0PpCUM8njdV9L05zYXR5hNjA=; b=NUAOVw0rZer060SK/mAX kiWw8Tx+2egC5rWARUeUOrImoFKTSmkAnxW0y+aMHSTRCXkY578O0aGSxR6LKd6ERqh6VKa0gJdqa Vt9hTCpXw6Mx9VLSk5kxRuYvcu4aP7mNJ4vSr1/twEmp18T20nsPDgTmbelXz2j+rbdC/1DClBRZ6 gBj7qDuRquY1asygohEPoFc0tIw6YUYkvQTZVCegn6+qm6ROo+/CGxoSRAmbBn/aiRPoe0LqGe5h8 3m7KjQAYrAxk7DVJiPHaCGDWNa4rMhYCfEYXcfkdrKe/wUOlzXEsj5BIfPiaYmAfLkkCArbTVSBHK +GcXjn2IJrFy9A==; In-Reply-To: (message from Christopher Dimech on Thu, 15 Aug 2024 15:28:24 +0200) 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:322788 Archived-At: > From: Christopher Dimech > Cc: rms@gnu.org, emacs-devel@gnu.org > Date: Thu, 15 Aug 2024 15:28:24 +0200 > > The focus in free software is on creating clear, understandable, and > accessible code. That's _part_ of our focus here. Another part, and definitely no less important, is to make sure the software is free. > The core principle of free software Just one of the core principles, not the only one. > is that users have the freedom to study, modify, and distribute the > software as they see fit. Not "as they see fit": there are some restrictions on what they can do. For example, they cannot distribute the modified software without its complete source code, including the modifications and additions. > This freedom is best supported by writing clear and well-documented > code that users can easily understand and adapt to their needs. And by other measures, some of which are no less important. > Encouraging free software adoption through software design or structural > means — such as intentionally complicating the code to guide or limit how > users interact with it — is problematic. It's a judgment call, yes. There's a trade-off to be considered. > This approach runs counter to > the spirit of free software because it resembles the kind of code > obfuscation often seen in proprietary software, where the intent is to > prevent users from understanding or modifying the code. No, nothing in the specific issue at hand causes any kind of obfuscation. > In free software, the goal should be to empower users, not restrict > them. To empower users to be able to use, modify, and redistribute the software they receive. Not to empower them to do everything imaginable. > Any attempt to influence how users engage with the software > through code structure, rather than through education or advocacy, > undermines the principles of transparency and user freedom that are > central to the free software movement. No, nothing in our practice undermines any transparency nor any user freedom to use, study, and modify the software. > The power of free software lies in its openness, and that openness > should be reflected in the clarity and accessibility of the code > itself. Nothing in our practice makes the Emacs code less open and clear. > There is ambiguity in determining software freedom. One cannot always > determine a priori whether external software is free or non-free without > examining its license. Imposing restrictions or enforcing certain ways > of doing things to ensure compliance with the free software ethos is an > overreaching approach. Once again, this is the approach taken by the GNU Project, and if you want to argue against it, you are in the wrong place. Kindly take this dispute elsewhere. > The statement you’re referring to touches on an important aspect of the > free software ecosystem - namely, that the GPL (GNU General Public > License) is just one of many licenses under which free software can be > distributed. The idea that software needs to be GPL-compliant is indeed > a common misconception, but it's more accurate to say that it needs to > be compatible with the GPL, especially when interacting with GPL-licensed > code. > > But only when distributed. For software that is not distributed (e.g., > used privately or within an organization), these requirements do not > apply. Nothing in what we do prevents users from doing whatever they like with Emacs as long as they do it for their private use. > Suggesting or enforcing limitations on what users can code, even > in private use is where the controversy lies. No one enforces users to do anything nor prevents them from doing anything they like. The request was to force the Emacs project to actively help people do something that we do not want to endorse. Such kind of request is ridiculous: a software project is not obliged to do everything its users request, only those parts with which it (the project) agrees. > The GPL, as stated, does not place restrictions on private > modifications or use. Yes. > Users are free to experiment, modify, and even create non-free > software for their private use, without any obligation to comply > with the GPL’s distribution requirements. Yes. > But you decided to hinder that possibility. No. Please stop accusing the project with these false accusations.