Back in February of this year, Nat Torkington asked “Is ‘Open Source’ Now Completely Meaningless?”
Obviously we don’t think so, having just launched this directory, but from the beginning, one of the challenges has been just what definition of Open Source we should use in determining which projects to include.
Dana Blankenhorn posted recently on ZDNet (”Optaros EOS will take the licensing question seriously“) talking about some of the issues and our plans for handling them. (For more on the subject see Michael Tiemann’s “Will the Real Open Source CRM Please Stand Up, ” and Matt Aslett’s “Centric CRM and SocialText respond to open source hard line,” as well as Blankenhorn’s earlier posts on the subject)
The simplest criteria we could use to determine whether to include a certain project is whether the software is available under an OSI Approved License. If the license being used is not currently OSI approved (as is true of, for example, with the Affero GPL), we could try to determine whether the license would be approved if submitted, by testing the license against the open source definition. (This approach would run the risk of marking as “unapprovable” licenses that OSI might approve, or of marking licenses as “approvable” that OSI might reject.)
However, there are projects out there which are widely used in enterprises, and which describe themselves as open source. For example, projects which require the prominent display of a logo in any derived work (often called “badgeware” or “logoware”), or projects which use an Affero GPL like clause to close what they see as an ASP or services “loophole. These licenses have not met with OSI approval, and yet many would consider such projects open source and wonder why they aren’t listed.
Our approach has been, and will continue to be, to provide as much clarity as possible about the licenses under which various projects are available.
As my colleague Dave Gynn put in his discussion with Blankenhorn, our plan is to positively identify projects whose licenses are OSI approved, and provide a basic overview of what that means and why we think it is important.
This way, projects whose licenses are not OSI approved will still be included in the directory with what license they are released under clearly identified.
We’re also trying to find a fair but clear way to identify and present to users what prevents any particular license from being OSI approved. This can be complicated, however, since we do not want to position ourselves as speaking for the OSI (it is not up to Optaros to determine what is or is not OSI approved licensing) or for the project (presenting the projects’ own rationale for its license does not mean endorsing it).
I’m also interested in what the community of users here has to say. What guidelines would you like to see applied to projects being considered for inclusion in the EOS Directory?
Entries (RSS)