You could tell all the potential students about how IT is a long term stable career with good pay. That might get them interested. Of course, you'd be lying if you said that.
Yes, IT is improving. But it is still nowhere near where it was in the dot-com boom, or even in years leading up to that. A large percentage of older workers are still unemployed (in IT) for various reasons. And this is important to smart newcomers because that can see that as things change in the technology, they could end up being left out because someone assumes they can't continue learning and doing new things as the changes happen.
You see, it is the business managers that have the wrong perceptions about people, and assume that people cannot learn new things once past college. If someone learns Java today in college, where will they be when something new comes along and the usage of Java begins to decline? Companies will be hiring the future graduates that know the new language (despite lack of real world experience) and ignoring the experienced professionals under the assumption they can't learn a new language.
Many of your potential students are well aware that the IT career lifetime is shorter than the time between graduation and retirement. Instead of pitching IT as a career to students, you should be pitching this to business. It is business that, by treating IT workers as a commodity to be bought at the lowest price, has burned their own bridge.
Then what the manufacturer should do is implement their buggy logic in firmware than can be loaded into the hardware by a means that an open source driver can perform (and also one that does not require an existant firmware to be present to accomplish firmware loading).
If the hardware manufacturers want to include the growing Linux market, which in great part is there because of the security aspect of Linux, which is ruined by having binary drivers, then they need to bite the bullet and do things the right way... the Linux way. That's what it's about. Trying to turn Linux into another Windows is the wrong way.
One major reason I avoid Windows is to avoid this binary driver malarky. I sure as hell don't want to see this move into Linux. If it does, then I guess I have to move on to BSD or something.
As for the winmodem thing, I don't know that Microsoft specifically encouraged it directly. But they certainly have encouraged binary only drivers. And they are most likely happy to see anything that only works on Windows.
The lower cost hardware comes with a higher cost in terms of using CPU resources for what should have been hardware accelerator resources. You don't see high end graphics card manufacturers trying to move their graphics accelerators into the CPU.
Why support distributions when what is needed for that support is either actual drivers (open source), or technical information to allow kernel developers to write the drivers. Instead, this "support" should be specifically targeting "The Linux Kernel". Then supplementary support can be provided to retractively install those drivers in distributions containing older kernel versions that don't include the drivers. Genuine "Linux Support" would mean doing whatever is necessary so that a future kernel version will correctly function with the targeted hardware. Likewise, similar support should also be provided for all the BSDs (even if just supplying the info to let the developers create the necessary code).
It is not carving into stone if the next version of the hardware can do newer more innovative things. What carving into stone would mean is that no new innovations are allowed in even the next version of the hardware. But there is no real reason to have such limitations. For example a TV video output card could accept MPEG-2 in its first version, then accept both MPEG-2 and MPEG-4 in its second version. No driver change should even be needed for that. And certainly do even think of putting the MPEG decoding in the driver.
I really do understand their position. I just think they are wrong. If they hadn't gotten themselves into this rut of backwards thinking in the first place by having worked on Microsoft (and other) products that encourage both closed source and embedding in software drivers that which should be in hardware, then we wouldn't even have had this Slashdot article in the first place. Instead, we'd have more interesting and more innovative hardware, and a lot fewer bugs (even in Windows).
And there's no assurance the driver interface hasn't changed between any one of them and the next.
But there's no assurance that the driver interface has changed. What I'm referring to is the actual history of the changes, not what the most extreme possibility is.
There are extremes. On the left hand some people might want to make interface changes at any time. On the right hand other people want the interface to never be changed. I think the kernel team is doing something pretty close to a fair compromise by not carving it into stone in a way that limits the ability for Linux to evolve and improve, but also not making such changes too often, either (that does mean a lot more work for others in the team, too).
There could be some things that driver writers are using that perhaps shouldn't be used in a driver, and changes done there are not considering the impact on drivers (and shouldn't). We really can't tell for sure if those driver writers are releasing only binary. This is yet more reason to always have drivers in source code that can be compiled and linked to make an actual driver.
I still don't buy the intellectual property issue regarding drivers. If they want the kernel to use standard interfaces, then maybe they should try using standard interfaces at the hardware level and stop using proprietary designs to try to lock people in their drivers. They should put all their innovation inside the hardware itself and to the extent possible use an existing standard interface to access that hardware. If there are new features (which should be selling points for the hardware, and not kept secret) that need special communications for the applications to configure how they are used, then perhaps something added on at the driver would be needed to communicate what parameters are to be passed to the hardware and what status to be passed back. Again, there is no reason for secrecy in the driver, and no reason not to release the source code. There is plenty of reason to do so because that just increases the poetntial market among Linux users.
If companies that keep their drivers in closed binary form are finding that their hardware is not being used by very many people in the Linux community, maybe it is because of that closed binary driver. I know that's a big reason for me to dismiss ever buying that hardware. Another reason is the use of non-standard hardware interfaces.
A source based distribution would be the other extreme. I don't think I need to go that far to achieve my basic goals. I don't anticipate a need to modify most small things. OTOH, there would be some substantial comfort from a full source build.
One can have a higher confidence in future source availability with something in GPL like Linux, than even with a vendor giving their source for other reasons (e.g. as IBM did with early VM/CMS systems).
BTW, I'm using Slackware as my base distribution (just now upgrading to 10.2). I build a starter system in a directory and chroot in to recompile lots of stuff from source, building a Slackware package of each as I do it. Then I redo the install (again, into a directory) but with my own packages substituted. Finally, I use rsync replication to really install to other machines (though I could use the mix of Slackware and my own binary packages to do the install).
Certainly those languages leave a lot of room for "something better". But what particular criteria would make a language better? I suspect not everyone will rank these criteria the same way (hence we get so many languages). For example, I happen to like the C syntax and that means I find Pike a good choice. Still, even Pike has room to be improved on. I happen to not like C++ at all.
So, what would it take to satisfy your criteria on being a proper successor to C++, if none of C#, Java, Pike, Python, and many others are unable to qualify?
You mean SuSE, Mandriva, Fedora, and Slackware have been modifying the driver APIs? OMG! I was not aware of this. I'll have to switch to Debian where I can get a pure unmodified Linux kernel which really don't change the API all that much.
Well, at least Windows has been using the same API for all its drivers since the Version 2.0 release (the first one I ever used on an Intel 80286). Yeah, right.
BTW, actually I'm not really affected by the distribution I use, since I download pristine kernel sources and compile it using a gcc that recompiled itself 3 times. I also leave out module support for security reasons, and so only drivers that come in the kernel, or that I can add at the source level, ever get used. If I can't see what it's doing, it isn't going to be doing anything on my machines. That means not using binary drivers, whether closed source or not. If you also give me source code for a driver that is in binary, how the hell am I to know you really compiled that binary from that source?
Long ago, back in the dark ages, when I worked on IBM mainframe computers, I administered several systems in which everything was re-assembled (source was in System/370 Assembler Language) from source. I had actually encountered a few cases where the binary that was distributed did not match the source. By running from source rather than binary, I knew there would be no surprises if I ever had to modify the source code (and that happened numerous times... the modifying). I continue that practice even today under Linux, by recompiling the kernel and all mission critical applications (e.g. the ones actually doing the services I might ever need to modify to correct security problems or customize the bugs and features).
Why would they not face a similar problem with Windows? Or does every version of Windows since 95 have exactly the same driver API?
I think the real problem is the manufacturers don't want to put the effort into Linux drivers. And this is made worse by having proprietary hardware-software interfaces, instead of making something simple at the interface, and putting their intellectual innovations in just the hardware.
1. We make software that allows you to keep an eye on your children while they are on the internet.
It can also be put to use in other ways. It could be installed by one spouse to spy on another. It could be installed in offices to spy on coworkers, the boss, or for civil espionage. How do you make sure only parents of children can install it only on the computers their children use? These are situations where the need to be able to detect any form of spyware, not matter what the design intention is, is real.
It won't detect kids who boot a Linux or BSD CD such as Knoppix.
2. Some anti-virus software blacklisted our software.
Don't you mean anti-spyware software? Don't you mean they merely detect and report (and maybe optionally remove)? Blacklisting doesn't enter into this.
3. We state that they are not allowed to download our software in an attempt to stop them blacklisting us
Again, it's not a blacklisting issue. If your EULA only expressed "blacklisting", you've already lost your case.
4. They carry on doing so, ignoring our warning they they are expressly forbidden from downloading our software - it is our copyright.
It might have been downloaded by someone else, first, who intended to use it either for good or evil, and then your software was discovered by a security expert upon inspection of a malfunctioning computer system. It may be that the software was installed by someone who had inappropriate access to the machine (a neighbor kid, for example) and the owner brings the malfunctioning machine to the experts who discover many spyware programs that the owner never installed.
5. They ignore our attempts to contact them
Given how you seem to be twisting things, I would ignore you, too, unless and until you decide to really pursue a genuine legal case.
6. So we consider going to the police to stop them downloading our program without permission.
Since the EULA you claim they violated makes it a violation of contract, not a violation of a specific criminal statute, this would be a civil case, not a criminal one.
7. We get flamed by a load of people who don't seem to understand the situation!
There seems to be a lot that you don't understand.
Why are we sleazy?
1. You are making a tool that could be readily abused in a very broad way.
2. You are hinting at pursuing a case that could establish a defense usable by software makers with even less honorable, and less naive, intentions.
Maybe they never downloaded it in the first place. Maybe they are acting on the basis of experience that is typically gathered by a practitioner of the field who also works to diagnose malfunctions in client computers where previous detection efforts have failed. This would not necessarily mean your software caused any such problems, but rather, your software may have co-existed on a machine with previously undetected malware which was also performing similar spying actitivies, although for malicious intentions. On the basis of these activities, they would never have agreed to your EULA in the first place as they would never have downloaded a copy of the software.
The ability to detect software like yours, which presumably has no ill-intent, is still necessary, IMHO, because of the existant possibility of ill-intended installation by other parties, such as kids spying on their parents first (it happens), or one spouse spying on the other in domestic issue civil cases (it happens a lot). Unless you can prove that your software has unbreakable facilities that prevent anyone from installing the software except in cases where it would involve only legal spying (e.g. parents spying on kids), I don't think you have a valid basis for demanding that your software be exempted. And I do not see how the software is capable of evaluating the domestic role of the person doing the installation.
My real concern has nothing to do with your software. It has everything to do with all spyware in general, and the establishment of legal defenses that they all may use if you take this matter to court and prevail. Such a ruling would be universally harmful to everyone.
In an unrelated issue, how is your software going to spy on kids that are skipping Windows and booting up a Knoppix CD instead to get to the internet to surf for 7un3z, w4r3z, and pr0n? You know kids are doing it, and not just the smart ones. Do you warn parents that your software cannot detect all these cases?
The following scenario may be more defendable in court. I am not a lawyer, nor do I have a briefcase or fins, so I cannot advise whether this could actually work. The scenario goes like this:
Someone who did download the spyware software is having problems with their computer. That spyware software may, or may not, have anything to do with the problem. They bring their computer to you to diagnose. You do the diagnosis and discover numerous programs present that are performing unexpected activities that appear to be spying. You notice specific signatures about these programs in order to detect if they are present. You implement spyware detection software that can recognize each of these programs. You have never agreed to any EULA from any of these spyware companies.
The legal issues that can still be present include that you may still be attached to the obligations of the owner of the computer, since they cannot pass on to you any rights to do beyond what the EULA specifies is not passed on to them in the first place, and include that the very signature may somehow be considered a copyright violation, even if it is a cryptographically strong checksum.
I would be more inclined to buy their router if they made it an open platform that would also let me run programs I write (using an external cross platform development kit consisting entirely of free open source software such as gcc, etc). I think a lot of people would end up preferring such models of things (routers, switches, modems, radios, TV sets, DVD players, etc) if they could program on it, or run downloaded free open source programs that other people write and make available online. I'd even pay extra to get extra memory capacity on such models to have the room to run more processes. Make it Linux or BSD based and I'm happy. Obviously Linksys is blind to our tiny little market of hackers.
Of course the RIAA and MPAA would have a fit if it involved things that could open their content. But hey, let's do things to help keep their lawyers busy.
My big reason to switch to exclusively IPv6 for at least my mail servers is that the spammers and their zombies won't be doing any IPv6 for a long time. I just have to wait until most of the places I want to exchange mail with at least have IPv6 in addition to any IPv4. That should give me a few years of nearly zero spam.
Let's see here. Manufacturers want us to create a kernel than allows them to infect and interfere with its integrity, reliability, performance, and security, just so they don't have to keep maintaining that driver as the design of the kernel continues to be improved? They want us to stagnate the design of the kernel so they can let us use their stagnant device drivers? And they want us to have a system that is no longer viably supported by staff or consultants, while they are most likely not ever going to provide system support (if they can't keep the driver maintained, how the hell are they going to provide support for an old driver)?
Why do you even need to develop a special driver, anyway?
Why would the features vary between one driver (for Windows) and another (for Linux)? Aren't you trying to sell hardware?
OK, let's say that you have some reason to do so. If you make the driver open source, and if that driver gets adopted into the Linux kernel tree, that puts your hardware at a market advantage because at that point it can "just work" with any Linux system with that version of kernel or later. Then when the ABI does change (as it may need to in the future), it gets maintained for you in the kernel development process (which you could also participate in to help ensure the driver for your hardware continues to work effectively).
I don't know even what kind of hardware device this is that your employer makes and that you write drivers for. If I did know, I could know whether it was some really special kind of device that needs a unique driver, or if it is some general kind of device that perhaps you should use a generic driver for (and put all your smart advanced features in the firmware on the device, running on that device's own CPU, instead of running in the host CPU).
BTW, isolating an environment for securely running device drivers is fundamentally going to be difficult. The driver needs to access the device, and if you have to create an abstraction to that, you are also creating a performance hurdle since every access has to be requested through the kernel and verified as to permission (e.g. so the driver cannot access other devices or memory structures or processes, etc). Drivers work better when they are trusted to do the right things and don't have to be watched over all the time. They work faster if they can access the device with direct memory references instead of having to run through dozens or hundreds of kernel core instructions for each access.
So tell me what this device is that I may tell you the way a driver really needs to be done for it.
As someone who has tried to install various Linux distributions on RAID cards, and has had difficulty getting installers to use even third-party open-source drivers*, I'd love a binary driver API.
And how would this have been any easier if the driver were closed source?
At least with an open source (and GPL) driver, the opportunity to roll it into the main kernel tree exists. Then it should be rather easy to get it enabled and installed under various distributions, as well as making a solid kernel with that driver compiled and linked in. You get no such advantage with closed source drivers. And there is no guarantee that the driver maker's installation tool will even work right in all distributions that use the same common Linux kernel.
I have had occaisional problems like you describe. Building a custom kernel with the drivers compiled in (not as modules) always solved them.
The real problem is this need to have unique drivers for every instance of hardware. Part of that problem is that manufacturers keep wanting to put their code in the host system for various reason. One common reason is to use the host CPU for work they are too cheap to do in the device they are selling. And another that has come out is their desire to access the host system itself (and something in the kernel involves a huge amount of access).
This practice is bad because it compromises the integrity, reliability, performance, and security of host systems.
What is really needed is a standard way of accessing hardware devices so there is no need to have unique drivers for each device. And for many devices, such as disk drives, that already exists. This just needs to be extended so that it works for all general and common devices. The only time a new device should need its own driver is when it is so uniquely new, that there is no analogy to what it does in existing devices (e.g. it would also need a new device file name in the/dev directory as well).
If you actually want to let various hardware manufacturers to have control of code that runs in the kernel layer of your computer, or even in the root permitted process layer, then you don't really deserve Linux, and should stay away from it. One of the big advantages of Linux is the very fact that everything that runs with indefinite permission or indefinite credentials is open for inspection, and where necessary, modification. That doesn't mean you personally (or even any of your staff if you are a business) have to even have the skills to do this... you gain an advantage just from the community eyes doing this inspection independently.
The manufacturers should simply use standard drivers for devices. Every device that a normal common laptop computer needs already has many existant, working, and generally very well debugged, drivers in the open source kernel tree. They need to just make their hardware work with those drivers as is. Tell me what kind of device can't follow along with that requirement and can't establish a new software to hardware interface open standard where existing interfaces are inadequate.
Put yourself in the position of being a manufacturer of a hardware device that wants to have a closed source driver. There, now you look really stupid. So, tell me, what is wrong with this hardware device that requires a closed source driver? Are you just secretly trying to get the host CPU to do the work that the hardware should be doing instead?
If you have any intellectual property you need to protect, such as proprietary (de)compression or other processing algorithms, or any (de)encryption keys, or anything else like that, those should be put in the hardware itself (or in the firmware running that hardware's internal CPU). Don't try to offload work, especially if that work involves any intellectual property protected processes, onto the CPU.
There needs to be a definitive boundary between the product, and the user of that product, and that boundary should absolutely not be inside the host CPU itself. That boundary should be the layer between the existing system, and the product purchased to add on to it.
Drivers really should do no more than provide a means to communicate between the kernel (usually the I/O parts) and the hardware. If you have some nifty invention that makes things work better that warrants the development and marketing of this device, then put that invention inside the device itself. Don't screw with the integrity, reliability, performance, and the security of my system (and kernel) for this.
Slashdot Mirror
You could tell all the potential students about how IT is a long term stable career with good pay. That might get them interested. Of course, you'd be lying if you said that.
Yes, IT is improving. But it is still nowhere near where it was in the dot-com boom, or even in years leading up to that. A large percentage of older workers are still unemployed (in IT) for various reasons. And this is important to smart newcomers because that can see that as things change in the technology, they could end up being left out because someone assumes they can't continue learning and doing new things as the changes happen.
You see, it is the business managers that have the wrong perceptions about people, and assume that people cannot learn new things once past college. If someone learns Java today in college, where will they be when something new comes along and the usage of Java begins to decline? Companies will be hiring the future graduates that know the new language (despite lack of real world experience) and ignoring the experienced professionals under the assumption they can't learn a new language.
Many of your potential students are well aware that the IT career lifetime is shorter than the time between graduation and retirement. Instead of pitching IT as a career to students, you should be pitching this to business. It is business that, by treating IT workers as a commodity to be bought at the lowest price, has burned their own bridge.
Then what the manufacturer should do is implement their buggy logic in firmware than can be loaded into the hardware by a means that an open source driver can perform (and also one that does not require an existant firmware to be present to accomplish firmware loading).
If the hardware manufacturers want to include the growing Linux market, which in great part is there because of the security aspect of Linux, which is ruined by having binary drivers, then they need to bite the bullet and do things the right way ... the Linux way. That's what it's about. Trying to turn Linux into another Windows is the wrong way.
One major reason I avoid Windows is to avoid this binary driver malarky. I sure as hell don't want to see this move into Linux. If it does, then I guess I have to move on to BSD or something.
As for the winmodem thing, I don't know that Microsoft specifically encouraged it directly. But they certainly have encouraged binary only drivers. And they are most likely happy to see anything that only works on Windows.
The lower cost hardware comes with a higher cost in terms of using CPU resources for what should have been hardware accelerator resources. You don't see high end graphics card manufacturers trying to move their graphics accelerators into the CPU.
Why support distributions when what is needed for that support is either actual drivers (open source), or technical information to allow kernel developers to write the drivers. Instead, this "support" should be specifically targeting "The Linux Kernel". Then supplementary support can be provided to retractively install those drivers in distributions containing older kernel versions that don't include the drivers. Genuine "Linux Support" would mean doing whatever is necessary so that a future kernel version will correctly function with the targeted hardware. Likewise, similar support should also be provided for all the BSDs (even if just supplying the info to let the developers create the necessary code).
It is not carving into stone if the next version of the hardware can do newer more innovative things. What carving into stone would mean is that no new innovations are allowed in even the next version of the hardware. But there is no real reason to have such limitations. For example a TV video output card could accept MPEG-2 in its first version, then accept both MPEG-2 and MPEG-4 in its second version. No driver change should even be needed for that. And certainly do even think of putting the MPEG decoding in the driver.
I really do understand their position. I just think they are wrong. If they hadn't gotten themselves into this rut of backwards thinking in the first place by having worked on Microsoft (and other) products that encourage both closed source and embedding in software drivers that which should be in hardware, then we wouldn't even have had this Slashdot article in the first place. Instead, we'd have more interesting and more innovative hardware, and a lot fewer bugs (even in Windows).
They say: more consistent --- They mean: you can only do it our way
They say: predictable --- They mean: you don't know if Linux will ever crash
They say: easier to manage --- They mean: you have no control
Is the current one insecure?
Seriously, why have a vendor at all? Just hire a decent sysadmin and a decent support engineer.
But there's no assurance that the driver interface has changed. What I'm referring to is the actual history of the changes, not what the most extreme possibility is.
There are extremes. On the left hand some people might want to make interface changes at any time. On the right hand other people want the interface to never be changed. I think the kernel team is doing something pretty close to a fair compromise by not carving it into stone in a way that limits the ability for Linux to evolve and improve, but also not making such changes too often, either (that does mean a lot more work for others in the team, too).
There could be some things that driver writers are using that perhaps shouldn't be used in a driver, and changes done there are not considering the impact on drivers (and shouldn't). We really can't tell for sure if those driver writers are releasing only binary. This is yet more reason to always have drivers in source code that can be compiled and linked to make an actual driver.
I still don't buy the intellectual property issue regarding drivers. If they want the kernel to use standard interfaces, then maybe they should try using standard interfaces at the hardware level and stop using proprietary designs to try to lock people in their drivers. They should put all their innovation inside the hardware itself and to the extent possible use an existing standard interface to access that hardware. If there are new features (which should be selling points for the hardware, and not kept secret) that need special communications for the applications to configure how they are used, then perhaps something added on at the driver would be needed to communicate what parameters are to be passed to the hardware and what status to be passed back. Again, there is no reason for secrecy in the driver, and no reason not to release the source code. There is plenty of reason to do so because that just increases the poetntial market among Linux users.
If companies that keep their drivers in closed binary form are finding that their hardware is not being used by very many people in the Linux community, maybe it is because of that closed binary driver. I know that's a big reason for me to dismiss ever buying that hardware. Another reason is the use of non-standard hardware interfaces.
A source based distribution would be the other extreme. I don't think I need to go that far to achieve my basic goals. I don't anticipate a need to modify most small things. OTOH, there would be some substantial comfort from a full source build.
One can have a higher confidence in future source availability with something in GPL like Linux, than even with a vendor giving their source for other reasons (e.g. as IBM did with early VM/CMS systems).
BTW, I'm using Slackware as my base distribution (just now upgrading to 10.2). I build a starter system in a directory and chroot in to recompile lots of stuff from source, building a Slackware package of each as I do it. Then I redo the install (again, into a directory) but with my own packages substituted. Finally, I use rsync replication to really install to other machines (though I could use the mix of Slackware and my own binary packages to do the install).
Certainly those languages leave a lot of room for "something better". But what particular criteria would make a language better? I suspect not everyone will rank these criteria the same way (hence we get so many languages). For example, I happen to like the C syntax and that means I find Pike a good choice. Still, even Pike has room to be improved on. I happen to not like C++ at all.
Why would there be a substantially greater number for Linux? The kernel doesn't really change that often.
So, what would it take to satisfy your criteria on being a proper successor to C++, if none of C#, Java, Pike, Python, and many others are unable to qualify?
You mean SuSE, Mandriva, Fedora, and Slackware have been modifying the driver APIs? OMG! I was not aware of this. I'll have to switch to Debian where I can get a pure unmodified Linux kernel which really don't change the API all that much .
Well, at least Windows has been using the same API for all its drivers since the Version 2.0 release (the first one I ever used on an Intel 80286). Yeah, right.
BTW, actually I'm not really affected by the distribution I use, since I download pristine kernel sources and compile it using a gcc that recompiled itself 3 times. I also leave out module support for security reasons, and so only drivers that come in the kernel, or that I can add at the source level, ever get used. If I can't see what it's doing, it isn't going to be doing anything on my machines. That means not using binary drivers, whether closed source or not. If you also give me source code for a driver that is in binary, how the hell am I to know you really compiled that binary from that source?
That is a better way to say it.
Long ago, back in the dark ages, when I worked on IBM mainframe computers, I administered several systems in which everything was re-assembled (source was in System/370 Assembler Language) from source. I had actually encountered a few cases where the binary that was distributed did not match the source. By running from source rather than binary, I knew there would be no surprises if I ever had to modify the source code (and that happened numerous times ... the modifying). I continue that practice even today under Linux, by recompiling the kernel and all mission critical applications (e.g. the ones actually doing the services I might ever need to modify to correct security problems or customize the bugs and features).
Why would they not face a similar problem with Windows? Or does every version of Windows since 95 have exactly the same driver API?
I think the real problem is the manufacturers don't want to put the effort into Linux drivers. And this is made worse by having proprietary hardware-software interfaces, instead of making something simple at the interface, and putting their intellectual innovations in just the hardware.
It can also be put to use in other ways. It could be installed by one spouse to spy on another. It could be installed in offices to spy on coworkers, the boss, or for civil espionage. How do you make sure only parents of children can install it only on the computers their children use? These are situations where the need to be able to detect any form of spyware, not matter what the design intention is, is real.
It won't detect kids who boot a Linux or BSD CD such as Knoppix.
Don't you mean anti-spyware software? Don't you mean they merely detect and report (and maybe optionally remove)? Blacklisting doesn't enter into this.
Again, it's not a blacklisting issue. If your EULA only expressed "blacklisting", you've already lost your case.
It might have been downloaded by someone else, first, who intended to use it either for good or evil, and then your software was discovered by a security expert upon inspection of a malfunctioning computer system. It may be that the software was installed by someone who had inappropriate access to the machine (a neighbor kid, for example) and the owner brings the malfunctioning machine to the experts who discover many spyware programs that the owner never installed.
Given how you seem to be twisting things, I would ignore you, too, unless and until you decide to really pursue a genuine legal case.
Since the EULA you claim they violated makes it a violation of contract, not a violation of a specific criminal statute, this would be a civil case, not a criminal one.
There seems to be a lot that you don't understand.
1. You are making a tool that could be readily abused in a very broad way.
2. You are hinting at pursuing a case that could establish a defense usable by software makers with even less honorable, and less naive, intentions.
Maybe they never downloaded it in the first place. Maybe they are acting on the basis of experience that is typically gathered by a practitioner of the field who also works to diagnose malfunctions in client computers where previous detection efforts have failed. This would not necessarily mean your software caused any such problems, but rather, your software may have co-existed on a machine with previously undetected malware which was also performing similar spying actitivies, although for malicious intentions. On the basis of these activities, they would never have agreed to your EULA in the first place as they would never have downloaded a copy of the software.
The ability to detect software like yours, which presumably has no ill-intent, is still necessary, IMHO, because of the existant possibility of ill-intended installation by other parties, such as kids spying on their parents first (it happens), or one spouse spying on the other in domestic issue civil cases (it happens a lot). Unless you can prove that your software has unbreakable facilities that prevent anyone from installing the software except in cases where it would involve only legal spying (e.g. parents spying on kids), I don't think you have a valid basis for demanding that your software be exempted. And I do not see how the software is capable of evaluating the domestic role of the person doing the installation.
My real concern has nothing to do with your software. It has everything to do with all spyware in general, and the establishment of legal defenses that they all may use if you take this matter to court and prevail. Such a ruling would be universally harmful to everyone.
In an unrelated issue, how is your software going to spy on kids that are skipping Windows and booting up a Knoppix CD instead to get to the internet to surf for 7un3z, w4r3z, and pr0n? You know kids are doing it, and not just the smart ones. Do you warn parents that your software cannot detect all these cases?
The following scenario may be more defendable in court. I am not a lawyer, nor do I have a briefcase or fins, so I cannot advise whether this could actually work. The scenario goes like this:
Someone who did download the spyware software is having problems with their computer. That spyware software may, or may not, have anything to do with the problem. They bring their computer to you to diagnose. You do the diagnosis and discover numerous programs present that are performing unexpected activities that appear to be spying. You notice specific signatures about these programs in order to detect if they are present. You implement spyware detection software that can recognize each of these programs. You have never agreed to any EULA from any of these spyware companies.
The legal issues that can still be present include that you may still be attached to the obligations of the owner of the computer, since they cannot pass on to you any rights to do beyond what the EULA specifies is not passed on to them in the first place, and include that the very signature may somehow be considered a copyright violation, even if it is a cryptographically strong checksum.
I would be more inclined to buy their router if they made it an open platform that would also let me run programs I write (using an external cross platform development kit consisting entirely of free open source software such as gcc, etc). I think a lot of people would end up preferring such models of things (routers, switches, modems, radios, TV sets, DVD players, etc) if they could program on it, or run downloaded free open source programs that other people write and make available online. I'd even pay extra to get extra memory capacity on such models to have the room to run more processes. Make it Linux or BSD based and I'm happy. Obviously Linksys is blind to our tiny little market of hackers.
Of course the RIAA and MPAA would have a fit if it involved things that could open their content. But hey, let's do things to help keep their lawyers busy.
My big reason to switch to exclusively IPv6 for at least my mail servers is that the spammers and their zombies won't be doing any IPv6 for a long time. I just have to wait until most of the places I want to exchange mail with at least have IPv6 in addition to any IPv4. That should give me a few years of nearly zero spam.
Let's see here. Manufacturers want us to create a kernel than allows them to infect and interfere with its integrity, reliability, performance, and security, just so they don't have to keep maintaining that driver as the design of the kernel continues to be improved? They want us to stagnate the design of the kernel so they can let us use their stagnant device drivers? And they want us to have a system that is no longer viably supported by staff or consultants, while they are most likely not ever going to provide system support (if they can't keep the driver maintained, how the hell are they going to provide support for an old driver)?
I'd just stay away from their hardware.
Why do you even need to develop a special driver, anyway?
Why would the features vary between one driver (for Windows) and another (for Linux)? Aren't you trying to sell hardware?
OK, let's say that you have some reason to do so. If you make the driver open source, and if that driver gets adopted into the Linux kernel tree, that puts your hardware at a market advantage because at that point it can "just work" with any Linux system with that version of kernel or later. Then when the ABI does change (as it may need to in the future), it gets maintained for you in the kernel development process (which you could also participate in to help ensure the driver for your hardware continues to work effectively).
I don't know even what kind of hardware device this is that your employer makes and that you write drivers for. If I did know, I could know whether it was some really special kind of device that needs a unique driver, or if it is some general kind of device that perhaps you should use a generic driver for (and put all your smart advanced features in the firmware on the device, running on that device's own CPU, instead of running in the host CPU).
BTW, isolating an environment for securely running device drivers is fundamentally going to be difficult. The driver needs to access the device, and if you have to create an abstraction to that, you are also creating a performance hurdle since every access has to be requested through the kernel and verified as to permission (e.g. so the driver cannot access other devices or memory structures or processes, etc). Drivers work better when they are trusted to do the right things and don't have to be watched over all the time. They work faster if they can access the device with direct memory references instead of having to run through dozens or hundreds of kernel core instructions for each access.
So tell me what this device is that I may tell you the way a driver really needs to be done for it.
And how would this have been any easier if the driver were closed source?
At least with an open source (and GPL) driver, the opportunity to roll it into the main kernel tree exists. Then it should be rather easy to get it enabled and installed under various distributions, as well as making a solid kernel with that driver compiled and linked in. You get no such advantage with closed source drivers. And there is no guarantee that the driver maker's installation tool will even work right in all distributions that use the same common Linux kernel.
I have had occaisional problems like you describe. Building a custom kernel with the drivers compiled in (not as modules) always solved them.
The real problem is this need to have unique drivers for every instance of hardware. Part of that problem is that manufacturers keep wanting to put their code in the host system for various reason. One common reason is to use the host CPU for work they are too cheap to do in the device they are selling. And another that has come out is their desire to access the host system itself (and something in the kernel involves a huge amount of access).
This practice is bad because it compromises the integrity, reliability, performance, and security of host systems.
What is really needed is a standard way of accessing hardware devices so there is no need to have unique drivers for each device. And for many devices, such as disk drives, that already exists. This just needs to be extended so that it works for all general and common devices. The only time a new device should need its own driver is when it is so uniquely new, that there is no analogy to what it does in existing devices (e.g. it would also need a new device file name in the /dev directory as well).
If you actually want to let various hardware manufacturers to have control of code that runs in the kernel layer of your computer, or even in the root permitted process layer, then you don't really deserve Linux, and should stay away from it. One of the big advantages of Linux is the very fact that everything that runs with indefinite permission or indefinite credentials is open for inspection, and where necessary, modification. That doesn't mean you personally (or even any of your staff if you are a business) have to even have the skills to do this ... you gain an advantage just from the community eyes doing this inspection independently.
The manufacturers should simply use standard drivers for devices. Every device that a normal common laptop computer needs already has many existant, working, and generally very well debugged, drivers in the open source kernel tree. They need to just make their hardware work with those drivers as is. Tell me what kind of device can't follow along with that requirement and can't establish a new software to hardware interface open standard where existing interfaces are inadequate.
Put yourself in the position of being a manufacturer of a hardware device that wants to have a closed source driver. There, now you look really stupid. So, tell me, what is wrong with this hardware device that requires a closed source driver? Are you just secretly trying to get the host CPU to do the work that the hardware should be doing instead?
If you have any intellectual property you need to protect, such as proprietary (de)compression or other processing algorithms, or any (de)encryption keys, or anything else like that, those should be put in the hardware itself (or in the firmware running that hardware's internal CPU). Don't try to offload work, especially if that work involves any intellectual property protected processes, onto the CPU.
There needs to be a definitive boundary between the product, and the user of that product, and that boundary should absolutely not be inside the host CPU itself. That boundary should be the layer between the existing system, and the product purchased to add on to it.
Drivers really should do no more than provide a means to communicate between the kernel (usually the I/O parts) and the hardware. If you have some nifty invention that makes things work better that warrants the development and marketing of this device, then put that invention inside the device itself. Don't screw with the integrity, reliability, performance, and the security of my system (and kernel) for this.