Re: [OSCOM] are the collaborative licenses approved by OSI?

Hi Martin,

I do not want to start a license war here. I do not think this is the right 
place to discuss open source license/fair source license/ developer source 
license or other derivatives and tI think the world is large enough so that 
all type of licenses can exist.

I am not against free-riders (and the Jahia license is free for test, demo 
or development purposes) but I am clealry in favour of a fair and win-win 
collaboration pro rata the value added the end-user will get from a 
software project. Such an approach also help create faster a community of 
active contributors. With an OSI license this is just a bit too easy for an 
IT manager to tell his developers: "It's free, let's take it and let's 
spend our time (and then our money) on other tasks". Too many good open 
source projects only relies on 1 or 2 volunteers and have have difficulties 
to attract other long term developers. Starting a successful open source 
project with a strong community of contributors is not an easy task. So if 
we push the customers (indirectly his system integrators or his internal IT 
dept) to contribute, they have then no choice than assigning some internal 
ressources on developing some new enhancements and the developers do not 
have to try to argue to their IT manager: "It's free but it would be fair 
to contribute something to the project even if we have no obligation to do 
it". Sorry we are leaving in a "maximize your immediate profit" world. So 
our license just tries to enforce a fair but strong quid-pro-quo where, at 
the end, everybody is a winner.

And what is more important: we never had problems with the final end-user 
to explain this paradigm. End-users (in our case mainly public or 
commercial organisations) generally have no problem to "pay" for a product. 
If they can pay in a kind it is even better. Especially in the CMS/Portal 
world where you can be quite sure that there will be some new enhancements 
to bring to the platform in order to satisfy your internal requirements. I 
clearly think that what the customers really want today is the full source 
code and no vendor lock-in. Mixing free beer and free speech was an error. 
Ideally OSI should have regrouped all licenses with source and should have 
classified them by clear categories (FOSS license, Fair source license, 
Developer source license...). Then it would have been clearer for all the 
end-users (and developers) what is commercial product but with source, what 
is gratis but with a strong viral effect, etc...

Finally, as said, I'am not against OSI licenses and projects. We are 
contributing lots of things under OSI (mainly what I call "infrastructure 
libraries") when this makes sense to share the maintenance costs with a 
community where everybody is interested to have as soon as possible a bug 
free working library. For ready to use finished software product (e.g. a 
CMS), I think this is more difficult because one will always thing he's 
being cheated.

But as mentionned Michi what's important for OSCOM is the OSCOM definition 
of open source. Does it mean FOSS licenses only or does it regroups other 
kind of licenses with source (freely) available?

Peace,
Stéphane


At 23:38 01/03/2005, Martin Bähr wrote:
>On Mon, Feb 28, 2005 at 11:10:44AM +0100, Stéphane Croisier wrote:
> > So, briefly speaking we wanted to push (=force) the customer to contribute
> > (in cash or in kind) and to avoid technology free-riders
>
>allow me to quote:
>   Steve Weber, 2004, The Success of Open Source, p154:
>
>   The point here is that open source software is not simply a non-rival
>   good in the sense that it can tolerate free riding without reducing the
>   stork of the good for the contributors. It is actually anti-rival in the
>   sense that the system as a whole positively benefits from free riders.
>   Some (small) percentage of these free riders will provide something of
>   value to the joint producteven if it is just reporting a bug out of
>   frustration, requesting a new feature, or complaining about a function
>   that could be better implemented. In fact, one wonders if it makes sense
>   to use the term free rider here. Regardless the more free riders in this
>   setting, the better.
>
>greetings, martin.
>--
>cooperative communication with sTeam      -     caudium, pike, roxen and unix
>offering: programming, training and administration   -  anywhere in the world
>--
>pike programmer   travelling and working in europe             open-steam.org
>unix system-      bahai.or.at                        iaeste.(tuwien.ac|or).at
>administrator     (caudium|gotpike).org                          is.schon.org
>Martin Bähr       http://www.iaeste.or.at/~mbaehr/