With the annual Kuali conference – Kuali Days – starting today in Indianapolis, the big topic should be the August decision to move from a community source to a professional open source model, moving key development to a commercial entity, the newly-formed KualiCo. Now there will be two new announcements for the community to discuss, both centering on a esoteric license choice that could have far-reaching implications. Both the announcement of the Ariah Group as a new organization to support Kuali products and the statement from the Apereo Foundation center on the difference between Apache-style and AGPL licenses.
AGPL and Vendor Protection
Kuali previously licensed its open source code as Educational Community License (ECL), a derivative of the standard Apache license that is designed to be permissive in terms of allowing organizations to contribute modified open source code while mixing with code with different licenses – including proprietary. This license is ‘permissive’ in the sense that the derived, remixed code may be licensed in different manners. It is generally thought that this license type gives the most flexibility for developing a community of contributors.
With the August pivot to Kuali 2.0 / KualiCo, the decision was made to fork and relicense any Kuali code that moves to KualiCo to use the Affero General Public License (AGPL), a derivative of the original GPL license and a form of “copyleft” licensing that allows derivative works but requires the derivatives to use the same license. Ideally the idea is to ensure that open source code remains open. No commercial entity can create derivative works and license with different terms.
The problem is when you have asymmetric AGPL licenses – where the copyright holder such as KualiCo does not have the same restrictions as all other users or developers of the code. Kuali has already announced that the multi-tenant cloud-hosting code to be developed by KualiCo will be proprietary and not open source. As the copyright holder, this is their right. Any school or Kuali vendor, however, that develops its own multi-tenant cloud-hosting code would have to share this code back with KualiCo relicense and share this code publicly as open source. If you want to understand how this choice might create vendor lock-in, even using an open source license, go read Charles Severance’s post. Update: fixed wording about sharing requirements.
To their credit, the Kuali Foundation and KualiCo are very open about the intention of this license change, as described at Inside Higher Ed from a month ago.
[Barry] Walsh, who has been dubbed the “father of Kuali,” issued that proclamation after a back-and-forth with higher education consultant Phil Hill, who during an early morning session asked the Kuali leadership to clarify which parts of the company’s software would remain open source.
The short answer: everything — from the student information system to library management software — but the one thing institutions that download the software for free won’t be able to do is provide multi-tenant support (in other words, one instance of the software accessed by multiple groups of users, a feature large university systems may find attractive). To unlock that feature, colleges and universities need to pay KualiCo to host the software in the cloud, which is one way the company intends to make money.
“I’ll be very blunt here,” Walsh said. “It’s a commercial protection — that’s all it is.”
My post clarifying this interaction can be found here.
Enter Ariah Group
On Friday of last week, the newly formed Ariah Group sent out an email announcing a new support option for Kuali products.
Strong interest has been expressed in continuing to provide open source support for Kuali®products therefore The Ariah Group, a new nonprofit entity, has been established for those who wish to continue and enhance that original open source vision.
We invite you to join us. The community is open to participants of all kinds with a focus on making open source more accessible. The goal will be to deliver quality open source products for Finance, Human Resources, Student, Library, Research, and Continuity Planning. The Ariah Group will collaborate to offer innovative new products to enhance the suite and support the community. All products will remain open source and use the Apache License, Version 2.0 (http://opensource.org/licenses/Apache-2.0) for new contributions. A number of institutions and commercial vendors will be announcing their support in the coming days and weeks.
To join or learn more visit The Ariah Group at http://ariahgroup.org/
Who is the Ariah Group? While details are scarce, this new organization seems to be based on 2 – 3 current and former Kuali vendors. As can be seen from their incomplete website, the details have not been worked out. The group has identified an Executive Director, based on an email exchange I had with the company.
The only vendor that I can confirm is part of Ariah is Moderas, the former Kuali Commercial Affiliate that was removed as an official vendor in September (left or kicked out, depending on which side you believe; I’d say it was a mutual decision). I talked to Chris Thompson, co-founder of Moderas, who said that he understood the business rationale for the move to the Professional Open Source model but had a problem with the community aspects. The Kuali Foundation made a business decision to adopt AGPL and shift development to KualiCo, which makes sense in his telling, but the decision did not include real involvement from the Kuali Community. Chris sees that the situation has changed Kuali from a collaborative to a competitive environment, with KualiCo holding most of the cards.
This is the type of thinking behind the Ariah Group announcement – going back to the future. As described on the website:
We’ve been asked if we’re “branching the code” as we’ve discussed founding Ariah and our response has been that we feel that in fact the Kuali Foundation is branching with their new structure that includes a commercial entity who will set the development priorities and code standards that may deviate from the current Java technology stack in use. At Ariah our members will set the priorities as it was and as it should be in any truly open source environment. Java will always be our technology stack as we understand the burden that changing could cause a massive impact to our members.
This is an attempt to maintain some of the previous Kuali model including an Apache license (very close to ECL) and the same technology stack. But this approach raises two questions: How serious is this group (including whether they are planning to raise investment capital)? And why would Ariah expect to succeed when Kuali was unable to deliver on this model?
While this move by Ariah would have to be considered high risk, at least in its current form without funding secured or details worked out, it adds a new set of risks for Kuali itself as the Kuali Days conference begins. Kuali is in a critical period where the Foundation is seeking to get partner institutions to sign agreements to support KualiCo, contributing both cash and project staff. Based on input from multiple sources, only the University of Maryland has already signed a Memo of Understanding and agreed to this move for the Kuali Student project. Will the Ariah Group announcement cause schools to either reconsider upcoming decisions or even to just delay decisions. Will the Kuali project functional councils be influenced by this announcement on whether to move to the AGPL license.
I contacted Brad Wheeler, chair of the Kuali Foundation board, who added this comment:
Unlike many proprietary software models, Kuali was established with and continues with a software model that has always enabled institutional prerogative. Nothing new here.
Apereo Statement
In a separate but related announcement, this morning the Apereo Foundation (parent organization for Sakai, uPortal and other educational open source projects) released a statement on open source licenses.
Apereo supports the general ideas behind “copyleft” and believes that free software should stay free. However, Apereo is more interested in promoting widespread adoption and collaboration around its projects, and copyleft licenses can be a barrier to this. Specifically, the required reciprocity of copyleft licenses (like the GPL and AGPL) is viewed negatively by many potential adopters and contributors. Apereo also has a number of symbiotic relationships with other open source communities and projects with Apache-style licensing that would be hurt by copyleft licensing.
Apereo strongly encourages anyone who improves upon an Apereo project to contribute those changes back to the community. Contributing is mutually beneficial since the community gets a better project and the contributor does not have to maintain a diverging codebase. Apereo project governance bodies that feel licensing under the GPL or AGPL is necessary in their context can request permission from the Licensing & Intellectual Property Committee and the Apereo Foundation Board of Directors to select this copyleft approach to outbound licensing.
Apereo believes that the reciprocity in a copyleft open source software project should be symmetrical for everyone, specifically that all individuals and organizations involved should share any derivative works as defined in the selected outbound license. Apereo sponsored projects that adopt a copyleft approach to outbound licensing will be required to maintain fully symmetric reciprocity for all parties, including Apereo itself.
Those seeking further information on copyleft licensing, including potential pitfalls of asymmetric application, should read chapter 11 of the “Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide – Integrating the GPL into Business Practices”. This can be found at –
http://www.copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-10400011.2
While Kuali would appear to be one of the triggers for this statement, there are other educational changes to consider such as the Open edX change from AGPL to Apache (reverse of Kuali) for its XBlock code. From the edX blog post describing this change:
The XBlock API will only succeed to the extent that it is widely adopted, and we are committed to encouraging broad adoption by anyone interested in using it. For that reason, we’re changing the license on the XBlock API from AGPL to Apache 2.0.
The Apache license is permissive: it lets adopters and extenders do what they want with their changes. They can release them under a copyleft license like AGPL, or a permissive license like Apache, or even keep them closed-source.
Methods Matter
I’ll be interested to see any news or outcomes from the Kuali Days conference, and these two announcements should affect the license discussions at the conference. What I have found interesting is that in most of my conversations with Kuali community people ,even for those who are disillusioned, they seem to think the KualiCo creation makes some sense. The real frustration and pushback has been on how decisions are made, how decisions have been communicated, and how the AGPL license choice will affect the community.
It’s too early to tell if the Ariah Group will have any significant impact on the Kuali community or not, but the issue of license types should have a growing importance in educational technology discussions moving forward.
At Ariah our members will set the priorities as it was and as it should be in any truly open source environment.
(The hazards of commenting while traveling: premature submit)
“At Ariah our members will set the priorities as it was and as it should be in any truly open source environment.”
This begs the question of what it takes to become a member. Kuali and other (previous) “Community Source” projects have an established history of using “The Golden Rule” where, those [members] who bring the gold make the rules. If this pay to participate approach continues, I would argue that this is not a “truly open source environment.”
Has there been any information provided to help understand membership and member roles by any other the parties?
I would suggest communities based on meritocracies are best for open source environments.
Patrick – I don’t believe there is an answer yet on membership and member roles. It’s not clear if the group itself has not answered the question internally or just does not want to share that information yet.
Isn’t it also important to document how the schools who are making the licensing decisions about Kuali are funding their contributions? Did the money come from the taxpayer or was it raised under the pretense that the money would be used to fund a non-profit enterprise? If it was than the decision to give an exclusive monopoly over parts of the code base to a private for-profit will seem problematic to some and outrageous form of enclosure to others. Maybe none of the above is happening. But to put the public at ease those concerns should be clearly and directly addressed.
Luke – you make a good point. I have done some research on Kuali total budgets & financials but not tracing origins of $$ and conditions of that funding. Not to erase your concerns, but it should be noted that the current plan as I understand it is for schools to sign MoUs with Kuali Foundation who would contract with KualiCo, for the purposes of software projects. I believe schools that use KualiCo for hosting would handle that transaction directly, with Kuali Foundation giving a discount on cash contributions but not acting as intermediary.
Phil, I don’t think the quoted characterizations of the AGPL are strictly correct. To step back, viral licenses such as GPL and AGPL intend to preserve user freedom by enforcing licensees to “pay it forward” as it were, and in that way are generally regarded as antagonistic to closed, walled, proprietary forks. It is the permissive/BSD style licenses such as Apache that make a different tradeoff, encouraging commercial participation by allowing proprietary derivatives (and generally more relaxed licensing environment). It makes sense that the foundation would have chosen Apache, as many do, to foster a commercial support environment.
Now AGPL appears to be characterized as a play to turn the software proprietary, and limit competitors. I think it can be seen as the opposite: it ensures any commercial affiliate *cannot* create a walled proprietary service. It then would follow that it would be hypocritical for KualiCo to do so, and I would agree if this is what they are going to do, because that could only be predicated on the source handout by the Kuali Foundation. I think the crucial point here is that one-way contributions to AGPL codebase can *only* work for KualiCo if they enforce copyright assignment. This is how they can “proprietarize” the service – assuming they have comprehensive copyright, they can use their software as they wish (independent of AGPL requirements). So the community already has a way to deal with this – don’t assign copyright and simply license any contributions as AGPL. The question is who will have the developer/contribution momentum – if it’s the “community” then KualiCo one-way AGPL proprietary service will die off from lack of contribution. If it’s KualiCo…well, then I suppose they are going to reap the reward of their developer investment at the expense of diverging codebase.
In response to Aaron’s comments,
“Now AGPL appears to be characterized as a play to turn the software proprietary, and limit competitors.” I agree that the focus is on AGPL, when discussions are more relevant to “ope core” (http://en.wikipedia.org/wiki/Open_core). As OSI president Simon Phipps would warn KualiCo and those looking to adopt it, “Open Core Is Bad For You” (http://www.computerworlduk.com/blogs/simon-says/open-core-is-bad-for-you-3569652/).
“the community already has a way to deal with this – don’t assign copyright and simply license any contributions as AGPL.” This would require KualiCo to change the Contributor License Agreement that the Kuali Foundation currently requires: http://www.kuali.org/licensing
Aaron, I’m not sure where we disagree or where the characterizations are not strictly correct. FWIW, KualiCo is planning to protect its multi-tenant cloud hosting software (to be developed) as proprietary source, which is the asymmetry I describe. See https://eliterate.us/kuali-foundation-clarification-non-open-source/.
The comment on limiting competition refers to the Asymmetric AGPL usage – see Severance blog or even see Copyleft.org section 11.2 (bottom of section): http://copyleft.org/guide/comprehensive-gpl-guidech12.html#x15-10200011
I believe the “answer” to the question about membership costs for Ariah is still under discussion. The Ariah Group has been talking with commercial partners about their thoughts on this and we’ve encouraged a drastic shift to the Kuali way of doing things and they seem very receptive to it. We’re in favor of contributions being tied to real measurable deliverables, This appears to align with their goal of being more product oriented rather than basing membership on projects that flounder. Basically it looks like they want member institutions to decide what they want, share what they’re willing to contribute (dollars and/or resources) and to set a schedule to get it done, the more resources and dollars the quicker the delivery. They also say they want to eliminate the multiple layers of bureaucracy that caused deliverables to languish. I gotta say, we’re REALLY excited about being a part of an effort that lives up to what Kuali originally was supposed to be all about, delivering great products for higher education at reasonable prices collaboratively.
As the author of the GNU General Public License and the GNU Affero General Public License, and the inventor of copyleft, I would like to clear up a possible misunderstanding that could come from the following sentence:
> Any school or Kuali vendor, however, that develops its own
> multi-tenant cloud-hosting code would have to relicense and share
> this code publicly as open source.
First of all, thinking about “open source” will give you the wrong idea about the reasons why the GNU AGPL and the GNU GPL work as they do. To see the logic, you should think of them as free software licenses; more specifically, as free software licenses with copyleft.
The idea of free software is that users of software deserve freedom. A nonfree program takes freedom away from its users, so if you want to be free, you need to avoid it. The aim of our copyleft licenses is to make sure all users of our code get freedom, and encourage release of improvements as free software. (Nonfree improvements may as well be discouraged since we’d need to avoid them anyway.) See http://gnu.org/philosophy/free-software-even-more-important.html.
I don’t use the term “open source”, since it rejects these ethical ideas. (http://gnu.org/philosophy/open-source-misses-the-point.html.) Thus I would say that the AGPL requires servers running modified versions of the code to make the source for the running version
available, under the AGPL, to their users.
The license of the modifications themselves is a different question, though related. The author of the modifications could release the modifications under the AGPL itself, or under any AGPL-compatible free software license. This includes free licenses which are pushovers, such as the Apache 2.0 license, the X11 license, and the modified BSD license (but not the original BSD license — see
http://gnu.org/licenses/license-list.html).
Once the modifications are released, Kuali will be able to get them and use them under whatever license they carry. If it is a pushover license, Kuali will be able to incorporate those modifications even into proprietary software. (That’s what makes them pushover licenses.)
However, if the modifications carry the AGPL, and Kuali incorporates them into a version of its software, Kuali will be bound by the AGPL. If it distributes that version, it will be required to do so under the AGPL. If it installs that version on a server, it will be required by the AGPL to make the whole of the source code for that version available to the users of that server.
To avoid these requirements, Kuali would have to limit itself to Kuali’s own code, others’ code released under pushover licenses, plus code for which it gets special permission. Thus, Kuali will not have as much of a special position as some might think.
See also http://gnu.org/philosophy/assigning-copyright.html
and http://gnu.org/philosophy/selling-exceptions.html.
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
MacArthur Fellow
Dr. Stallman,
I believe Kuali has stated that they do not plan to release their Multi-tenant changes as open source, that this functionality will be withheld from the community. If this is true are they “breaking the rules” of open source as you’ve explained them? I assume there must be a way to comply, some of us just don’t understand how and they didn’t provide any insights into this last week which was something many of us attended to understand.
Richard – thanks for commenting. There is one key clarification that would help in this case. It’s a given that KualiCo is planning to deliver the original code as AGPL alongside / integrated w/ proprietary multi-tenant cloud-hosting code on server, and I assume that the two code bases are not fully separable. Let’s say that a user modifies the AGPL code – whether to develop their own cloud-hosting framework or some other functionality – and KualiCo incorporates all or portion of that modified code alongside their own multi-tenant code.
Q1. If this modified code carries AGPL license, does this require that the multi-tenant code from KualiCo be made available?
Q2. If the modified code carries a pushover license such as Apache 2.0, would the answer be different?
The missing piece here is the contributor license, as Patrick notes (which I take it is one possibility for what Richard refers to as “special permission”). These are legal agreements in open source projects that are designed to manage potential conflicts arising from multiple copyright holders and multiple licenses. The current Kuali contributor license has contributors giving copyright to their code over to the foundation. From there, the foundation can do whatever they like with it.
So, in answer to Phil’s questions:
A contribution with an AGPL license without a Kuali contributor license would indeed require KualiCo to make their multitenancy code available if they used the contribution. Which is why KualiCo will almost certainly reject outside contributions under GPL or AGPL unless they come with contributor license agreements.
A contribution with an AGPL license but with a Kuali contributor license would not require KualiCo to distribute their multitenancy code, assuming that the foundation granted the copyright or permission to KualiCo (which it almost certainly will do).
A contribution with a non-copyleft license like Apache 2.0 would not require KualiCo to distribute their multitenancy code.
Richard is right that contributors have some control over how their code would be reused by KualiCo. For example, a competing hosting company could comply with the AGPL distribution requirement by releasing their own code under AGPL but not signing a contributor licensing agreement. In that case, KualiCo would almost certainly reject the contribution in order to protect their proprietary code. The net practical effect would be a fork. But in this particular case, it seems unlikely that there are sufficient incentives and resources for a non-KualiCo AGPL fork to survive. Stranger things have happened, of course. But I wouldn’t bet money on it happening this time.
Quick clarification on the “Left or kicked out” question. I was on a conference call with Brad Wheeler the day before the infamous Jennifer Foutty email announcing we were terminated as KCAs. Brad very much wanted us to remain within the fold but my position was that I wasn’t comfortable with how this was all handled leading up to the August 22nd announcement and we could not in good conscience continue to be a part of the organization and withdrew our support.
This decision was a risky one but the right one based on our principles and has been further supported by learning that the impetus for this new direction came from a proposal provided to the Foundation by rSmart back in January. We’ve also heard that a company (Kuali LLC) was formed in the state of Utah in March which although not proven seems awfully coincidental since KualiCo is headquartered in Utah. It’s puts the belief that this was a “community” decision and the end result was not a forgone conclusion into the category of, as Brad Wheeler put it at Kuali Days, “brutal truths that must be confronted” when evaluating the credibility of the Kuali Foundation and by extension KualiCo. We wish them both great success since it’s in the best interest of higher ed that they overcome these hurdles and for our part we’re going to continue our mission of providing support for the community in any way we can withold abandoning our principles.