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
Ben Bucksch wrote: 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. That is not the clause I mentioned. From the clause that you are referring to, the only part that is of interest to me in this regard, is section 6.2 Effect of New Versions which allows me to choose to use such Covered Code under the terms of any subsequent version of the License. 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. Here is the clause that I mentioned (from MPL 1.1). It explictly says the Initial Developer. 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
Re: LDAP C SDK 5.0 MPL/GPL
Daniel, Yes, I'm floundering around a bit.but learning a lot from all of you guys so that is goodness. I'm actually all set to go as far as changing the C SDK to the MPL/GPL combo; however, thanks to you and others I'm reconsidering. This is a good thing because I would have otherwise just blindly charged ahead without fully understanding. I have a couple of goals as far as the licensing of the SDK go. 1) I would ofcourse like to prevent forks, if possible 2) For our commercial customers, I need a license which they will accept with minimal fuss and which protects their source code rights. In past experience, a BSD style license has always worked well for commercial customers. I want to allow for commercial customers not to have to recontribute code back etc. 3) Allow for as many people to pick up the source with the least amount of hassle. Daniel Veditz wrote: Daniel Veditz wrote: Michael Hein wrote: Bjorn Reese wrote: Instead we opted for a MPL/BSD dual-license. This weakens the copyleft of the project, which is the the opposite effect of what the FSF wants to achieve -- and the irony of it all is, that GPL was the direct cause of this shift. Do you mind posting the dual MPL/BSD you used the more I learn about GPL this seems quite attractive Didn't you start the thread asking about converting the NPL'd LDAK code? Netscape and mozilla.org specifically rejected the BSD when creating the MPL (we were strongly inclined to go with an existing license at the start) and Netscape may still be unwilling to release its code under those terms. In fact, if your motivation is that you're having trouble getting people to agree to change their LDAP contributions to MPL/GPL, picking MPL/BSD is unlikely to help. People who accepted the BSD (which allows taking code for proprietary projects) would be unlikely to object to MPL/GPL unless they are extreme knee-jerk GPL-haters. BSD-like licenses have a do whatever you want attitude. The objections I've seen about MPL/GPL (as it is currently formulated) are that it allows people to fork the code GPL-only without having to share improvements back. Since BSD would allow the same thing except with an even broader range of projects I'm sure you'll get at LEAST the same number of objections. Probably more because at least a GPL fork would still be open source. -Dan Veditz
Re: LDAP C SDK 5.0 MPL/GPL
One comment re using the BSD as an alternative. It does work well for commercial customers, because essentially they can do whatever they want with BSD code. Including privitize it, as long as they keep the correct notices. One of the things the MPL does is make customers look at the idea of contributing back to the project. (So this does require effort on their part, it is not the easiest way for them.) But in general, I have found that companies can get comfortable with the MPL and be comfortable enough to contribute back. (In large part because there's a clear line that says they can treat non-MPL code however they want.) So not having a BSD style license has encouraged contributions back in 2 ways. First of course, the MPL requires contributions back for MPL Modifications. Second, the process of getting companies comfortable with this requirement encourages them to understand the benefits so that the default response to a BSD license isn't only good, we can treat this as private code. The latter response may be less pronounced now than a few years ago. But I still find it in my discussions with the non-engineering departments of a number of companies. So we forego the easiest way (BSD), but get some benefits in return. Mitchell Michael Hein wrote: Daniel, Yes, I'm floundering around a bit.but learning a lot from all of you guys so that is goodness. I'm actually all set to go as far as changing the C SDK to the MPL/GPL combo; however, thanks to you and others I'm reconsidering. This is a good thing because I would have otherwise just blindly charged ahead without fully understanding. I have a couple of goals as far as the licensing of the SDK go. 1) I would ofcourse like to prevent forks, if possible 2) For our commercial customers, I need a license which they will accept with minimal fuss and which protects their source code rights. In past experience, a BSD style license has always worked well for commercial customers. I want to allow for commercial customers not to have to recontribute code back etc. 3) Allow for as many people to pick up the source with the least amount of hassle. Daniel Veditz wrote: Daniel Veditz wrote: Michael Hein wrote: Bjorn Reese wrote: Instead we opted for a MPL/BSD dual-license. This weakens the copyleft of the project, which is the the opposite effect of what the FSF wants to achieve -- and the irony of it all is, that GPL was the direct cause of this shift. Do you mind posting the dual MPL/BSD you used the more I learn about GPL this seems quite attractive Didn't you start the thread asking about converting the NPL'd LDAK code? Netscape and mozilla.org specifically rejected the BSD when creating the MPL (we were strongly inclined to go with an existing license at the start) and Netscape may still be unwilling to release its code under those terms. In fact, if your motivation is that you're having trouble getting people to agree to change their LDAP contributions to MPL/GPL, picking MPL/BSD is unlikely to help. People who accepted the BSD (which allows taking code for proprietary projects) would be unlikely to object to MPL/GPL unless they are extreme knee-jerk GPL-haters. BSD-like licenses have a do whatever you want attitude. The objections I've seen about MPL/GPL (as it is currently formulated) are that it allows people to fork the code GPL-only without having to share improvements back. Since BSD would allow the same thing except with an even broader range of projects I'm sure you'll get at LEAST the same number of objections. Probably more because at least a GPL fork would still be open source. -Dan Veditz
Re: LDAP C SDK 5.0 MPL/GPL
Bjorn Reese wrote: As an example, we have been using MPL for another project, and have naturally received requests, similar to those that the Mozilla community have received, about re-distributing the project under a GPL-compatible license. The disjunctive MPL/GPL dual-license was considered and rejected because it would allow the project to become GPL-only, which is would be unacceptable to us (the project is used in several commercial applications). Instead we opted for a MPL/BSD dual-license. This weakens the copyleft of the project, which is the the opposite effect of what the FSF wants to achieve -- and the irony of it all is, that GPL was the direct cause of this shift. Hang on... if you are using MPL/BSD (so long as you mean modified-BSD, that is, without the advertising clause - which is the only verson GPL-compatible) then you can still create a GPL fork: 1) Use the program under the terms of the BSD license, 2) Link in some other code that is GPL'd 3) Release the combined software as GPL The BSD license does not prohibit this, so you're still GPL-forkable but now you're also BSD-forkable and proprietary-forkable as well! Also, I don't quite understand the benefit of a MPL/BSD dual license. Surely everything that is permitted under the MPL is also permitted under BSD, so MPL/BSD is just equivalent to BSD by itself? Stuart.
Re: LDAP C SDK 5.0 MPL/GPL
Stuart Ballard wrote: Hang on... if you are using MPL/BSD (so long as you mean modified-BSD, that is, without the advertising clause - which is the only verson GPL-compatible) then you can still create a GPL fork: 1) Use the program under the terms of the BSD license, 2) Link in some other code that is GPL'd 3) Release the combined software as GPL If MPL had been GPL-compatible, then you could have done the same with purely MPL covered code. There is a subtle difference between the GPL fork you are talking about and the one I am talking about. With an MPL/BSD dual-license my code will remain under either MPL or BSD, regardless of what the combined software is released as. With an MPL/GPL dual-license my code can become GPL-only, which would be against my wishes. Also, I don't quite understand the benefit of a MPL/BSD dual license. Surely everything that is permitted under the MPL is also permitted under BSD, so MPL/BSD is just equivalent to BSD by itself? 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.
Re: LDAP C SDK 5.0 MPL/GPL
Bjorn Reese wrote: Stuart Ballard wrote: Hang on... if you are using MPL/BSD (so long as you mean modified-BSD, that is, without the advertising clause - which is the only verson GPL-compatible) then you can still create a GPL fork: 1) Use the program under the terms of the BSD license, 2) Link in some other code that is GPL'd 3) Release the combined software as GPL If MPL had been GPL-compatible, then you could have done the same with purely MPL covered code. I know. I misunderstood your previous comments as saying I don't want to use MPL/GPL because you can create a pure-GPL fork, so I used MPL/BSD instead. There is a subtle difference between the GPL fork you are talking about and the one I am talking about. With an MPL/BSD dual-license my code will remain under either MPL or BSD, regardless of what the combined software is released as. With an MPL/GPL dual-license my code can become GPL-only, which would be against my wishes. I'm not sure I understand the distinction, so I'll break down my logic more carefully, and you can tell me which step of my logic doesn't match yours. Under an MPL/BSD dual license, I can do the following: 1) Download your code 2) Elect to use it under the BSD license. 3) Modify it (eg by linking in other software, but also potentially by just modifying a few trivial lines of code) 4) Release my modified version under the GPL. Now, if Joe Developer downloads my modified version, the only rights he's given are those of the GPL; even the parts of your code that are embodied in mine are only available under the GPL to him. So in a way I have changed your code to GPL. However, in practice, if Joe Developer wants MPL or BSD rights to your parts of the code, there's no problem in him downloading the original code from you and thereby getting the MPL/BSD rights to that code. The upshot is that I can fork your code into a GPL license (so that people who download directly from me only have GPL rights, even on your code), but I can never stop people from getting the MPL/BSD terms if they go directly through you. If all of this is correct for the MPL/BSD combination you used, then as far as I can see all the same steps also apply to an MPL/GPL dual license. I can still do a GPL fork in the exact same way that I can with the BSD license, but other people can still go through you and get the original MPL terms. So what's the difference? Also, I don't quite understand the benefit of a MPL/BSD dual license. Surely everything that is permitted under the MPL is also permitted under BSD, so MPL/BSD is just equivalent to BSD by itself? 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? Thanks, Stuart.
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
Michael Hein wrote: Do you mind posting the dual MPL/BSD you used the more I learn about GPL this seems quite attractive You can find it at http://curl.haxx.se/docs/copyright.html Another example is (see question 1) http://xmlsoft.org/FAQ.html Daniel Veditz raises the question about a BSD-like license being too permissive, and indeed it is. I am also convinced that it will spark discussions as Daniel mentions. However, the experience from the two above-mentioned projects is that proprietary projects, which uses your BSD-like covered code, will usually contribute their modifications back voluntarily. One motivating factor is configuration management -- it is much easier to upgrade to a new version of the open project, if the modifications have become part of the Open project. It is also the experience that such contributions, as they are made by professional developers, are of a high quality. Then there is the pervasive fear in the Free/Open Source community that proprietary companies will steal the code (that is, extend the code without contributing anything back). This has certainly happened in the past, and will certainly happen again. However, this is not necessarily a bad thing. If they build upon your code, then you have less work to catch up, than if they made their own, and most likely, incompatible implementation.
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: LDAP C SDK 5.0 MPL/GPL
Bjorn Reese wrote: Frank Hecker wrote: A more interesting question is, are any of those GPL-compatible licenses copyleft licenses? I have never seen this stated explicitly, but I Most people have a one-dimensional concept about licenses. They only rate license according to their openness. However, there is an equally important dimension, namely cooperation. See for example http://devlinux.org/devLicense.html The problem with GPL is that its strongly defensive posture makes it a very uncooperative license. Interestingly, its tactics backfires as your question indicates. In an attempt to guard copyleft by all means possible, it kills (i.e. refuses to cooperate with) any similar attempts. This forces any compatible license to have a much weaker notion of copyleft. As an example, we have been using MPL for another project, and have naturally received requests, similar to those that the Mozilla community have received, about re-distributing the project under a GPL-compatible license. The disjunctive MPL/GPL dual-license was considered and rejected because it would allow the project to become GPL-only, which is would be unacceptable to us (the project is used in several commercial applications). Instead we opted for a MPL/BSD dual-license. This weakens the copyleft of the project, which is the the opposite effect of what the FSF wants to achieve -- and the irony of it all is, that GPL was the direct cause of this shift. Do you mind posting the dual MPL/BSD you used the more I learn about GPL this seems quite attractive suspect that the only copyleft licenses that the FSF would ever consider compatible with the GPL are the GPL itself, LGPL, dual licenses involving the GPL or LGPL, and minor variants of the preceding licenses. I tend to agree. The underlying mechanism seems to be that a license will only be GPL-compatible if it (1) does not prevent the terms of GPL to apply, or (2) it can be transformed into GPL. Many people who uses the LGPL, seems to be woefully unaware about section 3, which allows anybody, at any time, in any kind of weather, to transform LGPL into GPL. As somebody once said, the road to GPL is a one-way street. There have been at least two attempts to create non-GPL copyleft licenses from scratch, the NPL/MPL and the Jabber Open Source License, and the FSF considers both of them incompatible with the GPL. GPL does not promote copyleft, only GPL copyleft.
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
Daniel Veditz wrote: 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. That sort of restriction is already in the GPL, so IMO it doesn't count as a restriction above and beyond the GPL. A more interesting question is, are any of those GPL-compatible licenses copyleft licenses? I have never seen this stated explicitly, but I suspect that the only copyleft licenses that the FSF would ever consider compatible with the GPL are the GPL itself, LGPL, dual licenses involving the GPL or LGPL, and minor variants of the preceding licenses. There have been at least two attempts to create non-GPL copyleft licenses from scratch, the NPL/MPL and the Jabber Open Source License, and the FSF considers both of them incompatible with the GPL. 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. Yes, this has been discussed previously in connection with the dual license Exhibit A and the idea of altering the exhibit (i.e., as included in source files) to remove either the MPL or the GPL sections of the dual license language. I agree that there is ambiguity in the NPL/MPL regarding this, and that the language should be tightened up in future versions to make it clear that licensees are not allowed to alter existing copyright notices and license notices (except to add themselves as contributors as appropriate). Frank -- Frank Heckerwork: http://www.collab.net/ [EMAIL PROTECTED]home: http://www.hecker.org/
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: LDAP C SDK 5.0 MPL/GPL
Daniel Veditz wrote: 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? snip dual because currently GPL and MPL code cannot be combined in the same project due to niggly technical details. And the dual license allows each group of users to use the code under the terms they prefer: People who prefer the MPL or who otherwise need to be able to use its terms, including people developing proprietary software, can use the code under MPL terms. People who prefer the GPL or who otherwise need to be able to use its terms, including people wanting to incorporate the code into GPLed software, can use the code under GPL terms. I second the rest of Dan's excellent summary. Frank -- Frank Heckerwork: http://www.collab.net/ [EMAIL PROTECTED]home: http://www.hecker.org/
Re: LDAP C SDK 5.0 MPL/GPL
Daniel Veditz wrote: 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. Pardon my ignorance of the licensing of Gecko..are you say this to illustrate the case of Gecko not being released under the dual license thus preventing the participation of the GPL folks or what? religious issue because everything about the GPL is a religious issue. -Dan Veditz
