Subject: DEPLOY: SPF/Sender ID support in Courier.

From: Sam Varshavchik <[email-masked]>
Date: Fri, 27 Aug 2004 20:01:16 -0400

Please watch your followups, as this message is sent to multiple lists.

The purpose of this message is to clarify my plans for any deployment of the 
Sender-ID specification in Courier (http://www.courier-mta.org).

Microsoft has made certain patent claims on the Sender-ID specification. 
Microsoft has issued the IPR disclosures and royalty free license required 
by the IETF.  It appears that IETF's contemporary policies do not prevent 
the sponsor/advocates from including patented IP material into 
standards-track specifications, without even requiring the sponsor to 
actually enumerate and identify their intellectual property; a mere claim of 
the existence of some nebulous IP rights is sufficient, which can be 
revealed at any point in the future, at the sponsor's discretion.

The current development version of Courier implements the original 
SPF-classic specification, that predates Sender-ID.  This will be rolled 
into a forthcoming release.  I'm quite pleased with the results so far -- 
there are a lot of classic SPF records in existence, as witnessed by my mail 
logs :-)

It will not be possible for me to implement Sender ID in Courier.  Courier 
is licensed under the GPL.  The FSF already flatly stated that Microsoft's 
IP license is not GPL compatible.  I reviewed the most recent version of 
Microsoft's proposed IP license, and I've reached the same conclusion.  For 
this reason Sender ID cannot be implemented in Courier; Courier's 
implementation will be limited to the unencumbered SPF-classic.

-- 
Sam Varshavchik
http://www.courier-mta.org

---

From: Roy Badami <[email-masked]>
Date: Sat, 28 Aug 2004 02:06:12 +0100

[Distribution trimmed]

>>>>> "Sam" == Sam Varshavchik <[email-masked]> writes:

    Sam> It appears that IETF's contemporary policies do not prevent
    Sam> the sponsor/advocates from including patented IP material
    Sam> into standards-track specifications, without even requiring
    Sam> the sponsor to actually enumerate and identify their
    Sam> intellectual property

How is this worse that if Microsoft hadn't been involved in the MARID
group and the WG had come up with a similar proposal independently.
In that case you wouldn't have even known about the patent claims, but
it wouldn't have made them less relevent.  

    Sam> It will not be possible for me to implement Sender ID in
    Sam> Courier.  Courier is licensed under the GPL.  The FSF already
    Sam> flatly stated that Microsoft's IP license is not GPL
    Sam> compatible. 

That would be unforunate, and I think also misguided.

The licenses may well be technically incompatible, but that effects
no-one but Microsoft.  You, as the distributor of courier, will only
be distributing code under the GPL.  You will _not_ be granting rights
under the Sender ID patent grant, and more to the point you will not
(I assume) be making any patent claims on Sender ID.

The only entity that _might_ have to worry about the compatibility of
the licenses is Microsoft, and given they don't tend to distribute
much third-party GPL'd code, I suspect they can live with that.

IANAL, I could be wrong, but I don't think I am.  See also my recent
post to the MARID list on this subject.

       -roy

---

From: Graham Murray <[email-masked]>
Date: Sat, 28 Aug 2004 05:50:22 +0100

> (I assume) be making any patent claims on Sender ID.

That is *not* correct. Two of the rights which the GPL licence gives
to recipients (ie those to whom the software is distributed) are to 

1) Be allowed to modify (or have modified) the software.

2) Be allowed to distribute the software, either the original as
   received, or as modified in 1) above.

The patent grant (as currently on the table) is incompatibe with this,
as you (the software author and patent licencee) do not have the
rights under the patent licence to grant recipients the right to
modify and distribute that modified software - to do so they would
need to obtain a licence from the patent holder. The GPL is clear that
if you cannot grant these rights (eg because it is not yours to give)
to recipients then you cannot distribute the software under GPL.

---

From: Roy Badami <[email-masked]>
Date: Sat, 28 Aug 2004 14:03:44 +0100

>>>>> "Graham" == Graham Murray <[email-masked]> writes:

    Graham> The GPL is clear that if you cannot grant these rights (eg
    Graham> because it is not yours to give) to recipients then you
    Graham> cannot distribute the software under GPL.

Hmm, I concede that you may well be right.  I still think Sender ID is
useful though, and would hate to see this effort grind to a halt over
squabbles over IPR, which is what seems to be happening.

	  -roy

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 28 Aug 2004 10:01:14 -0400

On Sat, Aug 28, 2004 at 02:03:44PM +0100, Roy Badami wrote:
| 
| Hmm, I concede that you may well be right.  I still think Sender ID is
| useful though, and would hate to see this effort grind to a halt over
| squabbles over IPR, which is what seems to be happening.
| 

The above seems to be a "for" vote.  As recent discussions
have focused on patent issues, a positive vote is worthy of
note.

Could I ask you and other people who like Sender ID on
technical grounds to please explain what you like about it
in more detail?  Of course my other coauthors and I have our
own opinions, but I would like to hear from other members in
the working group.  Please limit replies to "what I like
about Sender ID" --- responses to those can come later.

cheers

---

From: Roy Badami <[email-masked]>
Date: Sat, 28 Aug 2004 19:21:46 +0100

>>>>> "Meng" == Meng Weng Wong <[email-masked]> writes:
    Meng> The above seems to be a "for" vote.  As recent discussions
    Meng> have focused on patent issues, a positive vote is worthy of
    Meng> note.

It is.  Unfortunately there appears to be no procedure within the last
call for indicating approval of the drafts, other than by individually
replying to specific objections that are made, and I'm afraid that
given the volume of traffic during this last call, I'm simply unable
to keep up with the comments.

    Meng> Could I ask you and other people who like Sender ID on
    Meng> technical grounds to please explain what you like about it
    Meng> in more detail?

One of the main reasons is that it allows me to take steps to make it
harder for people to spoof mail from domains that I control.

For me personally, this is not a serious issue.  In the context of the
company I work for, however, we have concerns that spam and virus
e-mail purporting to by from us is taken at face value by
non-technical users.  Phishing isn't an issue for us; customers and
potential customers thinking that we are sending them spam and viruses
is a moderate concern.

In this context, Sender ID is far more useful to us than SPF, because
SPF protects an identity that is not available to the MUA in any
reliable way.  I realize that Sender ID also protects an identity that
isn't currently displayed by MUAs, but hopefully we will see that
change fairly rapidly. [1]

That said, we will almost certainly be publishing SPF records in
addition to Sender ID records.  And we will almost certainly publish
Sender ID records, regardless of whether the spec has the aproval of
the IETF or gets filibustered by endless arguments in this WG, as long
as we see a benefit to us in doing so.  (And Hotmail alone accounts
for a large enough proportion of non-technical users that I suspect
that even if no-one except Microsoft checks Sender ID, we would decide
that it was in our interests to publish.)

As the above implies, I'm not against checking MAIL FROM (and believe
it is useful), and I would like to see this WG discuss MAIL FROM
validation if/when it completes its current work items (Sender ID and
CSV).

Another reason is that like most people, particular people who have
been using e-mail for a long time, we are deluged with spam.  We use a
heuristic spam checker, which works quite well, but there is a need to
whitelist organizations in order to avoid false positives.  The
problem is that when you whitelist a major corporation, the chances of
receiving spam or viruses claiming to be from is quite high.  So I'd
like to be able to whitelist based on a validated identity.  For this
purpose though it doesn't really matter what the identity is.  If they
publish Sender ID records, I'll whitelist them based on the PRA; if
they publish SPF records, I'll whitelist them based on the MAIL FROM.
If they publish CSV records, I could whitelist them based on HELO
strings (though this last requires them to tell me all the HELO strings
of their outbound MTAs, so is less convenient).

I support Sender ID also for the flexibility of the SPF record.  Many
people have criticised it for being over-flexible (and hence over
complex, and overly resource intensive) but I feel that this
flexibility is key.  Having a policy language that is expressive
enough to allow people to describe their existing policies will result
in far more buy in than requiring people to change their policies to
fit in with MARID.

It is certainly possible that we may need to make per-user exceptions
in the records we publish, at least in the early days of deployment,
to allow for a small number of people who work from home who don't
currently use our MTAs to originate e-mail.

I am of course aware of the utility of a validated identify in
constructing reputation systems, and the potential utility of
reputation systems in attacking the spam problem.  Sender ID is likely
to be useful in this regard, too.  This is an area though where I'm
less sure of relative utility of the different identities, and I can
see that CSV may be of particular use here too.

However in summary, of all the proposals I'm aware of, Sender ID seems
to me to be of the most immediate utility to me.  This is partly due
to its specific functionality, and partly due to the specs now being
in a fairly mature state, which could be deployed tomorrow without too
much difficulty.  (Without a doubt, SPF is the most mature of the
specifications out there, but for the technical reasons I describe
above, I expect Sender ID to provide me with greater benefits).

Even if Sender ID is incompatible with the GPL [2] -- and I'm
skeptical that it is except under the most extreme interpretations --
Sender ID can be implemented now, and the license is not so burdonsome
as to prevent significant deployment.  If it can't be implemented
within some MTAs, it can be implemented as a separate stand-alone
package that interfaces to the MTA.  Most modern MTAs have interfaces
that would permit this.

I have nothing against this WG seeking other solutions which are
either better or complementary to Sender ID, including attempting to
design an alternative solution that is unencumbered by patent claims.
But that should be a future work item.

Despite any technical and legal shortcomings of Sender ID, it's the
best thing we have _now_, and I am in favour of progressing it to the
IESG for consideration as a Proposed Standard.

Sorry for the length of this

      -roy

[1] If Microsoft fixes Hotmail, Outlook and Outlook Express to display
the PRA, and Apple fixes their mail client to display the PRA, and
both Microsoft and Apple roll out the fixes via their automatic
updates mechanisms, then you've covered a very significant proportion
of non-technical users.  There's no reason why this has to take lots
of time.

[2] And on further reflection my opinion is that whilst Sender ID
_might_ be incompatible with the GPL, to conclude this you have to
take a fairly extreme view of what the GPL requires.  In particular,
under such a view, _no_ GPL'd software that has (or even might have)
any patent claims against it may be redistributed.  That essentially
means prety much all non-trivial GPL'd software.  For instance, the
Linux kernel is GPL'd, and we _know_ that there are numerous patent
claims that may apply to it.  Distributing an MTA that incorporates
Sender ID is at least as legal is distributing the Linux kernel.  If
that's not good enough, then maybe it's time to throw away the GPL.

---

From: Paul Iadonisi <[email-masked]>
Date: Sat, 28 Aug 2004 15:09:40 -0400

On Sat, 2004-08-28 at 14:21, Roy Badami wrote:

[snip]

> change fairly rapidly. [1]

  This makes no sense.  MAIL FROM is most certainly at least as
available to the MUA as Sender-ID via the Return-Path: header.  Neither
is displayed by most MUAs, but if I'm not mistaken, Sender-ID identity
is heuristically determined.  Return-Path: is one value, so it is
presumably much simpler to determine.
  Anyhow, that may not be significant.  It's the only technical
disagreement I have with you that I can discern from your post here.

> as we see a benefit to us in doing so.

  I object to this being referred to as filibustering.  If it were, I
would have expected the co-chairs to put a stop to it by now.  With very
few exceptions (mostly from those in favor of moving forward with the
current Sender-ID patent license), the discussion has been very civil
and well reasoned.

[snip]

> skeptical that it is except under the most extreme interpretations --

  And we have yet to see a convincing legal argument (or *any* legal
argument) from an attorney posted to this list.  I'd like to know what
Anne Mitchell (on this list) thinks of her legal analysis being called
extreme by a non-lawyer.

> package that interfaces to the MTA.  Most modern MTAs have interfaces

  This is not as simple as you make it out to be.  You are once again
leaving out compilations such as Red Hat's Fedora and Debian.  I'm sure
I could list many others.  Having a separate module makes no difference
if it's included in the cdrom ISOs that are distributed.

-- 
-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: Graham Murray <[email-masked]>
Date: Sat, 28 Aug 2004 20:35:50 +0100

> in far more buy in than requiring people to change their policies to

I agree that people should not be required to change their policies
and working practices purely to fit in with MARID. However, I think
that the fight against phishing and identify forging could be greatly
helped if, as well as technical measures such as MARID, some
organisations (especially some of those most liable to have their
identity spoofed by phishers) were to make some changes to their
policies and working practices. In particular using third parties (eg
PR companies or advertising agencies) to send e-mail to customers (and
potential customers) makes it very much harder (before MARID or
equivalent authentication is introduced) to distinguish between
genuine emails and phishing attempts. Changing to only sending emails
from MTAs using MAIL FROM, EHLO and rDNS within their own domain would
not only help (those who know how to read headers) distinguish genuine
emails from phishing before MARID is introduced but could greatly
simplify the MARID DNS ecords which have to be published and checked.

---

From: Mark Lentczner <[email-masked]>
Date: Sat, 28 Aug 2004 13:14:42 -0700

> presumably much simpler to determine.
Your main points are true: In general, the Return-Path and the PRA 
value are both in the headers and available to MUAs to display.  And 
yes, Return-Path requires less processing than the PRA.  (Though given 
that the headers are read and parsed anyway, PRA isn't that hard.)

However, you are mistaken: There is nothing heuristic in the PRA 
identity.  It follows directly from the RFC 2822 definition of the 
headers.  The meanings of From:, Sender:, Resent-From:, and 
Resent-Sender: is in there, as is their relative precedence and the 
ordering issue with Resent-Sender: and multiple Resent-* blocks.

> disagreement I have with you that I can discern from your post here.

Ditto here.

	- Mark

---

From: Paul Iadonisi <[email-masked]>
Date: Sat, 28 Aug 2004 17:19:14 -0400

On Sat, 2004-08-28 at 16:14, Mark Lentczner wrote:

[snip]

> ordering issue with Resent-Sender: and multiple Resent-* blocks.

  I stand corrected.  However, Roy's comment about SPF identity (MAIL
FROM) not being available in any reliable way is not accurate, except to
the extent that most MUAs do not display it by default.  It is, however,
easily accessible.  That was my main point.  So to correct myself, both
SPF and Sender-ID identities are essentially equivalent with respect to
how available they are to the MUA (relatively speaking, since no MUAs
currently display either by default).

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 28 Aug 2004 22:01:31 -0400

> Anne Mitchell (on this list) thinks of her legal analysis being called

The main point here is whether the current IPR issue can delay 
deployment. The mere fact that several lawyers have stated their expert 
opinion that this license is incompatible with existing open source 
licenses, can cause deployment problems. However, it is important to 
note how people react to their statements. We have already seen several 
parties including myself stating that they will not implement Sender-ID 
in their products unless the legal terms are changed, or the legal 
situtation is clarified. We also saw several parties, including Roy, 
state that they are willing to implement it even with the current legal 
situation intact. Therefore, it seems to me that there exists a sizable 
percentage of the possible market for this standard that will hesistate 
to deploy Sender-ID. This, we have a deployment problem. Whether the 
underlying facts that cause it are true, might not be relevant, since we 
care about what people will do.

Yakov

---

From: Andrew Newton <[email-masked]>
Date: Mon, 30 Aug 2004 12:21:32 -0400

On Aug 27, 2004, at 8:01 PM, Sam Varshavchik wrote:
> Microsoft has made certain patent claims on the Sender-ID 
> specification. Microsoft has issued the IPR disclosures and royalty 
> free license required by the IETF.

The IETF does not require a royalty free license.

>   It appears that IETF's contemporary policies do not prevent the 
> sponsor/advocates from including patented IP material into 
> actually enumerate and identify their intellectual property; a mere 
> claim of the existence of some nebulous IP rights is sufficient, which 
> can be revealed at any point in the future, at the sponsor's 
> discretion.

I'm not sure what point you are trying to make here.

> It will not be possible for me to implement Sender ID in Courier.  
> Courier is licensed under the GPL.  The FSF already flatly stated that 
> Microsoft's IP license is not GPL compatible.  I reviewed the most 
> recent version of Microsoft's proposed IP license, and I've reached 
> the same conclusion.  For this reason Sender ID cannot be implemented 
> in Courier; Courier's implementation will be limited to the 
> unencumbered SPF-classic.

A couple of questions:

1) How do you base your decision on incompatibility? I ask this because 
Courier uses OpenSSL and ships with a file called COPYING which states:

> This software is released under the GPL, version 2 (see COPYING.GPL).
> Additionally, compiling, linking, and/or using the OpenSSL toolkit in
> conjunction with this software is allowed.

According to the FSF, the OpenSSL license is also incompatible with the 
GPL.  Additionally, is the webmail part of Courier licensed in a 
different way?  Would there be issues using it with Apache since the 
FSF also considers the Apache license to be incompatible with the GPL?

2) Based on my limited understanding of Courier, it seems that the only 
document in the Sender ID docset that needs to be implemented directly 
into Courier is the SUBMITTER ESMTP extension.  The encumbered portions 
of Sender ID, -core and -pra, could easily be implemented in a separate 
module using the courierfilter interface.  Are you unwilling to 
incorporate the unencumbered SUBMITTER even if a core/pra courierfilter 
were available?

3) If somebody were to patch Courier with Sender ID and distribute it 
with such modifications, would you take legal action against them?

4) You have stated above that you believe Microsoft's claim is 
"nebulous" with regard to rights being claimed.  Your release notes 
state "Implemented Sender Policy Framework checking on the From: 
header.  Be sure to read the documentation and understand the 
implication."  Since checking of the From: header is listed in the -pra 
document, are you concluding that this is not encumbered by Microsoft's 
claim?  If so, how did you come to this conclusion?

-andy

---

From: Daniel Quinlan <[email-masked]>
Date: 30 Aug 2004 12:13:17 -0700

> The IETF does not require a royalty free license.

Sure, but it seems evident that RF is practically a requirement for
MARID acceptance and consensus.

> I'm not sure what point you are trying to make here.

Fill in the blanks.

> According to the FSF, the OpenSSL license is also incompatible with
> the GPL.  Additionally, is the webmail part of Courier licensed in a
> different way?

I believe the Courier author could fix this by adding an exception to
the license.  Also, it's possible the usage of OpenSSL is okay if you
consider OpenSSL to be part of the operating system, but that seems like
a stretch from what I've read.

Your message seems to boil down an ad hominem tu quoque that revolves
around orthogonal issues.  OpenSSL could be replaced by another library
with the same API.  OpenSSL or Courier could tweak their license.
Patents often can't be worked around unless the owner changes their
license... especially if you don't know what the patents cover.

> Would there be issues using it with Apache since the FSF also
> considers the Apache license to be incompatible with the GPL?

The ASF believes that Apache License 2.0 is compatible with the GPL.

  http://www.apache.org/licenses/GPL-compatibility.html

> incorporate the unencumbered SUBMITTER even if a core/pra courierfilter 

-core is the document that ties it all together so the unknown
patents could cover ... well, I don't know what, but more than PRA.

You may be right that the Courier author might be able to include enough
of Sender-ID to support it and help make it a success.  The separate
module would not really be open source, though.
 
> with such modifications, would you take legal action against them?

That seems like a hard question to answer given that you can't predict
the nature of a future license violation.
 
Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Roy Badami <[email-masked]>
Date: Tue, 31 Aug 2004 00:54:27 +0100

>>>>> "Paul" == Paul Iadonisi <[email-masked]> writes:

    Paul>   This makes no sense.  MAIL FROM is most certainly at least
    Paul> as available to the MUA as Sender-ID via the Return-Path:
    Paul> header. 

Sadly non-compliant MTAs (which fail to add Return-Path on final
delivery) are quite prevalent in the field. 

Hence my comment that an MUA cannot _reliably_ determine it.

	   -roy

---

From: Roy Badami <[email-masked]>
Date: Tue, 31 Aug 2004 01:07:48 +0100

>> skeptical that it is except under the most extreme

    Paul>   And we have yet to see a convincing legal argument (or
    Paul> *any* legal argument) from an attorney posted to this list.
    Paul> I'd like to know what Anne Mitchell (on this list) thinks of
    Paul> her legal analysis being called extreme by a non-lawyer.

Ok, here's my argument:

(1) Imagine you don't sign the patent license.  In that case, the
    license clearly has no effect on you.  The question is, does the
    existence of a patent claim prevent you from distributing under
    the GPL anyway.

    It is possible to interpret the GPL such that it does, since you
    are not in a position to offer rights to redistribute, although
    it's not clear (to me) that this is what the GPL intends.

    This may even be the correct interpretation of the GPL, however I
    call it an 'extreme' position because under that position it is
    also unlawful to distribute the Linux kernel, since it seems
    likely from recent reparts that there are a substantial number of
    patent claims against it.  In fact, this is likely to be true of
    most non-trivial GPL'd software.

(2) Now imagine that you _have_ signed the Sender ID license.  The
    Sender ID license doesn't require you to place any restrictions on
    the recipient of the software, as far as I can see the situation
    with GPL compliance is no different to (1)

    -roy

---

From: Paul Iadonisi <[email-masked]>
Date: Mon, 30 Aug 2004 21:18:13 -0400

>     Paul> her legal analysis being called extreme by a non-lawyer.

  Another honest question: Are you an attorney?  We can go back and
forth until we are blue in the face, if we really want to, but I was
pretty clearly talking about analyses from attorneys, not armchair
lawyers like ourselves ;-)
  Obviously, no lawyer is infallible, but with the tally so far being
three lawyers finding the patent license incompatible, and zero finding
it compatible, one has to wonder if the view that they are compatible
carries any weight any more.

>     most non-trivial GPL'd software.

  Re-read the preamble and section 7 of the GPL.  The phrase that stands
out in section 7 is "court judgement or allegation of infringement" and
the preamble acknowledges the constant threat of software patents.
  Beyond that, I'd need to defer to an attorney's opinion, but if I'm
not mistaken -- and this is something I remember Linus Torvalds
acknowledging, or should I say, asserting -- any attorney will tell you
that willful infringement is much more likely to bring about a judgement
against you than innocent infringement.  In other words it is unwise for
any developer of software to rummage through the USPTO database, because
if you do it can be said that you got the idea there or discovered your
'invention' was already patented by somebody else and you went ahead and
used that 'invention' in your code knowing full well it was infringing. 
Ignorance *is* bliss in this case.
  But here we have someone stating that they have IPR claims on a public
mailing list on part of something that is being submitted as a standard
that all the internet's MTAs will presumably need to implement. 
Plausible deniability just went out the window, methinks.

>     with GPL compliance is no different to (1)

  Incorrect.  This one's easy.  Just reread section 2.2 of the patent
license.  It is clearly non-sublicenseable which makes it quite
obviously incompatible with section 6 of the GPL.  I could find other
conflicts, but I believe that is sufficient.
-- 
-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: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2004 18:33:00 -0700

>     with GPL compliance is no different to (1)

To be cynical there is a difference, as Sender-ID can not be transferred
and requires an individual agreement for its use:

Imagine Microsoft acquires 49% of the shares for company 'V'.  Microsoft
then transfers Sender-ID patent rights to company 'V' with a private
agreement for unlimited use of this algorithm.  Are the licenses with
Microsoft still valid when rights are now held by company 'V'?  The
license was with Microsoft, but now Microsoft says "Sorry, company 'V'
now owns the rights for that algorithm, and we gave them the list of
companies we know to be using this technology."  You will be receiving
their demands in the mail.

-or-

Imagine Microsoft no longer feels generous and changes these agreements
to be the equivalent of the third-world debt.  Does this make Exchange
with Microsoft clients look better?  Sender-ID by itself may break both
SMTP and DNS with clumsy TXT lookups and complex macro scripts, but with
the legal wrench thrown in, Bob's your uncle.

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Mon, 30 Aug 2004 22:20:12 -0400 (EDT)

This is all somewhat hypothetical, because I don't think the technology
works yet, and won't be adopted widely enough for patent issues to be a
concern.  

On Tue, 31 Aug 2004, Roy Badami wrote:
>     license clearly has no effect on you.  

This is completely wrong.  You are confusing a license with a contract.
Patent laws in various countries prohibit use of patented technology and
intentional violations have severe penalties, where unintentional
violations have economic penalties and injunction.  The details vary
slightly from country to country but the variance is being addressed by
the GATT Treaty and other accords for patent law harmonization. The broad
outlines are pretty much the same throughout the developed world, and like
it or not, it is getting more and more harmonized.

> The question is, does the

<LPF President Hat> 

Yes.  That _could_ be infringement:

http://www4.law.cornell.edu/uscode/35/271.html

There is an exception but it is thin and untested.  (US) patent law allows
others to patent enhancements and improvements to existing patents.  You
cannot patent hypotheticals, so there is an exception for research. The
original patent holder cannot prevent your patent filing by claiming you
aren't licenced to use the patented technology necessary for your
improvement, nor can they stop your research by injunction and refusal of
a license. They can only prevent you from using it commercially (and
non-commercially). Of course, the improvement holder can prevent them from
using the improvement, so cross-licensing is a likely outcome.  So, there
is a little wiggle for research.  However, I've spoken to lawyers who
think that you cannot share patent infringing source code with others
__at__all__Period.  This is untested so far as I know. The main weakness
is that there is often little argument that you _must_ share code in order
to patent enhancements or perform research.  There is some realistic
argument, but certainly limited to research.  Unlicenced __use__ is
definitely out.

</LPF President Hat>

Some years ago, I decided to have my company be a US mirror for OpenSSL
(ssleay) before the patents expired.  I did have some adverse legal
contact, but no one wanted to litigate the issue and we continued to
operate the mirror.  Other factors were that we were licenced to use the
patent, and that our mirroring certainly wasn't commercially beneficial,
and arguably facilitated research. However, unlicenced __Users__ of the
code would have no such defenses.  I think it would have been difficult to
resist a subpoena for the download logs, but that never came. Such logs
aren't protected by the ECPA.  It was a risky position to take because if
the research exception and other arguments were rejected, we risked being
found to be inducing infringement.  This was similar to Kazaa, etc which
were sued for inducing copyright violations.  Fortunately, the courts
found their activities to have enough non-infringing purpose that they
weren't found to induce copyright infringement.

What is important to understand is that certain things skate by on what
amounts to technicalities. In general, that isn't the case.

>     it's not clear (to me) that this is what the GPL intends.

No, this isn't right either. The GPL is a copyright statement and a
permission with conditions. It is not a contract, and it covers only one
aspect of the program.  The GPL is orthogonal to the licensing of patents.  
A source code license does not equate to patent licence. A good example is
the G.723 codec. The ITU provides a sample implmentation, but this cannot
be used without a licence from the consortium that handles the licensing.

>     most non-trivial GPL'd software.

This is wrong. The GPL allows redistribution of source code.  You can even
charge money, so long as you provide source code for free, though you are
not required to provide media for free. I am not aware of any patent
claims against Linux in particular, (yet).  We are rather expecting bogus
software patents to be problem for free software in general. I have been
advocating a legislative effort to exempt free software from software
patent infringement.

If you mean the SCO V. IBM suit, that concerns copyright, not patents.  
Last I heard, it didn't look too good for SCO on the merits, but of
course, we probably won't know the real scoop on the merits until after
the case is over.

		--Dean

---

From: "David H. Lynch Jr." <[email-masked]>
Date: Mon, 30 Aug 2004 23:24:16 -0400

>    with GPL compliance is no different to (1)

    While my understanding of the principles behind the GPL makes it 
perfectly clear to me that most any license is going to run afoul of it.
I do not see how it is my understanding of the GPL or yours that matter's.
   
    What matters is:
            whether the authors of the GPL or other FOSS license beleive 
they have a problem,
             whether the authors of FOSS licensed MTA's beleive they 
have a problem
             whether those distributing software under the GPL or other 
FOSS license beleive there is a problem.
   
    This is not a game - atleast not for those of us who are not 
lawyers. Finding a "loophole" is something well meaning people do after 
they have unintentionally gotten themselves into a bind.
      I would like to sucker Microsoft into a fight they can't win, but 
trying to push a standard into that position is irresponsible.

---

From: Daniel Quinlan <[email-masked]>
Date: 30 Aug 2004 12:13:17 -0700

Fill in the blanks.

 

Daniel

---

From: Roy Badami <[email-masked]>
Date: Wed, 1 Sep 2004 02:57:34 +0100

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:

    Dean> This is completely wrong.  You are confusing a license with
    Dean> a contract.  Patent laws in various countries prohibit use
    Dean> of patented technology and intentional violations have
    Dean> severe penalties, where unintentional violations have
    Dean> economic penalties and injunction. 

I think you're missing my point.  I fully realize that distributing
software may violate patent law.

However a lot of discussion here has focussed on whether the existence
of the Sender ID license causes distribution of software to be
contrary to the GPL.

My point is: clearly, if you aren't a party to the patent license then
its wording can't have any effect on you.  Either the GPL allows you
to distribute software that might have claims on it or it doesn't.

Distributing software may (obviously) be unlawful under patent law,
but the wording of a license you haven't agreed to isn't going to
affect your rights under the GPL.

   -roy