Re: Licensing of Mozilla website code

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=543181 on our code.

Axel

On 15.01.10 22:06, Axel Hecht wrote:
> 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