Yes, the FCC might ban your operating system

fcc-logo_blackOver the last few weeks a discussion has flourished over the FCC’s Notification of Proposed Rule Making (NPRM) on modular transmitters and electronic labels for wireless devices. Some folks have felt that the phrasing has been too Chicken-Little-like and that the FCC’s proposal doesn’t affect the ability to install free, libre or open source operating system. The FCC in fact says their proposal has no effect on open source operating systems or open source in general. The FCC is undoubtedly wrong.

I want to make something entirely clear: I believe the FCC has the best of intentions. I believe they want to protect the radio spectrum and implement the E-LABEL Act as required by Congress. I believe they want to protect innovation in the technology industry. I also believe that their proposal harms innovation, endangers the free, libre and open source community and is generally anti-user.

Just the basics

Before we get into the exact regulations, it’s important to understand some background material. The FCC exists in part to provide rules and regulations for managing the radio spectrum. Since the spectrum is a finite resource, the FCC acts as the referee to try to make sure all users can use the spectrum for communication and experimentation. While difficult, the FCC manages the needs of different classes of users, such as amateur radio operators, unlicensed users (like for Wi-Fi, Bluetooth, NFC, etc), commercial operators, armed forces and safety personnel, and air traffic control. Each of these classes of users has a right to operate in particular areas of the radio spectrum as long as they behave in an appropriate manner.

The rules on appropriate usage vary by class but they mostly relate to making sure users aren’t operating in a way which prevents other users from using the spectrum. As an example, users may be limited to a certain power-level in order to guarantee their transmissions only cover a small area. In the case of Wi-Fi users, the power of the transmission is limited to a small amount. While it varies by band and channel, in all cases the allowed transmission power for a Wi-Fi device is no more than 1 watt.

What happens though if a number of people were to violate these rules and run their Wi-Fi network at a much higher power level, say 1 kilowatt or 1000 times more power? In the event the users had the hardware to support this, this network would have an extreme range. At first blush that sounds great but there’s a problem. Remember: the radio spectrum is a finite resource. In the case of 2.4 GHz Wi-Fi, there are under 14 channels and, in the US, only 11 channels are effectively legal and only three are not overlapping. Each channel can have more than one Wi-Fi network on it but the bandwidth must be shared between the networks. If multiple networks were running at 1 kilowatt, none of the networks would be usable since there’d be potentially dozens of networks on each channel. By keeping wattage low and the range of Wi-Fi networks small, the spectrum can be more easily shared.

While regulating users helps protect the spectrum, imagine if the devices themselves caused interference. For example, let’s say your router in its default setup occasionally started transmitting unexpectedly at 1 kilowatt. This lack of reliability would have many of the same effects of users intentionally operating at 1 kilowatt. More importantly users may only operate devices in the manner in which the user is authorized. If the device may only be operated at say 1 watt and it instead operates at 1 kilowatt, the user is operating “outside of authorization” even if they don’t intend to do so. While the FCC may take intent into consideration when assessing penalties, they are not required to do so. Additionally, penalties for operating outside of authorization can be quite substantial. Since the user can be held liable for this, making sure devices are reliable is important.

In order to protect users and the spectrum from unintended damages, the FCC requires all devices sold in the US meet certain standards to assure reliability. This is called “equipment authorization.” During the equipment authorization process, the manufacturer must submit information about the device to the FCC, or someone working on their behalf. In many cases, an independent laboratory must test the device to ensure unintended, unauthorized transmission doesn’t occur. If the manufacturer does not receive equipment authorization, the device may not be sold in the US.

What is a device anyway?

When we use the word device in the context of equipment authorization, it’s important to know the term device is a little broader than developer parlance. In the terms of the FCC and wireless radios, the term device includes the hardware used for making the wireless transmission, primarily the wireless radio, as well as any software which can control aspects of the radio transmission such as frequency, transmission power, type of transmission, etc. This is implied by the rule at 47 CFR 15.407(i).

How does an operating system kernel interact with a wireless radio?

While the particular interaction varies by operating system, many of them follow a design somewhat similar to the Linux kernel. In the Linux kernel, there is a wireless subsystem which manages all the wireless radios on the system. Each one of these radios has a driver specific to the model of radio. The driver acts as a layer for translating the structures in the kernel for using the wireless radio into the structures expected by the wireless radio firmware. The wireless driver API requires every driver implement a set of functions which include getting and setting the transmission power, changing the channel, finding new access points and others.

While the drivers are unique to the radio, Linux in particular provides shared implementations of common wireless radio driver functionality. As an example, regulatory subsystem interacts with a shared implementation for properly managing regulatory rules for different countries, such as which channels are available, how much power is allowed, etc. Drivers don’t have to use the shared implementation. However, in most cases they’d then have to reimplement that functionality on their own. In the case of a driver using the shared implementation, the driver would verify with the regulatory subsystem that a change to the transmission power is legally allowed in the current regulatory domain (A regulatory domain represents a geographic area with a set of legally mandated rules for radio transmissions. For example, the US would be a regulatory domain while Canada is another.)  If the regulatory subsystem says the increase in transmission power is not allowed within the regulatory domain, the driver would reject the request for the change, signal an error and not pass it along to the firmware.

As mentioned previously, the driver interacts with the wireless radio firmware. Firmware is the software created by the wireless radio manufacturer that makes the commands and receives responses to the physical wireless radio. It may be free and open source software such as the firmware for Ath9k-htc but in many cases is not. Wireless radio firmware is OS agnostic. The exact functionality and the design of the firmware is very dependent on the design of the physical wireless radio.

How much of the software is included in the term “device?”

It’s not entirely clear. That said, the FCC seems to interpret software control rather broadly. In the FCC’s interpretation, the firmware is undoubtedly part of the device. The driver is also likely part of the device. In fact, in 2007, the method of protecting the regulatory domain information in the Linux kernel which passes information to the driver was relevant to the FCC’s regulation of devices. Additionally, the FCC’s implemented rules on U-NII (see more below) require manufacturers to explain how they’re preventing the flashing of third party software onto the device and uses DD-WRT as an example. This implies that the FCC’s powers to regulate the software that controls a wireless radio are rather broad.

So what parts of the NPRM are you actually worried about?

There are two areas which the NPRM is concerning: banning modifications of software control of the device and banning modification of the electronic label.

What parts of the NPRM ban modification of software control?

2.1033 Application for grant of certification. Paragraph 4(i) which reads:

For devices including modular transmitters which are software defined radios and use software to control the radio or other parameters subject to the Commission’s rules, the description must include details of the equipment’s capabilities for software modification and upgradeability, including all frequency bands, power levels, modulation types, or other modes of operation for which the device is designed to operate, whether or not the device will be initially marketed with all modes enabled. The description must state which parties will be authorized to make software changes (e.g., the grantee, wireless service providers, other authorized parties) and the software controls that are provided to prevent unauthorized parties from enabling different modes of operation. Manufacturers must describe the methods used in the device to secure the software in their application for equipment authorization and must include a high level operational description or flow diagram of the software that controls the radio frequency operating parameters. The applicant must provide an attestation that only permissible modes of operation may be selected by a user.

2.1042 Certified modular transmitters. Paragraph (8)(e) which reads:

Manufacturers of any radio including certified modular transmitters which includes a software defined radio must take steps to ensure that only software that has been approved with a particular radio can be loaded into that radio. The software must not allow the installers or end-user to operate the transmitter with operating frequencies, output power, modulation types or other radio frequency parameters outside those that were approved. Manufacturers may use means including, but not limited to the use of a private network that allows only authenticated users to download software, electronic signatures in software or coding in hardware that is decoded by software to verify that new software can be legally loaded into a device to meet these requirements.

Wait, what’s a modular transmitter?

It’s a legal definition for an approved wireless radio which can be added to another piece of hardware in such a way that doesn’t mean the combined hardware needs a new approval. Think of it like an add-on in software.

Okay, that sounds a little like they’re recommending Digital “Rights” Management (DRM).

Sure does.

So why does this mean you can’t install your own OS?

Remember a device includes the software which controls radio frequency parameters. In the case of Linux, radio frequency parameters are controlled in drivers which are part of the kernel. The only way to guarantee that a third party outside of the manufacturer’s control, which includes the user who owns the device, can’t modify these parameters is to prevent unauthorized modification and replacement of the driver which is in the kernel. And remember, in Linux the driver may use shared functionality inside the kernel. So how do you do that without restricting modifications to the operating system itself?

Are you sure this interpretation is correct?

Pretty sure. Routers which implement similar rules for U-NII devices already are locking down their devices. It’s the simplest and clearest way to guarantee the device meet the requirements for FCC authorization.

The number of people involved in open source software and digital freedom feel this interpretation is likely correct. These include lawyers from the Electronic Frontier Foundation, the Free Software Foundation, software developers involved in working in OpenWrt/LIbreCMC and CeroWrt and management impacted companies such as Qualcomm and ThinkPenguin.

Note: organizations included for identification purposes only.

Could companies design hardware that would allow modification?

Maybe, but they probably won’t. There’s minimal advantage to them in doing so and the easiest method of ensuring the rules are followed is to simply prevent modification. After all, they’ll have to rewrite drivers, redesign firmware and create new wireless radios with the hope that the design they’ve come up with will meet the requirements of the FCC. If you’re rushing to market to beat your competitors, why not just take the easiest method and lock everything down?

Possible other interpretations

What if the driver and firmware had to be signed to prevent modification? That wouldn’t be so bad would it?

(In this case we’re assuming the driver and firmware are the only parts of software that are considered part of the device.)

It actually would. Drivers created by hardware manufacturers often only support financially valuable functionality. In particular, while they support the standard Wi-Fi functionality, they may not have support for advanced scenarios. As an example, mesh networking support is rarely included in official drivers since it’s not a common use case. Communities of developers have worked together to build high quality mesh networking implementations into open source Linux drivers. These drivers are used to create mesh networking for expanding internet access to low-income communities and used for data communication by amateur radio operators responding to natural disasters.

Additionally, the ability to experiment with drivers is vital to academic research into wireless technologies. Nearly 7,200 scholarly articles on wireless networking technologies reference a particular brand of open and modifiable hardware which would be banned under these rules.

Alright, but what if only the firmware is part of the device?

(In this case we’re assuming the firmware is the only parts of software that are considered part of the device.)

A number of important innovations in wireless research depend on access to the firmware. User-access to firmware source code has led to bug fixes, security enhancements, and features that were not part of the original code base. In one instance a user was able to fix a critical bug impacting all Wi-Fi adapters based on a particular set of Qualcomm Atheros wireless chipset(s). As users were frequently being disconnected under certain conditions one user took it upon themselves to track down and fix the bug This bug was then submitted to QCA to be considered for inclusion in their firmware which is shipped to millions of people. This would not have been possible had the source code for the firmware been unavailable, or had these devices otherwise been locked.

This only affects routers right?

No it affects anything that includes a modular transmitter. This potentially could affect computers, phones, routers, anything.


What’s the E-LABEL Act?

The E-LABEL Act seems like a well-meaning act of Congress to require that the FCC create rules that allow the certificate of conformance for an authorized device to be displayed on screen.

Certificate of conformance?

Every device has gone through and been approved through the equipment authorization process must include a Certificate of Conformance when sold to the end user. One of those pieces of paper you probably recycle after you open the device’s box, the Certificate of Conformance lists information about the device’s authorization and approval as well as some related FCC rules. The law says the equipment manufacturer must provide you with the certificate of conformance when you get the device.

So what’s the problem with making that electronic?
Nothing, it sounds like a good idea to me.

Then what’s wrong with the NPRM?

The NPRM includes 2.935 Electronic labeling of radiofrequency devices, paragraph (d) which reads:

(d) The necessary label information must be programmed by the responsible party and must be secured in such a manner that third-parties cannot modify it.

What does it mean to “secure” the “necessary label information” against modification?

It’s unclear. One potential example of compliance is to have the information written at the factory on write-once ROM to be read out when the software asks for it to be displayed. This wouldn’t inherently imply that any sort of restriction on modification to the software is required.

So we’re cool, right?

That’s only if the manufacturer chooses to implement it that way. The manufacturer could put the information on the main storage medium and then lockdown the device to prevent modification. That’s quite possibly cheaper.

Additionally, it seems unclear to me how this rule would make sure the label information is always accessible. Let’s say the label information is viewable on an Android device from the settings menu. Does the manufacturer have to make sure that the device isn’t reflashed so that the label information can’t be removed from the menu? I really don’t know but I think it’s possible that this is implied.

U-NII rules

One topic that relates to the NPRM are rules which have begun to be enforced related to U-NII devices, primarily wireless routers.

What is U-NII?

Unlicensed National Information Infrastructure. The short answer is U-NII devices are devices for unlicensed users operating in the 5 Ghz band, which is required by 802.11ac standard and supported by 802.11n. Most routers are U-NII devices.

How does this relate to the NPRM?

The U-NII rules already require device manufacturers prevent modifications of U-NII devices and we know how they’ve been implemented. Since the U-NII rules are defined similar to the rules in the NPRM, we can assume that the implementation will be similar.

Wait, what are these U-NII rules?

The FCC’s application for authorization of a U-NII requires a manufacturer describe the overall security measures and systems that ensure that:

  1. Only properly authenticated software is loaded and operating the device, and
  2. The device is not easily modified with RF parameters outside of the authorization

Additionally, in the application, one of the questions which must be answered by the manufacturer is:

What prevents third parties from loading non-US versions of the software/firmware on the device? Describe in detail how the device is protected from “flashing” and the installation of third-party firmware such as DD-WRT.

Whoa, you mean I can’t install OpenWrt under the U-NII rules?

Generally no. You could if the manufacturer created a signed fork of OpenWrt. If it’s made by the OpenWrt project or if you made it yourself, the rules specifically prohibit that.

Are you sure that router companies would ban all modification of the device?

Yes. There are numerous examples of companies which have done just that in order to get their new devices approved.

These U-NII rules are serious, why aren’t we fighting them?

The problem is the U-NII rules are in place already. This makes them much more difficult to address. The NPRM is simply a notice that the FCC wants to make rules but they haven’t finalized anything. If we can make clear that the DRM aspects of the NPRM are unacceptable then we’ll have a stronger claim to change the U-NII rules.

Arguments against stopping the NPRM

A number of arguments have come up regarding the NPRM. I’d like to discuss them in turn.

“The FCC spokesperson says this doesn’t have an effect on open source software.”

It doesn’t matter what the FCC’s spokesperson says; it matters what the proposed rules say. Taking into consideration the wording of the proposals, the breadth of current rules and the design of hardware and software, the proposed rules have a potentially disastrous effect on the ability of users to control their devices. I believe users who want to install open source operating systems will be at the whim of device makers even if they want to operate fully within the law.

I want to make very clear: I think don’t the the folks at the FCC mean harm to anyone or any use case. They’re just not seeing the full picture of what they’re proposing and what rules already exist.

“You just want people to ignore FCC regulations and operate in an illegal manner!”

I actually don’t. I think the FCC rules on power output, frequencies available, etc. are important and should be obeyed. Additionally, I believe the FCC should fairly and equally punish those who willfully make decisions that lead to them operating outside of authorization. These rules exist for very good reasons and we should follow them.

“But if the FCC doesn’t prevent modifications, people are going to accidentally break the rules!”

That can only happen if the software already on the device is so poorly designed that a user wouldn’t know that they’re at risk of breaking the rules. The shipped software on the device should not, under any circumstances, allow the user to put the device into an unauthorized state from a user interface.

Additionally, a warning could be displayed if a user attempts to install a custom operating system. This warning could tell the user that they’re installing unverified software and that there’s no assurance that the device will operate in a legal manner. In such a case the user is taking their “life” into their own hands.

“The only way to guarantee that no one will break the rules is to require manufacturers to prevent the users from modifying the device”

No method will be 100% effective at preventing people with bad intentions from violating the law. Even if the proposed NPRM rules are implemented, we’d still have the billions of modifiable devices that already exist. Users would still be allowed to import devices from other countries for their own modifications (although companies may choose to lockdown everywhere to lower design costs). And bad actors could still create transmitters from scratch for a few hundred dollars that interfere with law-abiding citizens.

We’re not debating a proposal that’s guaranteed to fix a problem versus one that isn’t. These are proposals which make certain behaviors more or less likely.

“Users aren’t responsible enough to be allowed to modify their devices”

I firmly and respectfully disagree. The user always knows their life better than anyone else. Linux exists because users could modify their device. OpenWrt exists because users could modify their device. CyanogenMod exists because users could modify their device. Ultimately, a software community which believe users are fundamentally unqualified is a broken community. I trust users to take responsibility for their own actions.

There will always be bad actors, but even so there already existed a system to reduce the problems to a manageable level, and the recent rules won’t stop those whom are determined to break the rules/cause interference from doing so.

“So you’re saying nothing should happen?”

I believe the most effective way to reduce the small number of instances where users are modifying their devices AND breaking the law is to discourage the law breaking through social norms. We need users to understand the harm that can come from disobeying regulatory rules and that we as a community do not support their actions. Additionally, the FCC should address this law breaking through firm and fair enforcement actions. Violators can receive fines of $20,000 or more and those fines should continue, particularly for willful violations.

This effort should be inspired by the fight against drunk driving. Over the past 30 years, drunk driving deaths have decreased 60%. Much of the effect came from influencing drivers through education and changing social norms. These social changes were reinforced by increased penalties for drunk driving offenses. Most notably, this decrease did not require extreme restrictions on the freedom of law abiding drivers, such as mandatory breathalyzers in every car.

Next Steps

As we move forward, there are two things we can do to protect the rights of users to control the devices they own.

We can speak out

You need to contact the FCC and tell them that you value the ability to control your devices. Tell them you feel their NPRM is dangerous and overly broad. Tell them you care about protecting the wireless spectrum, but not at the expense of law abiding citizens. Tell them you believe there’s a better way.

We organize to self-regulate

As mentioned before I believe social change in the technology community will be extremely effective at protecting the spectrum while still allowing the ability of users and companies to experiment and innovate. Over the next few weeks, I propose we formalize a coalition based on the following principles:

  • We support the continued ability of users and researchers to control all the software on their devices for all legal purposes.
  • We will not create software to intentionally violate the rules of any regulatory domain.
  • We will not precompile base images containing a user interface allowing violations of the rules of the regulatory domain for which it is created.
  • We will not include source code in our public source code repositories which allow users to trivially violate regulatory domain rules.
  • As technologically feasible, we will warn users attempting to modify the software controlling radio operating characteristics that they are responsible for their actions and that those actions could violate regulatory domain rules.
  • We will educate users on the potential legal and safety dangers of modifying the software controlling radio operating characteristics.
  • We will not provide assistance to members of the community attempting to violate regulatory rules and will actively discourage members of the community attempting to do so.
  • We will serve as forum for education and collaboration between regulatory agencies, industry, FLOSS and proprietary software developers, and users.

Every member of this coalition should commit to behaving in accordance to these principles. If you agree with these principles and want to work together to improve our community, please email me at, post a comment below or join the Save Wifi email list at

Edit on September 22: I fixed some typos, such as changing ath9k to ath9k-htc, specified that this legal opinion is not unique to myself and clarified that device import is not a guaranteed way around the rules and clarified a few other areas.

32 thoughts on “Yes, the FCC might ban your operating system

  1. I believe that the professional linux community (Red Hat, Ubuntu) will fight this tooth and nail. They likely view FOSS as as an unalienable right, and will fight tooth and nail against it, or think it is so absurd that they will cackle when the FCC asks why they haven’t locked down their OS’s.


  2. >We will educate users on the potential legal and safety dangers of modifying the software controlling radio operating characteristics.

    What *are* the possible safety dangers of modifying changing radio operating characteristics?

    Liked by 1 person

    • On some frequencies, Wifi frequencies are shared with Terminal Doppler Weather Radar (TDWR) used at about 45 airports in the US. A mechanism called dynamic frequency switching is used for routers to sense if a radar is operating on the same channel as the router. If the a radar is operating, the router would change channels immediately. If DFS is turned off, interference with the radar can occur if the router is close enough to an airport that uses TDWR and is running at a sufficient power. Such behavior is exceedingly irresponsible and I believe the FCC should firmly and fairly address this by punishing those engaging in this activity.


  3. Interesting topic. I’m a fan of OpenWrt, because it allows the user to take control of their hardware and customise it, where manufacturer’s OS usually doesn’t … and at the end of the day, the hardware belongs to the person who bought it, and up to them to decide what they do with it, right ?

    I thought OpenWrt had already locked down transmit power, certainly in their forums, they are blunt with people asking how to circumvent it, basically – “Don’t ask that question here, we don’t approve of changing transmit power, and posting about it will get you banned from these forums”, or words to that effect …

    Presumably the hardware vendors could manufacture wifi devices that are locked to a certain transmit power, so isn’t this something to enforce in hardware, not in software ?

    Will be interesting to see what happens. Thanks for posting !


    Don Charisma


    • Don,

      Thanks for the comment! It’s not quite as simple as limiting the transmit power. There are two main issues related to transmit power. First is the allowed transmit power varies between countries. For example, on the 2.4 Ghz band, channels 12 and 13 are allowed to run at a normal power but in the US they have to run at an extremely low power to the point where they’re unusable. Putting this into hardware could be expensive since you’d have to have different hardware for every country.

      Secondly, the transmit power varies for different users in one country. For example, on channel 1 on the 5 Ghz band, amateur radio operators are allowed to run at a higher power than unlicensed users. This is of particular use when they operate long range mesh networks for use in disaster recovery. If the device is locked to only allow 1 watt, then that use case goes out the window.

      Additionally, there are topics such as DFS and modulation characteristics which also are required by law on certain frequencies. Those also vary by country. For an illustration of how complex this gets, you can look at the database used by the Linux kernel at

      On top of all this, these requirements change as regulators adjust the rules for new usecases or issues that come up!


      • You’re welcome, I have an interest in wifi, networking, routing etc.

        And, it never is that simple is it … or is it ?

        I don’t think the end consumer, be they retail, carrier or otherwise should bear the burden of responsibility here, it’s not their responsibility. License the retailers of the devices and fine them if they for instance sell carrier grade stuff to retail, without seeing a valid licence.

        Licence the hardware manufacturers and fine them if they supply devices that are capable of a higher power than US regs allow to retailers.

        The cost isn’t relevant, other than to say wifi equipment has eprom within it that can be fixed to certain transmit powers. I don’t see this as “expensive”, or complicated, more the hardware manufacturer taking due care and attention of the end user in their country, according to their county’s rules. Or don’t sell their stuff there.

        If the end user takes hacks it, then that’s only the responsibility of the end user and they should expect the possibility of fine and or prosecution.

        So it’s the hardware manufacturer’s problem, and the country’s enforcement officials problem. Not OpenWrt, DD-Wrt, Linux, Apple or Microsoft’s problem, who cares if the software will allow higher transmit power if the hardware manufacturers are allowed to continue to save a few cents on their hardware … fix the hardware, you’ll never fix the software, it’s too easy to change it, especially with Linux as it’s open source. And even then people have been hacking Microsoft and Apple right since the beginning.

        Ubiquiti Nanostation M has a max transmit power of 630mW, and I’m led to believe that it’ll transmit up to 15Km, so I doubt the limit of 1 watt 30dbm is the end of the world for mesh networks. At least not for Ubiquiti/Atheros equipment. But I’ve never operated it, so I don’t know …


        Also, I think transmit powers as low as 28 dbm in Nanostation M can cause human beings harm, their leaflet says it must be a few meters away from people … So limiting trans power is a sensible idea, to prevent presumably flash getting cooked and later cancer.

        The other thing is the air being “polluted” by transmitters at too high a power, which means no one can use their networks. So another reason for lower transmit powers.

        Just my two cents/pence worth 🙂




  4. Could an alternative be proposed?

    Suppose it was possible to detect (passively) signals that were highly likely to be in excess of legal limits. Someone could build a daemon that gathers data (time/date, location, strength, bandwidth anomalies, ID numbers) and automatically uploads this to an open database. Such a system could be made a common part of the infrastructure.

    Anyone who wants to make sure their experiments are not accidentally out of bounds could search this information. Additional automatic search tools could be built.

    Anyone who wants to find frequent violators (such as roving FCC enforcers) could also query the data and use it to protect the rest of us from the pests after (of course!) validating the information by direct on-site measurement.

    Obviously, it’d be hard to protect such a thing from idiots who feel compelled to inject bad data, but with the right sorts of authentication and data analysis techniques, it might well be useful, and far more effective than DRMing the universe.


    • Thanks for commenting James.

      That’s certainly a possibility but it bring up issues of privacy. I do think the FCC should be enforcing the law better of course though.


  5. This article is all about installing open source firmware into a router, not about downloading/installing an open source OS onto your computer.

    Thanks for the scare…


    • Thanks for your comment Luposian. It’s about any computing device using a modular transmitter. Modular transmitters can and will be used in devices of all types. I mention this in the section titled: “This only affects routers right?”


    • The dividing line between the two may well be paper thin. What about a CPU with an integrated WiFi chipset? Or an embedded wireless device such as a tablet?

      The new rules mean that if you have wireless hardware somewhere in your system, then you have to prove that nobody else can run their own code on it. That’s the slippery slope we’re sliding down.


  6. Thanks for the great right-up.

    FYI – I ran into an issue with my Google NexusOne phone. I ran stock Android from Google/HTC on for quite a while until after a small fall it started into a reboot loop when the ActivityManager couldn’t allocate enough memory (and thus rebooting). The first time I reset to factory only to have the issue resurface a couple weeks later. I permanently fixed it by flashing CyanogenMod’s CM7 variant of Android, and it’s been running for years since. I had no other means of getting it fixed.


  7. […] manipulation. While the rules do not ban open-source firmware modification in its entirety, some worry that manufacturers may find it easier to prevent modification in its entirety than to t…. Harold Feld (Senior Vice President of Public Knowledge), speaking to TechDirt, explained the […]


  8. I believe the FCC is another unconstitutional agency like all the other alphabet agencies and they
    have the worst intentions possible regarding freedom.
    The United States is a corporation and corporations want nothing but profit…this one wants profit at the barrel of a gun.
    Considering how microsoft is ‘forcing’ people to upgrade to their spy/ad-ware windows 10… I suspect they’re greasing the back-pockets of FCC droids to make sure open-source dies.

    Open source is the future. Otherwise our computers will be nothing more than glorified televisions spewing ads, spying on us, and eventually telling us what to do.

    This planet is supposed to be a vacation paradise but it’s been turned into a living hell
    by the ‘death cult’ of war and theft. And now they want to steal and control our last freedom.

    No thanks.



  9. […] said Swift, a recent post by prpl community manager Eric Schultz, which explores the question of whether the FCC can ban a new operating system, has generated significant discussion across a broad spectrum of open source […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s