Your location: Home arrow News arrow Latest arrow Open and Free, a discussion about freedom
Open and Free, a discussion about freedom Print E-mail
User Rating: / 13
Written by Steve Graham   
Wednesday, 05 April 2006

We have been arguing the merits of the concepts "open" and "free" for a while now within this team's discussions regarding licensing, and have come to a point where we need to make decisions regarding some of our commercial and "free" scripts.

We are strong proponents of the GNU licensing models, both general and lesser. In each of these instances a user has the option to make any appropriate modifications to a script for their own internal use, and to distribute those changes under like licensing. This gives to each of us the option of customizing those scripts in a way that brings maximum benefit for our own usage, and if applicable to others, the option to redistribute that software/application/script to others who could also benefit from our modifications.

This is an ideal model, and one that has led to tremendous development efforts being brought to bear for many of the larger open source initiatives that we all love and use.

But as is usually true with any definition of "free" and "open", these GNU models also have drawbacks that need to be addressed. While allowing maximum freedom to an end user, they do represent some compromise for contributors who wish to make commercially available products that use/employ/or run under products that adhere to these licensing models. Consider the following:


  • End users can modify, source is open and available, and users can redistribute.
  • Redistributing must be under same license, so others can do same
  • Requires that any software/application/script that utilizes any portion of the codebase also be of same or similar license.


  • End users can modify, source is open and available, and others can redistribute.
  • Redistribution must be under same license, so others can do the same
  • Can be included in distributions of other products, without affecting thier licensing, although the product licensed under LGPL cannot change license type.
  • Here is the problem for BOTH commercial software developers and users who employ GNU/GPL products: The two cannot be mixed without impacting the commercial developers licensing. If the user does the mixing, it largely goes unnoticed and does not effect licensing, but if a commercial developer tries to do the same, he/she imperils their own licensing models.

    There are a tremendous number of commercial developers who would participate in open source projects if they could do so without imperiling their licensing for their own products. Witness Joomla, and open source initiative that has openly declared that third party developers can create scripts that run under Joomla without having to be GNU/GPL as Joomla is (This actually started with Joomla's predecessor Mambo).

    As a result of this public policy, the Joomla community of both users and products has grown tremendously, and now enjoys the status of being one of the worlds largest open source initiatives in their class. Many of these third party developers see the success of Joomla as being inherently intertwined with their own success, and valuable contributions to the "free" and "open" codebase. Their inclusion has led to a better product, and their expertise and technical skills have benefitted all users of this community, not just the users of their own commercial products.

    Unfortunately, too many third party developers have no knowledge of this public policy, and subsequently make no efforts to participate. They simply stop when they see the GNU/GPL license. This ends up impeding the progress of this community and the resultant utilization of the Joomla application. Still one of the best out there, they could be much better (from a users perspective of total utilization, not a comment on the quality of the core Joomla application).

    The alternative for an open source free product is to release the application or product under the LGPL, a license really intended for libraries. As such, it allows for the product or application to be included in any other product without affecting that products licensing. It only governs the licensing of the included library. The problem here is that a great open source initiative can be hidden or eclipsed without much more that re-releasing it under a different name, which reduces support for the primary project.

    We doubt this small editorial will have a ton of impact on this issue, but we think its time to create and or form a new public license type that can accommodate the needs of both the public projects, and commercial developers who wish to support that project with privately licensed software that extends its utilization. While this would not be a go-to choice for many of the open source projects now in existence, it would provide a model for moving forward that would unify two apposing camps under a fair set of rules and ultimately lead to growth for these newly unified communities of interest.

    We would love to see the GNU and Free Software Foundation take this challenge on and develop new models for the benefit of all. Perhaps a GNU/GCEPL (General and commercial exception public license) that would protect the assets of the open and free portions of a codebase, while allowing writers of applications that utilize publicly stated API's from having to be bound by the same license. If a third party application utilizes these API's, and makes no attempt to utilize or duplicate code that is not included in the API, they should be considered autonomous as regards licensing.

    This would relieve developers of open source projects from having to advertise these exceptions in an effort to attract commercial third party developers, the commercial developers would know it already existed by the statement of license type. The license type would make clear to those familiar with it, that the codebase was open and free, but could be added to with commercial third party products.

    Third Party developers would be protected from attempts to "out" their code into the world of free and open, and open source projects would be able to interact with, and attract the participation of, these third party developers without having to resort to making their own projects LGPL.

    We need this option in the evolving world of open source, for those who wish to avoid the whole "free and open vs. commercial" battlelines in the interest of providing highest utility for end users and ultimate acceptance and growth of the base project.

    As is now, open source and free projects end up creating new licenses to accommodate this model which contribute to the proliferation of licensing models. We know this would not be totally eliminated, but we think a well thought out model could eliminate a lot of it, while providing a standard for open co-operation between differing camps and communities.

    We have been arguing this internally, primarily due to our expected release of Site Authentication Manager (working name) which we want to release as free and open software. We know that many commercial product developers will be reluctant to do much more than read what license type they are dealing with once they see GNU/GPL, and we do not wish to release it under the LGPL (although some portions of it will be). If we choose to release under the GNU/GPL, we will do as others have done and publicly state our exclusion for third party developers who wish to participate, but will be closely examining creating our own licensing model before proceeding.

    We hope this provides some useful food for thought. The Free Software Foundation would be providing the world a tremendous service by tackling this issue. They have the clout and the exposure to make it happen in a way that ultimately benefits everyone, and reduce the proliferation of some of these alternative "free" licenses that are currently clouding the license name space.

    Last Updated ( Wednesday, 05 April 2006 )
    < Prev   Next >

    All site content Copyright SAM Code Team
    This is a SAM powered website
    SAM Code Team is sponsored by the Road Star Clinic and