On 22/01/13 13:11, Henri Sivonen wrote: > 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'm not sure one could say the MPL was the tipping factor one way or the other for a particular contribution. I can try and answer the related question, "why is the MPL's particular brand of copyleft strength a good choice for Mozilla?" I think the answer to that is that the file-level copyleft sets up a community expectation of sharing more than permissive licenses do, while not prohibiting proprietary derivatives in the way stronger copyleft licenses do. Some, of course, may not agree with the first half of that. > 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? I've not seen an explicit post-mortem. I did not carefully study Flock's licensing, but my understanding from others is that they took tri-licensed code and made it GPL-only to prevent Mozilla from reincorporating their changes. (Of course, there's still the question of whether we'd have wanted to take their changes.) This is unfriendly, but then the MPL itself is designed to allow proprietary derivative works like e.g. Netscape 6+. It could be argued that the only difference with Flock is that instead of making it proprietary, they wanted to appear to some like good open source people and so used the GPL instead. Perhaps some of the ex-Flockers around the community, now that Flock is gone, could tell us a little about how these things were viewed inside? >> 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? I'd say it's too soon, yes. Although I'd also say that MPL (either version) provides other mechanisms (such as the limited copyleft) to keep your code from falling under the MPL if you are willing to make the engineering effort to use them. > 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). ....albeit one which requires a greater level of code sharing than MPL does. > 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. A fair point indeed. It would be interesting to hear from the platform engineers about their experience of incoming patches and their origins. > 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? I wonder whether it's in the best interests of the web for there to be lots of proprietary rendering engine forks. "People won't bother to do that" seems a bit wishful. If the engine is copyleft, one can at least see what brain-damaged thing someone else has done, even if you don't want to do the same thing yourself. >> 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? I have no idea; to know, we'd need to hear from an engineer who wanted some source but couldn't get it. > 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. I can see this as an argument against GPL-level copyleft; the FSF even uses it when deciding whether to use the LGPL. But I'm not sure it applies when considering the MPL. Let's imagine your "super-proprietary" app wants to include an MPLed library. What do they have to do? Ship the source to that library (only). Why can't they simply do that? There are a few possible reasons: a) technical changes to our code that they don't want to reveal b) ideological opposition to publishing source code Re: a) - do we really want lots of proprietary, differently-behaving HTML5 parser forks we can't see inside? I'm not sure what to say about b), other than that it's a really stupid position to hold. >> 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. Yes, albeit once, and the per-file license header is half the length of MIT in words, and less than half of BSD. > 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. It depends on how you interpret the word "give" in Apache 2.0. I'd only say that it's mind-bogglingly unlikely that you would face a copyright suit for providing a copy of the canonical URL to the Apache License instead of a full copy of the license itself. > 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. An interesting idea; although we could only do so for stuff we owned the copyright on, or which was contributed directly to us (and so we could say had been contributed with this rider in mind). If we used a 3rd party Apache-licensed thing, we wouldn't have this exception. And so we'd have to keep track of which Apache things in our tree were vanilla, and which were Moz-flavoured. >> 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? Good question; I hadn't thought about it. Are you thinking about the validator.nu HTML5 parser? :-) Gerv _______________________________________________ legal mailing list [email protected] https://lists.mozilla.org/listinfo/legal
