First off, I raised the subject of having an early decision on the
SenderID license in order to make more effective use of this working
group's time. If the SenderID license is decided to be acceptable,
then we can cut off the debate/discussion of it and save a lot of
mailing list bandwidth. If the SenderID license is decided to not be
acceptable, then we can stop evaluating the marid-core, marid-pra and
Instead of addressing this issue, PHB has tried to reframe the
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Right now, we are supposed to be reviewing all of the documents.
However, as demonstrated in the "DEPLOY/IPR: Fundamental
Disagreements, or Get On With It" thread, there doesn't seem to be a
rough consensus that the SenderID license is acceptable. (Actually,
there appears to be a rough consensus that it isn't acceptable.)
I have yet to see a statement that makes a valid legal argument
that the license terms prohibit open source distribution.
That is completely irrelevant. As Eric Allman pointed out, many of
the aspects of the SenderID create friction, and that is all that is
enough to question whether the SenderID license is worth it.
The license terms are at least as open as the terms which the
IETF has accepted in the past.
The IETF has accepted RFCs in the past that have been horribly
designed and written. The fact that the IETF has made mistakes in the
past is hardly a good reason to ignore the current situation.
Larry Lessig is a lawyer, lets give him a call and hit his folk
up for some pro bono.
Please feel free to contact Larry. On Monday, I started making
contact with Eben Moglen (the FSF lawyer) for his input on whether the
SenderID license is compatible with the GPL. I chose Eben for a
couple of reasons. First off, he was involved with earlier
discussions with MS over this issue and therefore should be up to
speed on the subject. Secondly, Eric Allman has used quotes form Eben
in order to claim that the current SenderID license is acceptable.
First I would suggest that those wanting to make the argument that
the license terms are not acceptable put them in a form that is
more coherent than that advanced so far. In particular paying close
attention to the fact that what is wanted is a license to redistribute
software without let or hinderance.
No, this is backwards. The IETF requires rough consensus in order to
advance things. People who think that the SenderID license is
acceptable need to show that there is a rough consensus that it is
This working group does not need to accept the SenderID license
because is no worse than the worst license that the IETF has accepted
in the past. Rather, we need to look at what RFC3668 says:
| 8. Evaluating alternative technologies in IETF working groups
| 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.
People who are trying to reach a rough consensus that the SenderID
license is acceptable need to show that the burden placed on software
(both MTAs and things like spam filters) that are already widely
deployed is justified. That the PRA "is superior enough to
alternatives with fewer IPR claims or free licensing to outweigh the
potential cost of the licenses."
So far, no one has come close to showing that the PRA is superior
enough to outweigh the costs.