Re: Using MPL covered components in application
Marko Lahtinen wrote: Im thingking about using a component, which is released under MPL, in my commercial application. The component I intend to use is not modified. Can I use the component without making my application open source and what other things I need to consider ? The MPL is a file-level copyleft. If by not modified you mean you've added entire untouched files then you don't have to make the rest of your app open source, you only have to worry about the notification requirements. If you incorporate part of an MPL'd file into another file you need to publish that entire file as a Modification, but not other files which are wholly your own. Keep your life simple and don't mix Mozilla code and yours in the same files. If you can avoid creating a Modification (http://www.mozilla.org/MPL/MPL-1.1.html#1.9) then you only need to worry about the notification requirements for Larger Works (section 1.7 and 3.7). The most relevant bit will be section 3.6, Distribution of Executable Versions, where you need to say that you incorporated source code available under the MPL and where to get it. The notice needs to be in the executable and anywhere else (documentation?) where you describe recipients' rights relating to the Covered Code. Most projects have interpreted that to mean anywhere you put a copyright notice for your program. If this is a commercial product you should run this by your lawyer (I am a developer), but several large commercial product have shipped based on Mozilla code that incorporate proprietary (non-open source) software. The most obvious example is Netscape. -Dan Veditz ___ mozilla-license mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-license
Re: mfcembed license?
The licenses used in Mozilla apply to individual source files; a person distributing mfcembed would have to comply with the union of requirements. For practical purposes that would mean you'd only have to worry about the MPL terms (the tri-license headers give you a choice of license terms, I assume you'd choose the least restrictive). Chak should have used the Mozilla Public License instead of NPL for new code, but it's possible those files were derivatives of code elsewhere in the tree in which case he would have to keep the original license. That would also explain why those files are not instead under the MIT-like license used in some of the other files. -Dan Veditz Per Lundberg wrote: Hello, I asked in another group but this is probably a better place. What is the intended license of the mfcembed program? In mfcembed.cpp I see this: * Permission is hereby granted, free of charge, to any person obtaining a * copy of this Mozilla sample software and associated documentation files * (the Software), to deal in the Software without restriction, including * without limitation the rights to use, copy, modify, merge, publish, * distribute, sublicense, and/or sell copies of the Software, and to permit * persons to whom the Software is furnished to do so, subject to the * following conditions: * * The above copyright notice and this permission notice shall be included * in all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS IN THE SOFTWARE. In other words, a standard MIT license. But some other files in the same directory, even files written by the same person, look like this: * Version: NPL 1.1/GPL 2.0/LGPL 2.1 * * The contents of this file are subject to the Netscape Public License * Version 1.1 (the License); you may not use this file except in * compliance with the License. You may obtain a copy of the License at * http://www.mozilla.org/NPL/ * * Software distributed under the License is distributed on an AS IS basis, * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License * for the specific language governing rights and limitations under the * License. * * The Original Code is mozilla.org code. * * The Initial Developer of the Original Code is * Netscape Communications Corporation. * Portions created by the Initial Developer are Copyright (C) 1998 * the Initial Developer. All Rights Reserved. * * Contributor(s): * Chak Nanga [EMAIL PROTECTED] * * * Alternatively, the contents of this file may be used under the terms of * either the GNU General Public License Version 2 or later (the GPL), or * the GNU Lesser General Public License Version 2.1 or later (the LGPL), * in which case the provisions of the GPL or the LGPL are applicable instead * of those above. If you wish to allow use of your version of this file only * under the terms of either the GPL or the LGPL, and not to allow others to * use your version of this file under the terms of the NPL, indicate your * decision by deleting the provisions above and replace them with the notice * and other provisions required by the GPL or the LGPL. If you do not delete * the provisions above, a recipient may use your version of this file under * the terms of any one of the NPL, the GPL or the LGPL. So, which goes? The MIT license is far less restrictive than even the LGPL and I think this may be what the authors intended... but the current situation (in my 1.2.1 tree) is a bit unclear. Any clues?
Re: MPL Plain English question
Gervase Markham wrote: I can distribute my compiled executable as public domain, freeware, shareware, commercial etc. I am not required to release my source code, and I'm not required to make mention anywhere in the executable or related documentation that it uses the JEDI library. So, is my interpretation correct? No, on that last point. 3.6. Distribution of Executable Versions. You may distribute Covered Code in Executable form only if [...] You include a notice stating that the Source Code version of the Covered Code is available under the terms of this License [this is the key bit], including a description of how and where You have fulfilled the obligations of Section 3.2 [which you don't need to do, because you have no obligations under Section 3.2]. So, you need to include a notice stating that the Source Code version of the Covered Code is available under the terms of this License. It doesn't state it explicitly, but it would make sense to include a pointer to where the Covered Code is available. Politeness also suggests that the notice appear in your About box or somewhere similar, rather than on page 362 of the manual. Gerv stopped quoting 3.6 too early, it's not mere politeness that suggests your About box or the like: The notice must be conspicuously included in any notice in an Executable version, related documentation or collateral in which You describe recipients' rights relating to the Covered Code Copyright statements, such as those which typically appear in About boxes, are a way of telling users what their rights are in the code so that is where this notification should go. conspicuously -- not page 362. -Dan Veditz
Re: Open-Source Licenses Anonymity
Matt Aaronson wrote: Hi! I am interested in writing a program and releasing it under an open-source license (possibly the MPL), but, for various reasons, want to release it anonymously. I cannot put it into the public domain, since I am using a library that has a GPL-like license that requires a program that uses it to use a license that is open-source and imposes the same license on people that make modifications of it. Actually you *could* put it in the public domain, and you *can't* put it under the MPL if the library you're using is GPL. You said GPL-like, though, so no one can say for sure without knowing what the other license is specifically. -Dan Veditz
Re: Netscape legal trickery?
andkonDOTcom wrote: Gervase Markham [EMAIL PROTECTED] wrote in message news:b0geso$[EMAIL PROTECTED]... andkonDOTcom wrote: http://www.andkon.com/stuf/mozilla3/ Okay read specifically the section Netscape Fraud where I ramble about the Netscape license. I understand the Netscape License to mean that they do not have to release some part of modified code as open source. It means if Netscape, for example, included the JavaScript engine in a server product, they would not have to open source any part of that server product. However, the NPL exceptions have no real impact on Mozilla development today, because there is so much MPLed code in the tree that Netscape would probably have great difficulty extracting a large enough NPLed piece to be useful in something else. It's not the technical implications but the legality of it. I can't just drive thru the red light because no cars are coming. As such, Netscape should include its open source code. However, it seems from the Netscape 1.1 license that Netscape for some magical reason does not have to obey this. Netscape developed the NPL and MPL licenses in parallel. Code originally donated by Netscape got the Netscape PL, and the MPL was for use by non-Netscape contributors who didn't particularly want to give Netscape special rights. Netscape did not simply change the license on Mozilla code, no one but the author can change the license on previously donated code. In fact, Netscape authorised mozilla.org to change the license of the code it authored from NPL to MPL after the two year special rights clause expired, and Netscape employees are instructed to apply the Mozilla license to new files rather than the Netscape license. This is the reverse of what your site appears to believe. -Dan Veditz
Re: My review of RealNetworks' RPSL
Ben Bucksch wrote: RelNetworks today released Helix DNA https://www.helixcommunity.org, Thanks for the announcement and review, Ben. * It has the same problem as the MPL in that it grants no trandemark and patent rights, not even those of the Licensor (as I understood), The MPL does grant patent rights, at least to the extent required to use the contributed code: 2.1b and d (2.2b and d for contributors)
Re: Licensing and larger work
Calvin Chin wrote: Thanks for the clarification. Does your company at least agree with your opinion - in other words, have they ever asked anyone to stop distributing closed source products with unmodified Rhino? We know of several companies using either Rhino or Spidermonkey (the C version of the JS engine) in commercial products and think it's great. We wouldn't ask someone to stop using it, we'd ask them to comply with the license and the terms are easy to comply with. I haven't heard of any cases where mozilla.org has had to ask for changes, but that would be a better question for [EMAIL PROTECTED] It's possible that kind of thing would be handled quietly so as not to cause trouble for a company whose infringement was unintentional and quickly fixed. -Dan Veditz
Re: Localizing Netscape 7.0
I have forwarded this to folks within AOL and it has re-sparked a discussion about this. Sounds like everyone is pretty positive on allowing this, but the inherent reluctance of the lawyers must be overcome. -Dan Veditz Andras Timar wrote: Hi, There is a thread in n.p.m.l10n which rather belongs to here. Let me summarize shortly what was going on so far. I coordinate the Mozilla localization effort to Hungarian language. Hungarian users would like to use localized Netscape 7.0, too.I thought it was easy to fulfil this requirement, because NS 7.0 is based on the already translated Mozilla 1.0.1 and the differences are minor. Basically we were to release Hungarian NS 7.0 language pack and install kits in two weeks. Then I read the EULA of NS 7.0 which says: ...Licensee may not: (i) modify or create any derivative works of the Product or documentation, including customization, translation or localization;... I joined to the Browser Distribution Program of Netscape, but that license says something similar, ie. it also did not permit translation (except code based on open source). This means IMHO that I can translate everything but AIM, P3P and other add-ons that does not exist in Mozilla. But if the users did not want AIM and the other Netscape improvements, they could use Mozilla. IMHO not translating these add-ons make translation of Netscape pointless. Andrea wrote in n.p.m.l10n: Also, it looks to be -not a lawyer, not a competent spoken person, not a Netscape official representative-, if the license forbid to create and redistribute the Product modified, it doesn't stop you to create an add-on for the product. I see an installable lang pack as an add-on, is it can be another theme. I would be grateful, if some authoratitive person could give me a hint, links, or anything else that helps me to answer the question: is there a legal way to fully localize NS 7.0? Thanks, Andras
Re: License question Rhino NPL
You may use and distribute js.jar as long as you follow the terms of the license. If you're shipping a commercial product it would be a good idea to have your lawyer look it over, but the terms should be pretty clear. Since you won't be modifying any source you will mostly be concerned with the notification requirements (section 3.6). Mainly you have to tell people your product includes some Rhino code, that the source code for the Rhino part is available under the NPL license, and where folks can get it. There are no claims made on your code. That's considered a Larger Work. -Dan Veditz Peter wrote: The specific question I have involves Rhino 1.5R3 which is available under NPL 1.1 Part of Rhino 1.5R3 contains a JS.JAR file. Our developers would like to call the functions embodied by the JS.JAR file. The developers have no desire to modify the source code or even use the source code. The only use of the JS.JAR file is its functionality. The question is: may a commercial provider of software use the file and distribute it as part of its proprietary code without having to release the source code of its application or make it available to the public under an open source license? If so, will the developer's patent rights be affected in any way ?
Re: Comments on LGPL + any OSI licence exception clause.
The current working exception is: * As a special exception the copyright holders of this source file * also give you permission to include this file in a library with * any other source code that has been released under an Open Source * Initiative certificed licence. More information about OSI * certification can be found at: http://www.opensource.org Sounds great to me, but the Mozilla license is a more permissive one than the LGPL to start with. The audience here already thinks along these lines. -Dan Veditz
Re: Licensing
[EMAIL PROTECTED] wrote: I make a commercial application, this use mozilla embedded, need put source of mozilla in my cd distributation? If you're making a commercial app you've probably hired a lawyer, so it'd be worth your while to have him or her look over your obligations in the license. You need to make sure the source is available to your customers, and for my money putting a tarball on the CD is probably the simplest way -- no need to worry about running a web server for the specified time period. (speaking for myself, Netscape doesn't pay me enough to speak for them, I am not a lawyer, etc., etc.) -Dan Veditz
Re: plugin nss license question
RG wrote: Ok. Perfectly clear about shipping or not binaries. I have only one more question related to using NSS: if I understood right, the combination: plugin-is-only-using-NSS-library-binaries + not-shipping-NSS-binaries-myself does not demand me to release my plugin under any Mozilla license. Is that right? IANAL, but that would be my understanding of the situation you describe. That is, for example, how the Galeon project uses Mozilla. Even if you were shipping the NSS binaries yourself, as long as it was separate from your plugin the source distribution and license notification requirements, etc., would only apply to NSS. -Dan Veditz
Re: plugin nss license question
RG wrote: I have developed a plugin for Mozilla/Netscape that makes use of NSS libraries (nss and smime). The plugin is gonna be free distributed. I am not gonna distribute NSS libraries. I have a couple of questions: - A general one: does a plugin for Mozilla/Netscape need to be released under any license ? If you don't incorporate any Mozilla code you can use any license you want. Your choice of license will depend on whether you wish to share your code with others and under what terms. - NSS libraries (binaries) can be found with latest Mozilla releases. That is not the case with Netscape (6.2 for example). If some people that wants to make use of my plugin only have Netscape (6.2 for example) installed, is there any license-problem for them if they get the nss library binaries from Mozilla ? Or should I release the plugin together with nss binaries for those not having them ? If you ship the NSS binaries yourself you must meet the distribution requirements of the license even if you're not modifying them (mainly telling your users you're including NSS, that it's MPL'd, and where they can get the source -- but see the license for the legal details). There's no problem if you send Netscape users off to download something from the mozilla.org site. -Dan Veditz
Re: Freedom, NPL, and SeaMonkey 1.0
Christopher S. Charabaruk wrote: Okay, I see [NPL] listed there. Too bad [RMS] says not to use it. He says not to create new code and apply that license to it; he's not saying you have to stay away from Mozilla code under that license. Netscape itself tells people--including its employees--not to use the NPL for new code (not counting Modifications of existing NPL code, in which case the existing license must be honored). -Dan Veditz
Re: a basic question
[EMAIL PROTECTED] wrote: I've read the NPL/MPL but I still don't understand the basics: can anyone download Mozilla source, make some changes, rebuild the whole thing, make the binaries available on a different web site and sell them or give them for free? Yes. That's what Netscape does with our Netscape 6 product, for example. If so, what do you do with the modified source? I understand you have to make all the changed source files available for free, but if you have object files containing your new procedures called by the modified source, those object files you can copyright. Is that true? Yes. Again using Netscape 6 as an example, the Instant Messaging portion of that product is not open source, and the Netscape 6 package as a whole is copyright by Netscape and cannot be redistributed without permission even though it is built on redistributable Mozilla source. -Dan Veditz
Re: Freedom, NPL, and SeaMonkey 1.0
Christopher S. Charabaruk wrote: Stallman does? You're sure? I'd like to see the document that shows this. Ralph Mellor wrote: Stallman even lists NPL as a free license, and one of the mozilla faqs I read clearly states the deal on NPL relicensing.
Re: NPL/GPL supposed status of Mozilla
Nigel McFarlane wrote: I can't believe that referencing an un-dated URL (www.mozilla.org/MPL or /NPL) whose contents could change at any time is the same as including licenses with the source. There is no copy of the GPL or LGPL in the Mozilla source. (ok, there's a copy in various imported-but-separate libraries). Is there not a LICENSE file at the top of the source tarball? I don't know, I don't have a source release and don't at the moment have the bandwidth to check. The LICENSE and LEGAL files are checked out as part of a developer's tree so I'd be surprised if they weren't included with the source releases. If they're not there we're violating section 3.1 which says You must include a copy of this License with every copy of the Source Code You distribute. Not to worry, I doubt we'd sue ourselves. I'd recommend you double check, though, because I'm pretty sure you'll find the LICENSE file. If it's not there obviously we should fix it. -Dan Veditz
Re: Doubts on LGPL
Arnaldo Salaroli Rugai wrote: Hi all, Due my poor English a have been some doubts on LGPL. One of them is: If one translate the LGPL software into another language, the result must be a LGPL software too ? This newsgroup is mainly devoted to the Mozilla license. LGPL is quite different. However, your question is quite general and would apply to either license. For a real answer you'd have to ask a lawyer, but since courts have held that natural language translations of copyrighted works (e.g. a French version of Harry Potter) are derived works you could make a strong case that a computer language translation of a copyrighted program is a derived work, and if so it would be bound by the LGPL terms. There may be court cases that apply here, but not being a lawyer I don't know about them. -Dan Veditz
Re: MPL/NPL License
Krishnan Chellakarai wrote: Hi, We are planning to use NSS for Java libraries to achieve digital signing of HTML Form Fields. Can some one point me out, what are the steps we need to take care off, inorder for us to re-distribute those libraries. I read something about LEGAL file, do I need to worry about these. If so, can someone send me a sample of the LEGAL file. Thanks Krish. We tend to think the license itself spells out the steps you need to do. Any attempt by us to paraphrase it colloquially here would be incomplete and probably legally inaccurate by omission. As a non-lawyer I'd like not to be sued for dispensing bad legal advice. If there are specific points of the license you have questions on I'm sure several of us here will happily chime in with how we've interpreted those points in our own projects. -Dan Veditz (speaking as a fellow Mozilla hacker, not on my employer's behalf)
Re: Newbie question
Gervase Markham wrote: I would like to know if he could distribute Mozilla and which would be his obligations in the positive case. You need to read the MPL - http://www.mozilla.org/MPL . That outlines your obligations and rights. In the theoretical sense, yes, but in practice the Mozilla codebase is a mixture of different licenses and nowhere is it documented which parts of the codebase are under which license. -Dan Veditz
Re: Multiple Licencing language
Ben Bucksch wrote: Simon P. Lucy wrote: Yes no one will ever see it unless they do a listing output, but that isn't the point. As always the point is to unambiguously define the licence used. But to whom define, if only you will ever see it? It will end up with the current scheme: If you are sued, you claim that you used a particular license, but you cannot prove it. Of course you can! At the very least under both the MPL and the GPL if the distributed binary has any kind of a copyright notice it must tell users about the license and how to get the source. As a developer you've got to pick which set of notification rules you're going to follow, and which set of source distribution rules. from MPL 3.6 (Distribution of Executable Versions) You may distribute Covered Code in Executable form only if the requirements of Section 3.1-3.5 have been met for that Covered Code, and if You include a notice stating that the Source Code version of the Covered Code is available under the terms of this License, including a description of how and where You have fulfilled the obligations of Section 3.2. The notice must be conspicuously included in any notice in an Executable version, related documentation or collateral in which You describe recipients' rights relating to the Covered Code From Gpl 2c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Mitchell Baker wrote: The additional language was added so that recipients who receive a file can be sure they can use it under either license. This may sound silly, but a lot of those who might use Mozilla, especially companies with due diligence and risk analysis requirements, look for an explicit statemnt about the scope of the license they are using. The language I object to lets people turn the file into GPL only, there is no equivalent permission to turn the file into MPL only. How is this clarifying anything? There is at least one FSF-approved disjoint license (the license of Perl) that does not require permission to remove one of the licenses from the file in order to be able to use the code under the license of choice. -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Ben Bucksch wrote: Ian Hickson wrote: The term (as used by the FSF) is extremely well defined. The GPL is a license that ensures two things: a. Code covered by the GPL will be free. b. Code covered by the GPL won't be used with code that is not free. Not exactly. Code covered under the GPL can't be used with code that is not the *GPL* (or a subset of it). Otherwise, the list of licenses compatible with teh GPL would be identical to the list of Free Software licenses. It isn't, and the MPL unfortunately happens to fall in the category Free Software, but incompatible with the GPL. That's exactly what causes all this headache. That's why I think that the GPL is not at all extremely well defined. I'll let the lawyers quibble with whether the GPL is well defined, but you can't knock it on the above grounds. The GPL *must* limit combinations to licenses whose restrictions are a strict subset of its own, or else sneaky people could craft a license with which they could violate copyleft by putting impossible-to-meet extra restrictions on a critical file or two. It is probably legally impossible to define what kinds of additional restrictions would be acceptable and which aren't while still guaranteeing the goals of the GPL are met. Thus a large number of free licenses are incompatible with the restrictive GPL. -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Gervase Markham wrote: AOL needs the COOL code closed because it doesn't want people writing clients it can't control to access its service. AOL doesn't even trust Netscape with the source to the COOL components, we get binary drops. Anyway, I think it's safe to say that a switch to pure GPL is not on the cards. The most likely scheme is an MPL/LGPL/GPL tri-license - allow the code to be used by the GPL and LGPL free software communities (a good thing) while not shafting all the contributors who like using it under the MPL (also a good thing.) Note that there are at least two folks--Simon Lucy and myself--who object to specifics in the current proposal for dual licensing (though not the concept itself) on the same grounds that GPL zealots dislike non-GPL licenses. It would allow people to turn the code GPL-only and keep their improvements to Mozilla files unusable by mozilla.org -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: On Wed, 12 Sep 2001, Daniel Veditz wrote: I'm lost, what's important to you? On the long run, that everyone be allowed to do whatever they like with all their programs, including modifying them, etc. (Emphasis on everyone and all. Everything, except combine it with non-free code. Not having the concept of 'copyright' at all would satisfy this, by the way.) You must be joking... then companies would be even more secretive with their source code since they'd only have trade secret law to satisfy their desire for competitive advantage. And there would be *nothing* to stop a company from taking your free source and creating proprietary versions. At this stage, having seen what parts of Netscape 6.01 were not covered by the MPL, it is my belief that Mozilla could switch to the GPL without stopping Netscape. The majority of the proprietary changes are things that Netscape would be quite happy having other distributions use (e.g., keywords). The main exception would be the AIM code (the COOL components) which it would be hard to get under GPL... AOL has already used Gecko in its touchpad device, and Barry Schuler has commented in the press that they're looking at using Gecko in the main AOL client. I doubt AOL would contemplate opening their client source code. Lots of people use the javascript engine in otherwise proprietary projects, a switch to GPL would nix those folks. Ditto NSPR and NSS. If the GPL allowed combination with proprietary optional plugins like Flash and Java (which it doesn't) Netscape6 could probably get by if Mozilla were GPL. But Netscape6 isn't the only version of Mozilla code being used commercially. It was discussed, and using a BSD-like license was strongly favored by some. The semi-copyleft of the MPL seemed like a good compromise, allowing the Mozilla project the possibility of taking back improvements and ensuring some visibility if our code got incorporated into popular projects. A BSD-like license (or, for that matter, the public domain) would have been compatible with the letter of the GPL (if not the spirit)... Ah well. You'd trade less protection of the code for GPL compatibility? -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Frank Hecker wrote: IMO Section 3 was intended for a specific case, a case explicitly addressed in Section 3: This option [i.e., changing the license notices] is useful when you wish to copy part of the code of the Library into a program that is not a library. But IMO it's not a general requirement of the LGPL that this be done in all cases where works containing LGPLed code are distributed under GPL terms. We need to triple-license the code, MPL/GPL/LGPL. MPL/GPL won't allow LGPL libraries to incorporate some of our code without having to switch to GPL, and MPL/LGPL wouldn't work for GPL'd projects that want to take a subset of Mozilla's code that doesn't hang together as a library. -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Ben Bucksch wrote: My personal opinion is that the GPL was poorly designed, because I think that this very discussion should never have to happen. The GPL is, IMO, not as free as other licenses. Ssshh! The zealots might hear you! Using the word free in conjunction with the GPL is sure to lead to confusion and argument. The GPL is indeed very restrictive on developers (not free in that sense) in its attempt to preserve specific freedoms for the user/recipient of GPL'd programs (who might themselves be developers). In its attempt to prevent combinations with licenses that might subvert the intentions of the GPL it also sometimes prevents combination with licenses compatible in spirit like the MPL as a side effect. In a sense the GPL is allergic to the MPL, a mistaken immune response to something otherwise harmless. -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: On Wed, 12 Sep 2001, Frank Hecker wrote: Ian Hickson wrote: Why do we care about LGPL projects and not, say, projects using the original BSD license, the Apache license, the Zope license, the IBM public license, the Qt public license, the Sun Industry Standards Source License, etc, etc, etc? Because nobody has ever claimed that the BSD license, etc., are incompatible with the MPL. The BSD license, etc., are incompatible with the MPL. (In that you cannot cut and paste from one to the other, not in that you cannot link code from one with another.) You can create a larger work (executable or library) out of MPL code combined with code under pretty much any license. As long as you respect the MPL requirements for the MPL files and whatever requirements might be on the non-MPL files there are no problems. The MPL is compatible with licenses that allow this, so we don't need to make any special accomodations for BSD, Apache, etc. You cannot, however, combine MPL and GPL code into a larger work (according to the FSF), because the GPL makes claims on the entire work which cannot be satisfied while also satisfying MPL terms for the MPL code. OK. So then I say in turn that if the MPL is incompatible with the GPL then it must be incompatible with the LGPL as well [...]. This doesn't follow. The GPL and LGPL are totally different licenses. LGPL section 10 has the same You may not impose any further restrictions on the recipients' exercise of the rights granted herein clause that is claimed to be the source of our incompatibility with the GPL. For that matter, why do we want to promote _any_ non-strong-copyleft projects, other than Mozilla itself? This has nothing to do with promoting a particular philosophy of software licensing. Maybe for you; for me that is a very important consideration. I'm lost, what's important to you? Are you unhappy that MPL is compatible with proprietary licenses? Do you not understand why that was required from the beginning given the commercial origin of the code? It has everything to do with permitting Mozilla code to be used in as many different projects as possible, regardless of what licenses are being used for those projects' code. If that is really the truth, then why are we not putting the Mozilla source into the public domain? (Seriously.) It was discussed, and using a BSD-like license was strongly favored by some. The semi-copyleft of the MPL seemed like a good compromise, allowing the Mozilla project the possibility of taking back improvements and ensuring some visibility if our code got incorporated into popular projects. -Dan Veditz
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: On Wed, 12 Sep 2001, Frank Hecker wrote: On the other hand, the GPL cannot be merged with any code other than GPL code (except for OS and compiler libraries). Not true, the GPL is compatible with code under quite a number of licenses that the FSF enumerates. The question is whether the LGPL would allow MPLed code to be combined with LGPLed code (i.e., putting Mozilla code into an LGPLed library) and the resulting work distributed under LGPL terms (as required by the LGPL). The LGPL wouldn't care, as far as I can tell. However, since the MPL doesn't let you relicense the code under another license, the MPL wouldn't let you merge the MPL code with the LGPL code (in the same file, with the license of the MPL code changed to the LGPL). Nor would the LGPL allow you to relicense a chunk of code to MPL; don't blame the MPL alone for this, it goes both ways. In fact this is pretty standard for all licenses, even the ones that the FSF considers compatible with the GPL. The compatible ones tend not to make any claims on the compiled code, but they commonly claim things like You may not impose any further restrictions on the recipients' exercise of the rights granted herein (i.e. can't turn it into GPL, which is restrictive), or This notice may not be removed or altered from any source distribution. (again, you can't turn it into some other license). Actually putting the Mozilla code, e.g. parts of nsCSSRendering.cpp, into an LGPL library, though, is not allowed, since the MPL doesn't grant you the right to change your license, and the LGPL requires the library to be under one license, the LGPL. The MPL allows you to distribute a larger work under a different license--as long as certain requirements are met. It's the latter, not the former, that causes the problem. (IANAL, I am merely trying to apply logic to the text of the licenses...) As are we all. -Dan Veditz
Re: simplest Mozilla license for a developer
Vikram wrote: Can this message thread be concluded as, I am not obligated to provide source code for functionality which is a)completely written by me. b)contained in separate source files than the Mozilla source files. No Matter without my component my distribution of Mozilla browser works or not. Please Reply with a definition in brief which you feel the best. Those are true statements -- see section 3.7: 3.7. Larger Works. You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code. -Dan Veditz
Re: NPL/MPL history question
SOELL Markus Helmut wrote: This one is just about a detail in history of these licenses. I do a little history writing and want to get things straight. Is it correct, that in a first time Netscape suggested just one license, the Netscape Public License, and that the MPL was added in response to some negative critics after a first round of public discussion? Basically correct, although negative critics makes it sound like a public backlash when it was really a cooperative effort to file off the rough edges. The initial draft of the NPL was announced 1998-03-05 in this group and issues were raised and resolved here. You can check out the ancient history for yourself by searching http://groups.google.com -Dan Veditz
Re: simplest Mozilla license for a developer
Frank Hecker wrote: Vikram wrote: I read some messages at http://groups.google.com/groups?hl=ensafe=offgroup=netscape.public.mozilla.license Conclusion is You really should base your conclusions on reading the license, not what people have said about the license. In big terms your conclusions sound ok but there's a fair chance you've gotten some details wrong. 2) I need to provide code which modifies behaviour of mozilla. So if I modify some mozilla component say 'html parser' then I need to give it's source code. Yes, if you make modifications to the Mozilla source files then you need to provide source code for those modifications, at least to people to whom you distribute your products. The Mozilla source you used needs to be made available whether you make Modifications or not! If you've used untouched Mozilla source you could probably rely on mozilla.org to maintain the distribution of the source, but you'll have to let your customers know which version of Mozilla source you've used and how they can get it. If you've made only small modifications to Mozilla code you may find it simpler to distribute them in patch form (allowed under the definition 1.11). 3) If mozilla is not fully functional without my program then I have to provide source code for my program too. This criterion is not really part of the Mozilla licensing scheme. That sounds more like the LGPL, (though not exactly). The LGPL is concerned that people have the freedom to improve programs they rely on, even if, for example, the vendor goes out of business or refuses to fix the defect. The MPL simply wants to make sure that the Mozilla community can use the bugfixes and improvements made by those who have benefitted from the Mozilla community's source. -Dan Veditz
Re: What's Branded Code?
SOELL Markus Helmut wrote: Well, basically the definition seems to be at NPL/II.: Netscape Branded Code means Covered Code that Netscape distributes... under Netscape trademarks not licensed under the NPL (paraphrased). This seems to mean any Netscape distributions and TMs, current and future. Since it's in Netscape's discretion to decide what they to apply their TM to, they can just apply their TM to all covered code which makes that branded code is equal covered code, right? Hm, is it the trademarks which aren't licensed, or is it the Covered Code which has been re-licensed? So why create this new term branded code? Talking about covered code would be more straight forward I think. covered code is general and applies to everyone involved with Mozilla code under the MPL/NPL. Netscape Branded Code is specifically the versions of covered code that Netscape releases or licenses to others to release under terms different from the NPL. Given this definition of branded code, It looks like V.3 gives Netscape a wildecard, they can do with the entire covered code what ever they want. The NPL works for Netscape just like a BSD license, right? This has been of no practical benefit for years due to the amount of *Mozilla* Public License code in the product. Yes, Netscape could take the NPL part of the product and treat it more or less like BSD code (which some in the company wanted to use in the first place), but at this point that would be just a big useless pile without the MPL'd parts. The NPL amendments were designed to get Netscape out of some practical and political jams when the source code was initially freed; they aren't really relevant anymore and for the past couple of years Netscape employees have been encouraged to create new files under the MPL rather than the NPL. When Netscape first decided to release the source code for Gromit (now known in the tree as Mozilla Classic) there were three main internal obstacles to anything copyleft-ish. We relied on some 3rd party libraries that we didn't have time to replace, yet couldn't get permission to release (thus amendment IV). We shared code with Netscape's server products (primarily NSPR and the Javascript engine) and the management of those divisions fought opening the source if it was going to mean extra work for them (thus amendment V.2). And we had contractual obligations to license whatever we shipped to other companies so they could release their own versions of the browser. They (or their lawyers) balked at trying to figure out what open source would mean for them, thus amendment V.3 -- although as you point out V.3 negates the rest of the license as far as Netscape is concerned. With the scrapping of MozillaClassic in favor of the current Mozilla codebase IV became irrelevant. With time (April 2000) V.2 expired. And V.3 was always (IMHO) a red herring to reassure lawyers and managers without any practical benefit. Or perhaps you can think of it as an incentive to non-Netscape developers (though I don't know if it was indended to be): as long as the only contributions were little bug fixes the source was essentially like a BSD license to Netscape (which some in the company wanted to use), but once significant chunks of code came from outside then Netscape would have to play by the copyleft-ish rules of the MPL too. In an ironic twist, it's the very power granted in V.3 and complained about since the license was written that will enable us to convert all NPL code to MPL when the dual-licensing details are worked out. But that's another long thread. -Dan Veditz
Re: LDAP C SDK 5.0 MPL/GPL
Mitchell Baker wrote: Daniel Veditz wrote: [emphasis added] I should note that I personally am opposed to the specific dual-licensing scheme proposed. It doesn't merely fix the GPL compatibility problem, it allows a GPL project to make improvements to Mozilla code without sharing those changes back (by changing the license of existing files to GPL-only). This is a violation of the fundamental idea behind the MPL, and *as far as I can tell wholly unnecessary to solve the license **incompatibilities.* I would be very interested in a proposal that didn't allow a GPL fork and yet was acceptable to the Free Software Foundation. I have yet to find one. All my discussions have coome back to the point that the GPL prohibits the application of any new restrictions. And requiring code to be licensed under the MPL as well as the GPL is an additional restriction which causes an incompatibility with the GPL. I took another look at some of the licenses the FSF considers GPL compatible (http://www.fsf.org/philosophy/license-list.html#GPLCompatibleLicenses). Most of those are chock full of restrictions, along the lines you can't remove the original copyright info and license from these files. What happens if some GPL project embedding perl modifies the perl engine? Or a GPL project embedding zlib fixes a bug or adds a feature? If someone pulls the modified file out of the GPL project (with the original copyright license notice still intact as required) could they use those changes in a project under the perl or zlib license? Wouldn't a dijoint license scheme (to use the FSF term) that simply says Alternatively this code can be treated under the terms of the LGPL or GPL as long as this copyright notice remains intact be equivalent to most of the official Compatible licenses? To change the subject slightly, my investigation caused me to realize that Exhibit A doesn't state that users of the code must keep the copyright notice intact. Section 3.5 of the license does, however, though some folks might argue it only says you have to duplicate the stock Exhibit A in the MPL itself, not preserve the one found in the source code. I hope I'm wrong on that loophole, but it still might be nice to add a line to this effect in Exhibit A itself. -Dan Veditz
Re: LDAP C SDK 5.0 MPL/GPL
Michael Hein wrote: I'm in the process of moving the LDAP C SDK 5.0 source code from NPL to the dual MPL/GPL license. In notifying past contributors of the intention of moving to the dual license I realized quickly this is more of a religious issue that I had first anticipated. Can someone sum up the pros/cons of the MPL/GPL dual license. Why is it good/bad etc. Is there something better? Why the MPL/GPL? MPL because that's the preferred Mozilla license, specifically drafted by Netscape/mozilla.org to accomplish the aims of the Mozilla project that didn't seem covered by existing open source licenses in quite the way we wanted. GPL because that's the license used by a large portion of open source projects (e.g. Linux itself, GNOME, GIMP, and many, many small projects). dual because currently GPL and MPL code cannot be combined in the same project due to niggly technical details. Important because the MPL/GPL incompatibility is blocking the use of Mozilla/Gecko by GPL'd projects. A bummer for projects that would like to use Gecko rather than invent their own, a bummer for us because we aren't getting bug reports and fixes from those projects and aren't getting the additional Gecko browsershare of those users. religious issue because everything about the GPL is a religious issue. -Dan Veditz
Re: Sample Apple Code
Andy wrote: AFAICT this is compatible with the terms of [M/N/G]PL... all it requires is we state somewhere in the file "portions of this code are descended from sample code which is Copyright 1984-1999 by Apple Computer". Effectively we list them as a contributor. Looks compatible to me, too. Some have suggested a CVS comment would be enough. Personally I'd think the best approach would be to state a 1 line comment at the top of each function derived from Apple code, just to make everything crystal clear. I don't think a CVS comment is sufficient, it needs to be something that travels with the source. Unless the entire file is basically the Apple sample file a comment above each derived function is probably a good idea, in addition to the contributor comment at the top of the file. As a developer I'd be interested in being able to track derived code back to its source. Perhaps the comment could specify which sample code its derived from, although that doesn't appear to be a legal requirement. -Dan Veditz
