Pick a license

[brson]

Servo still does not claim to be distributed under any license. There are probably only two options, MIT (the Rust license) and MPL.

We do have an OFL licensed font in the repo.

[brson]

There's a lot of cross-pollination between rust and servo so probably MIT everywhere is easiest.

[BrendanEich]

Let's not do this without consultation. We would prefer a license with a patent clause that we know works with prospective partners. I'll start a mail thread.

/be

[kripken]

There could be a big benefit to using the MIT license as this would be the only browser available under a permissive license (WebKit is LGPL, Gecko is MPL, others proprietary). Even without debating the benefits of permissive licensing, there is a benefit to having different licensing than existing browsers to fill a different need and attract new users.

[BrendanEich]

MPL is weak copyleft, file-wise only. This has not been an impediment in practice, and it has helped notably in some cases where we'd lose valuable work to private forks. MPL2 simplifies the MPL and fixes license interop. There's possibly some patent magic words in ASL2 that make it more desirable to some commercial outfits, but we're working on this.

I do not see either "license differentiation" or "uniform permissiveness" as goods. The license is a tool, a means to an end. One end could be widest possible use (including fragmentation into private/commercial forks). Another could be give-back by file a la MPL. Another would be having the right patent words. We should choose deliberately and not just go for MIT to be same as Rust, or to be more permissive than other engines -- including Gecko, which is permissive enough in practice.

/be

[apotheon]

I agree with kripken, and would in fact be hesitant to use even a layout engine distributed under a "weakly" copyleft license like the MPL in any of my projects, to say nothing of compatibility problems between copyleft licenses. I do not find Gecko "permissive enough in practice", and many others feel the same way.

I think the MIT/X11 License is an excellent choice.

[bstrie]

@apotheon Rust itself is planning to move from MIT to Apache License v2, due to the issue of protection from patents. Presumably that's now the other major contender for Servo's license, alongside MPL2. I'd also be interested to hear why you'd be hesitant to include weakly-copyleft code in any of your projects; MPL2 is (afaict) specifically designed to be used with proprietary projects, with its file-level licensing allowing it to be easily embedded and used alongside closed-source files as long as you make available any changes to the licensed files themselves.

[BrendanEich]

Also, MPL2 is compatible with GPL/LGPL, so I would like to hear of concrete problems of the "to say nothing of compatibility problems between copyleft licenses" kind.

/be

[BrendanEich]

@apotheon My last comment was for you -- MPL2 is compatible with GPL/LGPL, so is your objection simply to copyleft of any strength? If so, ASL2 is the front-runner as @bstrie notes. But if so, I'd like to hear more about why MPL2's weak copyleft is objectionable. Thanks,

/be

[apotheon]

The Apache License 2.0 is a pretty crummy license in general, and is not as permissive as people like to think. Apart from just general complexity, it also suffers from bookkeeping and project organization clauses, though I don't mind patent clauses at all. The only actually copyfree license I know that comes with a patent grant is the COIL, which is not the most widely used license in the world, though I'd use it if someone insisted on a patent clause just to avoid the restrictiveness of the ASL2.

I'm hesitant to use weakly copyleft licensed code in any of my projects mostly because of the increased compliance overhead involved in dealing with those licenses, the limitations it might impose on the more widespread use and distribution of my project because other people might avoid a partially copyleft project, and the general issues with license complexity that apply to all the popular copyleft licenses. I strictly stick to copyfree licenses for my own code, and copyleft licenses can make things difficult if I want to actually extend someone else's code when combining it with a project of mine (and I dislike throwing code into the black hole of copyleft licensing anyway). My dislike for copyleft licenses -- weak or strong -- has nothing to do with any desire to use others' code in commercial proprietary projects; I try to avoid contributing code to them, too, except on the rare occasion someone pays me a premium for transfer of copyright on contract work (and part of the reason for the premium they have to pay is that I prefer to discourage clients from keeping code I write closed).

As for the question about compatibility between copyleft licenses, the fact the MPL is friendly with the GPL is a matter of a specific exception being made. The MPL is not compatible with other copyleft licenses besides those maintained by GNU/FSF.

edit: license name superseded

[apotheon]

I also hear that the likely plan for Rust is not switching to AL2, but dual-licensing MIT/X11 + AL2 -- which isn't a bad idea, if you feel like you absolutely must have the Apache License 2.0 for some reason. If contributors are required to disjunctively dual license contributions that way, you get both the patent clause and the copyfree licensing option for downstream users.

[brson]

Rust relicensing is mostly complete, so it's time to start getting Servo sorted out.

Here is the minimum I intend to do:

• Add a LICENSE file to the main servo repo (likely MPL2)
• Come up with a standard license block, similar to Rust's, and put it on each file in the main servo repo

As far as sub-repos this is what I plan:

Classify each repo Servo uses as either servo-oriented, rust-oriented, or 3rd-party-oriented. servo projects (currently servo, servo-gfx at least) will use the Servo license, Rust projects will use the Rust license, 3rd-party projects and their bindings will use their own license. Currently there are 29 sub-repositories and most are bindings that I would classify as 3rd-party.

Servo projects will be set up like Servo, Rusty projects like Rust. Bindings to external libraries I will add a LICENSE file with the original library license, though I expect my licensing vigilance to wane the further I get away from core Servo code.

We've discussed adding an exception to Servo's license to allow code to be relicensed in the event it gets included in Rust, but if everybody agrees to license Rust projects and Servo projects differently then maybe we don't need those exceptions. We can be forward-thinking and do our prototyping of standard library features in subrepos that already carry the right license. Also, all Servo code is still written by MoCo employees and that will probably remain true for the next year at least. I think I prefer to avoid tacking on our own language to the license (though I made a big deal about it earlier).

For the heck of it, here is how I would classify (and license) our current subrepos:

3rd-party (other license)

src/libcss (remotes/mozilla-servo/master) src/libhubbub (heads/master) src/libparserutils (heads/master) src/libwapcaplet (heads/master) src/mozjs (heads/master) src/rust-azure (remotes/origin/HEAD) src/rust-cairo (remotes/origin/HEAD) src/rust-fontconfig (remotes/origin/HEAD) src/rust-freetype (remotes/origin/HEAD) src/rust-harfbuzz (heads/master) src/rust-http-client (remotes/origin/HEAD) src/rust-hubbub (heads/master) src/rust-mozjs (remotes/origin/HEAD) src/rust-netsurfcss (remotes/mozilla-servo/master) src/rust-stb-image (remotes/origin/HEAD) src/rust-wapcaplet (remotes/origin/HEAD) src/rust-xlib (remotes/origin/HEAD) src/skia (remotes/origin/master)

Rust (MIT/ASL2) license

src/rust-cocoa (remotes/origin/HEAD) src/rust-core-foundation (remotes/origin/HEAD) src/rust-core-graphics (remotes/origin/HEAD) src/rust-core-text (remotes/origin/HEAD) src/rust-geom (remotes/origin/HEAD) src/rust-glut (remotes/origin/HEAD) src/rust-io-surface (remotes/origin/HEAD) src/rust-layers (heads/master-3-geb86bb0) src/rust-opengles (remotes/origin/HEAD) src/sharegl (remotes/origin/HEAD)

Servo license

src/rust-css (remotes/origin/HEAD)

The only one I might prefer the Servo license for is rust-css. This is a generic library for parsing and selector matching. It is currently a wrapper around libcss, but it is intended to be rewritten completely in Rust someday.

[apotheon]

Why MPL, exactly?

[steveklabnik]

Has any progress been made on this front? I'm curious.

[brson]

@steveklabnik No progress.

[mindcrime]

I'd love to see Servo go with a license that's A. OSI approved, B. reasonably well known and widely adopted, so that it's implications are well understood, and C. fairly permissive. IMO, the ASLv2 would be a pretty good choice, as would the new BSD license, or the MIT license.

The MPL isn't bad per-se, but I feel like it's a license that not a lot of people understand really well, so I would not put it real high on the list personally.

Anyway, anything but the CPAL, or the AGPL or some obscure license that's only used by like 2 other projects in the world... :-)

[timkuijsten]

+1 for extra overhead when including work with more complex licenses than MIT/BSD like apotheon mentions.

It's often a one-way road when including work with a less permissive license which can feel a bit unfair and is often explained in the media "the wrong way" (like "Apache OpenOffice (AL2) won't allow inclusion of LibreOffice code (LGPLv3)").

In light of Mozilla's "Doing good is part of our code" I would suggest the shortest, simplest and most permissive license possible, that will add the least (no) overhead to those that include this code.

@apotheon Never heard of this Tesla or COIL license before but it looks really interesting as a MIT alternative with patent clause.

From https://www.wikivs.com/wiki/Apache_License_vs_COIL#Comparison:

The intended applicability of the AL2 is manifest in its specific reference to "software source code, documentation source, and configuration files" as well as "compiled object code" in its Definitions section, in addition to reference throughout the license text to the words "Source" and "Object" in whose definitions such phrases appear. This specificity of applicability to software projects and to related materials (software documentation and configuration files) may prove problematic in establishing grant of license for use of part or all of the covered work within derivative, non-software works.

By contrast, the COIL contains no text establishing such specificity of application to particular types of copyrightable work, making it likely suitable for works of significantly greater range and variation.

[brson]

I've started on this.

In all servo repositories that are not simply forks of an upstream project I have done one of two things:

In some projects I've added a LICENSE file containing the text of the MPL2. The main repository, rust-azure, rust-cairo, rust-css, rust-mozjs are licensed this way, either because their upstreams are MPL or because they are core parts of servo.

To the remaining repositories without preexisting licenses I've added a COPYING file containing the following text.

Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
<LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
option. All files in the project carrying such notice may not be
copied, modified, or distributed except according to those terms.

Plus the LICENSE-APACHE and LICENSE-MIT files. This is the same licensing as Rust.

Next I'll contact non-moco contributors to all repos and get them to send me an email explicitly licensing their code under the relevant terms. Then I will add a tidy script to our build process that verifies that all source files have the proper header, then add all the missing headers.

[apotheon]

So . . . dual-licensed MIT/X11 License and Apache License 2.0. I find this encouraging (mostly because of the MIT/X11 License option). Thanks for your efforts, brson.

[brson]

@apotheon Only some parts of servo are MIT/APL2. The engine itself, the code in the main repo is MPL2.

[apotheon]

Oh, crap. Well . . . good luck, I guess. I'll have to find what I need elsewhere.