Yes, but that request should only have the request for option 43, which wouldn't be vendor-specific. Only the response should have vendor-specific data in it and the XP client machine shouldn't be responding to DHCPREQUESTs, it should be the one sending them.
Aha. But it still doesn't make sense. If SP3 is sending option 43 as a client, then the data will be in Microsoft's vendor-specific format, not Billion's. The only way Billion would have a problem is if Microsoft changed the format without telling anyone. And why would a router need to look at Microsoft's vendor-specific information in the first place?
That doesn't make sense, though. Option 43 is sent by the DHCP server to the client. In this case the SP3 machine is the client and the router is the server. It's the server's responsibility to correctly format the vendor-specific data according to the vendor's spec, but the SP3 box shouldn't be the server in the scenario in question.
And this is a problem for me as the author of a GPLv3'd work how? My deal offered to you was "You can use my work as the basis for yours, but you have to let others do the same thing with yours as you did with mine.". Yes it may put a crimp in your plans to not let anyone else do that, but why as the author should I let you freely use my stuff as the basis for your product without any compensation in return? Just as with anything else, you either pay your supplier the price he wants, negotiate a different deal with him and pay according to that deal, or go without whatever the supplier was going to give you. Sure it'd be nice if the supplier just gave you stuff and never asked you to pay, but business doesn't work that way.
Is it anti-business for a businessman to demand that people pay him for what he's selling them? To say that if the customer isn't willing to pay, they don't get to walk out the door with the product anyway? I don't think so.
Possibly, but the fact that businessmen and lawyers have put on blinders that limit their view of the world to "exchange for dollars only" seems to me to be their problem, not anybody else's. To me the concept of free software was always obvious: any recipient of the code is free to use that code, modify it and distribute the original and/or modified versions to others. Which leads to the GPL's one restriction: as a recipient of the code, you may not deny that same freedom to anyone else you distribute the code to.
I've felt for many years that the hypothetical non-coder businessman you present isn't confused at all by the GPL. He understands perfectly and completely what it requires. And he doesn't like it. He'd rather be able to take someone else's work without paying, do whatever he wants to it, make a profit off of making and distributing copies of it, and prevent anyone else from doing the same thing he did. His "confusion" is just a sham, put forward for one purpose: to reserve that freedom for himself and no-one else, because that's to his benefit.
The GPL defines what it means by "program". Unless the client program's actually part of the server package itself, and thus licensed under the GPLv3, it's not part of the server program. The exception would be if the protocol between the client and the server were such that they were intimately tied together: the server couldn't be talked to by anything but that specific client, and the client couldn't talk to any server implementation other than that specific one. I suppose one could write a client/server pair that way, but it'd be a lot more work than just defining a clean interface protocol such that you could swap client and server implementations out without breaking anything. And since the output of a GPLv3'd program explicitly is not covered by the GPLv3 unless that output, standing on it's own, contains enough verbatim GPLv3'd material to constitute a covered work. So unless the server program's spitting out it's own code to the client, the output wouldn't be under the GPLv3. See section 2 of the GPLv3, first paragraph, "Basic Permissions".
Actually the provider can treat the set-top box as a sealed appliance. But they have to treat it as truly a sealed appliance. What section 6 of the GPLv3 prohibits is a company using GPLv3'd software in the set-top box and allowing the manufacturer to continue to access and modify the software (ie. the box isn't a sealed appliance as far as the manufacturer is concerned) while denying the recipient of the box the same access. The GPLv3 prohibits that asymmetric access, but explicitly says that it's entirely acceptable to not allow the user access if the manufacturer doesn't have it either.
And how do the implications differ from the implications of using any other software and redistributing it in violation of license terms? Suppose I go and build a product by modifying Microsoft Windows, and I go distributing this modified version of Microsoft Windows along with my product without having a license from Microsoft and complying with their terms. What do you suppose the implications and consequences are going to be?
The GPL is a license. Nothing more, nothing less. It grants you permission to use someone else's work in ways that copyright law doesn't by default allow, as long as you comply with the conditions set forth in the license. In the case of the GPL, the general deal is simple: "You benefited by modifying and using my software as the basis for your work. In return for that benefit, you have to let other people do the same thing with your software that you did with mine. If you can't or won't, then don't use my work.". To me that's a fairly straightforward deal. Most of the complex portions of GPLv3 simply amount to "We know you found this loophole to try and redistribute my code without honoring the deal. Sorry, that's explicitly prohibited.".
You seem to be suffering from the software-company delusion that the only meaning of "license" is "end-user license to use". Which is incorrect, "license" as a legal term emcompasses that and several other meanings. It's entirely possible to be both the owner of a copy (note the qualification) and a licensee of rights associated with that copy. The GPL's a classic example. When I receive a copy of a GPL'd program I become the owner of that copy. I also simultaneously become a licensee per the GPL and receive a copyright license to make and distribute additional copies of that software subject to the license terms imposed by the GPL.
My immediate response to this would be "They are the same person they were before they gave notice. If you believed they'd be so unprofessional, so untrustworthy, then why did you give them that access in the first place?". Simply giving notice isn't anything special or unusual. Everybody leaves their job. The head of HR will one day give his 2-weeks notice. Even the CEO of the company will one day leave for another position. The company itself isn't going to be shy about telling employees that outsourced contractors are a better opportunity for the company and the employee's services are no longer required. So why all this uproar and upset about this?
Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
Note "owner of a copy". If you aren't the owner, then 117(a) doesn't apply to you. If you find a copy on the street, you aren't the owner until you satisfy the legal requirements for found property. If it's a pirated copy then it's not a legal copy and you, being not the copyright holder, can't make it a legal copy just by picking it up. You're trying to make 2 permanent, independent copies exist where you started with only 1, and that I'm afraid is the very most basic thing copyright law says you must have the copyright holder's permission to do.
That depends. If it's an otherwise legal copy, then you probably don't because you haven't yet met the requirements for gaining title to found property. Once you've met those requirements, though, you're clear because you now own a legal copy. If it's a pirate copy, then no you don't because your copy isn't legal itself.
Note that the software companies want you to believe that not even Section 117 gives you any right to make the copies needed to install and run the software, that you need to get that right from them. They really really don't like the interpretation I gave, which is the correct one if you read the law (which you apparently haven't).
Because it's not the case that you require no license or permission to install and run the software. It's just that you can get your permission to do that from copyright law instead of the copyright holder. And that permission granted by copyright law is given to you only to install and run software which you legally own a copy of. If you sell your copy, you no longer own that copy and your permission goes with the copy you sold.
Transmitting sensitive data to the consultant isn't a problem. It's easy. PGP encryption using the consultant's public key confirmed via fingerprint check over the phone, then either e-mail the encrypted file or burn it to DVD and overnight it.
But what happens once it's in the consultant's hands? That's the rub. Once it's in their hands it will be decrypted and in the clear on their systems. It has to be. And you're trusting their security policies and procedures when you don't have any control over them or probably any idea what they are. And the consultant won't be the one suffering the fallout if the data's stolen from their network. Depending on how the contract's written they may not even be liable for the loss, and if they are liable you'll have to fight them in court and you're unlikely to recover a fraction of just your direct costs let alone the indirect, fuzzy costs like loss of reputation.
If it were me, I'd insist they do the work on my systems, connecting via IPSec VPN with proper key management protocols in place, with none of my data ever leaving my systems. And I'd still treat their systems as untrusted, have them VPN into an isolated network segment to do the work with solid firewalls between that segment and the rest of my network.
This sounds a lot like using OS/2 to check out suspected viruses/trojans. Run the suspect program in a DOS box, which used Virtual 8086 mode on the 386 to provide a virtualized environment. Watch for suspicious behavior, like modifying the interrupt vector table (V86 mode didn't use the VM's IVT, the INT instruction caused a trap back into protected mode and the supervisor checked what interrupt was being generated and either handled the call in protected mode or dispatched it back into the VM, so it was impossible for malware to hijack system calls and easy for the supervisor to reliably see if the IVT had been modified and where it was pointing to now). My understanding is that this was a fairly popular way of analyzing viruses and trojans back in the day, it was easy to see what the code was doing and (as long as you avoided running programs in OS/2's native format) all but impossible for the code to escape the VM and infect the actual system.
NB: it was moderately amusing watching stealth viruses try to burrow into the DOS system code (to try and hide themselves without the tell-tale modification of the IVT) and cause all sorts of nasty traps and faults because the memory they were trying to modify just didn't exist in the VM's address space.
Bear in mind that BIND for one doesn't use the root nameserver hints file directly under normal conditions. One of the first things it does is contact one of the servers listed in the hints file and download the real root nameserver list. After that it uses the downloaded list and ignores the hints file. So unless you contacted the L server for that initial download, you'll get the correct root server list and won't ever contact the bogus ones. I'd have to check whether BIND picks a hints entry at random or cycles through starting from the first. If it picks at random the window of vulnerability is small, but if it starts at the first it's virtually nonexistent (most hints files list A, B, C and so on in sequence, and the chance of getting no answer at all from the A-K servers is close to zero).
No, people exercising their rights is fine. No one should be ripped off. What I'm saying however, is if the vendor did not sell her the product the way she wanted it, why would she buy it just to sue? I'm more than certain that she had alternative choices.
Because she didn't have any alternative choices. Unless you're a techno-geek who knows how to build your own system from parts, or you're looking for a subnotebook like the XO or the EEE, it's incredibly difficult to find anything that doesn't come with a Microsoft OS bundled. If you're looking for a name-brand consumer machine (ie. you're not buying on a corporate account), it's effectively impossible. This person, like most, had two choices: buy a computer with some variety of Windows bundled, or don't buy a computer.
The French court here seems to be saying "The specific OS isn't an integral part of the computer, witness all the ones sold with different OSes. It's easy enough for vendors to supply a machine without an OS. Under French law the consumer has the right not to be forced to buy additional products just to get the one they're nominally buying. The vendor's refund program appears to acknowledge that, but it's more convoluted and costly than it has any reason to be. Vendor, stop playing games and give her the money back like the law says you have to.".
If it's only this customer's data in the database, nothing else, then just give them one or more users with read-only permissions. They'll be able to look all they want, but they won't be able to change anything or muck anything up. No danger there, and no problems with exposure of data because it's all their data anyway. The only problem comes if/when they ask for write access, and the case for denying them there depends on what they're asking and how the database is set up (if for various reasons it's not got a strong integrity constraint setup in place, the risk of corruption is a good enough reason technically to deny access unless the customer also wants to take over complete administrative responsibility for the database).
If there's data in the database that's not the customer's, eg. tracking data for other customers or additional data for your organization that's not supposed to be visible to the customer, cite the need to restrict access to that data and the inability to do that if you give the customer direct read access to the database. You may end up having to build a custom schema/view that exposes only what they're allowed to see, but that's a fairly significant undertaking and should be billed to someone.
They try. Problem is that the interesting calls, things like program loading and disk read/write, aren't easy to pin down exact timings for. How long the disk read calls take, for example, depends heavily on what else is running at the time (taking CPU cycles away from the reading process) and what the I/O load is (which affects how long it'll be before the read actually completes).
And, how is the scanner doing it's timing? Using system calls. To the operating system. The one that's compromised and lying to the scanner about how much CPU time it's used. See Programming Satan's Computer (PDF) for the problems inherent here.
First rule of system scanning: if your system is compromised, you can't trust anything running on it including the scanning software. Any malware that's gotten far enough in to be a threat can readily trap the system functions to load programs and read the disk and the system functions used to detect trapping of system functions, allowing it to invisibly return false data to the scanning program. This was standard practice in the late 80s for viruses, see the origin of the term "stealth virus". You can scan incoming files using a scanner running on the main OS but to scan the main OS for infection you need to be running from a different boot image, one that's never been made available in a writable state to the main OS. And no, that doesn't mean a different partition on the hard drive, that's writable by the main OS even if it's not directly available as a drive. The media has to have been physically write-protected or read-only any time it's been in the drive while the main OS is running.
What about services like Windows Update? As complex as the pages need to be, I can see any messing with them easily breaking them.
What about things that use HTTP as a transport but the client isn't a Web browser? It can't opt-out since it doesn't do cookies, and messing with what it expects can cause major breakage.
How does Charter think copyright's going to play into this? I own the copyright on my Web pages. If Charter modifies them before presenting them to a browser, they've just created and distributed an unauthorized derivative work. I'm pretty sure I can present a court with a long list of rulings supporting that. And what happens if the RIAA get their three-strikes law or worse? It'd be fun to see Charter's Internet connection cut off...:)
But if it's all on a centralized server, what does a DVCS give you that a CVCS doesn't?
1. It's dead simple to do this in CVS or SVN too. Branch, make your changes, check in as needed, merge when you're satisfied or discard the branch if you aren't. You don't need a DVCS for that. And yes, it gets stored forever. That's the point of a VCS. If it's your personal project it's not a big deal, but for corporate development the last thing you want is developers having work that's not available to everyone else. That way lies a developer leaving at an inopportune time and important work disappearing because it was on his machine and not on the central server where everyone else knows about it.
2. I can check in every little change along the way in a CVCS too. "cvs commit" works. You just have to branch, see #1. Of course if you don't branch it becomes a problem, but it's a problem in a DVCS too.
Simply put, a lot of development is in an environment that's not distributed and not concurrent. All the machines that should have the code on them are in the same datacenter or plugged into the same gigabit Ethernet switch. For various reasons the code's not supposed to be distributed outside this tight circle of machines. The developers are all in the same office, or at most you've got two, maybe three, groups. You only have one or two programmers assigned to particular parts of the software at any given time, and all work on any given piece needs to go through the assigned owner so it can be reconciled with all the other work required. And unlike most open-source projects, the developers don't control the requirements or the priorities which means they aren't in a position to be making changes outside their assigned pieces just because those changes are needed (those changes, however neccesary, may break something the developer's not in the loop on).
Not all development's done on the scale of or using the model of Linux kernel development, and when one needs to drive in a nail to hang a picture one uses neither a screwdriver nor a pile-driver.
Problem is, those "advantages" aren't in a lot of situations. Where I work, for instance, making it easy to get the code out of the office and onto a home machine would be a Bad Thing requiring nasty controls be imposed on the home machine to keep the code under the same control as if it were on the corporate internal network. Branching's already minimal-cost. The central repository's in the data center, and thinking is that if those machines are down then we're dead in the water anyway since our test environments, databases, build machines and such are down too. In addition, with the repository on a centrally-managed server we've got the entire disaster-recovery mechanism to work with, and getting that repository back up and running quickly on an alternate server comes with that. The fundamental problem is that the scale's too small for the advantages of a DCVS to kick in, and absent that the requirements to centralize control (and yes that is a requirement, not from a technical standpoint but from a regulatory and legal standpoint) mean added costs trying to make a DVCS behave like it's a CVCS.
Problem: the VCS doesn't know the base of the project. If I'm editing a file in/home/me/src/projects/utilities/ljbackup/database, exactly what portion of that path is this project's tree and which is the part the project lives under? It has to be able to figure that out with nothing more than the path available, remember, since you don't want it to store anything in the working directory indicating what the base for this directory's files is supposed to be. And it also has to accept ljbackup/database being simultaneously checked out at both/home/me/src/projects/utilities and/home/me/work, possibly at the same revision and possibly at different revisions.
CVS and SVN use meta-data under the current directory because it creates a self-contained working directory tree without any ambiguity in what the exact location of the meta-data for any given file will be.
Why do you need a working directory without meta-data present? I can't think of too many reasons, and the ones I can think of fall under "That's probably a bad idea.".
Slashdot Mirror
Yes, but that request should only have the request for option 43, which wouldn't be vendor-specific. Only the response should have vendor-specific data in it and the XP client machine shouldn't be responding to DHCPREQUESTs, it should be the one sending them.
Aha. But it still doesn't make sense. If SP3 is sending option 43 as a client, then the data will be in Microsoft's vendor-specific format, not Billion's. The only way Billion would have a problem is if Microsoft changed the format without telling anyone. And why would a router need to look at Microsoft's vendor-specific information in the first place?
That doesn't make sense, though. Option 43 is sent by the DHCP server to the client. In this case the SP3 machine is the client and the router is the server. It's the server's responsibility to correctly format the vendor-specific data according to the vendor's spec, but the SP3 box shouldn't be the server in the scenario in question.
And this is a problem for me as the author of a GPLv3'd work how? My deal offered to you was "You can use my work as the basis for yours, but you have to let others do the same thing with yours as you did with mine.". Yes it may put a crimp in your plans to not let anyone else do that, but why as the author should I let you freely use my stuff as the basis for your product without any compensation in return? Just as with anything else, you either pay your supplier the price he wants, negotiate a different deal with him and pay according to that deal, or go without whatever the supplier was going to give you. Sure it'd be nice if the supplier just gave you stuff and never asked you to pay, but business doesn't work that way.
Is it anti-business for a businessman to demand that people pay him for what he's selling them? To say that if the customer isn't willing to pay, they don't get to walk out the door with the product anyway? I don't think so.
Possibly, but the fact that businessmen and lawyers have put on blinders that limit their view of the world to "exchange for dollars only" seems to me to be their problem, not anybody else's. To me the concept of free software was always obvious: any recipient of the code is free to use that code, modify it and distribute the original and/or modified versions to others. Which leads to the GPL's one restriction: as a recipient of the code, you may not deny that same freedom to anyone else you distribute the code to.
I've felt for many years that the hypothetical non-coder businessman you present isn't confused at all by the GPL. He understands perfectly and completely what it requires. And he doesn't like it. He'd rather be able to take someone else's work without paying, do whatever he wants to it, make a profit off of making and distributing copies of it, and prevent anyone else from doing the same thing he did. His "confusion" is just a sham, put forward for one purpose: to reserve that freedom for himself and no-one else, because that's to his benefit.
The GPL defines what it means by "program". Unless the client program's actually part of the server package itself, and thus licensed under the GPLv3, it's not part of the server program. The exception would be if the protocol between the client and the server were such that they were intimately tied together: the server couldn't be talked to by anything but that specific client, and the client couldn't talk to any server implementation other than that specific one. I suppose one could write a client/server pair that way, but it'd be a lot more work than just defining a clean interface protocol such that you could swap client and server implementations out without breaking anything. And since the output of a GPLv3'd program explicitly is not covered by the GPLv3 unless that output, standing on it's own, contains enough verbatim GPLv3'd material to constitute a covered work. So unless the server program's spitting out it's own code to the client, the output wouldn't be under the GPLv3. See section 2 of the GPLv3, first paragraph, "Basic Permissions".
Actually the provider can treat the set-top box as a sealed appliance. But they have to treat it as truly a sealed appliance. What section 6 of the GPLv3 prohibits is a company using GPLv3'd software in the set-top box and allowing the manufacturer to continue to access and modify the software (ie. the box isn't a sealed appliance as far as the manufacturer is concerned) while denying the recipient of the box the same access. The GPLv3 prohibits that asymmetric access, but explicitly says that it's entirely acceptable to not allow the user access if the manufacturer doesn't have it either.
And how do the implications differ from the implications of using any other software and redistributing it in violation of license terms? Suppose I go and build a product by modifying Microsoft Windows, and I go distributing this modified version of Microsoft Windows along with my product without having a license from Microsoft and complying with their terms. What do you suppose the implications and consequences are going to be?
The GPL is a license. Nothing more, nothing less. It grants you permission to use someone else's work in ways that copyright law doesn't by default allow, as long as you comply with the conditions set forth in the license. In the case of the GPL, the general deal is simple: "You benefited by modifying and using my software as the basis for your work. In return for that benefit, you have to let other people do the same thing with your software that you did with mine. If you can't or won't, then don't use my work.". To me that's a fairly straightforward deal. Most of the complex portions of GPLv3 simply amount to "We know you found this loophole to try and redistribute my code without honoring the deal. Sorry, that's explicitly prohibited.".
You seem to be suffering from the software-company delusion that the only meaning of "license" is "end-user license to use". Which is incorrect, "license" as a legal term emcompasses that and several other meanings. It's entirely possible to be both the owner of a copy (note the qualification) and a licensee of rights associated with that copy. The GPL's a classic example. When I receive a copy of a GPL'd program I become the owner of that copy. I also simultaneously become a licensee per the GPL and receive a copyright license to make and distribute additional copies of that software subject to the license terms imposed by the GPL.
My immediate response to this would be "They are the same person they were before they gave notice. If you believed they'd be so unprofessional, so untrustworthy, then why did you give them that access in the first place?". Simply giving notice isn't anything special or unusual. Everybody leaves their job. The head of HR will one day give his 2-weeks notice. Even the CEO of the company will one day leave for another position. The company itself isn't going to be shy about telling employees that outsourced contractors are a better opportunity for the company and the employee's services are no longer required. So why all this uproar and upset about this?
To quote USC Title 17 Section 117(a):
Notwithstanding the provisions of section 106, it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
Note "owner of a copy". If you aren't the owner, then 117(a) doesn't apply to you. If you find a copy on the street, you aren't the owner until you satisfy the legal requirements for found property. If it's a pirated copy then it's not a legal copy and you, being not the copyright holder, can't make it a legal copy just by picking it up. You're trying to make 2 permanent, independent copies exist where you started with only 1, and that I'm afraid is the very most basic thing copyright law says you must have the copyright holder's permission to do.
That depends. If it's an otherwise legal copy, then you probably don't because you haven't yet met the requirements for gaining title to found property. Once you've met those requirements, though, you're clear because you now own a legal copy. If it's a pirate copy, then no you don't because your copy isn't legal itself.
Note that the software companies want you to believe that not even Section 117 gives you any right to make the copies needed to install and run the software, that you need to get that right from them. They really really don't like the interpretation I gave, which is the correct one if you read the law (which you apparently haven't).
Because it's not the case that you require no license or permission to install and run the software. It's just that you can get your permission to do that from copyright law instead of the copyright holder. And that permission granted by copyright law is given to you only to install and run software which you legally own a copy of. If you sell your copy, you no longer own that copy and your permission goes with the copy you sold.
Transmitting sensitive data to the consultant isn't a problem. It's easy. PGP encryption using the consultant's public key confirmed via fingerprint check over the phone, then either e-mail the encrypted file or burn it to DVD and overnight it.
But what happens once it's in the consultant's hands? That's the rub. Once it's in their hands it will be decrypted and in the clear on their systems. It has to be. And you're trusting their security policies and procedures when you don't have any control over them or probably any idea what they are. And the consultant won't be the one suffering the fallout if the data's stolen from their network. Depending on how the contract's written they may not even be liable for the loss, and if they are liable you'll have to fight them in court and you're unlikely to recover a fraction of just your direct costs let alone the indirect, fuzzy costs like loss of reputation.
If it were me, I'd insist they do the work on my systems, connecting via IPSec VPN with proper key management protocols in place, with none of my data ever leaving my systems. And I'd still treat their systems as untrusted, have them VPN into an isolated network segment to do the work with solid firewalls between that segment and the rest of my network.
This sounds a lot like using OS/2 to check out suspected viruses/trojans. Run the suspect program in a DOS box, which used Virtual 8086 mode on the 386 to provide a virtualized environment. Watch for suspicious behavior, like modifying the interrupt vector table (V86 mode didn't use the VM's IVT, the INT instruction caused a trap back into protected mode and the supervisor checked what interrupt was being generated and either handled the call in protected mode or dispatched it back into the VM, so it was impossible for malware to hijack system calls and easy for the supervisor to reliably see if the IVT had been modified and where it was pointing to now). My understanding is that this was a fairly popular way of analyzing viruses and trojans back in the day, it was easy to see what the code was doing and (as long as you avoided running programs in OS/2's native format) all but impossible for the code to escape the VM and infect the actual system.
NB: it was moderately amusing watching stealth viruses try to burrow into the DOS system code (to try and hide themselves without the tell-tale modification of the IVT) and cause all sorts of nasty traps and faults because the memory they were trying to modify just didn't exist in the VM's address space.
Bear in mind that BIND for one doesn't use the root nameserver hints file directly under normal conditions. One of the first things it does is contact one of the servers listed in the hints file and download the real root nameserver list. After that it uses the downloaded list and ignores the hints file. So unless you contacted the L server for that initial download, you'll get the correct root server list and won't ever contact the bogus ones. I'd have to check whether BIND picks a hints entry at random or cycles through starting from the first. If it picks at random the window of vulnerability is small, but if it starts at the first it's virtually nonexistent (most hints files list A, B, C and so on in sequence, and the chance of getting no answer at all from the A-K servers is close to zero).
No, people exercising their rights is fine. No one should be ripped off. What I'm saying however, is if the vendor did not sell her the product the way she wanted it, why would she buy it just to sue? I'm more than certain that she had alternative choices.
Because she didn't have any alternative choices. Unless you're a techno-geek who knows how to build your own system from parts, or you're looking for a subnotebook like the XO or the EEE, it's incredibly difficult to find anything that doesn't come with a Microsoft OS bundled. If you're looking for a name-brand consumer machine (ie. you're not buying on a corporate account), it's effectively impossible. This person, like most, had two choices: buy a computer with some variety of Windows bundled, or don't buy a computer.
The French court here seems to be saying "The specific OS isn't an integral part of the computer, witness all the ones sold with different OSes. It's easy enough for vendors to supply a machine without an OS. Under French law the consumer has the right not to be forced to buy additional products just to get the one they're nominally buying. The vendor's refund program appears to acknowledge that, but it's more convoluted and costly than it has any reason to be. Vendor, stop playing games and give her the money back like the law says you have to.".
Two words: gorilla arm.
If it's only this customer's data in the database, nothing else, then just give them one or more users with read-only permissions. They'll be able to look all they want, but they won't be able to change anything or muck anything up. No danger there, and no problems with exposure of data because it's all their data anyway. The only problem comes if/when they ask for write access, and the case for denying them there depends on what they're asking and how the database is set up (if for various reasons it's not got a strong integrity constraint setup in place, the risk of corruption is a good enough reason technically to deny access unless the customer also wants to take over complete administrative responsibility for the database).
If there's data in the database that's not the customer's, eg. tracking data for other customers or additional data for your organization that's not supposed to be visible to the customer, cite the need to restrict access to that data and the inability to do that if you give the customer direct read access to the database. You may end up having to build a custom schema/view that exposes only what they're allowed to see, but that's a fairly significant undertaking and should be billed to someone.
They try. Problem is that the interesting calls, things like program loading and disk read/write, aren't easy to pin down exact timings for. How long the disk read calls take, for example, depends heavily on what else is running at the time (taking CPU cycles away from the reading process) and what the I/O load is (which affects how long it'll be before the read actually completes).
And, how is the scanner doing it's timing? Using system calls. To the operating system. The one that's compromised and lying to the scanner about how much CPU time it's used. See Programming Satan's Computer (PDF) for the problems inherent here.
First rule of system scanning: if your system is compromised, you can't trust anything running on it including the scanning software. Any malware that's gotten far enough in to be a threat can readily trap the system functions to load programs and read the disk and the system functions used to detect trapping of system functions, allowing it to invisibly return false data to the scanning program. This was standard practice in the late 80s for viruses, see the origin of the term "stealth virus". You can scan incoming files using a scanner running on the main OS but to scan the main OS for infection you need to be running from a different boot image, one that's never been made available in a writable state to the main OS. And no, that doesn't mean a different partition on the hard drive, that's writable by the main OS even if it's not directly available as a drive. The media has to have been physically write-protected or read-only any time it's been in the drive while the main OS is running.
But if it's all on a centralized server, what does a DVCS give you that a CVCS doesn't?
1. It's dead simple to do this in CVS or SVN too. Branch, make your changes, check in as needed, merge when you're satisfied or discard the branch if you aren't. You don't need a DVCS for that. And yes, it gets stored forever. That's the point of a VCS. If it's your personal project it's not a big deal, but for corporate development the last thing you want is developers having work that's not available to everyone else. That way lies a developer leaving at an inopportune time and important work disappearing because it was on his machine and not on the central server where everyone else knows about it.
2. I can check in every little change along the way in a CVCS too. "cvs commit" works. You just have to branch, see #1. Of course if you don't branch it becomes a problem, but it's a problem in a DVCS too.
Simply put, a lot of development is in an environment that's not distributed and not concurrent. All the machines that should have the code on them are in the same datacenter or plugged into the same gigabit Ethernet switch. For various reasons the code's not supposed to be distributed outside this tight circle of machines. The developers are all in the same office, or at most you've got two, maybe three, groups. You only have one or two programmers assigned to particular parts of the software at any given time, and all work on any given piece needs to go through the assigned owner so it can be reconciled with all the other work required. And unlike most open-source projects, the developers don't control the requirements or the priorities which means they aren't in a position to be making changes outside their assigned pieces just because those changes are needed (those changes, however neccesary, may break something the developer's not in the loop on).
Not all development's done on the scale of or using the model of Linux kernel development, and when one needs to drive in a nail to hang a picture one uses neither a screwdriver nor a pile-driver.
Problem is, those "advantages" aren't in a lot of situations. Where I work, for instance, making it easy to get the code out of the office and onto a home machine would be a Bad Thing requiring nasty controls be imposed on the home machine to keep the code under the same control as if it were on the corporate internal network. Branching's already minimal-cost. The central repository's in the data center, and thinking is that if those machines are down then we're dead in the water anyway since our test environments, databases, build machines and such are down too. In addition, with the repository on a centrally-managed server we've got the entire disaster-recovery mechanism to work with, and getting that repository back up and running quickly on an alternate server comes with that. The fundamental problem is that the scale's too small for the advantages of a DCVS to kick in, and absent that the requirements to centralize control (and yes that is a requirement, not from a technical standpoint but from a regulatory and legal standpoint) mean added costs trying to make a DVCS behave like it's a CVCS.
Problem: the VCS doesn't know the base of the project. If I'm editing a file in /home/me/src/projects/utilities/ljbackup/database, exactly what portion of that path is this project's tree and which is the part the project lives under? It has to be able to figure that out with nothing more than the path available, remember, since you don't want it to store anything in the working directory indicating what the base for this directory's files is supposed to be. And it also has to accept ljbackup/database being simultaneously checked out at both /home/me/src/projects/utilities and /home/me/work, possibly at the same revision and possibly at different revisions.
CVS and SVN use meta-data under the current directory because it creates a self-contained working directory tree without any ambiguity in what the exact location of the meta-data for any given file will be.
Why do you need a working directory without meta-data present? I can't think of too many reasons, and the ones I can think of fall under "That's probably a bad idea.".