One comment re using the BSD as an alternative. It does work well for
commercial customers, because essentially they can do whatever they want
with BSD code. Including privitize it, as long as they keep the correct
notices.
One of the things the MPL does is make customers look at the idea of
contributing back to the project. (So this does require effort on their
part, it is not the easiest way for them.) But in general, I have found
that companies can get comfortable with the MPL and be comfortable
enough to contribute back. (In large part because there's a clear line
that says they can treat non-MPL code however they want.)
So not having a BSD style license has encouraged contributions back in 2
ways. First of course, the MPL requires contributions back for MPL
"Modifications." Second, the process of getting companies comfortable
with this requirement encourages them to understand the benefits so that
the default response to a BSD license isn't only "good, we can treat
this as private code."
The latter response may be less pronounced now than a few years ago.
But I still find it in my discussions with the non-engineering
departments of a number of companies. So we forego the easiest way
(BSD), but get some benefits in return.
Mitchell
Michael Hein wrote:
> Daniel,
>
> Yes, I'm floundering around a bit.....but learning a lot from all of you guys so
> that is goodness. I'm actually all set to go as far as changing the C SDK to the
> MPL/GPL combo; however, thanks to you and others I'm reconsidering. This is a
> good thing because I would have otherwise just blindly charged ahead without fully
> understanding. I have a couple of goals as far as the licensing of the SDK go.
>
> 1) I would ofcourse like to prevent forks, if possible
> 2) For our commercial customers, I need a license which they will accept with
> minimal fuss and which protects their source code rights. In past experience, a
> BSD style license has always worked well for commercial customers. I want to
> allow for commercial customers not to have to recontribute code back etc.
> 3) Allow for as many people to pick up the source with the least amount of hassle.
>
>
>
> Daniel Veditz wrote:
>
>> Daniel Veditz wrote:
>>
>>> Michael Hein wrote:
>>>
>>>> Bjorn Reese wrote:
>>>>
>>>>> Instead we opted for a MPL/BSD
>>>>> dual-license. This weakens the copyleft of the project, which is the
>>>>> the opposite effect of what the FSF wants to achieve -- and the irony
>>>>> of it all is, that GPL was the direct cause of this shift.
>>>>
>>>> Do you mind posting the dual MPL/BSD you used .... the more I learn
>>>> about GPL this seems quite attractive
>>>
>>> Didn't you start the thread asking about converting the NPL'd LDAK code?
>>> Netscape and mozilla.org specifically rejected the BSD when creating the MPL
>>> (we were strongly inclined to go with an existing license at the start) and
>>> Netscape may still be unwilling to release its code under those terms.
>>
>> In fact, if your motivation is that you're having trouble getting people to
>> agree to change their LDAP contributions to MPL/GPL, picking MPL/BSD is
>> unlikely to help. People who accepted the BSD (which allows taking code for
>> proprietary projects) would be unlikely to object to MPL/GPL unless they are
>> extreme knee-jerk GPL-haters. BSD-like licenses have a "do whatever you
>> want" attitude.
>>
>> The objections I've seen about MPL/GPL (as it is currently formulated) are
>> that it allows people to fork the code GPL-only without having to share
>> improvements back. Since BSD would allow the same thing except with an even
>> broader range of projects I'm sure you'll get at LEAST the same number of
>> objections. Probably more because at least a GPL fork would still be open
>> source.
>>
>> -Dan Veditz
>
