[%TAGS (074db819ec% %074db819ec) %]

(074db819ec% subtitle %074db819ec)


(074db819ec%|loc%074db819ec)chronological(074db819ec% END %074db819ec) (074db819ec%|loc%074db819ec)Thread(074db819ec% END %074db819ec) 
(074db819ec% IF user.email && action == 'arc' %074db819ec)
(074db819ec%|loc%074db819ec)Reply to sender(074db819ec%END%074db819ec) (074db819ec%|loc%074db819ec)to list(074db819ec%END%074db819ec)

(074db819ec% IF user.email == 'Gregory Aharonian srctran@world.std.com' || is_owner %074db819ec) (074db819ec% END %074db819ec)
(074db819ec% END %074db819ec)

Martin asks:
>I would like to ask you what a (bad) software patents is, and
>what differentiates it from a good one?

Simple, at least for US patent law.  It has to be novel (section 102
of the US laws) in the sense that in no prior journal, conference,
book, or other publicly available media, that someone else has
disclosed the same idea prior to the filing of the patent application.

Second, it has to be nonobvious (section 103) in the sense that using
the same above sources, you can't find a couple of pieces of prior
art that combined in an obvious way would anticipate the idea.

Finally, you actually have to fully disclose the invention in the
specification (section 112), so on my computer I can recreate in
source code what you are trying to claim.

Same rules as for all other technologies.  And if the patent offices
around the world actually had the resources to do these three checks,
I suspect 80% of the issued software patents would be found invalid,
if not more.  These 80% patents are the ones I refer to as BAD
patents.

The remaining patents would be narrow enough to allow people to
financially exploit their little innovation while not creating
an undue burden on anyone else, programmers or consumers.  In such
a world, there would be few if any complaints about software patents.

In fact, in such world, we would have a better basis to argue if
there is a logical difference between a new hardware idea and a
new software idea in terms of orginality, impact on the industry,
hardware/software equivalence, etc.

But as I have argued for the last seven years, their is no really
convincing a-priori argument why software should not be patentable
while hardware should be patentable.  So let's clean up the patent
examination systems first, get rid of much of the crappy patents
that issue, and then argue philosophy.

Look, I have a degree in Physics, and a degree in Computer Science.
I fully understand the nature of the physical and of the logical.
I build devices - I build software.  Yet, I still see no reason to
differentiate between the two when it comes to patenting.  Read
Stallman's writings?  Again, as I have said before, I would rather
read Turing, Post, Godel and Church, who quite powerfully and
logically argue that the "physical" nature of something is for
the most part irrelevant.  Given any new algorithm, it is irrelevant
to understanding its nature, novelty, utility, etc. because of
whether or not is implemented in hardware, software, an optical
computer, a DNA computer, a quantum computer.  If you are going to
allow the patenting of some of these forms of expression, you have
to allow the patenting of all of these forms of expression and
embodiment.

Harmut keeps on referring to the wisdom of German court decisions
against software patents.  Insufficient.  I can just as easily to
refer to the wisdom of American court decisions in favor of
software patents.  Assuming both sets of courts are equally
competent, how can I choose between the two?  I can't.  I present
a good argument for software patents using hardware/software codesign.
Hartmut presents an argument against?  How can someone choose 
between the two?  They can't, at least easily.

So theoretical attacks against software patents, assuming they are
even valid, will not be won in the court of public opinion by
resorting to the type of legal arguments Hartmut is making when he
relies on the twenty year old (1976-1981) German court cases.

And I point out that these decisions are twenty years old because in
relying on them, I sense Hartmut has this kind of fixed view of
judicial decisions.  We see this all the time in America -
conservatives demanding that judges not waiver from the constitutional
intent of the Founding Fathers of the US in the mid 1700s.  I am sorry,
but I reject such strict adherence for two reasons.  First, the 
Founding Fathers were flawed in their actions, such as treating
African Americans as sub-white, and denying the right of women to vote.
Second, laws are meant to evolve to make better good laws.

The world of computing, the world of physicality, is much changed
from the 1976-1981 time period.  The world has become more of an
idea economy, where increasingly the new idea is all that counts
(the embodiments assigned to big factories and consultants to deal
with).  The world has more profound technologies (DNA computers,
hardware/software codesign tools, etc).  Maybe it is time to reexamine
these twenty year old German court cases to see if their logic stills
hold up.

But treating them as gospel is a good way to lose your battle
against software patents.  And using the word "suffer" insults
all of the people around the world who truly are suffering.
Programmers who complain about "suffering" because of BAD software
patents are a bunch of lazy crybabies who probably aren't writing
interesting software anyway.  Someone has a patent like LZW -
alright, let's find another way to compress and then work to get
everyone to adopt it.  That's a fun fight.  But to cry about the
Unisys patent because you are suffering and some German court
says I am suffering?  I think not.  You will convince no serious
powers that be to support your cause to get rid of software patents
(which I think is a false cause anyway).

Look, I disagree with Hartmut's and others goals to get rid of
software patents.  But I can support his attempt to do so because
it is a fun thing to argue over.  And my advice is this - don't use
"suffer" and don't rely on those German court cases - to do so is
strategically a losing proposition.  But that's my advice.

Greg Aharonian








(074db819ec%|loc%074db819ec)Archive powered by(074db819ec%END%074db819ec) MhonArc 2.6.16.

(074db819ec%TAGS [% %]%074db819ec)