www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: IBM and WS-Security
Date Fri, 24 Jun 2005 02:15:47 GMT
Jeff,

Please see below.

On 6/23/05, Jeffrey Thompson <jthom@us.ibm.com> wrote:
>  
> 
>  Davanum Srinivas <davanum@gmail.com> wrote on 06/23/2005 11:22:45 AM:
>  
>  > Jeff,
>  > 
>  > Let's start fresh. Is IBM willing to allow Apache to write a
>  > WS-Security Implementation?
>  
> Certainly.  That was why we contributed it to OASIS and why we made an RF
> patent commitment.  As am aside, I'm not aware that we've identified any
> necessary patents for WS-Security.   

This is what i expected, Since i could not find anything. 

>  > We already have code, and have participated in interops, but have not
>  > made a release yet (http://ws.apache.org/ws-fx/wss4j/).
> Current terms
>  > published by IBM
> (http://www.ibm.com/ibm/licensing/977Q/2112.shtml)
>  > are incompatible with Apache License/Process. 
>  
> I think we have a basic disagreement here.  IBM's patent terms are not
> incompatible with Apache's license or Apache's open source model. 

Great!!!

> >                                                I have detailed feedback
>  > almost clause-by-clause for the IBM License (and the Microsoft
>  > License), but that defeats the purpose...It's better for us to specify
>  > what we'd like to see in a modified license from IBM (and Microsoft).
>  
> Actually, I haven't seen that (I'm not always able to read all of the list
> postings).  No need to bore everyone else with repetition, but if you want
> to send it to me off list, I'd appreciate it. 

Please see my other email. 

> > BenL and me were discussing this morning on what to request IBM and
>  > MSFT w.r.t WS-Security license. Here is the list:
>  > 
>  > 1. Users should be able to download our code and run it without further
>  > action on their part (obviously they should be aware of the licence and
>  > comply with it, but should not need to do anything beyond the normal
>  > requirements of the Apache Licence 2.0).
>  
> Obviously.  At that's what happens under the current licenses.  Under the
> doctrine of patent exhaustion, if a maker of a product (here, Apache) is
> licensed to practice a patent when it makes the product, users of that
> product are also covered. 

ok. we are on the same page.

>  > 2. The licence should not require implementations to be compliant (as we
>  > agreed, this is an incomprehensible requirement anyway).
>  
> I'm not sure why you are singling out WS-Security on this point.  Every Java
> specification license includes compliance requirements and I expect that all
> of the patent licenses pursuant to the W3C Patent Policy are limited to
> "implementations of the recommendation".  Is your point that it is not clear
> what "compliant" means in the absence of a test suite, or that the concept
> of compliance is itself incomprehensible.  If its the former, take the
> normal meaning -- that the implementation actually implements the spec
> correctly.  If its the latter, I'm not sure how to respond. 

Yes, "absence of a test suite" is the problem. We can't test compliance.

>  > 3. There should be no restrictions beyond those imposed by Apache
>  > Licence 2.0.
>  
> Again, why are we singling out WS-Security.  The Java spec licenses include
> additional restrictions as do pretty much all existing patent licenses for
> standards (W3C or otherwise).  The question is whether the additional
> restrictions impose an inappropriate burden on Apache or its licensees. 
> There was a germ of a discussion a few months ago (February 05) on this list
> about what Standards are compatible with Apache's approach to life.  At that
> time, I wrote in response to a post by Larry Rosen: 
>  
> --In any event, Apache guidelines would address, in my mind, at least three
> basic questions: 
> -- 
> --1.  Can Apache get the standard?  If we can't get it, we can't implement
> it. 
> -- 
> --2.  Can Apache publish its implementation under Apache's license?  This is
> --the most critical.  Any standards agreement that prevents open source 
> --implementations shouldn't be embraced by Apache. 
> -- 
> --3.  Is Apache opening itself or its customers to royalties for necessary 
> --patents?  This is the hardest to answer.  Your definition of open
> standards 
> --spent a lot of time talking about the details of the patent licenses, but
> in 
> --the end, the question is whether the open source project and its customers
> --qualify for the free license.   
>  
> The third item is the most relevant to the current conversation.  I think
> that this list is still accurate, and as far as I can tell WS-Security meets
> those requirements.   

Please see the other email. For example, Section 1.3 talks about
sublicensing as applied to subsidiaries ONLY. which is irrelevant to
ASF's model or open source in general.

>  > 4. Another instance of conflict with AL 2.0 is the requirement for
>  > compliance with U.S. Export laws - this needs to go.
>  
> I don't see an Export law term in the IBM license. 

My bad! this line was for MSFT license.

>  > 5. Note that the Apache Licence
>  > (http://www.apache.org/licenses/LICENSE-2.0.html) has a
> clause relating
>  > to patents which may well work in the way you want already - clause 3.
>  
> The patent grant in the AL2 performs a completely different function than a
> patent grant that applies to implementations of a Spec and necessarily
> focuses on different issues.  When a company contributes CODE to Apache,
> knowing that the code will be licensed liberally to the world, it is
> important to know that that company isn't going to go around and sue the
> licensees of that code for patent infringement just for using that code. 
> There are few restrictions on that patent license, but it is tied to the
> code. 
>  
> For specification related patent licenses, there is no code, or at least not
> yet.  The license is necessarily focused on implementations of the Spec. 
> Anyone who writes code that implements that Spec is covered, unlike the
> license in AL2 which only covers licensees of the Apache code.  So, in some
> ways, the AL2 license is too broad (it covers the code, whatever it is used
> for), and in others, its too narrow (it doesn't cover non-Apache licensed
> code). 

Ok. understood.

> I think that this is an important issue for Apache, because it seems to me
> that if Apache applies the rules that it seems you are applying here, most
> (if not all) of the current projects will have problems.  In some sense,
> patent licenses that are tied to specifications are orthogonal to the AL2
> license.  I don't think you can force them to be parallel, and if you filter
> out all licenses which are not, you will likely end up with a null set of
> specifications to implement. 
>  
> FYI, I'll be non-connected for most of tomorrow, but will try to respond to
> any comments when I get e-mail access. 

I guess, i am being cautious, the IPR statements on the OASIS web site
says, we have to get licenses from IBM/Versign/MSFT and thats what we
are trying to do...I don't know how else to tackle this.

Let me take a more concrete example, one that has bitten us before.
RSA Security has a patent on SAML and they have made public noise
about it. They are forcing OpenSAML project to put up a disclaimer
that says:

"Note that RSA has published their patent licensing terms for SAML
toolkits, and developers using OpenSAML may be subject to the terms
and may evaluate the license at
http://www.rsasecurity.com/solutions/standards/saml/."

I was told that Apache will *NEVER* allow such a disclaimer/verbiage
on *ANY* project and the incubation was cancelled. See
http://marc.theaimsgroup.com/?l=incubator-general&w=2&r=1&s=opensaml
for all the gory details.

I myself don't know why web services projects are getting this special
attention.

Thanks
dims

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message