On Thu, 2011-02-10 at 11:09 +0100, Aanjhan R wrote: > On Wed, Feb 9, 2011 at 1:37 PM, Rahul Sundaram <[email protected]> > wrote: > > conclusions after that point. If you want to discuss this > further, > > catch me up on IRC or mail me offlist. I am sure the list needn't > be > > bothered further with this. > > No way. Just because people are not contributing doesn't mean they are > not interested. I am all ears on this thread.
and now to add some ghee to the flames: My observations on the different modes of development now existent, the licenses they choose and how the licenses affect the development. 1. The classic mode which we all love and respect: Community driven, meritocracy ruled projects. These are hugely successful in attracting developers and although the top rung may not change much there is a constant in and out flow of developers in the lower rungs. As these projects reach maturity, the usually produce non profit foundations to take care of organisational aspects - examples: linux kernel (GPL), apache set of projects (Apache license) python and postgresql (BSD license) and many others of course. 2. Company mode (free) - where the project is mainly run by a company and the said company does not have any proprietary products based on the project in question. Usually these companies are able to attract large number of developers because the developers know that the open source version they are working on is the same version that the company is working on. Companies almost invariably choose the GPL as suits are scared that some one may 'steal' their code. Any way a prime example of this type is Red hat. There is the curious case of PHP where a company has 'downgraded' it's license from GPL to a BSD style license. Wonder why ;-) Sort of knocks the apparent logic of the wine license change into a hat. More on this later. 3. Company mode (somewhat free) - here the company has an open source project, and one or more proprietary products built on the open source project. Looks like wine (and codeweavers) is one of them. Usually the company does the bulk of the development and does not attract (and does not really want) too many outside developers. Company decides the path to be followed with not much say for others. Or in extreme cases like MySQL (and mono?) the company will not take contributions unless the copyright is handed over. From what I can make out from the wine case, it started as a community project under the BSD license, but codeweavers moved in to do the major development, and changed the license to 'protect' their interests and investment. An interesting comment in the discussion was - BSD licensed projects are based on trust, with LGPL the necessity for trust is eliminated - to me this sounds very sad. 4. Company mode (bogus) - here the company releases a watered down version as open source mainly as bait to get customers for the proprietary version. This does not attract developers as the the version they are working on is not the actively developed version. These companies are a disgrace and instrumental in turning a lot of people away from open source. The all either use GPL or something even more restrictive. 5. Autorickshaw mode - where the whole development team will fit into an autorickshaw. This segment rarely thinks too much about license, and anyway they can change license at will. When I first released something through sourceforge, license was one thing that I had to choose - GPL was the default and I clicked it - I only read the GPL about 3 years later ;-) 6. Closet mode - this is a new one that I just discovered a couple of months back. Here the guy develops software in secret, wraps it in the GPL and sells copies of it to the customers. He has discovered that the GPL does not oblige him to put up the source on the internet. Theoretically his customers can put it up themselves, but in practice it is impossible. I am sure if one sees the software, it would have to be installed by hand in various parts of the operating system. The customer, in the first place, having paid for it is not going to give it away free. And in the second place it is doubtful if he would have the knowledge to package it for release in a usable form. We are all aware of the time consuming processes we have to go through to make a release usable. And anyway without support from the developer, putting the code up someplace is an exercise in futility. I think this is a glaring loophole in the GPL and is why I had suggested a 5th freedom on my blog. note 1: Change of license is only possible if all the contributors agree to the change. Even if one disagrees, his work has to be removed before the license is changed. Which means that once the number of contributors reaches a critical mass, change of license is impossible. note 2: Although software cannot be stolen or made proprietary (only a copy can be stolen or made proprietary), the owner of the copyright can sell the copyright (as opposed to selling a copy). But if the number of developers has reached a critical mass, selling the copyright is also impossible. -- regards KG http://lawgon.livejournal.com Coimbatore LUG rox http://ilugcbe.techstud.org/ _______________________________________________ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
