emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Providing Emacs Dependencies with Nix & Guix


From: Ship Mints
Subject: Re: Providing Emacs Dependencies with Nix & Guix
Date: Thu, 27 Feb 2025 07:37:24 -0500

Is there a "dogma" mailing list to which this part of the discussion can be moved?  I'd rather see the Nix/Guix ideas discussed unitarily, much like code commits should be narrowed to as small a unit as practical.  Perhaps people could reply privately to make dogmatic views known rather than "tangent" the main discussion.  I hope my suggestion doesn't itself represent dogma, so much as pragmatism.

I'd prefer Guix over Nix, but, due to dogma, the Guix community is not willing to make macOS a primary platform despite its hybrid open source/proprietary code base (I suggest this is a reasonable compromise for a commercial company to make).  We've seen that at least 25% of Emacs users are macOS users and that should count for a lot.  Many macOS users use, support, and encourage GNU software use on back-end servers, or as virtual machines, with concomitant strong influence on GNU software.  Dogma can be pragmatic, and less alienating, if people choose for it to be.

Let's have the Emacs community continue to set an example of how to do this well.  We're all in this together.

On Thu, Feb 27, 2025 at 2:35 AM Psionic K <psionik@positron.solutions> wrote:
> on GNU project mailing lists, refer to GNU systems running the Linux kernel as "GNU/Linux"

> avoid the cant word "open source"

Respectfully, I decline both recommendations.  I have made a conscious choice that I will ask you to respect as an instance our known and compatible differences.  I intentionally have begun using the acronym _OSS to indicate that it is no accident that I advocate an open source rather than "Free/Libre" ideology.

The differences include the principles such as:
- Plurality: Any open community intending to represent all users must find ways to incorporate all views that at a minimum support plurality and respect independence on any topic where there is no technical reason for a singular exclusive answer.
- Freedom to Invade: Rather than avoiding closed systems, we should, the same as we did when using closed compilers to port GCC to closed platforms, maximize the application of closed platforms and tools where it suits our interests rather than isolate ourselves from users.
- Specialization: Software is intrinsically economic.  The skill level required to maintain and extend software requires more time and investment than is available, especially if we asked all specialized work to be handled by all people.  We should find ways to incorporate the demand from users who can only make non-code contribution.  The self-serve software economy only ever worked when software was extremely simple and the users were almost exclusively programmers.

I invite others to proudly use _OSS to indicate this intentional, well-intentioned, consciously developing set of views that are independent from "Free/Libre" ideals we all are well familiar with in FSF and GNU circles.  I have begun to present these views on YouTube.  Those who use software may navigate to https://youtu.be/NwDEpWC-Bo8 if interested.  The use of _OSS is not tightly defined and is a more liberal view.  It is not exclusive, and so it is compatible with cooperation on any project, including GNU Emacs.  The use of _OSS is not a denouncement of the FSF or "Free/Libre" so much as a demand to evolve and a determination to evolve on our own in the absence of necessary evolution elsewhere.  The use of _OSS is to block the misinterpretation of _OSS as a mistake or oversight.  "Free/Libre" advocates will not mistakenly suggest, "don't you mean 'Free/Libre'?"  The placeholder _ removes the ambiguity so that it is not unintentionally appropriated.  Therefore _OSS.

I do not recognize "GNU/Linux" as a fact.  While the FSF and GNU made essential contributions to the early days of mass computing when so many Unix vendors from Dilbert comics engaged in "stupid competition" (competition which hurts the market and consumers), I will no more call Linux GNU/Linux than I will it Ritchie/GNU/Linux owing to their massive debt to C and Unix or Turing/Ritchie/GNU/Linux etc.  The relationship exists only insofar as GNU tools ride the Linux wave.  It is not inseparable or intrinsic.  The reality is that a spectrum of GNU and non-GNU tools are in symbiosis and competitive equilibrium in the support of the Linux kernel.  Attempts to enforce GNU upon Linux can only harm Linux.  That the FSF is currently failing in its recognition of GNU's relationship with Linux can be seen prominently and incontrovertibly in the use of the GPL2 and adoption of the DCO, a practice that the FSF should have seen coming and figured out how to do right rather than fearing for their own role as a custodian of copyrights.  I see the insistence on GNU/Linux as a form of egoism and all egoism is inevitably destructive to the self.  Therefore I encourage the FSF and GNU to abandon the term, which has little common recognition outside of GNU projects and FSF literature.

In protest of the FSF's shortcomings with the GPL, I have decided to revert to permissive MIT licenses on all of my new open source software and anywhere I hold sufficient copyrights now.  I don't do this because I think the MIT license is superior but because it was the FSF's responsibility to continue evolving, and I don't believe that they did.  It wasn't my responsibility to care, but if the FSF dropped the ball, they made it my responsibility.  Since I am not an expert in that area, I will simply open the door to some future improvement rather than endorse the FSF for now.

I respect that everyone is well-intentioned and that we have differences in philosophy.  I intended to make clear that my stance is not an accident and that while I'm open to evolving my own views, I will continue to push _OSS because I believe the FSF is unwaveringly committed to a set of views I consider to have been developed for a different set of expectations than the reality we can observe today.  There were two decades to figure out what to do in the Web 2.0 era.  I won't wait two decades into the gen AI era for the FSF to still be looking for a plan.

Sincerely,
K

reply via email to

[Prev in Thread] Current Thread [Next in Thread]