ietf
[Top] [All Lists]

RE: FSF's comment on draft-housley-tls-authz-extns

2009-02-13 11:40:29
+1


Regards, 
Chuck 
------------- 
Chuck Powers, 
Motorola, Inc 
phone: 512-427-7261
mobile: 512-576-0008
 

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
Behalf Of ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
Sent: Friday, February 13, 2009 10:14 AM
To: Sam Hartman
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: FSF's comment on draft-housley-tls-authz-extns

...

I'm sorry, I don't see this at all.  I appreciate that you 
quoted the
text in question.  However I don't see anything in the language you
quote that applies differently to either users or developers.

Well, there's something of an exemption for developers 
producing generic
uilding block software. But I take your point to be that a 
developer who, say,
puts in specialized support for a Redphone critical extension 
(item one of the
four), would clearly be infringing.

The text is saying that the transport mechanisms described in the
Housley draft are not covered by the patent.  However the 
text goes on
to say that some ways in which an implementation might employ those
transport mechanisms would be covered by the patent.  As I read the
text, both developers and users who used the mechanisms in 
the Housley
draft in any of these four ways would infringe the patent, Redphone
claims.

Nicely put. I agree with this assessment.

However I'll also note that there are significant uses of the
transport mechanisms in the Housley draft that are 
interesting both to
the free software and IETF communities that fall well outside these
four areas.  In particular, transporting in-band group 
memberships and
authorization/attribute assertions see.ms to fall outside 
these areas.

Exactly.

I can understand why the GNU project would not choose to ship an
extension to GNU TLS that used this transport to send agreement
locations.

Sure, that would clearly infringe. The question to my mind is 
whether or not
this is an overly onerous restriction. I don't think it is 
but others may
disagree.

However, it is completely absurd to claim that because some
infrastructure building block could (by writing additional software)
be used in a manner that infringes a patent that no free software
version of that building block can exist.  As an example, the FSF
ships a compiler collection that can be used to infringe a number of
patents in the hands of someone who has infringing source code.  The
GNU/Linux kernel includes a TCP implementation that can be used to
infringe Redphone's patent.

This is the point I was trying to make in my earlier 
response. There are many
use-case patents built on top of pretty much any protocol 
building block you
can think of. If we adopt the theory, which is implicit in many of the
objections I've seem to this document, that we cannot work on 
protocol building
blocks when such use-case patents exist, we'll effectively be 
out of business.

I will also point out that the list of IPR disclosures 
includes very few of
these patents. Demanding the disclosure of all such patents 
participants are
aware of would be ... interesting.

                              Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf