RE: [security-services] Liberty IPR Issues (was: Liberty ID-FF 1. 2 submission to the SSTC)

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Just to (hopefully) close the loop on this specific set of points...

>  > "2. Each Author commits to grant a non sub-licenseable, non-
> transferable
>  > license to third parties, under royalty-free and other reasonable and
>  > non-discriminatory terms and conditions, to certain of their respective
>  > patent claims that such Author deems necessary to implement required
>  > portokions of the WS-Security specification, provided a reciprocal
>  > license
>  > is granted."
>  >
>  > This promises that the "authors" of the original WSS spec that was
>  > contributed to WSSTC will grant RF-reciprocal license rights to anyone
>  > implementing the OASIS TC spec for any IP claims
> 
> I don't see "OASIS TC spec" in that statement.  I see a specific
> reference to the document that was submitted.  Now, there may not have
> been material changes to the specification so that this still applies to
> the product of the TC.  However, there is nothing in the statement above
> that says that should a "derivative" work be documented by the TC, the
> grant would still apply (and NOTE that I would not expect such a
> statement to be there -- it would be asking too much from the owners of
> the IP to make such a statement without seeing what you were going to do
> with the IP).
> 
[Rob] Item #1 in the WSSTC IP declaration only pertains (I believe) to the
creation of specs (as Rich stated - rights to "push paper, not create
bits").  But it DOES state "for the purpose of further developing the
WS-Security specification in the WSSTC as set forth in the draft WSS TC
charter".  "the WS-Security Specification in the WSSTC"  sounds like "an
OASIS TC spec" to me. And #1 does discuss creating derivative works
("...grants permission to OASIS and OASIS members the right to copy,
display, perform, modify ... the draft specification...").  The derivative
works would be specs, not implementation.

Item #2 pertains to implementation.  Unfortunately, the wording refers to
the "WS-Security" spec, which in Item #1 is ambiguously defined.  It first
refers to the author's submission of the old draft spec and then by saying
it is to be further developed by the WSSTC, it implies the output of the TC.


But I really don't believe there is any doubt that the authors really are
referring to the output of the TC.  I've heard both IBM and MS make it clear
on multiple occasions in public statements that they intend to license IP
required to implement the WS-Sec **standard** on an RF-reciprocal basis.
This is, I truly believe, what they intended with item #2.  The words in the
WSS IP declaration may be ambiguously written in this regard, but that is
what I hear Tony claiming in this discussion.

> 
>  > As one of the contributors of the ID-FF specs to SSTC, I am willing to
>  > make a statement that RSA will offer RF-reciprocal licensing for
>  > implementing SAML that includes derivative ID-FF content.  If the
>  > other  contributors also do this, then I believe we will have done
>  > exactly as was done in WSS.
> 
> Not being one of the contributors of the specs to the SSTC, but being
> one of the contributors to the original specifications and being one of
> the companies who has IP in the ID-FF, we have offered reciprical-RF
> terms on all of the stuff in the liberty specifications.  We plan to do
> the same here in the SSTC once we see what it actually is that gets done.
> 
[Rob] You (and Scott also in his response) raise a good point.  We (RSA)
also can't actually offer reciprocal-RF terms until we see what actually
gets defined by SSTC.  Note that I also really should have said that we
would "commit to grant...". That's actually the phrase used by the WS-Sec
authors.

> However, I would be strongly resistant to making a statement that says
> "anything you do in the SSTC will be granted IPR to any IP owned by AOL"
> unless I can first see exactly what we are talking about.

[Rob] Okay... But the SSTC can ONLY do what's defined in its charter. My
statement really was assuming that the SSTC sticks to defining capabilities
consistent with that charter. RSA wants strong SAML adoption, so we're
interesting in making that as easy as possible (within certain corporate
constraints - e.g. reciprocity). So we're willing to "commit to grant"
reciprocal-RF licensing for what we build; and that by definition has to be
consistent with the charter.

> 
> Conor