Weekly Edition
Return to the Distributions page
| |||||||||||||
Searching for common ground between Debian and FSFOn July 3, Debian Project leader Stefano Zacchiroli announced the launch of a new effort to clarify why Debian is not endorsed on the Free Software Foundation's (FSF's) free distribution list, and perhaps even make changes to Debian so that it met the FSF's requirements. That effort has spawned a mailing list where the two projects are talking about the differences in their goals and principles, but a plan of action is yet to come. Zacchiroli cited three reasons for pursuing inclusion on the FSF distribution list. First, Debian's absence on the list has historically led to a duplication of effort, with derivative distributions created "that are essentially Debian, modulo the changes necessary to be listed." Second, many in the Debian community choose the distribution because of its rigorous stance on software freedom, and there is likely to be a large overlap between them and FSF supporters. Third, Debian's goals in software freedom are essentially self-reviewed, so measuring the distribution against an external standard could reveal valuable information about Debian's successes or failures and its general perception by outsiders. Conflicting legaleseAlthough one of the possible outcomes of the effort is getting Debian included on the FSF distribution list, Zacchiroli stated at the outset that documenting Debian's position on why it does not meet the criteria listed by the FSF might also be an acceptable result. He proposes "to work with the FSF to review the issues they claim apply to Debian" in bug-triage fashion. "Some of the bugs will be valid, some of them will be not, and on some there will be disagreement between submitter and 'maintainer'." Should Debian and FSF be unable to resolve the "bug validity" of the outstanding issues that keep Debian off of the FSF distribution list, Zacchiroli said, "at that point we will have obtained a list of blockers, that could than be used as documentation for Debian users who wonder why Debian and FSF disagree on the Free-ness of Debian." Accepting the possibility that the two projects might not reach common ground is important, because the biggest obstacle to Debian's inclusion on the list is the FSF's requirement that distributions "not steer users towards obtaining any nonfree information for practical use, or encourage them to do so," and the projects are definitely divided on how that guideline applies. To the FSF, not only must the distribution not have any repositories containing non-free software, but it must not refer to third-party repositories that are not committed exclusively to free software "even if they only have free software today," and individual applications cannot suggest installing non-free plugins or documentation. The latter requirement, for example, disqualifies Mozilla Firefox, because its official add-ons site contains proprietary extensions and plugins — and it disqualifies Iceweasel, Debian's rebranded version of Firefox. Therein lies the tricky part. Iceweasel is a repackaged version of Firefox built by Debian to cope with incompatibilities between Mozilla's trademark guidelines and the Debian Free Software Guidelines (DFSG). Although Iceweasel complies with the DFSG, it does not meet FSF's distribution guidelines. Conversely, many FSF documents are under the GNU Free Documentation License (GFDL), which does not meet DFSG requirements. Debian's explanation of GFDL's incompatibility notes "that this does not imply any hostility towards the Free Software Foundation" or that the project dissuades others from using GFDL. Nitty grittyDebian intentionally separates non-free software into a separate repository (named nonfree) which it states is not part of the Debian system, but in its explanation of Debian's status, FSF argues that this is not enough — the nonfree repository is hosted on Debian project servers, and there are references to it in the online documentation. A related problem is the contrib repository, which includes some packages that FSF claims "exist to load separately distributed proprietary programs." Finally, although Debian no longer includes any binary blob kernel modules, FSF points out that the installer still recommends some of them for specific hardware. Assessing the content of those repositories is a natural first step. Practically speaking, there is no list of exactly which packages in nonfree or contrib violate the FSF guidelines. Paul Wise pointed out an older project to document Debian's nonfree packages and said that "recent policy changes added the requirement for the debian/copyright file to document why something is non-free." The information in the non-free tracking system is quite old (early 2008); updating it could take considerable time, but Zacchiroli suggested reviving it — turning each tracking system entry into a bug report against the relevant package, tagging the reports, and linking each report to the appropriate policy that clarifies why the package is non-free. Early on in the list discussion, Thorsten Alteholz proposed rolling a "Debian" distribution that intentionally follows the FSF guidelines, and separating it from a "Debian Extended" distribution that includes access to the non-free and contrib repositories. That idea did not gain significant traction. Bryan Quigley suggested looking for packages in nonfree that might be encouraged to relicense, and compiled a list of "low-hanging fruit" including several varieties of non-software package: firmware packages, fonts, documentation, data, and so forth. Daniel Kahn Gillmor liked the concept, but said that most projects have reasons for choosing the licenses they use, so "Convincing the upstream of every package in non-free to change their license seems implausible, so that means that some packages would likely remain." But Henry Jensen contended that fixing up nonfree and contrib would not be enough on its own, because of the "steer users towards nonfree" requirement. "So, every explicit mentioning of non-free software could be interpreted as recommendation." He posted a list of the Debian components he believed needed fixing. In addition to Iceweasel and other programs that use plugins, he listed the Linux kernel (because it logs the names of proprietary firmware files it expects to see but finds missing), the official Debian web and wiki sites (because they mention non-free software), and the official forums and mailing lists (which lack a moderation system to discourage users from asking about or discussing non-free software). He cited references for the kernel and forum issues, including a 2010 message in which Richard Stallman said a distribution's official forums should not include advice on how to run non-free programs. The discussion sparked (perhaps predictably) a brief flurry of debate over the merits of FSF's guidelines, and specifically whether or not they go too far when they ban discussion of non-free software. As is typical of debates over free software ideals, there was a wide spectrum of opinion. But personal opinions are not the issue. As Mason Loring Bliss put it, "we're not here to discuss my standards. :P The FSF has, effectively, drawn a line in the sand, and it's their line to draw." Ian Jackson encouraged participants to refrain from dogmatic arguments, and for everyone to treat each other as allies. The long road aheadBut Jackson's appeal for respectful disagreement also conceded that full agreement between the projects might be unattainable. "If you can't convince your ally on some point then the right thing to do is not to browbeat them harder. The right thing to do is to agree to differ, and move onto a topic where cooperation is possible." So far, there appears to be little progress on the underlying issue of whether the nonfree and contrib repositories are suitably disconnected from the Debian distribution. That issue is the most fundamental, and it is what led to the brief philosophical debate. Documenting the contents of the repositories may be helpful, but ultimately it is their availability that FSF finds objectionable. Jason Self asked if moving the nonfree and contrib repositories to a different virtual host would satisfy the requirements, but so far there has been no reply. Exactly where FSF decides to draws its lines ultimately involves some judgment calls by humans, of course (I am reminded of Matthew Garrett's 2008 list of things in your computer that you do not have the source code for, including a great many firmware and microcontroller examples), but it draws those lines clearly. If the presence of any information about non-free software on any Debian site or service disqualifies Debian from meeting FSF's distribution guidelines, then it is hard to see how the two projects will find middle ground. Which is not to say that there is no hope — Michael Gilbert pointed to an FSF statement about where Stallman presents a more nuanced approach to balancing the pros and cons of non-free games than he is often given credit for. But these are clearly two projects with firm beliefs about their own ideals, and well-established rationales to back them up. Compromise can hardly be simple. (Log in to post comments)
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 0:57 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]
... appears to be that if a device contains firmware but it cannot be updated (say, it's in ROM, or the needed jumpers have been disconnected) it can be considered hardware and thus OK for free software purists. The problem with that position is that it may be possible, either by reverse engineering or the release of specs, to eventually write free software to run on these auxiliary processors, in which case a programmable device should be considered more "free" than a locked-down device, not less.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 5:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I think FSF's position is one of equality. If the hardware manufacturer has made it programmable, that freedom should be there for the users as well and source shouldn't be held a secret within the firmware. If it is not programmable, then the rights are the same for both parties. It is true that if it is firmware, then you have some chance of making it free and thus more flexible and cost effective but I don't think FSF's position is inherently self conflicting.
I am not sure I agree with it though. Where to draw to the line isn't as clear cut as it may seem at first glance and FSF's positions are not necessarily the community consensus. Firmware isn't the only source of such debates but apparently the most visible but GNU FDL invariant sections is another. One could consider font sources, game data and so on. FSF seems to have a less stricter view in these instances than I would have expected.
https://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF
https://www.gnu.org/philosophy/nonfree-games.html
Debian's efforts should be encouraged however since it helps with peer review of the standards involved and can bring up out the differences in a more public way. Transparency on disagreements is certainly helpful.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 8:09 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if you were talking about devices that could be updated remotely without any user intervention, then there could be a valid argument about the 'equality' of the owner with the device manufacturer.
But since almost no devices work that way, and if they have flash, frequently require specific user actions to update the system (booting into special modes for example), usually along with big nasty warnings about how dangerous the upgrade is. It seems very clear that the power to upgrade or not is already in the hands of the owner of the device. nobody forces them to upgrade.
the few devices that do have remote update processes (Sony game consoles for example) make no pretension of being free or open in any way and are not harmed by the FSF position
the fact that the FSF has actively encouraged firmware to be burned into ROM so that it could not be modified by anyone as an "improvement" over the exact same binary blob being loaded by the otherwise free OS is a clear indication of how wrongheaded they are. They would rather have a device that the owner cannot control that runs a binary blob instead of a device differing only in that the binary blob gets loaded to the device by the free OS instead of by additional hardware.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 11:54 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I think you didn't understand my point about having equal rights. I was not talking about remote updates or whatever of that nature but referring to the fact that hardware manufacturer have the source to the firmware and if it is non-free, the hardware manufacturer has all the control and you don't get to fix issues with it or even know what has really changed in-order to decide whether you want the update or not and yes, it is a practical problem in some cases. For instance, OLPC needed to tweak it for better power management and Fedora sometimes has to push updates without any real changelog.
https://lwn.net/Articles/459240/
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 17:58 UTC (Thu) by bosyber (subscriber, #84963) [Link]
Maybe a more apt way to describe it is "equal (lack of) rights".
That makes clear exactly what the problem with it is. It is an all or nothing clause: it doesn't promote openness so much as it requires the hardware reseller to choose - either go open fully, go or the easier route of no rights for anyone.
That second option is technically inferior, often worse for security and usability; but in companies that lack understanding and/or practice of open source, much easier to understand and thus sell, and thus it is the choice to make for many such companies. And they are still a big factor, or even the majority.
In theory both the software blob and the hardware ROM can be reverse-engineered and updated with free components, given enough effort. But this is much cheaper and easier to do with a software update than with hardware, which makes the 2nd option in practice worse for the FOSS community, certainly in the short run.
Theoretically then, this view is consistent, true, but in practice it doesn't clearly promote openness, nor a good path towards getting there, which is what ideally would be provided, as that would practically help improve the landscape for open software and hardware.
It is therefore not surprising that dlang, and many others, view it as going in the wrong direction, I'd think.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 18:10 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Actually, the hardware manufacturer has *more* rights if they decide to keep the firmware proprietary. They can fix any bugs in the firmware and you don't have that right. There are three choices
* No separate firmware at all
A) and B) is acceptable for FSF but C) is not. Again, I am not arguing that FSF is absolutely right but it is a very clear position and is logically consistent with the rest of their ideals which is always in favor of end user rights.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 18:59 UTC (Thu) by bosyber (subscriber, #84963) [Link]
And since C) is not acceptable, that leaves an all-or-nothing choice where in both cases they have the same rights to existing products: both can update, or neither can update, yes.
But, as I said, it might be consistent, but it also is arguably of very limited use in today’s world.
Since in many countries reverse-engineering for interacting is allowed, you might well have the right to replace the hardware as much as the software. Both are limited by legal barriers to uncertified running and warranty. If a software update blocks your phone's access to the network, so will a hardware tweak, after all.
Replacing software is in most cases a much more feasible strategy, and thus allowing for it gives much better hope of opening a closed product after sale.
Of course B) would be the preferred option, but it isn't the current majority choice, so blocking C) leaves A) as the practically poorer short-term default for much hardware.
I understand that the FSF isn't always concerned with practicality, but others may be; I repeat, it isn't surprising if those feel this is the wrong way to progress.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 20:56 UTC (Thu) by DavidS (subscriber, #84675) [Link] And since C) is not acceptable, that leaves an all-or-nothing choice where in both cases they have the same rights to existing products: both can update, or neither can update, yes. But, as I said, it might be consistent, but it also is arguably of very limited use in today’s world.Couldn't that be the point the FSF's trying to make? "A firmware that can only be updated at the manufacturer's mercy is worse - for the user - than a firmware that can't be updated at all?" At least one could send the TV back as defect, instead of having to wait for the next "OTA". Which won't fix it anyways.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 21:31 UTC (Thu) by bosyber (subscriber, #84963) [Link]
Yes, I do expect it is. And I see value in that message. Keeping that point in mind is very important as an outlook of where we want to go.
But it seems also clear that people might not like it (and thus work against it instead of heeding it) and/or think that a different approach will work better as a way to actually get there; especially as a solution until we eventually, hopefully, end up there.
The FSF answer to Matthew Garrett's list ... Posted Jul 12, 2012 22:27 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the issue is that the manufacturer usually doesn't have the power to update the firmware without the user doing something to approve it.
If you are talking about something like a TV where everything is fed from the manufacturer over the air, you really aren't talking 'firmware' you are talking about the complete OS of your system.
the idea that a Wifi card is somehow 'better' if you would have to send it back to the vendor to upgrade the firmware rather than moving to a new linux kernel driver version that uploads a different binary blob to the wifi card is where people get upset.
The FSF answer to Matthew Garrett's list ... Posted Jul 16, 2012 9:17 UTC (Mon) by ballombe (subscriber, #9523) [Link]
> the fact that the FSF has actively encouraged firmware to be burned into ROM so that it could not be modified by anyone as an "improvement" over the exact same binary blob being loaded by the otherwise free OS is a clear indication of how wrongheaded they are.
It is not the FSF which is wrong-headed, but laws and regulations.
In particular you can disclaim warranty on software but not on hardware, you can use software license to limit usage and resell in ways which are not possible with hardware.
The FSF answer to Matthew Garrett's list ... Posted Jul 16, 2012 16:55 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
This is a new argument as far as I am concerned.
I've never heard of any differences is liability (or even claimed liability limits) for a NIC card depending on if the firmware is in ROM, in Flash, or loaded by the OS.
can you point me to any device that has made such claims?
Searching for common ground between Debian and FSF Posted Jul 12, 2012 10:17 UTC (Thu) by nestal (guest, #66970) [Link]
There is sure a lot of work to do. Is it really worth spending the resources? It looks like they are only doing it because of ideology.
Searching for common ground between Debian and FSF Posted Jul 12, 2012 13:12 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
> It looks like they are only doing it because of ideology.
You say that like it's a bad thing. Ideology is important to some of us.
> Is it really worth spending the resources?
Since the outcome is likely to be the same state we have now, probably not. I don't see a way out of it unless the "alternate distribution" idea takes off. A Debian derivative that's officially maintained by the Debian project which meets all of the FSF requirements seems possible.
Searching for common ground between Debian and FSF Posted Jul 12, 2012 15:41 UTC (Thu) by panzerboy (subscriber, #16142) [Link]
> Since the outcome is likely to be the same state we have now, probably not. I don't see a way out of it unless the "alternate distribution" idea takes off. A Debian derivative that's officially maintained by the Debian project which meets all of the FSF requirements seems possible.
The problem with this approach is that it needs additional resources. Which would have to then stop whatever they're doing now. So it's a trade off.
Searching for common ground between Debian and FSF Posted Jul 12, 2012 16:40 UTC (Thu) by nickbp (subscriber, #63605) [Link]
In theory, a project of volunteers will have its resources directed to whatever those volunteers find interesting. If policy work is what they find interesting, the project likely doesn't really have much say in that interest.
non-free mailinglists mandated by the FSF? Posted Jul 12, 2012 11:08 UTC (Thu) by Seegras (subscriber, #20463) [Link]
This gets quite absurd.
Debian should take away the freedom of its users and developers to talk about non-free software in order to be endorsed by the FSF?
non-free mailinglists mandated by the FSF? Posted Jul 12, 2012 14:35 UTC (Thu) by Jonno (subscriber, #49613) [Link]
Not necessary, if I understand the FSF guidlines correctly, on that point all Debian has to do is to *discurage* users and developers from doing so *within the Debian project*.
The discouragement could be as simple as a template response to any support questions on Debian mailing lists and forums, telling them that non-free software is not part of Debian and asking them to go somewhere else for help (though notably not telling them where they can get such help).
Both users and developers would still be free to discuss the use of non-free software, as long as they don't do so under the umbrella of the Debian project.
non-free mailinglists mandated by the FSF? Posted Jul 12, 2012 16:44 UTC (Thu) by nickbp (subscriber, #63605) [Link]
I would find this sort of finger wagging pretty obnoxious if I were, say, discussing how to get a game functional under wine with other Debian users. I'd probably just switch to a more accommodating distribution.
non-free mailinglists mandated by the FSF? Posted Jul 12, 2012 16:58 UTC (Thu) by nickbp (subscriber, #63605) [Link]
Or, now that I think about it, trying to figure out why my ATI card had such awful performance after switching to the free radeon drivers from the decidedly less-free fglrx, a situation which I ran into on squeeze just a few weeks ago when AMD dropped support for my HD4850.
The answer, if a developer were permitted to provide it, would be to install linux-firmware-nonfree, which includes a binary blob necessary for radeon to support 3d acceleration on my card. I only discovered this solution myself when skimming Xorg.0.log; would the log entry mentioning the lack of a binary blob be removed as well?
Before discovering the correct solution, I was considering simply buying a new nvidia card, which would have brought me completely back into the fold of proprietary video drivers, and left me with the (incorrect) assumption that radeon was unsuitable for regular use.
non-free mailinglists mandated by the FSF? Posted Jul 16, 2012 17:45 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]
I'm a member of the Debian kernel team, partly responsible both for removing firmware from the kernel package, packaging it separately, and adding some of the warning messages about drivers loaded but missing firmware. My aim has been to comply with all parts of the Debian Social Contract, keeping non-free software out of 'main' but not standing of the way of users who want to use it. (Personally, I have firmware-iwlwifi installed on my laptop and firmware-linux-nonfree installed on a desktop with a Radeon GPU.)
I'm not sure we've got the conditions for warning messages quite right: some users (such as you) evidently don't see any messages, and some see them several times even though the firmware isn't needed for their specific hardware.
There is also an ongoing issue with radeon where the upstream developers try to make it functional without the non-free firmware but this doesn't seem to work with many of the newer chips (it's not just slow but may fail to generate a display at all).
non-free mailinglists mandated by the FSF? Posted Jul 12, 2012 19:42 UTC (Thu) by Jonno (subscriber, #49613) [Link]
I'm not saying it would be perfect, just saying it isn't quite as bleak as Seegras suggested.
Though in that particular case, I'd say you would be better off taking your problems to WineHQ anyway, as any problem with a windows application in Wine is likely to be 1) independent of distribution, and 2) not really related to the wine packages themselves.
As for your second use-case of the radeon firmware blobs, that would really only work if there was a separate community for the non-free and contrib components (see my other comment about that), in which case getting a canned response about software freedom would be a big hint for non-purists to go looking there instead (while purists could blame the hw and go buy Intel instead).
non-free mailinglists mandated by the FSF? Posted Jul 12, 2012 19:47 UTC (Thu) by nickbp (subscriber, #63605) [Link]
Yes, and in my case, I would go looking for another distribution.
non-free mailinglists mandated by the FSF? Posted Jul 17, 2012 12:08 UTC (Tue) by KotH (subscriber, #4660) [Link]
> Debian should take away the freedom of its users and developers to talk about non-free software in order to be endorsed by the FSF?
Yes, it's the FSF form of censorship. And i'm quite surprised that people do not outright refuse it.
Searching for common ground between Debian and FSF Posted Jul 12, 2012 15:06 UTC (Thu) by Jonno (subscriber, #49613) [Link]
While there are more issues, to my mind the largest sticking point is the management of the non-free and contrib components. While the Debian Social Contract explicitly exclude them from the Debian system, they are still maintained by the Debian *project* for use *with* the Debian system, which according to the FSF guidelines is enough to be considered "encouraging" their use.
I can not see Debian being approved by FSF without externalizing them to a separate project, with a separate community and brand (though possibly still hosted on Debian maintained infrastructure).
One solution would be to offer main at "deb http://ftp.XX.debian.org/debian stable main", but offer non-free and contrib at "deb http://ftp.XX.nonfreedebs.org/nonfreedebs stable non-free contrib".
My imaginary "nonfreedebs.org" would have their own website, wiki, forum and mailing lists, all separate from debian.org. While nonfreedebs.org would make plenty of references to debian.org, debian.org would never reference nonfreedebs.org. Also, while the Debian installation media would not include any non-free software, or in any way mention nonfreedebs.org, nonfreedebs.org would offer re-branded installation media that does.
The fact that both debian.org and nonfreedebs.org would be hosted on the same physical computers, and that most (if not all) nonfreedebs.org developers would also be Debian Developers, should make no difference to FSF endorsement of Debian.
For this to become a reality, section 5 of the Debian Social Contract would have to be changed, which would require a General Resolution.
While the exact wording of such a resolution would have to be worked out by people smarter than me, and FSF should be consulted to verify that it indeed would be enough to satisfy them, the following should be a decent discussion starter:
5. Works that do not meet our free software standards
Searching for common ground between Debian and FSF Posted Jul 12, 2012 15:44 UTC (Thu) by panzerboy (subscriber, #16142) [Link]
> 5. Works that do not meet our free software standards
We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. While such packages will not be offered as part of the Debian system, they can be configured for use with Debian. To support these users, we are prepared to provide infrastructure (such as web hosting, bug tracking system and mailing lists) for a third party to use to provide non-free packages compatible with the Debian system.
It might be that FSF will object at this as well. Isn't providing infrastructure for something endorsing it in a way?
Searching for common ground between Debian and FSF Posted Jul 12, 2012 20:29 UTC (Thu) by Jonno (subscriber, #49613) [Link]
> It might be that FSF will object at this as well. Isn't providing infrastructure for something endorsing it in a way?
Not necessarily. I would consider it to just be *tolerating* it, combined with a desire to bring some semblance of order to the chaos...
Searching for common ground between Debian and FSF Posted Jul 12, 2012 23:37 UTC (Thu) by ldarby (subscriber, #41318) [Link]
It's not just tolerating, it's actively providing resources to the "enemy", which the FSF won't accept.
Searching for common ground between Debian and FSF Posted Jul 12, 2012 23:47 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> It's not just tolerating, it's actively providing resources to the "enemy", which the FSF won't accept.
If you define the "enemy" as your users who are trying to get things done, you are correct.
The FSF has forgotten their earlier statements that it's acceptable to use closed code when there is no open equivalent yet. Instead they are trying to say that users should not have the choice of closed code at all.
Searching for common ground between Debian and FSF Posted Jul 13, 2012 0:09 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
When did FSF say that? A exact reference would be better.
Searching for common ground between Debian and FSF Posted Jul 19, 2012 15:55 UTC (Thu) by Wol (guest, #4433) [Link]
I doubt it was the FSF - I think it predates the FSF.
But you'll find RMS quoted as saying that if you look back far enough. Probably the mid 80s.
Cheers,
Searching for common ground between Debian and FSF Posted Jul 13, 2012 1:20 UTC (Fri) by ldarby (subscriber, #41318) [Link]
> If you define the "enemy" as your users who are trying to get things done, you are correct.
By enemy I meant the popularity of the software, possible the software itself, and maybe the authors, but not the users.
> The FSF has forgotten their earlier statements that it's acceptable to use closed code when there is no open equivalent yet.
I can't remember where I read this and I can't find a link, but I thought RMS's said it's never OK to use non-free, apart from when replacing it, i.e. in order to bootstrap the GNU project. And if there's no free alternative then to get started writing one. (I'm not saying that's practical, I'm saying that's what his position is...)
> Instead they are trying to say that users should not have the choice of closed code at all.
Yes, the FSF has a zero-tolerance policy for non-free, and trying to prevent it being used, by preventing users from finding out about it, is consistent with that. (although it's pretty much censorship, and very ineffective at that)
Searching for common ground between Debian and FSF Posted Jul 12, 2012 20:16 UTC (Thu) by anselm (subscriber, #2796) [Link] To support these users, we are prepared to provide infrastructure (such as web hosting, bug tracking system and mailing lists) for a third party to use to provide non-free packages compatible with the Debian system. That wouldn't fly since, to be approved as a »free« distribution, the FSF wants Debian to pretend there is no such thing as non-free software.
Searching for common ground between Debian and FSF Posted Jul 12, 2012 20:23 UTC (Thu) by Jonno (subscriber, #49613) [Link]
That is patently false. While only FSF can say definitely if my idea would be enough, they absolutely *don't* want you to pretend non-free software doesn't exist.
In fact they *want* you to preach to your users about the evils of non-free software, but only *require* you to not encourage it's use (for a fairly broad definition of "encourage").
Searching for common ground between Debian and FSF Posted Jul 13, 2012 1:29 UTC (Fri) by ldarby (subscriber, #41318) [Link]
> That is patently false. While only FSF can say definitely if my idea would be enough, they absolutely *don't* want you to pretend non-free software doesn't exist.
Actually, the requirement is you have to cover your ears and shout "LA-LA-LA-I-CANT-HEAR-YOU" whenever non-free is mentioned.
Hint: turn on your sarcasm detector :)
Searching for common ground between Debian and FSF Posted Jul 16, 2012 17:32 UTC (Mon) by ssam (subscriber, #46587) [Link]
If this makes debian freer, then it is probably a good thing. however i think it would be unlikely for them to actually get to the other side of the 'line in the sand'.
I dont agree with where the FSF have drawn their line. It comes across as closed stuff is fine as long as its burnt into the hardware. I suspect there will be windows tablets soon that will meet the criteria. their advice to the openmoko people to put their firmware onto a ROM did nothing to actually make the device freer (hence it being ignored).
Personally I'd agree with garrett, that there is basically no fully free computers, because somewhere there is something secret. That does not mean we should not use computers, it just means there is still work to me done. In the early days of GNU it was userspace tools that required a propriety kernel. The FSF of today would have called that non free, but by any standard it was progress.
That said I am a supporter of the FSF. They have produced a huge amount of useful stuff that I am grateful of.
|
|||||||||||||