Subject: Re: Why software patents are bad
From: "Karsten M. Self" <>
Date: Mon, 27 Sep 1999 17:40:32 +0000

"Stephen J. Turnbull", who's been taking his argumentum pills, wrote:
> >>>>> "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_
> license.

Remind me to ask the group what's meant by "Public License".

Work is work -- systems and, at least proprietary, software are owned by
the employer.  Even email is often presumed owned by the employer.

Installation of GPLd "Public License" software on a work system means:

 - The employer explicitly approves, allows, or certifies this.
 - The employer tacitly approves, allows, or certifies this.
 - The employee is acting as an agent of the employer.
 - The employee is installing unauthorized personal software on a work
machine. the first three cases, the employer is explicitly or through the
employee as its agent approving the terms of the public license.  In the
fourth, you've got an issue of who can and does install software on
systems.  Most shops I've worked have strict rules about installing
unauthorized software on systems (we won't discuss enforcement policies
or compliance).

> 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.

I suspect the law is not altogether fuzzy on this point.  You just
described case two.  Doesn't this "employer doesn't care" that employees
downloaded Emacs "on their own initiative" suggest tacit approval of
licensing terms?  Andy Greenberg's rather frightening comment that many
of his clients are unaware of the licensing obligations required of GPLd
software suggest that ignorance may be the norm.  It isn't, AFAIK, the

> 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.  :-)

Case 2.

> 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.

I see.  More coffee before you start next time :-)

> 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.

How about the people who are my enemy's minions, however pure their
individual consciences and objectives might be?  These aren't innocent
civilians, they're paid mercenaries.  Geneva takes the day off.

> 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."

What stops these people from loading software onto hardware they own and
control, for their own, but not the firm's, benefit?

> 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.

Well, that's a whole 'nother point.  But I still disagree.  RMS has
resorted to enforcement actions which are usually at least slightly
burdensome, but long-run, IMO, effective and in the interest of free
>     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
> GPL.

I disagree.

What is meant by "Public License"?  Is it a license that is negotiated,
one-on-one, with every member of the public, or a license which is
intended to preserve, in general, public access to code?

From the preamble to the GNU GPL (

> the GNU General Public License is intended to guarantee your 
> freedom to share and change free software--to make sure the 
> software is free for all its users.

There are conflicting freedoms.  One freedom is for all users to have
access to GPLd code.  The poison pill doctrine I've suggested doesn't
prevent employees *acting as individuals* from using free software. 
Another freedom, however, is to ensure that there are as few constraints
on the use of free software as possible.  Requiring re-issue of derived
works (e.g.:  NeXT's g++ compiler) is one such example.  NeXT was
inconvenienced by not being able to retain proprietary control of their
code, but the greater public access to the work was considered a more
important goal.  Likewise, preventing a company, its affiliates,
officers, agents, and employees from using software on behalf of the
company, when the company has violated the terms of the software
agreement, is an infringement on the freedoms of the company.  However,
lifting the burden of patent control by this company from the greater
public seems to me to be a greater good.

> 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

Is this a feature of the license, or a failing of Conglobulation Inc's
legal department to keep full and complete records?  Most companies in
recent years try to keep pretty good tabs of software use simply because
of piracy and unauthorized use concerns.  It's a major liability. 
You're really stretching it, Steve, and I don't buy it.

The employee acts (authorized or not) as an agent of the employer with
regard to his or her actions on behalf of the employer.  This is one
reason companies come up with lots of things employees shouldn't do
(purchase stuff, load software onto computers, talk to the press, enter
into binding agreements) unless they are specifically trusted to do so.

The out, if there is one, is that Conglobulation Inc. could probably say
"these were unauthorized copies of the software, we disavow knowledge
and request that damages or remedies based on intentional and knowing
infringement be dropped".  I don't think CI is going to be able to
pursue terminating actions (e.g.: patent litigation) *and* continue to
use the software.
> "Thou shalt not use this software in the employment of any company

> Uh-huh....

Uh-uh.  Not necessary.  See all of above.
> 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
> overjoyed.

Checks and balances.  Cost-benefit.  Equal and opposite reaction.  Are
you going to write off these just because there's a mutual opposition
involved?  As I see it, we've spelled out the benefits and costs, and
leave it to companies to decide.  If a company such as IBM can come up
with a document like the IBM PL, I think there's a pretty good chance we
can pull it off.
>     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).

My crystal ball can beat up your crystal ball.

We discussed this in the IEEE SW column and discussion.  IMO copyleft
provides a stronger return of development gains than other, less
restrictive, licenses.  The companies which find the poison pill terms
unpalatable will likely be in the minority.  I suspect they'll face
competitive disadvantage.  Yes, there are alternatives, and there is
software not covered by the license (Apache is dual licensed, BTW, under
Artistic and GPL, AFAIK).  Note that while xBSD are BSD licensed, apps
don't have to be.  However some of the vi alternatives, in particular,
vile, are probably BSD licensed.  vile is developed by one of the
freeBSD crew.  Hmm... Freshmeat says "free for noncommercial use" and
the ftp site has no COPYING or LICENSE file.

> 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.

What do you have to lose?  How many software patents do you currently
hold, or do you contemplate holding?  What is your risk of someone
taking your patented idea and turning it into a product which you will
have full rights to use, distribute, modify, sell, and support?  What is
the cost of not being able to use free software?

> 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.

This gets back to the nature of copyright and proving infringement. 
Unless the defendant can show exemption from exclusive rights (17 USC
107 - 121 under US law), they're almost certainly going to lose.  With
willful and intentional infringement heaped on top.  That's what makes
the poison pill effective -- copyright is a thin (expression, not ideas)
but broad (copying, distribution, modification) right.

And there's the usual GPL lawsuit paradox -- all we're really asking for
is that you keep the code free, and uphold your end of the bargain and
grant license to use of your patents.  You haven't paid us anything,
we're not asking you to pay us anything.  Moms sitting in the jury box
love it.
>     >> 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.

No, but the risk will be greatly reduced if the issues are clearly
raised.  I still doubt your view will prevail -- why should a contractor
bear risks for circumstances entirely under the client's control?  Full
disclosure would be a fair term. 

>     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.

And the larger a constituency I create.

Karsten M. Self (
    What part of "Gestalt" don't you understand?

SAS for Linux:
Mailing list:  "subscribe sas-linux" to    
  9:45am  up 4 days, 12:44,  1 user,  load average: 0.12, 0.14, 0.09