Well, as a licensed radio operator of equipment that does not require type approval, I do similar things to what I am suggesting every day. The load is on me, not the manufacturer. But I am not suggesting that there be a big liability load on someone who makes an honest mistake, nor does FCC generally put fines of any size on unintentional producers of interference who rectify the problem. That is reserved for the intentional abusers. And actually, those fines are generally not large enough.
And what will they do when the FAA just plops another "critical" radar or coms system in the middle of the new WiFi (or ISM) band?
Those guys may have been there before WiFi. In general a service like WiFi is approved after they assure the regulators that they won't interfere with the incumbent users.
FAA won't put transmitters with a life-and-property duty anywhere without FCC licensing them. I doubt these radars are really operating as ISM devices, I think they have a license.
fcc.gov/ecfs . Take the two proceeding numbers from the top of my comment. Take your time to craft a well-worded response, at least introducing yourself, they don't get as much value from me-toos without any data attached. Please get it in before the deadline.
There can be any number of software developers on a WiFi driver project. I am asking that just one of them has gone through the Gordon West / W5YI book on the GROL+Radar and has taken the test. Given my personal knowledge of Open Source developers, I don't think there would be any shortage of them.
What you really need is assurance that at least one person understands how to protect the radar and has the authority to get changes in the driver. The test is just to tell FCC that such a person has some minimum level of competence.
The problem with radio is that one user's operations can block another user's. So, we need some regulation to enable us to share fairly. Think of it as a bus with a lot of bus devices belonging to different people with different goals. If you don't have a bus protocol, one device could grab all of the bandwidth, or lock others out arbitrarily.
Also, get a CB and use it. What you will meet there is what comes from FCC abdicating responsibility to regulate a radio service.
Manufacturers don't write bug-free firmware, and they don't keep it up to date. So, I did not feel that having them control "only the RF part" was a good idea. Also, splitting the RF part and the rest would introduce hardware complexity that we don't need.
I'm pretty sure my OpenWRT treats the WiFi better than what came with the router.
I really didn't want to require an entire engineering career of WiFi driver hackers, just enough that they would have a good chance of understanding the requirements.
We used to have a "First Radiotelephone" license for broadcast chief engineers. And a "Third Radiotelephone" for DJs. This seems to be what has replaced the "First Radiotelephone".
Pretty much all spectrum is shared. Sometimes, you get incompatible sharing partners. Some WiFi channels are to one side or the other of the ISM band rather than in the spectrum reserved for ISM. FCC now wants to allocate yet more of those frequencies to WiFi.
A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. -- 'Ah, so you shall be sure to be misunderstood.' -- Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood.
-- Ralph Waldo Emerson, in his famous essay Self-Reliance
Heck, it was late. I try not to mangle the English language.
Anyone who gets the Gordon West / W5YI book on the GROL+Radar. Gordy himself will probably be at Pacificon (Pacificon.org) tomorrow. Ham Radio Outlet will be there, with the book. Or of course you can buy it on Amazon:-)
OK, perhaps I misunderstood something. What you are talking about is "disclosed source code". It can be "all rights reserved" except for the rights necessary to produce incidental copies in reading an online document. It is a good idea to use it for any code that presents a risk to life or property, as it makes it possible for an external auditor to review it without going through any permission process. The counter-argument (one we've all dealt with before) is that it makes it somewhat easier to find security bugs. We unfortunately had with Heartbleed a bug that the many eyes did not find until a lot of time had went by, because it required some significant crypto knowledge. But yes, most security bugs would fall to many eyes.
You are absolutely right that many bugs that are really trivial persist for decades after being cast in concrete.
Certainly it would be more than fine if your proposal was the one that won out. I just didn't see it being all that capable of surviving opposition. Were it a perfect world, I would do nothing to enable proprietary software. But we have to work with the proprietary guys to get what we want. I didn't feel that they would view your proposal as tenable for them.
Write a reply comment in support of my comment, collect signatures (not that this is a petition process, but it might be impressive anyway), submit your reply comment by the November 9 deadline.
The problem is that manufacturers would stop giving us chip documentation. They want to sell devices, so they cooperate with FCC, since FCC can block their imports.
We're not up to making WiFi chips on our own yet. But I'd encourage you to start at that, if you have the necessary background.
We just be careful to mark test code as being test code, and point to the link for the released version. The goal is to keep the RF-naïve from deploying it. Warning them might be sufficient.
Write a reply comment endorsing it. Collect signatures, not that this is a petition process, but it might carry some weight anyway. Submit it by the reply comment deadline of November 9.
FCC staffers come and go. We have, unfortunately, lost the two we knew were hams and up-to-speed on what's happening regarding individuals and innovation rather than companies as the sole source of it. Bill Cross, staffer who wrote some of the rulemakings, is retiring or might already have done so. Riley Hollingsworth was a ham attorney there who has retired.
FCC does have an advisory board, it would not be a bad thing to get some people we know on it.
My opinion is that whoever wrote this NPRM was not sufficiently informed regarding Open Source.
I am going to ask to visit the staffers concerned (you can do that, there is a permit-but-disclose process so I would have to write up the contents of the meeting). So, I might find out more about them.
Police have a device to break car windows that they carry all of the time. Just delete "rock" and you probably get a description of what might really have happened. The sheriff came, broke out the window, and cut the perp out of his seat.
I should add one thing. Distributing the instructions which create the derivative work is tantamount to distributing the infringing derivative work. The logic above applies to all of that.
But it's combined by the user at runtime, not by canocal. The GPL allows an end users to do this.
This is a way that people kid themselves about the GPL. If the user were really porting ZFS on their own, combining the work and never distributing it, that would work. But the user isn't combining it. The Ubuntu developer is creating instructions which explicitly load the driver into the kernel. These instructions are either a link script that references the kernel, or a pre-linked dynamic module. Creating those instructions and distributing them to the user is tantamount to performing the act on the user's system, under your control rather than the user's.
To show this with an analogy, suppose you placed a bomb in the user's system which would go off when they loaded the ZFS module. But Judge, you might say, I am innocent because the victim is actually the person who set off the bomb. All I did was distribute a harmless unexploded bomb.
So, it's clear that you can perform actions that have effects later in time and at a different place that are your action rather than the user's. That is what building a dynamic module or linking scripts does.
There is also the problem that the pieces, Linux and ZFS, are probably distributed together. There is specific language in the GPL to catch that.
A lot of people don't realize what they get charged with when they violate the GPL (or any license). They don't get charged with violating the license terms. They are charged with copyright infringement, and their defense is that they have a license. So, the defense has to prove that they were in conformance with every license term.
This is another situation where I would have a pretty easy time making the programmer look bad when they are deposed.
Uh, that doesn't work. The problem is that doing exactly what you've written down is contriving to avoid your copyright responsibility by deliberately creating a structure in someone else's work which you believe would be a copyright insulator.
If you went ahead and did this (I'm not saying that you personally would be the one at Ubuntu to do so), I'd love to be there when you are deposed. Part of my business is to feed attorneys questions when they cross-examine you. I have in a similar situation made a programmer look really bad, and the parties settled as soon as they saw the deposition and my expert report.
See also my comment regarding how Oracle v. Google has changed this issue. You can't count on an API to be a copyright insulator in any context any longer.
I think you need to look at this in the context of the appeal of Oracle v. Google. We had a concept of an API being a boundary of copyright based on 17 CFR 102(b) and elucidated by Judge Walker's finding in CAI v. Altai. That stood for a long time. But Oracle v. Google essentially overturned it and we're still waiting to see what the lower court does in response.
Slashdot Mirror
Well, as a licensed radio operator of equipment that does not require type approval, I do similar things to what I am suggesting every day. The load is on me, not the manufacturer. But I am not suggesting that there be a big liability load on someone who makes an honest mistake, nor does FCC generally put fines of any size on unintentional producers of interference who rectify the problem. That is reserved for the intentional abusers. And actually, those fines are generally not large enough.
You have to study and pass the test. But it is not very hard.
Those guys may have been there before WiFi. In general a service like WiFi is approved after they assure the regulators that they won't interfere with the incumbent users.
FAA won't put transmitters with a life-and-property duty anywhere without FCC licensing them. I doubt these radars are really operating as ISM devices, I think they have a license.
fcc.gov/ecfs . Take the two proceeding numbers from the top of my comment. Take your time to craft a well-worded response, at least introducing yourself, they don't get as much value from me-toos without any data attached. Please get it in before the deadline.
There can be any number of software developers on a WiFi driver project. I am asking that just one of them has gone through the Gordon West / W5YI book on the GROL+Radar and has taken the test. Given my personal knowledge of Open Source developers, I don't think there would be any shortage of them.
What you really need is assurance that at least one person understands how to protect the radar and has the authority to get changes in the driver. The test is just to tell FCC that such a person has some minimum level of competence.
The problem with radio is that one user's operations can block another user's. So, we need some regulation to enable us to share fairly. Think of it as a bus with a lot of bus devices belonging to different people with different goals. If you don't have a bus protocol, one device could grab all of the bandwidth, or lock others out arbitrarily.
Also, get a CB and use it. What you will meet there is what comes from FCC abdicating responsibility to regulate a radio service.
Manufacturers don't write bug-free firmware, and they don't keep it up to date. So, I did not feel that having them control "only the RF part" was a good idea. Also, splitting the RF part and the rest would introduce hardware complexity that we don't need.
I'm pretty sure my OpenWRT treats the WiFi better than what came with the router.
Actually, I looke at the Fundamentals of Engineering (FE) test. It's used for patent agents, among other things.
I really didn't want to require an entire engineering career of WiFi driver hackers, just enough that they would have a good chance of understanding the requirements.
We used to have a "First Radiotelephone" license for broadcast chief engineers. And a "Third Radiotelephone" for DJs. This seems to be what has replaced the "First Radiotelephone".
Pretty much all spectrum is shared. Sometimes, you get incompatible sharing partners. Some WiFi channels are to one side or the other of the ISM band rather than in the spectrum reserved for ISM. FCC now wants to allocate yet more of those frequencies to WiFi.
-- Ralph Waldo Emerson, in his famous essay Self-Reliance
Heck, it was late. I try not to mangle the English language.
Anyone who gets the Gordon West / W5YI book on the GROL+Radar. Gordy himself will probably be at Pacificon (Pacificon.org) tomorrow. Ham Radio Outlet will be there, with the book. Or of course you can buy it on Amazon :-)
OK, perhaps I misunderstood something. What you are talking about is "disclosed source code". It can be "all rights reserved" except for the rights necessary to produce incidental copies in reading an online document. It is a good idea to use it for any code that presents a risk to life or property, as it makes it possible for an external auditor to review it without going through any permission process. The counter-argument (one we've all dealt with before) is that it makes it somewhat easier to find security bugs. We unfortunately had with Heartbleed a bug that the many eyes did not find until a lot of time had went by, because it required some significant crypto knowledge. But yes, most security bugs would fall to many eyes.
You are absolutely right that many bugs that are really trivial persist for decades after being cast in concrete.
Certainly it would be more than fine if your proposal was the one that won out. I just didn't see it being all that capable of surviving opposition. Were it a perfect world, I would do nothing to enable proprietary software. But we have to work with the proprietary guys to get what we want. I didn't feel that they would view your proposal as tenable for them.
Thanks
Bruce
Write a reply comment in support of my comment, collect signatures (not that this is a petition process, but it might be impressive anyway), submit your reply comment by the November 9 deadline.
Note that these are all WISPs with WiFi on towers, using directional antennas, and in line-of-sight of airports. Not your home users.
The problem is that manufacturers would stop giving us chip documentation. They want to sell devices, so they cooperate with FCC, since FCC can block their imports.
We're not up to making WiFi chips on our own yet. But I'd encourage you to start at that, if you have the necessary background.
We just be careful to mark test code as being test code, and point to the link for the released version. The goal is to keep the RF-naïve from deploying it. Warning them might be sufficient.
Write a reply comment endorsing it. Collect signatures, not that this is a petition process, but it might carry some weight anyway. Submit it by the reply comment deadline of November 9.
FCC staffers come and go. We have, unfortunately, lost the two we knew were hams and up-to-speed on what's happening regarding individuals and innovation rather than companies as the sole source of it. Bill Cross, staffer who wrote some of the rulemakings, is retiring or might already have done so. Riley Hollingsworth was a ham attorney there who has retired.
FCC does have an advisory board, it would not be a bad thing to get some people we know on it.
My opinion is that whoever wrote this NPRM was not sufficiently informed regarding Open Source.
I am going to ask to visit the staffers concerned (you can do that, there is a permit-but-disclose process so I would have to write up the contents of the meeting). So, I might find out more about them.
Police have a device to break car windows that they carry all of the time. Just delete "rock" and you probably get a description of what might really have happened. The sheriff came, broke out the window, and cut the perp out of his seat.
Although trespassing is one thing they could be charged with, an industrial espionage charge might work as well. It's a federal crime.
I should add one thing. Distributing the instructions which create the derivative work is tantamount to distributing the infringing derivative work. The logic above applies to all of that.
This is a way that people kid themselves about the GPL. If the user were really porting ZFS on their own, combining the work and never distributing it, that would work. But the user isn't combining it. The Ubuntu developer is creating instructions which explicitly load the driver into the kernel. These instructions are either a link script that references the kernel, or a pre-linked dynamic module. Creating those instructions and distributing them to the user is tantamount to performing the act on the user's system, under your control rather than the user's.
To show this with an analogy, suppose you placed a bomb in the user's system which would go off when they loaded the ZFS module. But Judge, you might say, I am innocent because the victim is actually the person who set off the bomb. All I did was distribute a harmless unexploded bomb.
So, it's clear that you can perform actions that have effects later in time and at a different place that are your action rather than the user's. That is what building a dynamic module or linking scripts does.
There is also the problem that the pieces, Linux and ZFS, are probably distributed together. There is specific language in the GPL to catch that.
A lot of people don't realize what they get charged with when they violate the GPL (or any license). They don't get charged with violating the license terms. They are charged with copyright infringement, and their defense is that they have a license. So, the defense has to prove that they were in conformance with every license term.
This is another situation where I would have a pretty easy time making the programmer look bad when they are deposed.
Uh, that doesn't work. The problem is that doing exactly what you've written down is contriving to avoid your copyright responsibility by deliberately creating a structure in someone else's work which you believe would be a copyright insulator. If you went ahead and did this (I'm not saying that you personally would be the one at Ubuntu to do so), I'd love to be there when you are deposed. Part of my business is to feed attorneys questions when they cross-examine you. I have in a similar situation made a programmer look really bad, and the parties settled as soon as they saw the deposition and my expert report. See also my comment regarding how Oracle v. Google has changed this issue. You can't count on an API to be a copyright insulator in any context any longer.
Linus knows absolutely nothing about law and every time he opens his mouth about it he only makes the confusion around the issue worse.
I think you need to look at this in the context of the appeal of Oracle v. Google. We had a concept of an API being a boundary of copyright based on 17 CFR 102(b) and elucidated by Judge Walker's finding in CAI v. Altai. That stood for a long time. But Oracle v. Google essentially overturned it and we're still waiting to see what the lower court does in response.