Re: Licensing of Mozilla website code

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.

On 15.01.10 16:39, Gervase Markham wrote:
> 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.
>

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