Is the FSF Fighting the Previous War?
irreal.org
irreal.org
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.
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.
XEmacs failed, because eventually IDEs became a thing on UNIX platforms and that is where we went, to the toolset we were missing, not Emacs.
The argument I and other people are making is that the FSF's goals are being achieved but not by the FSF.
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.
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.
Ubuntu is 96% built on unmodified Debian packages. Ubuntu's successes are Debian's successes.
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.
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).
They've been working towards this with the (introduced[0] in v2 few years ago) experimental `nix` command that combines the various `nix-*` commands.
[0]: https://nixos.org/manual/nix/stable/release-notes/rl-2.0.htm...
> It is however a bummer that there's no socially-approved way to share packages of non-free software on the official channels
There is https://gitlab.com/nonguix/nonguix
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 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.
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.
"More freedom" is a benefit. You're free to judge whether it's a benefit specifically to you, but you can't judge that for others.
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.
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.
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.
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).
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.
Hint: they are.
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..
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Viral_license
either you are off base or you need to learn stuff
Not to mention https://en.wikipedia.org/wiki/Talk:Viral_license#False/Misle...
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.
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.
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.
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.
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.
Asus talks about how to disable it:
https://www.asus.com/support/FAQ/1047459/
As do many other manufacturers, its a thing.
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.
Go look up what kind of cool things you can do with a TPM. For example https://systemd.io/CREDENTIALS/ is pretty cool. So is using it to make your life easier with LUKS encrypted volumes. https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a...
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.
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.
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.
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.
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.
What this thread is discussing is modified copies validating as unmodified copies.
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.
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.
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?
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.
We already live in this future. Apple has 25% of the phone market worldwide.
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.
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.
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.
See this explainer by the FSF: https://www.gnu.org/philosophy/categories.html
- 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.
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.
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,
<do other things that have the same effect>
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.
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.)
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.)
I think that sums up the root of the entire debate. :)
> obligated
....so, basically, Free as in Slavery?
Seriously, I'm not going to stand by and watch GNU partisans try to rewrite history.
> GPL, LGPL ... might not exist if not for him
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.
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?
It is a pretty hollow success though, just look at what it enabled; adtech, large corporations, proprietary SaaS, locked down consumer devices etc.
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.
FSF is stuck in a world where everyone still writes everything in C.
And in a world where software is always compiled from source code to an executable binary file which is stored and run by the user's own computer.
There are a number of situations in modern software development which the GPL handles spectacularly badly, including:
* Software which usually runs on other people's computers, like cloud hosted services.
* Software which is exclusively delivered and executed over the Internet, like Javascript-heavy web applications.
* Software which is distributed in a form similar, but not identical, to its source code, like minified Javascript.
* Software which is written, distributed, and used in a source or source-equivalent format, like Python applications or shell scripts.
* Software which runs on embedded hardware which is not trivially modifiable.
* Software whose operating environment is another piece of software which may have an incompatible license, like browser extensions or game mods.
* Software which is not precisely executable, like web site templates or C++ template libraries.
* Software which isn't precisely software at all, like FPGA hardware designs.
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.
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.
In general, no you don't. You only do if you let other users interact with the AGPL'd program over the network.
Don't worry, this is a common misconception. Just running AGPL code doesn't obligate you to do anything
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.
> at least in the scenario the FSF opposes the users are able to be more secure
That's quite questionable. What if someone steals the manufacturer keys? Then people with unmodifyable devices would be more secure.
But anyway that's besides the point since FSF is against taking the freedom away from the users under the veil of "security" anyway.
only. the other scenario, "vendor can update I can't" is relevant.
and that detection mechanism is called "secure boot".
Of course they do. One example is pressed DVDs.
https://events19.linuxfoundation.org/wp-content/uploads/2017...
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.
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...
In addition, even the GPLv3 allows what Tivo did (break proprietary software when GPL software is updated:
https://events19.linuxfoundation.org/wp-content/uploads/2017...
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.
Google does not whine about GPLv3. Google ships GPLv3 licensed code. Google doesn't allow AGPL code, but that is a different license.
Apple, however, will not ship GPLv3 code.
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.
To continue with the metaphor: if the lighthouse appears unreachable, or advertising something people don't want, it will be ignored.
Perhaps they can improve said "advertising" by grading HW and distros instead, and indicating for each system how the grade could be improved.
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.
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.
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.
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.
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.
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.
> 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.
Hence XEmacs. And hence why I run the Mituharu-branch [1] Emacs rather than upstream on Mac.
[1] https://bitbucket.org/mituharu/emacs-mac/src/master/ aka emacs-mac-app in MacPorts or railwaycat/emacsmacport in Homebrew
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.
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 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.
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.
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.
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.
Indeed, weird situation as you note.
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 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.
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.
[1] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
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.
No.
- Old like people took years to create alternative drivers and reverse engineer APIs.
- Old like hardware which was phased out due to security flaws which also happened to allow free firmware.
- Old like the producer doesn't care about it anymore and therefor some employees feel safe to leak some details needed for creating free drivers.
- 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.
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.
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".
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.
- 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.
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.
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).
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.
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.
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:
https://github.com/railwaycat/homebrew-emacsmacport
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.
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.
You are distorting the argument
Accepting the loss isn’t going to help us move forward, just backward.
"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..."
This about sums up everything these corporations do. Why do people accept this? Is this really going to be our future?
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.
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!
So the part I don't understand is why the GPL exception wouldn't apply, if it is a system library that is going to be there on any Apple box.
Emacs integrates a lot of various Mac-specific API's.
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/nsfns.m
... and other "ns" files.
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.
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 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.
I was a big fan of FSF until that point.
then we start seeing every provider doing the same, and out goes the GNU standard, and welcome to proprietary cloud linux.
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.
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.
As for you telling me what software I can run on my server, that sounds like the opposite of freedom.
You can tell me what I can do with your data, and that's entirely in the EFF's wheelhouse of advocacy.
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.
Technology as we know it today only exists because of Free Software (period)
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.
|-GNU GPL...apache/MIT...proprietary-|
I submit that motives for doing code vary from:
* the social concerns of the GPL
* to the libertarian view of apache/MIT
* to the darwinian capitalist vistas of proprietary
Further, the optimal overall result is obtained by respecting everyone's rights and using the legal system where necessary to resolve frictions.
Messy? Inefficient? Confusing? Occasionally riddled by contradiction?
Welcome to people.
if they arent there, they will form again bcos lack of freedom will make ya thirsty.
RMS - Richard M Stallman
OSS - Open-source software
Very poor writing to launch into accronyms with no explaination.
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?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ab...