Group talk: Hardware/Certifications/Respect Your Freedom/Criteria
(→Use of GNU/Linux) |
(→Suggestion: Communicating with Customers) |
||
Line 20: | Line 20: | ||
Suggested addition: "Manufacturers will be open for communication with and try to cooperate with internet product fora that are moderated by active users and/or software developers for a certain product." | Suggested addition: "Manufacturers will be open for communication with and try to cooperate with internet product fora that are moderated by active users and/or software developers for a certain product." | ||
+ | |||
+ | * I don't agree with this. For a start, it's impossible to quantify, there may not be such fora, and you only find out after the hardware is packaged and shipped anyway. The FSF should be looking at issues of freedom, not every issue of what we think is good business practice. -- [[User:Gerv|Gerv]] 11:54, 18 October 2010 (UTC) | ||
===Suggestion: Clarify documentation freeness scope=== | ===Suggestion: Clarify documentation freeness scope=== |
Revision as of 06:54, 18 October 2010
Contents
- 1 Notice: Clarification about DRM
- 2 Suggestion: Include Examples of real hardware with firmware that would be acceptable
- 3 Suggestion: Include Criteria For Components
- 4 Suggestion: Communicating with Customers
- 5 Suggestion: Clarify documentation freeness scope
- 6 Suggestion: Reconsider or restate basis for "Incompatible Endorsements"
- 7 Suggestion: The guidelines should require equal billing for "free software" over open source, not "more prominent" billing
- 8 Use of GNU/Linux
- 9 What does "and more" mean?
- 10 Suggestion: Different Levels of Endorsement/compliance
- 11 Suggestion: Make clear hardware freedom limits
- 12 Suggestion: Customer Service
- 13 Suggestion: FSF Endorsed vs fully usable with free software only
- 14 Suggestion: reconsider requiring open documentation
- 15 Suggestion: Do not forbid time limited vendor locks on cell phones
Notice: Clarification about DRM
A note to everyone reviewing the criteria: we just added a sentence to clarify that, because DRM-encumbered formats can only be implemented by free software, a natural consequence of the technical policies we lay out is that users will be able to bust the DRM. We don't think this is a substantive change; instead, it just makes the consequences of the current substance explicit. We're still reviewing the other feedback we've received and will consider changes accordingly. Thanks for all your interest and comments so far. --Brett 20:48, 15 October 2010 (UTC)
Suggestion: Include Examples of real hardware with firmware that would be acceptable
Example: I would like to see an ARM-based laptop, using for example a 1ghz Samsung ARM Cortex A8 S5PC110 or S5PV210, be endorsed. however, the on-board 3D graphics engine, which is from a company called PowerVR, requires firmware in order to actually turn it [from a waste of silicon space on the CPU] into an OpenGL ES 2.0 compliant 3D engine. PowerVR's proprietary 3D graphics engine is so good that there is hardly a single manufacturer of high-end Cortex A8 and A9 CPUs who are not using it: the only exception found so far is the NVIDIA Tegra 250 Cortex A9 CPU, and that's because NVIDIA themselves are a 3D graphics card manufacturing company. Freescale's mx535, CreativeLab's Cortex A8, Texas Instrument's OMAP35xx, Samsung's S5Pxxxx series and many more: all of them use this low-cost proprietary 3D graphics engine, resulting in fantastic CPUs that cost anywhere between $20 and $50.
Now, the situation is marginally complicated by the fact that some of the companies who have used this proprietary 3D engine, requiring this firmware, have decided to make the userspace library which USES this 3D engine proprietary, and some have decided to make it free software licensed. For example, the S5PC100 has a proprietary userspace library to go with its proprietary 3D engine firmware but the S5PC110 has a *free software* userspace library to go with its proprietary 3D engine firmware: likewise for OMAP35xxs they have a free software userspace library.
So whilst I know what the answer is on this specific example, it would a) be nice to get some specific agreement b) be nice to get a list of likely components and ICs which are acceptable. specific mention of this page for example or its parent page would be nice http://www.fsf.org/resources/hw/index_html/net/wireless/index_html/cards.html
Suggestion: Include Criteria For Components
When buying parts or even assembling a new machine, it is important to know if they are going to work with GNU software. Lack of drivers, documentation, or hidden functionality may cause a purchase to go to waste.
Include a verification that endorsed components are open and operational under GNU software. Firmware like the BIOS can hide spyware and should also be subject to audit...even if they are not readily upgradable.
Suggestion: Communicating with Customers
Suggested addition: "Manufacturers will be open for communication with and try to cooperate with internet product fora that are moderated by active users and/or software developers for a certain product."
- I don't agree with this. For a start, it's impossible to quantify, there may not be such fora, and you only find out after the hardware is packaged and shipped anyway. The FSF should be looking at issues of freedom, not every issue of what we think is good business practice. -- Gerv 11:54, 18 October 2010 (UTC)
Suggestion: Clarify documentation freeness scope
Let us say a large corporation releases an FSF-endorsed music player, the Foo Player, which comes with a complete manual, which is under a free license. Its book division also releases "Foo Player: The Idiot's Guide". Is that book required to be free in order to get the endorsement? The current guidelines suggest that it might have to be. However, other companies do not have such a restriction on the books they ship about the Foo Player. It would be overreaching, in my view, to disadvantage the company who makes a product in this way, in comparison to its competitors, in order to get the endorsement. And the disadvantage is greater for larger companies with more divisions, which is unfair. As long as sufficient free documentation is available to understand and use the product, that should be enough. Perhaps we could say that all documentation shipped with the product, or necessary to understand the product's features, should be free? -- Gerv 09:30, 14 October 2010 (UTC)
Suggestion: Reconsider or restate basis for "Incompatible Endorsements"
This section says, in part:
"because these would give an appearance of legitimacy to those products, and may make users think the product requires them"
As far as I know, running Windows is not illegal in any jurisdiction. The FSF may consider software freedom to be a moral issue, but the act of running proprietary software is usually not a legal one. Also, I think it is unlikely that, if a box bears both "Works with Windows" and "Made for Mac", then a consumer will think that _both_ are necessary for the product to work. I am not sure the logic of this section withstands scrutiny. If you are worried about this problem, surely the right thing to do is require that a "Works with GNU/Linux" badge (or whatever) is given equal prominence to the Windows and/or Mac badges?
Pragmatically, making product creators choose between the FSF's badge and other badges means that a lot of products which do respect a user's freedom will end up not marked as such, because the company thinks that consumers need the reassurance of these badges to know that the hardware works with their OS. If the aim is to a) encourage products which respect freedom and b) let consumers know which products do and don't, then this outcome is bad for the campaign and bad for consumers. Yet, "Works with Windows" and "respects freedom" are not incompatible concepts, as the FSF acknowledges. -- Gerv 09:30, 14 October 2010 (UTC)
Suggestion: The guidelines should require equal billing for "free software" over open source, not "more prominent" billing
The FSF wishes to promote "free software", understandably. But many more people understand "open source". Putting the two terms together is an aid to understanding for the reader. Explanatory text on a product box like: "All software used in this product is both free software and open source software" would be prohibited by this restriction. But I think this should be OK. Are we going to require product creators to bump the font size of the words "free software" by half a point in order to pass this criterion? That seems unnecessary.
It is completely right that the criteria should not permit "free software" to be given lesser billing than "open source". -- Gerv 09:30, 14 October 2010 (UTC)
Use of GNU/Linux
What does it mean for an operating system to "include GNU"? If I ship something which has no GNU software except a copy of glibc, do I have to call it GNU/Whatever? -- Gerv 09:30, 14 October 2010 (UTC)
- see http://www.gnu.org/gnu/linux-and-gnu.html but basically linux is the kernel and GNU - as you rightly point out includes vital components such as glibc - is part of the OS. i imagine that in extreme cases where you literally do not have a single piece of GNU software installed but still all free software that yes, you'd likely still get endorsement, but the chances of you actually coming up with something useful to users, without _any_ GNU software, are sufficiently remote that it hasn't actually been considered! mind you, android is also free software, and also uses the linux kernel. so if you removed all proprietary software from android (any non-free java runtimes or libraries), and all connections to non-free web service endorsement... Lkcl 13:23, 16 October 2010 (UTC)
- My point is that the GNU project requests credit in the system name due to their large contribution to it. How is "large" defined? If there's less GNU in the system than some other provider, shouldn't I be calling it Apache/Linux or Google/Linux or something? My point: the amount of GNU-ness required to trigger the "GNU/Foo" naming requirement should be defined. -- Gerv 11:52, 18 October 2010 (UTC)
What does "and more" mean?
At the end of the first paragraph of #Respects_Your_Freedom, what does "and more" mean? It's a list of things the device "must" do:
- run free software on every layer that is user upgradeable
- allow the user to modify that software
- support free data formats
- be fully usable with free tools
- and more.
Maybe it should be removed. Or, if it has a meaning, the meaning should be explained. Ciaran 13:47, 14 October 2010 (UTC)
Suggestion: Different Levels of Endorsement/compliance
Following up with what Gerv said earlier; many hardware makers will be unwilling to meet all of the criteria, despite their products actually meeting some of the most important criteria. Insisting on strict compliance with every criteria in order to receive endorsement will force participation to be low. The "incompatible endorsements" aspect will basically force otherwise free hardware makers not to participate because, unfortunately, the vast majority of end users utilize OS/X and Windows operating systems.
I suggest that the most critical aspects of the criteria, namely 100% free software, user installation of modified software, and compilation, be sufficient to attain a separate endorsement, say a "bronze" endorsement. Hardware makers that meet more or all of the criteria could be given "silver" and "gold" endorsements, respectively.
I would like to add that it would be nice to see an even higher level of endorsement for hardware manufacturers that release specifications for their hardware under no specific terms (an NDA is not required to obtain the product specifications). Drivers developed behind closed doors by people under an NDA are much less maintainable as time goes on. The drivers tend to fall apart or can not be maintained after long periods of time either because the people that wrote them under NDA are no longer available and/or because the manufacturers that made the hardware have no vested interest in continuing the maintenance of the driver. Drivers written with freely available specifications tend to stand up well to the test of time and also tend to operate better as there is no 'magic' in getting them to work (versus transparency). See here and here for more information on the idea behind my addition.
Suggestion: Make clear hardware freedom limits
Quoting:
they say the hardware must run free software on every layer that is user upgradeable
Thats a interesting and tricky way of saying, Okay, this hardware or lets called in someway "lockware" have some layers, that user can not or even may never will able to touch or care because legally or technically reason like lack of documentation about how do to do it. My point actually is that there there is non-free-firmware as ROM/FLASH doing things to-work in some hardware layers up or between.
But this is okay.. free sofware movement is doing a great work around gpl and sofware freedom itself, just it good make clear that hardware is tricky/lock-down and we put a free sofware layer on it :). But at the end we can deal with. But be should be aware of hardware limitations in term of non-free-software embeded on it
Suggestion: Customer Service
Certification should cover quality of customer service. A device could be packaged separately as a free-software product but also exist packaged as a non-free product (ie for Windows). Customers must NOT discover that they have less or lower quality after-sale support when opting for freedom. Customer service should be equal to or greater than that offered to customers who use the device through non-free software. We should require that from sellers. -- Mathieug 19:20, 15 October 2010 (UTC)
Suggestion: FSF Endorsed vs fully usable with free software only
The FSF should only endorse products that fully respect computer users' freedoms and the proposed endorsement criteria do that just fine. However, there are realities we cannot ignore such as this one: it is already the practice in the industry to ship computer devices (printers, graphics card, external drives, etc.) in ONE package that includes software drivers for Windows and Mac. Free software needs to be there as well.
The FSF should consider a different certification mark for products it cannot endorse (because they are bundled with non-free software) but which are nevertheless freedom friendly because they are bundled with free software driver(s). This certification label would simply mean that the product is out-of-the-box fully operable through a computer running only free software. -- Mathieug 19:20, 15 October 2010 (UTC)
Suggestion: reconsider requiring open documentation
It seems compliant with the ideals of freedom to me to form a business that sells open/libre hardware, and also sells support and non-free documentation for that hardware. Thus, I recommend removing the requirement for open documentation. Although a lack of free documentation may be an annoyance, it is not the same as a limitation of freedom because the community is free to form its own free documentation independently. Unnecessary restrictions like this would just dilute the focus of this cause.--Headless 19:51, 15 October 2010 (UTC)
- It doesn't say they can't sell documentation, only "documentation must be released under a free license." The ability to sell something is prerequisite for a free license, so free documentation can be sold. Adrian Malacoda 16:32, 16 October 2010 (UTC)
Suggestion: Do not forbid time limited vendor locks on cell phones
Cell phones are often sold cheaper with e vendor lock to a telephone service. The lock may last forever or it may last for a period, say 12 months. It would be a breach of contract to remove the lock before the contract period expires (but it is usually possible through "hacking"). Such products have become extremely popular. I am concerned that products with time limited locking would not be endorsed, although all software on the device is free. I suggest that the criteria is checked so that even time limited vendor locked devices can be endorsed. In my opinion a product that locks the customer "for ever" should not be endrosed. As an aside, I might mention that the European Union (EU) is said to consider laws that will make automatic unlocking at the end of the lock period mandatory. -- Knuth 10:13, 16 October 2010 (UTC)