Daniel Veditz wrote:
> True, but if we said a MPL'd file could be used as GPL as long as the MPL
> header remains intact we haven't added any additional restrictions either --
> the file can be treated as GPL and has the same requirement the acceptable
> BSD/MIT/Zlib etc licenses have. The only time additional restrictions come
> into play is if the modified MPL'd portion is separated from the GPL'd
> project.
This is exactly the kind of licensing construct that I have been discussing
with RMS. Although he has rejected it, I believe that he is wrong.
In fact, it could be argued that the disjunctive GPL/XXX dual-licenses
that the FSF endorses are GPL-incompatible, as they allow an XXX-only
fork. Only dual-licenses which prevents a XXX-only fork can be considered
GPL-compatible (I believe the current MPL/GPL suggestion does so, but
other dual-licenses such as the Perl license does not).
The interesting question is then if dual-licenses which prevents both
XXX-only and GPL-only forks are GPL-compatible too.
> So what happens to code in a BSD file when part of a GPL project? Since you
> have to leave the license header intact then if that code is separated out
> of the GPL project it's covered by BSD presumably. Perhaps this is legal
Yes, BSD covered code will remain under BSD at all times (or at least,
until the copyright expires or the copyright holder changes the license).
> becase the BSD technically has fewer restrictions than GPL, but the results
> are far less in the spirit of GPL than the equivalent situation with MPL is,
> and yet this seems to be no problem to the FSF.
The FSF is more concerned about the whole than the individual parts. In
mathematical terms, the FSF wants the union of GPL and another license to
be strictly equal to GPL. The problem the FSF has with MPL, is that there
are additional restrictions on the whole.
