Subject: RE: Updated Sender-ID License Faq (was acceptable use)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 1 Sep 2004 13:12:01 -0700

The issue here is whether it is possible to add Sender-ID technology
to a GPL licensed mailer and distribute the technology with the
mailer itself.

Let us for the sake of argument stipulate that there is a conflict,
that it is not possible to distribute the technology itself under
the GPL. My point is that the GPL does not prevent the distribution
of Sender-ID technology for GPL licensed mailers.

It is still possible to distribute the code under a separate OSS
license. Since most OSS mailers appear to already be taking the 
same approach with SSL (another patent encumbered technology) this
does not seem to be a big deal.

It is also possible for the copyright holder to vary the license.
VeriSign has distributed the same code under the GPL and a commercial
license for several years, there is nothing in the GPL to prohibit
this, the copyright was never transfered to the FSF. 

The terms of the license itself are only invariant if the code
distribution has forked so that there is a QMail type situation
where the party that holds the copyright is not the party wanting
to maintain the code.

What we have here is like someone claiming that the telephone
system discriminates against themselves because they have made a 
vow of silence. 

One of the reasons we chose making the CERN libwww code (the
basis for Mosaic) public domain, not GPL was because we thought 
GPL too restrictive.

It is rather ironic that the GPL seems to insist on patents being
put in the public domain in their entirety in order to allow the
distribution of copyright code. The GPL dates from an era when
code was expensive and there were few patent rights. The logical
approach for the GPL to take would be to treat patents in the
same way as code, with a viral poison pill defense. Instead the
demand is for unilateral disarmament.

I think that people are missing the real threat here. Let us 
assume that the precedent is set that absolutely no encumbered 
technology of any sort is going to be allowed in an IETF spec,
regardless of the license terms offered. It seems to me that 
this would provide a very effective way to shut down all 
future developoment of OSS, merely claiming to have applied
for a patent would be sufficient to stop any and every new
development. 

As the problem of patent trolls increases the chances of any new
technology being entirely unencumbered becomes vanishingly small.

---

From: Alan Hodgson <[email-masked]>
Date: Wed, 1 Sep 2004 14:22:02 -0700

> of Sender-ID technology for GPL licensed mailers.

I don't see how this solves the problem.  The problem is that the license
appears to prohibit source code redistribution.  This would affect all FOSS
products equally.

Yes, you can make a Sender-ID implementation available, but you can only
distribute it directly to end users.  It doesn't seem to matter what license
you put on it, so I don't see why the emphasis here is on the GPL.  Much of the
value of open source is the multitude of distributions, mirrors and sites like
Sourceforge that distribute the code to users.

So, while it is perfectly possible to do so, I believe this will unreasonably
inhibit adoption of the standard.   Sender-ID will likely not appear in open
source OS distributions.  Sender-ID will likely not appear in standard
distributions of MTA's and MUA's, Webmail systems, etc.  Even the Sendmail
statement said they'd have to make it available as a separate download.  Sure,
people who really want it might be able to get it, but that isn't going to
result in widespread adoption.  Without MTA adoption, the incentive to publish
is low.

I suggest, therefore, that with the current license requirements, that this
standard be rejected and a non-encumbered alternative be considered.

-- 
"You can only protect your liberties in this world by protecting the other
man's freedom. You can only be free if I am free." -- Clarence Darrow

---

From: Paul Iadonisi <[email-masked]>
Date: Wed, 01 Sep 2004 17:54:41 -0400

> to a GPL licensed mailer and distribute the technology with the

  It is more than that.  I bring up the GPL more than anything else
because it is the license I know best.  As others have pointed out, the
GPL is not the only license with which this patent license is
incompatible.

> the GPL.

  It is much more than 'for the sake of argument'.  You are implying
what you have asserted elsewhere: that they are not incompatible.  Yet
you have only asserted it and have not successfully countered what three
lawyers have said and zero lawyers have countered: that the patent
license is not only incompatible with the GPL, but many, if not all
other FOSS licenses.

>  My point is that the GPL does not prevent the distribution

  Like others before you, you are forgetting about aggregations.  This
patent license does not meet the standards for distribution with Red
Hat's Fedora Core, or Debian GNU/Linux and no software encumbered by it
can be (re)distributed with either collection, and I'm sure many others.

> does not seem to be a big deal.

  I am not aware of what patents cover SSL, but your argument is
incomplete without a description of the license terms.  This is, I fully
acknowledge, something I am not too familiar with and intend to read up
on, especially since there is a work in progress library (gnutls) that
is intended to replace openssl, if I'm not mistaken.
  I hope you are not referring to the RSA patent, as I'm sure you are
aware that it is expired.  The RSA patent is also a prime example of how
a patent demonstrably *hindered* adoption.  FOSS operating system
vendors began including the algorithms soon after the patent expired. 
Yes, US export laws hindered it as well, but the patent clearly had a
negative effect.

> this, the copyright was never transfered to the FSF. 

  What code are you talking about?  Was any of the technology covered by
patents?  Were they Verisign's own patents?  If they were Verisign's own
patents, then how is this argument relevant?
  In this case, all you are saying is that Microsoft is allowed to
distribute a GPLed implementation of the patented technology.  With the
current licenses, this would make no sense, i.e.: You can modify the
code and redistribute without permission (pursuant to the GPL) but you
can't modify the code and redistribute without a separate license from
Microsoft (pursuant to the patent license).
  And Microsoft GPLing the code would not allow the restriction to 'only
what is necessary to implement Sender-ID'.  By the time they were done
with all the legalese, it would be clear that using the GPL would only
be for show as there would be so many contradictions that it would
essentially NOT be GPLed.

> where the party that holds the copyright is not the party wanting

  If I'm understanding the above, then there are several thousand
packages that fit this description within Debian, Fedora Core, Mandrake
SUSE Linux, and others, because of the simple fact that a good
percentage of packages are patched by distributors.

> system discriminates against themselves because they have made a 

  I don't follow this logic, though it's probably not relevant.

> basis for Mosaic) public domain, not GPL was because we thought 

  This adds nothing to your argument.  No one is asking that anyone GPL
anything.  Only that those of us you choose the GPL license to license
our own, copyrighted code are allowed to continue to do so if we
implement Sender-ID.  The current patent license does not allow this, as
three attorneys so far have stated.

> demand is for unilateral disarmament.

  Well, if we are to assume you are correct in your analysis above,
considering that those who wield the arms (software patents) are almost
universally those with the deep pockets to carry out the litigation,
then I wouldn't call that an unreasonable demand at all.  But again,
that doesn't really add much to this discussion.

> for a patent would be sufficient to stop any and every new

  Have you considered that this may have the opposite effect?  Namely
that if that precedent were set, perhaps the people that matter
(legislators, judges, the USPTO, voters) would wake up and see just how
much harm software patents cause?
  Personally, I think this distracts from the matter at hand: should
MARID approve a standard that is encumbered in such a way as to
ghetto-ize several MTAs.  My recommendation is an emphatic "NO."

> technology being entirely unencumbered becomes vanishingly small.

  Agreed.  But that is a battle for another forum.  It does not bolster
your argument in any way I can see.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 01 Sep 2004 18:57:32 -0400

> standard be rejected and a non-encumbered alternative be considered.

Keep in mind that there is at least another alternative: ignore the IPR 
claims as irrelevant and frivilous, and go ahead with the standard 
anyway like the example given in RFC 3669.

Yakov

---

From: wayne <[email-masked]>
Date: Wed, 01 Sep 2004 20:36:20 -0500

In <[email-masked]> Yakov Shafranovich <[email-masked]> writes:

> Keep in mind that there is at least another alternative: ignore the
> IPR claims as irrelevant and frivilous, and go ahead with the standard

Thanks to your (Yakov's) fine efforts, it does appear that the MS is
likely to be worse than the typical patent-the-obvious type patent,
but is much closer to what PHB calls a patent troll.  They may well
have taken ideas discussed in the ASRG and, after the fact and without
telling anyone, patented them.

The problem is that even if Microsoft is being a patent troll, they
would be a patent troll with very deep pockets.  If they chose to sue
for ignoring "their" IPR, they could bankrupt even medium to large
companies with lawyer fees.  A cease and desist from a tiny patent
troll may well be ignored by most open source mirror sites, but I
doubt that it would be ignored if it came from MS.

-wayne