Group talk:Hardware/Certifications/Respect Your Freedom/Criteria

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)

The Windows/Mac badges each have pages of requirements, some of which are onerous and incompatible with user freedom or even each other (from memory, the "Designed for Windows 95" requirements prohibited any form of end-user software delivery that was not a Windows 95 PE executable, while the software I was working on consisted mostly of Perl scripts at the time). That said, hardware vendors are under pressure to put every logo they qualify for on their product packaging, and a logo which can be combined with as many of the others as possible would be valuable (it might be the same one in a different color with "FSF" removed). --Zblaxell 17:49, 19 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)

As long as the box the device is shipped in contains a CD with a free driver that works under GNU/Linux and provides at least the same functionality, I don't think we should be concerned about the box containing another CD with a driver for a proprietary system. Also I think the criterion that the product must not state that it "Works with Windows" really goes too far. A hardware vendor should certainly not force or steer its customers towards a proprietary operating system. However, I don't think that anybody should force the manufacturer to make it unnecessarily difficult for its customers to use the product with a non-free system if they wish to do so either. I'd prefer hardware that doesn't restrict anybody at all rather than going from hardware that restricts users of free operating systems to hardware that restricts users of non-free operating systems. In the end, the user is the one who should have the freedom of choice. --Moritz 23:12, 6 December 2011 (EST)

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)

Endorsement mark ideas

Art submission: HEC_Key

The meanings of the key built up with electric circuit schematic symbols (open circuit breaker and chassi ground) are open for different interpretations. Two examples:

blue: with text explanation:

Incscape-SVG source (rar-file) for further tinkering -- Chim 10:23, 19 October 2010 (UTC)

Open Source Initiative uses a keyhole. I wonder if people would think this hardware endorsement is connected to open source? And if so, is there any way to make that confusion less likely? Ciaran 10:55, 6 November 2011 (EST)

Who is the user, and what can they upgrade?

I'm very bothered by the text "Every layer that is user upgradeable." An iPhone could satisfy that requirement by simply asserting all of its layers are not user upgradeable, except for a single application that provides a LOGO interpreter in a VM. You could similarly choose a definition of "user" which enables DRM or carrier locking, or a "user" who is incapable of installing any software at all.

Some proprietary game consoles run free software inside a proprietary VM which strictly limits access to the hardware. Do these devices respect user freedom? --Zblaxell 17:21, 19 October 2010 (UTC)

What is a layer, and how does layering protect freedom?

I'm concerned about referring to "layers" of software, and granting the endorsement even when some layers are non-free. Freedom can be subverted from any level of software or hardware unless technical measures are in place to prevent it. Much of the text here suggests legacy PC-oriented thinking (and 1980's thinking at that), which doesn't take into account the capabilities of modern system hardware designs.

A WiFi interface chip with bus-master capability can, with a bug or feature in its firmware, act as a covert remote surveillance device with full read/write access to main CPU memory. Some law enforcement agencies have requested permission to use data they collect by exploiting network device firmware security bugs in evidence. Some vendors may implement such security bugs intentionally if they can find a way to derive a profit from them.

Some SoC designs used in cell phones have two processors arranged such that the "low level" and usually "non-user-upgradeable" radio interface processor also controls access to memory from the "high level" application processor--in other words, the non-user-upgradeable layer has full control of the entire system at all times, and can implement all kinds of spyware, audit the application processor for DRM violations, and prevent privacy measures implemented in software on the application processor from being effective. Bugs in the "low level" radio firmware have been exploited to insert worms and other malware into the "high level" application firmware in cell phones. This design also enables media player software to be completely free software (in the sense that all of the software running on the application processor is free) and yet not have sufficient access to hardware or memory to break DRM (e.g. because the DSP output memory is not accessible to the application processor).

A system which separates embedded CPUs running non-free firmware from its host CPU and memory running free software (e.g. by placing the host CPU and subordinate devices on opposite sides of a USB or UART serial bus, or by using hardware IOMMU or security bits controlled by free software to prevent subordinate devices from having access to free software memory) would not have these particular problems; however, such a partitioning of the system is not necessarily layering. --Zblaxell 17:21, 19 October 2010 (UTC)

Encumbered but "built-in" Hardware features

There are three particular patented and/or encumbered and/or firmware/proprietary areas which are extremely common on low-cost low-power "embedded" CPUs that are becoming increasinly more important as their speeds and features (encumbered or otherwise) begin to equal and exceed those of x86 hardware.

After careful consideration, I *believe* that there is no problem, but I would appreciate someone checking the logic / reasoning, against that of the "Formats" section.

HDCP

HDCP is a DRM mechanism for preventing and prohibiting "unauthorised" playback of encrypted video data (such as that coming from Blu-ray players). It appears to require "cooperation" from the hardware and the software, and requires a "secret key" which will be handed out to Free Software Developers when hell freezes over. However, that is okay, because the scheme is so flawed that the "master key" was cracked recently.

Thus, the logic goes, that even though HDCP endeavours to "encumber" both the HDMI and DVI hardware interfaces of monitors, LCD panels and TV panels, it is actually possible to comply with the "Formats" section by utilising Free Software and this "master key" to decrypt the HDCP-encumbered video data.

However, ironically, it is usually encumbered and patented video formats (such as MPEG) that are further encumbered by HDCP, and thus it is moot that anyone who would purchase an FSF Hardware-endorsed product would be utilising it to play back encumbered video formats utilising an encumbered DRM encryption scheme! They would, instead, play back Free Software unencumbered video formats which are not encumbered by HDCP either! However, in the incredibly unlikely scenario where someone would encumber a Free Software video format with the HDCP DRM scheme, there does exist a way out, by utilising the flaws in the HDCP scheme and a Free Software implementation of that flawed HDCP algorithm to decrypt the unencumbered video data.

Please could someone confirm this logic - ta. Lkcl 13:05, 23 January 2011 (EST)

Hardware proprietary implementations of 3D Engines on SoC CPUs

Many of the best, affordable SoC CPUs are affordable because they are in mass-production and have features that are attractive to people who are not aware of their loss of Freedoms. 3D OpenGL capability is one of the important features that these people expect. However, there literally does not exist one single (worthwhile) SoC mass-production device which has a 3D Engine that is documented or understood enough to have a Free Software library. There do exist SoCs which have General Purpose Floating Point Vector Processing Units (NEON, X-Burst) but literally every single mass-produced CPU with the exception of the S3C6410 and the S5CPC100 has a proprietary 3D Graphics library.

Fortunately, however, these SoCs - at least the ARM Cortex A8 and A9 ones - typically have NEON Vector-Processing capability which could be utilised to at least get some measure of accelerated 3D performance.

The question remains:

• is the use of NEON, whilst work is ongoing to reverse-engineer these 3D Engines, sufficient in the mean-time? Specifically, is "non-use" of the entire proprietary library, thus cutting the user off from the 3D Hardware-accelerated capabilities until such time as a Free Software Library is available, in combination with a partially-accelerated Software (MESA) 3D implementation (utilising the NEON Vector Processing Unit), sufficient to qualify any such device which has such 3D Hardware for FSF Endorsed status?
• Or, would it be necessary to simply not *have* that 3D Hardware engine until such time as the engine has been reverse-engineered - bearing in mind that in order to reverse-engineer it requires having access to the hardware!
• Would it be acceptable that FSF Endorsement be given, but if there ever was initiated a reverse-engineering effort, it would be *required* that the device have that Free Software library installed, and failure to do so would result in the FSF Endorsement being removed?

These are tricky questions that need a clear answer! Lkcl 13:17, 23 January 2011 (EST)

Hardware proprietary implementations of MPEG and other encumbered formats on SoC CPUs

Some SoC CPUs have hardware-implementations of MPEG, H.264 and other patented formats. For example, those SoC CPUs from Texas Instruments such as the OMAP series have these encumbered algorithms burned into a ROM which the DSP can be requested to run, whilst other CPUs simply have full-on hardware engines that can be activated on request, and out pops video data into the requested memory area (usually the framebuffer). There also do exist some engines that are truly "General Purpose co-processors" but these co-processors are "secret". Typically they have proprietary instruction extensions that activate proprietary Vector Processing Units and other SIMD instruction capability, thus requiring "firmware" to be uploaded to them, but these are very rare.

Again, like 3D, the justification for the inclusion of these encumbered unchangeable implementations is that it is efficient to do so, thus making the device attractive in mass-volume quantities, and thus their price is lower and the end-result is affordable devices to both Free Software people as well as the average person.

On the basis that it is impossible to change or remove the hardware accelerated engine, and it is impossible to expect that the CPU SoC manufacturer create an affordable version of the CPU that *doesn't* have this encumbered accelerated hardware (unless sufficient money is paid to them, which will be several millions of dollars), the question is:

• In a similar way to the 3D engines, is it reasonable to simply ignore the existence of proprietary hardware-implementations of the proprietary encumbered video and picture formats (MPEG, JPEG etc.) because there exists perfectly good software-implementations of Free Software video and picture unencumbered formats?

Except in the case of the "General Purpose" co-processor SoCs, this issue is however slightly different from the 3D engines, because the hardware implementations of MPEG and JPEG decode/encode etc. are quite literally "fire-and-forget". In other words, it's a simple "one input, one output" black box. Whereas, the 3D engines are much more complex devices (GPUs), some of which have user-programmable (proprietary) engines that are very basic processors in their own right.

So it would seem that it is clear, under the "Formats" section, that simply implementing unencumbered Video Decoding (in Software) of unencumbered Video Formats (Theora) etc. would be sufficient, as the encumbered and unchangeable hardware-only blocks could just be... ignored, even though this would often result in those unencumbered Software implementations running much much slower and at much lower quality than the encumbered hardware-only blocks.

It's often the case, particularly with MIPS Set-Top Box processors, that a 200mhz MIPS is combined with a monstrous 1080p60 hardware MPEG decode engine. it is clearly impossible to expect a 200mhz MIPS to be capable of implementing Theora in software and expect it to be able to fill 1920x1080 pixels 60 times per second. But, aside from the fact that a 200mhz MIPS processor would be pretty useless as a General-Purpose device anyway, in the unlikely event that a manufacturer wished to apply for FSF endorsement criteria and was willing to attempt to run Theora and other Free Software video decoding - even at silly resolutions of 240x180 @ 20fps - should a device based on such a CPU be excluded from FSF endorsement because it happens to have this 1080p60 hardware-only MPEG engine which would just be so much "dead weight" as far as any Free Software user is concerned?

It is recognised that those CPUs such as the OMAP DSPs can in fact comply, and provide very reasonable comparative implementations. Texas Instruments (confirmation required!) may(?) have sponsored (or maybe it was a GSoC project) the implementation of Theora on the OMAP's DSP, and its performance is comparable to that of TI's proprietary encumbered (ROM-based) DSP MPEG algorithms. In this instance, compliance under the "Formats" section is pretty obviously clear

It is *equally* recognised that a "secret" DSP or "secret" Co-processor is less tolerable, especially in the case where proprietary firmware is required. In fact, such a CPU with a proprietary DSP or Co-Processor would fall foul of paragraph 2 of the "Always 100% Free Software" section, simple as that, and would not receive FSF Endorsement.

So it is this "grey area" where the implementations are entirely hardware where clarification is required: would "non-use" be sufficient (and a software implementation instead) to qualify? Lkcl

Suggestion: No Watermarking

I'd like to see the "No spying" section explicitly stating that the product mustn't use any form of (digital) watermarking. I think this should be stated explicitly because requiring all software components to be free software will not ensure it. Speaking of a printer, a watermark that is added by the product's firmware could be detected by the user when reading the code and be removed in a modified version of the code. However, the manufacturer has other ways to implement a watermark such as intentionally applying a special unique texture to the cylinders in the production process. This will not mean including any form of proprietary software or hardware locks but still would be a malicious feature and it won't even be possible for the user to detect / remove it. What do you think about this? --Moritz 22:07, 27 November 2011 (EST)

Suggestion: Create a definition for free hardware

The below suggestion was passed along to us:

The logic behind this is that we can't have truly free software without hardware that allows such freedom to happen in the first place. If the user doesn't have proper documentation to use the hardware, we really can't say the user can be capable of taking control over the hardware, which in turn means the user can't have control over the software, since it needs to run with that hardware.

• When somebody buys a piece of individual hardware, then the purchaser needs to be able to know the exact model of the hardware. This one is hard to avoid for starters, but better be safe and mention this explicitly.

• Related to the above: when somebody buys a pre-built computer, that person needs to know with what hardware the computer was built (i.e. the name and the model of each component). Doesn't need to be anything complex, a simple list on paper to go along with the receipt or something similar would do.

• The hardware documentation (at the very least its interface and any relevant behavior) should be freely available, ideally from the manufacturer site. Doesn't need to be bundled with the hardware itself since most users aren't going to bother programming it, but it should be easy enough to find by just looking up the hardware model (exception to the this rule: things like undefined behavior and such don't need to be documented, since software is not meant to mess with it for starters - just document what are the valid settings and such to prevent said behavior)

• Users should be able to program the hardware directly (e.g. by making drivers) and be able to distribute said software without any need for explicit permission from the hardware manufacturer, and the manufacturer shall not do any attempts to block such efforts (at worst it should just go ignored).

Here the person who suggested this. One important thing to take into account is the objective of this list. While the general criteria the FSF demands is to make it easy for hardware to be used in a free software environment, this list is to ensure we can even get it to work. Even when manufacturers don't want to cooperate, hardware that follows these conditions could still be easily made compatible with free software through community efforts, without need to resorting to practices such as reverse engineering and the like. As such, these conditions are even more critical than the criteria the FSF usually talks about. (also took the liberty to fix the formatting of that list in the wiki :P) Sik 20:41, 10 January 2013 (EST)

Suggestion: Pick another patent-encumbered multimedia format or explain the problem generally

Regarding "For instance, MP3 is an encumbered format, because several organizations actively work to get patent royalties from players.", my understanding is that MP3 is no longer patent-encumbered because the relevant patents expired in 2017 if not before. Therefore MP3 is not a good example of an encumbered format.

Perhaps the idea of patent encumberances could be explained more generally as something to look out for; naming any particular currently-encumbered format will someday require another edit when patents covering that format expire. jbn 30 September 2018

Suggestion: Switch from recommending Ogg Vorbis to recommending Opus

Regarding "Ogg Vorbis is an unencumbered format and serves the same purpose, so we are willing to endorse Digital Audio Players (DAP) that play MP3 and Ogg Vorbis files." and other sentences mentioning Ogg Vorbis, I suggest switching mentions of Ogg Vorbis to Opus as Opus is unencumbered, and because Opus has some technical and practical advantages. I believe Opus was also made part of the WebM standard in 2013, so Opus is likely to be playable in a lot of applications and devices. jbn 30 September 2018