This material was prepared for and submitted to the Mellon-Funded Retreat on Intellectual Property Issues held at Indiana University October 16-17, 2006.
I am publishing this on September 30, 2007 now that the Sakai Board has adopted the ECL 2.0 license for Sakai.
http://www.opensource.org/licenses/ecl2.php
If you read the whole document below and see my recommendation for an ECL 1.1 – this is *not* what happenned – instead the group came up with ECL 2.0 which is a tiny variation on Apache 2.0. I am pleased with the outcome – particularly since has OSI certified ECL 2.0. I think that the folks at the Indiana retreat did a great job and identified some precise use cases that clearly differentiate ECL 2.0 from Apache 2.0.
I did not attend the Indiana meeting because (a) I already had accepted an invitation to attend and speak at the Cal State CIO Retreat and (b) I was probably too emotional at the time about ECL 1.0 to be a positive contributor to the meeting :). Brad Wheeler and I agreed that I should submit my concerns formally and let the sausage get made – in retrospect this was a wise choice as everything turned out very nice – and I played a great round of golf in Santa Barbara looking out over the Pacific Ocean – it was the only round of golf I have played in the last 10 years.
The material below is my unedited submission to the Mellon-Funded Indiana Intellectual Property Retreat. Please read it in the context of October 2006.
October 2006
What is the Right License for Sakai?
My goals for a software license are effectively to give those who might find a use for our software maximum flexibility in how that software will be used. When we produce software today we cannot begin to imagine how that software might be reused in the future – so our gift to those future adopters is maximum flexibility. Our gift of this software must not require *any* interaction with the copyright owner – in the future – the copyright owner may no longer exist – or may have been sold or have transferred their interest to a different party. The license must have no strings attached at all. The critical underlying goals:
– Allow the code to be forked without limitation
– Allow the code to be included in any other application without limitation as to the license of the including application
– Allow the code to be used, retained and modified and re-released in perpetuity
– No requirement to communicate or interact in any way with the holder of the license – the software itself is a “bearer instrument”
– Effectively this can all be summarized as the owner of the license and one who simply possesses the software have equal rights
– These rights should be unaffected if the ownership of the copyright is transferred from one organization to another
The only acceptable limitations:
– Reasonable attribution when the software is included in another application
– Respect for the trademarks and brands of the producers original software – typically this means that you cannot “fork” the code and distribute the code under the same (usually trademarked) name as the original software
The BSD, Apache, and MIT class of licenses generally meet these criteria.
The Sakai Board’s Intent When Drafting the ECL
The Sakai board intended to produce a license that meets all of the above goals – is commercial friendly and was explicitly *not* to be a copyleft license like the GPL. The Sakai board saw copyleft as commercial-unfriendly and preferred the commercial friendly Apache approach which was in the line of the MIT/BSD licenses.
“Copyleft is a general method for making a program or other work free, and requiring all modified and extended versions of the program to be free as well.”.
http://www.gnu.org/copyleft/copyleft.html
The Sakai Board agreed on th ebasic principles and then looked at a number of different licenses and combined elements of those licenses together to produce the ECL 1.0 license.
The ECL Controversy
In May 2005, there was a discussion in Moodle forums about the fact that the ECL license was not GPL-Friendly.
http://moodle.org/mod/forum/discuss.php?d=22988 (login as guest)
Martin Langhoff’s assessment was that Sakai was not GPL-friendly and not fork-friendly.
— Martin Langhoff Quote —-
This makes the GPL pretty strict, that is certain. But most projects consider it in their best interest to use a GPL-compatible license (BSD, LGPL or GPL), specially because it has been estimated that 80% of the FOSS code out there is covered by the GPL.
Well, the ECL has two clauses:
Notice of any changes or modifications to the Original Work, including the date the changes were made.
Any modifications of the Original Work must be distributed in such a manner as to avoid any confusion with the Original Work of the copyright holders.
The first one is relatively harmless, and can be satisfied with a clear changelog. Still, if you fork and fail to maintain the changelog faithfully, you’ll be in breach of the license, as you’ll be misconstruing the extent and character of the modifications made.
The second one quoted here can be interpreted in a number of ways, but the traditional application of it is that a customized project will be distributed as a tarball containing the original files and a series of patchfiles. This is what happened to Minix, and it frustrated Linus (and others) enough to switch to Linux.
— End Martin Langhoff Quote —-
I have had several other similar conversations with laywers with several organizations that concluded that the ECL was not GPL friendly looking at the two clauses – with the biggest problem being the patches clause.
What is Wrong With the Patches Clause?
First this clause is vague – giving no specific guidance as to what is considered acceptable conformance. At some level, with this clause being so vague – the only way to resolve whether an adopter’s notification is acceptable is to test the clause in a lawsuit between the copyright holder and the adopter. The specter of requiring a court decision to interpret this clause is disquieting to many potential adopters who read this carefully.
When lawyers or organizations reviewing the ECL 1.0 take a very conservative reading of this clause and interpret this as allowing the copyright holder (Sakai Foundation Board in this case) as having a hold over future adopters that they would exercise at their option by filing a lawsuit against an adopter at the discretion of the Sakai Foundation Board.
Most organizations do not do an in-depth analysis of the ECL, simply assuming that it is the Apache or BSD-like license because Sakai’s overall message is “our license is just like Apache”. I have been told by some organizations that their lawyers simply did not think that the clause was likely to cause a problem and not worth being concerned about.
The problem comes when an organization takes a more rigorous approach to their licensing – often when considering embedding Sakai in their own product. In these scenarios, lawyers are more sensitive to small risks and tend to take the most dour interpretation of the clauses.
Where Did This Text Come From?
It is likely that the clause came from the OKI OSID license which was looked at during the development of the ECL:
Notice of any changes or modifications to the O.K.I. Work, including the date the changes were made. Any modified software must be distributed in such as manner as to avoid any confusion with the original O.K.I. Work.
http://okicommunity.mit.edu/javadoc/org/osid/SidImplementationLicenseMIT.html
The ECL words almost are identical to the W3C software license.
http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
“Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.)”
This is similar to the thrust of this clause in the GPL (http://www.gnu.org/licenses/gpl.html)
“You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.”
These clauses all are in the GPL vein of not allowing folks to make changes to code and not share the changes publicly and broadly. This text is part of the backbone of copyleft: “Copyleft is a general method for making a program or other work free, and requiring all modified and extended versions of the program to be free as well.”.
http://www.gnu.org/copyleft/copyleft.html
So ultimately the ECL 1.0 is a remix of the MIT, BSD, with just a tiny touch of copyleft sprinkled in.
Is the ECL GPL Friendly?
The most common complaint that I get about the ECL 1.0 is that it is not “GPL-Friendly” – often pointing to either the patch clause or the advertising clause in ECL 1.0.
Lets compare the clauses in the ECL 1.0 to the clauses in the W3C license:
http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
http://www.opensource.org/licenses/ecl1.php
ECL Patch Clause:
Notice of any changes or modifications to the Original Work, including the date the changes were made.
W3C Patch Clause:
Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.)
ECL Advertising Clause:
The name and trademarks of copyright holder(s) may NOT be used in advertising or publicity pertaining to the Original or Derivative Works without specific, written prior permission. Title to copyright in the Original Work and any associated documentation will at all times remain with the copyright holders.
W3C Advertising Clause:
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders.
Other than parenthesis – these are identical.
Just for reference, according to GNU, W3C *is* GPL-friendly
http://www.gnu.org/philosophy/license-list.html
But bright lawyers lawyers looking at the ECL decide that the ECL is GPL-unfriendly. Hmmm.
Perhaps people have a general bad taste in their mouth about advertising clauses because of the original BSD clause (http://www.gnu.org/philosophy/bsd.html).
All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors.
Read the above URL for a good explanation of the problems – modern advertising clauses like ECL and W3C are much more reasonable – in a sense – they restate basic obvious trademark law.
Is the Apache 2 License GPL Friendly?
Interestingly nearly all people *assume* that Apache licenses are compatible with the GPL. Sadly this is not the case according to GNU.
— Quoting: http://www.gnu.org/philosophy/license-list.html —-
Apache License, Version 1.0
This is a simple, permissive non-copyleft free software license with practical problems like those of the original BSD license, including incompatibility with the GNU GPL.
Apache License, Version 1.1
This is a permissive non-copyleft free software license with a few requirements that render it incompatible with the GNU GPL.
We urge you not to use the Apache licenses for software you write. However, there is no reason to avoid running programs that have been released under this license, such as Apache.
Apache Software License, version 2.0
This is a free software license but it is incompatible with the GPL. The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don’t think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)
— End Quote: http://www.gnu.org/philosophy/license-list.html —-
Interestingly, the GPL license is not compatible with Apache because Apache intends to *not* be copyleft – GPL declares that Apache 2 is *almost* GPL-friendly but not quite due to a small technicality that the GPL folks feel is a good clause but – sadly “only 99.99% compatible with the GPL”. Hmmm.
Summary to This Point
Sakai intended the ECL to be commercial-friendly, copyleft-free, and GPL-friendly. At some level none of these were accomplished. If I were on the way to argue in court – I would suggest that I could prove that ECL *is* GPL-friendly as long as I had a chance to face the charges “ECL is not GPL-friendly”. I would posit that when organizations are making the GPL-friendly analysis it is often an attempt to move a product choice into a license choice decision.
If you can get Sakai (using the ECL) declared as GPL-unfriendly at an organization that has policies about GPL, then Sakai is automatically out of the running in terms of consideration.
So the GPL-friendly analysis is a little “subjective” at best.
What is a Project Who wants to Do the Right Thing to Do?
All we want is a non-copyleft GPL-friendly license. Is that so hard? Lets look at the possible licenses we can use:
ECL – Has a whiff of copyleft – smart people and smart lawyers find ECL to be GPL-incomatible sometimes
Apache – Not GPL-compatible – Maybe this is resolvable – but this smacks of a soap opera – probably want to stay away.
GPL – Has a lot of copyleft (not surprisingly)
BSD (modified) – http://www.opensource.org/licenses/bsd-license.php – The advertising-free BSD license. Not too bad. GPL friendly and commercial friendly. Could benefit from a clause about the use of product names and trademarks. A little thin.
MIT license – http://www.opensource.org/licenses/mit-license.php – this minimalist and probably needs some of the clauses about trademark, etc.
What is the Real Problem Here?
There are two dimensions of licensing. Lets just look at GPL and Apache for the moment. Both licenses generally grown and get more complex over time as new problematic use cases are identified and new wording is needed to cover these issues.
As the Apache license grows, it adds more and more complex wording that makes it increasingly likely that something in the long Apache 2 license will conflict with something in the long GPL license and the even longer GPL 3 license.
Maybe the big guys will work this all out with an Apache 3 and GPL 3 that fit like a glove and then we will only have two licenses for ever going forward. No one will every change a word for the next 100 years so as not to break the interdependencies. A thought I have is that they simply share identical text where there is overlap between Apache and GPL.
So what do we do trying to survive the clash of the titans.
Lets Invent Our Own License and Not Make Mistakes this Time
We tried that and after 1.5 years it is still painful with the ECL. But then we still end up having to fight to get respect and validation from the GPL and OSI.
A case study in trying to start from scratch and do the right thing is here:
http://en.wikipedia.org/wiki/Academic_Free_License
http://www.opensource.org/licenses/academic.php
– This license has gone through versions 1.2, 2.1, and now 3.0 – all in trying to get everyone happy. This is a four year effort by Lawrence E. Rosen, general counsel of the Open Source Initiative itself.
The AFL license set out to do everything right – but in the end is simply not GPL-friendly no matter how hard they tried.
http://opensource.org/licenses/academic.php
Is There *any* Hope, or is this Simply Impossible?
The essential problem is that GPL holds the “strings” to the “GPL-compatible” certification and OSI holds the keys to the OSI certification. So I just decided to “give up” and look through the already GPL-Friendly Licenses and see if we find one we like. Avoid the “too simple licenses”, copyleft licenses and insist that the license be OSI certified.
Go through this URL with me: http://www.gnu.org/philosophy/license-list.html
Too Simple:
Modified BSD, Intel Open Source, MIT
Kind of Messy:
Python
Hint of CopyLeft
W3C, ZOPE
Not OSI Certified:
OpenLDAP, Vim, ZLib, Clarifiied Artistic, Vim, Ruby, X11, FreeBSD
So guess what – after 20 years of genetic evolution of Open Source Licenses – There is no license in existence which meets all four criteria of (1) non-trivial, (2) non-copyleft, (3) GPL-friendly, and (4) OSI Certified.
So What to Do?
I literally cannot believe that after all of this analysis, I have reached the following conclusion. You have no idea how much I have grown to dislike the ECL license and the burden of working with a non-mainstream license.
I think that the next interim step is to revise the ECL and remove the copyleft clause. Not change another word. Submit this to GNU to see if GNU would declare it GPL-compatible. If GNU sees ECL 1.1 as GPL-Compatible submit the license to OSI – OSI will claim licens proliferation – but based on the analysis above – Uh – there is no suitable license available (Modified BSD is the closest).
If GNU declares ECL 1.1 as not Compatible with the GPL or if OSI refuses to accept ECL 1.1 – then I would suggest that we pitch it ECL and simply go with Modified BSD. I do not like this because ECL has more modern wording (see also ZOPE) and includes some nice “state the obvious clauses”.
I feel in my heart that this is an interim step and that eventually Apache and GPL will work things out and Some version of Apache will be GPL-compatible. On that day, I would drop the ECL in a heartbeat and switch to Apache.
Placing my Comments in the Overall Meeting
My comments in this document are solely focused on the choice of license of the final product.
Looking back at the Sakai experience – the Contributor Agreements have been a far more complex issue and the Apache CLA’s that we adopted in Sakai have had real challenges as they CLA’s have been examined by various organizations and found to have legally unacceptable clauses in them. Because much of Apache’s participation is centered on the individual and not the organization – the Apache CLAs are sufficient for Apache.
Clearly project like Sakai, Kuali, and the Student Services project are characterized by the significant involvement of organizations in addition to individuals. Some of the legal exchange in the Apache that individuals just ignore and sign when joining Apache (I signed a 30 page document when I joined JSR-286 as an individual) are simply not acceptable when a university officer is signing the document. This is particularly true when Universities do have wide ranging patent portfolios and other aspects.
I think that what this group needs to talk about is to fully tease out the right/responsibility flow in the CLA’s and make the right choices by finding the right balancing point. In essence the discussion of a CLA that is Higher Ed focused is breaking wonderful new ground and ground that needs exploration. The current CLAs that we see work OK for individuals and kind of OK for companies – but need some adjustment for Universities.
Just like when Apache had to go form a simple individual oriented CLA to a corporate CLA – when presented with a unique new problem – with demonstrated new use cases – we need to build a new solution.
I will just state for the record that I am completely *not* an expert on CLAs and as such not much use in a CLA discussion – I feel that the people coming to this meeting are ideally suited to make some wonderful progress on evolving a new for of CLA that will meet the needs of higher education IP and TT. My guess is that it will be a variation on the Apache CLA that ends up looking at the experience of customizing that to fit the various schools.
Another important secondary topic is the discussion of a Membership agreement for organizations like Kuali Foundation and Sakai Foundation which use consortium-style memberships . We find that we are evolving our understanding of membership agreements as we negotiate each membership agreement with each new member. Again, like the CLA, policies, laws and procedures at some schools simply make it impossible to sign an unmodified membership agreement. To me this territory is even less charted than the CLA area which is about 2/3 charted by Apache. SO if the group has time left over after talking about CLAs for two days – perhaps membership agreements could be a fresh topic to consider.
The key distinction is that the license is how we license the output of our collaboration and the contributor and membership agreements define the legal structures which we use to work together so as to *produce* the product. Lets keep those separate. Membership agreements and CLA’s are the backbone for the business model for university participation in consortial development. We do not need to push our “business model” up into the license agreement.
Good luck to you and have a successful meeting.
Charles Severance
Executive Director Sakai Foundation