© 2005 Paul B. Gandel and Brad Wheeler
EDUCAUSE Review, vol. 40, no. 1 (January/February 2005): 10–11.
The notion of collaborating to create open source applications for higher education is rapidly gaining momentum. From course management systems to ERP financial systems, higher education institutions are working together to explore whether they can in fact build a better mousetrap. As Lois Brooks, of Stanford University, recently observed, the open source movement is as much about building communities as it is about developing and sharing applications.1 The idea of open source communities even extends into the realm of content, with the development of the MIT OpenCourseWare (OCW) Initiative (http://www.ocw.mit.edu) and the promotion of shared institutional digital repositories.
As higher education creates open source communities for shared resources, it’s important to know what kind of community we are creating and some of the principles underlying that community. Fundamental differences in approaches, philosophies, and incentives for various stakeholders exist. Perhaps nowhere is this more apparent than in the legal area of licensing.
Licensing in the open source world is not about giving up ownership of software or content. In almost all cases, the authors or communities maintain copyright of their work. However, through licensing, open source authors and communities can allow others to use the software or content more freely than would generally be allowed under copyright law. Broadly speaking, there are two approaches for open source licenses: (1) the General Public Licenses (GPLs), known as the "copyleft" approach, and (2) a set of approaches that together are sometimes referred to as "open/open."
Copyleft has its origins in the free software movement (http://www.fsf.org/licenses/licenses.html#WhatIsCopyleft). "Free" in this case doesn’t refer to the cost of a work (which could be free) but to the freedoms that are given to users. Copyleft is designed to provide four basic freedoms: the right to use the software; the right to have access to the source code; the right to create derivative works by changing the code; and the right to distribute the source code to others. However, copyleft has a key restriction as well: it forces derivative works to pass on these same rights to other users. Copyleft is designed to make sure that the four basic freedoms remain forever inseparable from the software.
Open/open licenses generally give users the same rights: freedom to use the software, access the source code, create derivative works, and distribute the source code. The key difference is that the creators of derivative works can choose any license they want for their software. New modules or improvements to the original code may be licensed under the same or a different license—including one that makes the work proprietary. Proponents of the open/open approach believe that for a work to be truly open, it should not restrict someone’s freedom to create a subsequent proprietary work derived from the open code.
This notion of "free" versus "open" has created within the open source community a debate that sometimes seems to resemble the feud between the Hatfields and McCoys. Although there are numerous subtleties to the argument, it centers on several questions: What is the definition of freedom? Whose freedom is more important? How do licensing choices affect community engagement? This disagreement is reminiscent of the conflicts between social activists and those who favor a more laissez-faire approach—or, as our colleague Richard Katz characterized it, the Birkenstocks versus the wingtips.
For the advocates of the copyleft/GPL license approach, "open" can be open only if the work always remains open. If the work is later modified into a proprietary derivative work, this essentially restricts the freedom or openness of the original work by possibly allowing a wall of proprietary work to surround the original work. Underlying this thought is the philosophy that in order to build a community, the notion of sharing must be guaranteed through the specific licensing arrangements.
The proponents of the open/open model often characterize copyleft as "viral," since works derived from a copyleft work must also be copyleft. They feel that copyleft therefore restricts the freedom of software developers to build on the work and to use it for whatever purposes the developers deem appropriate—including creating proprietary versions or modules. Open/open proponents argue that only by giving users total freedom to create derivations of the code as they see fit can the vendor industry be motivated to invest in the open source community for educational application software. From their perspective, if you take away the ability of the vendor to create derivative proprietary products, you remove a vendor’s ability to create unique value propositions in the marketplace and thus the incentive to participate. Open/open advocates see this approach as a middle ground between copyleft and closed proprietary licenses. In their view, this middle ground invites a broader community, including the commercial sector.
Ultimately, the debate comes down to what kind of community is desired and the best way to achieve that community. Open/open advocates maintain that community norms themselves will govern the way a community operates. They point to the five-year success of open/open licensing in uPortal (
For copyleft advocates, the issue boils down to trust. Trust needs to be guaranteed by legal license rather than by wishful market behavior. They argue that if the goal is to build an open community where works and derivations of those works remain free and open to the entire community, why not build that within the license approach up front? It is not enough to be open—works must always remain open. And the only way to ensure that works remain open is by incorporating a governing principle within the license that says, "Take only if you are willing to give."
The Berkeley UNIX system is often cited by copyleft proponents as what happens without a strong copyleft license. Originally released under an open/open type of license (a BSD license), soon this evolved into multiple and competing versions—some remaining open and some becoming closed proprietary systems. Linux, released under the GPL/copyleft type of license, is pointed to as the prime example of how a strong copyleft license can ensure that the work and the community supporting that work do not become fractured. Therefore, a key advantage of a copyleft license is that it forces all subsequent changes, releases, and derivations to be made available under the same terms and conditions—basically under the same license.
Open/open, though having the advantage of being less restrictive, also runs the risk that various versions will be released under different licenses. The proliferation of distinct organization-based or project-based licenses is a threat for community sharing of software. The reuse and sharing of code is an essential part of the value of open source projects, and multiple licenses with only minor differences are a real barrier to integrating software modules for further development. Invaluable time is spent interpreting various licensing arrangements rather than building sustainable open source communities of practice.
There are no easy answers to the question of which licensing approach serves higher education better, but the stakes in resolving this debate are high. As the higher education community continues to embrace open source—for software and other forms of electronic content—licensing choices will be the critical ingredient that will shape participation in and the trajectories of our communities. The two approaches begin with very different assumptions about the nature of the marketplace, organizations, relevant incentives, and ultimately, people. Those of us in the higher education community could improve our future now by collectively rallying around a single, common licensing approach. If that is infeasible, we certainly should choose one copyleft license and one open/open license and develop our shared software and our open source communities around these choices.
1. Lois Brooks, "Values of Community Source Development," Syllabus, September 2004.