Subject: Re: Why software patents are bad
From: "Stephen J. Turnbull" <>
Date: Mon, 27 Sep 1999 18:25:04 +0900 (JST)

>>>>> "kms" == Karsten M Self <> writes:

    kms> If, as I understand it now, you mean that all employees (and
    kms> other directly employed|contracted agents) of the company,
    kms> who aquire license to the free software through the employer
    kms> and for the purpose of doing work for the employer,

What's this "through the employer" noise?  The GPL is a _public_

Prove that they did not download Emacs from on their own
initiative, and use it, not for the benefit of their employer, but
simply because the employer doesn't care.

It would take some gall to argue that that is true of a farm of 100
Apache/GNU/Linux web servers, but I could see the guy who spent three
years and 1500 hours of overtime taking all the credit for the Linux
installation on the witness stand, saying that it was over the
opposition of the entire corporate management.  :-)

Obviously, the servers are owned by the employer; is it necessarily
_legally_ true that the software running on them must be considered to 
be licensed by the employer?  I dunno.

    kms> Frankly I don't understand your POV on this.  Yes, it's a
    kms> pain for the company (and people) involved, but that's sort
    kms> of the point -- to raise the consequences of patent
    kms> infringement activities against free software.

Be careful.  Causing pain to people who are not your enemy in order
to "get the point across" to your real enemy is a violation of the
Geneva Convention.  It is taking hostages.  _Of course_ that's the
point; but that's what every terrorist says.

What did the people who joined this company do that deserves
termination of the license _according to the principles of free
software_?  I say, "nothing."

If this is strategically a good idea, that's OK with me.  But I don't
think it accords with the ideals of free software.

    kms> My question is: who is the licensee?  Conglobulation Inc. or
    kms> the individual employees.

The GPL is a _public_ license.  The individual employees are
licensees, and I don't see that it is _anyone_'s business what they
use Emacs or Linux for or where, as long as they do not violate the

Remember, _the only document related to the use of XEmacs on my
workstation is /usr/doc/XEmacs/COPYING_; the legal department of
Conglobulation Inc has no idea what software the company has
implicitly licensed by my use of XEmacs.  My possession of that
document (including the poison pill clause) binds _me_ not to take IP
infringement action against any free software.  I think you would have
to explicitly word the license as

"Thou shalt not use this software in the employment of any company
prosecuting infringement against free software, and thou shalt be
aware that this license becomes null and void if you employer should
in the future decide upon such prosecution; your ignorance of the
details of your employer's patent portfolio is no excuse."


You might have grounds to take action against a big departmental
server running Poison Pill Linux, but I think that the nature of
public licenses makes it possible for a good lawyer to give you a run
for your money.  I think it would be extremely difficult to take
action against tools which are clearly personal, like Emacs, and not
easy to take action against tools that are clearly for the convenience
of the individual administrator and not part of the actual
organization-visible system, such as the GNU fileutils.  It might be
hard to take action against Linux itself running on personal

    kms> What we *have* done is to create a constituency within
    kms> Conglobulation Inc. which can argue that CI's patent
    kms> enforcement policies are causing real harm to the company.

You've also created a different consituency within CI which argues
that the permissive use of "poison pill" free software puts the
company's property rights at risk.  Excuse me if I'm less than

    kms> I also disagree with your evaluation of the scope and breadth
    kms> of free software.  Because of the cost, adaptability, and
    kms> utility of the stuff, I expect it to become basic
    kms> infrastructure in much of computing, networking, and
    kms> communications -- an essential facility, if you will.

Free software yes; "poison pill" stuff, no.  Linux?  Hah!  Screw that,
install FreeBSD; the networking, especially NFS, is better anyway.
Apache is already XFree-style licensed.  Emacs?  Well, vi is less
bloated anyway, and there are BSD-licensed clones (I'm guessing).

This is risky, because the poison pill is inapplicable to a lot of the
software you are implicitly thinking about.  And people who are
already leaning toward non-viral licenses may see reason to lean even
harder away from "poison pill" licenses.  That's just a guess, of
course, but I know which way I'm personally leaning at the moment.

If you're right, the collateral damage will be small.  I suspect that
during the transition period, though, the collateral damage will be
90% of the damage.

    kms> CI will find that when it comes down to it, they simply won't
    kms> have a choice between patents and free software, it will be
    kms> patents or continuing business operations in an internet age.
    kms> This will be the case for virtually *any* CI of more than a
    kms> few score employees operating in the US, EU, or Asia --
    kms> certainly the bulk of the software patent holders we're
    kms> concerned with.

Prove that they're using versions of the software covered by the
poison pill, and not older ones.

Now show me how to do that without a court order.  Expensive.

    >> How about independent consultants trying to provide free
    >> software solutions to large corporations, any of which may very
    >> well have some software patents they might like to enforce?

    kms> Fair point.  Though this would probably be pretty well hashed
    kms> out after the first couple of times it occured.  I'd expect
    kms> to see a contracting agreement which doesn't hold the
    kms> contractor liable for encumberances on use of a product which
    kms> result from the client's actions WRT the license for the
    kms> product.

Expect to see a clause which reduces the consultants' revenue in such
an event, unless the potential risk to the client was fully explained
in advance; in which case the total fee will probably be negotiated
down, or there will be a completion bonus, or something like that.
You can't expect the corporate client to bear all that risk, whatever
you think of the fairness.

    kms> This is a straw man, IMO.

Of course the specific disaster scenario is.  The costs and
inefficiencies which preventing the disaster entails are real.  More
annoying than anything else, I would suppose.  But real.
    kms> The previously discussed "corporate veil piercing" methods
    kms> should probably cover this case, however.  If the association
    kms> is sufficiently weak between product and tech, the company
    kms> risks a buyout of their technology -- presumably not an
    kms> acceptable risk.

The more effectively you pierce the veil, the more hostages you take,
of course.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
What are those two straight lines for?  "Free software rules."