> And I don't think that RMS is the only reason the free software movement has failed
For one thing it hasn't failed, the free software movement has been an amazing success.
For another, RMS created the free software movement, in an era where most software was proprietary. The GPL, LGPL, and probably many subsequent free software licenses might not exist if not for him. Read his story that led him to this: he was trying to connect a printer to a new machine in the late 1970s or early 1980s, and the maker would not share their proprietary drivers, even though he was willing to port it to the new machine himself, so he reverse engineered it, wrote a new driver himself, and proclaimed his version to be free for all so others wouldn't have to face that same problem in the future, on the condition that they also share any improvements they make to it. Viewing most RMS behavior through the lens of this early formative experience makes it mostly make sense.
Most of the article is really not about the FSF but about emacs. Emacs is Stallman's own project - he started it in the 1980s and remains its mostly-benevolent dictator. He wants it to abide by his own strict principles. If others disagree, they're free to fork it, as has been done over the years. And his free software ideals are the reason they have that freedom.
I just don't see a general argument here to justify the broad title about the FSF in general.
> For another, RMS created the free software movement, in an era where most software was proprietary.
Stallman did a lot of things, but he most definitely did not start the free software movement. Free software was the norm prior to the meeting of the Committee on New Technology Uses (CONTU) suggesting in 1977 that rather than try to amend the recently passed Copyright Act of 1976 they should just classify software as 'literature'. It continued to be the norm and was openly termed "Freeware" by author Jay Lucas at InfoWorld (until a certain lawyer, Andrew Fluegelman, trademarked the term and began threatening legal action if he didn't change the name of his "Freeware" column, leading to a contest which suggested the term "Shareware"). Most freeware of the time came with source code and the right to make modifications (in fact this is how a number of improvements were made to Fluegelman's own PC-TALK). It wasn't until after the coining of Shareware that the two terms were hijacked by people essentially using it to create freely recirculatable demos of otherwise proprietary products, much like 'free software' was later repackaged as 'open source'.
I'm not saying you shouldn't be thankful for his contributions, but to pretend that BSD didn't exist, nor an entire tradition of free software prior to the rise of proprietary software, is simply wrong.
Free Software is software where you're obligated to share your source code changes if you distribute them. It's not anything that was ever referred to once as "free software" outside of this definition, and it is not any software that is free.
edit: hearing irrelevant histories like this makes me more upset that Stallman is the only person who keeps Free Software firmly in mind, and doesn't waver. Free software isn't a vibe, Open Source software can easily become Free Software if you relicense it within a GPL'd project (just as it can be incorporated into proprietary projects), but Open Source software is not Free Software. Free Software is what Stallman said it was, and has only been extended in a few logical ways that Stallman failed to anticipate ahead of time.
Histories of people sharing source, and of not being able to copyright software are nice, but irrelevant.
All copyleft software is Free software (as defined by the FSF), but not all Free software is copyleft. So it's incorrect to say that all Free software licenses obligate you to share your changes to the source code. Permissive licenses like MIT and BSD are also Free software licenses according to the FSF.
Free software doesn't need to be copyleft, which is what you're describing - eg, the FSF explicitly considers 3 clause BSD to be a free license. Similarly Open Source (as used by the OSI) doesn't require that you can incorporate into proprietary projects and it considers the GPL to be open source. Somewhat famously the definitions of the two terms are basically equivalent even though they're motivated quite differently.
I think it is time to refuse to call GPL 'free software'. It is not free like freedom. It can be free as free beer, but since you must pay for it with your changes, and can't/hard to monetize them, free as beer is questionable as best.
I don't think you "must pay for it with your changes," as in article 5, Conveying Modified Source Versions, it only says that the work must do the following:
- have a notice that you modified it,
- have a notice that the work is licensed under the GPL,
- be licensed under the GPL, and
- if the work has interactive UIs, it must display Appropriate Legal Notices.
It says nothing about contributing changes back, the only freedom it restricts is the "freedom" to restrict the freedom of others. It is like the whole "is prohibiting slavery reducing freedom" problem.
> in article 5, Conveying Modified Source Versions, it only says that the work must do the following:
You have to keep reading the entire license...
Section 6 of v3 begins:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
<or several other functionally similar ways are options in the full text linked below>
How is that not needing to convey your source changes to those whom you distribute the object code?
It’s been there since v1:
Paragraph 3 of the v1 or v2 GPL is similar to section 6 of v3:
You may copy and distribute the Program (or a portion or derivative of
it, under Paragraph 2) in object code or executable form under the terms of
Paragraphs 1 and 2 above provided that you also do one of the following:
a) accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of
Paragraphs 1 and 2 above; or,
I think we have a different view on the meaning of "pay with your changes." I take it to mean "you must send patches/pull requests/... to the upstream project," which isn't the case. Whereas, if my reading of your message is right (feel free to correct me if I'm wrong) you consider it to mean something like "you must make the changes you make public."
I personally wouldn't consider the second interpretation as "paying" for Free Software any more as I would consider having people publically criticise me as "paying" for Free Expression.
You only have to send your changes to anyone to whom you distribute the modified program.
If that’s upstream, then you have to offer them upstream. If that’s to someone else who then decides to share them upstream, that’s also something you can’t prevent.
If you don’t distribute the program, you don’t have to send your changes anywhere.
(My main point was your citation of only Section 5 was incomplete with regards to your obligations under GPL.)
> It is like the whole "is prohibiting slavery reducing freedom" problem.
Except there are dozens of incompatible (A/L)GPL (2,3) licenses alone and an uncountable number of minor modifications of the same. So you end up with the "freedom" not to share code between various GPLed projects because they all are slightly different flavors of free.
Also the free but not really has already a name, called shareware. I think it's just their marketing ability that they managed to be called free software, despite the definition of the word. (But GPL is not really about the price of the software, they aim to be free as freedom, but .. they are not.)
The hardware manufacturers are adapting. They're now using cryptography to maintain control over "our" machines. Now we can only run software they sign off on. What good is free software if we can't run any of it?
There's something even more important than free software and that is free computing. Free software takes free computers for granted. It assumes we're able to develop and run whatever software we want. This is increasingly no longer the case.
This is a FUD take. Are you griping about TPMs? I run Linux on every one of my personal machines and I run the software I want and I use my TPMs for useful things. I keep hearing this cry about hardware manufactures are coming for our hardware freedoms and I have seen one instance this year where Lenovo did some stupid stuff[1] on a specific piece of hardware.
Now that I know that, I am not going to buy that specific hardware for my needs. If they follow onto their other models, I will find a hardware vendor that doesn't do stupid stuff. The market will adjust and you will have options like the Framework laptop to give you the freedom you want with your hardware.
Also, even with the above stupid stuff, you can disable secure boot for now and move on with your life.
Normal desktop processors already come with features designed to protect memory and code from the prying eyes of users. Not to mention all the ring -5 code that is really in control of the computer.
Smartphones now have attestation. They have hardware designed to cryptographically prove to its real owners that those pesky users haven't tampered with their phones. Software will refuse to run if this fails and it's not really something you can override by hacking on the OS.
Face it, hardware today comes pwned from the factory. Hardware doesn't belong to us anymore, they belong to the "stakeholders" and they're only generously allowing us to use it so long we don't run any software they don't like.
Now try running your own build of Linux on a phone, or similar devices. It most probably won't work, because the likes of Qualcomm, Mediatek, Samsung, Huawei, Apple have locked down the hardware so you can only boot digitally signed firmware that matches public keys fused into the device. And that firmware does the same when loading the rest of the OS.
> Also, even with the above stupid stuff, you can disable secure boot for now and move on with your life.
Except for Android phones (nominally, an open source OS), disabling the cryptographic protections results in the loss of your Safety Net status, and from now on a whole host of applications will refuse to work at all, or have reduced functionality. Make no mistake, I think this is the future of the PC.
> from now on a whole host of applications will refuse to work at all
This is pretty scary. I know I close the tab and move on when I see a notice on Firefox that says something to the effect of I must enable DRM to play media on this website (paraphrasing) but what if a bank or the government says the same?
I think the answer goes back to we can't solve societal problems through technological means. We have to get involved in politics. If anything is a legal monopoly (such as taxes), it should use open protocols and be accessible through free software.
Yeah but how can we even win in such a space? These monopolistic corporations are already involved, they spend loads of money on lobbyists in order to legitimize their abuse. How can we possibly beat that?
> Are you griping about TPMs? I run Linux on every one of my personal machines and I run the software I want and I use my TPMs for useful things.
There's no inherent problem with TPMs existing, since they do have some legitimate use cases. The problem with them is that they don't support owner override. Fixing that would make them useless for tyranny without impacting any legitimate use cases.
You misunderstand what owner override is. It's not the ability to disable the TPM from functioning. It's having a way to tell the TPM to attest "yes, this system is totally running Microsoft/Hollywood-approved software" when it really isn't, if that's what the owner wants it to do.
Yeah. There's little point in overriding anything since these days everything requires remote attestation that software hasn't been "tampered with". What good is installing custom software if the applications we need refuse to run because we "tampered" with stuff?
I must misunderstand what override. Wouldn't the "override" term in this case be better served as being called "customised validated attestation state" ? Its doesn't roll of the tongue but correct terms matter.
Then don't run that software or don't buy that hardware in the first place? There are plenty of options here.
A TPMs main role in our current hardware ecosystem is to provide device identity and attestation. This has been driven by businesses that want an easier time to bootstrap hardware for their needs. Which means controlling what software is run on company owned hardware.
All of the FUD about lost of hardware freedom comes some from the fact that IT teams were tired of having to keep inventory and they needed a solution to enable the on boarding and off boarding of hardware. Look at what Apple is doing with their hardware and OS right now. It's not to take away more individual freedoms of their users. It is to help businesses and edu manage their Apple stuff stuff. The other vendors are trying to fix those pain points too.
Managed device attestation is the SBOM new new hotness of 2023 and you don't need to be a big business to take advantage of it.
> Then don't run that software or don't buy that hardware in the first place? There are plenty of options here.
Yeah, right. Just don't use any proprietary software. Just don't use any mobile app. Just don't buy any mainstream hardware and products. Enjoy all those ridiculously old FSF RYF certified laptops that won't run anything requiring the latest cryptographic user control features anyway.
How in the world is this a solution? These corporations should be forced by law not to do this stuff. The hardware and software should be open and free and they should have no choice but to run on it on our terms if they want to reach customers at all.
> Look at what Apple is doing with their hardware and OS right now. It's not to take away more individual freedoms of their users.
You gotta be kidding me. It is literally impossible for a user to run software on an iOS device without Apple digitally signing it. "Manage their Apple stuff"? What a bunch of BS. More like create their own digital fiefdom where they own users, determine what they can and can't do and sell access to them to third party developers like they were cattle.
You said it yourself, it's about "controlling what software is run on company owned hardware". We don't own these devices, the companies do. There is no freedom to be had here, we're all playing on their playgrounds.
Not all proprietary software currently insists that you get into a TPM-mediated Dom/sub relationship with its developers. Its currently possible, and might be ethically necessary, not to buy those ones, and instead to buy the other ones.
But it's also probably important to pursue a political avenue as well. The government should absolutely not be using this stuff, and shouldn't be advising citizens to do it to access government services. We could even pass a law requiring purchased hardware and software to meet a fiduciary standard towards its users.
> You gotta be kidding me. It is literally impossible for a user to run software on an iOS device without Apple digitally signing it. "Manage their Apple stuff"? What a bunch of BS. More like create their own digital fiefdom where they own users, determine what they can and can't do and sell access to them to third party developers like they were cattle.
Then don't buy Apple products? I totally agree with you in spirit in a lot of your points and I want more freedoms on my hardware. I just understand why we are in this situation as users. We don't have the market power like businesses do when it comes to hardware and most consumers don't care or don't understand their loss of freedoms.
> You said it yourself, it's about "controlling what software is run on company owned hardware". We don't own these devices, the companies do. There is no freedom to be had here, we're all playing on their playgrounds.
Yep, 100% agree here. There are zero freedoms when you are using company owned devices. They have every right to lock them down to the playground they desire for their users. The hardware market is building what their end users want. It just so happens their biggest paying end users are businesses.
That argument boils down to "if there's something you dislike about society, feel free to live a hermit life in the woods instead". That's not an argument, that's an ultimatum.
In order to receive my salary, pay taxes, fulfill children's schooling, and a myriad of other things there are plenty of proprietary software involved that requries a full hardware attestation to prove that the no part of the software stack is under user control.
It is completely unfounded to call this FUD. It is a fact of modern life. I do condone it because there are many obvious economic and political problems with it already, and could easily see how it could get much worse before it gets better. So far I have been able to isolate these "0wned" devices from the rest of my digital life, but that rest is getting increasinly marginalized.
The “vote with your feet” argument has always been BS. The trend is overwhelmingly towards the introduction of DRM. It may be that there are options now, but soon there won’t be any.
I can see why people would want that, but I can also see why people would want to have an additional certified copy of an important document, artwork, or piece of sports memorabilia, if that’s what the owner of that object wants.
> certified copy of an important document, artwork, or piece of sports memorabilia, if that’s what the owner of that object wants
I don't see how this is relevant. Real world objects can't be exactly duplicated, certificates of authenticity make sense in that context. Data is just bits, any copy will be exact reproductions. There is no need to certify that.
Yes but I don't see how that's in any way comparable to wanting a certified collector's item.
Validating our software as unmodified is really just digital oppression. It's a violation of our dignity as users and human beings. We have all these corporations shipping literal data harvesting and advertisement displaying malware and there's not a thing we can do about it because they have usurped control of our computers.
Who does this "validation" serve? Not us. It serves the "stakeholders". It gives them confidence that we won't be running software that harms their interests.
RMS is micromanaging Emacs in a user-hostile and developer-hostile way. RYF is a disaster that accomplishes nothing. FSF/GNU has a habit of forking or rewriting existing free software to make it "more free" but delivering no actual benefits to users, like gNewSense, Libreboot, Guix, and GnuTLS.
I sympathize with your overall cautionary sentiment but have to push back on it as it pertains to Guix not adding value.
I chose to use Guix SD because I like that the config is in a real (more general purpose) language, which I then proceeded to learn.
From what I understand (someone that knows Nix can chime in) the Guix CLI is also more parsimonious than the Nix CLI, and not multiple differently named tools. I like the simpler interface this provides.
It is however a bummer that there's no socially-approved way to share packages of non-free software on the official channels (what are the unofficial channels I should know about? Just have been searching Github to find).
NixOS has had the new `nix` command for a long while, this bundles up all the functionality under one command just like `apt` or `guix`. It's still marked as experimental and has to be enabled manually, but once done you'll never have to touch any of the old commands ever again. The only problem left is that a lot of the documentation still refers to the old commands.
> It is however a bummer that there's no socially-approved way to share packages of non-free software on the official channels
That's one thing I prefer about NixOS, with Nix Flakes you can just turn any old Git repository into a package. No need to be part of any channels or need for the user to setup anything, you can just build and install straight from the upstream source with a single command line if they provide a `flake.nix` file. This automatically resolves a lot of pointless drama about what should or shouldn't be part of the distribution and makes it trivial to distribute patches and workarounds.
I suggest you update your mental model of what Guix is. If you only see it as a rewrite of Nix you're missing out.
I agree that the knee-jerk reaction of many FSF or GNU-adjacent developers to start a "filter" project that takes upstream and removes parts of it is regrettable.
True. Open source software is waaay bigger than Free software. And free software delivered by the FSF is a drop in the bucket of all software-available-in-source-code-format.
This is not a bad thing, nor a reflection that the FSF is doing it wrong. Indeed it is a sign they are doing it right.
Ultimately all open software exists _because_ of the FSF. They set the marker in the ground, they set the standard the rest if us don't quite live up to. Their role is not to produce all the code, their role is to explain the freedoms well enough so that enough other people believe in some, or all, of those freedoms.
The two main threads of the article are hardware, and emacs.
Depending on how far down the stack you want to go (open microcode in your CPU?) it's generally possible to get hardware open enough for you to do anything you like. Not all hardware is open, sure, but there are enough choices.
Yes there are still closed drivers (ironic given what kicked RMS off in the first place) but careful choices play a role here.
That said, keeping an eye in the hardware, and keeping open hardware in our minds, is an excellent reason for the FSF to exist. Their job is not to win the war, its to make us care about the war at all. We will win it, if we care about it.
Emacs is a very specific example of a program run by a person who has beliefs. He builds that program to conform to those beliefs, not the beliefs of his user base.
In this case he's the printer maker not wanting his printer to work on the new hardware. His goal is not to make "the world's best editor" - his goal us to "make the world's best editor that promotes free software ideals."
Ironically, if you don't like that, you can take his work and built on it however _you_ like. He not only represents the original problem, he presents the ongoing solution.
The Freedoms are explicit. They don't give the user rights over the developer. They give the user rights to add their own work to the equation. Emphasis on work.
The FSF is not fighting the wrong war. They are not fighting at all. They are setting a marker in the ground saying "this is what could be." Our job is to notice, and care.
Open Source's goals are being achieved by Open Source. I think a lot of people need to admit that they don't agree with Free Software's values and goals, and they prefer Open Source because it's free shit that they can use at their job to look good, and why wouldn't you like that?
Free Software is about owning your machine. It's not about being allowed to be installed, or even being easy to install on machines you don't own. It's not about being higher quality. The Free alternative maybe worse, but no one can take it away from you, and it won't spy on you if you don't want it to.
It is not about having free high quality software for everyone to use. That is a lucky consequence of giving people control over their own devices and the things that run on them. Things that enter Free Software never die. They grow, stop growing, then later grow again. They only die if people find something else better, and they always have a chance of rising from the dead. They're public property. Open Source, which is wonderful once you turn it into Free Software, is not immortal. All you have to do is embrace it, extend it, then kill interop, and it is gone.
edit: Open Source starts off as dead code. I can take it, extend it, and obfuscate it tomorrow, and it's mine. If I spend enough on marketing I can make the original look defective. I can make the Open Source version look dangerous and point out its bugs while hiding my own. I can make the vendors only accept the version signed with my key to provide something we decided to call "end-to-end verification."
Doesn't work with GPL software. They have to write their own.
It's not quite that simple. Ubuntu is a fork of Debian, but not Debian. Trying to install Ubuntu packages on Debian or the other way around will result in a complete mess. They are different and incompatible OS. That they share some roots doesn't really help much.
Debian was never flexible enough of an OS to allow all the customization that Ubuntu needed to do to happen in Debian itself, thus it had to be forked. That to me is a failure, not a success. Forks should always be the absolute last resort, yet are common place with distributions, which creates a terrible situation for the user, has features they might want end up being spread across numerous different distributions.
Debian has a whole notion of a "derived distribution", and is very flexible. I'd love examples of what constraints prevent people from making their own rebrand..
Sorry. I didn't read your comment as a criticism of the FSF because they don't live up to their ideals. And you didn't initially provide an organisation that did it better. That's fair enough.
XEmacs was a fork of GNU Emacs, driven by technical and philosophical disagreements with RMS. For a while it was rather popular, but then it died. Its failure is a counterargument to these complaints about RMS' management style–if his decisions are really as bad as some people say, why didn't the fork succeed? And why won't any of the complainers start up a new fork themselves, or revive the moribund XEmacs fork?
You might be thinking of GCC – the current GCC is descended from a fork of GCC (EGCS). RMS agreed to let the forkers take over the official project.
GNU Emacs itself is a fork of Gosling Emacs. The original Emacs was written in TECO, a rather horrendous language. Soon, people started writing Emacs clones in Lisp – Multics Emacs, and some of the Lisp Machine editors. James Gosling wrote the first Emacs for Unix platforms; for an extension language, he invented "Mocklisp", which resembled Lisp on the surface, but lacked its power and generality. GNU Emacs started out as a fork of Gosling Emacs, adding a real Lisp instead of Mocklisp. Gosling made his Emacs freely available under an unclear license, and then sold it to a commercial firm and declared its original free distribution rescinded. To get away from that legal problem, RMS rewrote all the remaining Gosling Emacs code.
The trouble with RYF I think is timing. If it came at a time when the movement was strong and had a large mindshare, then getting certified would get you a market and might be attractive to some vendors.
As it is, the RYF market is so small that no vendor is incentivezed by it unless they are part of the movement already themselves.
But my understanding is that RMS created the free software ideal, formalized as the GPL, that an author freely sharing code with others can in turn require them to freely share any changes and improvements they make to it. If he wasn't the first to think of it, he certainly was the one to codify and popularize it. And it all makes sense to me when viewed through the lens of his frustrating printer driver experience.
Both are not true. People shared software based on the same ideas for many years before RMS.
Not to mention that the whole scientific world has been sharing knowledge while also respecting authorship and providing citations in ways very similar to FOSS for a century.
> People shared software based on the same ideas for many years before RMS.
And did they encode that understanding in an official license and create a foundation to spread and protect those ideas under the banner of "Free Software"? No? Then he ostensibly created that movement. I don't know why people just can't give RMS the credit he's due. Others had similar ideas to Darwin at the time, but he's credited with discovering evolution by natural selection because he was first to create the most comprehensive and authoritative work on it.
> Not to mention that the whole scientific world has been sharing knowledge while also respecting authorship and providing citations in ways very similar to FOSS for a century.
And this has what to do with free software? If RMS came out and said his ideas had been inspired by how open science worked, would that make you feel better? Would that in any way change the fact that RMS was a big influence in changing the prevailing trends seen in software development at the time?
> For one thing it hasn't failed, the free software movement has been an amazing success.
It has failed.
Open software hasn't failed. But thats not the same as free software. Sure there is a lot of open and free software but there is soo much more open software which is not good for the free software movement. Weather that is because of it being open but not free or weather it's open and free but tightly controlled in ways which hurt the free software movement in the bigger picture.
You are measuring success in terms of specific license use. Or authorship. And by those measures its easy to say the FSF has failed.
If however you look at software as a whole, and compare today to say the early 80's, then you might note that the landscape is very different and wonder how that happened.
Today software exists unler a multitude of licenses, written by innumerable authors. A huge fraction of all software is either open, or built on open.
While Open Source and Free Software are different idealogically, they ultimately, broadly, confer the same freedoms on users.
That any of this exits _at all_ is thanks to the FSF - they won the war a long time ago. They are the very definition of success. A success that so many take for granted that we now wonder if they are useful anymore.
>While Open Source and Free Software are different idealogically, they ultimately, broadly, confer the same freedoms on users.
i don't know... i could be way off base but MIT and BSD allow devs to FORK the code and turn it into proprietary code throwing all benefits of "open source" into the wind. "enterprise friendly" is often mixed up but the reality is the end user ends up on the short end of the stick..
Hence the word "broadly". MIT etc allow for Open Source code to be used in proprietary software, true.
Whether this is good or bad, depends on your point of view, and is very newanced.
For example I can use OPENSSL (MIT licensed) in a proprietary system, but I would argue that is better for end users than not. Having a few solid libraries in play is arguably better than a multitude of home-grown closed commercial libraries.
OSI is clearly not FSF. FSF persues a future with no proprietary software. That's a necessary stance for someone to have in the world, it sets a goal post. OSI seeks to make code that has maximal utility by being useful in open and closed environments.
MIT does not prevent companies contributing code, it does not hold back a project in any way, it just makes the code more widely spread and more "utilitarian".
Edit: so it does not eliminate "all" the benefits of Open source, it may remove some of them. Alternatively it may be a net gain if the software is actually used more.
Technically, yes, a company can fork OPENSSL, add features to it, and ship it closed. But why would they? Certainly if the did they remove no utility from openssl for everyone else.
Equally SQLite has a public domain license and that does not seem to have hurt it in any way. There are plenty of contributers etc.
> I can use OPENSSL (MIT licensed) in a proprietary system
You can use LGPL libraries in proprietary software.
> MIT ... makes the code more widely spread and more "utilitarian"
Not for the end users and for developers that want to modify existing software. The "utility" is lost.
> a company can fork OPENSSL, add features to it, and ship it closed. But why would they?
It happens every day. Weak licenses allow freeloading.
> Equally SQLite has a public domain license and that does not seem to have hurt it in any way.
That's not the right metric. The people who are being hurt are developers and users who cannot buy a truly open phone/smartwatch/router/tv/car even if such devices are built on OSS.
yeah, a dev worked for no financial incentive other than the feel good of "open source" while doing MIT code and someone comes in, takes that code, slaps their proprietary tag on it and suddenly the same dev cannot get the benefits of "open source" even when he was doing the work for the greater good.
on the same vein, the same dev works on GPL code and he/she knows the virality of GPL makes it that no one can slap proprietary license on any fork of his work and he/she, if they became the customers of any forks, they CAN expect and demand source, completing the feedback loop.
That same dev _chose_ the license they wanted to use.
Some choose GPL because they value freedom over utility. Others choose say MIT because they value something else.
Naturally all open licenses (free and open source) allow anyone to take that code, compile it, and sell it. This is not a bug, this is a feature.
If the one selling the code makes changes to it, or augments it in some way, and assuming they follow the terms of the license, this is all good. The original author is getting exactly what they hoped for since that's why they chose that license in the first place.
In exactly the same way users make a choice about what software to use. They can choose something proprietary like iOS or something more open like Android. They can choose to use Android coupled to Google services, or not.
I get the goal that the FSF has of making users care enough to only use Free software. That is a noble goal, and we need a organisation that sets that goal.
Equally with hardware they can, and should, champion the cause of completely open hardware.
They are successful not just when all hardware is open, they are successful by making it part of the conversation. It took software 40 odd years or so for Open to become mainstream. It'll take some time for the hardware case to reach some form of critical mass.
All correct except the word "virality". There is no such thing. People can use [A][L]GPL software according to the license or not use it.
Software licenses, and any other work under copyright law, cannot "infect" other works. It's not Covid.
If I draw Mickey Mouse on my hand I might be in breach of Disney's copyright and I might be required to wash it away. It does not mean that my hand magically becomes Disney's property.
And as far as I can tell their methods are subpar for today. This in no way means that they didn't work well in the past. Or didn't do a lot of good things in the past. But times change.
And I'm also not saying they are not useful today anymore, I'm saying their methods don't work well anymore and could lead to them becoming increasingly irrelevant and powerless which would be a loss of all consumers and most developers.
This comment is splitting hairs that don’t even exist. I have never once heard the term “open software”. The closest match is Open Source. The OSI definition for open source is exactly the same as the FSF Free Software.
Another adjacent term is “Source Available” for software that isn’t open source but you can get the source, like Unreal engine.
There is also Open Core for software that has an open source part and a proprietary extension. Like GitLab.
I intentionally didn't use a well defined term as it would miss the point.
There is all kind of somehow "open" software which might be OSI open source or even be GPL licensed but is de-facto not free software.
Like I have seen more then one case where GPL or similar was used to archive "open sourcing the software" while "making sure no on complying with law can benefit relevantly from it". E.g. publish a software under GPL which is strongly dependent all through the stack on some proprietary software which is GPL incompatible but has some pseudo decoupling though some interfaces. The company which wrote the software just uses a different license when they use it. Everyone else would have to spend impractical amounts of time to create adapters to make it actually usable under the GPL license. Sometimes not much less time then rewriting it from scratch. I have seen this pattern quite often. Through more often with AGPL then with GPL. Sometime it did feel that such theoretically but not practically free software likes (A)GPLv3 more the actually free software does like it (but I'm pretty sure this is a bubble).
> The OSI definition for open source is exactly the same as the FSF Free Software.
It is not. If it is, you should explain that to every other expert and lawyer involved in litigating the differences, because they're operating under a delusion.
They are mutually inclusive licenses, because OSI licensed stuff can always be relicensed to GPL (or anything else, really), and because OSI says that GPL is also OSI (although I don't understand why.)
But they're different. You have to share your changes in GPL if you distribute them. That's it. That's the difference.
Not all free software is copyleft, and not all copyleft licenses are GPL compatible. But all free software is open source and vice versa. The four freedoms and the open source definition are intentionally equivalent.
The OSI doesn’t define their own licences. They set out a bunch of rules about what open source means and then list which common licences fit those rules. Their rules are basically the same as the FSF essential freedoms list. Which is why GPL software falls under the OSI definition of open source.
1) The FSF is on the winning side of the war they are fighting, the GPL is nearly everywhere except firmware and phones. Their job is to keep fighting that war. If you want to start a new war, start a new group with different goals.
2) There has never been a time when using free software & hardware didn't end up with a weird system. It isn't like FOSS was a beacon of great engineering through the 2000s. We were lucky if half the hardware on a given computer worked even with non-free drivers.
3) The FSF needs to be a lighthouse on this issues. Compromising will mean the lighthouse is in the wrong spot.
The FOSS movement has the best system for letting people disagree of any organisation - it lets those who care, do. Let the FSF do its thing. If you want compromises, start a Compromised Free Software society or a Partially Free Software Foundation. Maybe even all it the Open Source Initiative, hint hint. Someone needs to be standing up for raw freedom, devil take convenience.
Today two areas matter most 1) Phones, 2) Server/Cloud/PaaS, it's not relevant on Phone and gaps in it's design get abused all the time on the server side.
Additionally a common GPL usage is to prevent usage so that you can sell a proprietary license especially when we speak about variations which try to fix gaps in the GPL, like AGPL. Which is a failure for truley free software, too.
> 2) [..]
Was acceptable in 2000. But in 2020 not well working high maintenance systems are much less accepted even by developers AFIK.
> 3) [..]
But it has become a Lighthouse for how to not try to change things, as it's not an effective approach anymore. Wasn't always that way. It did a lot of good things. It just didn't move with the change of time.
> Someone needs to be standing up for raw freedom, devil take convenience.
Yes but if you bring that into maintenance of relevant software _too_ much then you guarantee that your software will slowly lose it relevance. It might take years, but it's pretty much guaranteed. And at some point you will have lost all influence through software, because all you software lost influence. Means you will have lost beyond a chance for recovery.
I mean look at the change mentioned in the article, I don't expect any relevant amount of the mac users to move away from mac because of this change, I do expect people to move away from Emac because of it, and I do expect people to just have a fork, potentially with increasingly more macOs specific features. Which means it will make the FSF lose influence AFIK.
> I do expect people to move away from Emac because of it, and I do expect people to just have a fork, potentially with increasingly more macOs specific features.
1) Emacs isn't a business, so it doesn't care if it loses market share.
2) Emacs won't have any trouble keeping up with a MacOS fork if it wants to. The software is GPL. It's not like Open Source, it's yours no matter what happens. Apple will be obligated to share everything it does. Emacs will merge it if it likes it.
> Emacs isn't a business, so it doesn't care if it loses market share.
Sure, but "market share" is at least to some degree a proxy for long-term health. My impression -- and I think it's a well-founded one -- is that the most passionate free-software partisans do not like Visual Studio Code, for a variety of reasons ranging from its licensing to "it's Microsoft, dammit." And over the long-term, VS Code is arguably a major threat to all other editors, and perhaps particularly to long-standing editors that are highly extensible but perhaps not the easiest to get comfortably configured.
I love Emacs in principle, but in practice it is way, way, way easier for me to set up and personalize an installation of VS Code. Being that easy to set up isn't necessarily a worthy goal for Emacs, but what the original article is pointing out is, in so many words, that if Emacs' maintainers specifically -- and the FSF more broadly -- consider "fuck you for using a Mac" to be a worthy goal, that's very likely to drive Mac users to non-FSF-approved software. With something as important as your editor, once you have it set up, you're going to want to use it everywhere you can, and like it or not, VS Code's "everywhere you can" includes Linux. Driving people away from any major free software package in the name of purity is something that, at the least, the maintainers should really, really think hard about: there is a generation of developers coming up right now who, even if you convince them to trade in their Mac in a few years for a glorious Linux desktop, may very well keep using Visual Studio Code on Linux because that's what they know. And they know it because Emacs deliberately chose to be frustrating on a Mac and VS deliberately did not.
tl;dr: This sure looks like a case of letting the perfect be the enemy of the good.
There is indeed already (and long-standing) a Mac-specific Emacs port: https://bitbucket.org/mituharu/emacs-mac and I have no doubt that it would add `ns-do-applescript` right back if it were removed from the upstream. I am also very curious about the breakdown of Emacs Mac users: how many are using the Mac port and how many the GNU upstream?
I use Emacs on Mac OS and I can certainly say that I use it for the features -- it is the editor that best suits me -- not because of the license or anything like that. If it were to become insufficiently featureful, I would pick a different editor, not change my entire OS.
> 3) The FSF needs to be a lighthouse on this issues. Compromising will mean the lighthouse is in the wrong spot.
This. Criticizing the FSF that the pure distros have outdated hardware is like criticizing the light house that it is not moving and has no cargo. Those projects are highly valuable, even if they might not deliver value to users.
vrms (virtual Richard M. Stallman) is what your asking for. Go install it, it has been packaged in most distros for decades.
Additionally, crashing into lighthouses with your ship or personal watercraft is considered a bad thing. Lighthouses are usually unreachable by water, they even have bouy perimeters to delineate where the shallows start around them to discourage getting too close/exiting navigable waterways.
> the GPL is nearly everywhere except firmware and phones
GPLv2 is still a tenable license. GPLv2 also has huge flaws around libre intentions, and it is reasonably easy for a company to sidestep the intent of a copyleft license.
GPLv3, which was created to prevent companies from side-stepping the intent of FOSS, is a huge limiting factor to any project - companies simply cannot risk the implications of using it. And thus, projects using it rarely see commercial commits back - a huge source of contribution for any popular library.
As for firmware and phones, well, those are increasingly the majority of devices in existence. And servers are increasingly forgoing shipping userspaces, as they move to a more hardened and lightweight role.
The GPL is only in places where it is defanged (v2). Its use is steadily declining. The amount of use-cases for it is steadily declining. This has been the general trend of the industry and computers.
They are not on the winning side of libre/copyleft, and have not been for over a decade now. It is tragic.
But as long as companies like Apple whine about it (and sometimes outright lie about it), people will continue to believe that it poses a great risk to commercial use.
Edit: Not Google. Google has been fine on GPLv3 for years. It's individual Google employees that have said incorrect things about it, but I can't find a reference for what I'm remembering.
yeah they'd need to innovate to mitigate their risk.
example: you are a car manufacturer. you have a legal responsibility for the street safety of your car, a responsibility for the functional safety of your product.
now a car crashes, badly, killing people, and blame is put onto the internal software of some on board "electronic control unit", ecu.
how can you ensure the software was not tampered with?
lock it down, secure boot?
then you can't have any gpl3 component on there.
so to allow for personal software modifications you'd need to innovate some mechanism which reliably flags unsigned software changes to the ecu. they need to be reliable enough that even after a crash you can still check if the ecu was running vendor software or some modified version. just like you can check if the brakes or the steering was intact or tampered with.
such legal liability is at the heart of rejecting gpl3 for many devices.
ps: for infotainment it's not about human life but about profit, content tax, a different story.
It's perfectly okay for you to put GPLv3 software in ROM that nobody can ever modify and then sell me the hardware. What's not okay is selling me hardware where you can modify the software after the fact, but I can't. And it's also okay for your hardware to detect if I modified the software. It just can't refuse to work if I did.
And this is where the FSF makes the weird trade off that they prefer to not have security updates as that's more "free" than being able to get security updates from the manufacturer. Either way you can't update it, but at least in the scenario the FSF opposes the users are able to be more secure.
this has nothing to do with security updates. any vendor is free to ship security updates however vendors often decide to refuse updates to "tainted" devices.
...and put your device in "dev board mode", which loses all homologation and puts the vehicle into safe space.
and as per the slide deck this may be a one way operation, creating a brick in the driveway.
I know the slide deck. I've asked automotive oems to think about a dev mode which does drive, but puts the whole car into a dev mode and makes this obvious. too expensive. just kick out gpl3 from anything relevant to homologation.
yeah AGPL seems to go father than many people are willing to accept. if i ship a device with copyleft code on it fair enough share the code. But AGPL is my device runs AGP code i have to share it. thats to much for me. if i am not distributing binaries i shouldn't have to share code.
No, running AGPL programs does not require you to share the code. Modifying AGPL programs requires you to offer all users a copy of the source code. You can for example modify the code and offer it in a public github project and after you have made the modification make the github project private.
Don't worry, this is a common misconception. Just running AGPL code doesn't obligate you to do anything
> world where software is always compiled from source code to an executable binary file which exists on the user's own computer
That is ultimately what you need to do if you want the highest level of autonomy (modulo "compilation" being optional). The FSF and the framing of Free Software is an uncompromising judgement, but you're still free to accept compromises.
Do you have a concrete framework that you think would be more worthwhile? Even for any one of the examples you've listed?
My own thinking is augmented with a tower of diminishing Freedom/Trust. My main desktop and laptop run only Free software, period. Their peripherals run proprietary firmware, but they're either isolated from the network (keyboard, mouse, etc) or not fully trusted (encrypted network traffic and disk drives).
I run my biggest use of proprietary code, web applications, in browsers in many different VMs (actually on separate machines). This also isolates their networking to defeat IP-based tracking, since I have to treat them as quasi-hostile black boxes. Similarly when I have to run MSWin apps, virtual machines.
In a third direction, I have infrastructure running Free software on less secure systems (eg VPSs).
In another direction, I have separate machines when I have to fully engage with the surveillance economy, like an Android tablet for banking apps.
Having basic Freedom in my base environment is what gives me the perspective to see each compromise clearly. I understand why I am forced to compromise, what I am giving up, and how I can best protect myself from the fallout of what I've given up.
It's true that I optimized around something other than Freedom, like say ease of use or productivity for a specific task, that I would end up with more Freedom compromises and more of what I optimized for. But I can't see how that's anything other than a Faustian bargain, especially as proprietary software has now combined with ubiquitous network connectivity to undermine Freedom 0.
> The FSF is on the winning side of the war they are fighting, the GPL is nearly everywhere except firmware and phones.
The degree to which the FSF is synonymous with the GPL is exactly how much they've lost. The FSF's fight was never "for the GPL", the GPL was a tool to win the fight for people to be able to control their computers rather than the other way around. It's like saying (actual) war is "for the tanks".
The GPL is everywhere but people are more than ever at the mercy of opaque, inflexible, abusive computational systems. The FSF lost.
GPL is on phones, every Android phone runs Linux kernel and many apps use GPL'd libraries. The problem is that the vendors often don't respect the license, and increasingly are locking down the devices so that even if you do get the source code, it's not much use in terms of applying your own modifications.
Did anyone read the actual email thread? RMS is in there saying stuff like
> In principle, it is good to remove it, but there is no principled reason
why we must remove it, if that means breaking a user-level feature
that does work on non-MacOS systems.
Basically it is one person(Po Lu) pushing for removing it, in part "to encourage users to switch to Linux", but it seems like he is getting a lot of push back from other contributors about why this is actually necessary, and that if he wants to remove it, there should be some more generalized equivalent functionality which would let current mac users port their deprecated usages to some other method.
FWIW, Emacs is a GNU tool at the end of the day. Complaining about upstream changes negatively effecting MacOS is like complaining to Microsoft when your games don't run in WINE. It's the wrong tree to bark up, even if the project is community-led.
He's often quite pragmatic if you really listen to what he says, not just the memes people repeat about him.
He doesn't demand utter purity from others, doesn't expect others to be as extreme as he personally chooses to be. He says that choosing to use Free software even just once is a good thing. That using Free software on windows is preferable to using only proprietary software on windows. That impure distros like Debian are better than Windows, even though they aren't good enough to be FSF-approved. That proprietary software like Steam getting ported to GNU/Linux is good since it will encourage more people to use GNU/Linux.
Is there any reason `ns-do-applescript` couldn't be made as an Emacs package? That way it'd be trivial to remove it from Emacs proper and Mac users could still extend the editor as needed.
My understanding from that thread is that there basically is a package way. The 'ns-do-applescript' is a c function, though. Providing potential speed benefits over the lisp based implementations.
> She says that strict adherence to the FSF’s Respects Your Freedom program means that you’ll be using only obsolete and probably broken hardware.
Old, like from a time when it respected your freedom more?
I don't like the insinuation here, which is that we have lost; if you want the shiny new hardware, just shut up and fork over your freedom.
Just because you put up a white flag and surrendered doesn't mean that those who haven't are fighting the "previous war".
If Stallman is "fighting a war that’s no longer going on", why can't you have your freedoms respected on new hardware?
> If you’re particularly masochistic, here’s the start of the thread on Emacs-Devel.
Here we see completely cringe-inducing, uncivil exchanges such as:
RMS> Is it possible to do this with call-process
or by running a shell command [instead of the do-applescript function]?
H. Melman> I think so, though I have to figure out the right
incantation to get stdout returned as a string. I might be
nice if call-process' DESTINATION arg had an option for this.
A. Schwab> See shell-command-to-string for how to do that.
It's like not being able to look away from a trainwreck, these uncouth, unconstructive GNU diatribes.
> Old, like from a time when it respected your freedom more?
Old and broken as in "You can't update the firmware" because updating the firmware with proprietary software is Bad, but using the proprietary firmware that ships with the product is A-OK.
If absolutely nobody can replace the firmware (without desoldering chips and such), then the playing field is level; the firmware is effectively part of the hardware, like a voltage controller chip on the circuit board.
If the firmware is flashable, then until someone actually flashes it, the situation sort of resembles the above, which is why the original firmware image is acceptable.
Would you prefer that Stallman declare unacceptable any proprietary factory firmware that can be overwritten?
Basically the FSF concerns itself with things that are programmable: who controls that. If only some privileged players can produce images for the device (like the original manufacturer or some parner or other cohor thereof), then the user is disadvantaged: the field is not level.
A device with a nonprogrammable ROM could be be harmful, and that could be due to code. But it is not fixable by programming, just like a harmful toaster.
Let's pretend for a minute that there were enough people following FSF recommendations to affect the market (that's one objective, right?):
A hardware vendor can just move their blobs from the driver download to flash on the hardware, and they went from "not respecting your freedom" to "respecting your freedom" it's a silly place to draw the line.
Then on top of it, an OS that ships updated blobs is anti-Free, but an OS that just runs the out-of-date blob gets the stamp of approval.
I personally wish they'd revise this singular obtuse rule in favor of talking about specific processor domains. A peripheral running proprietary software, whether from ROM, flash, or loaded into RAM by a Free host, has a similar level of non-freedom. But it is ultimately still a peripheral with limited purpose and limited privilege - it does not harm my freedom in the main computing domain.
I'd say the FSF isn't so much "fighting the previous war", but rather new fronts in the war opened up and they've had a lackluster response. But there is of course much money to be made by convincing people to just give up on freedom entirely, to sell them flashy computationally-disenfranchising gadgets and services.
A place where this idea falls down now is many devices do not actually contain a ROM. They only have RAM and get their firmware loaded into them at initialization. Functionally they are little different from a device with a flashable firmware.
This is a weird situation for Linux distros or any FOSS operating system. In order to use this hardware they need to ship closed binary blobs. Even if the license on the blobs allow redistribution shipping non-free software is often against a groups internal rules.
Peripherals requiring firmware from the host are not new. In the consumer PC market, software modems (or "winmodems") appeared in the early-to-mid 1990's.
A device with only RAM that gets proprietary software loaded into it from a storage device on startup is the description of any computer booting a proprietary operating system.
The GNU Public License contains an exception allowing GPLed programs to link to the libraries of an existing installation of a proprietary system.
The situation that is different with firmware blobs is that you have to redistribute them. Even if you get rid of the proprietary OS from the host machine, your free OS has to supply those blobs.
> A device with a nonprogrammable ROM could be be harmful, and that could be due to code. But it is not fixable by programming, just like a harmful toaster.
So why is it better to be harmful and unfixable than harmful and fixable?
I can think of one reason: when something can't be updated, whether that be a ROM or hardware itself, device manufacturers are more likely to keep that thing as simple and well-defined as possible, in order to limit risk. Complex functionality, opinionated functionality, potentially user-hostile functionality: that is left to updatable software.
But that is only a heuristic, not a fundamental moral value. It cannot justify behavior like [1], where an existing hardware component, designed with the idea that its firmware would be updatable, has a downstream hardware manufacturer put that firmware into something hard-to-update for the sole purpose of getting Respects Your Freedom certification. To be fair, the Librem 5 still does not have RYF cerification (who knows why), but I vaguely (perhaps wrongly) recall there being older examples of similar shenanigans.
There is also the example of Linux-libre removing warnings to update insecure microcode. It doesn't make the un-updated microcode any more free! At best it protects against a hypothetical attack where the manufacturer adds a backdoor in an update, but again that seems less like a fundamental moral value, more like a practical question of threat models and security tradeoffs.
> So why is it better to be harmful and unfixable than harmful and fixable?
In terms of the harm, it isn't better; harmful is harmful.
A non-programmable device is more freedom-respecting than one that is only programmable by a vendor. It causes users to have some blackbox whose future behaviors are controlled by third parties.
The situation with the non-programmable device is a vacuous truth. Like why is it possible that "all crows in set X are black" if X is an empty set? Yet not if X is a set containing one white crow?
"Nobody can program this device" implies that users are just as free to program the device as the vendors and their cohorts.
The statement "any firmware that can be flashed onto this device is allowed to be a nice, clean-smelling piece of GNU software" is a logically true statement, if the set of what can be flashed is empty. The statement becomes false when the set of what can be flashed becomes nonempty, and excludes free software.
It's a waste of time to try to fix your definitions in order to eliminate "weird" vacuous truths.
It's like trying to change the definition of what is a black crow so that not all crows are black in an empty murder of crows.
But it's not, because it only affects a small number of devs with a lot of conviction. A number small enough to be mostly irrelevant for any company with relevant market share. The rest of the world does just ignore the FSF of today.
Part of the reason why I pay attention to Marginalia search is the hardware problems it shows. There are now some good papers on SSD based search engines.
I have a lot of thoughts on this and not a lot of time to write them up. The things that really stand out to me are:
- a lot of FSF projects are based around the premise of a multi user *nix system. This is an outdated model of usage. Systems are generally single-user or no-user (and instead part of a herd of application hosts). Human login rarely happens except to debug, and that debugging rarely occurs on the host.
- the FSF has not done a good job of bringing new people in. They do not make a compelling case for their importance. I think this ties into the above - they don't have any compelling work to demonstrate for modern consumer freedom in one of the most important spaces - phones. This also ties into RMS - regardless of how you feel about the man, his presence in the FSF still continues to generate controversy that makes recruiting more difficult.
- The FSF is supposed to address issues about freedom, privacy, etc, but they have completely missed the modern age of application usage models. Web apps, centralized auth, locked down phone OSes, etc. They have very little presence, and a lot of licensing mindshare has gone to non-copyleft FOSS (apache, mit, etc)
- Richard Stallman famously corrects people who say Linux, by saying "GNU/Linux". This would be fine, except the vast majority of consumer electronics using Linux no longer ship with the GNU userspace. This should have been a huge red flag to the FSF that their efforts were being sidestepped entirely.
The FSF does not appear to have a clear vision of the future, or concrete goals, and has lost significant amounts of influence through inaction. I do not know what the way forward looks like for them.
Ultimately, I think the FSF "won" the mindset war, but has lost the overall battle.
This sounds like a level-headed analysis. Granted, I don't totally understand the history nor the practical nuances of all of the FSF's work, I do have a basic grasp of their overall influence and imprint on FOSS and am a happy Emacs user.
It seems to me that all of this talk questioning the need for the foundation in the modern age is good. The ought to be a bevy of splinter groups advocating and developing for the rights of certain users.
> a bevy of splinter groups advocating and developing for the rights of certain users.
I'm curious what you mean by this. Free Software has always been about licensing software indiscriminately to all users. I much prefer that than a bunch of ideologically-driven splinter groups fighting for the rights of "certain users".
I agree with you. But my choice of words was more a reflection of my observation that not all users care about software licensing rights. Between the mid-80s to now, the motivations and characteristics of the average computer user has changed dramatically. Not everyone necessarily shares the same concerns in the realm of software particularly.
This whole arena is new to me, I must confess, so I'm thinking my way through where I stand in the middle of it all out loud to you. I know I'm probably a few weight classes above my own right now.
Computers have been absorbed into the fragmented, chaotic world that we live in. I think that we are entering a period where lots of ideological enclaves will rupture in the software development world. If there ever was a "utopic" period of the FOSS movement, perhaps it is nearing its end.
Yup most of the GNU in GNU/Linux is kinda irrelevant by now. Sure it's still widely used all the time, but only out of convenience/backward compatibility, not because of conviction of it being good or anything.
Believing that people will stop using macOs just because Emacs stops working nicely is probably the most ridiculous thing I have read this week. It shows a complete non-understanding about how most users, including developers, use software. If I would guess it has two possible (and possible overlapping) outcomes:
- a mac fork which will maintain this functionality, and probably adds other mac specific functionality over time, basically making the situation worse
- the user will decide it's time to move away from Emacs. Hypothetical quote: "I mean <modern GUI editor> doesn't look that bad and it's 2022 the area of stateless cloud has replaced dedicated servers, so why care for TUI interfaces anymore." So also a loss of free software.
Which is what is at the core of the recent complains about the FSF I think. It looks like they don't fight a ware for a better future anymore but a war for fanatically enforcing ideology even if it hurts their original goals in the bigger picture.
> I have my own data point in this discussion. Back in May, there was a long thread on Emacs-Devel about removing ns-do-applescript from the Next Step branch. The problem, according to the instigator, was that applescript runs only on macOS which is not a free operating system—although it does represent over 25% of Emacs users—and therefore ns-do-applescript should not be in Emacs.
This isn't the first time that free-software spite has led Emacs developers to disable perfectly good features. Back in 2016, Emacs developers deliberately prevented color emoji from being displayed on the macOS port because Linux (and other free software platforms) didn't support color fonts at the time.
Emacs is a GNU tool, right? Why should they be forced to merge patches that don't relate to the GNU software ecosystem? Adding Applescript compatibility means that contributors who maintain that code require proprietary hardware to fix these issues. The GNU project forbids members from spending donation money on proprietary hardware, even for debugging purposes. You're better off asking why MacOS doesn't have support for EXT4, just because "all the work is already done for them"
If color emojis and Applescript compatibility is such a huge deal, the license explicitly allows you to fork Emacs with these changes merged. Knowing MacOS developers, they'll probably even charge you for it too (which the license graciously permits as well).
> Why should they be forced to merge patches that don't relate to the GNU software ecosystem?
They don't need to. Color emoji worked by default until it was deliberately broken. AppleScript support currently exists and works; what was being proposed is that it be removed simply because it interacts with a feature which is unique to a non-free operating system.
> Adding Applescript compatibility means that contributors who maintain that code require proprietary hardware to fix these issues.
You seem to be working towards the conclusion that Free Software should only be usable within a fully Free environment, which is pretty thoroughly out of step with the expectations and requirements of actual users.
> what was being proposed is that it be removed simply because it interacts with a feature which is unique to a non-free operating system.
Right. Why should the GNU maintainers be responsible for maintaining code that only executes in a proprietary runtime? If you want these features, you should petition your Emacs distributor to package it. Otherwise, this is a silly fight over who's responsible for what. GNU developers are no more responsible for ensuring MacOS compatibility than Apple is responsible for ensuring GNU compliance.
> You seem to be working towards the conclusion that Free Software should only be usable within a fully Free environment
No, but all Free Software should work as-expected in a Free environment. Mac users should be well-familiar with the advantages of writing tight-knit native software.
> Why should the GNU maintainers be responsible for maintaining code that only executes in a proprietary runtime?
It didn't need maintenance. The only reason being put forth for removing it was that it interacted with a feature of a non-free OS.
> GNU developers are no more responsible for ensuring MacOS compatibility...
I'm unsure what you're trying to say here.
Are you trying to draw a line between "GNU developers" and other developers? If so, who are those other developers?
Are you trying to suggest that the developers of GNU Emacs should start ignoring all bugs reported running their software on macOS (or Windows, for that matter) because they aren't responsible for "ensuring compatibility"? If so, who is responsible for that? Is anyone?
> No, but all Free Software should work as-expected in a Free environment.
Non sequitur. What I'm arguing here is that Free Software should not deliberately cripple itself or discard features simply to match the limitations it would have if running under a Free operating system. That sort of thing just makes Free Software look bad; it isn't going to convince anyone that life would be better with a Free operating system.
There already is a fork of Emacs for MacOS, which I and others on this site have been using for many years (me since 2010) because this isn't the first time the Emacs project has neglected or outright sabotaged Emacs on MacOS:
One time (roughly 2012) FSF Emacs was in such a bad state that you couldn't interact with it at all: it would display as small, un-resizable window, but nothing I did would cause anything sensible to appear inside the window.
Whether `ls` is the BSD-derived ls that is shipped with MacOS or GNU ls has effects on how well Dired works, and a similar thing applies for M-x grep and M-x compile, but coreutils has no bearing on whether Emacs can successfully draw a window (frame in Emacs terminology) on the screen that is functional enough to, e.g., echo the user's keystrokes.
I know that because I used to have GNU coreutils installed on my Mac, then I was a Linux user for a little while, and now I am back on a different Mac, but I have yet to bother installing GNU coreutils on this Mac and I notice no difference. Also, I've been using Emacs since 1991.
But yes, I am almost sure I had GNU coreutils installed when I had the very pathological problems with FSF Emacs circa 2012.
Consider what is happening in the Visual Studio Code ecosystem. In this particular case the FSF is on-point on topics about freedom....
"When I see people arguing over open-source vs non-opensource in 2022, I feel like people are completely missing the bigger and more pressing issues at hand, like how the Visual Studio Code ecosystem has been designed..."
I think the article is misrepresenting RMS' view. In fact he does not seem to be against it at all. His point is that so long as the feature works on other systems, it is ok to use this implementation for Mac OS using what's available there. He's only against adding features that are exclusive to closed systems. He seems to prefer a 100% end-to-end "free" implementation, but is not against interfacing with proprietary systems if that is the only option, so long as it replicates a feature that is available in a free system (GNU).
In my view, if you want to provide a 100% "free" alternative you need to pull users in. If a feature works on GNU/Linux, but requires you to connect to a proprietary system on Mac OS (apple script) to implement the same feature, you should do that. When you run enough free software on a closed OS, it lowers the bar for choosing a free OS the next time you buy a computer.
Relevant quotes from the mail thread, that shows that RMS does have a relatively pragmatic view:
> Does anyone object to its removal?
RMS: In principle, it is good to remove it, but there is no principled reason
why we must remove it, if that means breaking a user-level feature
that does work on non-MacOS systems.
> but using it in a subprocess to retrieve only contacts data (which is already possible on free systems) must be more acceptable than Emacs including a C primitive to do the same thing.
RMS: Since retrieving contact data in Emacs is supported on free systems,
adding code to do the same job on MacOS is ok in principle. An
implementation which implements only that particular feature poses no
special problem. Implementing something more general than that might
pose a problem
> Just FTR, AppleScript is used in eudcb-macos-contacts.el, but via osascript executable
RMS: The comments in that file suggest that this is not a general facility
to execute AppleScript programs, but rather a way to get data out of a
MacOS-specific contacts database.
[...]
If so, then under the conditions in the node Non-GNU-Only Features of
the GNU Maintainers Guide, this is a system-specific implementation of
a feature that is supported equally well on the GNU system, so it is
ok.
I read the Emacs thread. Say what you want about the FSF as a whole, or even Emacs policy as a whole. But this is at another level. The proposal was to remove the function ns-do-applescript, which runs an AppleScript script using the C API, because AppleScript is proprietary and thus bad. I can sort of understand that. What I can't understand is the suggested replacement: to run the same AppleScript scripts using a shell command.
And I don't mean something like "well, we won't endorse any use of AppleScript, but 'run shell command' is a general-purpose interface and we can't stop users from using it for AppleScript if they really want to". I could understand that. No, there are uses of AppleScript in Lisp code within the Emacs repo itself (not a separate package repository or something). The thread discussed one such use, which fetches the user's contact list using AppleScript. This was considered completely fine. Fetching the user's contact list, as a high-level feature, is supported on free operating systems, so it's okay to also implement it for non-free operating systems, even if that requires using a proprietary OS-specific API, in this case AppleScript. All fine. But for some reason, it was considered essential to do this using a shell command instead of a C API.
There was even a post suggesting that ns-do-applescript be reimplemented on top of the shell command instead of the C API. In this case, Emacs would still be offering its users a built-in API to run AppleScript scripts, just… in Lisp code instead of C! Because that's so different!
These would fall under that GPL exception. It's the same like, say, GTK+ having to use a Win32 API to be able to do its job of opening a window and painting into it.
I see that Emacs' w32fns.c source file uses ShellExecuteEx. Why not insist that CMD.EXE has to be spawned to run stuff.
The biggest problem with the FSFs religious and dogmatic set of beliefs is that it leads to bizarre outcomes that don't make any sense. Like shipping proprietary firmware is ok as long as you don't change it because then it's not really software and it doesn't count, or whatever. So your software is free if it's proprietary and old but it's suddenly not free if it's proprietary and new, try to explain this to anyone not steeped in free software theology.
It has the same energy as only being able to walk x steps on the Shabbat. It's important to recognize when your doctrine has started to hijack you rather than making and adapting rules to serve your long term goals.
> It has the same energy as only being able to walk x steps on the Shabbat. It's important to recognize when your doctrine has started to hijack you rather than making and adapting rules to serve your long term goals.
Except that religions and political movements are different. Many people following Shabbat restrictions would freely admit that some of the restrictions have no practical value, but are observed purely for their symbolic value, as a way to honor God. That's fine if that's your goal. The FSF too has many practices that could be seen as symbolic, but they're still meant to indirectly promote a concrete objective. Which makes it a problem when they fail to do so.
I think they are right to try to exclude nonfree parts of Linux kernel, and to try to avoid Intel ME and other things like that (but they will need to try better to make improved hardware designs that can be used, which I would think would be difficult for an organization that deals with software), but the certification requirements are a bit too strict in my opinion (while I think there are legitimate reasons to mechanically disable the GPU and WiFi (to save power, avoid unwanted communications, etc), this should not be permanent; it should be possible to re-enable them if their functionality is desired, and free replacement firmware can be used (they could, if desired, make them disabled by default and not include any nonfree firmware with it so that they cannot be used without free firmware, I hope)), and I think they are wrong to remove "ns-do-applescript" (they could, if needed, put it in a separate file which can be omitted if you are not using AppleScript, and there is also possibility of making FOSS implementation of AppleScript in future on other systems possibly, even if for now there might not be).
Don’t forget that all todays browsers being open source is in no small part thanks to Stallman inventing the GPL and the KHTML team adopting it (ok, the LGPl but who’s counting)
Ironic people complaning about FSF just as Debian decides to kneel
I think this kind of reflects the mood of the newer generation "oh ye I am all for free software values, but if it gets inconveniente I can trade them for a 20$ coupon on Starbucks. These people with values are sooo antiquated"
That and whine about Richard Stallman and the FSF
First step create something better, then trade it for the coupon, leave other people projects to be guided as they see fit
Big Tech can afford to wall their gardens and close off their ecosystems. That is because they have billions of users, and profits merely require keeping the users.
But services undergoing adoption need to offer disruptive advantages such as extraordinary user experiences, or being interoperable with other networks to benefit from network effects.
When a small movement (which is what Free Software is becoming sadly) chooses to burn bridges, they are bound to get even smaller.
FSF has been burning bridges for pretty much their entire existence (what is "open source" if not: have you considered not firebombing every bridge you see)
I have to agree. I saw FSF members argue with uutils coreutils [0] developers about having their project licensed under MIT. And for no good reason, they started attacking the project and the people behind it.
I mean if it continues to get better, it will be just a matter of time till we see a cloud provider sepcifc usershell that is closed sourcd and built on top of the rust rewrite.
and naturally its going to have its own features and options, away from the GNU's standard.
then we start seeing every provider doing the same, and out goes the GNU standard, and welcome to proprietary cloud linux.
If there is one area where the FSF has failed it's "user data". They focus only on the software side of things, which given their name and history is understandable, but more and more irrelevant in the modern cloud driven world.
Having a web browser under an Free Software license is nice to have, but everything that matters is stored on the server side, which you have no access or control over.
The FSF, as far as I can tell, never did anything to address that. Even the AGPL, which didn't even originate from the FSF, still just addresses the source code side of things, not the data side of things. I am not even talking here about actual licenses here, but just a philosophical framework about how to deal with data that is on computers that aren't yours.
Somewhat surprising, politics got there first. The GDPR is actual law that tells you what you are and aren't allowed with user data. So we did get a bit of a happy end, but it feels like that would have been a fight in which the FSF could have played a more active role.
The FSF is still stuck in a model where you own and control your computer and data. But that's simply no longer the case, neither with cloud nor with smartphones.
EFF is concerned with actual law and legal defense in court, they don't write licensees. They don't have their equivalent of a GPL. Nobody really does as far as I know.
If you wanted to make the next Youtube or Twitter, but be "Free as in Freedom", what rules would you follow? As far as I can tell, there is nobody dealing with whatever the "Free Software" analog would be in a cloud world where you don't own the computer. And that's kind of sad given how important and dominant that area has gotten over the last decade. GDPR is the best we have, but that only applies in a few selected countries, we don't even have a license version of that that you could slap on your cloud software.
Quite a rehashed discussion I think. I the essence of my question towards the fsf critics camp is: There is a non-gplv3 alternative for every single thing the fsf has made. You can literally live your life as normal without even touching their software. Why is there such a chronic pressure towards making the fsf more pragmatic? what do you wish to get out of such a move? aren't there other organizations that fight for that cause you want better than fsf? honest question.
When I see takes like this, I just want them to look up "Overton Window."
The point (or perhaps best purpose) of the FSF isn't to dominate the world with their vision, it's to remind people of what the endpoints of the whole debate should be.
It is not inconsistent to support FSF/RMS etc. and not follow everything they do.
FSF has succeeded in its mission wildly. So much good free software today. Fully functional Free Software desktop. Over the last 20 years of use, I have watched us enter a phenomenal era of Free Software and Open Source software. This is victory and it is absolutely great.
If it is new to you that RMS is hostile towards proprietary software
and operating systems then you have not been paying much attention.
An open-source project is not going in the direction you like,
the founder of the text editor has opinions you disagree
with and you spend your time pissing on him because of it.
Just fork the code.
Be the change.
It is far more productive.
And if there are a lot of people who feel like you do then great.
That is part of the freedom that Stallmann has given users.
Libreboot -- the FSF-approved fork of Coreboot which the author is indirectly referencing -- only supports a small number of Intel Core2 systems. This microarchitecture is heavily affected by speculative execution vulnerabilities, and rejecting Intel's microcode blobs means that these vulnerabilities cannot be effectively mitigated, even partially.
If you are writing with an expectation that your audience knows those acronyms, there's no reason to stop to explain them.
When personal blog posts like these get picked up by HN there's always someone who wants to die on the hill of "but you're writing on THE PUBLIC INTERNET and thus you can't ASSUME that your posts will only be read by your regular readers," and, I mean, sure, you're technically correct -- but on a practical level, do we really want to archly insist that everyone writing any blog post anywhere must write it as if they were writing for a widespread mainstream audience on the off-chance that it becomes the one post that gets 50,000 views instead of the usual 500?
The FSF and Stallman are pretty mid tbh. The whole thing seem hopelessly outdated. Some of the media on the FSF website is extremely cringe, the weird cartoons in particular. Stallman is problematic and it feels like that tarnishes things. The front has long moved on from writing C and package jannying your distro together.
For one thing it hasn't failed, the free software movement has been an amazing success.
For another, RMS created the free software movement, in an era where most software was proprietary. The GPL, LGPL, and probably many subsequent free software licenses might not exist if not for him. Read his story that led him to this: he was trying to connect a printer to a new machine in the late 1970s or early 1980s, and the maker would not share their proprietary drivers, even though he was willing to port it to the new machine himself, so he reverse engineered it, wrote a new driver himself, and proclaimed his version to be free for all so others wouldn't have to face that same problem in the future, on the condition that they also share any improvements they make to it. Viewing most RMS behavior through the lens of this early formative experience makes it mostly make sense.
Most of the article is really not about the FSF but about emacs. Emacs is Stallman's own project - he started it in the 1980s and remains its mostly-benevolent dictator. He wants it to abide by his own strict principles. If others disagree, they're free to fork it, as has been done over the years. And his free software ideals are the reason they have that freedom.
I just don't see a general argument here to justify the broad title about the FSF in general.