Re: OSD#5 needs a patch?
Okay, I guess I see that. I didn't see it as entirely a case of moral positioning. In the example that I created, if I were a member of ethnic group, I would feel like I were not as welcome to use the software as others are. Moreover, depending on what exactly was said, I might also find it repulsive to propagate the message by redistributing the program, whether I am a member of ethnic group or not. Thus it seemed to me that, when a licensor tries to discourage a person or group from using the software, it shouldn't matter whether they are trying to accomplish that through legal force or through insults and intimidation. However, I realize that argument must seem a little fuzzy, and perhaps a little too idealistic as well, for all of you lawyers :-). Thanks, Bruce - Original Message - From: Rick Moen [EMAIL PROTECTED] I'm pretty sure the OSD is concerned solely with licences' actual effect, not their attitude problems. - Original Message - From: Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] I will stop lurking for just a split second to say that I agree that the OSD is not a moral code. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD#5 needs a patch?
Well, the copy attached to Sean's introductory email (also on his web site) states among other things: ..the most expendable, unimportant engineers work on GPL software and the better software engineers work on BSDL-licensed software. In a gift economy / meritocracy like ours, that's just about the worst thing you can say about a group of peers. By the way I don't think Sean's a hateful person. I don't even think he cares whether anyone uses his license. I just think he was having some fun at our expense. Sincerely, Bruce - Original Message - From: Ben Reser [EMAIL PROTECTED] Newsgroups: gmane.comp.licenses.open-source.general Sent: Tuesday, October 07, 2003 1:27 AM Subject: Re: OSD#5 needs a patch? It doesn't seem to me that the OSSAL is making any discriminatory or derogatory statements in its DISCUSSION section. IMHO it's based on some misguided goals though. But that is an entirely different matter. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Academic Free License version 2.0
I think this change is mostly-positive. The only negative aspect that I see is that it's twice as long as the previous revision. AFL 1.2 had stricken a nice balance between brevity and precision. May I suggest that, alongside AFL 2.0, you publish one last license in the AFL 1.x series, based on AFL 1.2 but with the applicable OSL 2.0 revisions merged in, i.e. sublicenseable, and with the revised, more palatable Termination for Patent Action clause? In addition, considering how different the wording of AFL 2.0 is from 1.x (even though the effect is similar), and the fact that there may be projects using 1.x, please do not withdraw the AFL 1.x when 2.0 is approved. I would like to see them both in the list of approved licenses. - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] Newsgroups: gmane.comp.licenses.open-source.general Sent: Wednesday, July 16, 2003 10:05 PM Subject: Academic Free License version 2.0 To License-Discuss (and others interested persons on BCC): Version 2.0 of the Academic Free License (AFL) is hereby submitted for your review and for the approval of the OSI Board of Directors. It can be found at http://rosenlaw.com/afl2.0.html. Most academic-style licenses follow the BSD model -- short, generous and uncomplicated. [See http://opensource.org/licenses/bsd-license.php] Simply put, academic licenses permit derivative works to become a part of other software, including proprietary software, for any purpose whatsoever. Unfortunately, those licenses often omit many details, leaving to the imagination how certain things are to work in an open source/proprietary world. The AFL fills in those gaps. It addresses issues of patent, trademark, warranty, jurisdiction and venue, contributor recognition, etc., in ways entirely consistent with the BSD philosophy of open source. AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose wh atsoever, including to create derivative works. This new version of the AFL also helps eliminate possible confusion between academic-style licenses and reciprocal licenses [see, for example, the GPL, www.fsf.org/licenses/gpl.html, and the Open Software License (OSL), www.rosenlaw.com/osl2.0.html]. Reciprocity requires that any Derivative Works be licensed under the same license as the Original Work. Reciprocal and non-reciprocal open source licenses ought to be the same -- except with respect to provisions dealing with reciprocity. Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision. A redlined comparison of AFL2.0 and OSL2.0 is at http://rosenlaw.com/afl2.0-redline.pdf. When you suggest changes to the AFL, please consider how that language would read in the OSL, and vice versa. Suggestions regarding both AFL2.0 and OSL2.0 will be welcomed. Feel free to ask questions or complain here on license-discuss. The OSI board of directors needs your input before they decide whether to approve these licenses. In the meantime, I encourage you to think about using the Academic Free License version 2.0 instead of the BSD, MIT and Apache licenses, and their variants, that have proliferated on OSI's approved license list. /Lawrence Rosen Rosenlaw Einschlag, a technology law firm General counsel, Open Source Initiative 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * fax: 707-485-1243 email: [EMAIL PROTECTED] www.rosenlaw.com -- 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: Problems in Open Source Licensing
For cases 2 and 3: who is to say that I haven't, in the past, distributed the code to someone else and they happened to distribute a copy back to me? For that matter, did I really get it directly from you, or did I get it from someone else, who was redistributing it under the GPL? If you're trying to un-GPL something that you have previously GPL'd, you're going to have a very hard time suing anyone who has a copy of the code from before you did that. Best you can do is stop distributing it, and hope that your software was unpopular enough that no one else will bother to redistribute it either. - Bruce - IANAL - From: John Cowan [EMAIL PROTECTED] To: Jeremy Malcolm [EMAIL PROTECTED] CC: C. Hamacher [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Problems in Open Source Licensing Date: Mon, 17 Feb 2003 00:26:45 -0500 (EST) Jeremy Malcolm scripsit: [L]et's take the simpler case of releasing my own code under the GPL. Do you see anything that would prevent me from withdrawing those licensing terms? Short of contract or estoppel, and assuming that I adequately communicate the revocation of licence to my users, how can I be prevented from changing the licensing terms whenever and however I like? I think there are three cases: 1) Users who have already relied on the GPL to distribute or modify your code 2) Users who are at present relying on the GPL to distribute etc. 3) Users who intend in the future to rely on the GPL to distribute etc. As to case 1, I think you are pretty clearly estopped from doing anything about their existing distributions or modifications; they relied on your licensing terms in good faith. Case 3 users, OTOH, are screwed. Case 2 is obviously intermediate. (IANAL, TINLA) Licence conditions have to be reasonable, contract conditions don't. Excellent. That means the infamous MSOSL, which I bruited about onthis list a few years ago, can be freely dismissed. (This was a putative Open Source license which required the licensee to consume moose by-product as a condition of the license, for those of you who have mercifully forgotten.) -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --_The Hobbit_ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
historical permission notice and disclaimer - ready to go?
So, is this template ready to be put before the board and considered for approval? Is there anything that should change before this happens? Can I assume that, if someone was strongly against this template, I would have heard about it by now? One final question: should this be published with the documentation and examples that I put together for the approval process, or should it just be published in its bare form? http://www.geocities.com/brucedodson.rm/hist_pnd.htm For the list archive, here is the template in its absolute barest form, copied from the web page: -- copyright notice Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies[,] [and] that both [that] [the] copyright notice and this permission notice appear in supporting documentation[, and that the name [of] copyright holder [or related entities] not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission]. [copyright holder makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty.] [copyright holder DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS[,][.] IN NO EVENT SHALL copyright holder BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.] -- Regards, Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: approval request: Historical Permission Notice and Disclaimer
So far, no discussion. Is that a good thing or a bad thing? http://www.geocities.com/brucedodson.rm/hist_pnd.htm Regards, Bruce - Original Message - From: Bruce Dodson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 12:11 AM Subject: discuss: approval request: Historical Permission Notice and Disclaimer [ Please discuss this template. It's a clever idea. You'd have thought that someone would have thought of it before. Bruce has sent a few changes since his submission. Please consult his web page (URL at bottom) for the exact current submission. -russ ] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
discuss: approval request: Historical Permission Notice and Disclaimer
[ Please discuss this template. It's a clever idea. You'd have
thought that someone would have thought of it before. Bruce has
sent a few changes since his submission. Please consult his web page
(URL at bottom) for the exact current submission. -russ ]
I would like to ask that the following permission notice
template be approved by the OSI board.
This template is distilled from a permission notice that is
used in many packages, including two that I work with in my
own open source contributions: Scintilla, and OGDI (Open
Geospatial Datastore Interface). A better known example of
this template is the CWI Permission Notice on Python 1.5.x.
The license for ATT / Lucent AWK also follows the pattern.
Python is now under a different, OSI-approved license.
However, so many other packages remain under this style
of permission notice, and some of these will never
change their license. Thus it is important to recognize
this template so that these packages can be acknowledged
as OSI certified open source software.
Also, more to the point for my own interest in this
template: Suppose I distribute a work that includes
code that I licensed under this style of permission
notice. I want to be able to put my own code under
AFL, affirm that the CWI-style permission notice still
applies to the library that I used; and call the
package as a whole OSI Certified.
I am suggesting the name Historical Permission Notice
and Disclaimer, since it implies that this template
isn't really intended / recommended for new software,
but is meant to acknowledge software that has
historically been licensed under these general terms.
Explanation of the Template:
Angle brackets hold fields, e.g. copyright holder.
If a field appears more than once, subsequent appearances might
use a short form of the same name. The CWI notice for Python
1.5.x is an example of a case where this was done.
Square brackets hold optional text, e.g. [or related entities].
Squiggly braces hold alternative spellings for some required
word. This is to try to accomodate trivial variations such
as are found in the Scintilla license. e.g. {the|that}.
A license can have variations in capitalization and
whitespace, and still be considered an instance of this
template.
The template:
-BEGIN-
[license name]
Copyright [(C)] year(s) [by] copyright holder[.]
[All rights reserved][.]
Permission to use, copy, modify and distribute this software and
its documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies, [and]
that both {the|that} copyright notice and this permission notice appear
in supporting documentation[, and that the name [of] copyright holder
[or related entities] not be used in advertising or publicity
pertaining to distribution of the software without specific, written
prior permission]. [copyright holder makes no representations about
the suitability of this software for any purpose. It is provided as
is without express or implied warranty.]
[copyright holder DISCLAIMS ALL WARRANTIES WITH REGARD
TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS{,|.} IN NO EVENT SHALL
copyright holder(s) BE LIABLE FOR ANY SPECIAL, INDIRECT
OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.]
-END-
Since this template is meant to retro-fit onto existing
licenses, there's little room for negotiation on the
wording. The notice has ambiguities that make it hard
to recommend when licenses like AFL are available, but
these can't be fixed, or the template would not fit the
existing licenses any more. (This template is clearly
for old software, not new software. That much is
evident in the name.)
There may be other licenses which are practically
identical to this one, but which differ in some tiny,
inconsequential way. Discussion on license-discuss
might reveal ways to easily accomodate these. (An
example: Scintilla uses and that both that license
and ..., while most other instances use and that
both the license and...) However, it is unlikely
that we will accomodate every possible nuance in
version 1 of this template. The 20/80 rule applies.
I think I have handled the most common variations
in this draft.
In accordance with the approval process, I've placed
a copy of the license on a web web page:
http://www.geocities.com/brucedodson.rm/hist_pnd.htm
_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Duemetri Public License (DPL) Version 1.0
The pain you speak of, is this from a purely legal stand point? If so, in what manner does it hinder or cause pain to an end user? I'm not a lawyer so I never speak from a legal standpoint, even when I'm talking about licenses. The pain is from a technical standpoint. If I make a modification that I think others would also enjoy, I had better hope the project team accepts it into the core; otherwise it will be not only onerous for me to maintain (just ask Christian Tismer), but also onerous for the end user to build from source. (The same end user who might be quite comfortable following instructions that say type configure; then type make; then type make install, might be deeply mistified by tools like diff and patch.) What this constraint does accomplish is that if deep philosophical differences leave one with no choice but to fork (q.v. XEmacs), it makes it much harder for the forkers to succeed in taking mindshare away from the original developers. But if the original developer abandons the project, it also makes it more difficult for the code to take on a life of its own, and find another owner to care for it. My dislike of QPL does not apply to QT itself, since Troll Tech is kind enough to make that available under GPL as well. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Request for license approval...
Is it true that changing proper names is not a problem? I had always been of the impression that, e.g. I couldn't just use the Apache License, change the proper names, and call my software OSI Certified. - Original Message - From: John Cowan [EMAIL PROTECTED] I urge you instead to see if you can reuse one of the 39 existing licenses (generally speaking, changing proper names in them is not a problem). That way you will not add to the queue and you will be able to call your software OSI Certified right away. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
time frame between request for approval and acknowledgement of request?
What should one expect as a reasonable time period between the sumission of a license-approval request, and some acknowledgement that the request has been made? -- Background: On November 6, I wrote to license-discuss suggesting that the style of permission notice used in Python 1.5, OGDI, Lucent AWK, Scintilla, etc. should be considered for approval by the board. On November 9, I made a formal request to that effect. A draft of the template is here: http://www.geocities.com/brucedodson.rm/hist_pnd.htm I structured the request as a template so that it would match the minor variations in wording / punctuation / proper names in these OSD-compliant licenses. Otherwise I would have to make a separate request for each license. The board is already overworked, and so am I. -- I realize the actual time to discuss the license and process the request will vary from one case to the next, and can be months. However, I just want to know that I'm in the queue. Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: time frame between request for approval and acknowledgement of request?
I understand that, Russ, and I have a great respect for the work that you do. The role of filter is not a glamorous one. It certainly isn't a job that I would want, and yet there you are, doing it. I was just looking for an ACK that my email hadn't been eaten by your junk mail filter or whatever. Now I have that. Thank you; now I can go back to waiting, more patiently than before. I'm a volunteer, Bruce, with a TODO list longer than your arm. The problem with license submittals is that I try to pre-vet them, so that the license-discuss people don't have to waste their time with licenses that are obviously unacceptable. Yours has not been pre-vetted yet. It will be. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | it's better to be free 521 Pleasant Valley Rd. | +1 315 268 1925 voice | than to be correct. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Duemetri Public License (DPL) Version 1.0
The QPL uses the same tactic to control distribution of customized versions of Qt. But this creates is a pain for developers and end-users alike. At least your term #8 provides an alternative, changing this requirement to distribute patches into something that's optional. But it's confusing the way 7 and 8 seem to contradict one another. As a licensee, I would be scratching my head, unsure whether I was compliant or not. Please consider dropping term 7, and simply leaving term 8. Given the choice, most developers would choose that option anyway, because distributing patches creates extra burden for the end-user. Even term 8 creates a difficult situation. You have a license whose first line says, The software is called RAINBOW, and then says that for modified works, The software must not be called RAINBOW. If I were you, I would check out the AFL 1.2. That version might not have been approved yet when you made your request. Depending on what business requirement points 7 and 8 of your license are meant to serve, you might find that the AFL's Attribution Rights provision can be leveraged to deliver the same business value in a different way. Then you'd have a professionally written license, you wouldn't have to go through a long drawn out process to try to get your license approved, and you can get on with writing your software. - Original Message - From: Graziano Poretti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 21, 2002 12:01 AM Subject: discuss: Duemetri Public License (DPL) Version 1.0 [ Please discuss this license. Graziano reports that the only change from the Zope license are terms 7 and 8. -russ ] hi we would like to start an open source project on a product called rainbow. the 1st version of the license is at http://www.duemetri.it/licenza.htm http://www.duemetri.it/licenza.htm the most similar license is the ZOPE public license. the changes occur for the Integrity of The Author's Source Code - point #4 of OSD. according with this point, we prefer that the free distribution of source and binary would be granted with the release of official versions and modifications can be installed using the patch files only. the developers community will check and test all the patches in order to release the new official version including all new features (tested and with a sufficient documentation). thanks for ur time ... sincerely --- Graziano Poretti - DUE METRI http://support.facile.duemetri.net http://support.facile.duemetri.net/ - Per creare e gestire un portale in 20 minuti http://www.duemetri.it http://www.duemetri.it/ tel.: 0039 184 42163 Fax: 0039 184 462673 -- License follows Duemetri Public License (DPL) Version 1.0 1. The software is called ``RAINBOW'' 2. This software is Copyright (c) Duemetri sas (tm) and Contributors. All rights reserved 3. Redistributions in source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 4. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 5. The name Duemetri sas (tm) must not be used to endorse or promote products derived from this software without prior written permission from Duemetri sas 6. If any files are modified, you must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. Disclaimer THIS SOFTWARE IS PROVIDED BY DUEMETRI SAS ''AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DUEMETRI SAS OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 7. The official version of the product will be released by Duemetri sas. The distribution of the modified product in source or binary form is allowed as official version and ``patch files''. 8. The distribution of modified versions of the software without using ``patch files'' is allowed. In this case is fobidden to use the term ``Rainbow'' as the name (or part of it) of the product -- License ends -- 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: [kmself@ix.netcom.com: Re: We are looking for an open source licensethat...]
Just remember, if I can't sell your stuff, it ain't open source. extrapolate some of the benefits of the GPL. I have worked for companies that will not use free software for fear of tainting their development efforts and having their propietary code made free. [CFC] Yes, there are companies like that. Their fear is their loss, and for most open source software it's unfounded. There are also companies who have opened their source just so that they can gain access to code which is only available under GPL. You can't hold onto your custodianship of this technology through licensing restrictions. [WBD] I think you mean and still release the product as open source, because today we do a perfectly good job of retaining our technology through licensing restrictions. [CFC] That's right. I meant, if you want to call your license an open source license, you can't... So, you believe reinventing the wheel is a good thing (as long as the reinvented wheel is an open one (and the old wheel wasn't))? [CFC] That's what many of us believe, yes. It does lead to some good things, like Linux. so far, no one has offered to pay me what I expect as a salary and allow me to write the software that I want to write and also give it away, and I don't really expect... [CFC] If you're serious about this, tweak your expectations. -bruce _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [kmself@ix.netcom.com: Re: We are looking for an open source licensethat...]
From: Chris F Clark [EMAIL PROTECTED] It is more to discourage commercial users from using the open source version. [CFC] I don't know if you're going to see much support here for a license that discourages use of the open source version, by any particular group. We want to encourage the use of open source, not only by those who are already using it, but also by newcomers. However, we do not wish to deprive open source developers the bounty of our labor and have no qualms their using our tool to build open source programs that they give away. [CFC] What you seem to be suggesting is what FSF calls semi-free. http://www.fsf.org/philosophy/categories.html#semi-freeSoftware Then by protecting your revenue stream, you would be depriving us of the full bounty of our own own labors. Use of your software would be a poison pill, that prevents us from selling the the open source programs that we build. (Some of us will never sell our software, but all of us, and all of our licensees, retain that option.) We make a certain profit by being the sole provider of this software and we cannot afford to have that revenue stream dry up completely. [CFC] You can't hold onto your custodianship of this technology through licensing restrictions. If you open-source your technology, there are two ways to keep ownership of the project: (1) adopt a cooperative attitude; work with the community while continuing to maintain yourself as the leader in this technology. (2) hope that no one else is interested in it. Netscape has done it right with Mozilla.org. Borland/Interbase has not, and so there is Firebird. ...Rational Rose... [CFC] If Rational started giving away Rose gratis for open source development, while still maintaining it as non-open software (whether that is by closed source, shared source, semi-free), I believe it could hurt the open source community, since it could take mindshare away from legitimate open source CASE projects like ArgoUML. -bruce _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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
Re: Approval Requested for AFL 1.2 and OSL 1.1
From: Mike Nordell [EMAIL PROTECTED] Bruce Dodson top-posted: Derivative Works means derivative works based upon the Original Work, as upposed to derivative works based upon Marvel Comics characters, or derivative works based upon previously-unreleased Elvis tracks. Since the definition of this isn't yet established in the license text, how would I know? If you take out the parenthesized Derivative Works, the license reads derivative works based upon the Original Work, just as I said. Anyway I was just stating my opinion as a layman who is NOT confused by this license. (That doesn't mean I would use it. That will not happen for either of these licenses until I see some open discussion that makes me comfortable with the warranty.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Plan 9 license
I disagree. (I know, I do that a lot, but I mean well.) It's best if licenses are simply either approved or not approved. There is no list of licenses that have been rejected or withdrawn; that would be punitive. By the same token, there should be no special status given to licenses in limbo. Perhaps OSI would list licenses that have ended in limbo (neither rejected nor approved) and/or list licenses that claim to be open source but which are not (yet) certified by the OSI. -- ralph -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
a template for the CWI permission notice (Python 1.5.x) and similar licenses
I would like to suggest that a license template like the one below be put forward for approval by the OSI board. This is not really intended for new software. Nevertheless it's pragmatic to approve it since many OSD-compliant licenses follow this template. Examples include Scintilla/SciTE, Lucent AWK, OGDI, Python 1.5.x, and derivatives. This is not a license that we would recommend for new software - for that, AFL will do a better job. (Heck, MIT would do almost the same job as this new template, and is already approved.) However, I want to be able to use components licensed under these terms, combine them with other open source software (say, stuff I write and license under AFL), and still call the result OSI certified. Explanation of the Template: Square brakets hold optional text. Angle brackets hold fields, as usual. If a field appears more than once, subsequent appearances might use a short form, e.g. see copyright holder in the Python 1.5.x and in the AWK license. Small variations in capitalization and whitespace do not matter. The template: [license name] Copyright [(C)] year(s) [by] copyright holder[.] [All rights reserved][.] Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies, [and] that both the copyright notice and this permission notice appear in supporting documentation[, and that the name [of] copyright holder [or related entities] not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission]. [copyright holder makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty.] [copyright holder DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL copyright holder(s) BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.] Examples of licenses that follow this template: -- License for Scintilla and SciTE Copyright 1998-2002 by Neil Hodgson [EMAIL PROTECTED] All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * This license omits the optional no-endorsement clause, and includes the long disclaimer. It also has a typo, I think (and that both that copyright notice) but maybe it was intentional; if so I suppose it could be incorporated into the template. --- License for ATT AWK Copyright (C) Lucent Technologies 1997 All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that the copyright notice and this permission notice and warranty disclaimer appear in supporting documentation, and that the name Lucent Technologies or any of its entities not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * This template includes the no-endorsement clause and the long disclaimer. --- License for OGDI - Open Geospatial Datastore Interface Much of OGDI is implicitly or explicitly under the following two licenses (year varies a bit): Copyright (C) 1995 Logiciels et Applications Scientifiques (L.A.S.) Inc Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided
Re: Approval Requested for AFL 1.2 and OSL 1.1
It seems clear to me, yet another non-lawyer:
Derivative Works means derivative works based upon the Original Work, as
upposed to derivative works based upon Marvel Comics characters, or
derivative works based upon previously-unreleased Elvis tracks.
Prepare - it doesn't say to prepare yourself to create [Derivative
Works]. It says to prepare [Derivative Works]. Like when you're
preparing dinner - after you have finished preparing it, you have something
that you can eat. No offense, but Duh.
Cheers,
Bruce
- Original Message -
From: Mike Nordell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 05, 2002 10:56 PM
Subject: Approval Requested for AFL 1.2 and OSL 1.1
From my wording, I think it's quite obvious that IANAL.
Lawrence E. Rosen wrote:
[link to OSL 1.1]
I must say, I read just down to 1 b) before I got hickups.
to prepare... What is prepare? To fork a CVS copy in preparation for
some
real work? To... I don't know.
No, the prepare phrase is way too vague for me to like it - especially
since it seems to be completely superfluous. Why would I need a grant to
prepare something? Someone is going to look over my shoulder to say Hey
there, it looks like you're 'preparing' derived works here!. Someone is
going to dissect my brain while it's running and say It seems like a
preparation... for even _thinking_ of doing something (which is a form of
preparation).
I think you should either reword or just drop it.
What would happen if to prepare was replaced with to create? That
wouldn't try to forbid people to even think, would it?
I also have complaints about the 100% reduncance in explaining that
derivative works is _really_ ('Derivative Works'). I believe it is a
great merit to explain something before it's used. In this case
derivative
works (capitalize however you like) could be explained before it was
used.
That would 1) obviate the need to write it twice in the same point, 2)
make
(reasonably) sure the reader knew what it was.
Besides that? Actually, that was enough for me to stop reading. Sorry
Lawrence, I'm sure you put great effort in creating this, but this
developer
didn't agree even with pt 1.
/Mike
--
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: a proposed change to the OSD
I can offer something without entering a relationship with each recipient. I have software published on SourceForge; I entered into an agreement with SourceForge but I have no relationship with the people who downloaded my stuff from there. The people who downloaded might or might not have a relationship with SourceForge; that is no concern of mine. Likewise with Tripod, and other places where I have published stuff. Mahesh, you're switching back and forth between liability and warranty, using the words interchangeably, which is confusing. Warranty is a product that can be offered or not offered. Implied warranties are an implicit part of another product (which can be expressly excluded in many places). Liability is not a product to be offered; it's a completely different beast. If there is no contract, you can't contract away liability. But if there's no direct relationship between you and the recipient (such as a contract), it's hard to conceive of a way that you could be held liable in the first place. At least I, a mere software developer, cannot conceive of one. As for warranty, I was sure that I can always say I'm offering something as is. That's just a statement that I'm not offering any warranty products in addition to my software product. As for implicit warranties of merchantability etc., I will always use a license that says those don't apply, but why should the recipient care about merchantability if they didn't buy it? (And if they did buy it, they probably have a contract with whoever sold it to them, but not with me because I wasn't involved in the transaction.) THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW - I'm guessing the GPL says that for other reasons, that have to do with the fact that some jurisdictions don't let you remove the implied warranties of merchantability and fitness. I doubt this matters much for the software that FSF gives away, although it might make a difference for the CDs that they sell. I am only guessing. - Original Message - From: Mahesh T Pai [EMAIL PROTECTED] To: David Johnson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 02, 2002 5:10 AM Subject: Re: a proposed change to the OSD David Johnson wrote: I still haven't come to grips yet with the concept that a contract is required for disclaimers of warranty. It seems to me that there must be another mechanism that achieves the same result. You have to make the terms under which you are offering something clear. Situations where a single person (eg. a software developer) entering into relationships with several persons ( eg, by distributing several copies of the same s/w) on same terms (that is, under the same license) are not always treated as *pure* (mark the word pure) contractual by courts - at least, in the common-law world. When you disclaim liability you have to make such disclaimer it clear and tell the court that you have informed the recipient of s/w that he knew, at least you took sufficient steps to inform the other guy about the existence of the disclaimer. If the relationship is contractual, this disclaimer will help you, if not, (status based) nothing will. That is why, the GNU GPL (and most other licenses) use the phrase THERE IS NO WARRANTY FOR THE PROGRAM, TO THE *EXTENT PERMITTED BY APPLICABLE LAW* in paragraph 11. Regards, Mahesh T Pai. -- 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: a proposed change to the OSD
Thanks John and Larry. Now I am starting to see. That's very frightening to think about, but I still find it hard to believe. With the manufacturer / retailer situation, the manufacturer got paid for the goods, and there was a chain of contracts even though there was no privity between manufacturer and final recipient. Does all of this apply equally to my situation, where I am making the software available purely as a gift? (I realize others among us are selling their open source products, and I have no problem with that, but that's not what I'm doing.) -- Forget about privity for a second. That's a red herring. My cat just strolled in, so now I have other things on my mind: Someone gave this cat to me; she was free to a good home. They said she was healthy, and it turned out they were right. If I found that she had some health problem when I got her, could I have expected the original owners to pay the veterinary expenses based on some theory of implied warranty? If I had decided to return her, could I have expected to be compensated some amount so I could buy a replacement cat from Pets R Us? Don't be stupid, Bruce, of course not, says my conscience. Does the law disagree? Also, does it give a different answer for software than for cats? - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'John Cowan' [EMAIL PROTECTED]; 'Bruce Dodson' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'David Johnson' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, November 02, 2002 8:15 PM Subject: RE: a proposed change to the OSD That used to be the law. But people got tired of buying useless and/or dangerously defective products from stores and getting this answer: Store: I had no way to know it was useless/defective: try the manufacturer. Manufacturer: You and we have no privity of contract: try the store. So after enough people got angry enough, the law was changed. Now manufacturers are liable for the useless/defective products they produce *to the ultimate consumer*, under a fiction of implied warranty: the manufacturer is deemed to have issued such a warranty whether he has or not. The warranty disclaimer is an attempt to dispose of this obligation, and 1) it may not work at all in some jurisdictions, and 2) it surely will not work unless the manufacturer SHOUTS it at the consumer in an unmistakable place. Yes, what John says is true. And so we find ourselves in a situation where manufactured products intended for consumers are covered by mandatory warranties under federal law. (Even some products that contain Linux software in them!) And there are effective product liability and consumer protection statutes in nearly all states that make manufacturers and distributors liable for the crap they foist on the unsuspecting public. Someday UCITA may do these things for software. Do you want that? Do you want the open source community to try to influence the shaping of laws like UCITA? For those who fantasize a different kind of world, let's make it so. In the meantime, we're stuck with contract law the way it is. Or at least the way it is in the US. How is it different in other countries? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSL 1.1 treatment of documentation
I took it to mean any technical documentation which is provided by a licensor, which may make the source code more accessible to a licensee. Then you would be compelled to provide such documentation as was provided to you when you received your copy of the source code. So, access in the sense of making source code accessible. That's my interpretation as a layman; it might not be the same one that Larry had in mind. However I think it could be spelled out more clearly. If you use excerpts of that that documentation in a book, and the documentation was considered to be under OSL, then it seems you would have to make the full text available under OSL. Is that right? Then, Forrest's question: what about a book that isn't a derivative work? Could contract law and some technically inept judge compell the book publisher to release the book's source code (DocBook / TeX / whatever) under OSL? - Original Message - From: Forrest J. Cavalier III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 1:53 PM Subject: RE: OSL 1.1 treatment of documentation Lawrence E. Rosen [EMAIL PROTECTED] wrote in part: 3) Grant of Source Code License. The term Source Code means the preferred form of the Original Work for making modifications to it and all available documentation describing how to access and modify the Original Work. access is not well-defined. Is your intent to compel book publishers to give away the text of their books written for users of the Work? No, and I don't think the word access conveys that meaning. accessed appears in OSL 1.1 paragraph 5. And it seems that use is different than access. Can you explain what you meant in each paragraph? -- 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: OSL 1.1 treatment of documentation
(Larry said...) Not if it ain't a Derivative Work, I'd say. ... What do you think? I think the same. Common sense tells me that a book that isn't a derivative work should be outside the scope of the contract. This concept is probably non-technical enough that even a judge would be able to grasp it. (Forrest said...) Seems to me by the OSL paragraph 3, a book publisher is compelled to include a machine-readable copy of their book if they provide a copy of the Original work. Common sense also tells me including the software on a CD in the back cover of a book doesn't make the book a derivative work - it just makes the book a distribution medium of sorts. Larry: Although common sense seems to lead to the right answers, it is true that the wording is cumbersome. Maybe the problem is that it's hard to define which documentation you mean without creating a self-referencing definition for Source Code. Then perhaps it would be easier to make this clear if you defined two terms, so the Technical Documentation is not part of the Source Code, but must also be included. That could look something like this: The term Source Code means the preferred form of the Original Work for making modifications to it. The term Technical Documentation means all available documentation describing how to access and modify the Source Code. Licensor hereby agrees to provide a machine-readable copy of the Source Code and Technical Documentation along with each copy of the Original Work that Licensor distributes. Licensor reserves the right to satisfy this obligation by placing a machine-readable copy of the Source Code and Technical Documentation in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work, and by publishing the address of that information repository in a notice immediately following the copyright notice that applies to the Original Work. (Hey, it's just a thought. I ain't no lawyer.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Revised versions of the OSL and AFL
I like the revised AFL. It's getting to the point where I may even use it. I have just one concern, and that is with the warranty of copyright which appears in both of these licenses. I think there must be a better way to achieve that - it smells like a cludge to me - but since I'm not a lawyer I won't venture any ideas. It would be very helpful for me (and I assume for some others) to see some public discussion of how / whether this warranty would work in practice. If a discussion like that happens here, I promise to stay out of it! Bruce - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 12:44 PM Subject: Revised versions of the OSL and AFL New versions of the Open Software License (OSL) and the Academic Free License (AFL) are now available for your review. They are posted at: www.rosenlaw.com/osl1.1.html www.rosenlaw.com/afl1.2.html Both licenses now contain an Attribution Rights provision. Other minor changes have been made to clarify the language and to make the licenses (a little) easier to read. /Larry Rosen -- 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: Moral Rights (was Simplified Artistic License (A Proposed Compromise))
I don't know if this is quite what Larry was saying, but I for one consider it an unfair tactic to try to discourage RSW from seeking approval. Russ and other board members may think he is misguided in believing that others will want to use his license, and might even be right, but that does not change your obligation to approve his license if it is OSD compliant. RSW he has shown a lot of patience, and has been flexible in incorporating requested changes (even those that have nothing to do with OSD). Nevertheless his mounting frustration has also shown through at times, and I empathize. For what it's worth, I think his license is better for having gone through this process. Once any remaining significant issues are worked out you should approve his license. That said, I think RSW might benefit from seeking some professional legal advice before requesting final approval, just to make sure that the license that gets approved is one that truly meets his needs. Question: can the OSI's approval process be changed so that OSD-compliant licenses are approved, but not automatically published on the website? i.e. 8. Once we are assured that the license conforms to the Open Source Definition and has received thorough discussion on license-discuss or by other reviewers, and there are no remaining issues that we judge significant, we will notify you that the license has been approved. At our discretion, we may also publish a copy of the license on our website. - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] I am unhappy with the current status of this request. Robert Samuel White (RSW) is absolutely within his rights to obtain approval for his license if it satisfies the published criteria on OSI's website. Russ Nelson is also absolutely correct in worrying, as do all members of the board of directors of OSI, about the proliferation of licenses that only serve to confuse and confound the community. -Original Message- From: Robert Samuel White [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 2:18 PM To: 'Russell Nelson' Cc: [EMAIL PROTECTED] Subject: RE: Simplified Artistic License (A Proposed Compromise) I've decided to just forget it. I'm going to use my license and forget about OSI approving it. I didn't want this much controversy. I was very patient and listened to every one's comments on the list, and I adjusted my license as recommended, all with the misguided belief that my license would be approved as long as it met the conditions of the OSD. I support OSI, the OSD, and the open source community. So I guess this is the end. Have a wonderful life and keep up the good work. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Procedure for using an approved license
For what it's worth, so far Netscape has been very responsible and careful about not making ad-hoc changes to their license. Look at the trouble they've been going to recently, to try and get all of their code MPL/GPL/LGPL tri-licensed. It would have been easy to take advantage of their right to change the license, to streamline this process, but they did not. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Moral Rights (was Simplified Artistic License (A Proposed Compromise))
You misunderstood me, Larry. I was not saying that YOU were trying to discourage RSW from pursuing approval. On the contrary I was surmising, without putting words in your mouth, that you'd agree that this would be unconscionable. As for Russ and others, I don't have any opinion on what they said. Too much was said in private email for me to form an opinion. I can only look to the result, which was an RSW discouraged to the point where he was ready to say have a nice life and walk away. Bruce - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Bruce Dodson' [EMAIL PROTECTED]; 'Robert Samuel White' [EMAIL PROTECTED]; 'Russell Nelson' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, October 06, 2002 9:00 PM Subject: RE: Moral Rights (was Simplified Artistic License (A Proposed Compromise)) I don't know if this is quite what Larry was saying, but I for one consider it an unfair tactic to try to discourage RSW from seeking approval. Russ and other board members may think he is misguided in believing that others will want to use his license, and might even be right, but that does not change your obligation to approve his license if it is OSD compliant. That certainly wasn't what I was saying, and I don't think it was what Russ and the other board members were saying. We've all said many times that, if RSW's license is OSD-compatible, it will be approved. I do recommend, however, that RSW seek an attorney's advice. I recommend that to everyone who wants to roll his own license. /Larry -- 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: discuss: Modified Artistic License (eNetwizard Content Application Server)
In one of my licenses, I use the phrase the copyright holders and contributing authors instead of my own name, in the disclaimers. The BSD license says copyright holders and contributors, and the AFL goes one step further, saying licensor, contributors, and copyright owners. (I think licensor might be important for AFL due to the embedded patent license - the licensor might have a patent on the software, and might not be a copyright holder. However this is just a guess.) I am not a lawyer, Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
how NOT to form a contract? (second try)
I have published software under an MIT-style License, and I don't know if that makes a good contract or not, but I get the feeling that it's pretty vague, and that I might be better off to treat it as a permission notice and not enter into contracts with all my users. This ties back to recent discussions of click-wrap contracts, pros and cons. However, let's put that debate aside and think mostly about the GPL, where there is no debate about whether or not it should be used as a contract. (RMS says it should not.) I have in the past presented my license terms on the License Agreement page provided by my install builder. This page has a note saying if you do not accept, you cannot install this software. I have also seen the GPL presented that way. I still want to show the license terms during the install, but I don't want the user to see this as a click-wrap contract. To make it clear that I do not agree to enter into a contract with the person installing the software, I have been thinking about presenting it on a page marked Information rather than License Agreement, and prefacing the license with a note like the following: This software is protected by copyright law and is made available under the following license. The copyright holders do not intend for these license terms to form a contractual agreement. Does that make sense? Bruce (IANAL / YANML) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
I kept my own email short because I knew there were other people, better qualified to speak on this. Rod, thanks for stepping forward. You presented the facts more thoroughly than I could. By the way, although you say you disagree with me, I don't think I disagree with you. I'm not sure where that leaves us. My issue with Bernstein is that he presents his opinion as if it were historical fact. This is dangerous for the unsuspecting reader. One part of his opinion is that Microsoft's end user license agreements (and, by extension, all software license agreements) are not enforceable; that you can simply ignore the license terms and do whatever you want with the software. That part of his argument really doesn't hold water for me. From: Rod Dixon [EMAIL PROTECTED] Last point: I do not think anyone made the argument that open source licenses that are contracts are not enforceable. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
I thought that section 117 was about the right to crack a program's copy protection (if necessary) in order to make a legitimate backup copy. Well, that's an oversimplification, but I think it's closer to the truth than Mr. Bernstein's argument. It goes to show that you shouldn't believe every opinion that you read on the Internet. (Follow the references back to the source; the quotes under patches both seem to be taken out of context. If you read them in their intended context you might find that they don't support Mr. Bernstein's opinion nearly as well.) Bruce - Original Message - From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 6:59 PM Subject: Re: Legal soundness comes to open source distribution [ Catching up on mail from ten days ago ] Carol A. Kunze writes: Here is the theoretical difference between proprietary and traditional (GPL, BSD) free software. With the former the user agrees to a license and does not get title to the copy of the program. Without agreeing to the license (and the use restrictions in it), the user has no legal right to use the copy of the software that they possess but do not own. Basically, its a license transaction where the user has no ownership in the copy of the software they possess. My understanding is that, if you have legally acquired a copy of the software, you have the right to run it. http://cr.yp.to/softwarelaw.html Absent a contract otherwise, a user can do anything they want to their copy, including use it, modify it, give it away, or resell it to someone else. So why form a contract, then? To get a warranty disclaimer. To get the recipient to agree that they lose their patent grant if they sue for patent infringement. If we can get those things without a contract, that would be a perfect world. The question here is whether we should amend the Open Source Definition so that it is clear whether click-wrap licenses are allowable or not. We could go either way, but we want to hear from you first. Your opinions solicited, and engaged! OSI has already blessed licenses which are intended to be agreements or contracts (see IBM license), so I'm confused about what the point is here.And why OSI definition would have to change. Am I missing something? They're not enforcable, at least as I understand it. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- 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: Open Source Click-Wrap Notice
Er, I agree. :-). But, as an open source author, does the limitation of liability protect me? The contract that the end user clicked is between the distributor and the end user; does it protect the original developer, who is a third-party? (Or is the distributor is seen as an agent, facilitating a contract on behalf of each developer?) Good, common sense. That is why I suggested in the notice that you there be a simple procedure to review all the licenses... OSI-approved licenses. For many of us, that may be all we need to know without reviewing each license in detail. We will click on I AGREE knowing that we are agreeing to something reasonable. But we will still AGREE! /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open Source Click-Wrap Notice
Here, here. I agree completely that this would be absurd. Yet I still worry. Hopefully the law will eventually agree with us on this point. In Canada we have a good samaritan law; I don't know whether something like that exists in the USA. The good samaritan law says that, in an emergency, if you accidentally hurt the victim while you were trying to help, you can't be held liable. Although open source development isn't done in an emergency situation, it is done by many whose only goal is to help people, and who don't ask any compensation other than a nod of recognition. Wouldn't it be nice if, to the extent that open source development is an altruistic act, we were afforded the same kind of protection that a volunteer fire department gets? Sadly, wishing doesn't make it so. From: Carol A. Kunze [EMAIL PROTECTED] information on mushrooms would pass out of existence. The same would apply to open source. If developers are sued they'll stop writing free software. The idea of imposing liability for potentially millions of copies of a program for which the developer received no compensation is absurd. Please note - this is theory, not current law. _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open Source Click-Wrap Notice
Let me try to make it clear that I know the good samaritan laws don't apply to software or any other non-emergency situation - only for emergencies, where the time it takes to get a waiver signed could otherwise cost a life (or a house). I am also quite aware that liability has nothing to do with motivation - e.g. that if i give someone a lift downtown, and we get into a car accident, and my passenger gets hurt, I can be sued even though I was trying to be nice. Nevertheless the good samaritan laws are for the common good, and so would be a law that prevents someone from suing me for things I contribute to the open source commons. That is the extent of my analogy. I am not drawing any equivalence between the reasons why liability is inappropriate in these two situations. I am also aware that wishing for a thing doesn't make it true. I think we are on the same page. As for bandages vs. underlying problems: In open source, the need to have open source licenses seen as contracts, so that liability can be disclaimed, is a bandage. I'll take the bandage rather than expose myself to continued risk, but I hope the underlying problem will not be forgotten. From: David Johnson [EMAIL PROTECTED] Although open source development isn't done in an emergency situation, it is done by many whose only goal is to help people, and who don't ask any compensation other than a nod of recognition. There is a very good reason why the various good samaritan laws specify acts performed during emergency and/or urgent situations only. Liability, as I understand it, is unconcerned with the actor's motivation, but only with the results of the action. Good Samaritan laws are exceptions to the rules for exceptional circumstances. There are some good reasons for limiting liability for Open Source software. But the goal of helping people is not one of them. The good samaritan laws are bandages on a system that is slowly but surely being broken through abuse. We don't need more bandages, we need correct the underlying problems. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
[Whew!] I'm glad I checked this again before going to bed. From now on until this approval process is done, I will talk about my WILLINGNESS to make changes here on the list first, but I will not actually MAKE the changes until someone from OSI tells me whether that will help or harm my bid for license approval. Maybe that will help things go smoothly. (Russ: if we reach an impasse or if too many changes are required, then we can talk candidly, privately, about whether I should continue this bid or not.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
I made a revision to the SHPTRANS License Template. http://gisdeveloper.tripod.com/shptrans_license_template.html The changes are highlighted in the HTML. For those looking at the text version which Russ posted: I reversed the order of the first two conditions, got rid of the required brief notice, and replaced it with a required pointer to the complete license. Before, the notice distilled to This work is licensed under the license terms for this work, which should have accompanied this work. That was circular and, in a product using libraries under various licenses, probably ambiguous. Also, in the description of what I mean by complete license agreement I reversed the items disclaimers and provisions to provisions and disclaimers - not for any legal reason; it just sounds better that way. The first two conditions were: a. The above copyright notice must appear in all copies or substantial portions of the software. The copyright notice must be followed immediately by the complete text of this license agreement, or by the following brief notice: This work is distributed on an as is basis without warranty of any kind. For more information, and to understand your rights and obligations, please refer to the complete license agreement for software short name, which should have accompanied this work. The same license agreement applies to derivative works. This work may also be redistributed and/or modified under the terms of the GNU General Public License, version 2 or any later version, as published by the Free Software Foundation. b. A verbatim copy of this license agreement (including the above copyright notice, this permission notice, and the following disclaimers and provisions) must appear in the documentation and/or in other materials accompanying the software. They are now: a. A verbatim copy of this license agreement (including the above copyright notice, this permission notice, and the following provisions and disclaimers) must appear in the documentation and/or in other materials accompanying the software. b. The above copyright notice must appear in all copies or substantial portions of the software. The copyright notice must be followed immediately by the complete text of this license agreement, or by a pointer stating where the complete license is found. regards, bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
I thought this process was one in which the license is submitted for discussion, minor revisions are made if needed, and the license is eventually accepted or rejected. From your web page describing the approval process: 6. At the same time, we will monitor the license-discuss list and work with you to resolve any problems uncovered in public comment. How can one resolve problems if one is not allowed to change the license? Or, on the other side of the coin, how can you hope to work with me to resolve a problem, if I am not allowed to admit when changes might be warranted? And let's be realistic: my change was minor: it amounted to removing a requirement for a boilerplate notice pointing to the license agreement; replacing it with a requirement for a free-form pointer to the license agreement. The new form just makes it easier for the recipient / distributor to do the right thing and unambiguously identify the license terms. Anyway, you've made your executive decision. It seems clear that the wasted time was primarily mine. Lawrence made some useful comments today after he had already read about the change I made; no one (other than me) had made any comments at all up to that point. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: ESST license
If copyright statute says that all rights not explicitly granted are reserved to the copyright holder, doesn't that mean the user ought to have gone looking for a license to make sure they had the right to use it? If the premise is that you are not aware, then the assumption should be that you have no rights at all in the software. Trouble is that in some jurisdictions, the usage is not a right that can be restricted. It makes sense: If I receive a book, I can read it. If I receive software, I can use it. So that's why, in those countries, you can't assume the recipient read your license just because they exercised their right to use it. This is part of the reason why, for example, the GPL's teeth are attached to things like modification and distribution. For most people (except lawyers) this is not a problem - after all, what harm can an isolated end user do? Regards, Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
So far there have been no comments on the list since I submitted this template for approval. I have tried to address the concerns raised in the previous discussions (copyleft lite? and simple copyleft...) Perhaps those who had suggestions for the previous versions could tell me whether I addressed their concerns adequately, and whether they see any new shortcomings in the current revision? Several of the comments from the previous iterations revolved around the question of GPL compatibility. To make sure I got that right, I sent a copy of the template over to the folks at FSF. They confirmed that, when the GNU Copyleft provision is included, a license created from this template is GPL compatible. So, that question is now put to rest and we can focus on the other aspects of the license, such as its ability to stand on its own. Regards, Bruce - Original Message - From: Russell Nelson [EMAIL PROTECTED] [ Please discuss this license. This version is different from earlier versions seen here. I have appended the license text to Bruce's email. Please note that the license must stand on its own, since GPL compatibility is an option, not a requirement. -russ ] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: WGPL (WebGPL)
I think the GPL itself would be fine for web pages, as long as you make it clear that your page content is source code as far as you're concerned. You can do that by putting the GPL's license notice in a comment block. But the trouble there, I guess, is that GPL's idea of linkage doesn't mesh with the web's idea of linkage... I think the GPL scope would end up extending to content that you embed (e.g. JavaScript files) but not to other pages that you link to. Has anyone looked at the Design Science License http://www.dsl.org/ as an open source license? It seems to me this would make sense for content that doesn't meet a strict definition of software in everyone's book (e.g. a web page) and would also work for parts of the content that are unambiguously software. - Original Message - From: Ken Arromdee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 28, 2002 2:25 AM Subject: Re: discuss: WGPL (WebGPL) Does this license make it illegal to use an ad-filtering proxy on the page without accepting the license? After all, using an ad-filtering proxy copies and modifies the page, and it's not clear that this is 'running the Web'. What about putting the page on a site like Geocities which automatically modifies the code? Geocities ad-popup code is not GPL, after all. What exactly is a web page? More specifically, are framed content, inlined images, etc. considered part of the web page? -- 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
thanks for helpful suggestions - (simple copyleft license template)
Thanks for your help with the license template, folks. Although my last few revisions have not generated any discussion on the list itself, helpful comments have continued to trickle in through private email. I have now submitted my license template to the OSI for approval. In case you want to look at the final draft, it's at this URL: http://gisdeveloper.tripod.com/shptrans_license_template.html http://gisdeveloper.tripod.com/shptrans_license_template.txt Thanks again, Bruce _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: open source applications with closed source components
If your program was written in Visual Basic, it would depend on the Visual Basic runtime, which is a framework. There are lots of open source applications written in VB. You should not include the proprietary components in your source kit, but should instead list them as requirements. It would also be best if you made a good-faith attempt to remove those requirements, or stated a willingness to accept patches which remove the requirements. For the convenience of end users, you can still include the proprietary parts in the binary distribution. Then your source kit would be for an incomplete program, but would be OSI Certified. There are lots of incomplete OSI certified products out there. Mozilla was incomplete when it was launched. In a few cases a closed-source requirement can remain in the software indefinately, and no one will object. For example, if your open source component is an Adobe Photoshop plugin, it may reasonably depend on Photoshop. (No one will be put out by this because the only people who would want that software are those who have Photoshop.) Although I haven't quite answered your question, I hope that helps. Bruce From: Edwin Zacharias [EMAIL PROTECTED] To: Bruce Dodson [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: open source applications with closed source components Date: Mon, 15 Jul 2002 16:59:28 -0400 MIME-Version: 1.0 (Apple Message framework v482) Received: from ns.crynwr.com ([192.203.178.14]) by mc1-f39.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 14:00:30 -0700 Received: (qmail 21484 invoked by uid 566); 15 Jul 2002 21:00:41 - Received: (qmail 21465 invoked from network); 15 Jul 2002 21:00:37 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Delivered-To: mailing list [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] X-Mailer: Apple Mail (2.482) Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 15 Jul 2002 21:00:30.0390 (UTC) FILETIME=[A72B6D60:01C22C42] On Monday, July 15, 2002, at 03:30 PM, Bruce Dodson wrote: Do your recipients have permission to distribute the two closed-source frameworks freely with their apps? For the sake of argument, lets say that the closed-source frameworks have to be purchased by the user. So, to run the binary you have to buy a closed-source operating system and two closed-source frameworks. Nothings stopping anyone from porting the source of my app to an open-source OS and open-source frameworks. It just hasn't been done yet. - Edwin -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: open source applications with closed source components
Do your recipients have permission to distribute the two closed-source frameworks freely with their apps? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
copyleft lite? - rev 3
Thanks for the feedback so far! By without fee I meant that copyright holder(s) were not imposing a fee; this was confusing and unnecessary so I removed it. I see what you meant meant about the rights not specifically granted are reserved being superfluous. I've removed it for now, but might add it back. Not sure whether the license is easier to understand with or without that. Nailing down the copyleft scope was the tricky bit. This doubled the length of the license terms. As soon as you start talking about what's inside the scope of copyleft, you also have to talk about what's outside the scope. I taken a stab at this but I think I could use some help with the wording, especially in the last paragraph. Here's the current revision: software program name. Copyright (c) year(s) copyright holder(s). All rights reserved. LICENSE AGREEMENT: This license agreement applies to the accompanying software, documentation, and related materials (software). This license also applies to derivative works. Permission to use, copy, and distribute this software is hereby granted, provided that the above copyright notice appear in all copies or substantial portions of the software; and that the above copyright notice, this permission notice, and the following disclaimers appear in the documentation and/or other materials provided with the software. When you distribute this software outside your organization, the source code must be made available to the recipients under these license terms, and/or under the terms of the GNU General Public License (GPL) as published by the Free Software Foundation. You may create derivative works by modifing this software; and/or by combining part or all of this software with other materials. Derivative works must be plainly marked as such, and must not be misrepresented as being the original software. When you distribute a derivative work based on the software, the source code for the entire derivative work must be made available under the terms of this license and/or the GPL. A work that does not itself contain any portion of the software is not considered a derivative work, even if it accesses services exposed by this software or a derivative work; even when it is stored or distributed on the same medium with software licensed under this agreement. Your rights under this license will terminate automatically if you fail to comply with the terms and conditions set forth herein. DISCLAIMER OF WARRANTY: THIS SOFTWARE AND THE ACCOMPANYING FILES ARE PROVIDED AS IS. NO WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE IS OFFERED. ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTING AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The recipient must assume the entire risk of using this software. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: copyleft lite?
Okay. I can add that or under GPL clause; it doesn't really make the license harder to understand, and it's worth it to ensure GPL compatibility. I will have to work on some simple explanation of what modifications means. Suggestions are welcome! I'm thinking if the resulting software ends up as one binary executable file (DLL / EXE / .so / whatever), the whole thing needs to be covered under the terms of this license (or the terms of the GPL, subject to its definition of what constitutes a modification). But I want the wording to be simple and not scary - I don't want the recipient to need to hire both a lawyer and a programmer to understand the license! software program name. Copyright (c) year(s) copyright holder(s). All rights reserved. LICENSE AGREEMENT: This is a license agreement and not an agreement for sale. All rights not specifically granted in this agreement are reserved to the copyright holder(s). Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies, and that the above copyright notice, this permission notice, and the following disclaimers appear in supporting documentation. When you distribute this software outside your organization, the source code (including any modifications) must be made available to the recipients under these license terms, or under the terms of the GNU General Public License as published by the Free Software Foundation. Your rights to use, copy, modify, and distribute this software will terminate automatically if you fail to comply with the terms and conditions set forth in this license agreement. DISCLAIMER OF WARRANTY: THIS SOFTWARE AND THE ACCOMPANYING FILES ARE PROVIDED AS IS. NO WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE IS OFFERED. ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTING AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The recipient must assume the entire risk of using this software. - Original Message - From: Andy Tai [EMAIL PROTECTED] To: Bruce Dodson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, July 13, 2002 5:40 AM Subject: Re: copyleft lite? These terms will make it not GPL compatible because the GPL is not identical to these terms. Maybe something like the source code (including any modifications) must be made available to the recipients under these terms or the terms of the GNU General Public License... --- Bruce Dodson [EMAIL PROTECTED] wrote: I'm trying for a simple, easy-to-read license with some degree of copyleft. I hope it will be compatible with the GPL also. __ LICENSE AGREEMENT: When you distribute this software outside your organization, the source code (including any modifications) must be made available to the recipients under these license terms. __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
copyleft lite?
I'm trying for a simple, easy-to-read license with some degree of copyleft. I hope it will be compatible with the GPL also. Please take a look at the following, and help me find any flaws. Thanks, Bruce __ software program name. Copyright (c) year(s) copyright holder(s). All rights reserved. LICENSE AGREEMENT: This is a license agreement and not an agreement for sale. All rights not specifically granted in this agreement are reserved to the copyright holder(s). Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies, and that the above copyright notice, this permission notice, and the following disclaimers appear in supporting documentation. When you distribute this software outside your organization, the source code (including any modifications) must be made available to the recipients under these license terms. Your rights to use, copy, modify, and distribute this software will terminate automatically if you fail to comply with the terms and conditions set forth in this license agreement. DISCLAIMER OF WARRANTY: THIS SOFTWARE AND THE ACCOMPANYING FILES ARE PROVIDED AS IS. NO WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE IS OFFERED. ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTING AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The recipient must assume the entire risk of using this software. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
