Re: testing kit conformance as a condition of distribution
At the risk of being off-topic with Brian, I have a similar question about the effect of another notice or clause. We've been looking at code which has a traditional BSD license, with the following sentence added: You acknowledge that this software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. I don't believe this has been officially submitted to OSI for review as part of a BSD license, though I see other OSI-approved licenses have this clause (Apple, Real, Reciprocal?). I believe the rationale is that this is an acknowledgment, but a limitation on use in nuclear facilities, and so it's OK. Would including this clause in a BSD-license be OK? Mitchell Brian Behlendorf wrote: I know this list is supposed to be about reviewing proposed licenses rather than speculation, but hopefully you'll at least find this question more on-topic than most. With respect to the language at the top of: http://geronimo.apache.org/download.html and for context: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=52 The NOTICE Sun is asking us to post seems, to me, to effectively constitute an additional term of copyright. Such a term would not seem to be OSD compliant. Empirically I can argue this easily, as no open source license has been approved with such a conformance requirement on derivative works (AFAIK). The Sun Internet Standards Source License comes close, but it also allows the release of non-conformant works so long as the full source code to non-conformant works is available. What I need are solid sound-bite-y easy-to-explain but non-dogmatic arguments as to why such a conformance requirement is not compatible with the way Open Source works (putting aside compatibility with any particular licenses). Thanks in advance, Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Submitting a new license or using the current ones
Actually, I think there are other reasons beyond the lawyer, and understanding them would be helpful to any hope of progress. Many people have an idea of how they want to run their business or project and want a license that is geared to their plans. Lacking a good understanding of how hard a different license makes things, they wanta license that meets their particular goals. Mitchell [EMAIL PROTECTED] wrote: Ian Lance Taylor scripsit: I don't understand why there are so many licenses, if the open-source specification is so rigid. I don't really understand it either. I mean, I know how we got here step by step, but looking at the situation now it doesn't make much sense. We have so many licenses because of the Not Invented Here principle: lawyers don't want to adopt the work of other lawyers as is, because how could they justify their fees then? We really need only about two licenses: a reciprocal one and a non-reciprocal one. Perhaps we also need one that is reciprocal as to the code itself, but not as to larger works in which the code is embedded. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Update for CUA Office Public License
Hi Everyone With regard to the MPL there is one new element that probably isn't well known.nbsp; There is a section of the MPL that says who can modify the MPL.nbsp; The 1.0 and 1.1 versions specify that entity as netscape (it had to be someone).nbsp; But with the creation of the Mozilla Foundation that entity has been changed to the Mozilla Foundation.nbsp; I plan to create a Mozilla 1.2 version shortly to make just this change.nbsp; (One might consider other changes of the license as well, but that's a long discussion.)nbsp; And I assume that changing the entity from Netscape/AOL to the Mozilla Foundation should be seen as a positive step. Mitchell John Cowan wrote: Patranun Limudomporn scripsit: PS. If you want to compare and know what difference between CPL and MPL, just have a look at http://cuaoffice.sourceforge.net/productinfo_cpl_diff.htm Thank you for providing this diff. What it amounts to is that your CPL *is* the MPL 1.1 with the name changed and the pointers to Netscape changed to point to you. While this procedure is permitted under the MPL, I wish to strongly discourage you from taking this step, for these reasons: 1) The MPL is well understood by many programmers, who will be able to tell, simply by seeing that your software is licensed under the MPL, exactly what they can and cannot do with it without having to read and understand a new and complex license. 2) The MPL has become widely used outside the Mozilla project, just as the GPL has become widely used outside Project GNU and the BSD license has become widely used outside BSD. Thus, using the MPL does not in any way suggest that you are using Mozilla code or that there is some connection between your group and the Mozilla project. 3) It's in everyone's best interest if there are fewer, rather than more, open source licenses. It has often been difficult to convince corporate lawyers of this, hence the proliferation at opensource.org; nevertheless, standard licenses make for simplicity and uniformity, which encourage the easy use and reuse of open-source software. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSS-lics vs. liability and warranty
The Mozilla Public License explicitly allows a distributor to do this. Mitchell bird birdie wrote: Hi, With regard to the disclaimer clauses regarding warranty and liability in many open source licenses I have the following question. Does a distributor of OSS need permission of the copyrightholders to provide warranty and to accept liability? I heard that some distributors of open source software sometimes believe that they need permission of copyrightholders for this. It is not clear to me what the ratio behind this request for permission is, because if distributors provide warranties or liabilty -in my opinion- they are not overriding the terms of open source licenses. The provided warranty and accepted liabilty can be seen as additional services, that are laid down in a seperate agreement and only have legal force between the distributor and the enduser. The GPL for example seems to explicitly allow a distributor to provide warranty and to accept liability with regard to the distributed GPL-software (see articles 1, 2c, 11 and 12 of GPL). The BSD license does not allow it explicitly. However, because the disclaimer clause only mentions COPYRIGHTHOLDERS AND CONTRIBUTORS, one can deduce that no permission is needed for a distributor to provide warranty and accepting liability. Is there any information available about this? And what is your opinion regarding the above? Cheers, Bart Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Licensing Model: open downstream apps or proprietary license
The Open Source Applications Foundation (http://www.osafoundation.org) is planning the 0.1 release of Chandler (a personal information manager) shortly, hopefully by the end of April. OSAF's plan of record for licensing is to follow the model used by MySQL: recipients must either (a) make their entire application available under the GPL or other approved open source license, or (b) get a commercial license from OSAF. I'm very interested in the thinking of this group about this model. The plan is reasonably firm but not set in stone, so I'd appreciate hearing about potential pitfalls as well as benefits. Mitchell -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licensing Model: open downstream apps or proprietary license
Lawrence E. Rosen wrote: Mitchell Baker wrote: The Open Source Applications Foundation (http://www.osafoundation.org) is planning the 0.1 release of Chandler (a personal information manager) shortly, hopefully by the end of April. OSAF's plan of record for licensing is to follow the model used by MySQL: recipients must either (a) make their entire application available under the GPL or other approved open source license, or (b) get a commercial license from OSAF. I'm very interested in the thinking of this group about this model. The plan is reasonably firm but not set in stone, so I'd appreciate hearing about potential pitfalls as well as benefits. I've always liked that model. :-) /Larry Rosen Excellent. That's good to know. Mitchell -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licensing Model: open downstream apps or proprietary license
Ian The goals are to be a broadly adopted, high-quality PIM on all platforms, and to ensure that Chandler is always available on an open source basis to those who want it. We also hope to generate a piece of the funding that will be necessary to make Chandler development self-sufficient. OSAF is a non-profit organization, so there is no return on investment goal. But we do need a way to sustain ourselves. Your point that a database is much more likely to be distributed as part of a larger application is very well taken. The potential revenue for Chandler may be much smaller since it is intended as a useful application in and of itself. On the other hand, we're not looking for big profits, only self-sufficiency. I am acutely interested in any ideas for a different focus which you might have. Mitchell Ian Lance Taylor wrote: Mitchell Baker [EMAIL PROTECTED] writes: The Open Source Applications Foundation (http://www.osafoundation.org) is planning the 0.1 release of Chandler (a personal information manager) shortly, hopefully by the end of April. OSAF's plan of record for licensing is to follow the model used by MySQL: recipients must either (a) make their entire application available under the GPL or other approved open source license, or (b) get a commercial license from OSAF. I'm very interested in the thinking of this group about this model. The plan is reasonably firm but not set in stone, so I'd appreciate hearing about potential pitfalls as well as benefits. I think the discussion might be more focused if you say what your goals are. Then we can compare the licensing plan to those goals. If your goal is to be the dominant PIM on free software platforms, then copying MySQL's licensing seems reasonable. It's worth noting that MySQL is only mildly useful by itself, and is normally part of a larger application. I would have thought that a PIM would be quite useful by itself, and would not normally be part of a larger application. So focusing on forcing people to release their entire application may miss the point. Or, more likely, I have missed the point. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Optimal license for Java projects ...
It's generally agreed that a BSD-type license does allow privitization of a fork, including useful modifications in that fork that the original authors might prefer to be able to use. Project dymanics may minimize this, as happens in the Apache project. But the liense does permit a private fork, and this may well have been the setting that concerns Gunther. The Mozilla Public License was pretty much written to fit into the setting Gunther describes. As to the interface question: if the toaster makers copy parts of an MPL file into a new file, that new file is governed by the MPL. That new file can call proprietary material, which remains proprietary, pretty much for the reasons Gunther describes. The MPL's explicit statement that it doesn't apply to the combined work as a whole has been very helpful to commercial entities which wish to partipate. (I'm not advocating that everyone +should+ care about the participation of commercial entities.) The MPL has been used by the NetBeans project, so it may be familiar with some of your audience. Mitchell David Johnson wrote: On Thursday 13 March 2003 09:32 am, Gunther Schadow wrote: - The problem of the BSD license is that it allows commercial parties to take the source code away and contribute little, and take away the freedom of their customers to use improved versions of the free code You've completely misunderstood the nature of the BSD license. First, commercial parties cannot take source code away any more than they could take water away from an ocean. It may look like they are, but if you check, the free source code is still there and the ocean isn't any smaller. Second, they can't take away their customer's freedom to use improved versions, because the free source code is still there and the ocean is still huge. It seems to me that what you don't want is something much different. You don't want a commercial company being more successful than a noncommercial entity. You whole horrible scenario of MicroToast forcing burnt toast on their customers can easily occur anyway, regardless of license. All MicroToast has to do is to implement their own YML suite. As a reference, I point you to BSD licensed Kerberos. For a few days in history, every GPL advocate in the country was talking about how horrible it was that Kerberos wasn't under the GPL. If only it weren't under the BSD, they said. But then it turned out that Microsoft didn't use the BSD licensed code to begin with! They implemented their version from scratch! Even RMS had to back track a bit and rewrite an interview he gave(1). The point is, your scenario has never occured. But the scenario of MicroToast implementing their own stuff from scratch has happened innumerable times. So licenses alone aren't going to save you. So, what is the best open source license that Hans Hacker should have used? It seems to me that the best solution for Hans' paranoia is the LGPL. It gives most of the benefits of the BSD license in that it can be used to promote a standard YML implementation, but with just enough copyleft to eliminate his paranoia. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open Source Licence for my cms?
The isues you raise have been troublesome for many. The Sun Public License is actually the Mozilla Public License with exactly the changes you have pointed out -- who can change the license, jurisdiction, etc. It seems to me that the next version of the MPL should allow different choices for new Original Code. (That is, code not based on mozilla.org releases.) So others could adopt the MPL for use with their project and make their own choices. I suspect there will be some issues when code with different choice of law and venue provisions are combined and end up in court, but I haven't done research on this lately. But until this change is made, you would need to rename the license and change the parts you mention. If you do so you, it might be nice to put a header or footer that says The [X] Public License is the Mozilla Public License v1.1, with the following changes. Sun did this when they originally posted the Sun Public License, I' m not sure why they removed this notice. The Jabber Open Source License is also a variant of the Mozilla Public License, with the preamble added and some other changes. If you use the GPL, as was suggested, you will get a different scope of license (i.e., the strong copyleft) which you may or may not want. You would probably have a different set of questions about future changes to the GPL, which wouldn't be in your control either. Mitchell Baker Goran Svensson wrote: Hi, I am about to release a Content Management System written in Cold Fusion to the Open Source Community for free, the reason for that is partly because it is not possible to protect CF scripts, due to poor encryption, and I have also found lots of other compelling reasons to do so during my research in to free software. I have read many of the license in the OSI web and find it difficult to find a license that match my requirements. I am looking for a license where contributors have to make source code of modifications and scripts available to others and where I have the right to modify the terms in the License not Sun or Jabber etc and where International or the Licensors country's law is applicable or as in the Zope License nothing is written about it. I have found the one with a preamble useful when it come to understanding them. My problem is to find a license that are suitable for a mix of interpreted code (scripts) and source code. It´s also difficult for me to accept any jurisdiction than International or Swedish law. For example the Sun Public License suits me well except for jurisdiction, source code and the rights to modify the terms in the License: 11. MISCELLANEOUS ---snip--- any litigation relating to this License shall be subject to the jurisdiction of the Federal Courts of the Northern District of California, with venue lying in Santa Clara County, California, with the losing party responsible for costs, including without limitation, court costs and reasonable attorneys' fees and expenses. ---snip--- 6.2. Effect of New Versions. No one other than Sun has the right to modify the terms applicable to Covered Code created under this License. snip- I think that Sun Public License or Jabber Open Source License have come closest to match my requirements right now, but not close enough. If you know of a license that will match my requirements please point me in the right directions and the right procedures for using it. /Göran Svensson -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Procedure for using an approved license
On review, I think the Open Software License is more like the GPL in scope than it is the MPL. Larry notes that the OSL applies to derivative works rather than files. This means that all the complexities of defining a derivative work are reflected in the license. It's not that easy to know precisely what is and isn't a derivative work. One would think it would be, but the case law is complex. Last I researched this, the exact tests used to determine whether something is a derivative work varied by judicial circuit in this U.S. Also, I'm not sure if a derivative work under U.S. law is exactly the same as under European law, or of the mechanisms by which international treaty deals with this, if at all. Even more importantly, many entities do not want derivative works to be governed by the GPL, MPL or OSL. Assume someone takes JavaScript and incorporates it into a product. That product may well be a derivative work. Yet the creator of that work may not want the entire work to be governed by the OSL, MPL or GPL. In fact, there are a ton of projects and products that use JavaScript and I'm sure many of them have no intention of converting the entire project or product to open source. (Maybe we'd like them to, but the MPL is explicitly designed to allow authors to decide if and when their original work moves into the open source/free software world.) So I suspect there are many developers who are content with the MPL but would not be with the OSL. In general, the relative simplicity of the OSL is appealing. But some of the additional topics in the MPL seem important to me. For example, Sections 3.6 and 3.7 make it clear once the source availability requirements for MPL code have been meet, projects and companies are welcome to combine MPL code with other code, and to distribute that combined work under an End User License Agreement that differs from the MPL. I'm not sure what the OSL envisions here, and it feels closer to the GPL model. The explicit language in the MPL makes MPL code much easier for many projects to use. The OSL is indeed reinforcing my view that the MPL should be revised again and simplified. I don't see the OSL as taking its place. Larry, can you explain the thinking behind the warranty in the OSL? I'll be traveling with probably limited access for the next week, so may not be able to respond right away. Mitchell Mitchell Baker wrote: I had never really thought of the Open Software License as a practical alternative for the MPL. I'll certainly reread it carefully with that in mind. The MPL's file based system was used so that people working with the code, particularly programmers, could automatically and accurately understand the scope of the license. Programmers know a file when they see one. They don't necessarily know a derivative work when they see one. And neither do lawyers. Last time I did serious research into this topic, the determination of derivative work and copyright infringement varied according to which part of the country (and which judicial Circuit) one referred to. Sounds wild, but different Federal Circuits often use different tests. So we opted for something firmly based in the programming world. Mitchell Lawrence E. Rosen wrote: James, I agree with the problems you've noted with MPL 1.1. For most practical purposes, the Open Software License (OSL) accomplishes most of what MPL 1.1 does -- without those problems you mentioned. The major difference is that MPL 1.1 applies on a file-by-file basis and the OSL deals consistently with derivative works, but I never understood the importance of a file-by-file license anyway in most typical software. /Larry Rosen -Original Message- From: James E. Harrell, Jr. [mailto:jharrell;copernicusllc.com] Sent: Sunday, October 06, 2002 7:52 PM To: David Johnson; Dave Nelson; OpenSource Licensing Discussion Group Subject: RE: Procedure for using an approved license Open Source friends, I've been looking at MPL 1.1 as well. One of the reasons I would replace the word Netscape with my own company name is #6.2: 6.2. Effect of New Versions. 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. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape. No one other than Netscape has the right to modify the terms applicable to Covered Code created under this License. The last sentence is a difficult one for me- why would I ever want *Netscape* to be able to supplant this license with what they deem to be another better version? That version might say All covered code automatically becomes the sole property of Netscape corporation... Not suggesting that they would, but... Further, if I take this license to legal review and finally do find
Re: Procedure for using an approved license
First I'll respond to the question of renaming the license, then to some of the particular issues raised with the MPL. Using the MPL unchanged is helpful for combining code from projects and avoiding complexity. But if this is not acceptable, then Dave's technique is a good one. First, it lets people know of the only change quickly. Second, the only change concerns a potential future event -- the possibility of a different future version. Until that possibility occurs, the code from the two projects is effectively licensed under the same terms. So combining code from the two projects is simplified. Not as simple as if both used the MPL of course, but still well within the realm of possibility. I can't speak as to OSI certification. As to the particular issues raised with the MPL, I can give some background as to why the MPL is the way it is. And James, if there are other things in which your lawyers are interested, please feel free to have them contact me. I can explain the thinking when the MPL was written, as well as what we've learned since. Also, I' m interested in learning what works well for people and what doesn't. Section 6.1. We felt some provision for changing the license was necessary. We realized that the chance of the MPL being perfect in its first release (or really, any particular release) was small to nil. Perfection is the goal, but we we're not so arrogant as to think we've reached it J Code evolves, a license might need to as well. The GPL has been undated several times. New laws might be enacted which would suggest changes be made (UCITA perhaps being one). A lawsuit could do the same thing. Also, as time goes on, the community might find new needs arising, and some way to respond in the licenses will be required. Once we decided that some way of accommodating change was needed, the obvious question is: who will make this decision. I'd prefer mozilla.org to Netscape immensely, but mozilla.org is not a separate legal entity for historical reasons. For practical purposes, the MPL is managed by mozilla.org staff, but that's hard to write into a legal document. So we ended up with Netscape. It is clearly understood that this right to change the license is one of stewardship. And that changing the license without a consensus is dangerous, and changing the license to benefit Netscape is deadly. Section 11. Venue and jurisdiction is an area where I don't think we have a good solution yet. It seems to me that the next version of the MPL should allow different choices for new Original Code. (That is, code not based on mozilla.org releases.) So others could adopt the MPL for use with their project and make their own choices. I think the MPL community would want this, though we haven't yet had extensive discussions. I suspect there will be some issues when code with different choice of law and venue provisions are combined and end up in court, but I haven't done research on this lately. Hope this is of interest. Mitchell James E. Harrell, Jr. wrote: Open Source friends, I've been looking at MPL 1.1 as well. One of the reasons I would replace the word Netscape with my own company name is #6.2: 6.2. Effect of New Versions. 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. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape. No one other than Netscape has the right to modify the terms applicable to Covered Code created under this License. The last sentence is a difficult one for me- why would I ever want *Netscape* to be able to supplant this license with what they deem to be another better version? That version might say All covered code automatically becomes the sole property of Netscape corporation... Not suggesting that they would, but... Further, if I take this license to legal review and finally do find it to be acceptable for my product, what happens when MPL 1.2 comes out? The legal review is then pointless (or at least has to be re-done); but worse, if I don't like the terms of MPL 1.2, now I have a product that is licensed under terms that I don't find acceptable- and I have now way to keep you from using it under the terms of MPL 1.2. Now, give that MPL 1.1 is probably one of the most suitable licenses for commercial Open Source products... but there are some minor things that might not be acceptable for our lawyers... does that mean it's time to try another one specifically geared to Open Source commercial products that solves the templating problem (and maybe some others?) -- OR -- Perhaps someone can really address the question that Dave asked- or maybe really my re-phrase of the original question: Is this *a* correct procedure? (I change the to a) Given this procedure, is this license automatically 'OSI certified'?
Re: Procedure for using an approved license
I had never really thought of the Open Software License as a practical alternative for the MPL. I'll certainly reread it carefully with that in mind. The MPL's file based system was used so that people working with the code, particularly programmers, could automatically and accurately understand the scope of the license. Programmers know a file when they see one. They don't necessarily know a derivative work when they see one. And neither do lawyers. Last time I did serious research into this topic, the determination of derivative work and copyright infringement varied according to which part of the country (and which judicial Circuit) one referred to. Sounds wild, but different Federal Circuits often use different tests. So we opted for something firmly based in the programming world. Mitchell Lawrence E. Rosen wrote: James, I agree with the problems you've noted with MPL 1.1. For most practical purposes, the Open Software License (OSL) accomplishes most of what MPL 1.1 does -- without those problems you mentioned. The major difference is that MPL 1.1 applies on a file-by-file basis and the OSL deals consistently with derivative works, but I never understood the importance of a file-by-file license anyway in most typical software. /Larry Rosen -Original Message- From: James E. Harrell, Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 06, 2002 7:52 PM To: David Johnson; Dave Nelson; OpenSource Licensing Discussion Group Subject: RE: Procedure for using an approved license Open Source friends, I've been looking at MPL 1.1 as well. One of the reasons I would replace the word Netscape with my own company name is #6.2: 6.2. Effect of New Versions. 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. You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape. No one other than Netscape has the right to modify the terms applicable to Covered Code created under this License. The last sentence is a difficult one for me- why would I ever want *Netscape* to be able to supplant this license with what they deem to be another better version? That version might say All covered code automatically becomes the sole property of Netscape corporation... Not suggesting that they would, but... Further, if I take this license to legal review and finally do find it to be acceptable for my product, what happens when MPL 1.2 comes out? The legal review is then pointless (or at least has to be re-done); but worse, if I don't like the terms of MPL 1.2, now I have a product that is licensed under terms that I don't find acceptable- and I have now way to keep you from using it under the terms of MPL 1.2. Now, give that MPL 1.1 is probably one of the most suitable licenses for commercial Open Source products... but there are some minor things that might not be acceptable for our lawyers... does that mean it's time to try another one specifically geared to Open Source commercial products that solves the templating problem (and maybe some others?) -- OR -- Perhaps someone can really address the question that Dave asked- or maybe really my re-phrase of the original question: Is this *a* correct procedure? (I change the to a) Given this procedure, is this license automatically 'OSI certified'? *NOTE* MPL 1.2 is solely used in conjecture for the purposes of this email! Thanks for help understanding this too! James -Original Message- From: David Johnson [mailto:[EMAIL PROTECTED]] Sent: Sunday, October 06, 2002 10:03 PM To: Dave Nelson; OpenSource Licensing Discussion Group Subject: Re: Procedure for using an approved license On Sunday 06 October 2002 02:10 pm, Dave Nelson wrote: I wish to use the Mozilla 1.1 license, but don't know the exact procedures here. I copied the Mozilla 1.1 license from your site, replace 'Netscape' with my company, and 'Mozilla' with my product, and Netscape trademarks with mine. No other changes were made. Then added a line under the title stating: You did too much unnecessary work. The MPL is sufficiently templatized that you don't need to do all this. You only need to change the words Mozilla and Netscape if you make a derivative license of the MPL. This does not seem to be your intent. Far simpler: Just fill in EXHIBIT A with your name, software, etc., and you are done! You *do* want to keep the name Mozilla Public License, because people already know what it is and what rights it confers. Changing the name will only cause confusion. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at
Re: Partial OpenSource products/licenses?
(esending, bounced the first time) The Mozilla Public License (www.mozilla.org/MPL/MPL-1.1.html) was written in large part to allow this sort of combination. In the MPL world, individual files governed by the MPL must always be open source. A vendor is free to combine those files with other files, which may be proprietary, or governed by another open source license. The combined executable may be shipped under a license of the vendor's choice, provided that the recipient is told where an how to get the MPL files. Many companies do exactly this. For example, Netscape takes MPL code, combines it with proprietary code (such as a Java Virtual Machine, AOL Instant Messanger), and ships the combined result under a Netscape end user license agreement for its Netscape 7 browser suite. The limitation of the scope of the MPL to particular files rather than an entire application can be found in Section 1.9 (definition of a Modification, which must remain open source) and Section 3 (oblications regarding Modifications). Section 3.7 explicitly states that you may combine MPL with other code not govened by the MPL. Hope this helps, Mitchell Baker James E. Harrell, Jr. wrote: Open Source friends, Pardon if you find this off-topic. I tried to retrieve the FAQ from the list, but it doesn't exist, and can't seem to find a list charter. Can't find a good list search either. Anyway, I've read many of the licenses and some of the posts, but I don't see a good way to do what we're interested in. My question to this group pertians to bridging the gap for commercial applications and the world of Open Source. Quite simply, is there a license (or would this group ever consider a license) that allows for a Partial Open Source product- perhaps a 95% Open Source license? Here's a little reasoning, comments flames and criticisms are welcome, while constructive discussion is encouraged: -- We have a product that we are considering publishing as open source. The product would be available for free download and use. Some features would be limited though, and only available if you purchase a commercial license. Thus, a portion of the code (containing a license key manager) would necessarily be closed-source in order to prevent someone from easily removing the license checking. We enjoy many of the benefits of open source software, and would like to contribute back. The major base of our software has some good stuff in it- that we're more than happy to publish and allowing anyone else to use/copy/redistribute, etc. We would like to do so in a way that allows us to still produce commercial products that are (paritally) closed source. After all, we have a payroll to cover. ;) Of the major companies that appear to be making money on open source products, it appears the primary method of doing so is via related services. However, services do not scale as well (commercially) as do products. So I'm searching for the happy medium. Thoughts? Regards, James Harrell, CEO Copernicus Business Systems, LLC -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Partial OpenSource products/licenses?
I believe the difference is that the MPL does not require two versions of the same code, one open and one closed. Our system is to allow one version of the open tree, to which everyone would contribute. Copernicus would also keep a second tree, containing the closed source material. Copernicus would participate with everyone in the open source project. When Copernicus builds its commercial product, it would pull form the open source project, then add in closed source additions to build its commercial product. Returning to the Netscape example, this is what Netscape does. Netscape engineers participate in the mozilla.org source tree, and get the critical benefits of the open source project. Netscape pulls from that open source tree, then pulls from a separate closed source commercial tree to complete its product. This means anyone can pull the same thing from mozilla as Netscape does. (Any many do, forming the variety of Mozilla distributions.) But no one else can pull from Netscape's commercial tree, because that remains proprietary to Netscape. I use Netscape as an example because it is so well known, but numerous other companies do the same thing as well. Mitchell Lewis Collard wrote: John Cowan: That way lies great pain and suffering for everyone. Instead, I recommend you use the Mozilla Public License, and have two versions of your product. ProductX Open is fully open source under the MPL, which basically allows people to create closed-source derivatives as long as they reveal actual patches to the source (as opposed to additions). ProductX Gold is a derivative of ProductX Open, but is closed-source. By using the Netscape modification to the MPL (see the NPL), you can have patches submitted to ProductX Open made reusable in ProductX Gold as well. Couldn't you use the GPL too for this purpose? If you are the copyright holder for the entire code is there anything stopping you from releasing modified versions under different licenses? Yours -- Lewis -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
Bruce Perens wrote: John Cowan: I don't understand how this breaches the spirit of the GPL any more than providing ASP-style access to the unmodified work does (i.e. not at all). If you are free to make private mods to GPLed programs for your own use, why not for others' use? This is just timesharing under a new name. Well, I could answer that in two, conflicting ways. If distribution becomes irrelevant, the spirit of the GPL in that respect is obsolete, isn't it? On the other hand, Richard treats this as a privacy issue. I contend that a publicly performed GPL work with a private implementation does indeed contradict the spirit of the GPL. Then, you get into the question of what is the entity in which privacy applies? In the GPL, it is the entity within which there is no need to distribute. This has always been sort of vague to me, because it's not clear if a corporation and all of its employees are a single entity, or if distribution takes place between employees, or between employees and the corporation. Then, bring in complications like consultants and companies working under contract but not part of the same legal entity as the corporation. Bruce As to the question of the scope of a corporate entity, the MPL uses a control standard often found in corporate documents, securities documents and statutes. The language is the sort everyone hates -- clearly written by lawyers for laawyers. I've included it below. But it is in general use, is generally understood by lawyers and judges who may someday look at this, and so won't need to develop its own case law and understanding. There is a couple of other standards in use for determinging control but the one in the MPL seemed the best, at least when I researched this last. Mitchell *++ 1.12. You'' (or Your) * means an individual or a legal entity exercising rights under, and complying with all of the terms of, this License or a future version of this License issued under Section 6.1. For legal entities, You'' includes any entity which controls, is controlled by, or is under common control with You. For purposes of this definition, control'' means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: License Question
The Mozilla Public License allows one to charge for executable versions of products built using MPL code. The source version of MPL code must always be available free of charge under the MPL. But one is allowed take that source code, compile it and sell the executables. this may be hard since others can do the same. But if you have the brand, or user base that will pay for this, then one is free to do it. And of course, one can combine MPL code with other code into a product and charge for the combined product; a number of companies do this. Mitchell David Johnson wrote: [EMAIL PROTECTED]">On Wednesday 20 June 2001 08:59 am, Stephane Routelous wrote: Hello,I'm a newbie in License considerations.Does exists an OpenSource license which allow to be paid if the Sofware isused in a commercial application ?Thanks, No there isn't. But it may be possible to use an Open Source license in conjunction with a closed license to achieve the same thing. It depends upon the nature of your software, and what you consider "commercial."Trolltech licenses its Qt library under a dual QPL/GPL license. The only way you can use it for your own software is to make your stuff open source. If you want to release closed source software using Qt, you must purchase the professional license for quite a few dollars.Commercial software is NOT the same thing as closed source. But 99% of it in the real world is. A scheme like Trolltech's may work for you if your software is used for the creation of other software.
Re: OpenLDAP license
Yes, that was our thinking. MPL source code must be available under the MPL. Once that is done, binaries can be licensed differently mitchell Derek Seabury wrote: [EMAIL PROTECTED]">Derek Seabury wrote: The MPL, for example, explicitly allows software executables to bedistributed under a license other than the MPL (MPL section 3.6). So it isperfectly possible to contemplate, say, a binary Mozilla distributionbeing distributed under a license prohibiting redistribution of thebinaries.This isn't true. MPL 1.1 section 3.2 states: Ooops. It is true... Thought I read source. So yes, you could prohibitpeople from distributing thebinaries but allow the code to go out. And in turn, anyone who got the codecould compile it anddistribute the binaries freely... so it doesn't seem to be a 'very bad thing.'--[EMAIL PROTECTED](617)428-May 2 is Global Speech Day! Join the First-Of-Its-Kind Web Event aboutspeech recognition technology. Hear industry experts. Access the largestvolume of information ever assembled on speech -- its powerful businessbenefits, its future and more. Information and registration athttp://www.globalspeechday.com--Derek.Seabury@! SpeechWorks.com(617)428-May 2 is Global Speech Day! Join the First-Of-Its-Kind Web Event aboutspeech recognition technology. Hear industry experts. Access the largestvolume of information ever assembled on speech -- its powerful businessbenefits, its future and more. Information and registration athttp://www.globalspeechday.com
Re: Modifying existing licenses in minor ways
The MPL is due for a revision before long. I'd like to make the revised version as neutral as possible for just this reason. mitchell [EMAIL PROTECTED] wrote: on Tue, Nov 28, 2000 at 12:25:56PM -0800, Adam C. Engst ([EMAIL PROTECTED]) wrote: Hey folks, A quick question. If you want to adopt an OSI-certified license to avoid the proliferation of yet more open source licenses, how do you deal with the fact that many of the open source licenses have specific language that doesn't make sense if used by any product other than what the license was generated to address? This is an issue I've brought up with several parties, including Mitchell Baker of Mozilla and Danise Cooper of Sun. It's more of an issue with copyleft-style licenses (particularly Mozilla) than with BSD/MIT style, as the latter allows mingling of licenses. My most recent suggestion, reiterated again, is this: - Draft a standard Mozilla-style license. Lets call it SMozPL. Nobody uses it. - What people *do* use is their own Derived Mozilla Public License, a DMozPL. This specifically restricts modifications to, say: Section 6.1, "New Versions" substitutions for "Netscape Communications Corporation", "Netscape", etc. Section 11, "Miscellaneous" Venue -- "California", "United States of America", "Northern District of California", "Santa Clara Count, California", etc. ...and any additional exhibits. - The common license provides that, for derived licenses limiting modifications to the specific substitutions specified, code is miscable between licenses. What this does is allow for use of common licensing terms while reserving to a particular organization the right to modify its terms (and break compliance) at a later date. Another option is to dual-license under some license, say MozPL, and the GNU GPL and/or LGPL. In this case, two MozPL-style licenses could share code under the terms either of the "separate files" provisions of MozPL-style licenses or the GPL. The latter would, however, have the effect of making downstream versions of the work essentially GPLd. For instance, in the Python license, item 1 starts "1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives" How could anyone else use that license without changing it, since CNRI wouldn't be involved in other products? CNRI may not be particularly involved in Python at the present time either, but that's another story. Python has essentially a BSD-style license. Provided no incompatibilities were introduced (e.g.: specific exclusion of works covered under the Python license), a license replacing organizational references should be compatible. Similarly, the Apache license says "The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."" But that makes no sense if another product were to use the Apache license. The new BSD license is more forgiving in this regard. IANAL, this is not legal advice.
Re: Free documentation licenses
We're also trying to figure out a documentation license for the Mozilla Project. One reason we've talked about using the same license for documentation and code is that it can be difficult to separate the two. For example, the Help documentation is included in electronic format as part of the source code. It seems odd to treat this documentation under one license in this format and under another license if it's printed. And even odder to say that the help documentation in the code is not governed by the MPL, but by a different documenation license. Has anyone sorted through this type of problem? Apologies if this has been discussed and I missed the thread. Mitchell John Cowan wrote: [EMAIL PROTECTED] wrote: No, it is specific to documentation, so long as the documentation doesn't incorporate code from the project. My point was that it is convenient for documentation and software to be under the same license, so that the same set of persons can make revisions to both in synchrony. If the software were BSD and the doco GPL, then if I make a proprietary version of the software, then I have two unpalatable alternatives: write a manual for the proprietary version from scratch, or issue the manual for the proprietary version under the GPL. If the software were GPL and the doco BSD, then if anyone rewrote the doco for greater clarity or some such, then he would be able to make the improved version proprietary and prevent it from being distributed with current or future releases of the program. Software and its accompanying documentation are generally considered two seperate works. There is no licensing compatibility requirement between the docs and the code. Even where short samples of code could be used in the document, they could be incorporated under fair use 107 exemptions or (possibly) by turning the document as a whole into a collective work. I agree; my argument speaks to expediency, not necessity. I don't believe there's anything in the GNU GPL, e.g., which prohibits publishing of the source code within a book, so long as the source itself is clearly identified as GPLd. I can't see this. A book which incorporates all of another textual work strikes me as a paradigm case of a derivative work. IANAL, but such a book looks clearly derivative of the source code and as such would have to be published under the GPL. Your example is backwards: newBSD/MIT software can be relicensed under GPL. GPLd software cannot be relicensed, by third parties, under any other license (barring GPL versioning allowances), without specific authorization from the copyright holder(s). The term "relicense" should be avoided, as it leads to wifty thinking. No one but the copyright holder can "relicense" anything, in the sense of changing the license. You can create a *derivative* work containing BSD parts and GPL parts, and license the whole work under the GPL. You cannot license the whole work under the BSD license. You also cannot change the licenses of the parts. In particular, I can extract a BSD-licensed component from a GPL-licensed work and use it in derivative works under the BSD license.
Re: License for JavaScript applications
Also, the MPL define the source version as the "preferred form for making modifications". We used this definition precisely to pick up setting like you describe. So the MPL would work fine if you like the license. When we wrote the MPL, we adopted this idea (of source as the preferred form for making modifications) from GPL practices. So I assume the GPL works the same way. But I don't claim to have particular knowledge for the GPL, others are far more knowledgable than I about the GPL. Mitchell Baker John Cowan wrote: [EMAIL PROTECTED] wrote: However, every license I have looked at so far makes the assumption that the application has "binary" and "source" versions. I think that there is no problem under any open-source license, since in no case is binary distribution compelled; it is simply allowed provided source is distributed also. So there is no problem with saying that in your case the binary and the source are the same thing. -- Schlingt dreifach einen Kreis um dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
