Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hartmans-ietf@xxxxxxx writes:

> The authors asked for a week delay while they prepared a new IPR
> disclosure.  That disclosure seems to have hit the IETF servers

Ah, good.  For easy reference, the new IPR disclosure is available
from:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833

>From a proprietary perspective, it appears to be a rather permissive
license.  It seems to be one of the better ones that I have read
relative to the other licenses in the IETF IPR disclosure list.  Kudos
to Mark!

However, if I understand the license correctly, it seems incompatible
with free software licenses.  The RedPhone license contains:

   "1. General Use License"

   "Upon request, RedPhone Security will provide a worldwide,
   nonexclusive, fully-paid, perpetual, royalty-free patent license to
   manufacturers who (a) implement the Protocol, (b) acknowledge this
   general use license as described in Schedule B, and (c) refrain
   from implementing any Protected Assurance System Functions defined
   and listed below.  This general use license granted to
   manufacturers also flows down to sublicensees and users, to permit
   end users of these systems (including both client and server
   components) to use the Protocol, provided those users do not use
   the system as a Protected Assurance System (PAS) as defined in
   Schedule A without obtaining an End User License."

There are two problems here:

     1) Requires that vendors 'request' the license.  It would be
     better if the license was given directly to third parties without
     any action required by the third parties.

     2) The restriction of field-of-use (i.e., cannot be used with
     PAS) is incompatible with free software norms: implementations
     must be usable for any purpose as long as the license is
     followed, and several free software licenses does not permit
     restrictions like this.

Studying problem 2) in more detail for some common licenses:

     1) Section 6 of the GPL and section 10 of the LGPL which says:

     "You may not impose any further restrictions on the recipients'
     exercise of the rights granted herein."

     http://opensource.org/osi3.0/licenses/gpl-license.php
     http://opensource.org/osi3.0/licenses/lgpl-license.php

     2) Section 2.1 of the Mozilla 1.1 License:

     "The Initial Developer hereby grants You a world-wide,
     royalty-free, non-exclusive license, subject to third party
     intellectual property claims:
...
        (b) under Patents Claims infringed by the making, using or
        selling of Original Code, to make, have made, use, practice,
        sell, and offer for sale, and/or otherwise dispose of the
        Original Code (or portions thereof).

     http://opensource.org/osi3.0/licenses/mozilla1.1.php

     3) Section 3 of the Apache 2.0 License:
     http://opensource.org/osi3.0/licenses/apache2.0.php

I stopped looking at licenses after that, but I'm sure similar
problems can be found with other licenses.  These are licenses that
widely adopted TLS implementations are distributed under.

Thus, it seems that this license may allow some proprietary vendors to
implement tls-authz, but it prevents free software vendors to provide
a GPL/LGPL/Mozilla/Apache/etc implementation because the RedPhone
license is incompatible with these free software licenses.

I don't believe this was the intention.  Mark, would you like to
comment?  I am inclined to believe that Mark's license is more
consequence of lack of understanding how free software licensing
works, rather than bad-faith against free software.

Perhaps there is some use of an informational document that explains
how IPR disclosures needs to be written in order to be free software
friendly.  Mark, others, would such a document be helpful when trying
to write an IPR disclosure?

At this point, I think I'm bringing up a generic concern which also
affects many other drafts with IPR disclosures than Mark's.  It is
somewhat unfair to Mark to have to go through all these discussions
because the IETF doesn't have fully functioning procedures and/or
guidelines on this.  Still, since this document is a good example of
patented technology aiming at the standards track, with a license
incompatible with free software licenses, and I believe the IETF
should discuss the problem -- as a general problem, not just for
Mark's document -- further.

/Simon

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]