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 Google and Apple whine about it (and sometimes outright lie about it), people will continue to believe that it poses a great risk to commercial use.
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.
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 whose operating environment is another piece of software which may have an incompatible license, like browser extensions or game mods.
* Software which is distributed in a form similar, but not identical, to its source code, like minified Javascript.
* Software which is written and distributed in a source or source-equivalent format, like Python applications.
* Software which runs on embedded hardware which is not trivially modifiable.
* 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.
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.
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.