Subject: Re: IC's patent-pending technology
From: <>
Date: Wed, 27 Sep 2006 03:06:47 +0900

Jamie Lokier writes:

 > wrote:

 > > Burden, yes.  But is it a large burden compared to the work required
 > > to redevelop it?  Tom Lord bid "a few months."  What's your bid for
 > > redeveloping?

 > No, the burden is that I have to be careful, for the next 20 years,
 > not to _accidentally_ re-create the same methods in the course of
 > normal work.

So do I.  The penalties for doing so are never financial, of course---
wasted effort and the embarrassment of being scorned by the referees.
Nonetheless, I find it behooves me to know my field, especially the
stuff I've used personally in the past!

 > It doesn't matter if there's a handy library, or even if I've used and
 > paid for that library at some time.  10 years from now, there's a
 > realistic chance that one of us will happen to re-create at least one
 > of the same methods, coincidentally.

And you consider that something that should be encouraged rather than

 > > Here the semantics of "worrying" is simply "looking up prior art".  If
 > > you're not doing that already, either you're doing this for the fun of
 > > it, or we could argue that you're wasting social resources (ie, your
 > > own time and skills) on redundant work.
 > If you think that, you are not practicing the sort of software
 > development that I and many others routinely do.

No, I'm not.  To the extent that I'm a wannabe software developer, I
know that I do not know enough to routinely develop every little
algorithm.  I use Google and find out somebody else who's done it, or
look it up in Knuth or Sedgwick or the Dragon Book, or borrow it from
one of the sprawling pieces of code I know well enough to guess where
something similar might be hiding.  And I make substantial efforts to
document not only the borrowing itself, but other potentially useful
techniques I bump into along the way, for future reference.

I'm sure that for a practiced software developer the balance between
"looking it up in the library" and "what the hell, I can write this
myself" is much more toward the latter than it is for me.  How do I
know?  Because every book I've ever read on managing software
development *complains bitterly* that it is so!

 > It is unrealistic to "look up prior art" for every little
 > algorithm.

I know---even I don't have to google for a case statement.  But if
you've done it before yourself, it becomes much more realistic to
expect you to remember that there's prior art.

 > It is also unrealistic to expect that programmers will _never_
 > re-create little algorithms for the pleasure of doing so and then
 > using them.

Doing it for the fun of it is deliberately encouraged by the
International Characters covenant.  It's a shame that you can't have
fun at work, too, but nobody promised that work would be fun.  Anyway,
there are probably plenty of alternative ways to have fun developing
software.  Eg, reinventing technology that's more than 20 years old:

 > (It's not a bad thing that, e.g. hash tables are implemented over
 > and over.  They are good practice.)

They're also not patented.  There is plenty of public domain art to
use for practice, and it gets added to all the time.

And it's not obvious to me that in production code you wouldn't rather
have an extensively alpha, beta, and field tested library routine
rather than "Johnny's first hash table".

 > Also, while the entire suite of algorithms may represent real work,
 > several of the individual algorithms are quite straightforward to
 > anyone experienced in SIMD coding.

Do they claim those "straightforward individual algorithms"
individually?  If so, point out the problems on Community Patent
Review.  They'll *thank* you for that.

 > Tom Lord hit upon something appropriate in saying that, given the
 > basic idea (which is rather obvious in itself, but not always worth
 > pursuing), that the algorithms are derived rather mechanically.  That
 > is highly relevent to the question of whether they would be re-created
 > co-incidentally by future programmers.

True, but you could equally well argue that given the basic idea, an
experienced practitioner would realize that the relevant algorithms
would have *already* been "mechanically derived" and refined, and
Google for the basic idea.  The number one hit would probably be the
patent and in the sidebar there'd be an ad for licensing the patent.

I realize it's not much fun to develop software that way, but I bet it
would be miles more productive!

 > With patented methods, it is more usual to _not know_ one is

We're not talking about what's "usual"; we're talking about patents
which are brought to market a la Cameron-Rosen: run them through
"Community Patent Review", and provide a public covenant exempting
distribution as open source software and R&D from any action for
infringing the patent.

 > infringing until one has done substantial work, perhaps brought
 > something to market.

No "perhaps", in the sense that under the covenant, you're at no risk
of infringing until you take it to market (or deploy internally).

 > And then, unlike "re-implemeting readline", there is no workaround!

What, you think somebody waved a magic wand and there was libedit or
whatever it's called?  Your judgment and Tom's is that the basic idea
in the Cameron et al patent is one you could have come up with had you
found the need.  Surely you can come up with something non-infringing
that does the job, probably less efficiently---but you might even get
lucky and find something better!  How long did the RSA monopoly on
one-way functions last?

Sure, you're liable for some royalties for past sales; but even if you
decide it's not worth paying the royalties, this is basically the same
as any "brown bag" bug in a crucial module.  You face a delay to
rerelease.  It might be longer than the typical showstopper bug, and
it will be embarrassing as you've probably already taken customer
money.  Is it going to kill your firm?  Possibly, but not likely.

Is this a good thing?  No, of course not.  On the other hand, you
clearly don't think you personally are able to appropriate a fair
return from your software, yourself.  Nobody has yet found a generic
and reasonably sure way to do it without IP.  So it's one of life's
little tradeoffs.

 > Most likely, it will be buried in closed source code and remain
 > undiscovered, so risky but that's practice.  In open source code
 > (or widely published code, e.g. "shared source") it is more likely
 > to be discovered.

That's an excellent point.  Infringement is a lot more discoverable in
that case.  But guess what?  The International Characters covenant
explicitly promises not to take action against such infringement.
Which puts open source software back on the same footing as closed
source software.

 > Therefore, because of the risk of legal consequences, there is a
 > burden of having to be aware of what methods to avoid accidentally
 > re-creating.

Sure.  But the point here is, "Doesn't the International Characters
covenant dramatically decrease that burden?  Isn't that *good* for

Nobody's denying that FSBs would, by their very nature, prefer that
software patents not exist.  The question is, can we do better than
the usual practice of patent licensing?  Specifically, isn't the
International Characters covenant a clear improvement?