Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Licensing of Mozilla website code

40 views
Skip to first unread message

Jeff Balogh

unread,
Jan 14, 2010, 3:16:31 PM1/14/10
to le...@lists.mozilla.org
Greetings all,

Over in webdev, we've been having some unproductive arguments over how
our website code should be licensed. I'm hoping this list will be
able to enlighten us.

The repo in question is http://github.com/jbalogh/zamboni/, the new
version of addons.mozilla.org. Bug 539671 asks that we add a license
to that repository.

I'd like to license our web code under a simple, permissive license
like the BSD. I find clause 3.5 of the MPL, which requires a
duplicate of the license text in every source file, onerous and
fatiguing in our repositories. We create a lot of small files with
code or templated HTML, and often the 40 lines of boilerplate license
outweighs the lines of code. Even with large files, the first thing I
invariably see when opening a file is a full screen of license. I can
try to hide it with my text editor, but I look at our code in more
than just a text editor. Sometimes I work with it on the command
line, often I look at it through a web interface, and hiding the
license for myself doesn't help all the other people who look at our
code.

It feels slightly trivial to complain about 40 lines so much, but I
think the developer ergonomics of confronting the license at every
turn are poor.

In addition, the community we're working with uses and shares
primarily BSD-licensed packages. I'm not sure if there are any
restrictions to importing MPL code into a mostly-BSD codebase, but I'd
like to make our interactions with them as smooth as possible. Advice
on this point would be appreciated.

I'm not completely clear why our Mozilla product code is under the
tri-license, but I have a feeling that it's not as relevant in our
webdev environment. The code that makes up a complete website is
typically only run by us, but we share basic packages with the
community. Our websites won't be distributed with any operating
systems, and if parts are used in a corporate setting, I don't mind.

I don't think our circumstances call for the MPL or the tri-license,
but I'd like to make sure other parts of Mozilla are comfortable with
this.

Thanks,
Jeff Balogh

p.s. If you're curious, we're working on github because:

* we like the interface
* it's fun to interact with the greater open-source community on github
* IT doesn't have git hosting set up on mozilla servers

Benjamin Smedberg

unread,
Jan 14, 2010, 3:53:15 PM1/14/10
to
On 1/14/10 3:16 PM, Jeff Balogh wrote:

> I'd like to license our web code under a simple, permissive license
> like the BSD.

I don't have any authority in the matter, but I approve! I think all of our
non-product code should be BSD-licensed unless there is a strong reason not to.

--BDS

timeless

unread,
Jan 14, 2010, 4:22:34 PM1/14/10
to le...@lists.mozilla.org
Jeff wrote:
> I'm not sure if there are any
> restrictions to importing MPL code into a mostly-BSD codebase, but I'd
> like to make our interactions with them as smooth as possible. Advice
> on this point would be appreciated.

in general i don't think there are any real problems with doing so,
other than that a file or its contents will carry MPL and whatever
lifespan requirements for delivery of code and attribution from MPL
will apply for those files.

> I'm not completely clear why our Mozilla product code is under the
> tri-license, but I have a feeling that it's not as relevant in our
> webdev environment.

I'm not sure if you want an answer or not. There are probably books on
it :). In short MPL was to keep the product alive, enable it to be
integrated into other places and get changes made by companies to be
contributed to the public (this includes a change made by e.g.
Netscape or Nokia to a Mozilla file that's under MPL), but without
preventing them from adding extras (AOL IM support) through a
restrictive license.

The LGPL/GPL story was roughly because a certain group of people
claimed that MPL wasn't compatible and therefore insisted that we
change somehow (I'm pretty sure they'd have preferred for us to
replace MPL with LGPL or GPL, but this didn't sit well with the
Mozilla community [I count myself amongst that group, and I'm sure it
included certain corporations at that time]), the dual licensing and
later tri licensing was a compromise to enable groups using GPL and
later LGPL code to integrate Mozilla code without having to play
license games (mozilla.org paid instead).

> The code that makes up a complete website is
> typically only run by us,

I'm not sure your assumptions are correct:
http://addons.songbirdnest.com
https://extensions.flock.com/

> but we share basic packages with the
> community. Our websites won't be distributed with any operating
> systems,

I'm always amazed by which things are bundled into packages. Bugzilla
is available in package form for iirc both RedHat. Although perhaps it
depends on how one defines 'distributed', let's not go there :).

> and if parts are used in a corporate setting, I don't mind.

:)

> I don't think our circumstances call for the MPL or the tri-license,
> but I'd like to make sure other parts of Mozilla are comfortable with
> this.

I believe we've used MIT licensing for sample code. (And I like this.)

We're certainly fine with pulling in BSD licensed content. I find
nothing wrong with producing it. Breakpad is New BSD and we do work
with and contribute to it.

While in certain circumstances I find MPL to be a nice balance, I'm
quite happy with MIT/BSD for other things and would be happy to see
your project using it.

The advantage of MPL for a thing like Bugzilla is that if a group
(mozilla) develops a product (Bugzilla), and another group takes it
and develops it further (IssueZilla/Bugopollis?) and sells it to
clients (where the clients run the product), then the clients are
still able to take the modifications to the product core and
contribute them back upstream (to mozilla/bugzilla.org).

If you don't expect such an ecosystem, or don't worry that someone
might fork in some annoying way (and issuezilla was indeed an annoying
fork, which while the MPL enabled us to get the source, we were unable
to get anything useful from it), then relying on MPL doesn't make
sense. The one benefit of MPL's per file license was that in theory if
someone decides they don't want to write MPL code, so they stick it
into other files, they'd have to write MPL'd APIs to integrate their
non MPL code, and ideally *those* apis would be beneficial to us and
others. But I've never seen anyone write decent APIs this way, so it's
just a failed pipe dream.

Gervase Markham

unread,
Jan 15, 2010, 10:39:24 AM1/15/10
to Jeff Balogh
On 14/01/10 20:16, Jeff Balogh wrote:
> Over in webdev, we've been having some unproductive arguments over how
> our website code should be licensed. I'm hoping this list will be
> able to enlighten us.

Thanks for dropping in. You are in the right place :-)

> I'd like to license our web code under a simple, permissive license
> like the BSD. I find clause 3.5 of the MPL, which requires a
> duplicate of the license text in every source file, onerous and
> fatiguing in our repositories.

I agree entirely. If the MPL is ever revised, this will be one of the
first things to be fixed.

> In addition, the community we're working with uses and shares
> primarily BSD-licensed packages. I'm not sure if there are any
> restrictions to importing MPL code into a mostly-BSD codebase, but I'd
> like to make our interactions with them as smooth as possible. Advice
> on this point would be appreciated.

Here's the advice: you cannot import MPLed code into a BSD-licensed
codebase if you want the result to be BSD-licensed. And I suspect that
third party libraries would not appreciate the additional licensing
complexity of having some of their code MPL and the rest BSD. However,
if you know who the copyright owners are and have their permission, then
of course you can copy it over. And I'd expect changes made directly to
those packages to be made BSD to start with (and our licence policy is
cool with that - point 4).
http://www.mozilla.org/MPL/license-policy.html

> I'm not completely clear why our Mozilla product code is under the
> tri-license,

Because we started with the MPL, and then wished to add GPL
compatibility without losing copyleft (which we would have done if we'd
switched to BSD to achieve that goal).

I myself think that having a copyleft licence is an important community
norms statement, even if it's possible to dodge the copyleft. Mozilla
expects you to share your changes - and if you don't, using some
licensing wrinkle to get out of it, we don't appreciate it.

Of course, in the case of a web app, no copyleft short of the Affero GPL
can _require_ people to publish their changes to server-side code. So
most copyleft licences we might choose for webapp code would fall into
that "norms statement" category.

> but I have a feeling that it's not as relevant in our
> webdev environment. The code that makes up a complete website is
> typically only run by us, but we share basic packages with the
> community. Our websites won't be distributed with any operating
> systems, and if parts are used in a corporate setting, I don't mind.

Please don't confuse "copyleft" with "non-commercial" or
"non-corporate". No open source licence has any restriction on using the
code "in a corporate setting".

> I don't think our circumstances call for the MPL or the tri-license,
> but I'd like to make sure other parts of Mozilla are comfortable with
> this.

Some more thoughts, on the way to an opinion:

The Mozilla codebase itself uses a number of BSD-licensed libraries
without feeling the need to itself be BSD. (That's the way BSD is
supposed to work.) And if we change those libraries, we licence our
changes under the licence of the original library. So the fact that we
are using BSD libraries in a web app isn't itself, IMO, an argument for
making the web app BSD too.

On the other hand, if we were writing a Perl module, we would tend to
make it available under the standard licence for Perl (Artistic/GPL
dual) because that's the standard the Perl community uses.

I'd like to hear what you think of all the above before going on :-)

> p.s. If you're curious, we're working on github because:

I am curious; I hope you will forgive further questions :-)

> * we like the interface
> * it's fun to interact with the greater open-source community on github

Is this like what I once described as "the sort of geek fellowship that
comes from concentrating very hard on your own code in the presence of
other people", or are there features of github which connect projects
together in some way? I must confess, I'm not familiar with them.

> * IT doesn't have git hosting set up on mozilla servers

What features does git have which hg does not have that lead to point 3)
being a different point to points 1) and 2) (if you see what I mean)?

(As a side note, I don't think much of the argument (from bug 539671):
"This isn't in a 'mozilla.org' repository right now, so the rules don't
technically apply." While the rules are phrased in terms of
"mozilla.org-hosted code", what was really meant was
"mozilla.org-originated projects". The recent appearance of such
projects on other hosting services means that distinction is now
relevant, when it wasn't before. We work very hard to have "code which
comes out of the Mozilla project" have a consistent licensing story, and
the license policy is a means to that end.)

Gerv

Jeff Balogh

unread,
Jan 15, 2010, 2:07:22 PM1/15/10
to le...@lists.mozilla.org
On Fri, Jan 15, 2010 at 7:39 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 14/01/10 20:16, Jeff Balogh wrote:
>> In addition, the community we're working with uses and shares
>> primarily BSD-licensed packages.  I'm not sure if there are any
>> restrictions to importing MPL code into a mostly-BSD codebase, but I'd
>> like to make our interactions with them as smooth as possible.  Advice
>> on this point would be appreciated.
>
> Here's the advice: you cannot import MPLed code into a BSD-licensed
> codebase if you want the result to be BSD-licensed. And I suspect that
> third party libraries would not appreciate the additional licensing
> complexity of having some of their code MPL and the rest BSD. [...]

From this, and the talk of using the community-standard Perl licensing
below, I think we're in agreement that small components extracted from
our site should be licensed so that they play well with the larger
community. In this case, the Python community prefers BSD, so making
our libs BSD would be the best choice.

>> I'm not completely clear why our Mozilla product code is under the
>> tri-license,
>

> Because we started with the MPL, and then wished to add GPL
> compatibility without losing copyleft (which we would have done if we'd
> switched to BSD to achieve that goal).
>
> I myself think that having a copyleft licence is an important community
> norms statement, even if it's possible to dodge the copyleft. Mozilla
> expects you to share your changes - and if you don't, using some
> licensing wrinkle to get out of it, we don't appreciate it.

I'm not a fan of copyleft licenses; this "Maximal Usage Doctrine" sums
up my feelings surprisingly well:
http://yehudakatz.com/2010/01/05/the-maximal-usage-doctrine-for-open-source/

I hope we can agree to disagree on this point, or at least keep any
argument threads off of this list. :)

> Of course, in the case of a web app, no copyleft short of the Affero GPL
> can _require_ people to publish their changes to server-side code. So
> most copyleft licences we might choose for webapp code would fall into
> that "norms statement" category.
>

>> but I have a feeling that it's not as relevant in our
>> webdev environment.  The code that makes up a complete website is
>> typically only run by us, but we share basic packages with the
>> community.  Our websites won't be distributed with any operating
>> systems, and if parts are used in a corporate setting, I don't mind.
>

> Please don't confuse "copyleft" with "non-commercial" or
> "non-corporate". No open source licence has any restriction on using the
> code "in a corporate setting".

I haven't experienced it firsthand, but from what I hear on the
internet, many corporate environments avoid copyleft because they fear
the viral license. The license itself doesn't preclude commercial
usage, but the untested implications are enough to rule out copyleft
code.

What I was trying to say, though, was that I don't mind if someone
uses our code without contributing improvements back. I'd prefer to
get fixes, of course, but I trust that most people would give back
without a license forcing their hand.

>> I don't think our circumstances call for the MPL or the tri-license,
>> but I'd like to make sure other parts of Mozilla are comfortable with
>> this.
>

> Some more thoughts, on the way to an opinion:
>
> The Mozilla codebase itself uses a number of BSD-licensed libraries
> without feeling the need to itself be BSD. (That's the way BSD is
> supposed to work.) And if we change those libraries, we licence our
> changes under the licence of the original library. So the fact that we
> are using BSD libraries in a web app isn't itself, IMO, an argument for
> making the web app BSD too.
>
> On the other hand, if we were writing a Perl module, we would tend to
> make it available under the standard licence for Perl (Artistic/GPL
> dual) because that's the standard the Perl community uses.
>
> I'd like to hear what you think of all the above before going on :-)

I think our reasonable options are:

1) license the full website as MPL, but split off small packages as BSD
2) license the website and smaller packages as BSD

I lean toward (2) through personal bias, but can rationalize it.
Since the MPL doesn't enforce copyleft for website code, we're not
gaining anything technically, though we are advertising the idea that
we'd like contributions back. I think a BSD license advertises the
same idea, and using BSD everywhere avoids the hassle of complying
with the MPL, and of relicensing packages if we'd like to release them
separate. Full BSD also allows people to take pieces that we haven't
specifically packages and use it within their BSD projects.

I also feel that the Python web community would appreciate full-BSD
more than semi-BSD. There was a web kerfluffle a few months ago when
someone released GPL packages that built on top of the BSD web
framework we're using. Many people felt it was unsporting to release
a viral package that they couldn't use in their BSD code.

So, that's what I've gathered from this thread so far. And now for
something completely different:

>> p.s. If you're curious, we're working on github because:
>

> I am curious; I hope you will forgive further questions :-)

>> * we like the interface
>> * it's fun to interact with the greater open-source community on github
>

> Is this like what I once described as "the sort of geek fellowship that
> comes from concentrating very hard on your own code in the presence of
> other people", or are there features of github which connect projects
> together in some way? I must confess, I'm not familiar with them.

I think the community feel comes from the former; lots of us are on
there publishing code, using other projects hosted on github, and you
get the feel of contributing to something bigger than whatever project
you're working on.

github also makes it easier to discover and keep up with an
open-source project than something like hg.mozilla.org. If someone
says "get redis from github", I know immediately where I can check out
the project, and I can subscribe to feeds from redis or a feed of
everything that the author of redis publishes. github in itself isn't
the critical part, but it sets a standard way of watching and
collaborating with other developers.

>> * IT doesn't have git hosting set up on mozilla servers
>

> What features does git have which hg does not have that lead to point 3)
> being a different point to points 1) and 2) (if you see what I mean)?

I don't think I see what you mean, but if you can clarify we should
probably continue that discussion off-list. :)

> (As a side note, I don't think much of the argument (from bug 539671):
> "This isn't in a 'mozilla.org' repository right now, so the rules don't
> technically apply." While the rules are phrased in terms of
> "mozilla.org-hosted code", what was really meant was
> "mozilla.org-originated projects". The recent appearance of such
> projects on other hosting services means that distinction is now
> relevant, when it wasn't before. We work very hard to have "code which
> comes out of the Mozilla project" have a consistent licensing story, and
> the license policy is a means to that end.)

Yes, that was a weaselly tongue-in-cheek suggestion. I'm here now, so
hopefully you can forgive it.

Axel Hecht

unread,
Jan 15, 2010, 4:06:07 PM1/15/10
to
Jumping in here with my own 2cts, developing some django-based website
ourselves.

With django, a well-designed site should be composed of a bunch of
modules (called apps in django jargon). Filled with optimism, those
should serve generic purposes, or at least be adaptable to a different
use case on a different site. The code-interchange is largely based on
the "new bsd license"

So, folks could use amo applications together with their own project and
some other apps and tweaks and create a spin-off for gecko extensions or
some other extension mechanism.

I recall talking to Mitchell at one point of BSD vs MPL for real code,
and her key-argument was patent-protection that the MPL had on top. Not
sure how essential that is in this context.

As a side tangent, is there any relation between the licensing of code
that's running a website and the resulting website? In our case, we'd
aggregate data from bugzilla, hg.m.o, self-hosted database content, and
templates under the code license to create ... ? No idea.

I'm commonly using the network diagram feature to keep track of a DVCS
network, and only github offers that at this time. That is totally
independent of the DVCS, it's just that nobody has hacked up that
feature. See http://github.com/djmitche/buildbot/network for an example.

When talking hg, the tools offered on bitbucket still win over what we
have on hg.m.o in that they at least show who's having clones, even if
they're not able to connect the histories.

Axel

John J Barton

unread,
Jan 15, 2010, 5:07:50 PM1/15/10
to
Jeff Balogh wrote:
...

>> Please don't confuse "copyleft" with "non-commercial" or
>> "non-corporate". No open source licence has any restriction on using the
>> code "in a corporate setting".
>
> I haven't experienced it firsthand, but from what I hear on the
> internet, many corporate environments avoid copyleft because they fear
> the viral license. The license itself doesn't preclude commercial
> usage, but the untested implications are enough to rule out copyleft
> code.

Use of GPL or LGPL is not such a big issue in corporations I am familiar
with (IBM and HP). Redistribution is completely another matter.
Developers, because they may someday work on product code, generally
avoid messing with GPL source. I am able to work on Firebug because it
is BSD; I'm not sure I have enough patience to talk with lawyers about
MPL; I'm sure I don't for GPL.

jjb

Wil Clouser

unread,
Jan 27, 2010, 1:53:02 PM1/27/10
to
On Jan 15, 2:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Jeff Balogh wrote:
>
> ...
>

Thanks for your feedback, everyone. I haven't heard any concrete
objections (and several cases of support) to us licensing website code
under the BSD so we'll pursue that option for the new AMO.

Thanks,

Wil

Axel Hecht

unread,
Jan 30, 2010, 5:06:29 AM1/30/10
to

Ben Bucksch

unread,
Apr 8, 2010, 8:09:59 PM4/8/10
to jba...@mozilla.com
On 14.01.2010 21:16, Jeff Balogh wrote:
> The repo in question is http://github.com/jbalogh/zamboni/, the new
> version of addons.mozilla.org...

> I'd like to license our web code under a simple, permissive license
> like the BSD...

> I don't think our circumstances call for the MPL or the tri-license,
> but I'd like to make sure other parts of Mozilla are comfortable with
> this.

Sorry for jumping way too late into the thread, and the question is
probably already all over, but:

There's very little point in using MPL for website code. Most
open-source licenses allow the user of the code to do with it whatever
he wants, on his own systems. The "share alike" requirements only come
into effect when you start to distribute it. GPL is very explicit about
that, and the MPL is also like that.

However, that's toothless for website code, because the "user" is the
company, the code only runs on their servers. The end-users, the
website-visitors, are not users in the sense of the license. That's an
older debate, and that annoyed many GPL people, and that's why there's
the "Affero GPL" license (or "GNU AGPL v3" from the FSF).

So, either do Affero GPL or BSD. MPL is pointless for licensing websites.

0 new messages