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. _______________________________________________ legal mailing list [email protected] https://lists.mozilla.org/listinfo/legal
