Free-software concerns with Europe's radio directive
At the 2017 Free Software Legal and Licensing Workshop (LLW), Max Mehl presented some concerns about EU radio equipment directive (RED) that was issued in 2014. The worry is that the directive will lead device makers to lock down their hardware, which will preclude users from installing alternative free software on it. The problem is reminiscent of a similar situation in the US, but that one has seemingly been resolved in favor of users—at least for now.
Mehl is a program manager at the Free Software Foundation Europe (FSFE), which is the organizer of LLW. He has been working on the RED issue, which is one of the programs at the FSFE.
The RED is not a law, but instead directs EU member countries to pass laws compatible with its contents. The intent of RED is mainly to harmonize and modernize the standards governing radio equipment and to regulate software-defined radio (SDR). There are parallels to the "router lockdown" by the US Federal Communication Commission (FCC) but, in Mehl's opinion, the problem is worse in the EU.
The "radio lockdown" part of RED is just a small piece. Article 3(3) says that "radio equipment" must be built so that it complies with a long list of requirements. One of those, 3(3)(i), is where the concerns lie:
As with many things in the field of law, the definitions of the terms are important. "Radio equipment" is defined as all devices that intentionally emit and/or receive radio waves for communication, though there are a small number of exceptions (e.g. amateur radio, marine and airborne products)—the RED only applies to new devices, however. That definition could be read to apply to a wide variety of hardware, including laptops (with WiFi and Bluetooth), smartphones, routers, GPS receivers, televisions, FM radios, and so on.
![[Max Mehl]](https://static.lwn.net/images/2017/llw-mehl-sm.jpg "Max Mehl")
The "compliance" portion of 3(3)(i) seems to say that manufacturers have to be able to prove that any software that is able to run on the hardware is in compliance with the applicable radio regulations. Those regulations include things like frequency ranges, transmission strength, purity of signal, and so on. But that piece also says that manufacturers need to implement "certain features" (which is ill-defined) to ensure that only those proven combinations can be run. That is where lockdown rears its head.
RED was adopted in April 2014, with a deadline of June 2016 for it to be implemented in national laws. At this point, Germany and other countries have not yet done so, however. June 13 of this year is supposed to be the deadline for all new devices to comply with the requirements, but that has been put on hold for now. In April, the European Commission (EC) said that the old standards can be used until the European Telecommunications Standards Institute (ETSI) finishes its harmonization and modernization work. So, right now is a transition period for the standards and for the radio lockdown part of RED; but it is only a matter of time, Mehl said, before devices will need to comply.
There are multiple actors in this particular play. ETSI is tasked with updating the standards. The EC and its DG GROW directorate are responsible for RED. The EU parliament is overseeing the work. And the EU member states are tasked with reviewing RED, implementing it, coming up with penalties for not following it, and so on.
The general idea of keeping radios from misbehaving—using frequencies or power levels that interfere with other users—may seem quite reasonable, but trying to ensure that it is not possible has a number of possibly unintended consequences. One obvious way that device makers can enforce the directive would be to only run software that is authorized for running on the device. That might use technologies like secure boot, DRM, and signed binaries to restrict what software users can install on their devices.
That would be especially bad for free-software enterprises and projects. Hardware manufacturers would somehow need to check every software package that will run on their devices. Software makers would be dependent on the hardware vendors to do those checks; those vendors could use the process to discriminate against various types of software, licenses, or companies. Free-software projects like Linux, OpenWrt, and Android could also be affected since they all work with various kinds of radio receivers and transmitters.
There are also security and privacy implications because complying with RED could add complexity and might make it impossible for privacy-friendly software to be installed. Device lifetimes would be completely at the whim of the manufacturer since users could not make their own updates or swap to something that is still being updated.
The FSFE has spent the last one and a half years working on the problem. It is trying to build an alliance with other enterprise and community actors. Part of that is the Joint Statement against Radio Lockdown that has been signed by 48 different organizations and companies.
One solution might be for the EC to define certain device classes or categories that are affected by RED such that as many devices as possible are excluded. That will take at least two to three years to happen—if it does. Several months ago, the FSFE applied to the EC to join the expert group on reconfigurable radio systems, which would assist in defining these classes or categories, but the application has not yet been answered.
There are still quite a few open questions about RED, Mehl said. The scope of devices and software is totally unclear. Linux laptops have WiFi chips (and, potentially other radio devices), does that mean new laptops cannot allow Linux to be installed? Will third-party software revisions each need to be assessed by all of the different hardware vendors? When will ETSI complete the standards update and what will that contain? How can users' and developers' rights be maintained under RED? And so on.
Mehl suggested that those interested in the issue start by talking with the FSFE. Those who support it should consider signing the joint statement. There is also a mailing list for experts to get involved with the project. Finally, supporters should also contact the EC DG GROW, ETSI, and their national authorities to further support the effort.
[I would like to thank Intel, the Linux Foundation, and Red Hat for their
travel assistance to Barcelona for LLW.]
| Index entries for this article | |
|---|---|
| Conference | Free Software Legal & Licensing Workshop/2017 |
Posted May 11, 2017 7:26 UTC (Thu)
by Adrien (guest, #82659)
[Link] (1 responses)
> June 13 of this year is supposed to be the deadline for all new devices to comply with the requirements, but that has been put on hold for now.
That is not the case at all. You will find no document from the EU stating that and in the absence of such a document, you have to assume the situation hasn't changed. Actually the Commission has answered that they were not delaying anything but not in public documents.
Similarly, the old standards cannot be used for the new directive. That has been confirmed in a "Webinar" by ETSI (which was a few days after LLW I think).
However article 3.3(i) has to be "enabled" separately by the European Commission so it's not coming into effect on June 13 (everything under 3.3 requires dedicated acts from the Commission to be enabled). It might be still possible technically but there are so many constraints that it's highly unlikely (the expert group taking months to give its conclusions being the main one).
What might happen is that the national regulators are unable to enforce anything for a while and therefore don't. That is in no way an official position from anyone. It's basically like not getting speed tickets because the new police equipment is not working.
Don't get me wrong, I'm not saying that you shouldn't care about this. Quite the contrary! This still needs to be avoided but we'll only see the effects brutally one day when the act from the Commission is passed without notice. That's the worst that could happen.
PS: please update the article with my corrections and you can check with Max. :)
Posted May 11, 2017 9:09 UTC (Thu)
by mxmehl (guest, #104271)
[Link]
> However article 3.3(i) has to be "enabled" separately by the European Commission so it's not coming into effect on June 13 (everything under 3.3 requires dedicated acts from the Commission to be enabled).
I think that's the most important correction. Even if there was a delay, 3(3)(i) wouldn't come into effect automatically as soon as ETSI finishes the relevant harmonised standards. On the one hand this gives us some time to join forces and push our comments through official and inofficial channels, on the other hand...
> Don't get me wrong, I'm not saying that you shouldn't care about this. Quite the contrary! This still needs to be avoided but we'll only see the effects brutally one day when the act from the Commission is passed without notice. That's the worst that could happen.
...it may tempt us to relax and sit back which could result in a really bad legal and technical situation for almost everyone in- and outside of the EU.
Posted May 11, 2017 16:11 UTC (Thu)
by flussence (guest, #85566)
[Link] (23 responses)
This directive's more likely to burn hardware vendors that don't upstream their code or ignore the ready-made kernel mechanisms for staying within legal limits, but they don't deserve sympathy for going down that path.
Posted May 11, 2017 19:16 UTC (Thu)
by glaubitz (subscriber, #96452)
[Link] (22 responses)
Exactly. The regulators couldn't care less what you are running on your hardware. All they want is a guarantee that people cannot modify the radio part of their equipment such that the transmitter operates outside the legal limits.
Allowing devices transmit outside the legal limit is never going to be up for discussion as the frequency band is a shared medium and proper operation for all participating services and operators can only be guaranteed if everyone respects the rules issued by the regulators.
And if there is hardware that allows sideloading of unofficial firmware which can then consequently be used to manipulate the radio part, then this hardware is illegal and needs to be taken offline.
Anyone who thinks that this is about blocking free software hasn't understood the underlying set of problems at all.
Adrian
Posted May 11, 2017 19:58 UTC (Thu)
by zlynx (guest, #2285)
[Link] (3 responses)
The law isn't actually that stupid is it? That would make microwave ovens illegal. Because you can jam the door sensor and run it with the door open, instantly hashing the 2.5 GHz band.
Manufacturers shouldn't be responsible for people doing stupid hacks.
Posted May 11, 2017 22:07 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
The law mandates this safety feature for all microwaves.
Posted May 12, 2017 3:14 UTC (Fri)
by dps (guest, #5725)
[Link]
A DVD rewriter is a class 1 laser device, which is completely safe, because the beam is confined within the DVD device and you don't need any door interlocks to own or use ir. There are almost certainly few impediments to you removing the covers and misusing the class 3b laser to damage yout eyes. You can damage your eyes with class 2 lasers too but that requires special effort.
I would think is it not unreasonable to ask manifacturers not to provide otions to violate the spectrum refulations out the box. Those using unofficial firwmare should definitely be resposnvble for enusring they sollow the rules.
Posted May 15, 2017 11:18 UTC (Mon)
by mxmehl (guest, #104271)
[Link]
The incentives are good (make sure that the radio band is free from interferences) but the means are disproportionate and tackle the problem at the wrong end.
> Manufacturers shouldn't be responsible for people doing stupid hacks.
But RED's 3.3(i) is actually doing that. Manufacturers shall prevent users to do illegal things by locking down software access – while actually max. 0.5% of users intent to do stupid things. And those who really want to tweak their radio parameters in illegal ways will be able to circumvent this easily.
Posted May 11, 2017 20:18 UTC (Thu)
by zoobab (guest, #9945)
[Link] (2 responses)
Then good luck with any cheap SDR radio coming now.
This FCC/Radio directive comes from some European committee that wanted to solve the 5ghz weather radar and DFS problem, where we ended up locking ANY radio firmware for ANY frequency, even 2.4GHz.
And wifi manufacturers are not locking down the whole firmware, because it is cheaper.
Posted May 12, 2017 7:32 UTC (Fri)
by Adrien (guest, #82659)
[Link]
Do you have more details about the origin of the FCC directive? Tracing the thing back to its root is very valuable. The further we got is early 2010s but the document isn't explicit about any issue. Knowing the root needs will help avoid getting the article being applied for something completely different.
Posted May 15, 2017 21:56 UTC (Mon)
by glaubitz (subscriber, #96452)
[Link]
Well, you are always free to challenge your local regulators agency. They have the equipment to trace down illegal senders and if they catch you, it can be expensive, very expensive, up to six figures in fines. I seriously wouldn't try to challenge the FCC or any of their international counterparts.
> This FCC/Radio directive comes from some European committee that wanted to solve the 5ghz weather radar and DFS problem, where we ended up locking ANY radio firmware for ANY frequency, even 2.4GHz.
No, it was the manufacturers who locked up the firmware.
> And wifi manufacturers are not locking down the whole firmware, because it is cheaper.
Actually, they are locking down the whole firmware because it *is* cheaper than adding an additional mechanism to lock the radio part.
Manufacturers have the problem that the allowable frequency spectrum varies by region which means they would have to manufacture different hardware components for every region. In order to reduce costs, they just shift this variation into software and lock out the firmware to make sure people cannot switch the radio part arbitrarily to a different country.
Whether the locking down is very efficient or can be easily worked around with hacks is a different story though.
Adrian
Posted May 12, 2017 7:35 UTC (Fri)
by Adrien (guest, #82659)
[Link] (14 responses)
We fully agree that the issues are when end-users misconfigure their device. There shouldn't be a presumption that they will however (and remember that it could already be the case but it basically never happens).
Posted May 12, 2017 20:59 UTC (Fri)
by rahvin (guest, #16953)
[Link] (13 responses)
I'm all for open access but the vast majority of people have no factual understanding of any of these parameters. They see an input box in their firmware that allows them to boost their wifi power so they can get a signal further out and a whole lot of people will do it even if it violates the agency approval. The person doing it has no idea that doing so can cause Doppler effects in other bands and potentially cause enough interference to cause real problems. If you asked your average retail wifi owner if they thought that little box by the computer could disrupt some critical service they would think you were pulling their leg or outright lying.
The easiest way to solve this for devices that basically every household owns but doesn't understand at all is to lock the radio down so it can't operate outside it's approved power limits and bands. Unfortunately we're probably going to have to live with that solution as it guarantees compliance whereas more flexible solutions cannot guarantee that someone won't figure out how to tweak the radio and distribute that tweak to the public. Personally I don't have a problem with this as long as the locks are in hardware or dipswitches on the board rather than software locks. Unfortunately most OEM's just take the easy way out and use signed kernels or propriety firmware's that block freedom.
Posted May 12, 2017 21:45 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (5 responses)
In my version of the world this is a non-goal, creating the restrictive devices that can make guarantees and putting the liability on the manufacturer seems unnecessary and foolish, while the manufacturer shouldn't present some obvious setting to the user that takes the device out of compliance, if the end user goes out of their way to modify the device to take it out of compliance that should be the liability of the user, not the manufacturer, which means that there is little incentive for the manufacturer to invest in lock-down technology.
Posted May 15, 2017 22:10 UTC (Mon)
by glaubitz (subscriber, #96452)
[Link] (1 responses)
No, it isn't foolish at all. The manufacturer has the necessary training to know regulations and the law. The normal end user usually doesn't.
End users can acquire the proper qualifications through an amateur radio license though. Then legislators actually do allow end users to design, set up and operate their own equipment. They are still expected to respect the limits of the frequency spectrum though. Otherwise it can be very expensive.
> while the manufacturer shouldn't present some obvious setting to the user that takes the device out of compliance, if the end user goes out of their way to modify the device to take it out of compliance that should be the liability of the user, not the manufacturer, which means that there is little incentive for the manufacturer to invest in lock-down technology.
No, I'm sorry, but that's basically a thought-terminating cliché. It's like saying "We don't need speed limits with fines attached to them, because there will still be people who will break the law and ignore the limit."
That's not the point at all that legislators and regulators have in mind. The idea is to make it as difficult as possible to modify the radio device in a way that it can be operated outside the spectrum. There are various ways to prevent that.
Of course, there will still be people who will be able to overcome these lock downs. But since this usually requires advanced technical skills, the number of users who will be able to do that is limited. For example, if you have to modify the hardware and replace parts to tune the radio part, it requires much more work to circumvent the lock down as compared to if the manufacturer allowed tuning by simply setting some values in the software.
Again, legislators and regulators are fully aware that they cannot protect against malicious users with 100% efficiency. But if they, let's say, achieve 75% efficiency, it's still much better than 10% efficiency. The remaining users that are willing to break the law will be traced down by the engineers at FCC when they roam around with their measurement equipment and punish violators with high fines.
The whole discussion isn't new and regulators aren't naive. The problem to keep the spectrum clean has existed for decades. The only thing that changed is that often the manipulation of the radio part can now be done in software as compared to older, analogue transmitters. Thus, legislators and regulators consequently adapted the laws to cover software modification as well.
Adrian
Posted May 18, 2017 8:14 UTC (Thu)
by oldtomas (guest, #72579)
[Link]
Ahem. Actually, it's the driver who pays the fine, not the car manufacturer. So you seem to agree with raven on this?
Posted May 16, 2017 9:52 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
The trick then is to make it hard for the end user to modify the device outside compliance, such that if they do so, it's tamper-evident.
For example, current UNECE rules for speedometers say that a car can only be type-approved under UNECE rules if the speedometer cannot underread (claim that you're travelling at 29 kph when you're in fact travelling at 30 kph) with any tyres that physically fit in the wheel arches, and sets limits on the maximum overread if you're using manufacturer approved wheel and tyre combinations (IIRC, 10% plus 10 kph overread is permitted, so a car travelling at 50 kph can have a speedometer reading of 65 kph).
For a router, similar might require you to break part of the router case, then remove a screw and unsolder a connection. You've now done enough physical alteration of the device that it's evident that it's been changed, and therefore not the manufacturer's fault if it isn't RF-compliant.
Posted May 17, 2017 3:25 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted May 17, 2017 8:37 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Yep - and my described solution is basically "to disable the signed firmware requirement, break off this bit of plastic moulding. Undo the screw that's now exposed (and will be clearly visible to future buyers of the device, with scary words around it), and you can solder on a jump lead that disables signing and enters developer mode.
That puts it comparable to the car scenario - you have to do the equivalent of the metal bashing you have to do to make your speedo underread in order to enter developer mode, and the fact that you've done obvious physical damage to get there means that the manufacturer can argue that you knew what you were doing.
Posted May 12, 2017 22:19 UTC (Fri)
by pizza (subscriber, #46)
[Link] (5 responses)
I'm typing this communicating through a completely-stock access point, purchased within the US, that allows itself to be configured outside "legal" parameters -- Uts UI allows the user to specify which country it's operating within, which means means I can easily configure it to go outside the US 2.4GHz ISM band, and the bits of the 5GHz ISM band that are off-limits in the US.
That said, even if I limit myself to "FCC" frequencies, I can also specifically instruct this device to exceed legal output power limitations on the 5GHz side of things -- certain sub-bands have different indoor/outdoor power restrictions, and the device itself has no way of knowing where it's actually deployed. Or what kind of antenna you've connected to the device. It's the user's responsibility to know what combinations are legal and properly configure an appropriate power limit, and that holds whether or not the radio control functionality is locked down or not.
(Incidently, the overwhelming majority of the devices supported by DD-WRT are physically incapable of exceeding in-band output power limitations, though the sidelobes if pushed to hardware limits might barely violate out-of-band limits. And at that jacked-up power level you're likely to have ruined your ability to actually communicate with the AP anyway)
Posted May 15, 2017 21:43 UTC (Mon)
by davecb (subscriber, #1574)
[Link] (4 responses)
Posted May 15, 2017 21:49 UTC (Mon)
by glaubitz (subscriber, #96452)
[Link] (3 responses)
No, that's not how radio regulations work in most countries. Most legislators put the burden to lock the device on the manufacturer because they do not trust end users without the proper training.
Legislators do allow end users to take over responsibility for operating a radio safely with full access to the radio parameters if they have an amateur radio license, however.
Adrian
Posted May 15, 2017 21:56 UTC (Mon)
by davecb (subscriber, #1574)
[Link] (2 responses)
Posted May 15, 2017 22:17 UTC (Mon)
by glaubitz (subscriber, #96452)
[Link] (1 responses)
Of course it is. It's one of the basic ideas of becoming a ham.
From [1]:
> B-001-005-002.... The holder of an Amateur Radio Operator Certificate may design and build from scratch transmitting equipment for use in the amateur radio service provided that person has the:
For Canada [2]:
> Basic Qualification: an examination of 100 questions.
I'm a fully licensed hamradio operator myself (class A German license).
Adrian
> [1] https://www.hamstudy.com/freebasic/b-001-5.html
Posted May 15, 2017 23:35 UTC (Mon)
by davecb (subscriber, #1574)
[Link]
In Canada, everyone is required to obey the law[1], but only licensed people can build their own equipment, because they have demonstrated the ability to obey the law, by passing the appropriate exams.
I was making the point that *everyone* must obey the law: I read you as saying that hams have more priveledges, based on their *demonstrated expertise*, while manufacturers must limit their (unlicensed) customers' capabilities.
--dave
Posted May 13, 2017 16:21 UTC (Sat)
by Adrien (guest, #82659)
[Link]
But the regulators themselves say that these issues do not happen. There is absolutely no reason to add such restrictions.
And this only applies to devices sold in the EU. Not the ones brought across the border by individuals.
So:
Posted May 11, 2017 21:50 UTC (Thu)
by fratti (guest, #105722)
[Link] (1 responses)
Posted May 13, 2017 16:22 UTC (Sat)
by Adrien (guest, #82659)
[Link]
Posted May 18, 2017 8:59 UTC (Thu)
by callegar (guest, #16148)
[Link] (4 responses)
Posted May 18, 2017 9:33 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (3 responses)
Client devices (laptops, phones etc) and "server" devices (access points, eNodeBs etc) have different requirements here.
A client device can passively listen on a channel for a server device that's broadcasting, and thus can start by only transmitting on the global common subset of channels, but expands its channel set as and when it hears a server device broadcasting either a signal on a "forbidden" channel, or a regulatory permit on an allowed channel. E.g. my laptop will, by default, only transmit on 2.4 GHz channels 1 to 11 and 5 GHz channels 36, 40, 44, and 48. Everything else is forbidden by default. When I connect to my workplace WiFi network, however, it picks up a suitable "country IE" which tells it that it's in the UK and that the access point (AP) supports TPC and DFS operation - and I can then use the AP on channel 136 because my WiFi card "opens up" its regulatory limits to match those of the AP it saw either in a passive (receive-only) scan of channels that aren't allowed globally, or because it saw the country IE on channels 1 to 11 or 36, 40, 44 and 48. Locking these devices down is thus not challenging - the hardware can detect that it's receiving a beacon frame, and pull out the country IE to check for allowed channels fairly easily, and otherwise stay on tight lockdown.
Server devices like APs are in a different position - they tell clients what's allowed, and can't rely on there being another server device around to tell them what's locally allowed. These are the devices that need to be locked down hard to comply with the regulation, so that it's clear when I've tampered with it to make it run outside its legal boundaries - you want one hardware design that you can sell globally, but you also want it to be obvious when a user has tampered with it to (e.g.) run a US regulatory domain in the EU. Fortunately, these are also the devices that people rarely take with them, and the ones that people do commonly carry with them are things that are also client devices (WiFi APs that use a mobile network for backhaul, for example) and can rely on the client behaviour to determine what channels they're allowed to use.
Posted May 18, 2017 10:24 UTC (Thu)
by callegar (guest, #16148)
[Link] (2 responses)
Are there really client and server devices? I would say that wifi on mobile phones are quite often (particularly abroad, where it is easy to get a local sim) used as APs for tethering. And laptops do occasionally put up ad hoc networks.
Furthermore, it is not really true that servers are the devices that people rarely take with them. There are tons of "portable" boxes to do 3G/4G -> Wifi that people regularly travel with (in fact they are mainly made for travelers). Even for less portable stuff, I have just checked and the AP I am currently connected to (in the EU) is a US model (probably cheaper than the almost identical EU counterpart). I wonder how many of these are around in the EU.
I also wonder if it is enough to have a country locked (unconfigurable) AP in the wrong country with open wifi with a captive portal to make all the laptops and mobile phones that see it open up to an incorrect regulatory domain?
Posted May 18, 2017 10:30 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Most of the devices you name are both client and server devices in one both (e.g. WiFi on a mobile phone), and can use their client-side knowledge to determine what they can do server side.
Plus, on clients, you default restrict to the lowest common denominator - e.g. transmit only on 20 MHz width only, 2.4 GHz channels 1 to 11 only (even though 12 and 13 are usable here), only channels 36, 40, 44 and 48 on 5 GHz, power limits to the lowest allowed globally without authorisation from the "server" device. On "server" devices, such as APs, these restrictions are unacceptable - APs with local regulatory domains are able to use more power, wider bandwidth, and more channels, making your product fail in the market.
And yes, running an illegal AP will make clients also act illegally (tested in controlled circumstances). But as soon as the illegal AP is taken down, the clients resume legal operation.
Posted May 18, 2017 11:25 UTC (Thu)
by excors (subscriber, #95769)
[Link]
Phones can find out which country they're in from static data stored on the SIM, or from nearby cell towers, or possibly from GPS, etc, and configure the wifi device based on that.
June 13 still is the deadline but 3.3(i) will come into effect later on
June 13 still is the deadline but 3.3(i) will come into effect later on
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
>
> *Advanced qualification*
> Basic and Morse code qualification
> Morse code withe Honours qualification
> Basic qualification
>
> access all amateur bands above 30 MHz
> use a maximum of 250 watts DC transmitter input power
> build and operate all station equipment, except for "home-made" transmitters
> Basic with honours (80% or above score) - access to all amateur bands below 30 MHz
> There is no Morse code requirement on this test.
>
> Advanced Qualification: an examination of 50 questions.
>
> access all amateur bands below 30 MHz
> use maximum transmitter power of 1000 watts DC input
> build and operate transmitting equipment
> establish repeaters and club stations
> remotely control fixed stations, including the use of radio links
> There is no Morse code requirement on this test.
> [2] http://www.eham.net/newham/howtobecome
Free-software concerns with Europe's radio directive
[1. For excample, the minister may "issue orders to persons in possession or control of radio apparatus, interference-causing equipment or radio-sensitive equipment that the Minister determines to be responsible for the harmful interference", to cease their unlawful linterference https://www.canlii.org/en/ca/laws/stat/rsc-1985-c-r-2/lat... at 5(1)l]
Free-software concerns with Europe's radio directive
- no reason strong enough for such a lock-down
- not an issue in practice
- no attempt to actually prevent possible issues anyway
Usefulness of Europe's radio directive
Usefulness of Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive
Free-software concerns with Europe's radio directive