Why can't you do the same thing, and send an email to the developers of the GPL'd package asking whether your specific use case is acceptable?
Given that the entire point of the GPL is to encourage sharing and collectively-developed code, is it not reasonable to assume that in general there may be many contributors in such a scenario, each of whom would need to be contacted individually for their view, and all of whose views would then need to be reconciled?
In addition to that, you're essentially arguing that companies have to perform due diligence if they want to use the GPL but not otherwise.
No, I'm arguing that the cost of performing that due diligence is often prohibitively high in the GPL case, while it is typically very low in a typical commercial deal.
analogy, n. a similarity between like features of two things, on which a comparison may be based.
I was simply trying to make a point concisely. If I'd known this many people would nitpick the metaphor rather than get the point, I would have just made the point longhand, as I've now done several times anyway. And the point itself is valid, regardless of whether you like the parallel I drew between the legal idea and the tendency for people defending making money from GPL'd software to cite the same tiny number of examples without ever showing a viable generalisation.
I have encountered numerous problems in recent years with Java code that simply doesn't work on IcedTea. It's not doing anything clever or undocumented. It runs fine on Windows, on MacOS, and on the same Linux boxes but with a different Java run-time. On some of these projects, we had so many problems that we explicitly no longer support IcedTea and won't even consider support requests from customers who insist on using it.
I don't know about any other JREs based on OpenJDK, but IcedTea is so bug-ridden as to be unusable, and has been for a long time.
So maybe the FSF should go on a public relations campaign to explain the GPL so that lawyers aren't afraid of it.
It won't make any difference. The only thing that matters is the words in the licence. Once they've finished writing the licence and other people start using it, the FSF's opinion or interpretation is irrelevant, and every lawyer knows this.
It might be the antidote to all the FUD people spread about it.
The thing is, there is uncertainty and doubt in the GPL. It's specifically written that way. For example, the GPLv2 uses several words that lawyers choose very carefully to leave scope for interpretation in individual cases, the exact meaning of which in any given case will be determined by a court if necessary.
That style might match the philosophy of the FSF/GPL crowd very well. It might work effectively for the kinds of project they are hoping to support, where everyone is obviously compliant and happy to share all of their own code under the GPL anyway. On the other hand, it creates genuine legal concerns for businesses who need to know exactly where the boundaries fall, and there are consequences to doing that.
I thought we were talking about use cases; not development.
I'm talking about the context set up by the eric conspiracy in the post early in this thread to which I originally replied, which I assumed to mean we were talking about development.
Obviously, if you are attempting to circumvent the GPL by distributing proprietary software based on it but pretending it isn't based on it then you are going to have problems.
My point is that, particularly in the case of library-like code, "based on it" is often ambiguous. As new ways to connect code together evolve, it is not necessarily clear even whether the original authors who chose a GPL-family licence would approve of a particular usage, and certainly not clear whether the licence legally permits it. This sort of uncontrollable risk is anathema to lawyers, and therefore many businesses will simply walk away rather than risk any contact with GPL-infected code (or spend a lot of time and money checking out the implications for each specific project before approving the use of that GPL'd code).
Proprietary licenses are ambiguous too. It's pretty close to impossible to write something that isn't open to interpretation whatsoever.
I completely agree with you that removing all scope for ambiguity in legal terms is hard. To me, the distinction is transparent motivation.
If you're going to link with a commercial library, then the library vendor wants you to pay for it. They have nothing to gain from harassing legitimate customers who pay their dues. It's mostly a black-and-white requirement, and you can usually resolve any ambiguity that might exist in advance by simply asking the library vendor how much you need to pay in your particular circumstances. Companies are well used to keeping track of such agreements and of what they have paid for, so there is a clear record and everyone knows what the deal is.
On the other hand, if you're going to link with something in Open Source land, then the motivation of the people giving it to you is more abstract. The licence includes words like "reasonable" and "customarily" that are deliberately subject to interpretation. Moreover, because you are not directly giving them anything in return, from a legal point of view the contractual situation is completely different. Now the company is necessarily in a legal grey area, which in turn means lawyers and technical people need to do serious risk assessments, take steps to mitigate any fall-out if they do get it wrong in the eyes of a court considering the question later, etc. Or they could just save the fortune that exercise would cost and spend the money on a commercial solution instead, which is what a lot of places do.
It's probably true that if you're A) planning on distributing the thing you're using GPL code in, and B) not planning to publish your own code under the GPL, you'd probably be best off to check with the lawyers before you do it. But that is far from the only scenario under which a company might use GPL code.
Sure. I'm restricting my comments to the scenario originally set out by the eric conspiracy in the post I originally replied to. He was talking about including Open Source code in products he was supplying, which I am assuming means we're talking about software development rather than end user products here.
Which is why I think a blanket ban is silly.
I think the point is not whether a legal/technical analysis would find using some variation of GPL'd code to be acceptable. Given unlimited time and money to explore the implications for a particular project, it might well do. The point is that the costs to perform that analysis, determine those implications, and risk getting it wrong, are higher than for a typical commercial deal and often they simply aren't worth it. The inherent ambiguity in using the GPL, as I set out above, carries a heavy cost and "prices the GPL'd code out of the market".
Hobbyists used to share their stuff as freeware, and many would provide the source code on request to anyone interested, without anyone's legalese telling them they had to do it. And of course you have things like BSD, which arguably triggered, or at least catalysed, the whole FOSS movement as we see it today.
Of course that sort of sharing happened much less often in the days when we had to type in programs from magazines or get the source off a cover disk or BBS, but the spirit was similar. If you're going to discuss the widespread adoption of Open Source projects, I would argue that this also coincided with the rise of the Internet, which in turn facilitated much easier sharing of code and ideas than ever before, and that this could just as easily explain everything without any reference to the (L)GPL.
There are no problems with any standard use cases with the GPL.
If that were true, we would not have had two decades of debate over which of the ever-evolving technologies for combining code constituted links between independent and separate works, thus exempting part of the overall product from the GPL.
I'm not a lawyer either, but I have spent a fair bit of time working with lawyers on related matters, from which I've reached the following conclusions.
My take is that it's not the specifics of the GPL that usually cause the problems, but the ambiguities. With a proprietary library, once you've paid your cash for redistribution rights, it's reasonably clear that you're OK. With the GPL, you might think you are doing something acceptable, but unless you've got someone who understands all of the law, the GPL, and the technical details of your project -- and the world doesn't have many such people to go around -- you're never quite sure.
If you build a project that uses a GPL'd library for some significant function and then someone does come after you later, then yes, there are probably going to be options other than giving away the farm, but they are going to be seriously expensive one way or another, through disruption if not through direct costs. From a management point of view, it may well be better to pay cold, hard cash for a "real" product that controls the risk, rather than betting on a "free" product with an unquantified risk attached.
The thing is, even typical proprietary software licences are better than the GPL family in some respects. You're not going to accidentally give away your code because you linked to a runtime library that came with Visual Studio, or because you wrote a Photoshop plug-in or Word macro. Call a function in a library that is GPL'd and find that someone disagreed with your assessment of how strong the linkage was (or, God forbid, call a function that ever came within 100 miles of a computer once owned by someone who read the Affero GPL in a past life) and you can find your business giving away rights it didn't intend to, named and shamed on someone's web page, or even literally in court. When that's the kind of culture that is following the FSF around, it is hardly surprising that a lot of reputable companies with cautious legal departments won't touch anything GPL-infected with a barge pole.
Why would you say that? There are many very reasonable concerns about using GPL'd software that have nothing to do with Microsoft, starting with the fact that some of the most basic use cases are ambiguously specified.
So tell me, o mighty spouter of clichés, what the fuck your statement has it to do with the question at hand?
If you can't immediately see the answer to that question, then you could always look up the old legal concept properly and educate yourself. Here, let me Google that for you. Perhaps next time, you'll have the courtesy to do so before you resort to knee-jerk ad hominem attacks.
The point of the original legal idea was that if you start enumerating specific counter-examples then you are creating a presumption that the general case holds. In this context, while obviously we're talking about economics rather than law, the same basic idea makes sense: any time someone asks about commercial viability of GPL'd software, the same tiny number of companies that make money based around such software get trotted out as counter-examples. (Don't agree? Try Google again, this time to see how many other examples you can find by searching the history of Slashdot. It won't take you long.) Given that it is easy to cite numerous companies that make money via other means, this suggests that perhaps making money from GPL'd software really is relatively difficult, thus backing up the comment by InsightIn140Bytes above.
Yes, I've heard similar stories many times in recent years. You see small companies that don't want anything to do with it because they're afraid of risks they don't fully understand. And you see large companies that don't want anything to do with it because their legal departments are well aware of the risks and issue company-wide bans, and you don't argue with company-wide bans from Legal.
So the entire academic community is wrong and you're right. OK. You're not one of those people in denial, despite perpetuating fallacies that have been debunked on numerous occasions.
Also, nice strawman at the end, and an ad hominem thrown in for good measure.
I notice that despite telling us lots about what studies say or have shown, you haven't actually cited a single source throughout our discussion here. I assume therefore that you are simply trolling.
So your answer to a report that cites numerous studies from around with world, carried out by different research groups with varying methodologies, over many years, which collectively paint a remarkably consistent picture, is: the studies are surely fundamentally unrealistic (what, all of them, in the same way?) and I must be biased and looking for selective data to support a predetermined conclusion? Seriously?
Again, we don't have to speculate. You are as free as I am to look up the citations in the report I linked to and see exactly how they conducted their studies and what potential errors they sought to control. You might also like to look up some of the different studies cited by other posters elsewhere in this Slashdot discussion. Had you bothered to do so, you would realise how desperate you look by appealing to hypothetical errors like not accounting for people dropping a phone in their lap. (Hint: Many of the studies have shown that hands-free kits are almost as dangerous as hand-held phones, so why would you think that strange behaviour would actually help anyway?)
I'm fairly sure one of us is indeed looking for cherry-picked results to support a predetermined outcome. I just think you're mistaken about which of us it is.
The incremental improvement is not nearly enough to justify stripping the majority of responsible people of yet more liberty.
Responsible people don't use their phones while driving, unless the risk in not doing so outweighs the risk of doing so as it might in genuine emergencies.
Also, if a responsible person is going to cite a popular quotation, they look it up first to ensure they get it right. Franklin actually said:
They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety.
In this case, I wouldn't consider a right to use a mobile phone while driving to be "essential" other than in emergencies, and the safety benefit is not temporary but a permanent improvement in driving standards, particularly among those who are starting at a lower standard anyway, with the consequent reduction in KSI statistics for road traffic accidents.
OK, I'm going to insert this here, since it's always disappointing to see the delusions in threads like this one and it's about time we had some actual data.
Here's a report (PDF) from the Royal Society for the Prevention of Accidents (RoSPA) in the UK, published a few years ago around the time we started banning handheld mobile phone use while driving. It cites numerous formal studies. Not all of them reported statistically significant results in all scenarios, but many did and the overall picture is clear. Below are some choice quotations.
Firstly, the bottom line:
Many studies, using a variety of different research techniques, have reached the same conclusions. Using a mobile phone while driving adversely affects driver performance in a number of different ways. It impairs:
Maintenance of lane position
Maintenance of appropriate and predictable speed
Maintenance of appropriate following distances from vehicles in front
Reaction times
Judgement and acceptance of safe gaps in traffic
General awareness of other traffic.
Much of the research has assessed using hands-free phones and demonstrates that these still distract drivers and impair safe driving ability, even when driving automatic cars, which are arguably easier to drive than the manual transmission cars predominantly used in the UK.
There is also evidence that using a mobile phone while driving causes greater problems for those drivers who already have a higher accident risk, namely young, novice drivers and elderly drivers.
Next, an example on the subject of denial:
Interviews with nine people who regularly used a hands-free mobile phone for work-related calls while driving revealed that they did not believe that using the phone affected their driving performance because they could adapt their speed or end the call if necessary. However, when they participated in simulated driving tasks of varying complexity on a computer (not a driving simulator) and had to respond to mobile phone calls, their performance was significantly worse during both simple and more complex phone conversations. So, although they did not believe using the phone affected their driving, in reality it did.
It turns out that not all calls are equally distracting, but the difference is not huge:
In another study, 150 subjects observed a video of driving sequences containing situations to which drivers would be expected to respond. Each situation occurred when the subjects were placing a mobile phone call, conducting a simple conversation on a mobile phone, conducting a complex conversation, tuning a radio, and with no distraction. All the distractions led to significant increases in both the number of situations to which the subjects failed to respond and the time it took to respond to them. Complex phone conversations created the greatest distraction and simple conversations the least. The likelihood of a driver failing to notice and respond to a highway-traffic situation ranged from 20% when placing a call or holding a simple phone conversation to 29% for holding a complex phone conversation. Subjects over 50 years old were significantly more likely to fail to respond than younger (17-25 years) subjects.
So how bad is performance while distracted by using a mobile phone? Almost twice as bad as being on the legal drink-drive limit, it seems:
Before the drives, the subjects consumed either an alcoholic drink to take them up to the UK legal drink drive limit of 80 mg/100 ml or a similar looking and tasting placebo drink. During each drive the drivers answered a standard set of questions and conversed over a mobile phone.
On average, drivers’ reaction times were 50% slower when using a hand-held mobile phone than under normal driving conditions, and 30% slower than when under the in
That argument is only worth anything if there is Free Software available that is (and will remain) as good as anything they could build in house, or at least "good enough". The number of areas where this is actually true is rather small, and might even be negligible if we're talking about software to go with specialist proprietary hardware, where NDAs and extensive waits before you even get access to the detailed specs are not uncommon.
I suspect that if they aren't competitive on the hardware, a few extra bits of binary-only software won't help.
If by "not competitive" you mean "inferior", then maybe that's true. If the hardware is essentially a commodity within the industry, in that any competitor willing to throw enough money at the problem could build the same kind of solution, then maybe the software is a big distinguishing factor. I'm not sure from the OP's description that this is the case here, though.
If other people manage to make better hardware at the same or lower price, they'll figure out how to make better software as well.
That does not follow at all.
/guy who pays a significant part of his rent writing better software than his clients' competitors, while the hardware on which it runs is broadly similar to what those competitors sell, thus giving his clients a significant commercial advantage.
I hate "pinned" apps. If it's not open I don't need it "pretending" to be open on my task bar. It's already got a desktop shortcut.
I really like pinned apps, jump lists, and not having to care whether a document-centric application is already loaded any more.
There are plenty of usability things I do think they screw up in Windows 7, particularly relating to the basic Explorer window and command prompt, but I don't count pinned apps among them.
Slashdot Mirror
Why can't you do the same thing, and send an email to the developers of the GPL'd package asking whether your specific use case is acceptable?
Given that the entire point of the GPL is to encourage sharing and collectively-developed code, is it not reasonable to assume that in general there may be many contributors in such a scenario, each of whom would need to be contacted individually for their view, and all of whose views would then need to be reconciled?
In addition to that, you're essentially arguing that companies have to perform due diligence if they want to use the GPL but not otherwise.
No, I'm arguing that the cost of performing that due diligence is often prohibitively high in the GPL case, while it is typically very low in a typical commercial deal.
In legal usage - the only correct one
analogy, n. a similarity between like features of two things, on which a comparison may be based.
I was simply trying to make a point concisely. If I'd known this many people would nitpick the metaphor rather than get the point, I would have just made the point longhand, as I've now done several times anyway. And the point itself is valid, regardless of whether you like the parallel I drew between the legal idea and the tendency for people defending making money from GPL'd software to cite the same tiny number of examples without ever showing a viable generalisation.
I have encountered numerous problems in recent years with Java code that simply doesn't work on IcedTea. It's not doing anything clever or undocumented. It runs fine on Windows, on MacOS, and on the same Linux boxes but with a different Java run-time. On some of these projects, we had so many problems that we explicitly no longer support IcedTea and won't even consider support requests from customers who insist on using it.
I don't know about any other JREs based on OpenJDK, but IcedTea is so bug-ridden as to be unusable, and has been for a long time.
So maybe the FSF should go on a public relations campaign to explain the GPL so that lawyers aren't afraid of it.
It won't make any difference. The only thing that matters is the words in the licence. Once they've finished writing the licence and other people start using it, the FSF's opinion or interpretation is irrelevant, and every lawyer knows this.
It might be the antidote to all the FUD people spread about it.
The thing is, there is uncertainty and doubt in the GPL. It's specifically written that way. For example, the GPLv2 uses several words that lawyers choose very carefully to leave scope for interpretation in individual cases, the exact meaning of which in any given case will be determined by a court if necessary.
That style might match the philosophy of the FSF/GPL crowd very well. It might work effectively for the kinds of project they are hoping to support, where everyone is obviously compliant and happy to share all of their own code under the GPL anyway. On the other hand, it creates genuine legal concerns for businesses who need to know exactly where the boundaries fall, and there are consequences to doing that.
I thought we were talking about use cases; not development.
I'm talking about the context set up by the eric conspiracy in the post early in this thread to which I originally replied, which I assumed to mean we were talking about development.
Obviously, if you are attempting to circumvent the GPL by distributing proprietary software based on it but pretending it isn't based on it then you are going to have problems.
My point is that, particularly in the case of library-like code, "based on it" is often ambiguous. As new ways to connect code together evolve, it is not necessarily clear even whether the original authors who chose a GPL-family licence would approve of a particular usage, and certainly not clear whether the licence legally permits it. This sort of uncontrollable risk is anathema to lawyers, and therefore many businesses will simply walk away rather than risk any contact with GPL-infected code (or spend a lot of time and money checking out the implications for each specific project before approving the use of that GPL'd code).
Proprietary licenses are ambiguous too. It's pretty close to impossible to write something that isn't open to interpretation whatsoever.
I completely agree with you that removing all scope for ambiguity in legal terms is hard. To me, the distinction is transparent motivation.
If you're going to link with a commercial library, then the library vendor wants you to pay for it. They have nothing to gain from harassing legitimate customers who pay their dues. It's mostly a black-and-white requirement, and you can usually resolve any ambiguity that might exist in advance by simply asking the library vendor how much you need to pay in your particular circumstances. Companies are well used to keeping track of such agreements and of what they have paid for, so there is a clear record and everyone knows what the deal is.
On the other hand, if you're going to link with something in Open Source land, then the motivation of the people giving it to you is more abstract. The licence includes words like "reasonable" and "customarily" that are deliberately subject to interpretation. Moreover, because you are not directly giving them anything in return, from a legal point of view the contractual situation is completely different. Now the company is necessarily in a legal grey area, which in turn means lawyers and technical people need to do serious risk assessments, take steps to mitigate any fall-out if they do get it wrong in the eyes of a court considering the question later, etc. Or they could just save the fortune that exercise would cost and spend the money on a commercial solution instead, which is what a lot of places do.
It's probably true that if you're A) planning on distributing the thing you're using GPL code in, and B) not planning to publish your own code under the GPL, you'd probably be best off to check with the lawyers before you do it. But that is far from the only scenario under which a company might use GPL code.
Sure. I'm restricting my comments to the scenario originally set out by the eric conspiracy in the post I originally replied to. He was talking about including Open Source code in products he was supplying, which I am assuming means we're talking about software development rather than end user products here.
Which is why I think a blanket ban is silly.
I think the point is not whether a legal/technical analysis would find using some variation of GPL'd code to be acceptable. Given unlimited time and money to explore the implications for a particular project, it might well do. The point is that the costs to perform that analysis, determine those implications, and risk getting it wrong, are higher than for a typical commercial deal and often they simply aren't worth it. The inherent ambiguity in using the GPL, as I set out above, carries a heavy cost and "prices the GPL'd code out of the market".
#include <obvious_correlation_causation_fallacy.h>
Hobbyists used to share their stuff as freeware, and many would provide the source code on request to anyone interested, without anyone's legalese telling them they had to do it. And of course you have things like BSD, which arguably triggered, or at least catalysed, the whole FOSS movement as we see it today.
Of course that sort of sharing happened much less often in the days when we had to type in programs from magazines or get the source off a cover disk or BBS, but the spirit was similar. If you're going to discuss the widespread adoption of Open Source projects, I would argue that this also coincided with the rise of the Internet, which in turn facilitated much easier sharing of code and ideas than ever before, and that this could just as easily explain everything without any reference to the (L)GPL.
There are no problems with any standard use cases with the GPL.
If that were true, we would not have had two decades of debate over which of the ever-evolving technologies for combining code constituted links between independent and separate works, thus exempting part of the overall product from the GPL.
I'm not a lawyer either, but I have spent a fair bit of time working with lawyers on related matters, from which I've reached the following conclusions.
My take is that it's not the specifics of the GPL that usually cause the problems, but the ambiguities. With a proprietary library, once you've paid your cash for redistribution rights, it's reasonably clear that you're OK. With the GPL, you might think you are doing something acceptable, but unless you've got someone who understands all of the law, the GPL, and the technical details of your project -- and the world doesn't have many such people to go around -- you're never quite sure.
If you build a project that uses a GPL'd library for some significant function and then someone does come after you later, then yes, there are probably going to be options other than giving away the farm, but they are going to be seriously expensive one way or another, through disruption if not through direct costs. From a management point of view, it may well be better to pay cold, hard cash for a "real" product that controls the risk, rather than betting on a "free" product with an unquantified risk attached.
The thing is, even typical proprietary software licences are better than the GPL family in some respects. You're not going to accidentally give away your code because you linked to a runtime library that came with Visual Studio, or because you wrote a Photoshop plug-in or Word macro. Call a function in a library that is GPL'd and find that someone disagreed with your assessment of how strong the linkage was (or, God forbid, call a function that ever came within 100 miles of a computer once owned by someone who read the Affero GPL in a past life) and you can find your business giving away rights it didn't intend to, named and shamed on someone's web page, or even literally in court. When that's the kind of culture that is following the FSF around, it is hardly surprising that a lot of reputable companies with cautious legal departments won't touch anything GPL-infected with a barge pole.
The common idiom is a complete misunderstanding
Of course it is. But I was using the term in its original spirit, hence the mention of etymology.
And since it's not a logical term, I'm not sure why you compare it to logical fallacies.
Why would you say that? There are many very reasonable concerns about using GPL'd software that have nothing to do with Microsoft, starting with the fact that some of the most basic use cases are ambiguously specified.
So tell me, o mighty spouter of clichés, what the fuck your statement has it to do with the question at hand?
If you can't immediately see the answer to that question, then you could always look up the old legal concept properly and educate yourself. Here, let me Google that for you. Perhaps next time, you'll have the courtesy to do so before you resort to knee-jerk ad hominem attacks.
The point of the original legal idea was that if you start enumerating specific counter-examples then you are creating a presumption that the general case holds. In this context, while obviously we're talking about economics rather than law, the same basic idea makes sense: any time someone asks about commercial viability of GPL'd software, the same tiny number of companies that make money based around such software get trotted out as counter-examples. (Don't agree? Try Google again, this time to see how many other examples you can find by searching the history of Slashdot. It won't take you long.) Given that it is easy to cite numerous companies that make money via other means, this suggests that perhaps making money from GPL'd software really is relatively difficult, thus backing up the comment by InsightIn140Bytes above.
That's not what it actually means at all.
The fact that people defending the commercial viability of GPL'd software always trot out the same tiny number of examples is incredibly telling.
Yes, I've heard similar stories many times in recent years. You see small companies that don't want anything to do with it because they're afraid of risks they don't fully understand. And you see large companies that don't want anything to do with it because their legal departments are well aware of the risks and issue company-wide bans, and you don't argue with company-wide bans from Legal.
Are you familiar with the phrase "the exception that proves the rule" (and its etymology)?
I have yet to see any evidence that GPL creates more benefit for society than any other FOSS licence. Can you provide anything?
For personal use, not everyone is in it for the money. <shrug>
And as far as the political aspects, to most companies GPL == toxic, and they don't care about the details.
So the entire academic community is wrong and you're right. OK. You're not one of those people in denial, despite perpetuating fallacies that have been debunked on numerous occasions.
Also, nice strawman at the end, and an ad hominem thrown in for good measure.
I notice that despite telling us lots about what studies say or have shown, you haven't actually cited a single source throughout our discussion here. I assume therefore that you are simply trolling.
So your answer to a report that cites numerous studies from around with world, carried out by different research groups with varying methodologies, over many years, which collectively paint a remarkably consistent picture, is: the studies are surely fundamentally unrealistic (what, all of them, in the same way?) and I must be biased and looking for selective data to support a predetermined conclusion? Seriously?
Again, we don't have to speculate. You are as free as I am to look up the citations in the report I linked to and see exactly how they conducted their studies and what potential errors they sought to control. You might also like to look up some of the different studies cited by other posters elsewhere in this Slashdot discussion. Had you bothered to do so, you would realise how desperate you look by appealing to hypothetical errors like not accounting for people dropping a phone in their lap. (Hint: Many of the studies have shown that hands-free kits are almost as dangerous as hand-held phones, so why would you think that strange behaviour would actually help anyway?)
I'm fairly sure one of us is indeed looking for cherry-picked results to support a predetermined outcome. I just think you're mistaken about which of us it is.
The incremental improvement is not nearly enough to justify stripping the majority of responsible people of yet more liberty.
Responsible people don't use their phones while driving, unless the risk in not doing so outweighs the risk of doing so as it might in genuine emergencies.
Also, if a responsible person is going to cite a popular quotation, they look it up first to ensure they get it right. Franklin actually said:
They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety.
In this case, I wouldn't consider a right to use a mobile phone while driving to be "essential" other than in emergencies, and the safety benefit is not temporary but a permanent improvement in driving standards, particularly among those who are starting at a lower standard anyway, with the consequent reduction in KSI statistics for road traffic accidents.
OK, I'm going to insert this here, since it's always disappointing to see the delusions in threads like this one and it's about time we had some actual data.
Here's a report (PDF) from the Royal Society for the Prevention of Accidents (RoSPA) in the UK, published a few years ago around the time we started banning handheld mobile phone use while driving. It cites numerous formal studies. Not all of them reported statistically significant results in all scenarios, but many did and the overall picture is clear. Below are some choice quotations.
Firstly, the bottom line:
Many studies, using a variety of different research techniques, have reached the same conclusions. Using a mobile phone while driving adversely affects driver performance in a number of different ways. It impairs:
Much of the research has assessed using hands-free phones and demonstrates that these still distract drivers and impair safe driving ability, even when driving automatic cars, which are arguably easier to drive than the manual transmission cars predominantly used in the UK.
There is also evidence that using a mobile phone while driving causes greater problems for those drivers who already have a higher accident risk, namely young, novice drivers and elderly drivers.
Next, an example on the subject of denial:
Interviews with nine people who regularly used a hands-free mobile phone for work-related calls while driving revealed that they did not believe that using the phone affected their driving performance because they could adapt their speed or end the call if necessary. However, when they participated in simulated driving tasks of varying complexity on a computer (not a driving simulator) and had to respond to mobile phone calls, their performance was significantly worse during both simple and more complex phone conversations. So, although they did not believe using the phone affected their driving, in reality it did.
It turns out that not all calls are equally distracting, but the difference is not huge:
In another study, 150 subjects observed a video of driving sequences containing situations to which drivers would be expected to respond. Each situation occurred when the subjects were placing a mobile phone call, conducting a simple conversation on a mobile phone, conducting a complex conversation, tuning a radio, and with no distraction. All the distractions led to significant increases in both the number of situations to which the subjects failed to respond and the time it took to respond to them. Complex phone conversations created the greatest distraction and simple conversations the least. The likelihood of a driver failing to notice and respond to a highway-traffic situation ranged from 20% when placing a call or holding a simple phone conversation to 29% for holding a complex phone conversation. Subjects over 50 years old were significantly more likely to fail to respond than younger (17-25 years) subjects.
So how bad is performance while distracted by using a mobile phone? Almost twice as bad as being on the legal drink-drive limit, it seems:
Before the drives, the subjects consumed either an alcoholic drink to take them up to the UK legal drink drive limit of 80 mg/100 ml or a similar looking and tasting placebo drink. During each drive the drivers answered a standard set of questions and conversed over a mobile phone.
On average, drivers’ reaction times were 50% slower when using a hand-held mobile phone than under normal driving conditions, and 30% slower than when under the in
That argument is only worth anything if there is Free Software available that is (and will remain) as good as anything they could build in house, or at least "good enough". The number of areas where this is actually true is rather small, and might even be negligible if we're talking about software to go with specialist proprietary hardware, where NDAs and extensive waits before you even get access to the detailed specs are not uncommon.
I suspect that if they aren't competitive on the hardware, a few extra bits of binary-only software won't help.
If by "not competitive" you mean "inferior", then maybe that's true. If the hardware is essentially a commodity within the industry, in that any competitor willing to throw enough money at the problem could build the same kind of solution, then maybe the software is a big distinguishing factor. I'm not sure from the OP's description that this is the case here, though.
If other people manage to make better hardware at the same or lower price, they'll figure out how to make better software as well.
That does not follow at all.
/guy who pays a significant part of his rent writing better software than his clients' competitors, while the hardware on which it runs is broadly similar to what those competitors sell, thus giving his clients a significant commercial advantage.
I hate "pinned" apps. If it's not open I don't need it "pretending" to be open on my task bar. It's already got a desktop shortcut.
I really like pinned apps, jump lists, and not having to care whether a document-centric application is already loaded any more.
There are plenty of usability things I do think they screw up in Windows 7, particularly relating to the basic Explorer window and command prompt, but I don't count pinned apps among them.