We outline the reasons for distributing the initial release of the software under the conditions of the (new) BSD license. The component-based design of the software may lead us to license other packages and/or subsequent versions of the software under other licenses.
The inter-system interface modules - specifically the interfaces for § and with both and CORBA will be released under the GPL. The reasoning behind this is that we want to ensure a consistency between the interfaces for the different target languages (§ and ) and avoid allowing proprietary changes. (A special license will be provided to the author's of XGobi to distribute the code with their application but with that part of the code still under GPL.) The GPL for these modules applies to the (and header files), § and and code used to implement all of these.
These inter-system interfaces are made up of three different levels of code.
The IDL code is to be licensed under the BSD terms. Implementations of the IDL code in both and will be licensed under the BSD also.
All of the configuration files (including those in the inter-system interfaces), etc. will be provided under the BSD license.
Documentation licenses?
We have spent a great deal of calendar time considering the most appropriate license for the omegahat project. There are many constraints for which we are trying to find a solution that keeps most of us (the developers), potential users and contributors and potential commercial interests. The members of the omega-core group all embrace the open-source ideology both from a practical perspective for developing high-quality code, and also from a social perspective. We do not wish to create another license, but instead adopt one of the existing ``open source'' licenses. Most of these are focussed on classical code and application distribution - e.g. compiled languages such as C/Fortran, libraries, etc. By the nature of Java - a virtual machine with portable byte-code, and reflectance - there is no need for static/compiled linking of classes. Many of the licenses do not really protect against abuse of the open-source concept and will be difficult to enforce in the era of dynamically executable code (i.e. dynamic compilation of classes, dynamic network downloads of portable code and dynamic method invocation via CORBA).
The initial code release was initially intended to illustrate how one might use Java to develop an interactive, object-based environment similar to §, and . While it has become more complete than originally intended, it is far from a complete system. The framework or skeleton we believe is reasonably close to what we may end up with. However, the details of some of the method bodies are still incomplete. Because of this, we are happy if others can use this code in different ways: ideally by extending the interfaces and then classes and sometimes by modifying the existing code or adding new ones. We hope that people will take the time to try to work within this framework, identifying the weaknesses and identifying them to us so that we can change them for all to benefit. Consistency between modules in the core data structures and services is vital and worth the slightly extra effort needed rather than changing existing interfaces and classes directly.
We are strongly encouraging others to participate in this project by experimenting with the code and providing enhancements, additions, new modules, etc. We feel that the best way to do this is to provide a non-invasive license. Perhaps this will change when we come closer to a more complete environment.
The rationale for distributing the inter-system interfaces under the GPL is that they are intrinsically different from the other modules. We are trying to encourage people to develop based on this in a cross-language and cross-application manner rather than on the code itself. For this, we need to promote consistency between the interfaces from the different systems. For this reason, we want to encourage sharing of improvements within this more specialized and focussed domain.
In short, the constraints we face are that we would like to:
We do not want to
Most of all we want to encourage people to contribute. The community of statistical software developers is small and we need to cooperate so as to be able to effectively deal with the changing nature and challenges of statistical computing. Whether enhancements are returned to the core packages or distributed separately should not be forced upon the developer. For this reason, applying a GPL to the current code may discourage development.
We want to make such contributions as easy as possible without complicating the distribution. One aspect of this is that the contributor of a modification will own the copyright to that change. Accordingly, we cannot distribute or license it differently to other groups, e.g. a commercial interest without all the contributors approval/permission. Alternatively, we can attempt to acquire copyright ownership as contributions are submitted. This means that contributors must obtain a release from any institution in which they are working and also sets an overly formal tone to the development. This is far from encouraging contributions.
We also want to make our works as accessible to others as possible. Given the nature of the potential user-base and the designed flexibility of the software, a commercial entity providing support seems essential. However, it is value-added that we want to encourage from such entities. We do not want people modifying the core or base facilities so that their value added requires a proprietary version of the core. An example of what we are trying to encourage would be the facility to purchase a different module or user interface (e.g. time series module or Web reporting front end). We do not want to encourage these to be sold with the requirement of an expensive license for the core facilities on which these rest.
While the existing licenses do not address the specific issues associated with and portable, dynamic code and method invocation, the nature of the software offers some assistance to our efforts to determine an appropriate license. The system consists of components that can be glued together to provide different functionality within different user interfaces and environments.
It is possible to license each of the modules or significant components under different licenses. From our perspective, this would be somewhat more complicated but provide the resolution we need to differentiate different components and developer interests. Distribution on CD would be complex and it places the burden on the distributor and user to know which license applies to which modules and uses of those modules. However, it does provide developers with a mechanism to provide an enhancement without contributing it to the source tree and being subject to the license we use. We are very willing to provide facilities for distributing 3rd party contributions released with a different license than ours. Of course, such enhancements may be uni-directional. We may not be able to provide works derived from them within the core. As such, they will force us to have 3rd party code.
All of us (the developers) keenly support the open source ideology and the GNU principles. However, I speak entirely for myself when I suggest that there is a gross contradiction in the GPL. It emphasizes the rights it gives one in contrast to other languages, but simultaneously removes your rights to distribute code that you develop that uses other GPL code. This is of course a fair request, but it is coercive. I would prefer to have the same end result, but to have people recognize that open source development is better rather than force them to adopt it. The ``set a butterfly free, and it it returns...'' idea comes to mind - it is better to have people that are committed to the philosophy rather than those who begrudgingly accept it. Whether it is better to have software under these circumstances than no software at all is another matter.
Since the BSD licenses was changed in June '99 to rescind the clause obligating advertisements to acknowledge the copyright holders, the X license no longer is preferable to BSD. Indeed, the BSD license additionally prohibits people using the names of the copyright holders in endorsements of their derived products. So the BSD seems preferable to X.
Interestingly some of these have a GPL with an exception that offers no restrictions if the code is unmodified.
The QPL license requires modifications to be distributed as visibly separate elements, such as patches. The focus seems more on protection for the authors than on defining privileges for the users.
Numerous valuable pieces of information have been obtained from reading chapters of Open Sources: Voices from the Open Source Revolution edited by Chris DiBona, Sam Ockman &Mark Stone.