Except that your premise is false. Firstly, the hooks aren't there to allow built-in measures to be disabled. They're there to allow non-built-in measures to be added. MS's firewall then becomes one of possibly several that can be added. Modules can be added, but no module can remove another (other than by configuring the system to not load the other module, which no module should ever have permission to do). Secondly, security and open/proprietary aren't connected. If they were, and your premise was right, then Windows would have far fewer exploits than Linux or *BSD. The fact that the reverse is true is a good indication your premise is incorrect.
The rest of your argument rests on air, and on accepting MS's definition that they are the only supplier of security in the OS. The EU's position is that MS shall not be the sole supplier. I'd note that that's true for OSX and Linux now: you probably won't go searching out third-party firewall modules, but nothing in OSX or Linux prevents someone from creating a set and completely replacing the standard firewall subsystem with their own with no loss in functionality or performance (other than that caused by their own code and their own decision whether or not to implement various bits of functionality). If MS's firewall and other security products are so good, no other company will be able to compete on the merits. The EU is merely saying that MS will have to compete on the merits, not by preventing any competition from existing at all. I'd note that blocking competition will be bad for consumers as well. We've already seen that with the Windows XP firewall: MS's offering lacks significant functionality, but the way they implemented it interferes with more capable third-party firewalls and makes them unable to function stably. I had to take a significant hit by dropping my Sygate firewall because it simply wouldn't work after XP SP2 (when it had worked perfectly for a year before, and the problems started exactly when SP2 was applied). I was more secure before MS decided theirs would be the only firewall allowed on XP.
Bear in mind that the EU isn't saying that Microsoft can't include security software in Windows Vista. What they're saying is that MS can't include it in such a way as to exclude competitors. For example, take a firewall. If MS integrates their firewall into the network stacks at the physical-code level so that no other firewall can take over, that's not allowed. However, if MS adds hooks to their network stacks to allow other modules/drivers to tap in and filter packet traffic, and then implements their firewall completely using those hooks and makes it so you can replace the loading of MS's firewall modules with a third-party firewall's modules, that's perfectly fine. And for anyone who says this can't be done, I'd point out that Linux and *BSD implement their firewalls in exactly that manner so obviously it can be done.
It's interesting the unstated assumption in the arguments against heterogenity: that any given company must support multiple platforms for heterogenity to work. I don't think that's true, though. If any given company uses a single platform, but different companies choose different single platforms, the end result is much the same overall: exploits have a much smaller target they'll work on.
And further, I don't think the arguments about the cost of supporting multiple platforms hold up. There's more than enough research supporting the contention that it takes fewer people to support Unix-based desktops than Windows-based ones, and that makes sense given the remote-admin capabilities built into desktop Unix that come from it's server roots. So suppose a company switches to a 50/50 mix of Windows and Linux desktops, and a Linux tech can support twice as many desktops as a Windows tech could. Yes, supporting two platforms costs more than supporting one. But at the same time you've just halved the number of Windows support people you need because you've got half the number of Windows desktops (assuming you've got more than 1 or 2 people could support). You need to replace them with Linux support people, but you only need 1 Linux guy added for every 2 Windows guys you're dropping. If you started with 4 Windows techs, you'd drop 2 Windows techs and add 1 Linux tech for a total of 3 techs now. That's a 25% drop in personnel costs. When figuring costs, you have to add in the reduction in personnel costs as well. Plus there's the reduction in licensing costs that offset any increase from having multiple platforms.
And finally, there's the BSA. We've all read the reports about their audits and the havoc they create. If your company's already supporting non-proprietary platforms, you're in a much better position to do an Ernie Ball if the BSA gives you grief.
When somebody in the US gambles on this website then a transaction occurs simultaneously between that person in the US and wherever the webservers are located.
Yes, but does the transaction occur where the person is, or where the webservers are? We talk about "going to" a Web site, so apparently the standard view is that the transaction happens where the Web servers are. When you buy mail-order, the sale happens at the location of the company selling the product even though you never leave your home and your order arrives on your doorstep. Why should a Web site be different?
ANY business that sells products or services globally must abide by the laws of the countries where their customers are.
Commonly that is not the rule. A store in California isn't required to abide by Utah laws just because people from Utah may shop there while on vacation. It isn't even required to ask where people are from before selling to them. And if the person from Utah buys >3.2 beer from a non-UABC store (which is highly illegal in Utah) while in California, Utah can't touch them because Utah laws aren't applicable in California even if the person buying is a Utah resident and they haven't broken any laws.
There seems to be this view that if a US citizen is involved in a transaction then that transaction must have occurred in the US. This does not seem to be the case in any conventional transaction, quite the opposite in fact. This may make it... inconvenient for certain lawmakers, but if the US wishes to make laws about what it's citizens can do then it should enforce those laws on it's own citizens.
How is he selling it in the US? His operation's located in the UK, his servers are outside the US as well. Yes people from the US can go to his site, but then people from the US can go to London too. That doesn't make London be located in the US. And when did enforcing US laws about what US citizens can and can't do become the job of a British citizen in Britain?
So if cocaine was legal in the UK and they sold it to people in the US then the feds shouldn't go after them?
If the Brits sold cocaine in Britain to US citizens who were visiting Britain at the time, and the US citizens then took it back to the US, exactly what laws that the Brits are subject to did they break? Note that US laws don't apply, British citizens in Britain are subject to British law, not US law. The US citizens probably broke some law, but note that the US citizens aren't the ones being arrested.
True, but often either package B isn't in the same bug-tracking system or team A doesn't have authorization to move the bug to someone else's package. I run into this all the time at work.
I forgot, some people may not know another aspect of C++: operator new never returns a null pointer, so checks on it aren't needed. Operator new throws an exception if it can't allocate memory, the malloc() wrapper I described simply makes malloc() in a C++ program behave the way operator new would.
If it's C++ code, there's another possibility. I use malloc() for byte buffers, but if you dig into the headers you notice something odd: the malloc() routine is actually a small macro that throws an exception if malloc() would return a null pointer. Back up in main() there's a catch block that catches all unhandled exceptions from the body of the program and terminates things as cleanly as possible. It'd be easy for a code analysis to turn up thousands of what look like unchecked memory allocations, but if they really would return NULL the check wouldn't ever get a chance to execute because of the throw.
"Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"
Could be entirely legitimate to close it. If the spec says that package B shall take ownership of the memory when passed in, then yes a bug against package A for a memory leak should be closed and refiled against B that's not honoring the spec.
"Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"
Again possibly entirely legitimate. I've written a number of low-level routines that don't do much error-checking. This fact is explicitly noted in the API spec, and responsibility for error checking is explicitly placed on the caller. That's because these routines get used in performance-critical inner loops, and the error checking should only be done once outside the loop instead of every time the loop executes. That's easier to do if you hoist responsibility for the check up to the point where the data comes in, rather than pushing it down to the lowest level. But things like that do need to be spelled out in the spec, so users of that routine know what their responsibilities are.
Except that if you're reading the ballots via OCR, you still need to check whether the results of the OCR process match the actual printing. You can't simply take it as given, any more than you can take as given that the barcodes match the printing. And I've seen the results of OCRing high-quality scans of high-quality text, and there's very few words that don't have at least one error in them. When it comes to a device correctly reading what's printed, barcode scanners are at least an order of magnitude more reliable than OCR at this point. Why introduce an error-prone step when you can introduce a less-error-prone one?
As far as random, the selection doesn't have to be cryptographically random. It just needs to be sufficiently unpredictable that our vote-rigger can't reliably figure out where he needs to avoid placing his discrepancies to avoid having one selected for a check. And he's got a tough job: he has to have every single one of his introduced errors avoid being selected (while still introducing enough errors to actually change the outcome, because if he biases the election by 2% in favor of A but B wins by 3% then the rigging fails), while we only need to catch one introduced error to foil him. Shaking the ballot box up, stacking the ballots and selecting every tenth one would suffice, even if the order's not random our rigger can't predict what the order will be until it's too late.
As far as speed, speed is desirable simply because people want to know the outcome. I wouldn't sacrifice accuracy for speed, but we have a system where we can get speed without sacrificing the ability to manually count every single ballot if needed.
NB: the system I consider best retains a physical ballot and ballot box, only using the machines to speed up the tallying process. If OVC has a step that depends entirely on the machines, that step needs eliminated. Of course, there's also another way of dealing with the problem: publish the specification, then insure that both parts of the system (the box that creates the barcode and the box that counts the votes) are created by different, unrelated companies. But I prefer a fairly direct representation of an ordinary ballot where humans can, if needed, check every single portion of the ballot. And yes, you can check barcodes using templates once you've checked that the templates match the specification. Even if the system consistently credits barcodes to the wrong candidate, the counts won't match what the humans get when they credit those barcodes to the right candidate.
we only need to tell the difference between President --> George Washington and President --> John Adams.
Exactly. What does the software do when it sees Presldont --> Goorge Washlngten because of character-recognition errors in the OCR software? Yes, that sort of thing can happen even with machine-printed text because of smudging and such. Barcode is much easier because of it's form (eg. the fact that the narrowest a wide bar can appear to be is still wider by a considerable margin than the widest a narrow bar can appear, so you can set a fairly large error margin without overlap). That all makes for a more accurate count, since there's fewer opportunities for ambiguity to creep in.
The smaller that certain percentage is, the greater a chance that an error could slip through unnoticed.
Yep. It's the same with regular paper ballots. So you pull out the statistics textbook, work out what confidence level you need in the results, then work out what percentage of the ballots you need to check to insure that confidence level. If the spot-checks turn up a discrepancy, you run a wider check. If you keep finding discrepancies, you can go all the way up to hand-counting all ballots based on the human-readable text if you have to. Personally I'd spread it around: check 5% of the ballots at every precinct, not all the ballots at 5% of the precincts. Pick your ballots truly randomly throughout the day and it's extremely unlikely that you'll miss every single discrepancy, and since the machines are supposed to be 100% accurate a difference in totals of even a single vote indicates a problem.
The big difference is that a manual count of all the ballots takes time and people. Hand-counting only 5% of the ballots takes only 5% of the time and people that hand-counting 100% would. If you don't spot any problems, you get the results faster than a hand-count would. If you do spot problems, you only lose a little time getting the hand-counting underway. And you still get all the advantages of touch-screen and similar voting machines (easy and fast to load a new ballot layout, easy to handle multiple languages, they can handle "displaying" in braille, large fonts, text-to-speech etc. for disabled voters) without the problems of having to blindly completely trust an unauditable system to produce correct results.
If we voted for the same mayor but a different dog catcher, our barcodes would differ.
No, they wouldn't. The barcodes are for each individual selection, not for the ballot as a whole. Essentially each selection you make has a unique barcode, and the barcode for that selection should be identical on every ballot where the voter selected it. So if you and I both voted for the same candidate for mayor, we should have exactly the same barcode for that race. If we voted for different dogcatchers we should have different barcodes, but each of our barcodes should be identical to everyone else who voted for the same dogcatcher we each did.
As for the time-of-day hack, what makes you think the mock election would start within the first hour of the polls opening? Depending on scheduling the machines might not be picked up until lunchtime, and the mock election might not start until 3pm. And if there's a real fear of that kind of software backdoor, you could randomize the selection so not every machine was even selected at the same time during the day (as long as all the selection and mock voting was done by the time the polls closed). With all the other checks it's unlikely any fudging of the results could get through undetected, this check is simply a final "And just in case you think you can evade the random samples, this one checks when we know exactly what every single vote was and where the machines were selected by the people most suspicious of you. Still think you can slip past unnoticed?" safeguard.
The barcode's there for faster scanning. Machines can read barcode about as fast as you can physically feed the paper through them. Reading printed letters is slower and more prone to recognition errors.
In my view the human-readable form should be authoritative. That's the one the voter could read, so in any conflict between it and the barcode you can assume if the human-readable version had been wrong the voter wouldn't have put the ballot in the ballot box. You count using the barcode, but you verify a certain percentage of ballots to make sure the barcode counts match the human-readable name counts. If there's a discrepancy, you recount all the ballots using the human-readable names and human counters. Even if the voting machines themselves and the counting machines are both compromised, this check catches it. Note that you can check barcodes easily by having a template of the barcode for each name with the bars printed right at the edge of the paper. Put the template up against the barcode to be checked and see if all the bars line up. Humans are good at spotting when they don't.
As for what's in the barcode, just publish the encoding. Then anybody (with the inclination) can decode the barcode and see that it says what it's claimed to say and nothing more.
As a final check, I'd allow observers from any interested group to each select one or two machines at random from those actually set up at polling places at the start of election day. Those machines are taken down and brought back to a central location. Those observers then get to pick one or two machines (not the one(s) they selected) and, while being watched by the other observers, cast a ballot with everyone agreeing to the actual votes cast. Then the results of this mock election are counted and the counts compared against the agreed-upon actual results. Any discrepancy triggers an automatic recount of the election based on the human-readable printing on the ballots, since the machines have just proven themselves unreliable.
The problem is, those unsecured access points cause problems for people other than the AP's owner. It's like the requirements for a driver's license: that test, and requiring you to pass it before you're allowed to drive, isn't there to insure you aren't a danger to yourself, it's there to insure you aren't a danger to everybody else on the road. Same thing here, the law's intended to eliminate the "But I didn't know!" defense when it comes to an outsider hijacking an open wireless connection.
On the first, yes you can use GPL'd software without accepting the license. The GPL itself says this explicitly. However, you cannot distribute additional copies in violation of the license. True, the law doesn't say you have to honor the license. However, the law does say that you can't legally make and distribute copies of a copyrighted work without a license from the author to do so. If you don't accept and honor the GPL, then, any distribution would be a violation of copyright law.
Note that this is why you'll never be sued for violating the GPL, you'll be sued for copyright infringement. The GPL won't be the plaintiff's tool to prosecute you, it'll be your defense against the charge. And it'll be a very flimsy defense indeed if plaintiff can point to your own failure to honor it.
As for the #includes, think about the FSF's actual argument. They may be only extern declarations, but it's not true that they don't generate any code. Every time you call one of those functions, the code to do the call is generated from the extern declaration of the function. You simply can't use the library without that code being physically in your program, even if the library's dynamically linked. That's true even for Java: the imported class declarations are the source of a chunk of bytecode to do the actual call when you use methods from those imported classes.
Now, your last has some merit. It's been long-recognized (since the IBM v. Phoenix case) that if you reverse-engineer the specs and then do a clean-room reimplementation based only on those specs and not on the original code, the result is "clean" in the copyright-infringement sense. If the GPL'd library implements some public specification while has multiple compatible implementations and your program can be built against any of those other implementations, then you could easily argue that the bits of code to do the calls fall under exceptions laid out for public specifications. The FSF probably would even agree with you. But when the library implements it's own API, not a standard one, and is the only implementation of that API, you're not going to be able to avail yourself of those exceptions. As well, the existence of the LGPL would weigh against you. If the creator had intended to let you link dynamically without invoking the GPL, he could've licensed his library under the LGPL. That he didn't argues that he intended to not allow dynamic linking without invoking the GPL. That on it's own wouldn't affect whether the FSF's reading is legally valid or not, but if theirs was found to be one of several possible valid readings it'd weigh heavily towards their reading.
And frankly, I haven't seen many important libraries that're licensed only under the GPL. Most are under LGPL-ish or BSD-ish licenses or are dual-licensed to allow for non-GPL use. There's a few exceptions, but for the most part you're going to be able to avoid using a GPL-only library in a non-GPL'd program. Given that the authors obviously intended to follow the FSF's interpretation (else they'd've used the LGPL instead), I'd say it's only polite to defer to their intent and avoid their library if you can't comply with the GPL's terms (just as you'd want them to defer to your intent and not push the edges of the license on your software).
As long as you're only using it and not making and distributing copies of it. Problem is, depending on how you use it you may have to make and distribute a copy with each copy of your program. It's that, not the use, that causes you to run into copyright law. The question is the nasty one of exactly how much library code, and of what sorts, you can include in your program while staying away from infringement. Oddly, the proprietary software companies and the media conglomerates have helped to clarify this in the GPL's favor by arguing successfully that even copying normally considered minor and uninfringing are in fact infringing and come under the purview of copyright's prohibition.
You are recasting the library's code, though. If you weren't, then the verbatim copying and republishing of a book without permission and without paying royalties to the author wouldn't be copyright infringement by exactly your logic.
Copyright law considers it. To use a library's API you #include it's header files. Those header files cause a small amount of binary code corresponding to the declarations from the library to be included in your executable. That code is minimal in physical amount, but it's crucially important because without it your program won't function. In the case of libraries with in-lined functions in the headers, even more code is included as the actual bodies of those library functions are physically copied into your executable. So even if you leave the library file out, your executable still contains copyrighted code from the library when dynamically linked. What does copyright law say about works that contain material copyrighted by others?
Even under the LGPL, static linking would require the executable to be released under the GPL. It contains copyrighted code subject to the GPL, therefore it's only distributable under the license terms. Static linking, remember, copies the entirety of the library's code into your final executable (or at least the entirety of the routines you're using). Remember that copyright isn't about modification, it's about distributing copies of someone else's copyrighted work which is very much what you're doing when you distribute an executable that's staticly linked against someone else's library. You'd need to dynamically link (which doesn't include the bulk of the code directly in the executable) to take advantage of the LGPL's exceptions.
Yes, but how's that different from any other license out there? If you use Microsoft's code in your application, you're going to have to release the result under the license terms dictated by the license you have from Microsoft to use their code. In that respect the GPL is no more viral than any proprietary software license.
As the article said, "any third party" means exactly that: any third party. So yes, if you distribute binaries with only an offer to provide source, any Joe off the street can ask for source. That's because anyone you provide binaries to can redistribute those binaries per the GPL and pass along your offer (as long as they're not redistributing commercially).
It's already addressed. GPLv2 section 3 includes an explicit statement that components normally provided with the system (eg. the system libc, compiler, etc.) do not have to be included with the source distribution. So if you used make to handle the build process you have to provide your makefiles, but you don't have to provide the make program itself since it's part of the recipient's system and normally available to them.
As far as I can tell from reading the GPLv3 drafts, there's no plan to require disclose of code when the binaries aren't actually distributed to others. The closest thing is the clause that says that if the original GPL'd Web program included the ability for the user to download the source code (eg. the PHP behind a Web site), your modified version can't remove that ability (note that if the original didn't include that functionality there's no requirement that you add it).
The FSF has already straightened this out: they created the LGPL, which you directly mentioned. They can't "straighten out" the fact that the library's author chose to license it under the GPL instead of the LGPL, since it's not their code.
Slashdot Mirror
Except that your premise is false. Firstly, the hooks aren't there to allow built-in measures to be disabled. They're there to allow non-built-in measures to be added. MS's firewall then becomes one of possibly several that can be added. Modules can be added, but no module can remove another (other than by configuring the system to not load the other module, which no module should ever have permission to do). Secondly, security and open/proprietary aren't connected. If they were, and your premise was right, then Windows would have far fewer exploits than Linux or *BSD. The fact that the reverse is true is a good indication your premise is incorrect.
The rest of your argument rests on air, and on accepting MS's definition that they are the only supplier of security in the OS. The EU's position is that MS shall not be the sole supplier. I'd note that that's true for OSX and Linux now: you probably won't go searching out third-party firewall modules, but nothing in OSX or Linux prevents someone from creating a set and completely replacing the standard firewall subsystem with their own with no loss in functionality or performance (other than that caused by their own code and their own decision whether or not to implement various bits of functionality). If MS's firewall and other security products are so good, no other company will be able to compete on the merits. The EU is merely saying that MS will have to compete on the merits, not by preventing any competition from existing at all. I'd note that blocking competition will be bad for consumers as well. We've already seen that with the Windows XP firewall: MS's offering lacks significant functionality, but the way they implemented it interferes with more capable third-party firewalls and makes them unable to function stably. I had to take a significant hit by dropping my Sygate firewall because it simply wouldn't work after XP SP2 (when it had worked perfectly for a year before, and the problems started exactly when SP2 was applied). I was more secure before MS decided theirs would be the only firewall allowed on XP.
Bear in mind that the EU isn't saying that Microsoft can't include security software in Windows Vista. What they're saying is that MS can't include it in such a way as to exclude competitors. For example, take a firewall. If MS integrates their firewall into the network stacks at the physical-code level so that no other firewall can take over, that's not allowed. However, if MS adds hooks to their network stacks to allow other modules/drivers to tap in and filter packet traffic, and then implements their firewall completely using those hooks and makes it so you can replace the loading of MS's firewall modules with a third-party firewall's modules, that's perfectly fine. And for anyone who says this can't be done, I'd point out that Linux and *BSD implement their firewalls in exactly that manner so obviously it can be done.
It's interesting the unstated assumption in the arguments against heterogenity: that any given company must support multiple platforms for heterogenity to work. I don't think that's true, though. If any given company uses a single platform, but different companies choose different single platforms, the end result is much the same overall: exploits have a much smaller target they'll work on.
And further, I don't think the arguments about the cost of supporting multiple platforms hold up. There's more than enough research supporting the contention that it takes fewer people to support Unix-based desktops than Windows-based ones, and that makes sense given the remote-admin capabilities built into desktop Unix that come from it's server roots. So suppose a company switches to a 50/50 mix of Windows and Linux desktops, and a Linux tech can support twice as many desktops as a Windows tech could. Yes, supporting two platforms costs more than supporting one. But at the same time you've just halved the number of Windows support people you need because you've got half the number of Windows desktops (assuming you've got more than 1 or 2 people could support). You need to replace them with Linux support people, but you only need 1 Linux guy added for every 2 Windows guys you're dropping. If you started with 4 Windows techs, you'd drop 2 Windows techs and add 1 Linux tech for a total of 3 techs now. That's a 25% drop in personnel costs. When figuring costs, you have to add in the reduction in personnel costs as well. Plus there's the reduction in licensing costs that offset any increase from having multiple platforms.
And finally, there's the BSA. We've all read the reports about their audits and the havoc they create. If your company's already supporting non-proprietary platforms, you're in a much better position to do an Ernie Ball if the BSA gives you grief.
When somebody in the US gambles on this website then a transaction occurs simultaneously between that person in the US and wherever the webservers are located.
Yes, but does the transaction occur where the person is, or where the webservers are? We talk about "going to" a Web site, so apparently the standard view is that the transaction happens where the Web servers are. When you buy mail-order, the sale happens at the location of the company selling the product even though you never leave your home and your order arrives on your doorstep. Why should a Web site be different?
ANY business that sells products or services globally must abide by the laws of the countries where their customers are.
Commonly that is not the rule. A store in California isn't required to abide by Utah laws just because people from Utah may shop there while on vacation. It isn't even required to ask where people are from before selling to them. And if the person from Utah buys >3.2 beer from a non-UABC store (which is highly illegal in Utah) while in California, Utah can't touch them because Utah laws aren't applicable in California even if the person buying is a Utah resident and they haven't broken any laws.
There seems to be this view that if a US citizen is involved in a transaction then that transaction must have occurred in the US. This does not seem to be the case in any conventional transaction, quite the opposite in fact. This may make it... inconvenient for certain lawmakers, but if the US wishes to make laws about what it's citizens can do then it should enforce those laws on it's own citizens.
How is he selling it in the US? His operation's located in the UK, his servers are outside the US as well. Yes people from the US can go to his site, but then people from the US can go to London too. That doesn't make London be located in the US. And when did enforcing US laws about what US citizens can and can't do become the job of a British citizen in Britain?
So if cocaine was legal in the UK and they sold it to people in the US then the feds shouldn't go after them?
If the Brits sold cocaine in Britain to US citizens who were visiting Britain at the time, and the US citizens then took it back to the US, exactly what laws that the Brits are subject to did they break? Note that US laws don't apply, British citizens in Britain are subject to British law, not US law. The US citizens probably broke some law, but note that the US citizens aren't the ones being arrested.
True, but often either package B isn't in the same bug-tracking system or team A doesn't have authorization to move the bug to someone else's package. I run into this all the time at work.
I forgot, some people may not know another aspect of C++: operator new never returns a null pointer, so checks on it aren't needed. Operator new throws an exception if it can't allocate memory, the malloc() wrapper I described simply makes malloc() in a C++ program behave the way operator new would.
If it's C++ code, there's another possibility. I use malloc() for byte buffers, but if you dig into the headers you notice something odd: the malloc() routine is actually a small macro that throws an exception if malloc() would return a null pointer. Back up in main() there's a catch block that catches all unhandled exceptions from the body of the program and terminates things as cleanly as possible. It'd be easy for a code analysis to turn up thousands of what look like unchecked memory allocations, but if they really would return NULL the check wouldn't ever get a chance to execute because of the throw.
"Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"
Could be entirely legitimate to close it. If the spec says that package B shall take ownership of the memory when passed in, then yes a bug against package A for a memory leak should be closed and refiled against B that's not honoring the spec.
"Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"
Again possibly entirely legitimate. I've written a number of low-level routines that don't do much error-checking. This fact is explicitly noted in the API spec, and responsibility for error checking is explicitly placed on the caller. That's because these routines get used in performance-critical inner loops, and the error checking should only be done once outside the loop instead of every time the loop executes. That's easier to do if you hoist responsibility for the check up to the point where the data comes in, rather than pushing it down to the lowest level. But things like that do need to be spelled out in the spec, so users of that routine know what their responsibilities are.
Except that if you're reading the ballots via OCR, you still need to check whether the results of the OCR process match the actual printing. You can't simply take it as given, any more than you can take as given that the barcodes match the printing. And I've seen the results of OCRing high-quality scans of high-quality text, and there's very few words that don't have at least one error in them. When it comes to a device correctly reading what's printed, barcode scanners are at least an order of magnitude more reliable than OCR at this point. Why introduce an error-prone step when you can introduce a less-error-prone one?
As far as random, the selection doesn't have to be cryptographically random. It just needs to be sufficiently unpredictable that our vote-rigger can't reliably figure out where he needs to avoid placing his discrepancies to avoid having one selected for a check. And he's got a tough job: he has to have every single one of his introduced errors avoid being selected (while still introducing enough errors to actually change the outcome, because if he biases the election by 2% in favor of A but B wins by 3% then the rigging fails), while we only need to catch one introduced error to foil him. Shaking the ballot box up, stacking the ballots and selecting every tenth one would suffice, even if the order's not random our rigger can't predict what the order will be until it's too late.
As far as speed, speed is desirable simply because people want to know the outcome. I wouldn't sacrifice accuracy for speed, but we have a system where we can get speed without sacrificing the ability to manually count every single ballot if needed.
NB: the system I consider best retains a physical ballot and ballot box, only using the machines to speed up the tallying process. If OVC has a step that depends entirely on the machines, that step needs eliminated. Of course, there's also another way of dealing with the problem: publish the specification, then insure that both parts of the system (the box that creates the barcode and the box that counts the votes) are created by different, unrelated companies. But I prefer a fairly direct representation of an ordinary ballot where humans can, if needed, check every single portion of the ballot. And yes, you can check barcodes using templates once you've checked that the templates match the specification. Even if the system consistently credits barcodes to the wrong candidate, the counts won't match what the humans get when they credit those barcodes to the right candidate.
we only need to tell the difference between President --> George Washington and President --> John Adams.
Exactly. What does the software do when it sees Presldont --> Goorge Washlngten because of character-recognition errors in the OCR software? Yes, that sort of thing can happen even with machine-printed text because of smudging and such. Barcode is much easier because of it's form (eg. the fact that the narrowest a wide bar can appear to be is still wider by a considerable margin than the widest a narrow bar can appear, so you can set a fairly large error margin without overlap). That all makes for a more accurate count, since there's fewer opportunities for ambiguity to creep in.
The smaller that certain percentage is, the greater a chance that an error could slip through unnoticed.
Yep. It's the same with regular paper ballots. So you pull out the statistics textbook, work out what confidence level you need in the results, then work out what percentage of the ballots you need to check to insure that confidence level. If the spot-checks turn up a discrepancy, you run a wider check. If you keep finding discrepancies, you can go all the way up to hand-counting all ballots based on the human-readable text if you have to. Personally I'd spread it around: check 5% of the ballots at every precinct, not all the ballots at 5% of the precincts. Pick your ballots truly randomly throughout the day and it's extremely unlikely that you'll miss every single discrepancy, and since the machines are supposed to be 100% accurate a difference in totals of even a single vote indicates a problem.
The big difference is that a manual count of all the ballots takes time and people. Hand-counting only 5% of the ballots takes only 5% of the time and people that hand-counting 100% would. If you don't spot any problems, you get the results faster than a hand-count would. If you do spot problems, you only lose a little time getting the hand-counting underway. And you still get all the advantages of touch-screen and similar voting machines (easy and fast to load a new ballot layout, easy to handle multiple languages, they can handle "displaying" in braille, large fonts, text-to-speech etc. for disabled voters) without the problems of having to blindly completely trust an unauditable system to produce correct results.
If we voted for the same mayor but a different dog catcher, our barcodes would differ.
No, they wouldn't. The barcodes are for each individual selection, not for the ballot as a whole. Essentially each selection you make has a unique barcode, and the barcode for that selection should be identical on every ballot where the voter selected it. So if you and I both voted for the same candidate for mayor, we should have exactly the same barcode for that race. If we voted for different dogcatchers we should have different barcodes, but each of our barcodes should be identical to everyone else who voted for the same dogcatcher we each did.
As for the time-of-day hack, what makes you think the mock election would start within the first hour of the polls opening? Depending on scheduling the machines might not be picked up until lunchtime, and the mock election might not start until 3pm. And if there's a real fear of that kind of software backdoor, you could randomize the selection so not every machine was even selected at the same time during the day (as long as all the selection and mock voting was done by the time the polls closed). With all the other checks it's unlikely any fudging of the results could get through undetected, this check is simply a final "And just in case you think you can evade the random samples, this one checks when we know exactly what every single vote was and where the machines were selected by the people most suspicious of you. Still think you can slip past unnoticed?" safeguard.
The barcode's there for faster scanning. Machines can read barcode about as fast as you can physically feed the paper through them. Reading printed letters is slower and more prone to recognition errors.
In my view the human-readable form should be authoritative. That's the one the voter could read, so in any conflict between it and the barcode you can assume if the human-readable version had been wrong the voter wouldn't have put the ballot in the ballot box. You count using the barcode, but you verify a certain percentage of ballots to make sure the barcode counts match the human-readable name counts. If there's a discrepancy, you recount all the ballots using the human-readable names and human counters. Even if the voting machines themselves and the counting machines are both compromised, this check catches it. Note that you can check barcodes easily by having a template of the barcode for each name with the bars printed right at the edge of the paper. Put the template up against the barcode to be checked and see if all the bars line up. Humans are good at spotting when they don't.
As for what's in the barcode, just publish the encoding. Then anybody (with the inclination) can decode the barcode and see that it says what it's claimed to say and nothing more.
As a final check, I'd allow observers from any interested group to each select one or two machines at random from those actually set up at polling places at the start of election day. Those machines are taken down and brought back to a central location. Those observers then get to pick one or two machines (not the one(s) they selected) and, while being watched by the other observers, cast a ballot with everyone agreeing to the actual votes cast. Then the results of this mock election are counted and the counts compared against the agreed-upon actual results. Any discrepancy triggers an automatic recount of the election based on the human-readable printing on the ballots, since the machines have just proven themselves unreliable.
The problem is, those unsecured access points cause problems for people other than the AP's owner. It's like the requirements for a driver's license: that test, and requiring you to pass it before you're allowed to drive, isn't there to insure you aren't a danger to yourself, it's there to insure you aren't a danger to everybody else on the road. Same thing here, the law's intended to eliminate the "But I didn't know!" defense when it comes to an outsider hijacking an open wireless connection.
On the first, yes you can use GPL'd software without accepting the license. The GPL itself says this explicitly. However, you cannot distribute additional copies in violation of the license. True, the law doesn't say you have to honor the license. However, the law does say that you can't legally make and distribute copies of a copyrighted work without a license from the author to do so. If you don't accept and honor the GPL, then, any distribution would be a violation of copyright law.
Note that this is why you'll never be sued for violating the GPL, you'll be sued for copyright infringement. The GPL won't be the plaintiff's tool to prosecute you, it'll be your defense against the charge. And it'll be a very flimsy defense indeed if plaintiff can point to your own failure to honor it.
As for the #includes, think about the FSF's actual argument. They may be only extern declarations, but it's not true that they don't generate any code. Every time you call one of those functions, the code to do the call is generated from the extern declaration of the function. You simply can't use the library without that code being physically in your program, even if the library's dynamically linked. That's true even for Java: the imported class declarations are the source of a chunk of bytecode to do the actual call when you use methods from those imported classes.
Now, your last has some merit. It's been long-recognized (since the IBM v. Phoenix case) that if you reverse-engineer the specs and then do a clean-room reimplementation based only on those specs and not on the original code, the result is "clean" in the copyright-infringement sense. If the GPL'd library implements some public specification while has multiple compatible implementations and your program can be built against any of those other implementations, then you could easily argue that the bits of code to do the calls fall under exceptions laid out for public specifications. The FSF probably would even agree with you. But when the library implements it's own API, not a standard one, and is the only implementation of that API, you're not going to be able to avail yourself of those exceptions. As well, the existence of the LGPL would weigh against you. If the creator had intended to let you link dynamically without invoking the GPL, he could've licensed his library under the LGPL. That he didn't argues that he intended to not allow dynamic linking without invoking the GPL. That on it's own wouldn't affect whether the FSF's reading is legally valid or not, but if theirs was found to be one of several possible valid readings it'd weigh heavily towards their reading.
And frankly, I haven't seen many important libraries that're licensed only under the GPL. Most are under LGPL-ish or BSD-ish licenses or are dual-licensed to allow for non-GPL use. There's a few exceptions, but for the most part you're going to be able to avoid using a GPL-only library in a non-GPL'd program. Given that the authors obviously intended to follow the FSF's interpretation (else they'd've used the LGPL instead), I'd say it's only polite to defer to their intent and avoid their library if you can't comply with the GPL's terms (just as you'd want them to defer to your intent and not push the edges of the license on your software).
As long as you're only using it and not making and distributing copies of it. Problem is, depending on how you use it you may have to make and distribute a copy with each copy of your program. It's that, not the use, that causes you to run into copyright law. The question is the nasty one of exactly how much library code, and of what sorts, you can include in your program while staying away from infringement. Oddly, the proprietary software companies and the media conglomerates have helped to clarify this in the GPL's favor by arguing successfully that even copying normally considered minor and uninfringing are in fact infringing and come under the purview of copyright's prohibition.
You are recasting the library's code, though. If you weren't, then the verbatim copying and republishing of a book without permission and without paying royalties to the author wouldn't be copyright infringement by exactly your logic.
Copyright law considers it. To use a library's API you #include it's header files. Those header files cause a small amount of binary code corresponding to the declarations from the library to be included in your executable. That code is minimal in physical amount, but it's crucially important because without it your program won't function. In the case of libraries with in-lined functions in the headers, even more code is included as the actual bodies of those library functions are physically copied into your executable. So even if you leave the library file out, your executable still contains copyrighted code from the library when dynamically linked. What does copyright law say about works that contain material copyrighted by others?
Even under the LGPL, static linking would require the executable to be released under the GPL. It contains copyrighted code subject to the GPL, therefore it's only distributable under the license terms. Static linking, remember, copies the entirety of the library's code into your final executable (or at least the entirety of the routines you're using). Remember that copyright isn't about modification, it's about distributing copies of someone else's copyrighted work which is very much what you're doing when you distribute an executable that's staticly linked against someone else's library. You'd need to dynamically link (which doesn't include the bulk of the code directly in the executable) to take advantage of the LGPL's exceptions.
Yes, but how's that different from any other license out there? If you use Microsoft's code in your application, you're going to have to release the result under the license terms dictated by the license you have from Microsoft to use their code. In that respect the GPL is no more viral than any proprietary software license.
As the article said, "any third party" means exactly that: any third party. So yes, if you distribute binaries with only an offer to provide source, any Joe off the street can ask for source. That's because anyone you provide binaries to can redistribute those binaries per the GPL and pass along your offer (as long as they're not redistributing commercially).
It's already addressed. GPLv2 section 3 includes an explicit statement that components normally provided with the system (eg. the system libc, compiler, etc.) do not have to be included with the source distribution. So if you used make to handle the build process you have to provide your makefiles, but you don't have to provide the make program itself since it's part of the recipient's system and normally available to them.
As far as I can tell from reading the GPLv3 drafts, there's no plan to require disclose of code when the binaries aren't actually distributed to others. The closest thing is the clause that says that if the original GPL'd Web program included the ability for the user to download the source code (eg. the PHP behind a Web site), your modified version can't remove that ability (note that if the original didn't include that functionality there's no requirement that you add it).
The FSF has already straightened this out: they created the LGPL, which you directly mentioned. They can't "straighten out" the fact that the library's author chose to license it under the GPL instead of the LGPL, since it's not their code.