{{ Opening disclaimer: This post touches on license interaction and
consequences. I am not a lawyer. This is not legal advice. }}

Ann Harrison wrote:

> >- If 1.1, will the multiple-licensed code provisions be utilised? (I
> >hope so.)
>
> They will be intact, but we don't anticipate using them immediately.
>
> >- If so, is LGPL an option?
>
> Interesting question. I'm not entirely sure what the benefits
> are.

I'll describe them shortly.

> >Perhaps the situation is still being considered, in that case a clear
> >indication of what needs to be achieved first would be appreciated.
>
> We need a license that meets open source standards and the standards
> of corporate legal departments. InterBase has an existing user

Clearly. MPL was very much designed with that in mind.

> base. We like them (well, most of them). If we a license that
> appears to move their code into open source without their consent,
> they will choose a different database.

Ah. That is an important concern, it is neccessary not only that the
licensing strategy employed is "safe" for licensees, but that it appear
to be so. This is actually pretty straight-forward for the approach that
MPL 1.1 makes available.

> Would you elaborate on this? I understand that the Gnome developers
> prefer GPL/LGPL ...

It's more than that, they're kind of chained to it. (If you could draw a
line around "all" GPL'd Gnome code and all GPL'd code on which it
depends, identify all of the developers and get unanimous consent, it
would be possible to change licenses. In practice, the steps prior to
"get unanimous consent" appear infeasible, but even if not, unanimity is
likely to be unattainable. Isolating dissenters and dependence upon
their code is also likely to be infeasible.)

To integrate, they need code to either (i) be under the GPL or (ii) be
capable of conversion-at-licensee-option. That latter option is offered
by LGPL and by MPL-1.1-with-GPL-option or MPL-1.1-with-LGPL-option (in
the latter case, conversion is a two-step process, but you gain the
ability to achieve LGPL integration also).

> we've certainly had that argument on this list
> and around the Interbase 2000 site. The general (though certainly
> not universal) conclusion was that even LGPL would not sit well
> with corporate legal departments. There were some who felt that
> was a good thing, but ...
>
> If we used multiple-licensing and put out an LGPL version and the
> Gnome developers contributed, could we bring their contributions
> into the main-line, MPL 1.1 licensed code?

{{ Clarification: I'll talk about "GPL developers" to mean developers
who, for one reason or another, tend to work with the GPL in preference
to other licenses, at least for some projects. The Gnome group is just
one group of such developers, it may be that an RDBMS is of limited
interest to this group, but that some other group(s) may emerge
post-release. In fact, at the time that I was making the dual-licensing
argument to Netscape exactly two years ago (give or take a few days), I
was unaware of the likely importance of the Gnome group. It was only a
year later that their importance, and thus Netscape's mistake, was
obvious. For Interbase I am arguing against excluding unidentified GPL
developers, whose activities and importance will almost certainly only
become apparent after the fact. }}

This is up to the individual GPL developers and IBDI policy. (How do I
talk about the group that is handling the open-source Interbase effort?
Do I say IBDI? interbase2000.org?) I'd propose that contributions only
be accepted into the "main" source tree if they are offered under the
same dual-licensed arrangement.

Suppose a GPL developer chooses to take the code under GPL, and accept
only the GPL's redistribution obligation (that derived works also be
made available under the GPL). If the work is of a sort that is not of
use to IBDI (e.g. a tight integration with other GPL'd code). In this
instance, nothing has been lost.

Now suppose a GPL developer chooses to take the code under GPL, but
produces a bug fix or a performance tweak, and refuses to contribute it
under the dual-licensed arrangement. This developer now becomes a victim
of the "stupid tax", as his/her/its patches need to be re-integrated
with each new version, at substantial cost and inconvenience to
him/her/itself. (N.B. This is not exclusively a problem with
dual-licensing, MPL was built specifically to facilitate similar
behaviour, where it suits a licensees interests to do so. The existence
of performance-tweaked Linux distributions demonstrates that there is a
business opportunity here, and that the failure of some of those changes
to be offered/accepted into "main" trees does harm the Linux community
at all, in fact it aids it.) If the convenience of having the
fix/enhancement rolled into the main tree exceeds the benefit from not
doing so (competitive advantage, commitment to FSF's principals, etc.),
then there is a good chance that the developer will willingly contribute
under the dual-licensed arragement.

So, in answer your question, yes you can, if the developer allows you to
(same applies for most other enhancements to MPL'd code).

Larry Wall's policy on contributions to Perl itself is that they must be
offered under both GPL and Artistic, or they don't go into his tree.
This doesn't prevent others from making GPL'd enhancements that aren't
available under Artistic, it just means that such enhancements have to
be maintained in their own tree. Needless to say, few people bother.
Larry receives dual-licensed contributions from many people.

It seems that I really should do some background reading. I'll strive to
read the list archive before getting into specifics of the arguments
about freedom from unintentional obligation and/or grant.

- Raz