> 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.
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.
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.
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.
> 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.
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.
> 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.
> 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.
> 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.
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.
> 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.
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.
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).
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.
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.
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.
[+] [-] zugi|3 years ago|reply
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.
[+] [-] EarlKing|3 years ago|reply
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.
[+] [-] matheusmoreira|3 years ago|reply
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.
[+] [-] wmf|3 years ago|reply
[+] [-] pjmlp|3 years ago|reply
[+] [-] kevin_thibedeau|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] goodpoint|3 years ago|reply
> 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.
[+] [-] pabs3|3 years ago|reply
It is a pretty hollow success though, just look at what it enabled; adtech, large corporations, proprietary SaaS, locked down consumer devices etc.
[+] [-] dathinab|3 years ago|reply
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.
[+] [-] roenxi|3 years ago|reply
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.
[+] [-] dathinab|3 years ago|reply
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.
[+] [-] est31|3 years ago|reply
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.
[+] [-] parker_mountain|3 years ago|reply
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.
[+] [-] TylerE|3 years ago|reply
FSF is stuck in a world where everyone still writes everything in C.
[+] [-] morelisp|3 years ago|reply
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.
[+] [-] honkthegoose|3 years ago|reply
[+] [-] googlryas|3 years ago|reply
> 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.
[+] [-] bombcar|3 years ago|reply
[+] [-] AceJohnny2|3 years ago|reply
[+] [-] chungy|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] kazinator|3 years ago|reply
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.
[+] [-] dathinab|3 years ago|reply
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.
[+] [-] aidenn0|3 years ago|reply
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.
[+] [-] yuhong|3 years ago|reply
[+] [-] parker_mountain|3 years ago|reply
- 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.
[+] [-] the-printer|3 years ago|reply
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.
[+] [-] dathinab|3 years ago|reply
[+] [-] dathinab|3 years ago|reply
- 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.
[+] [-] duskwuff|3 years ago|reply
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.
http://xahlee.info/emacs/misc/emacs_macos_emoji.html
[+] [-] smoldesu|3 years ago|reply
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).
[+] [-] falcolas|3 years ago|reply
Accepting the loss isn’t going to help us move forward, just backward.
[+] [-] datadata|3 years ago|reply
[+] [-] danielheath|3 years ago|reply
[+] [-] ghuntley|3 years ago|reply
"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..."
https://ghuntley.com/fracture
[+] [-] matheusmoreira|3 years ago|reply
This about sums up everything these corporations do. Why do people accept this? Is this really going to be our future?
[+] [-] anon25453|3 years ago|reply
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.
[+] [-] comex|3 years ago|reply
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!
[+] [-] kazinator|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Barrin92|3 years ago|reply
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.
[+] [-] comex|3 years ago|reply
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.
[+] [-] zzo38computer|3 years ago|reply
[+] [-] skrebbel|3 years ago|reply
[+] [-] guilhas|3 years ago|reply
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
[+] [-] danuker|3 years ago|reply
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.
[+] [-] faisal_ksa|3 years ago|reply
I was a big fan of FSF until that point.
[0] https://github.com/uutils/coreutils
[+] [-] grumbel|3 years ago|reply
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.