ietf-mxcomp
[Top] [All Lists]

Re: acceptable licenses (Was: Can there be an early decision on t he SenderID license?)

2004-08-27 13:21:04

On Fri, 2004-08-27 at 13:42, Margaret Olson wrote:

[snip]

My problem with this line of reasoning is that any spam reduction 
mechanism is going to have IPR claims - by either the genuine inventors 
or someone else.

  I think you will find that most anyone in the IT business would agree
that *any* technology fits this description.  But we can only deal with
what we know.  I'm a strong proponent of fixing the patent system to the
point of eliminating *software* patents entirely.  That is the *only*
way do deal with submarine patents, IPR pooling companies, and other
abuses of the patents system.  But that's a battle to be fought
elsewhere.
  In this case, we have known claims.  Or *somewhat* known, since the
IPR holder has not stated *exactly what* technology its claims are
over.  That in and of itself is enough reason to scuttle Sender-ID, or
at least put it on hold until the issue can be resolved.  I wouldn't say
this except there are apparently a lot of *technical* issues people have
brought up *and* there are also non-IPR-encumbered alternatives.

 There are multiple patent claims on challenge 
response. I am not comfortable with the idea that we reject a 
technology because the IPR holder has deep pockets.

  Few, if any who are opposed to this license have suggest we reject it
because 'the IPR holder has deep pockets.'  Sure, the deep pockets have
been mentioned, but not in any way as a primary motivator for rejecting
the license.

 As far as I can 
tell, that the IPR is held by Microsoft remains the primary objection, 
and I can't see that as a valid objection.

  Nice job setting up straw man.  This is patently (no pun intended)
false.  Please cite in any of these last call posts on the IPR issue
where the primary objection has to do with Microsoft.  And please
include multiple examples to support your assertion that it is the
*primary* objection.  I don't care if it's "Do No Harm" Google, or Eben
Moglen himself.  It's the license *terms* that people are talking about
here.

I would also argue that there is a control advantage to making Sender 
ID an IETF standard. It makes it much harder for Microsoft (or anyone 
else, for that matter) to make arbitrary revisions.

  This *sounds* like you are advocating giving IETF *legal* teeth. 
Whether or not that is your intent, I don't know, but if it is, I think
it's misguided and also not a good thing to work towards (giving the
IETF legal teeth, that is).  It's the IPR holder who would have the
legal teeth here.  I don't mind if the IETF says to me that I cannot
implement Sender-ID and *call* it Sender-ID in my GPLed MTA unless I
follow the spec strictly.  Trademark law could possibly help with that
(but I won't go down that road).  But I do mind if ANY organization
motivated by profit, and especially when this organization is a
*competitor*, dictates what I can do with my GPLed MTA, including either
changing my license or drawing up some burdensome -- really,
contradictory -- exception to it (i.e.: This software is convered by the
GNU General Public License with the exception that you need to get a
license from Microsoft to modify and/or distribute any changes).

 Whether or not this 
matters depends on whether you think it will get widespread adoption. I 
think it will, and that most of us are going to wind up dealing with it 
regardless of the IETF decision. Do we prefer an IETF standard or a 
de-facto standard?

  I would think that most on this list prefer an IETF standard, of
course.  But you are depicted a false dichotomy here.  If the IETF does
not adopt Sender-ID, you seem to be assuming that there are no other
choices.  The IETF, though still having its critics, still has a lot of
weight when it puts it imprimatur of "RFC" on a standard.
=-=-
  Aside: We now have three legal opinions that this patent license is
not compatible with the GPL or even the DFSG, OSI, and FSF
meta-definitions of FOSS licenses.  And zero legal opinions (as far as
I've seen) that say otherwise.  If that's the tally, I hope we can put
that argument to rest.

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