> > I've heard from Turbine folks, as well as from someone
> > working on Enhydra that MPL is acceptable.
>
> At this point, I'm hesitant about Enhydra because I'm not comfortable with
> their motivations for using code. In other words, there is very little
> distinction between Lutris.com and Enhydra.org and that lack of distinction
> tells me that they are simply trying to use the OSS communities to develop
> their code for them vs. simply developing code for the OSS community and
> everyone else. These are little semantic games that I'm talking about, but
> they do matter because perception ends up being very important.
There should be Lutris' people on this list so I will let them do their
defense.
I am speaking as an Enhydra's community member. Lutris has done a great
job with the open source effort of Enhydra. They didn't just dump the
massive code base of Enhydra into open source and expect the community
to pick up the development work. Netscape did just that with Mozilla and
look at who's actually using Mozilla these days.
I am not sure where the perception comes from. From the $99 packaged
Enhydra banner on Slashdot, perhaps?
> I would strongly suggest making a case *why* you want to MPL vs. BSD/ASF it.
> You have already stated that you want the most amount of people to be able
> to use your software without having to worry about stuff. If that is the
> case, then the BSD/ASF license is the way to go vs. the MPL. If you choose
> to BSD/ASF your code, you will have no problems with any other framework.
>
One thing about contributing to a BSD/AFS project is that some big guy
may extend and package my contribution without giving me back the
source. Something like MPL or LGPL would at least give me more
protection in my contribution. GPL would be the ideal license for me as
a individual.
However, in our quest to build an open source software company, we found
GPL isn't the best. We build the company arround the RMS' manifesto
about open source. We provide open source software based professional
service and develop codes to glue these togehter for our clients. Not
many clients can accept GPL, especially when some of these codes involve
their business rules.
In the business side, we prefer to use software under MPL or LGPL. On
one hand, it protects our contribution to the community. On the other,
the clients are more likely to accept those license terms.
This is not perfect but it's better than doing propritery programs in
days and hacking open source at night. We can at least make working on
open source software our day jobs.
David Li
DigitalSesame
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
