Mitchell Baker wrote:
>
> Daniel Veditz wrote:
> [emphasis added]
>
> > I should note that I personally am opposed to the specific dual-licensing
> > scheme proposed. It doesn't merely fix the GPL compatibility problem, it
> > allows a GPL project to make improvements to Mozilla code without sharing
> > those changes back (by changing the license of existing files to GPL-only).
> > This is a violation of the fundamental idea behind the MPL, and *as far as I
> > can tell wholly unnecessary to solve the license **incompatibilities.*
>
> I would be very interested in a proposal that didn't allow a GPL fork
> and yet was acceptable to the Free Software Foundation. I have yet to
> find one. All my discussions have coome back to the point that the GPL
> prohibits the application of any new restrictions. And requiring code
> to be licensed under the MPL as well as the GPL is an additional
> restriction which causes an incompatibility with the GPL.
I took another look at some of the licenses the FSF considers GPL compatible
(http://www.fsf.org/philosophy/license-list.html#GPLCompatibleLicenses).
Most of those are chock full of restrictions, along the lines you can't
remove the original copyright info and license from these files.
What happens if some GPL project embedding perl modifies the perl engine? Or
a GPL project embedding zlib fixes a bug or adds a feature? If someone pulls
the modified file out of the GPL project (with the original copyright
license notice still intact as required) could they use those changes in a
project under the perl or zlib license?
Wouldn't a "dijoint license" scheme (to use the FSF term) that simply says
"Alternatively this code can be treated under the terms of the LGPL or GPL
as long as this copyright notice remains intact" be equivalent to most of
the official Compatible licenses?
To change the subject slightly, my investigation caused me to realize that
Exhibit A doesn't state that users of the code must keep the copyright
notice intact. Section 3.5 of the license does, however, though some folks
might argue it only says you have to duplicate the stock Exhibit A in the
MPL itself, not preserve the one found in the source code. I hope I'm wrong
on that loophole, but it still might be nice to add a line to this effect in
Exhibit A itself.
-Dan Veditz
