Subject: Re: patent trolls and X-licensors
From: "Stephen J. Turnbull" <>
Date: Fri, 09 Jun 2006 20:14:04 +0900

>>>>> "Ben" == Ben Tilly <> writes:

    Ben> I do, I do, and in that case I expect to have to explain
    Ben> myself in more detail. :-)

I've greatly enjoyed and benefited from those explanations in the
past.  Thank you very much!

    Ben> Personal judgement call.

Gah.  OK, the "unpatented wavelets propagate better than patented
ones" meme goes into the "Ben T thinks so, must take seriously" bin. :-)

    Ben> [Patented techniques] can't get implemented in free software.

    >> That's a definitional problem.

    Ben> What do you mean by a definitional problem?

By definition, free software allows anyone to use it.  If you don't
own a patent whose claims are embodied in your software, you can't
apply a (truly) free license to it.  The GPL itself says that if you
know about a patent you must arrange for it to be licensed for use in
all circumstances where the software can be used (ie, use and use of
derivatives), or you may not redistribute.

BTW, IMO, that means that all GPL-licensed software, except that
distributed by copyright holders and IBM, is at minimum irresponsible
and probably fradulent.  At least if you take the "anything is
patentable and probably has been patented" rhetoric seriously.

    Ben> If I've patented my idea, and you know about it, you're going
    Ben> to be less inclined to put it into a standard unless I'm
    Ben> willing to agree to terms that mean that people can actually
    Ben> use my patent.

Eh, I think you're cheating a bit.  There's no point in creating a
standard at all if people can't actually use it!  Stripped of the
hyperbole, what exactly are you claiming?

    Ben> Even if I say that I I'm willing to license under reasonable
    Ben> and non-discriminatory terms (RAND), a lot of people are
    Ben> going to complain.  One of the big reasons why they will
    Ben> complain is because licensing fees mean that people can't
    Ben> implement the patent in free software.

If you mean that they can't do it because that would amount to a
prohibited royalty on the software, see "definitional problem".

If you mean that they can't do it because people object to paying for
value received, those people are beneath my consideration.  Well, not
completely; let me gloss that a bit.  The diamond-water paradox was
solved about 6 generations ago.  The value of a good in society is
not, and cannot, be measured by the value of resources used to produce
it.  The fairness of the division of surplus (ie, value in use - value
of resources consumed in production) is constrained by the incentives
required to make the social mechanism work.  Objecting to paying for a
copy of software merely because it didn't cost the author of the
*software* anything to produce the *copy* simply ignores the
interconnectedness of society.  Such self-serving ignorance is beneath
my notice.  Looking for mechanisms that distribute the surplus more
evenly than patents do is fair game, though.

If you mean that they can't do it because there are no social
mechanisms in place for collecting revenue on free software and paying
the patent-holder, well, what are we waiting for?  Let's get cracking
on designing those systems and comparing the costs and benefits of the
various alternatives.  One of which is abolishing patents; another of
which, I must remind you, is abolishing free software as we know it.

For example, how about socializing only the *intellectual property
rights*.  Anybody who gets value from contemplating and developing the
intellectual side of software is allowed to do so freely, but control
over economic rights stemming from actual use could be privatized.
There would be a fair use exemption for embodying patents for the
purposes of working out those new ideas.[1]

I'm sure everybody on this list is horrified by the very idea, but how
do you think non-developers would react?  "That's how it works for
*me*, anyway" seems likely to be the most common reaction, except for
people involved in P2P "sharing" of consumer goods (goods that even
rms won't say are inappropriate objects of copyright), who will be
horrified by the idea of actually paying money for something they're
used to getting for free.

    Ben> But my impression then certainly was that patents were the
    Ben> big issue for would-be implementers, and I've run across
    Ben> comments since that indicate that they remain so.

Yeah, but I don't care very much about implementation per se (for this
discussion---for personal use, yes, I know how to use FreshMeat).  The
question is whether it would actually get to market, eg, in image
content production and browser display.  I assume it's your opinion
that they would have taken it to "market" (eg, Sourceforge or the GNU
project or one of the BSDs), and there would have been uptake by
content providers?

    Ben> The [MP3] standard became widely adopted and THEN they
    Ben> started enforcing the patents.  It is exactly examples like
    Ben> that which make people leery of patents in standards.

Really, anybody who's surprised by that timing should think again (or
more likely, should start thinking for the first time).  Enforcing
patents is not cheap; it's only going to be done when the revenue
stream being threatened is mature, and defense is more profitable than

And which people?  Not Mac users; my Mac rips CDs into MP3s just fine,
and I'm pretty sure I clicked on a license for it.  Big deal
(especially since it didn't even occur to me to consider that when
thinking about buying the thing).

    Ben> Also you'll find that support for a lot of audio and video
    Ben> applications is sadly lacking on Linux because of patent
    Ben> issues.

So?  Mac OS and Windows support them just fine.  When the pin has
threads, you insert it with a screwdriver, not a hammer.  That is not
a "problem" with threads.

There's also the problem of the boycott of proprietary software
proclaimed by the GNU Project, which is a very big factor in Linux
users' consumption habits.  I wouldn't be surprised if you start to
see growth in patented software for Linux as the population of Linux
users with more money than brains and/or free software scruples grows.

    >> Nor did the Unisys patent really put a dent in the market for
    >> GIF.

    Ben> See the above comment about submarine patents.  Also note
    Ben> that the Unisys patent only affected encoders - decoders
    Ben> weren't touched.

Sure.  AFAIK the same is true for MPEG enforcement.  Accident?  I
don't think so.

    Ben> The famous example [of an innovation that the organization
    Ben> was unable to exploit] that people like to offer is Xerox and
    Ben> the GUI.  But it is not isolated.

    >> >> Emacs and GNU comes to mind. :-)

    Ben> You wouldn't be biased, would you? :-)

    >> I am, but (at least until quite recently) in the direction
    >> opposite to the one you imply.  Sad, isn't it?

    Ben> Odd, I'd thought that you'd be biased because you were a fan
    Ben> of XEmacs and that whole Emacs vs XEmacs split.  Which
    Ben> happened a while ago.

Well, I have to admit that I think Emacs would be a lot better today
if rms had let Lucid install its improvements into the main line, and
*then* got to work on the things that were important to him.  But I
didn't think it really mattered; there was plenty of room in Emacs
space for a bunch of on-the-edge types playing with Mule and eye
candy, and another bunch doing the deadly serious world's-best-editor

Unfortunately, today the Emacs community simply is uninterested in
doing any of the things needed to keep it relevant to the IDE market
(outside of its historical niche, of course).  That's important
because Emacs is too big to be "just an editor."  Emacs is still the
best text editor available, but it no longer clearly justifies the
effort of learning Emacs, unless you're willing to buy into some of
the major applications (eg, MUAs) at the same time.  Not everybody is,
and I sure can't blame them.

We lost one of our brightest guys (Hrvoje Niksic, who also wrote wget)
because after a 2-year leave due to military service and health
problems, he came back and looked around and said "Emacs is all the
editor I'll ever need---and has been since v18.55 (1988 or so).  I
can't afford to spend time on it anymore, because my current needs are
being addressed by Python and Eclipse and Mozilla, not by any of the
Emacsen."  I can't disagree.

And there's no excuse for any of that.  Lisp *can* compete with Python
(at least for veteran Lispers), but Emacs Lisp cannot---nobody in
their right mind writes batch scripts in Emacs Lisp (except for
maintaining Emacs).  Lucid Emacs and Energize *could* have given Emacs
a 10 year head start on Eclipse, but seems to me we're about 5 years
*behind*.  In 1995 the only browser that could properly handle the
Japanese web was w3.el on a Mule-patched Emacs, but today w3.el can't
handle the modern web at all----lynx does better.

You bet I think it would all be different if a company (or consortium)
with paying customers had been funding the Emacs mainline for the last
15 years.  But until Hrvoje left, I didn't really think it much
mattered.  The various Emacsen would survive, and prosper.  But Hrvoje
forced me to take a serious look at what the Emacs community was
doing, and not doing.  I see no real way to avoid the conclusion that
Emacs has connived at making itself quite irrelevant to the great
majority of programmers (other than a reasonable option as an editor,
and many would not even concede that), and current policies are going
to make the gaps described above grow rapidly.

Those policies are mostly rooted in GNU's political goals, and the
enormous conservatism of Emacs hackers.

    Ben> However I'll note that I have yet to hear of a real case of
    Ben> someone who needed to solve a technical problem choosing to
    Ben> solve it by doing a patent search looking for a previous
    Ben> solution.

    >> Don't you think that's the saddest thing you've written today?

    Ben> Not particularly.  It is the wrong tool for the job.

That's what I consider sad!

    Ben> What distinguishes a good business from a great one is
    Ben> execution.  Which depends on a ton of small details.  For
    Ben> instance one recent subtle interface tweak increased our
    Ben> profit margin by over 20%.  You could spend weeks analyzing
    Ben> our site and not even notice the change that is responsible.
    Ben> We could face a direct competitor without that tweak and bid
    Ben> up their cost of advertising to the point where we make money
    Ben> and they don't.

And if you patented it, you could give it to them (at a price), and
both of you keep your costs down.  But you clearly don't plan to give
it to anybody, or even post an URL here and ask us to look for it
ourselves.  Right?

    >> Have you forgotten the GNU Manifesto?  We don't hack for money.
    >> The immediate effect of improving appropriability of short-term
    >> gains is not going to be on basic researchers.

    Ben> There is a lot of pressure on universities to judge
    Ben> themselves based on how many patents they get and business
    Ben> they generate.  That pressure does affect basic researchers,
    Ben> even if it reasonably shouldn't.

Sure.  Which is partly due to an unfortunate historical organization.
For an opposite case, take economics.  There are basically two kinds:
financial economists, and the rest of us.  The finance guys are all in
business schools, where they *do* come under a lot of pressure to
generate licensable technology.  Nobody's ever bugged me about
licensable technology, though, and I don't think they ever will.

Granted, in computer science it's harder to disentangle by field, but
it seems to me that the social effects are just as important.  If you
start splitting computer science departments into IT groups in
engineering schools and business schools, and computer science
departments proper, in whatever division your university keeps math
and physics, I suspect the basic researchers in CS proper would feel
only slightly more pressure to patent than I do.

    >> I misdoubt that [the problems of free OCR] were due to lack of
    >> availability of free licenses to wavelet patents.

    Ben> Fair enough.  I haven't looked at OCR, you have.

Don't be too hasty; just as you generalize from your experiences, I
generalize from mine. :-)

Everywhere I look (not just in computers), I see losses from "tweaks"
and "best practices" that never get propagated because they're either
trade secrets or simply because nobody's looking for them.  I may be
biased; "unused tweak" losses are rampant in university teaching, and
absolutely huge in Japanese universities.

I think they're big enough to justify some strong forms of
intellectual property.  Not the patent system current in the U.S., but
it might look more like that than like no-patents-at-all.

    Ben> Did you try

    >>> I haven't tried the OCR yet, but that's not for want of trying
    >>> to build the software.  [...]  In the meantime, I use the free
    >>> as in free beer products.  I don't even have to build
    >>> those. :-)

    Ben> No criticism meant.

Oh, none felt.  Anyway, I would never bother to defend against
criticism on this point.  ;-)

My point is that free software all too often results in "solutions"
that are unusable unless you have more brains than money, and probably
more time on your hands than both money and brains put together.
IMHO, society should be arranging the rules for these markets to
benefit those who have more money than they have brains, and more
brains than they have time, and not so much of any of the above in the
first place.

[1]  For me it would be merely a return to my roots.  When I first
started working with publically distributed source, that's actually
what I thought "free software" meant.  I had no trouble classifying
"no commercial use" licenses like Ghostscript's Aladdin license as
"free".  They're actually "free"-er than what I would have demanded

Graduate School of Systems and Information Engineering   University of Tsukuba        Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
        Economics of Information Communication and Computation Systems
          Experimental Economics, Microeconomic Theory, Game Theory