On Fri, Jan 18, 2013 at 6:06 PM, Gervase Markham <
ge...@mozilla.org> wrote:
> The MPL was created as an intermediate stage between the copyleft of the
> GPL and the non-copyleft of licences like the BSD license. It has served
> us well in that role for many years.
Served us well in what sense? What code contributions has Mozilla
gotten because of copyleft in MPL? What code contributions Mozilla
thinks it should have gotten but didn't get despite of MPL?
I didn't follow the Flock case at the time. Is there a postmortem
analyzing the Flock case and whether Mozilla's licensing policy
resulted in outcomes Mozilla wanted in that case?
> Copyleft is a tool which we use to achieve particular ends.
What are the ends in Mozilla's case?
In general, copyleft serves three purposes: 1) requiring people who
build upon the copylefted code to license their code in such a way
that it can be integrated back into the original project, 2) making
people see what code someone ships and 3) making how you obtain
software not matter when it comes to right to redistribute (i.e. you
know GCC is still under the GPL if you obtain GCC from Apple—but are
you sure the copy of clang you obtained from Apple hasn’t gotten
infected by the proprietary license of the dev tool package?). (GPLv3
also tries to serve the purpose of making sure users can repair
software on their devices themselves, but in the Tivoized world
copyleft in general does not provide this.)
In the case of the old tri-license, purpose #1 was easy to circumvent
by someone who didn't mind #2 but who had reasons not to contribute
back to the original project: Licensing modifications only under the
LGPL or the GPL. MPL 2 tried to plug that hole. Is it too soon to
assess whether plugging that hole has resulted in any code getting
integrated into Mozilla's repositories that previously would have been
deliberately made unintegratable?
It's worth noting that copyleft works for coercing reluctant third
parties only when the copylefted software is unique among other Open
Source alternatives. For example, Apple and the BSD projects where
more willing to tolerate the licensing of GCC before clang existed as
a technically good enough alternative. (Also, they were more willing
to tolerate GPLv2 than GPLv3. Apple is so intolerant of GPLv3 that
they sacrificed user experience in order to get rid of Samba
[replacing it with the outrageously beachbally SMBX].)
When Mozilla's licensing policy was established, the expectation was
that many proprietary-minded entities would embed Gecko into
proprietary shells and still make improvements to Gecko itself. But
after that time:
1) WebKit has entered the market and is perceived by potential
embedders as good enough and has a more common license that Gecko
(LGPLv2 vs. MPL).
2) The way WebKit has been used suggests that proprietary-minded
entities that want to embed a Web engine aren't really that interested
in contributing to the engineering of the Web-exposed capabilities of
the engine. (That is, Apple and more recently Google are the companies
that do the most of the core engine engineering in the case of WebKit.
The large number of other companies that use WebKit tend to get a free
ride when it comes to the core features of the engine and they focus
their engineering efforts on porting the engine to their environment.)
That is, perhaps the idea that proprietary-minded embedders would
improve the guts of Gecko was wishful thinking all along.
3) It appears that copyleft is not what motivates Apple and Google to
work on a common source tree. There are other factors.
4) Mozilla has ceded the embedding market to WebKit anyway as far as
technical aspects go, so the legal aspects of embedding Gecko aren't
really that relevant anymore.
If one considers the availability of competing alternatives as a
factor in licensing: Should Mozilla make Servo's licensing less
restrictive than either Gecko's or WebKit's to drive adoption once
Servo is technically good enough?
> So, the first question is: if use of non-copyleft licenses has become a
> practice, is it a good practice?
Have there so far been cases where someone has improved non-copyleft
Mozilla source and we really wish we could get their improvements and
believe that had the code been under MPL, they'd have still chosen to
make the improvements?
On Mon, Jan 21, 2013 at 4:21 PM, Gervase Markham <
ge...@mozilla.org> wrote:
> 1) Do we think there are circumstances under which it is best for
> Mozilla to release software under a "no copyleft" (a.k.a. "permissive")
> license? If so, what are they?
The link between Mozilla's Mission and funding the DOM and XOM
features of the Validator.nu HTML Parser that are needed neither by
Validator.nu nor by Firefox was driving the adoption of the HTML5
parsing algorithm thereby driving the adoption of Open Web formats
beyond Mozilla's usual browser context. The MIT license made sense,
because when you want to drive adoption, it makes sense to choose an
universal donor license that works for apps from super-proprietary to
GPLv2 and GPLv3.
So I think it makes sense to say: Mozilla should release software
under a "no copyleft" license at least when driving the adoption of
that software is more important than attempting to force other people
to open their code and copyleft would hinder the adoption. (Copyleft
is more likely to hinder the adoption of libraries like a parser than
the adoption of full end user products like Firefox.)
On the other hand, it doesn't seem particularly useful to use a
copyleft license unless there is a good reason to believe that Mozilla
would get more useful contributions as a consequence of copyleft
compared to the "no copyleft" scenario.
> 2) If there are such circumstances, what "no copyleft" license should we
> use? (With the licensing team recommending Apache.)
Compared to BSD and MIT, Apache has two downsides:
1) Incompatibility with GPLv2.
2) Having to include a longer piece of legal text.
On point #2 even without comparison to BSD or MIT: Apache License 2.0
says you have to distribute the full license text along with the work.
This is a non-issue for a large software application. It might even be
a non-issue for Web use if it is enough for the license file to sit on
a server ready to a GET with only its URL sent in JS or CSS comments
or something but the end user does not actually have to issue the GET
for it.
However, for works like fonts, images and similar, the requirement to
distribute the full license text along with the work may be onerous.
If Mozilla mandates the use of the Apache License for that kind of
works, I think Mozilla should waive the requirement to distribute the
full license text.
> 3) If we decide on Apache as our "no copyleft" license, what do we do,
> if anything, about existing projects which are BSDed or MITed?
Does this question apply to projects whose development Mozilla pays
for but that aren't under Mozilla governance formally?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/