On Fri, Jan 15, 2010 at 7:39 AM, Gervase Markham <[email protected]> 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. _______________________________________________ legal mailing list [email protected] https://lists.mozilla.org/listinfo/legal
