On Fri, Jan 18, 2013 at 6:06 PM, Gervase Markham <[email protected]> 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 <[email protected]> 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 [email protected] http://hsivonen.iki.fi/ _______________________________________________ legal mailing list [email protected] https://lists.mozilla.org/listinfo/legal
