From: Christopher Dimech <dimech@gmx.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: as for Calc and the math library
Date: Thu, 15 Aug 2024 15:28:24 +0200 [thread overview]
Message-ID: <trinity-548990af-f8fb-4fcf-a209-41876a7b9a3c-1723728504101@3c-app-mailcom-bs02> (raw)
In-Reply-To: <864j7m8ewk.fsf@gnu.org>
> Sent: Thursday, August 15, 2024 at 6:43 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: emacs-devel@gnu.org
> > Date: Thu, 15 Aug 2024 05:06:47 +0200
> >
> > > However, _distribution_ of such a nonfree combination would violate
> > > GPLv3.
> >
> > Despite this clarity, there's a recurring problem with the community:
> > some maintainers go beyond the requirements of the GPL3 by creating
> > additional barriers within the source code to prevent what they perceive
> > as undesirable use cases.
> >
> > This could involve adding checks to verify that only certain libraries
> > are used or implementing "allowed-lists" to restrict what modifications
> > can be made or with what the software can interact.
> >
> > It's quite right to argue that these additional obstacles are
> > unnecessary and, in some cases, counterproductive. The GPL3 already sets
> > clear boundaries — if a nonfree module or library is being used in a way
> > that is kept private and not distributed, it is perfectly legal under
> > the license. The problem arises when maintainers attempt to enforce
> > additional restrictions that go beyond the license’s requirements,
> > sometimes under the misconception that doing so aligns with the GPL's
> > spirit.
>
> The maintainers only add these obstacles when there's a request for
> Emacs as a project to distribute code which would allow making Emacs a
> front-end for non-free software. As long as such code is used
> privately by someone, or even left on some repository outside of
> Emacs, it is not our business (although distributing non-compliant
> software which claims to be compliant is against the law). But please
> understand that you cannot request _us_ to include such code in Emacs,
> because then _we_ will be either violating the GPL or encouraging use
> of non-free software.
> And please don't forget or ignore that in addition to GPL violations,
> there's one more aspect involved here, and that is not to encourage
> use of non-free software. For the same reason we don't mention
> non-free programs or libraries or fonts in our sources and
> documentation, we do not intend to make it easy for people to use
> non-free shared libraries by providing _our_ code that caters to such
> use cases.
The focus in free software is on creating clear, understandable, and
accessible code. The core principle of free software is that users have
the freedom to study, modify, and distribute the software as they see
fit. This freedom is best supported by writing clear and well-documented
code that users can easily understand and adapt to their needs.
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. 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.
In free software, the goal should be to empower users, not restrict
them. 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. The power of free software lies
in its openness, and that openness should be reflected in the clarity
and accessibility of the code itself.
> Emacs is Free Software, so anyone can take its sources and
> modify them to do whatever they want, but don't expect _us_ to do that
> as part of the official Emacs sources. This is not new, although some
> people tend to raise the same issues here time and again for some
> reason.
>
> > For instance, claims that using a nonfree library with a GPL3-covered
> > module is inherently illegal reflect a misunderstanding of the
> > license.
>
> It would be illegal for a library to claim GPL compliance when in fact
> there's no compliance, yes. Other than that, no one said anything
> about the legal aspects; the issues discussed in this thread are our
> usual ethics that precludes us from encouraging use of non-free
> software in conjunction with Emacs.
Emacs, as a project, must always ensure that its releases are fully
compliant with the GPL, which governs its distribution and use.
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. Forcing a particular method of interaction and
then claiming that this makes the software free misses the point that
freedom is inherent in the license itself, not in the prescribed usage.
> > As clarified, such usage is only problematic if the
> > software is distributed. Unfortunately, these misunderstandings can lead
> > to a unpleasant environment where maintainers unnecessarily police the
> > actions of users or other developers, potentially stifling innovation
> > and cooperation.
>
> It could, but it doesn't, not in this case.
>
> > Moreover, some maintainers might believe they are in a better position
> > to judge what is or isn't permissible under the GPL3.
>
> This is a strawman: no one said anything about GPL; the fact that the
> symbol required by loading dynamic modules has "GPL" in its name does
> not contradict this, because the requirement is to be GPL-compatible,
> not GPLv3.
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. Suggesting or enforcing limitations on what users can code, even
in private use is where the controversy lies. The GPL, as stated, does
not place restrictions on private modifications or use. 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. But you decided to hinder that possibility.
An additional item to the list of bad ideas.
next prev parent reply other threads:[~2024-08-15 13:28 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 5:30 as for Calc and the math library arthur miller
2024-08-12 11:00 ` Eli Zaretskii
2024-08-12 11:23 ` Nicolas Martyanoff
2024-08-12 11:46 ` Eli Zaretskii
2024-08-12 12:11 ` Nicolas Martyanoff
2024-08-12 13:22 ` Eli Zaretskii
2024-08-12 13:38 ` Christopher Dimech
2024-08-15 1:59 ` Richard Stallman
2024-08-15 3:06 ` Christopher Dimech
2024-08-15 6:43 ` Eli Zaretskii
2024-08-15 13:28 ` Christopher Dimech [this message]
2024-08-15 16:39 ` Eli Zaretskii
2024-08-13 7:16 ` Sv: " arthur miller
2024-08-13 12:12 ` Eli Zaretskii
2024-08-13 13:10 ` Nicolas Martyanoff
2024-08-13 13:30 ` Eli Zaretskii
2024-08-13 13:48 ` Nicolas Martyanoff
2024-08-13 21:43 ` Sv: " arthur miller
2024-08-14 5:09 ` Eli Zaretskii
2024-08-14 8:45 ` Sv: " arthur miller
2024-08-14 9:56 ` Nicolas Martyanoff
2024-08-14 10:43 ` Eli Zaretskii
2024-08-13 5:39 ` Gerd Möllmann
2024-08-14 4:11 ` Gerd Möllmann
2024-08-14 6:23 ` Eli Zaretskii
2024-08-14 6:28 ` Gerd Möllmann
2024-08-14 6:43 ` Eli Zaretskii
2024-08-14 14:00 ` Suhail Singh
2024-08-14 14:20 ` Eli Zaretskii
2024-08-14 15:08 ` Suhail Singh
2024-08-14 15:31 ` Eli Zaretskii
2024-08-14 16:00 ` Suhail Singh
2024-08-14 16:24 ` Eli Zaretskii
2024-08-14 20:35 ` Emanuel Berg
2024-08-15 5:00 ` Sv: " arthur miller
2024-08-15 7:02 ` Eli Zaretskii
2024-08-15 20:09 ` Sv: " arthur miller
2024-08-16 5:47 ` Eli Zaretskii
2024-08-16 6:17 ` we need *modularity* [last problem] (was: Re: as for Calc and the math library) Emanuel Berg
2024-08-16 9:35 ` first-is (3 versions, Elisp hangup) (was: Re: we need *modularity* [last problem]) Emanuel Berg
2024-08-16 9:53 ` Emanuel Berg
2024-08-16 10:57 ` Eli Zaretskii
2024-08-18 16:38 ` as for Calc and the math library Richard Stallman
2024-08-18 17:27 ` Christopher Dimech
2024-08-19 12:05 ` Sv: " arthur miller
2024-08-24 2:59 ` Richard Stallman
2024-08-24 2:59 ` Richard Stallman
2024-08-15 9:31 ` Emacs ffi (was: Re: as for Calc and the math library) Andrea Corallo
2024-08-15 9:43 ` Eli Zaretskii
2024-08-15 20:32 ` Emacs ffi Andrea Corallo
[not found] ` <trinity-a24567af-9dc5-4e16-960c-c42d9759f282-1723755762558@3c-app-mailcom-bs05>
2024-08-16 20:07 ` Andrea Corallo
2024-08-16 21:21 ` Christopher Dimech
2024-08-17 6:06 ` Eli Zaretskii
2024-08-17 9:05 ` Christopher Dimech
2024-08-17 10:53 ` Eli Zaretskii
2024-08-17 13:21 ` Stefan Kangas
2024-08-17 14:30 ` Joel Reicher
2024-08-17 17:18 ` Christopher Dimech
2024-08-18 4:44 ` Emanuel Berg
2024-08-19 12:38 ` Sv: " arthur miller
2024-08-17 15:36 ` Christopher Dimech
2024-08-18 5:25 ` Emanuel Berg
2024-08-17 15:23 ` Andrea Corallo
2024-08-18 13:26 ` Björn Bidar
[not found] ` <87h6birmfy.fsf@>
2024-08-19 16:57 ` Richard Stallman
2024-08-19 17:22 ` Christopher Dimech
2024-08-17 2:21 ` Emanuel Berg
2024-08-14 14:35 ` as for Calc and the math library Gerd Möllmann
2024-08-14 14:40 ` Nicolas Martyanoff
2024-08-14 14:47 ` Gerd Möllmann
2024-08-14 14:49 ` Eli Zaretskii
2024-08-14 5:29 ` Madhu
2024-08-14 6:06 ` [ffi] " Madhu
-- strict thread matches above, loose matches on Subject: below --
2024-08-10 22:48 Emanuel Berg
2024-08-11 4:58 ` Eli Zaretskii
2024-08-11 16:45 ` Ihor Radchenko
2024-08-11 16:55 ` Christopher Dimech
2024-08-11 17:05 ` Emanuel Berg
2024-08-11 17:59 ` Eli Zaretskii
2024-08-11 18:17 ` Christopher Dimech
2024-08-11 18:32 ` Eli Zaretskii
2024-08-11 19:53 ` Christopher Dimech
2024-08-11 18:27 ` Ihor Radchenko
2024-08-11 18:38 ` Emanuel Berg
2024-08-11 18:52 ` Eli Zaretskii
2024-08-11 19:13 ` Ihor Radchenko
2024-08-12 2:24 ` Eli Zaretskii
2024-08-11 21:50 ` Christopher Dimech
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-548990af-f8fb-4fcf-a209-41876a7b9a3c-1723728504101@3c-app-mailcom-bs02 \
--to=dimech@gmx.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).