The early adaptors have all moved to Firefox apparently. It looks as though 8% is Firefox's natural open source market share. I wonder if the new Mozilla corporation will help drive adaption by giving corporations someone to talk to. That's a pretty common request among CIOs. Trying to gain market share against a product that ships with every single machine in the world is fairly hard. I use it and I find it a pretty good product. Of course now that the IE team is re-constituted and working away, MS will ship a product that's just good enough.
Technorati Tags:
Open Source
Firefox
IE
Tuesday, August 16, 2005
License Issue & Success of an Open Source project
One of the things recently discussed at OSCon was the proliferation of open source licenses. As more companies begin to open source some of their applications, their corporate attorneys often feel the need to re-write and redo licenses that have effectively been done.
"Referring to 63 approved OSI licenses and another 100-200 "floating around," Levin echoed others from the FSF and elsewhere in calling for a reduction in licenses. "We want to reduce any possible objection, concern, or friction point with using open source licenses," he said. "There are truly an unnecessary group of licenses which have been created because of lawyers' needs to justify their existence or because companies have a narcissistic need for differentiation. The slight variations are more often than not an overreaction by zealous lawyers."
I knew the moment that OSI started accepting licenses to approve that this problem was going to happen. Everyone wants their own licenses, even if it's just their own spin on the BSD license. We licensed under the Sleepycat for Xao and it seemed to work fine.
The problem that the proliferation of licenses creates confusion over the usage of the particular program especially in a situation where you want to build a new set of services on top of an existing set of open source programs. The confusion of parentage of such a chimera makes it impossible to decide which license to use and for developer to understand what rights they retain to the code. That's why it's pretty clear that the open source projects that succeed have clear relatively easy to follow licenses.
When I say success, I mean successful at attracting outside developers to the project . By using one of the traditional open source licenses that is well understood by the developer community, allowing them to understand exactly which rights they are giving up and which they are retaining. While your corporate counsel may want to write their own, I can assure you that someone else has covered all the issues you are facing.
One way to determine your license is to take a look at the business purpose for open sourcing your software. If your intent is to develop a community around your software, chose a well known license. (Sleepycat, BSD, GPL, Mozilla)
If your purpose is to have an "open source" product and most of the developers are going to work internally on your project, feel free to write your own. Just don't expect a whole lot of outside developers to contribute. Without a clear delination of rights, developers are much less likely to work on a project. Why waste the time?
Technorati Tags:
Open Source
Licenses
GPL
"Referring to 63 approved OSI licenses and another 100-200 "floating around," Levin echoed others from the FSF and elsewhere in calling for a reduction in licenses. "We want to reduce any possible objection, concern, or friction point with using open source licenses," he said. "There are truly an unnecessary group of licenses which have been created because of lawyers' needs to justify their existence or because companies have a narcissistic need for differentiation. The slight variations are more often than not an overreaction by zealous lawyers."
I knew the moment that OSI started accepting licenses to approve that this problem was going to happen. Everyone wants their own licenses, even if it's just their own spin on the BSD license. We licensed under the Sleepycat for Xao and it seemed to work fine.
The problem that the proliferation of licenses creates confusion over the usage of the particular program especially in a situation where you want to build a new set of services on top of an existing set of open source programs. The confusion of parentage of such a chimera makes it impossible to decide which license to use and for developer to understand what rights they retain to the code. That's why it's pretty clear that the open source projects that succeed have clear relatively easy to follow licenses.
When I say success, I mean successful at attracting outside developers to the project . By using one of the traditional open source licenses that is well understood by the developer community, allowing them to understand exactly which rights they are giving up and which they are retaining. While your corporate counsel may want to write their own, I can assure you that someone else has covered all the issues you are facing.
One way to determine your license is to take a look at the business purpose for open sourcing your software. If your intent is to develop a community around your software, chose a well known license. (Sleepycat, BSD, GPL, Mozilla)
If your purpose is to have an "open source" product and most of the developers are going to work internally on your project, feel free to write your own. Just don't expect a whole lot of outside developers to contribute. Without a clear delination of rights, developers are much less likely to work on a project. Why waste the time?
Technorati Tags:
Open Source
Licenses
GPL
Subscribe to:
Posts (Atom)