Re: This source code is subject to the U.S. Export AdministrationRegulations
anthony hill wrote: Could not Mozilla be virtually based somewhere more amenable to the open source philosophy. And the developers? Shall they and their families move, too?
Re: Do triple licenses potentially force branches on the communityor other dead-locks?
Ralf Hauser wrote: ii) Contributor G applies Modification 1 and creates a ContributorVersionGPL.C with it, licenses it with GPL and includes it in her GPL Larger Work. This is expressedly discouraged by both mozilla.org and Richard Stallman. 1) I guess T does not have the right to just take parts of Modifications 1 into a ContributorVersionTRI.b.C and distribute with the LargerWorkArbLicensed. Correct. 2) Can G help T doing so? Keep the tripple-license. 3) Or is there a timing/rigidity issue? Should G first publish her modifications under the less rigid license (i.e. the triple license) in the same repository as ID published OriginalCode.C (or in a repository of G, but that's much less practical.) and only then proceed to step ii) with the more restrictive GPL? Yes. Step ii) is only a thought/legal step and most people think that it does not have to be performed actually. I have a question of my own, though: I have heard the argument of some GPL-zealots that Mozilla is now or soon to be available under the GPL and that we could thus theoretically use GPL (not LGPL) libraries. It would make it impossible to distribute other propriatary libs with it, but that is often seen as advantage my these people. They have thus refused to relicense the lib under LGPL or even MPL, although they considered it previously. Case in point is the GPGME library to access GPG. Another case might be the GPL Flash implementation (I haven't heard from that author yet). Personally, I find it inacceptable to be forced under the GPL and thus make it impossible to distribute Macromedia Flash with it and maybe even impossible to *offer* Macromedia Flash for it, just for 1 or 2 GPL libs. I had no success to argue that with those people though (Lesser GPL, all the world must be under GPL, bla bla). (For the record: I am against monopolies, even if the monopoly is the GPL. Eventhe GPL has IMO weak and imperfect wordings and we should not all be forced to use that one license. I think that LGPL, BSD and MPL are just as reasonable licenses and that all Open-Source should be possible to be combined, but the GPL disallows that.) Ben
Re: Freedom, NPL, and SeaMonkey 1.0
Ralph Mellor wrote: Aiui, the NPL is not a free license. It might not be approved as such, but why shouldn't it be Free or OSI-compliant? It is essentially the MPL plus some license terms that give Netscape some additional special rights. Those rights are not much different to the GNU's right to issue new GPL licenses and have them apply to code under old licenses. Aiui, some files in the Mozilla codebase are NPL only. These files are not dual or triple licensed. Note here that I am talking about the best possible view of the situation: if the tip file currently in CVS is NPL only, I still would not count that as NPL only if Netscape have already given permission for that file to be dual/triple licensed so that it is already really free. IIRC, Netscape allowed all NPL files in Mozilla to be tripple-licences and the CVS tree licenses should reflect that. If they don't, that's a bug. So, with the above clarification of NPL only, are any of these NPL only files used in SeaMonkey 1.0? No. (To my understanding) If not, great. Please just answer yes to the above and ignore the rest of this email. Well, that no doesn't really help you practically. The [L]GPL (your other alternative for these files in that case) doesn't allow to be mixed with the MPL, and we have MPL-only files in the tree. That means, as soon as you compile and distribute Mozilla, you have to decide for either NPL/MPL or GPL or LGPL. The latter 2 ae no options, because there are MPL files. Internal use doesn't matter, because the [L]GPL doesn't care about internal use (dunno about MPL/NPL). I am not a laywer, just my personal understanding. Ben
Re: Freedom, NPL, and SeaMonkey 1.0
Ralph Mellor wrote: OK. Hmm. So SeaMonkey is free, but incompatible (in terms of mixing source) with some other free software. Is that correct? Well, some other Free Software is incompatible with Mozilla (if under the MPL), yes. I say it that way around, because it's terms in the GPL that disallows the merging, not the MPL.
Boilerplate additions
Hi Mitchell, hi Frank, is the following addition to the MPL/GPL/LGPL boilerplate OK for new files in existing Seamonkey modules (Mozilla.org code), reflecting the fact that I'm not AOL ;-P ? Quick answer appreciated, since I'd like this code to get into 1.0. Thanks in advance. Ben /* * Unlike stated in the License, this License shall be governed by * German law provisions. Any litigation relating to this License shall be * subject to German jurisdiction. * Once Covered Code has been published under a particular version of the * License, You may always continue to use it under the terms of that version. * The Initial Developer and no one else has the right to modify the terms * applicable to Covered Code created under this License. */
Re: Boilerplate additions
Adam J. Richter wrote: This came up before with the previous copying permissions for Python 2. The Free Software Foundation stated that it believed that this sort of choice of law restriction would constitute an additional restriction prohibited by section 6 of the GPL. I think you misunderstood it. I am merely changing the *existing* choice of law in the original MPL license (which choses California). License is defined above as the MPL, so that term doesn't apply at all to the [L]GPL. As for the new license versions, that's a clause that the Linux code has, too. I don't think that RMS can stand up against that :-). From Linux COPYING: Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Also, you might want to think about what would happen if somebody wanted to comingle a contribution that was covered by a similar additional choice of law restriction, but one specifying a different choice. I guess that if there are 2 conflicting provisions, the default per law applies. (That's the case with conflicting ToSes (AGBs) here in Germany.) What if there's a problem between a French company and me? I am relatively happy with our laws - why should I chose the U.S. law? Ben Bucksch
Re: Boilerplate additions
Ben Bucksch wrote: License is defined above as the MPL, so that term doesn't apply at all to the [L]GPL. As for the new license versions, that's a clause that the Linux code has, too. Actually, I misworded the clause. I meant The Initial Developer and no one else has the right to modify the terms applicable to Covered Code created under the licenses. (I don't like GNU to change the licenses under my feet without my permission either.)
Re: Questions about MPL license
Bjorn Reese wrote: Simon P. Lucy wrote: You can charge as you like for your application, but you won't be charging for the Mozilla component itself. What part of MPL says that you cannot charge for Mozilla? You can, but nobody will pay, because it is available for free. Same for your changes to Mozilla code (files).
Mozilla.org's statement to W3C patent policy (and my comments)
http://lists.w3.org/Archives/Public/www-patentpolicy-comment/2001Oct/1350.html Thanks for your thorough statement to the patent policy of the W3C. My comments: Did you notice that some of your (valid) complaints to the RAND patent license also applies to RF patent licenses, to my understanding? Namely, the restriction to certain implementations and prevention of incremental improvements of the standard (or derivates). Even if the W3C chooses not to support RAND licenses we would personally love to see the W3C require that any Members grant royalty free licenses before working in a Working Group. What I would like to see is that any patent, which is holded by a Working Group member and which is touched by a Recommondation of that WG, has to be relelase to the public domain, i.e. making it non-existant. Even RF patent licenses might impose restrictions on uses of the standard, and I think that no standard should be restricted in that way. (With one exception maybe: I could imagine that legal force (like patents) is used to enforce standards compatibility of implementations, but I am not sure, if that is a good thing.)
Re: Merging MPL and GPL libraries
Carmi Grushko wrote: Is it relicensing my application to MPL/GPL (or even MPL/GPL/LGPL), and that's it ? Yes, I think so. And if it is, as an Initial Developer, I may do this anytime I want to, subject only to my discretion ? No. If there are other contributors, you have to ask them, too.
Re: Multiple Licencing language
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. The environment variable though is the critical part of this. If that makes you feel better, create a file at the top-level of the Mozilla tree, stating I use this source under the terms and conditions ot the MPL license only.\nSimon P. Lucy.
Re: Reasons for incompatibility GPL-MPL
Gervase Markham wrote: I am asking, because I think that making the MPL compatible might be the better way for the relicensing. Please read the FAQ on this issue. Gerv, as I said, I *did* read the FAQ. Most of the arguments there I addressed already. The remaining ones are no-brainers: Modifying the MPL itself would have taken more time and effort There is no support in the FAQ for this claim. the Mozilla project (like other projects) was already making use of a multiple license scheme without apparent problems. There obviously are problems with some people who don't like the GPL. Those probably just didn't happen to contribute to NSPR or JS. Changing the MPL would also have potentially affected developers who had adopted the MPL for use with their own code, independently of the Mozilla project. If those developers did not like the new MPL changes then they would have to explicitly use an older version of the MPL, or create their own MPL-based license. We can't know, if other projects would object, if we don't know, which terms are those. I don't think, any project would object the removal of the jurisdiction clause. In fact, it will probably help some (OpenH323 for example). As I mentioned, the GPL incompatibility is a problem for other projects, too. They now have to go through the same hassle as we do. Finally, changing the MPL would have required re-submitting it to the Open Source Initiative http://www.opensource.org/ for certification in connection with the Open Source Definition http://www.opensource.org/docs/definition.html , another potentially time-consuming process. That's bogus. The mail I quoted also says that FSF and OSI were quick to respond on the new Python license.
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: Also if I have to licence using the GPL then I may be locked out of future derivations of my own work. Unlikely. If it's a smaller change, that project would have to maintain the change as a patch, and maintaining patches is hell, as we experienced. If it is something larger, it probably involves new files, which could always be under different licenses. Forks are unlikely to survive, unless somebody strong backs it and/or mozilla.org does a very bad job. A GPL forked version may add some feature. I cannot make use of that feature because I cannot use the GPL licenced file, That feature probably wouldn't exist, if the source were not open for GPL projects. I can't even replicate the feature because it could be seen as a violation of the GPL code. I highly doubt that. GNU were in that very situation when replicating BSD/UNIX back then and I doubt that they are so evil to prevent what was the basis of their existnce. there is no way to identify the use of the MPL licence at the time of use and that has been the core of my objection all the time and no one has addressed that. (Answered that in a preceeding mail.) (Though I noticed that the Beonex run time licence includes the additional licence language which confuses me) The Beonex Comm. run-time license is plain MPL. Is there anything worng or problematic about it? I thought that Mozilla binaries were onder the exact same license.
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: I know, this I don't understand, i don't see how Galeon and Nautilus can go on, yet there's a need to further allow GPL licencing. The only reason why they still exist is that nobody sued them yet (to my understanding; dunno if they fixed the license in the meantime). Having decided its a dead project for me I'm not proposing to stand on the sidelines and throw rocks. heh. I don't want to throw rocks, but I still have a little hope that things will improve.
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: I have said that the only way to use the source is to remove the GPL/LGPL language. But its not the binary that matters, you have to make sure for all uses. This effectively still means that I'm estopped from contributing back because I can't licence using the GPL. Why not? I can understand that you fear to *use* the GPL in your projects, but why do you fear to *release* your work under GPL, too? If you want, you can use 2 sets of source: One you get from mozilla.org and you do changes there. If you contribute back, you create patches there. When you compile, you first remove the dual license part. Of course, the precompiler already does that :), so I'd just skip it and compile normally. I thought that was the case. I believe its a mistake not to pursue deliberate violations of source licencing, Well, you can do so. If you have code in the mozilla.org sourse, you have the right to sue, I think. Of course, I don't think, it's a good idea to sue them, as all they want to do is have fun and help the world. re-licencing to regularise a breach is plain cowardice and a breach of confidence with original contributors. It's not cowardice, it's what mozilla.org wants. It wants to be used in projects like Galeon or, say, CrystalSpace (which might want to use XPCOM).
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: Mozilla runs on Linux, no user that uses Linux is really going to care about the source licencing. They do care, but the MPL is acceptable to most. Developers that wish to combine code from GPL may be affected but I've never quite seen the problem like that. Galeon. Dunno, how it is solved in Nautilus. Originally, and some might remember this differently, the NPL licence was meant to be a limited to I think three years. V.2 is limited to 2 years. V.3 (which they resort to) doesn't seem to be. if clauses within the NPL are being used to relicence by the back door Back door is a nice word. Regardless of the licencing now or in the future I've separately come to the conclusion that Mozilla is a dead open source project, some products may be produced but I cannot see the quality improving in the current climate. It does improve in some areas, e.g. stability and features. PC magazines are starting to call us a competition to MSIE. 0.9.2.1 is much better than 0.6. We still have serious problem or are getting worse in other areas, like contributor treatment and tree management. I don't mention details here, because it's offtopic. Please ask, if you are interested, and I'll followup to .general.
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: Actually, having read the FAQ, even if I hadn't thought that Mozilla, for me, was a dead project it certainly is now. Forcing developers to licence their own work under the GPL simply means that developers such as myself can never contribute back because of the risk of having our own future unrelated development and client development affected. Simon, I think you misunderstood the issue. I see 3 cases: People downloading the Mozilla source have the *option* to use your contributed source code under the GPL. Nomally, the source is guarded by MPL. Now, if (and only if) the opt to use the GPL instead, *they* are forced to follow the GPL terms, which means that they have to release the full source of all *their* binaries which link to Mozilla. In other word, you get their source, while you aren't forced to do anything. If you contribute code to mozilla.org and at the same time use it (and only it) in one of your products, you don't have to care about the Mozilla license, because you have the copyright and you (in most countries) have the right to license your work to any number of people under any number of licenses. If you use Mozilla code (presumably with code contributed by people other than you) in your app, you don't need to use the option of using the GPL. You follow the MPL terms. The dual license explicitly says that it's optional to use it under the MPL: quote src=http://www.mozilla.org/MPL/MPL-1.1.html; Alternatively, the contents of this file may be used under the terms of the _ license (the [___] License), in which case the provisions of [__] License are applicable instead of those above. /quote Alternative, instead. If you opt to use the MPL and distribute the binary which includes Mozilla code and proprietary code, your users don't get the Mozilla portions of the binary under the Mozilla dual license, they get the whole binary under the license terms you choose. The MPL allows that and Netscape does it. All you have to do is to follow the MPL terms of releasing the *source* to your Mozilla source modifications. There, we are back at case 1, which, as we already saw, is no problem either. HTH. I am not a laywer. This is not legal advice. Feel free to add that to the FAQ, if you want, assuming appropriate credit. Ben
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: I fail to see how contributions will be made back to the tree by those that insist on using the GPL. Not at all. In which case why bother? Because Mozilla can't be used by GPL projects otherwise. Note: *used*, i.e. compiled and distributed. Development should (!= must) happen under the triple license in all cases. Licencing under the GPL isn't necessary to achieve this, both NSPR and XCOM can be used as LGPL targets, and without relicencing under LGPL. ? And the licences give third parties the right to sue as well as the original copyright holders, in fact they give third parties the right to sue the copyright holders under certain circumstances. Which ones? but if all these marvellous things are happening in GPLand and they aren;t contributed back (I promise you they won't be), then in 6 months time what is the point? Oh yes here is the point, AOL will still get use of the codebase protected by the buffer and the original copyright. I don't understand what you are saying.
Relicensing going on
It seems like the relicensing is already going on. Did I miss any announcements or hasn't this been announced on .license? I find it somewhat irritating that you now change (NPL code) to the dual license, although my understanding was that you wanted to ask each and every contributor for permission (incl. contributors to NPL code). I'm not sure that the special rights of Netscape under the NPL amendments (which you cite as the base for the relicensing without prior permission) are applicable at all, because it has been suggested that this was for Netscape's pre-existing contracts with corporate licensees. (This is included because Netscape already has certain source code licenses in place whose terms differ from those of this NPL. These licenses may not require the license back of code, Annotated NPL) In fact, V.3 seems to cover only Netscape's Branded Code, which is distributed under trademark(s) which are controlled by Netscape but which are not licensed fpr use under this License, which I interpret as the Netscape 6 code (in contrast to the Mozilla code). This would be in line with the comments to the license. Now, as I said in previous discussions, I don't object to that change for files where I am a Contributor, i.e. I won't block such a change. But I find the current approach somewhat goofy, considering that some people here indeed seemed to oppose such a change to a GPL dual license. I understand how difficult and time-intensive it is to get *all* contributors to even *react* at all. But shouldn't you at least make some modest attempt? Again, maybe I missed it, but I didn't even see any hint that you intend to use any Netscape special rights, and I am on all relevant mailing lists (cvs account, code copyright notice, .license, .announce). Can someone please shed some light into this? Maybe I misunderstood something? As for the code where I am the Initial Contributor, would it be acceptable for mozilla.org and Netscape (which Contributed some changes) that I relicense the code under a more liberal license, which is compatible to all of the MPL, NPL, LGPL and GPL, e.g. the BSD or MIT license? They are used for some dirs in the Mozilla tree already (in my understanding), but the license policy says that the agreement of mozilla.org is limited to those dirs.
Re: Licensing Statistics (2001-09-08)
Simon P. Lucy wrote: the GPL effectively removes the original copyright (insofar as original copyright holders have rights to any derivable product) and gives it away to all and sundry. The MPL, and a few other licences avoids this imposition. Does the MPL give the original copyright holder rights to derived products? In which way?
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: You mis-read what I wrote. Nokia do not intend their product to be used as a Flash Renderer, they intend it to be used as a web browser. The point is that the plugins are not deriative works (they in fact can be created, compiled and used totally independently of the hypothetical GPL Mozilla). They are distinct products. And since they are not deriative works, they can be shipped together with GPL product without breaching the GPL license. That, at least, is my reading of the GPL. Did I miss a particular clause that denies even this? Macromedia Flash is primarily a plugin. It is a proprietary library loaded by Mozilla. I thought, this is what the GPL disallows. The fact that you *can* run RealPlayer (or Flash?) stand-alone is irrelevant, to my knowledge. That's exactly what happens here - the GPL does not only catch proprietary code, but also other open-source code, which does nothing to harm anyone. IMHO, the fact that free code may be used in conjunction with non-free code is a problem because it doesn't emphasise that non-free code is (IMHO) wrong. Note the may and problem. MPL code (by itself) does not harm you in any way, and it is in fact intended to be usually used solely, without any proprietary code. I don't see how MPL code would harm you. *If* you choose to use proprietary code with it, *then* you might harm yourself. But you don't have to do so; and even if you do, it's not the MPL harming you (but the proprietary code by your very own decision). FWIW, the english version of that page does not contain the string forc -- could you point out the exact sections you disagree with? | Releasing it under the GPL and limiting its use to free programs | gives our community a real boost. At least one application program | is free software today specifically because that was necessary for | using Readline. How is that forcing anyone? The authors of the application were free to write their own Readline library -- they made a choice to use GPL software and therefore be GPL themselves. I consider this a victory, and do not see where anyone was forced to do anything. Could you explain what you mean? If I want to use readline, I am forced to use the GPL. That's about as much force as the author of readline can exercise, and he makes full use of that force. Similarily, a GPLed Mozilla might force Macromedia to release the Flash Player under the GPL. That's about the same force as I am forced to use Microsoft products when I want to read MS Word documents. And I very much dislike the latter. Why should I exercise a similar force on others? (Please don't argue with But the GPL is good and Microsoft does it only to get even richer. That's not the point and even arguable.) As a matter of fact, Stallman does consider the MPL to be Free Software (in his definition even), and BSD and others, too. I didn't say he didn't. Yes, the MPL and the BSD are free software licenses. You said even An LGPL project should NOT be using free software code, although the LGPL is itself Free Software. My point was that open source and free software are different, which is easily proved by comparing their definitions. Can you elaborate what the exact difference is? I find it hard to find. So, the GPL does in fact violate the goal that free software (in Stallman's deinfition) developers should support one another, because it disallows the use of these apps together (see below for an example). No. The MPL (and others) violate that goal by supporting non-free software as well as free software, No, support is not exclusive. thus diluting the message that free software is important. That message is a completely different issue. It is completely arguable, how that message should be carried out. The GPL does not support developers that support proprietary software, that was one of the main goals of the GPL. That is in line with the goal you quote above. Wrong. The MPL is free software. Developers using the MPL are thus free software developers. The GPL does not support them. Thus, the GPL violates free software developers should support one another. You can't distribute it linked with proprietary software, no. That is to protect your end users -- if you could, then they would not be guarenteed freedom as well. How often have I to repeat that? *It is not about proprietary software.* *It is about the MPL together with the GPL.* The MPL is not proprietary software. Nevertheless, I can't use it with the GPL. And that in fact harms end-users, because I can distribute Beonex Communicator (which is Free Software) with Sun's JRE (which is proprietary), but I can't distribute it with kaffe (which is Free Software). So, they might end up using Sun's closed-source JRE, while they could be using Free Software only. As a concrete example, I can't use kaffe to replace Sun's closed-source JRE, because kaffe is under the GPL and the plugin interface is to link a lib, not to invoke an
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: In practice, though, our ability to be used in proprietary projects has not really affected our market share relative to the market share obtained through the Netscape brand release. Therefore if Netscape switched to the GPL, we could switch to the GPL without this affecting market share. (Also note that our current miserable marketshare is apparently enough to keep Microsoft on their toes -- without Mozilla leading the way, would WinIE6 have a strict rendering mode with as many bug fixes as it does?) In both cases, it's not the current, but the expected market share that matters. After all, a useable product based on Mozilla is only out since not even a month. For code, given the goal of promoting free software principles and hindering proprietary software if possible, the GPL seems to me to be the most appropriate license today. Why are you working on Mozilla then? (Don't misunderstand me - I appreciate your work and are glad that you work on Mozilla.) Konqueror is GPLed and quite useable already, I heard. Yes, which is appropriate or even required in some situations. Like? (Bear in mind that because there is no free equivalent is not, for me, a valid reason. There was no free equivalent to Unix, the C++ compilers, text editors, web browsers, web servers, mail servers, etc... until someone decided that there should be.) And what did Emacs (the first GNU software, to my knowledge) run on? Could the need to run on prorietary systems be the reason why the GPL stops at the process border (which is pretty arbitary)? Mozilla lives in a different world, in a world where Microsoft exists and where libraries are used in cases where Unix uses processes. How can you say that the one license (MPL, LGPL) is (IYO) wrong while the other (GPL) is (IYO) the only way to go?
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: must allow _their_ end users to reverse engineer their program, Does their peogram include linked libraries? which at this stage includes the MSVC++ code, which the end user is not allwed to reverse engineer. Who says that? In Europe, reverse engineering is allowed for ensuring compatibility. The only case where I can see a problem is where a specific LGPL library wishes to use Mozilla's code directly (i.e., not linking to it). Is there really such a case? I think so. That's the idea of open-source -- Screw open source. Oh, we're getting a bit too philosophically for my taste here. The idea of free software is that ALL users should be able to run the source, study the source, adapt the source, and redistribute the source. Adapt the source (and use it) would not be not possible here. The LGPL should only be used when it can do this better than the GPL -- namely, when the service that the library provides is already commonly provided. The services that Mozilla provides do not fall into that category, It does. MSIE is wide-spread and often incorporated in other apps. There are a lot of companies which had the choice between MSIE and Mozilla, and some of them chose Mozilla (and I think that Nokia chose Linux in part because of the availability of Mozilla, while a Mozilla that disallows the use of Macromedia Flash and RealPlayer might have been out of question). http://www.fsf.org/philosophy/why-not-lgpl.html I wholly disagree with parts of that doc. It speaks about forcing people to use make software free (GPL), and force is not free in my book. But, it also says We free software developers should support one another.. (I make no distinction between free software and open source here.) That's exactly my point - allowing other projects to use our code. If we are starting fights with free vs. open and deny each other code, we only harm ourselves, IMO. to have a large pool of software you can use to build new projects. Let's say, I want to use the TXT-HTML converter in an LGPL project. I may have to change the string classes, but most of the code could be reused. I would not even be allowed to reuse a few lines, if it is under the MPL or the GPL only (ignoring that I happened to write it myself). And that is exactly WHY I am against using the LGPL. An LGPL project should NOT be using free software code. Are you saying that LGPL code is not free? Is only the pure GPL in your view? That doesn't seem to be supported by http://www.gnu.org/philosophy/free-sw.html. If the project wants the code that much, it should switch to a strong copyleft free software license. It won't. we should move Mozilla to the GPL -- so that this kind of problem does not arise. This is impossible. People who contributed code to Mozilla are objecting that. (I am not one of them, as long as my code is still usable/available under terms which *I* consider free, for which the GPL does not qualify.) The GPL is, IMO, not as free as other licenses. You're right, it isn't. (That's why I think that the term Free Software is wholly inappropriate and misleading.) It was very carefully designed to make it impossible to use GPL-covered software in proprietary environments. http://www.gnu.org/philosophy/why-free.html I don't speak less about proprietary environments, but other open source environments, like the MPL, LGPL etc etc..
Re: Licensing Statistics (2001-09-08)
Did the thread started in .general? Can you give a short summary? Gervase Markham wrote: I think Hixie's saying that if you want to combine with GPL code, you have to change all the notices, as section 3 requires, before you can do so. This is inconvenient (and may make returning changes to the original codebase more complex.) That's a problem, but not that bad that it were the reason to dual-license under GPL instead of LGPL. There are quite a number of LGPL problems, and Mozilla code dual-licensed under the GPL could not be used in those projects, assuming they want to keep the ability to be used under LGPL terms. Note that this problem is (again!) a problem inherent with the LGPL and not limited to thedual license. If you want to use LGPL-native code in GPL projects, you have the same problem. It is unclear, how it works, if I don't directly incorporate/import the code into the GPL project, but just use it (e.g. linking, extracting mozilla tarballs etc.).
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: The LGPL would also prevent anyone from building Mozilla using MSVC++, since the MSVC++ redistributables license disallows reverse engineering, and the LGPL requires that that be allowed. There're tons of (L)GPLed projects using MSVC++. The only case where I can see a problem is where a specific LGPL library wishes to use Mozilla's code directly (i.e., not linking to it). Is there really such a case? I think so. That's the diea of open-source - to have a large pool of software you can use to build new projects. Let's say, I want to use the TXT-HTML converter in an LGPL project. I may have to change the string classes, but most of the code could be reused. I would not even be allowed to reuse a few lines, if it is under the MPL or the GPL only (ignoring that I happened to write it myself). Note that this problem is (again!) a problem inherent with the LGPL and not limited to the dual license. If you want to use LGPL-native code in GPL projects, you have the same problem. It is unclear, how it works, if I don't directly incorporate/import the code into the GPL project, but just use it (e.g. linking, extracting mozilla tarballs etc.). The GPL is pretty clear about it. Do you have any specific examples of where you think it is unclear? Yes. Galeon, a GPL project, uses Mozilla libraries. In order to build Galeon with Mozilla, would it have to change all Mozilla code or could it be used unchanged? I.e. when exactly do I have to alter the license notice? * Whenever I compile code that will eventually be linked anyhow to GPL code? * When I use an (unchanged) source file in a GPL project? * When I change the source for use in my GPL project? I should also point out that my overall opinion on this issue is that we should be pure GPL 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.
Re: Licensing Statistics (2001-09-08)
Ian Hickson wrote: On the other hand, the GPL cannot be merged with any code other than GPL code (except for OS and compiler libraries). BTW: That exception might apply to the reverse engineering (in LGPL license) as well.
Re: What's Branded Code?
SOELL Markus Helmut wrote: Well, basically the definition seems to be at NPL/II.: It looks like V.3 gives Netscape a wildecard, they can do with the entire covered code what ever they want. Mostly. This is intended. Note that - there is also the MPL, which does not contain this clause. - the NPL special terms expire after 3 years. Disclaimers: I'm speaking form memory only, am tired and not a lawyer.
Re: Larger Work: what's an API?
SOELL Markus Helmut wrote: So I imagine this new file may e.g. contain some new functions and I could add some lines in the covered code, with call to those functions. Is that right so far? Right. Now, maybe my question boils down to what is an API?. Basically exactly what you described above. IANAL.
Re: Statically linking libstdc++
Ben Bucksch wrote: For some bizarre reasons, we link in libstdc++, which is LGPLed on gcc Linux. FYI: Jim Nance just cited a special exception in the libstdc++ license, which basically invalidates the GPL terms, if linked using a GNU compiler. See bug 79681.
Statically linking libstdc++
For some bizarre reasons, we link in libstdc++, which is LGPLed on gcc Linux. We currently do this dynamically, which is the standard, but causes major problems during distribution (the user has the have the exact same version of the lib installed that wer eon the build system) for other bizarre technical reasons. Bug 79681 proposes to link the lib statically, but cls raised a concern that this might force Mozilla to be under the (L)GPL, i.e. be illegal. My response: My understanding of the LGPL http://www.gnu.org/copyleft/lgpl.html, sections 5 and 6: Linking (dynamically or statically) changes the executable to be a derivative of the LGPLed lib. But that fact solely doesn't force the whole binary to have a GPL-compatible license. Rather, the executables have to follow some restrictions the GPL imposes, outlined in Section 6. One restriction seems to be that the user must be able (legally and practically) to use a new/changed version of the LGPLed lib. (Another restriction might be the copyright notice, see below.) With /dynamical/ linking, this is trivial. Replacing a /statically/ linked lib would require the user to have the object code or source code of the non-GPL portion, and exactly that is what the LGPL requires the distributor to provide. In the case of Mozilla, the user has the source - can recompile and relink - LGPL terms are fulfilled. That might not be true for vendors which mix Mozilla code with proprietary code - they would have to supply object code (.o files) for the proprietary parts, if they are linked statically with Mozilla code. The latter seems to be the only new restriction when statical linking is used. Again, all said here is only my guess. I don't know the GPL too well. Some nit-picking: You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Strictly, does this also apply to a dynamically linked libstdc++? Even it's not actually used? There's an exception: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs but it only speaks about the source code.
Re: LDAP C SDK 5.0 MPL/GPL
Bjorn Reese wrote: quote 13. MULTIPLE-LICENSED CODE. Initial Developer may designate portions of the Covered Code as 'Multiple-Licensed'. 'Multiple-Licensed' means that the Initial Developer permits you to utilize portions of the Covered Code under Your choice of the NPL or the alternative licenses, if any, specified by the Initial Developer in the file described in Exhibit A. /quote Uh, if I interptret it your way, it basically means that the Inital Developer can do with the code, including all contributions, whatever he wants. Was that intended???
Re: LDAP C SDK 5.0 MPL/GPL
Mitchell Baker wrote: Ben Bucksch wrote: Bjorn Reese wrote: quote 13. MULTIPLE-LICENSED CODE. Initial Developer may designate portions of the Covered Code as 'Multiple-Licensed'. 'Multiple-Licensed' means that the Initial Developer permits you to utilize portions of the Covered Code under Your choice of the NPL or the alternative licenses, if any, specified by the Initial Developer in the file described in Exhibit A. /quote Uh, if I interptret it your way, it basically means that the Inital Developer can do with the code, including all contributions, whatever he wants. Was that intended??? No, this was not the intent. The intent was that the Initial Developer of a piece of code could decide (for example) that s/he wanted people to be able to use that code under either the MPL or License X. The Initial Developer would add language to the header files naming the MPL and License X. If you then make a Modification, the Initial Developer can use your Modification under either the terms of the MPl or the terms of License X, but not under any other terms. But the MPL unfortunately does not specify, *when* the Intital Developer allows the alternative license. If, as Bjorn suggests, the Initial Developer can do that at any time, this has the effect of what I outlined, since License X is also arbitary. It is not even restricted that it's always the same License X. As an Initial Developer, I could sell the code to my customer A under license X, to customer B under license Y etc., even though the code is under the stock MPL 1.1 and I didn't ask the contributors about licenses X or Y. I assumed that the alternative license has to be specified at the same time as the MPL begins to apply to a document and that it is virtually unchangeable after that (unless all contributors agree, of course). In any case, I find Bjorn's move questionable, considering that he didn't ask contributors for permission and how many people here objected the move to change the license (to MPL/GPL in our case).
Re: LDAP C SDK 5.0 MPL/GPL
Stuart Ballard wrote: There is no benefit per se, and none were intended -- it is all about legalism. The code was originally released under MPL. Years later the contact to many of the contributors had been lost, and it was thus impossible to ask their permission for a change of license to solve the GPL-incompatibility problem. Instead, section 13 Multiple-licensed Code in MPL 1.1 was used to create a dual-license. I don't have time to go and read the legalese of the MPL right now, but I'm surprised that you can do this. Netscape and mozilla.org have been trying for ages to dual-license the mozilla code, but they had to get permission from all of the contributors and they haven't been able to do this yet. How were you able to dual-license the code without permission from all the contributors, and why doesn't the same logic apply to Netscape and mozilla.org? Almost same logic does apply in both cases. There is a clause in the MPL saying that AOL is allowed to update the license. Nowhere is specified how that update has to look like. Theoretically, MPL 1.3 could be equivalent to the BSD license. Thus, it would be strictly legal for Netscape to just release the whole NPL/MPL mozilla.org code under the BSD license or a MPL/GPL dual license or a propriatary license.* If that is morally the right thing is a completely different question. *Note that code once released under MPL 1.1 is always still available under MPL 1.1, independant of any updates. Ironically, Bjorn cannot use that clause, because the clause mentions AOL specifically, not the initial developer. Thus, what Bjorn described above is illegal, I believe. I am not a lawyer. Nothing I said here is definitive, it's just my understanding of the matters.
Re: LDAP C SDK 5.0 MPL/GPL
Bjorn Reese wrote: The FSF is more concerned about the whole than the individual parts. In mathematical terms, the FSF wants the union of GPL and another license to be strictly equal to GPL. The problem the FSF has with MPL, is that there are additional restrictions on the whole. mozilla.org is no different here, with s/GPL/MPL (modulo NPL), not? It wants the whole mozilla.org code to be available under the MPL terms. Less so for purity, but more for practical terms. And I agree - having x licenses is not practical and could turn potential users/contributors away.
Re: mozilla.org artwork
Gervase Markham wrote:
As a related observation, it seems very odd to me that Netscape chose to
open the source of its entire Communicator code base, and set up a
"Mozilla" project to look after it, but didn't give the project rights to
the cute green Mozilla graphics...
Me too. I really like it, by far better than the new, red one.
Can you guess how much I would have liked to use
http://home.snafu.de/tilman/mozilla/sculptor.gif (Mozilla building a
"B") for the preview and development versions of Beonex Communicator?
Is this the same issue, or a separate ("mozilla.org wants to keep control
of the red lizard") one?
Mitchell Baker told me that Netscape-the-business, not mozilla.org,
holds the copyright to it.
Re: custom versions of the MPL
David R. Astels wrote: our legal guy is concerned about using a license that is a slight tweak to the MPL (such as Sun's... i.e. Netscape - Sun). Any issues here? IIRC, many folks do that, btu I don't know, if you are still allowed to call it MPL then. I think, you may call it a MPL-derivate. IIRC, the license even says something about that!?!
