Subject: Re: IC's patent-pending technology
From: "Ben Tilly" <>
Date: Tue, 26 Sep 2006 18:40:06 -0700

On 9/26/06, <> wrote:
> Ben Tilly writes:
>  > On 9/25/06, Lawrence Rosen <> wrote:
>  > [...]
>  > > FSB might instead help us understand how such patent claims (assuming they
>  > > are valid) might affect free software businesses.
>  > [...]
>  >
>  > Let me just address this point and this point only.
>  >
>  > With the license grant as I understand it, this patent cannot be
>  > included in any open source software that wishes to be possibly used
>  > commercially.  That might include being pre-installed on a computer,
>  > sold on a commercial CD, be embedded in a commercial OS, etc.
> It can't be distributed together the commercially usable portion.  It
> could, however, be distributed separately (in your leading example of
> Debian, in "non-free" along with Aladdin Ghostscript).  Am I missing
> something?  (Of course Debian might choose not to do so, but I don't
> see any "can't".)

You said the same thing with a different spin.  Saying that they can
include it but not in the part that is commercially usable is the same
as saying that it can't be included in the part that wishes to
possibly be used commercially.  You're focussing on what they can do,
I am focussing on what they can't.

>  > by projects such as Perl, Mozilla, Apache or Open Office.  Any
>  > proprietary competitor to those projects would, of course, be able to
>  > negotiate a license and practice the patent.
>  > Could it actually be used by any free software?  Yes, it could.  For
>  > instance while Perl can't use it, one could put up a CPAN module to do
>  > fast Unicode processing.  However it can't be used by any "big"
>  > projects,
> In what sense is CPAN not "a big project"?  If it's in CPAN, in what
> sense can't Perl use it?  Ask Russ Nelson about the usability of
> various patches with qmail---a CPAN module would be much easier than
> that, no?

CPAN is only "a big project" in the same sense that Sourceforge is.
CPAN is a collection of many independent small projects.  Very few
have any importance.  The aggregate collection has considerable value.

Of interest here is that CPAN comes with very few license guarantees.
You have to look at the license of every module you're interested in.
Some of them might not be usable for many people who might want to use
them.  (Random example, Finance::Quote is not usable commercially
without violating Yahoo's terms and conditions.)  This is already the
case, so adding a module that is patent encumbered in an odd way isn't
a significant change.

>  > To the extent that rapid XML processing is valuable, the result is a
>  > resounding negative for free software.  And is therefore negative for
>  > any business that is built on free software.
> Not so fast.  "To the extent that a faster CPU is valuable, faster
> proprietary CPUs are a resounding negative for free software."  What's
> the difference?  (I'm serious.)

The difference is that I think it is easier to run free software on
proprietary CPUs than it is to achieve wide integration of free and
not quite free software.  I may be wrong, but that is my opinion.  (We
were asked for opinions.)

>  > In my opinion it would be far more useful for free software and for
>  > free software businesses if you, say, gave a license for pure software
>  > implementations in GPLed software.
> They don't want to do that, and I don't blame them:

It is their choice to do that.

>  > Sure, some people you want money from could do an end run around
>  > you.
> In Ghostscript's case, that was just about the whole market, no?

The problem there is that Ghostscript had a limited number of truly
compelling features to add, and the restrictions of the GPL were not
an issue for their key customers.

> While the scope of this patent is much less than the scope of
> Ghostscript in a printer or fax, hardware manufacturers might be
> willing to free their second-best firmware for a competitive benchmark
> on low-end products, while licensing the patent for the top-of-line
> product---or simply specializing in the low-end, and cobbling together
> their firmware from freely available or cheap modules.

I was thinking that their ideal market was more likely to be someone
like Microsoft.  (If, that is, you could get Microsoft to be honest
and not just infringe on the theory that infringement would be hard to

>  > And, speaking practically, the makers of a proprietary product will
>  > have more of an incentive to license from you if they find that they
>  > are losing benchmarks against someone that can practice the license
>  > when they can't.
> I'm sure it'll be available from CPAN, I imagine there will be a
> modapache_icxml in short order, etc.

Available from CPAN doesn't mean widely used.

> So they will be losing benchmarks, or will be shown similar benchmark
> comparisons; International Characters marketroids will see to that.

Now *that* can be accomplished no matter how widely it is used.

>  > If nobody else is using the technique and their software is already
>  > seen as "fast enough", then they have little incentive to spend
>  > serious money on you.  Sure, you might sell them a license, but
>  > you'll probably get less for it.
> You have no way to guess at probability.  The more competition there
> is, the less profit there will be in IC's client markets.  So they may
> get a bigger share of the proprietary profit if there's better free
> competition, but it will be of a smaller pie.

Oh I definitely do have a way to guess at probability.  I just guess! ;-)

In the long run if free competition beats the proprietary products,
potential revenue from Windows, OS X, Office, etc could go away.  But
then they can go after the OEM market.  And this issue may be moot
since I suspect that the long run won't happen until after the patent

You raise good points, but my opinion remains just that.  My opinion.