MPL 2.0 has been published here:http://www.mozilla.org/MPL/
with a FAQ here:
I am interested in your views as to whether Saxon-HE should move forward
to being licensed under MPL 2.0 (it is currently under MPL 1.0, having
skipped MPL 1.1). I know that the vast majority of you don't care one
way or the other, but if you have a strong reason for favouring a change
or opposing a change, please let us know.
I'm inclined to move forward for the simple reason that the 2.0 license
is much clearer. There are some useful relaxations of the rules, for
example the requirement to include legal notices now applies only to
source code distribution, which makes it possible for the first time to
distribute JAR files via Maven.
Note that licenses other than MPL are not an option, because it would
require the consent of all previous contributors, and they are not all
I get periodic requests from various organizations saying they can't use
Saxon because they have a policy about which open source licenses they
will accept. Generally I'm prepared to tell them that if they don't like
it they can lump it; the only people they are hurting are themselves.
However, I have some sympathy with people who are trying to assemble
open source products from many components issued under a variety of
MPL modules can be marked "compatible" or "incompatible" with secondary
licenses (which in practice means GPL). GPL-compatible modules can be
included in a larger work distributed under GPL; GPL-incompatible
modules can't. We can't move existing modules to a GPL-compatible
license without the consent of contributors.
If we choose to do so, then Saxon open-source code can be moved forward
to MPL 2.0 "incompatible with secondary licenses" without difficulty.
For modules where the code is ours or BSD-licensed (99% of the "core"
code) we could go further and move it to MPL 2.0 "compatible with
secondary licenses"; we could also offer such code under licenses such
as Apache. There may be benefits in doing this, even though more
restrictive licenses still apply to the remaining 1%, because an
integrator who cares about license incompatibilities could potentially
undertake the work of rewriting the 1% (though it's not trivial, because
some of the 1% includes interfaces, and it's not clear how you can
retain interface compatibility without copying code).
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
saxon-help mailing list archived at http://saxon.markmail.org/