Canadians tends to talk about speed and distance in kilometres, distances on a golf course in
yards, milk and gasoline in litres (and when they say a quart of milk everyone knows they mean a litre of milk),
liquor in ounces, temperature in Celsius in Canada but Fahrenheit in the U.S. (e.g., it's 30 degrees in Toronto,
but 85 in Buffalo), food weights in kilograms, and a person's weight and height in pounds and feet + inches.
A bizarre polyglot, but not as bad as their cereal boxes, n'est-ce pas?
In software development, you may safely assume that developer salaries is the majority of the cost. I know - I'm a manager
of software development.
You should go through the list and add up the costs. It's not that great. For example, it's hard to imagine
having more than one manager and one secretary per 10 developers. Hardware is dirt cheap (a few thousand per
year at most). Electricity and office space likewise, at least compared to a developer's salary. Health insurance
is a serious expense, but still only a fraction of the cost.
And if SCO is paying $1.5 million for coffee, the management should be fired tomorrow. A dollar or two per day per employee,
that's it.
Trust me, $8 million per year buys a lot more than 10 developers.
SCO's quarterly financial reports say different.
They state about $2 million in research and development costs
for the last reported quarter. If we assume that to be mostly
salaries, then that's about 50 developers.
SCO also makes software releases regularly containing many
new feature.
And now, a moment of silence in mourning over SCO's imminent demise...
that's long enough.
Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.
So where is the word simplicity in all of this? Anybody that has learned to use C++ really well has,
to my mind, earned the equivalent of a Master's degree. This makes C++ a brilliant failure. So to learn D
will we require the equivalent of a PhD?
Good designers make things both simpler and more powerful. They improve the product as much
through subtraction as addition. Instead we get this...
and Walter has continued to add more and more features.
Touching the brakes so that the brake lights come on
causes people to naturally back off. They get a little nervous
cause they figure I might slam on the brakes at any time
(they can't tell that I only taped the brake lightly).
This is hardly "humiliating." Most probably just think I
use the brakes too much. But they do tend to back off a little.
Might I suggest that this practise actually does more good
than harm, given the danger that tailgaters put me in.
But that aside, I've always believed in standing up to bullies
(i.e., tailgaters). One of the reasons they tailgate is because
no one calls them on it. Avoiding confrontation because
"it'll only make matters worse" is nonsense.
The courts require something quantitive. A police office
saying "the accused was driving real close to the car in front of him" doesn't cut it.
The courts want to know precisely how close, and how the police
officer knows this.
I just touch my brakes so that the brake lights go on, but the car doesn't slow down.
This drives some tailgaters nuts. One of them pulled up beside me at a red light
and told me I just about caused an accident. This perhaps should have taught him
something about his own habits, but given that tailgaters are pretty much by definition stupid,
I'm not optimistic.
I don't recommend this strategy unless you box or something.
You forgot to add following at the end of your post:
This posting is an attempt at humor
If you do not have a sense of humor,
or do not appreciate my specific style of humour,
then I recommend you limit yourself to moderating or replying to postings
that do not contain such humorous elements.
Such fundamental confusion about the nature of science is everywhere.
How can one, even in principle, prove that anything is safe?
No matter how many studies one has that fail to detect a hazard,
there is always a chance that the hazard was too subtle to be statistically detectable,
or was of a type of hazard that wasn't investigated (e.g., hearing loss or arthritis).
It's the old saying - you can't prove a negative. Actually, you can't prove
anything in science. You can only present evidence.
But how will we ever find our way to "Toutes Directions" and "Autres Directions"?
The locals only seem to want to direct tourists to some place called
"Mangez LeMerde", which I've never heard of.
You're talking about patents where there are hundreds of millions of dollars at stake. Those are exceptional, and may well be worth contesting. The vast majority of patents aren't in that league. It's these patents - the ones where only moderate amounts of dollars are involved - that people don't bother to contest, but can still create considerable amount of frustration when they are vague, ambiguous, or overbroad.
It's a simple matter of economics: It can cost as little as a few tens of thousands of dollars to be develop a
patent, but it costs at a minimum hundreds of thousands of dollars to contest it.
That improved seismic data is not something you can "see or touch" would come as a massive surprize to people in the industry. And your definition of "software patent" has now been expandeded to include all of data processing.
Such processing has been patented in the seismic industry long before they were using computers
to do the work (e.g., "CDP stacking"). Sometimes they used hardware and sometimes people (which is allowed in a patent so long as the people are not excercising professional judgement). And trying to distinguish between an "idea" and an "invention" is completely unworkable in practise.
This gets to the very root of the problem - given that computer chips are found everywhere, defining "software patents" in a way that clearly delineates what is meant, and is not easily got around, is remarkably difficult.
My comment on the suffocating aspects of patents was particularly directed towards vague and overbroad patents. Although in principle they can be overturned, in practise (as my last post discussed) it's seldom worth
the effort. Instead companies tend to bear the costs of working around them. My view on patents would be immensely improved if they were all of high quality and well explained.
My patents are on the processing of seismic data for petroleum exploration (6,798,714 and 6,895,336), an area some might consider dangerously close to software patents (although I don't think the words "computer", "software", or "program" ever appear in the text).
I am ambivalent about them. On the one hand, I like to see my company fully benefit from my work. On the other
hand, people (including academics) avoid further research in these areas because they would have to
license from us to benefit from their own work.
The question is not whether it's desirable to allow patents for graphics rendering - that call I leave up to you.
The question is can we disallow it without creating a legal quagmire that causes a lot of unintended side effects?
No, of course not. Why would you possibly think that it would?
I don't. I asked a question in order to point out the problems with forbidding software patents.
Most "software patents" do not involve just stand-alone software. Even ignoring the computer, they involve externalities of some kind. As an example, a patent on a graphical rendering algorithm ultimately involves the displaying and viewing of the results.
With a little creativity, software can almost always be presented as a component of the invention, rather than its
entirety, thus making it very difficult in practise to define and forbid a "software patent".
Actually I have better than half a clue on how the patent system works. I have two patents
to my name (in geophysics, not software), which means I have spent a lot of time being
lectured on the system by IP professionals.
Here's the problem...
All patents are assumed to be valid by the courts until ruled otherwise. This means that
the holder of the patent is in the driver's seat.
If you want to contest a patent, it's going to cost you a million
bucks if your lucky (and much more if you're not), plus an extraordinary amount of
personal effort and distraction that could continue for years.
Most people don't want to spend the rest of their lives talking to lawyers, nor can
small companies afford the money, risk, or distraction, so they just work around the patent
as if it were valid.
Don't believe that that's how it works? Talk to an IP lawyer.
In the case of your carburator, you could certainly patent a new carburator design that happened to include software. What you can't patent is the idea of using software in a carburator.
Agreed on both counts. But here's a third question: Could you patent the software without reference to the carburator? Answer: No because software, in and of itself, is not useful. It has to be applied to some real world problem for it be useful, and thus patentable.
So given that, what do people mean when they say "software patent"?
I have been in much the same situation - vague, overbroad, ambiguous patents that seem to cover the earth.
In theory they should be easily contestable - in practise they are suffocating.
This has less to do with software patents, per se, than just bad patents in general.
Well, that's kind of my original point. It's incredibly difficult to define "software patent" in a
meaningful way, unless you mean the patenting of a pure algorithm unconnected to any useful application, which is already disallowed.
I'm interested (truly). Could you name, with U.S. patent number, specific computing algorithms that have been patented but which had no reference to one or more specific useful real-life applications?
Regarding the trivial and obvious, that is already unpatentable, at least in theory. In so far as the need to better weed them out in practise, we are in full agreement.
You can only patent an invention as a whole. You can't patent a list of components which,
if combined with some other undisclosed parts (e.g., software),
might do something useful in a novel way.
The simple question "what is a software patent?" is suprizingly difficult.
For example, if you were
to design a new carburator, there's an excellent chance that software
would be a key component in its preferred embodiment. If so, does this
disallow a patent? And if so, does that
mean replacing any component in a patented invention with software
protect you from allegations of patent violation?
But what about inventions that are pure computing? Well, patented inventions that only involve
computing are rarer, because pure computing doesn't actually do much good.
That's just moving electrons around. There generally are real-world components and
ramifications to the thing - otherwise, why bother? Even the infamous one-click shopping
patent involves the exchange of money for goods - thus software is only a one part of it.
I would think a bullet-proof definition of software patents is needed before they can be forbidden.
Slashdot Mirror
A bizarre polyglot, but not as bad as their cereal boxes, n'est-ce pas?
And I assumed about $160,000 per employee per year. $100,000 per developer is optimistic, although possible under some circumstances.
You should go through the list and add up the costs. It's not that great. For example, it's hard to imagine having more than one manager and one secretary per 10 developers. Hardware is dirt cheap (a few thousand per year at most). Electricity and office space likewise, at least compared to a developer's salary. Health insurance is a serious expense, but still only a fraction of the cost.
And if SCO is paying $1.5 million for coffee, the management should be fired tomorrow. A dollar or two per day per employee, that's it.
Trust me, $8 million per year buys a lot more than 10 developers.
SCO's quarterly financial reports say different. They state about $2 million in research and development costs for the last reported quarter. If we assume that to be mostly salaries, then that's about 50 developers. SCO also makes software releases regularly containing many new feature. And now, a moment of silence in mourning over SCO's imminent demise ...
that's long enough.
If D is cleaner and simpler than C++ then they should advertise that aggressively. I would consider it a critical point.
Bloody hell.Good designers make things both simpler and more powerful. They improve the product as much through subtraction as addition. Instead we get this...
This is hardly "humiliating." Most probably just think I use the brakes too much. But they do tend to back off a little.
Might I suggest that this practise actually does more good than harm, given the danger that tailgaters put me in.
But that aside, I've always believed in standing up to bullies (i.e., tailgaters). One of the reasons they tailgate is because no one calls them on it. Avoiding confrontation because "it'll only make matters worse" is nonsense.
Your point escapes me. What's this got to do with the fact that courts like things to be measured?
The courts require something quantitive. A police office saying "the accused was driving real close to the car in front of him" doesn't cut it. The courts want to know precisely how close, and how the police officer knows this.
This drives some tailgaters nuts. One of them pulled up beside me at a red light and told me I just about caused an accident. This perhaps should have taught him something about his own habits, but given that tailgaters are pretty much by definition stupid, I'm not optimistic.
I don't recommend this strategy unless you box or something.
That'll learn 'em.
No matter how many studies one has that fail to detect a hazard, there is always a chance that the hazard was too subtle to be statistically detectable, or was of a type of hazard that wasn't investigated (e.g., hearing loss or arthritis).
It's the old saying - you can't prove a negative. Actually, you can't prove anything in science. You can only present evidence.
But how will we ever find our way to "Toutes Directions" and "Autres Directions"? The locals only seem to want to direct tourists to some place called "Mangez LeMerde", which I've never heard of.
Given the sociophobic nature of software developers, that is no small thing.
It's a simple matter of economics: It can cost as little as a few tens of thousands of dollars to be develop a patent, but it costs at a minimum hundreds of thousands of dollars to contest it.
That improved seismic data is not something you can "see or touch" would come as a massive surprize to people in the industry. And your definition of "software patent" has now been expandeded to include all of data processing. Such processing has been patented in the seismic industry long before they were using computers to do the work (e.g., "CDP stacking"). Sometimes they used hardware and sometimes people (which is allowed in a patent so long as the people are not excercising professional judgement). And trying to distinguish between an "idea" and an "invention" is completely unworkable in practise.
This gets to the very root of the problem - given that computer chips are found everywhere, defining "software patents" in a way that clearly delineates what is meant, and is not easily got around, is remarkably difficult.
My patents are on the processing of seismic data for petroleum exploration (6,798,714 and 6,895,336), an area some might consider dangerously close to software patents (although I don't think the words "computer", "software", or "program" ever appear in the text).
I am ambivalent about them. On the one hand, I like to see my company fully benefit from my work. On the other hand, people (including academics) avoid further research in these areas because they would have to license from us to benefit from their own work.
The question is not whether it's desirable to allow patents for graphics rendering - that call I leave up to you. The question is can we disallow it without creating a legal quagmire that causes a lot of unintended side effects?
Most "software patents" do not involve just stand-alone software. Even ignoring the computer, they involve externalities of some kind. As an example, a patent on a graphical rendering algorithm ultimately involves the displaying and viewing of the results.
With a little creativity, software can almost always be presented as a component of the invention, rather than its entirety, thus making it very difficult in practise to define and forbid a "software patent".
Here's the problem...
All patents are assumed to be valid by the courts until ruled otherwise. This means that the holder of the patent is in the driver's seat. If you want to contest a patent, it's going to cost you a million bucks if your lucky (and much more if you're not), plus an extraordinary amount of personal effort and distraction that could continue for years.
Most people don't want to spend the rest of their lives talking to lawyers, nor can small companies afford the money, risk, or distraction, so they just work around the patent as if it were valid.
Don't believe that that's how it works? Talk to an IP lawyer.
Agreed on both counts. But here's a third question: Could you patent the software without reference to the carburator? Answer: No because software, in and of itself, is not useful. It has to be applied to some real world problem for it be useful, and thus patentable.
So given that, what do people mean when they say "software patent"?
This has less to do with software patents, per se, than just bad patents in general.
Well, that's kind of my original point. It's incredibly difficult to define "software patent" in a meaningful way, unless you mean the patenting of a pure algorithm unconnected to any useful application, which is already disallowed.
Regarding the trivial and obvious, that is already unpatentable, at least in theory. In so far as the need to better weed them out in practise, we are in full agreement.
You can only patent an invention as a whole. You can't patent a list of components which, if combined with some other undisclosed parts (e.g., software), might do something useful in a novel way.
The simple question "what is a software patent?" is suprizingly difficult.
For example, if you were to design a new carburator, there's an excellent chance that software would be a key component in its preferred embodiment. If so, does this disallow a patent? And if so, does that mean replacing any component in a patented invention with software protect you from allegations of patent violation?
But what about inventions that are pure computing? Well, patented inventions that only involve computing are rarer, because pure computing doesn't actually do much good. That's just moving electrons around. There generally are real-world components and ramifications to the thing - otherwise, why bother? Even the infamous one-click shopping patent involves the exchange of money for goods - thus software is only a one part of it.
I would think a bullet-proof definition of software patents is needed before they can be forbidden.