RE: Approval Requested for AFL 1.2 and OSL 1.1
What happens if you, in the USA, prepare a derivative work based on two OSL licensed pieces of code, one from, say, Taiwan, and the other from France. You are obligated under two licenses, one from the licensor in Taiwan and the other from the licensor in France. Nothing unusual here with respect to the OSL. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
Henry Pijffers wrote: However, suppose big US company didn't register to do business anywhere in Europe, and just licensed some open source software to me through the Internet, and later decides to change their mind, then how can I defend my rights on anything I did with their software (assuming I didn't do anything illegal)? I am not aware of any Open Source or Free Software license that handles this situation. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
You are obligated under two licenses, one from the licensor in Taiwan and the other from the licensor in France. Nothing unusual here with respect to the OSL. Two licenses with different effective terms; there is not one OSL, but one for each of the 100+ countries in the world. It means you need to know whose bit of the code you are actually modifying, something that, in real life, is likely to be difficult to do, unless the licence requires that derivative works only be distributed as patches to the virgin code. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Approval Requested for AFL 1.2 and OSL 1.1
From: Larry Rosen You are obligated under two licenses, one from the licensor in Taiwan and the other from the licensor in France. Nothing unusual here with respect to the OSL. From: David Woolley [mailto:david;djwhome.demon.co.uk] Two licenses with different effective terms; there is not one OSL, but one for each of the 100+ countries in the world. It means you need to know whose bit of the code you are actually modifying, something that, in real life, is likely to be difficult to do, unless the licence requires that derivative works only be distributed as patches to the virgin code. Huh? I meant two instantiations of the same license. What makes you think the terms of the OSL are different, or will be interpreted differently, in those other countries? It is true that the OSL -- and all other licenses -- must be interpreted in light of the laws of the jurisdiction in which the case is brought. Will every court interpret every license the same way? Of course not. Even the GPL hasn't been tested in any jurisdiction. While the Berne Convention is adopted almost everywhere, there are local differences with respect even to copyright law. For example, some here have argued that the term derivative work means different things in different jurisdictions, and that term is all over the GPL too. What's the specific problem with enforceability of the OSL in Taiwan? France? UK? Please don't try to make the lives of open source licensors and licensees seem any more difficult than it needs to be. In most places around the world where it matters, open source software can be licensed consistently. I challenge everyone to identify any part of the OSL (or AFL) that is illegal in any country or will be enforced locally in a way different from the consensus expectations of the open source community. If we've got problems with those licenses, help me fix them, or at least let's warn people not to license software from The State of Unfreedonia. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
think the terms of the OSL are different, or will be interpreted differently, in those other countries? It is true that the OSL -- and The fact that you said that the choice of law was determined by the licensor; if it is unlikely to change, there will be less uncertainty for licensees if it is fixed as, say US law. As I see it, the only reason to need to specify that the law is defined by the licensor is that the interpretation *can* differ for different licensors (of which one program may have many). -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RPL 1.1--How do we do to move forward here.
Last Month, I posted the attached new iteration of the Reciprocal Public License(version 1.1). There were some criticisms of this license that were made, but I don't think anything showed that the conditions in the RPL were outside the OSI guidelines. What do we need to do to get approval on this license? RJB Original message: A while back, I submitted a license to this list a software license the we wanted to get approval on. We've rewritten the license-and hope that we've covered the objections that were raised then-so we'd like folks to take another look at it. Thanks for the previous input. RJB Justification for a New license The Reciprocal Public License (RPL) is a license derived largely from the Apple Public Source License or APSL version 1.2 and the GNU General Public License version 2. The LGPL and MPL were also referenced, as was the Jabber Open Source License. Our main goal in creating the RPL was to create a license similar in intent to the GPL with respect to being viral, but which did not include a privacy clause such as that found in the GPL. In particular, we wanted to ensure that consumers of RPL code were required to release their source code under the RPL subsequent to any deployment, internal or otherwise. We further wanted to create terminology surrounding the question of what code was covered that did not rely on terms such as linking etc. which are difficult to define in a world dominated by interpreted languages and virtualmachines. The RPL's use of the term Required Components addresses this issue while attempting to remain open to the integration of RPL-based code with code from other licenses. One additional goal was to create a license that could be used by other parties in licensing their code, therefore we've attempted to limit references to a specific company and provided for the construction of derivative licenses whose only modification is to the Notice required in each source code file, as well as other license derivatives so long as they are renamed to avoid confusion. We feel the RPL is compatible for use with other open source licenses. First, the RPL makes no claims on code which is not authored by the licensee. For code which is authored by the licensee there are a few scenarios. If the new code wouldn't be covered by another license the RPL applies and the new code is inherently governed by the RPL. When code authored by the licensee is a derivative work of code licensed under a different license, the RPL requires that the new code be dual-licensed such that both licenses may be honored while ensuring that a pure-RPL version remains available to all parties. When, for some reason, a conflict in license terms would still exist the RPL specifies that the licensee should contact the Licensor for permission to resolve the conflicting terms in a fashion which remains consistent with the intent of the RPL. See Section 6.6 for specific wording here. === RECIPROCAL PUBLIC LICENSE Version 1.1, November 1, 2002 Copyright (C) 2001-2002 Technical Pursuit Inc., All Rights Reserved. PREAMBLE This Preamble is intended to describe, in plain English, the nature, intent, and scope of this License. However, this Preamble is not a part of this License. The legal effect of this License is dependent only upon the terms of the License and not this Preamble. This License is based on the concept of reciprocity. In exchange for being granted certain rights under the terms of this License to Licensor's Software, whose Source Code You have access to, You are required to reciprocate by providing equal access and rights to all third parties to the Source Code of any Modifications, Derivative Works, and Required Components for execution of same (collectively defined as Extensions) that You Deploy by Deploying Your Extensions under the terms of this License. In this fashion the available Source Code related to the original Licensed Software is enlarged for the benefit of everyone. Under the terms of this License You may: a. Distribute the Licensed Software exactly as You received it under the terms of this License either alone or as a component of an aggregate software distribution containing programs from several different sources without payment of a royalty or other fee. b. Use the Licensed Software for any purpose consistent with the rights granted by this License, but the Licensor is not providing You any warranty whatsoever, nor is the Licensor accepting any liability in the event that the Licensed Software doesn't work properly or causes You any injury or damages. c. Create Extensions to the Licensed Software consistent with the rights granted by this License, provided that You make the Source Code to any Extensions You Deploy available to all third parties under the terms of this License, document Your
Re: Approval Requested for AFL 1.2 and OSL 1.1
The amount of damages that courts would award might vary considerably from one jurisdiction to the next, even if the license is interpreted exactly the same way. Without naming any names wink, some countries are just more litigious than others; some courts, more punitive. - Original Message - From: David Woolley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 5:47 PM Subject: Re: Approval Requested for AFL 1.2 and OSL 1.1 think the terms of the OSL are different, or will be interpreted differently, in those other countries? It is true that the OSL -- and The fact that you said that the choice of law was determined by the licensor; if it is unlikely to change, there will be less uncertainty for licensees if it is fixed as, say US law. As I see it, the only reason to need to specify that the law is defined by the licensor is that the interpretation *can* differ for different licensors (of which one program may have many). -- 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: Express and implied warranties in software licenses
Thank you very much for clearing up my FUD. Well, I have never hidden the fact that I'm no legal scholar, and this is proof once again that a little knowledge can be a dangerous thing. I can only speak for myself, but between this and the discussions we had privately, I'm finally comfortable with the warranty. I would no longer let it stop me from using AFL in situations where I might currently use MIT or Apache-style licenses. bruce - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Bruce Dodson' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 2:59 AM Subject: Express and implied warranties in software licenses Bruce Dodson wrote: snip The other two concerns -- about whether I'm on the hook for other warranties besides the one that is offered explicitly (Magnusson Moss). You are repeating the notion, occasionally mentioned on license-discuss, that if an open source license offers any warranties at all then the implied warranties of merchantability and fitness for a particular purpose cannot be disclaimed. (See 15 U.S.C. §2308 [no supplier may disclaim or modify any implied warranty on a consumer product if such supplier makes any written warranty].) The Magnusson-Moss act deals with consumer products, meaning any tangible personal property which is distributed in commerce and which is normally used for personal, family, or household purposes (including any such property intended to be attached to or installed in any real property without regard to whether it is so attached or installed). 15 U.S.C. §2301. That does not include software because it is not tangible personal property. Software is intellectual property. If you combine software with a consumer product (e.g., a PDA or telephone), or distribute it on a tangible CD-ROM, arguably the entire consumer product would be subject to Magnusson-Moss rules. But the term written warranty in the act is defined as follows: (A) any written affirmation of fact or written promise made in connection with the sale of a consumer product by a supplier to a buyer which relates to the nature of the material or workmanship and affirms or promises that such material or workmanship is defect free or will meet a specified level of performance over a specified period of time, or (B) any undertaking in writing in connection with the sale by a supplier of a consumer product to refund, repair, replace, or take other remedial action with respect to such product in the event that such product fails to meet the specifications set forth in the undertaking, which written affirmation, promise, or undertaking becomes part of the basis of the bargain between a supplier and a buyer for purposes other than resale of such product. 15 U.S.C. §2301. I don't read the narrow express warranty in the OSL or AFL as meeting the criteria under either A or B. The notion that one runs afoul of Magnusson-Moss if a software license gives any written warranty whatsoever is not justified in law. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
