For Approval: ECL 2.0

[Christopher D. Coppola]

On May 23, 2007, at 3:00 AM, Brian Behlendorf wrote:
> > 3. A core part of our IP management practices include using  
> contributor
> > license agreements. Our CLA's are based on Apache's CLA's with  
> one change to
> > limit the scope of patent grants. This is a requirement for the  
> large
> > research universities involved in our projects at present. This  
> is the reason
> > *we cannot simply adopt the Apache license and CLA's." We have  
> been working
> > with institutional counsel for 2 years. Though we are making  
> progress, it is
> > likely to take years to change the IP policies of major  
> universities like
> > University of California and MIT.
>
> Which is hard for me to understand, as these organizations have  
> released
> code under the BSD licenses for ages, which had an even vaguer and
> (generally-interpreted-as) much more generous license, and I know  
> there
> have been contributions from Berkeley and MIT employees to various  
> Apache
> projects (with institutional approval, I don't know, but can only  
> assume).
> And I still can't get past the karmic undertone of the request,  
> that the
> contributors want to still be in a position to litigate against  
> people who
> create derivative works based on patent IP in their contributions.
The key thing to understand is that the IP policy of many  
institutions gives individual researchers  (including many who are  
not associated with our project in any way) an interest in proceeds  
from licensing their patents. These institutions are allowing  
individual faculty and IT staff to contribute to our project, and  
they are willing to agree that any patents these individuals are the  
inventor of will be licensed, but they are concerned that it would  
not be fair or consistent with that policy to license patents created  
by individuals who have not made a decision to contribute to Sakai.
>
> > The idea that there might be an implied patent license is an  
> interesting one.
> > If a contributor knew that a particular patent to which they held  
> the rights
> > would be infringed by their contribution, and failed to disclose the
> > existence of the patent at the time of the contribution, it could  
> well be
> > that a court would find some form of implied patent license.
> > But it’s har to guess what a court would do in those circumstances.
>
> Didn't the Rambus case from a few years back set a precedent?  As I  
> recall
> (and I'm not net-connected at the moment to be sure), Rambus  
> advocated to
> a consortium of memory chip manufacturers a particular approach  
> that later
> Rambus sought patent licensing for.  The courts, IIRC, found against
> Rambus in that case.  I forget if the decision was based on  
> contract law
> (did Rambus agree in contract to disclose any related IP, or to not  
> sue
> over any they had?) or if it was based on antitrust (given that a  
> patent
> is a temporary monopoly), or something else.  But it seems like it  
> would
> at least be a touchstone for any judge considering a case like this.
I'm not familiar with the  Rambus case, but I asked the attorney who  
helps Sakai  with its IP management practices about it, and this is  
what he said :

"The Rambus situation was, and unfortunately continues to be, a  bit  
of a nightmare.  When industry competitors collaborate to set  
standards, they are typically asked to disclose any patents they hold  
or are applying for that may be relevant, so that they cannot "steer"  
the standard (and thus their competitors) towards their own patented  
technology.   Many feel that Rambus failed to disclose its patents  
and steered the standard towards its patents, and then proceeded to  
litigate against various players in its industry.  The result has  
been numerous court cases and appeals  (including a number the  
unsuccessfully tried to assert Rambus' conduct as a defense to patent  
infringement),  and many  millions of dollars of legal fees, not to  
mention hundreds of millions in royalties paid to Rambus that are  
unlikely to ever be repaid.  The FTC stepped in at the last minute  
and found a basis in antitrust law to limit Rambus's ability to  
enforce its patents under these circumstances,  but even now the  
remedies the FTC has proposed (limits on royalty rates, etc.) would  
be forward looking only, and the FTC's decision is still being  
appealed to see if it will stand up.  It is, unfortunately, a good  
example of the problems you can run into when you try to rely on   
implicit understandings and equitable arguments."

...
>
> > and indeed, we fought hard for as broad of a patent license as  
> possible,
> > both in our discussions with individual contributors and their
> > institutions, and during the international summit on open source
> > licensing in higher education that we organized -- many institutions
> > just couldn’t agree with this because they felt that this would in
> > effect force all of the inventors at that institution to be  
> contributors
> > to the project.
>
> Then there was massive misunderstanding of the CLA, unless again  
> the case
> is overstated.  You're on better ground when describing the limits the
> university has on granting access to some of the patents they claim to
> own, patents derived from research funded jointly with other  
> institutions
> - as that moves an inadvertant grant from simply "loss of revenue  
> to the
> institution from commercial outfits that create derivative works" to
> "breach of contract with second institution".  But even then, I  
> have to
> work to arrive at a place of compassion for that position.  Given  
> that the
> first institution presumably conducts joint research with more than  
> one
> other institution, there must be some tracking process to ensure  
> that the
> joint work with a third institution doesn't infringe inadvertantly  
> upon
> the patents granted on the work conducted between first and second
> institution.  I would guess this to not be an uncommon concern  
> given that
> all three (or N) institutions may be focusing on the same research  
> topic,
> such as cancer fighting or nanotech, and thus keeping track of who  
> owns
> what patents would be very important.
The problem here is not collaboration between institutions, but  
rather conflicting obligations that the university has to its faculty  
and IT staff. On the one hand, they want to let staff participate in  
this project, and see it as valuable for the community.  On the other  
hand, they are worried about impacting the rights of other staff who  
are not contributors.
>
> Ah, I see a second vector of attack to possibly justify such a  
> sentence.
> Let's say that I wish to rob Berkeley of its right to enforce U.S.  
> patent
> 31337.  I write code that implements that patent and get it into  
> the Sakai
> project.  A Berkeley developer signs the CLA (which in this story  
> looks
> like the Apache CLA) makes a contribution, which carries with it
> Berkeley's grant of any patent rights to the contributed whole...  
> which at
> that point includes my code, unbeknownst to Berkeley.  Thus, patent  
> 31337
> has been "liberated", because anyone who can create a derivative  
> work of
> my 31337-implementing code has also inherited Berkeley's patent  
> grant, and
> the Apache license allows them to work that code into unrelated  
> commercial
> software and still inherit that grant.  Of course, this approach  
> does not
> work for non-software-related patents, and ignores the difficulty in
> isolating "patent that implements the code" and injecting that into
> existing software so as to avoid patent licensing fees.
>
> I really have to stand on my head to get enough blood to the brain to
> visualize this as being a reasonable risk that can not be  
> mitigated.  It
> seems like it would be very straightforward for an institution's  
> patent
> licensing office to give their engineering staff a list, ordered by
> associated revenue or mutual-defense value, of patents that are  
> generating
> income and whose loss would be measurable, so as to avoid  
> contributions
> that would lead to such an inadvertant grant.
Happily, the universities have not expressed much concern that the  
project will add features or functionality that was not contemplated  
at the time of the original contribution, effectively broadening the  
scope of the license they thought they were granting.
>
> > It is important to us that we have contributor license agreements  
> which
> > provide explicit copyright and patent licenses to each  
> contribution. If ECL
> > 2.0 is not approved, we will be forced to stick with ECL 1.0  
> which give us no
> > ability to leverage CLA's for many of our key contributors. This  
> surely isn't
> > the best alternative for our communities.
>
> ECL 2.0 requires the software recipient to go back through the
> contribution history - which could be very inscrutable even to core
> developers - to understand exactly who contributed the code that  
> applies
> to a patent grant, and who that person happened to be working for  
> at the
> time of their contribution.  It's even conceivable that a contribution
> doesn't directly implement a patent (thus not providing a grant), but
> enables it in related code, or turns it on by default, and could  
> become a
> proxy for the dreaded submarine patent.  I would hope the lawyers have
> weighed this jeopardy and the diligence it'll require as an end-user
> against the benefits the ECL 2.0 patent language provides.
>
> Apache's license and CLA, by contrast, in the worst case might require
> knowing whether the version at the time of contribution in question
> implemented the patent in question, but over the long term  
> (covering older
> patents held by historic contributors) reduces the possibility of
> surprises.
ECL 2.0 just requires you to, in effect, treat the individual as the  
one who made the contribution, rather than treating the institution  
as the one who made the contribution.  It does require some diligence  
on our part -- it requires that we verify there are no funding  
agreements in place that might conflict with the license grant.  Of  
course, Apache 2.0 arguably has the same issue.  It covers only  
patents that are "licensable" by the contributor, perhaps excluding  
patents that are already subject to an exclusive license to someone  
else and thus not "licensable."
>
> > In summary, we are respectfully requesting that ECL 2.0 be  
> approved. Of two
> > issues raised, we addressed one as suggested, and the other we've  
> provided
> > compelling reasoning why it cannot be addressed at this point. We  
> intend to
> > remain vigilant on the matter and eventually hope these projects  
> and our
> > efforts will effect a reform in institutions' IP policies. This  
> is going to
> > take years, but once we've succeeded, we would endeavor to move  
> to a popular
> > license such as the Apache 2.0 license.
>
> I think I've said all I need to say on this.  It really does come  
> down to
> a value judgement on the part of this community, as to whether an
> acceptable balance is struck between incentives for contributors  
> and legal
> reassurance for users.  Open Source has long been about  
> constraining the
> flexibility of contributors and licensors in the interests of  
> recipients,
> and I think because of this, the implicit economic value realized by
> recipients has been huge.
We believe we're striking the best balance we're able here Brian. We  
do appreciate the time and energy that the participants on this list  
have put into this conversation and hope we've made a clear case  
that, while not without some compromises, the license we're proposing  
is consistent with the goals of OSI, the OSD, and the best choice for  
our community at this time.
>
> Russ, time to run a vote?
>
>         Brian
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070604/61a7eec4/attachment.html>