RE: For Approval: ECL 2.0

[cdcoppola]

I'm writing to summarize the discussion to-date on approval of ECL 2.0 with the objective of bringing the conversation around to a decision point.

First, let me repeat the key points of my initial post:

Our request is for approval of the Educational Community License 2.0, which is a successor to ECL 1.0. 

Relevant highlights: 

1. "Net Zero Impact on license proliferation within 6 months" - The approval will result in a net zero impact on the number of OSI approved licenses. To the best of our knowledge the ECL 1.0 is only used by communities in Education which have been closely coordinated. All involved will switch to ECL 2.0 as soon as it's approved and then ECL 1.0 can be de-commissioned. We expect this would happen within 6 months. 

2. Ambiguity, lack of explicit patent grants, and ineffective use of contributor agreements are our primary drivers for upgrading the license. Original post: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12705:200704:pinhehafopjimikjkpki

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.

The issues raised in the license-discuss thread with our request for approval boil down to two

Issue #1:  We should make it more clear that the ECL 2.0 is really just the Apache 2.0 with a modified patent license section. We agreed with this and have made a change to the license we believe accomplishes the goal:

https://www.collabtools.org/access/content/user/chris.coppola%40rsmart.com/ECL2.0.doc

Issue #2: The ECL 2.0 limits the scope of the patent license and this is generally not the best thing for the community. We agree with this, but our proposal is the best alternative available to us. The conversation has essentially revolved around the notion that there *may* be an implicit patent license in ECL 1.0 that these same institutions are currently agreeing to. 

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 hard to guess what a court would do in those circumstances. Our goal for the ECL v.2.0 -- and for the contribution agreements that support it, because Sakai, Kuali and the other projects that have adopted the ECL can only pass along whatever patent rights our contributors are willing to give -- is to include an express patent license that covers this scenario, so users don't have to speculate about what a court might do. While we might wish for a broader license that would cover all of the inventions coming out of an entire university or institution -- 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.

 

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.  

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. 

 

Respectfully,

/Chris.

[Brian Behlendorf]

On Mon, 21 May 2007, Christopher D. Coppola wrote:
> 1. "Net Zero Impact on license proliferation within 6 months" - The approval
> will result in a net zero impact on the number of OSI approved licenses. To
> the best of our knowledge the ECL 1.0 is only used by communities in
> Education which have been closely coordinated. All involved will switch to
> ECL 2.0 as soon as it's approved and then ECL 1.0 can be de-commissioned. We
> expect this would happen within 6 months.

OK, this is pretty compelling; still not enough for me personally to
recommend ECL 2.0 over the Apache license, as I disagree that it adds
clarity to the scope of the patent grant, but I now would not encourage
people to vote against its approval.  I think we both share the goal of
seeing ECL 2.0 as a stepping stone to an Apache-licensed Sakai, etc.; the
risk is that if the stone is too comfortable the walker might not have any
motivation to finish the journey.

> 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 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.

> Our goal for the ECL v.2.0 -- and for the contribution agreements that
> support it, because Sakai, Kuali and the other projects that have
> adopted the ECL can only pass along whatever patent rights our
> contributors are willing to give -- is to include an express patent
> license that covers this scenario, so users don't have to speculate
> about what a court might do. While we might wish for a broader license
> that would cover all of the inventions coming out of an entire
> university or institution --

I don't think that's a fair characterization of my position or of the
Apache license; perhaps it was not intended to be, but by presenting that
as the other side, we are moved further away from the goal.  The Apache
CLA only covers the patents the contributor owns that apply to their
contribution, and to the version of the larger software work they
contributed to.  If someone adds an invention later that is owned by the
first contributor, it's not covered.  And the grant only covers the work
and derivative works; it doesn't make any patent grants to other
non-open-source software.

> 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.

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.

> 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.

> 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.

Russ, time to run a vote?

  Brian

[cdcoppola]

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

[Matthew Flaschen]

Christopher D.Coppola wrote:
> 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.

But as Brian pointed out, institution-wide implicit patent licenses are
already common (MIT, Apache, BSD), even if contrary to that policy.  The
only real argument is about whether the implicit license would hold up.

Matt Flaschen