From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: rec.photo,alt.cd-rom,gnu.misc.discuss,misc.int-property
Subject: Re: Time to boycott Photo CD
Date: 5 Sep 92 20:02:46 GMT
	<JIMB.92Sep4013256@occs.cs.oberlin.edu>
Followup-To: rec.photo
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: jimb@occs.cs.oberlin.edu's message of 4 Sep 92 06:32:56 GMT

In article <JIMB.92Sep4013256@occs.cs.oberlin.edu> jimb@occs.cs.oberlin.edu (Jim Blandy) writes:

   The licensing requirements can only be justified if they enable Kodak
   to afford to develop Photo CD in the first place.

Call me a purist, but given that we're talking about licensing of patents,
I don't think even enabling Kodak to afford to develop Photo CD is
justification for licensing requirements.

To me, the justification for license requirements is that if Kodak could
not take advantage of the patentability of their stuff and earn license fees,
then they would be justified in not publishing descriptions of their
processes.

However, I don't believe that patents should be thought of as ways to
fund development, though that is typical these days (and one of the big
reasons people support software patents).

If Kodak wants to publish its processes as patents, then I argue they must
not be algorithm/software patents (as probably most people in gnu.misc.discuss
would, perhaps).  Patenting of matter-transforming processes generally
helps the industry as a whole (otherwise Kodak would probably just have
plants that stamped out photo CDs using processes they'd keep secret and
which society might lose if Kodak went under); and Kodak deserves to benefit
from the licensing of use of those patents.

But, if we're talking about formats and techniques for image compression,
which are _algorithms_ and software, then I don't think the patent system
should be used to offer protection to Kodak here.  If they want to publish
the info on that, great; but license requirements should not be required
of someone who reverse-engineers their software and formats.  Publishing
software systems in pretty much any form (as delivered executables on floppy
or even in ROM, for example) is sufficient as publication of the processes
they embody.  There is no need to extend patent protection to further
publication of the info when such protection requires imposition of license
fees on people using similar ideas.

   Aside from that
   concern, consumers would benefit more from having the format freely
   disseminated, for the following reasons:

Again, the patent system makes it more palatable for Kodak to publish their
formats and software processes.  Consumers benefit slightly from this
form of publication, assuming it's easier to read than machine code in ROM.
(Having seen both software patents and machine code in ROM, I claim the
latter is more readable in many cases.)

But what I think you're arguing here is that Kodak should not only publish
the formats, but do so without requiring licensing to make products that
use those techniques.

I agree completely with that -- it'd be a wise business move, at least
if Kodak is interested in more than the next, say, four quarters.

   1) Competition clearly has a positive impact on the quality of a
   technology.  You *know* why computer chips are so cheap these days.

Well, one reason is they don't have lobbyists like the insurance
industry, so the chip manufacturers have to worry about anti-trust.  :-)

   2) As Barry Margolin points out, licenses do *not* discourage poor
   implementations.  You can't judge the quality of a product by looking
   at the corporate organization of the producer.

Well, licenses do seem to discourage _inexpensive_ implementations.  In
the sense that, say, GNU C is inexpensive, but some vendors' $3000 C
development package complete with patent licenses might be poor.

   3) The wider the distribution, the faster the development.  My
   favorite illustrations of this principle are Unix and GNU Emacs.

Also, the more publicly understood the concept being distributed, the more
able it is to flexibly adapt to varying needs, and the less likely it
is to contain dangerous bugs.  (Think of that Xray machine or whatever that
turned out to have a software bug that killed several people -- if that
code had been published as free software several months _before_ the
machine was released, along with an offer of a total of, say, $100K reward
money to all those who find any serious bugs in the code prior to the machine's
release, would those victims be alive today?  I think so!  Would the machine
have ever been made under such circumstances?  It's remotely possible it
wouldn't have, but then those people would be alive just the same.  It's
very reasonable to consider legislating that any software that controls or
monitors any equipment that is actively capable of killing or seriously
injuring people must be published as PD, GPL, or similar software along with
announcements asking the public to examine the software for life-threatening
bugs.  That oughtn't to hurt companies, since they're primarily making
sophisticated hardware with simple controlling software, and unfortunately
hiring simple software programmers to do the latter task. :-)

   It's not clear to me that Kodak's patents on the Photo CD format are
   strictly necessary to support the research.

Again, I appreciate that you're essentially against what Kodak is (or appears
to be) doing, but I don't think you have to cut them even _this_ much slack!
Patents should never be necessary to support the research -- just the
publication of the results of that research.

But most people seem to make enough connections to see patents as basically
necessary to support research -- in that, without publication in some form,
it's hard to profit from research, and without some way of ensuring profits
from publication, it's hard to profit from publication.  The thing is,
when it comes to software, release to the public of the product in pretty
much any form constitutes a form of publication of its internals.  Only
productization as a service, where the software isn't released but used
internally to process requests, does software conform to the classic model
for patents.  If Kodak could productize Photo CD in a fashion whereby
decoding software was released to the public (in the form of ROM on board
the players), but even having reverse-engineered the decoding process,
the encoding process was kept secret and tightly held within Kodak
manufacturing facilities, _then_ maybe it'd be worth worrying about whether
patenting software might be allowable in such cases, so as to encourage
Kodak to publish (and thus license) the encoding process.

   I'm sure Kodak puts an
   enormous amount of effort into development of their 35mm technology,
   even though they don't have a patent on that format; if they can
   afford to develop that in the presence of other 35mm film
   manufacturers, can't they afford to do the same thing with Photo CD?

Yes, but after all, the lawyers can't afford to own several houses and
expensive cars each by just having the developers and investors get
adequately rewarded, can they?  :-)

   After all, people buy Kodak 35mm film because it's *better*, not
   because it's the *only* 35mm film available, right?

Okay, let's include marketers and advertising agencies with the developers
and investors!

   I think Kodak should have every right to copyright their code, make
   their algorithms trade secrets, concoct proprietary hardware which
   makes their implementations so fast nobody else compares, create and
   patent new WORM technology, etcetera.  But patenting the format seems
   an unnecessary measure which dampens public innovation and thereby
   hurts the public interest.  It is of value to everyone to have the
   best Photo CD technology possible.  I worry that Kodak's position may
   contribute more to Kodak's coffers than the public good.

Well, I agree with the first several sentences, but I don't particularly
share your concern in the last one -- unless you add "and does this by
further restricting the ability of the public to make use of algorithms".
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Newsgroups: rec.photo