Subject: Re: Obstacles between us and the finish line

From: Michel Bouissou <[email-masked]>
Date: Thu, 15 Jul 2004 01:19:44 +0200

Shevek wrote:
>
> I request that any protocol standardised by the IETF be entirely free of
> license restrictions in order that implementors clearly understand their
> right to implement the protocol. I specifically oppose the adoption of
> SenderID as a standard since it imposes licensing terms on the user. 

I completely and entirely second Shevek's point.

Especially in a domain as critical for the entire Internet community as is 
email exchange and delivery, I believe that IETF should never even consider 
adopting as a standard any protocol which implementation could be encumbered 
with any kind of patent or license restriction.

Such a standard must be public domain, free for anybody to comply with, use or 
implement without any kind of licences or constraints from any entity, in any 
kind of MTA or software itself governed by any kind of license, among which 
Free Software licenses and the GPL.

License restrictions/obligations on such a protocol would quite probably 
forbid it from being implemented and integrated into most if not all of the 
mainstream open-source MTAs, which would make this new "standard" basically 
useless.

So I request that either parties currently claiming IP rights about any aspect 
of the protocol that will be part of the standard officially decide to put 
these into the public domain, or that any aspect of the protocol that is 
encumbered with known IPR claims should be removed from the future standard.

That's all.

- -- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Jul 2004 20:24:29 -0400

> Free Software licenses and the GPL.

Can you please explain the legal technicalities that lead you to 
believe that the license for Caller-ID inhibits (a) development and/or 
(b) distribution of open source software, and especially the GPL, under 
such license?

-andy

---

From: wayne <[email-masked]>
Date: Wed, 14 Jul 2004 23:43:19 -0500

(Ok, I know I said I wasn't going to post any more today, but it is
sufficiently close to midnight that I'm going to fudge it.  Of course,
everything I say is a lie, so YMMV anyway. :-)

In <[email-masked]> Andrew Newton <[email-masked]> writes:

>> Such a standard must be public domain, free for anybody to comply
>> with, use or implement without any kind of licences or constraints
>> from any entity, in any kind of MTA or software itself governed by
>> any kind of license, among which Free Software licenses and the
>> GPL.
>
> (b) distribution of open source software, and especially the GPL,
> under such license?

IANAL. It is my understanding that several lawyers from the OSS
community (the FSF and OSI) are working with lawyers from MS, but I do
not know what has resulted from those discussions.

I have every reason to believe that folks like Harry, Jim and Bob have
the best of intentions to try and get a license that is acceptable to
all parties.  Unfortunately, we all know what road is paved with good
intentions.  The hell I want to avoid is having this WG end up with an
RFC that can not be easily uses by parts of the SMTP community, in
this case, open source MTAs/spamfilters.

My layman reading of the Caller-ID license raises the following
issues:

1) In Section 2.1, the license granted by MS is nontransferable and
   non-sublicensable.  So, it is my understanding that if I create a
   hunk of software that implements SenderID, I must license it.  Now,
   if I upload this hunk of code to sourceforge and source forge
   starts to distribute it, do they have to go get a license also?
   What about all the linux/*BSD distributions, will each of them have
   to obtain a license if they bundle my code?  Does each ftp server
   that mirrors one of these distribution have to get a license?

   These kinds of issues are not as much of a problem for commercial
   products since there would be contracts and such saying that these
   folks are acting as my agent and that these other distributers
   aren't creating a new product.  However, in the open-source world,
   I would expect many of these distributers to change the code, fix
   bugs, or add features.

2) In Section 2.2, the Caller-ID license requires *adding* a term to
   the existing licenses.  Sorry, but I don't think anyone is going to
   want to change the BSD or GPL.  

3) In Section 6.3, in order to obtain a license, I must either use
   certified snail mail, or a fax machine to request a license.  I
   don't have a fax machine, so I'm stuck trying to send certified
   mail and waiting for a reply.  So, if you find a bug in my
   open-source implementation of SenderID, you can't just fix it and
   put a new version up on your ftp site, you have to go running
   around getting licenses and wait until you get a response back from
   MS.

This all gets back to what Shevek said: "Implementors are not lawyers,
and generally have better things to do with their time."  The fact
that I have to dig through yet another new license that requires me to
modify a bog-standard open source license and do so without messing up
is a big burden.

Again, as Shevek said: "I believe that a large part of the reason for
the success of the GPL, BSD or Apache licenses is that the rights of
the user and developer are particularly well understood in those
cases. It's frequently simpler to pick a GPL'd package than to
understand the license of a (possibly better) package under a custom
license."

As RFC3668 says:

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

I do not believe that the advantages of the PRA algorithm outweighs
the costs of licensing, or at least, not the current license.

The fact that the IETF generally prefers technology without IPR issues
is not just a philosophical position, it is also a practical one.
Given that SPF-classic can be freely implemented without any hassles,
the adoption of an RFC that is more burdensome runs a huge risk that
people will widely ignore the RFC and just use SPF-classic.  Mind you,
there are people who will do this anyway because they don't feel the
PRA algorithm is as effect, but the licensing issue makes a snappy
justification for not going with the RFC.

The problems with the license need to be addressed before the last
call goes out for the drafts.  (According to the schedule, that would
be this month.)  If the problems can not be resolved quickly, and this
has dragged on for weeks, then I think the PRA needs to be dropped.
It can be dealt with later on when there is more time.

-wayne

---

From: Michel Bouissou <[email-masked]>
Date: Thu, 15 Jul 2004 10:58:58 +0200

> (b) distribution of open source software, and especially the GPL, under

As a preamble, please note that I am no lawyer, and a competent lawyer would 
probably be necessary to understand all this better.

That said, in his message written today at 04:43:19 UTC, Wayne expressed my 
own concerns very precisely, and I share all of the points that he made.

Assuming Microsoft will impose for Sender-ID (or any subpart of it) the 
license that their webpage at 
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx currently 
points to, which actually is the license for Caller-ID gotten from their site 
at 
http://download.microsoft.com/download/6/0/a/60a02573-3c00-4ee1-856b-afa39c020a95/callerid_license.pdf , 
then this license states :

§ 2.1: That the license granted for "making, using [and] distributing object 
code versions of Licensed Implementations", "only as incorporated into 
Licensed Products" is "nontransferable, non-sublicenseable [and] personal".

§ 2.2 makes the same provisions for source code distribution, plus request 
that the license under which the source code is distributed would include a 
supplementary notice "and does not include any other terms that are 
inconsistent with, or would prohibit [the said notice]"

§ 4.3 repeats this again

§ 6.3 states that, to benefit from this royalty-free license, somebody needs 
to return a signed, written copy of the said license to MS either by fax or 
snail-mail.

In my understanding, all these provisions prohibit anybody who wouldn't have 
signed the MS license to redistribute a software implementing Sender-ID 
either in object or source code in any way.

This would mean that any "Free Software" MTA or antispam incoporating 
Sender-ID could not anymore be freely redistributed, either via FTP or 
included into, let's says, Linux or *BSD distributions, without each 
distributor having previously signed the MS license and sent it back by fax 
or snail-mail.

If you consider the number of different softwares and modules that any Free 
Software distribution usually includes, and the number or distributors and 
FTP or mirror download sites that each of them has, it is simply not 
imaginable that any "not-for profit" redistributor or contributor would have 
to sign dozens of such licenses, so requiring such a license will certainly 
prohibit any software including Sender-ID to be included into Free Software 
distributions, or further modified, improved or completed by benevolent 
individuals, and this would make any software including Send-ID to slip out 
of the Free Software community.

Now let's take a look at Free Software licenses.

The General Public License (GPL Version 2) says :

<<
  1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
[...]

  2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.
[...]
These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
[...]

  3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

    a) Accompany it with the complete corresponding machine-readable
    source code, which must be distributed under the terms of Sections
    1 and 2 above [...]
[...]

  6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein. [...]

  7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.
[...]

This makes clear that the license that Microsoft requires for Sender-ID is 
incompatible with the GPL, and as such, prohibits incoporating Sender-ID in 
any GPL MTA or antispam software.

Now let's take a look at "IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER", the 
license that governs the very popular and widely used Postfix MTA :

<<
1.  DEFINITIONS

"Contribution" means:
    a) in the case of International Business Machines Corporation ("IBM"),
       the Original Program, and
    b) in the case of each Contributor,
       i)  changes to the Program, and
       ii) additions to the Program;
           where such changes and/or additions to the Program originate
           from and are distributed by that particular Contributor.
           A Contribution 'originates' from a Contributor if it was added
           to the Program by such Contributor itself or anyone acting on
           such Contributor's behalf.
[...]
2.  GRANT OF RIGHTS

    a) Subject to the terms of this Agreement, each Contributor hereby
    grants Recipient a non-exclusive, worldwide, royalty-free copyright
    license to reproduce, prepare derivative works of, publicly display,
    publicly perform, distribute and sublicense the Contribution of such
    Contributor, if any, and such derivative works, in source code and
    object code form.

    b) Subject to the terms of this Agreement, each Contributor hereby
    grants Recipient a non-exclusive, worldwide, royalty-free patent
    license under Licensed Patents to make, use, sell, offer to sell,
    import and otherwise transfer the Contribution of such Contributor,
    if any, in source code and object code form.  This patent license
    shall apply to the combination of the Contribution and the Program
    if, at the time the Contribution is added by the Contributor, such
    addition of the Contribution causes such combination to be covered
    by the Licensed Patents. [...]

3.  REQUIREMENTS
[...]
When the Program is made available in source code form:
    a) it must be made available under this Agreement; and
    b) a copy of this Agreement must be included with each copy of the
       Program.

In my understanding, this prohibits as well the inclusion of Sender-ID into 
Postfix and its further redistribution in source code form, as the MS 
Caller-ID license would prohibit the Postfix source code including Sender-ID 
to "be made available under this Agreement" any further.

I repeat that IMHO, any protocol to be defined as an IETF standard should be 
public domain, free for any party to implement, distribute and use in any 
kind of software, regardless to the license that currently governs the 
concerned software.

The MS license clearly shows incompatible with this goal, which makes it 
unacceptable for considering building a standard upon a protocol that is 
encumbered with such a license.

If MS was ready to modify its licensing terms, and allow for anybody receiving 
Sender-ID in any form to _automatically_ receive a perpertual, royalty-free 
license to use it, implement it, redistribute it, build derivative works from 
it, and incoporate it into other works without any changes to said other 
works licenses, usage or redistribution rights, then things, of course, would 
be different.

--