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

+1


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

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of ned+ietf@mauve.mrochek.com
> Sent: Friday, February 13, 2009 10:14 AM
> To: Sam Hartman
> Cc: ietf@ietf.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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>