Open source license proliferation, a broader view
The desire of OSI to curb "license proliferation" by changing its policies and the effort of FSF to draft a new version of GPL should cause many to pause. Why are these changes being considered? Is it finally time to understand FSOS on terms other than the communities own, self-defined terms given that those terms may change over time? Is it time to recognize 'Free Software" and "Open Software" (FSOS) as inherently a heterogeneous phenomenon that is part of a continuum of software licensing styles, rather than entirely separate and apart from other means of software distribution? I think so.
Why does license proliferation occur and is it bad?
I think that it is actually inevitable and a manifestation of the maturation of the FSOS movement. It is an assertion of productive and healthy individualism and, arguably, reflects an expansion of the core ideas of open source outside the narrow confines of its own limiting doctrines. Except in a closely regulated world that would be inconsistent with the politics of many involved in open source, individualization of approaches around or related to core principles is an inevitable process.
But some do not agree. Among those who disagree, there are different explanations for why proliferation is bad. OSI might prefer to curb "license proliferation" at least in part because the expanding number of licenses creates a disincentive for others to use open source (creating a daunting morass of options) and a sense of anarchy; this builds a feeling of unease that inhibits broader acceptance of the movement.
Certainly, license proliferation is a nuisance, but more to the point, one effect is that the proliferating licenses create incompatibilities - the inability of one user to concurrently comply with the terms of two separate licenses. Larry Rosen, former General Counsel of OSI comments succinctly: "As a license musician, I'm not bothered as much by "too many notes" as I am by the fact that the notes aren't always in the same key. License proliferation has become an important problem because software under those different licenses cannot always be played consistently and compatibly everywhere. Perhaps ... we should throw out the off-key notes?"
But, of course, these incompatibilities are the result of choices made by licensors that one set of license restrictions are inappropriate for their work, while another set are appropriate.
OSI may attempt to curb proliferation through control of OSI certification standards; narrowing qualification criteria is certainly one accepted purpose of managing a certification mark. But in a community or a philosophy defined by its licenses, changes of this sort effect change in the philosophy itself.
The point of discussion here, however, is not that FSOS members or groups should (or should not) adopt a different definition or that their current self-description is wrong. Everyone and all groups are free to describe themselves however they like. The point is that others are also free to reject the description and to search for a more useful way of describing and understanding the software community. The terms of a group's self-description may not be the best way of understanding the group's role in the broader context of the software industry.
The FSOS movement today is self-defined. "It is" what it says "it" is. Actually, it is defined by its leaders in their response to various licenses. The Free Software Foundation (FSF), for example, describes various licenses as "free" or not "free", "open" or not open, based on standards its leaders accept. Why should non-members care into which category a license falls? What is the relevance of OSI certification?
There are many answers to these questions. But none involves a conclusion that being within the definition makes one inherently different in all respects from other products, licenses, or persons in the overall software or technology communities, except for the label itself. Indeed, it is not necessary to search far to find products and licenses that are not approved or certified by FSOS groups, but that incorporate terms corresponding to many or most of the "principles." What is the position of a person who releases source code under a license allowing modification and redistribution, but limiting uses to non-commercial or educational uses? This is neither a free, nor an open source license by the definition of those groups, but except for the field of use limitation, the license and marketing may correspond to all of the fundamental principles of advocated by the community.
Self-defined philosophies are common. Indeed, joining a group is inherently an act of self-definition for the new member. Self-definition in open source reflects the FSOS movement's philosophical, some might say quasi-religious, core; it corresponds to the ordinary desire of groups to create a self identity by allowing members to say "we are we" and "they are the others."
But what occurs when a person adheres to the core philosophy, but not to every detail of the doctrine? From the perspective of the group itself, they can accept the deviation or exclude that member - "perfect adherence to perfect doctrine is a required step in continued membership." While attractive to some extremists, a platonic view of doctrine that excludes all non-conformities is seldom followed in large organizations, even religious organizations. While Catholic doctrine rejects birth control and abortion, for example, many of its members support both. The church is free to reject or terminate membership of those people, but such a use of official doctrine does not often happen. A de facto coexistence exists because there is acceptance of more basic principles.
Given this, what should be the approach of a person who wants to ask broader questions than members of a self-defined group? The answer depends on what question is asked. If the issue is "how do Christians as an overall group view birth control", the proper approach is not to question Catholics only. Instead of asking what is the effect of FSOS and which licenses are part of it, consider asking "what role does, or should, the idea of releasing code and allowing modifications and distribution of a product play in the software community?" Asked in this way, one would not draw a line at the boundaries of approved FSOS licenses. Rather, the line would be drawn based on more fundamental or at least different premises. For example: what are the various ways in which modern practices reflect the idea that releasing source code and allowing changes and redistribution of it is one way of developing software?
This change in focus is not an academic exercise. Let's assume that making source code available with the right to modify it is a good way of improving software. Accepting this assumption, how should one promote that goal? Is it best promoted by the exclusionary doctrines of FSF and OSI? Is it better promoted by less exclusionary methods and more acceptance of choices voluntarily made by others that promote the goal but not every doctrinal detail? A colleague of mine, Greg Vetter, has argued and many others believe that the viral or reciprocal provisions of many FSOS licenses (including especially the GPL) discourage or impede adoption of some of the basic themes of the movement, rather than helping achieve them. There is at least enough evidence of that to ask the question of whether a different model might be better to achieving the goals of the movement itself.
In fact, there are many models other than the "approved-disapproved" self-definition of membership or compliance. One illustration is in the Creative Commons project. That project has a goal of encouraging more creative material to be made available under terms that assert less exclusionary rights as to the content. The project approaches that goal by setting out a platter of licensing options attaining differing levels of balance between openness and control. This platter of options, then, serves as a framework that can be used by authors who desire to achieve a degree of openness; but those authors might not otherwise understand how to use a licensing model to achieve their personal goals. The model has been described in terms of "some rights reserved" as a counterpoint to the frequently seen "all rights reserved" label. The options, however, range from complete dedication of a work to the public domain (a step not treated by the FSF as qualifying as "free" software) to some relatively restrictive licenses (e.g., precluding commercial use).
One difference between other membership groups and FSOS groups is that people do not become members of FSOS, but licenses do. That is, the same person or company might distribute some software under a license approved by FSF, while distributing other content or code under completely non-compliant licenses. This means, ultimately, that software authors make a choice in adopting or not adopting FSOS for their works and must make that choice anew with each distribution they make, as to that distribution. Today, it is quite common to see the same software released under an FSOS license, and under a different license that does not meet FSOS criteria.
The companies include Apple, Sun Microsystems, IBM, and others. More recently, Microsoft announced a package of license alternatives under a "shared source" program, which, like the Creative Commons approach, includes different levels of restriction and of openness.
The temptation might be to evaluate these initiatives solely in terms of whether they conform to FSOS doctrine. But in a broader perspective, the deployment of these licensing approaches is important even if they are not granted strict doctrinal approval. No law requires compliance with FSF or OSI doctrine in order to be part of a broadening sense of options re how software can and should be distributed.
But we can get to that realization only by recognizing FSF and OSI as part of a broader theme. In that broader context, other options and approaches are important and valuable, even if they do not fully conform to strict FSOS doctrine. It is in that broader context that the "movement" and the "community" need to be understood.
Indeed, there are many in the community who understand and advocate this broader approach. Russell Nelson, a leader of the open source and OSI certification process, in announcing OSI rejection of a newly proposed license (the OVPL), commented: "It is unfortunate that some licenses which almost exactly comply with the open source definition will not gain our approval. There must be a line somewhere, and after careful and thoughtful review we find that clause 5 of the OSD requires that we draw that line between the OVPL and OSI certification. We encourage everyone to release as much of their source code under whatever terms they are comfortable. They could call it Shared Source as Microsoft does. We encourage the use of the term "Source Available" software since the source is available but not open for all uses."
I completely agree with this broader perspective, regardless of labels used.
Your article highlights the myopia of the people who are active in the open source "movement."
My belief is that most people who develop "free" software on a non-commercial basis want to see their work used as widely as possible. Similarly, the users want to be free to use the work without restrictions. The people who spend their days worrying about whether or not some particular license formulation falls within some hotly debated "definition" is irrelevant at best, and at worst interfere with the basic goals of both groups.
Unfortunately, however, I don't believe the solution is to encourage everyone to develop his or her own customized license.
I recently was asked to do a survey for a major company of the software being used by its in house develop team, some of which consisted of development tools used internally while others were modules intended for inclusion in applications being developed for their own internal use and/or distribution to third parties. The number of different licenses was daunting and the results confusing. Some programs were only suitable for internal use without modification. Others could be modified but not distributed (at least not without practically forfeiting all IP rights in the product). Others could be distributed but not modified. Some required source code be provided when distributed, others did not. Some gave you a choice: distribute derivative works on an open source basis or pay a substantial fee for a waiver of that requirement. The list goes on.
In a few cases, there were no licenses at all to be found for in the product or on the web site from which it was obtained. When I was able to contact the author, he either picked one on the spot or let it be known that he didn't really care.
I have also found from my practice that there is a deep seated fear of "viral effect" among in house legal departments , even where they are buying software strictly for internal use.
1. A simple, non-restrictive license on the BSD model would suffice for most software developers who are not interested in commercial exploitation of their products and would greatly encourage the use of open source products by major corporate users. Experience has shown that the lack of a viral effect has not deprived many open source products, such as Apache, of any of the perceived advantages of open source development.
2. Faced with such truly free competition, commercial developers will be forced to offer less restrictive license terms in order to compete. As your article points out, this is already happening.
Why is the purity of development always hindered by greed. We all can agree no matter what "off-the-shelf" product you have customization is needed, deployment within an enterprise demands this. Companies show success because individuality, taking basic tools and applying creativity. It becomes hard too address this when "easy money" crawls in.
Open source brings more ideas to the table, great discoveries are achieved with "free-sharing". Greed always colors the water.
George misses the mark. If the programmers who are now active in working on open source projects were suddenly in the position that Microsoft (or Apple, or whoever) could make money by selling THEIR hard work, open source development would screech to a halt.
The open source movement has produced -- and will continue to produce -- incredible software that is open to EVERYONE. Why would you want to put a stop to that? Where is the benefit, other than to large commerical developers?
Good site, good blog, thank
Good site, good blog, thank
Excellent site, added to favorites!!