Well that was an interesting session at Educause as described at Inside Higher Ed:
It took the Kuali leadership 20 minutes to address the elephant in the conference center meeting room.
“Change is ugly, and change is difficult, and the only difference here is you’re going to see all the ugliness as we go through the change because we’re completely transparent,” said John F. (Barry) Walsh, a strategic adviser for the Kuali Foundation. “We’re not going to hide any difficulty that we run into. That’s the way we operate. It’s definitely a rich environment for people who want to chuck hand grenades. Hey, have a shot — we’re wide open.” [snip]
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.
While the article describes the communication and pushback issues with Kuali’s creation of a for-profit entity quite well (go read the whole article), I think it’s worth digging into what Carl generously describes as a “back-and-forth”. What happened was that there was a slide describing the relicensing of Kuali code as AGPL, and the last bullet caught my attention:
- AGPL > GPL & ECL for SaaS
- Full versions always downloadable by customers
- Only feature “held back” is multi-tenant framework
If you need a read on the change of open source licenses and why this issue is leading to some of the pushback, go read Chuck Severance’s blog post.
Does ‘held back’ mean that the multi-tenant framework to enable cloud hosting partially existed but is not moving to AGPL, or does it mean that the framework would be AGPL but not downloadable by customers, or does it mean that the framework is not open course? That was the basis of my question.
Several Kuali Foundation representatives attempted to indirectly answer the question without addressing the license.
“I’ll be very blunt here,” Walsh said. “It’s a commercial protection — that’s all it is.”
The back-and-forth involved trying to get a clear answer, and the answer is that the multi-tenant framework to be developed / owned by KualiCo will not be open source – it will be proprietary code. I asked Joel Dehlin for additional context after the session, and he explained that all Kuali functionality will be open source, but the infrastructure to allow cloud hosting is not open source.
This is a significant clarification on the future model. While Kuali has always supported an ecosystem with commercial partners that can offer proprietary code, this is the first time that Kuali itself will offer proprietary, non open source code.1
What is not clear is whether any of the “multi-tenant framework” already exists and will be converted to a proprietary license or if all of this code will be created by KualiCo from the ground up. If anyone knows the answer, let me know in the comments.
From IHE:
“Unfortunately some of what we’re hearing is out of a misunderstanding or miscommunication on our part,” said Eric Denna, vice president of IT and chief information officer at the University of Maryland at College Park. “Brad [Wheeler, chair of the foundation’s board of directors,] and I routinely are on the phone saying, ‘You know, we have day jobs.’ We weren’t hired to be communications officers.”
Suggestion: Simple answers such as “What ‘held back’ means is that the framework will be owned by KualiCo and not open source and therefore not downloadable” would avoid some of the perceived need for communication officers.
- Kuali Foundation is partial owner and investor in KualiCo. [↩]
One point of inclarity to me is how one architects a system so that the single-tenant free version cannot easily be converted by an industrious programmer back into a multi-tenant system. It seems possible to build in these impediments since AFAIK no one who is using the free version of Instructure’s Canvas has succeeded, much less attempted, in adding the multi-tenant capabilities back into the free version. But the fact that no one has done this because the architecture makes it really difficult to accomplish? Or because there’s other (non-technological) disincentives? I ask because we’re developing our own multi-tenant testing software (chitester.weber.edu). While we could easily distribute a single tenant free version, the multi-tenant aspects are so heavily embedded in the architecture that it wouldn’t be difficult for a savvy programmer to add the multi-tenant functionality back in. Will Kuali’s free version be truly difficult to convert back into a multi-tenant system? Or is the disincentive to do so based on something other than the technology?
Luke – good question on architecture but I haven’t done the research. Maybe others can answer.
What I can answer is that Kuali’s primary disincentive for others to add multi-tenant is the AGPL license. They made that change to actively discourage others from developing multi-tenant, so that KualiCo would be *the* hosting company at least for cloud. The argument is that if another group adds multi-tenant, they have to share the resultant code which would make it difficult for anyone else to charge for cloud hosting. Could an old-fashioned school or group of schools do the work and not care about sharing their code? That I could see happen – not sure if that option would be discouraged.