Re: [License-discuss] a Free Island Public License?
Wow! I must add that I do not think I would have seen a comment like this posted by Bruce Perens 10 years ago. Of course, I completely agree with the sentiment. Rod Dixon Sent from my iPhone On Dec 16, 2011, at 6:24 PM, Bruce Perens br...@perens.com wrote: OSI should deny certification of this license for the reasons already discussed, and because: It is not the product of a legal professional. I've been calling these crayon licenses, taking a line from an old Monty Python sketch about a dog license with the word dog crossed out and cat written in, in crayon. Crayon, in this case, is a metaphor for the poor legal qualification of the authors. Crayon licenses show a lack of understanding of copyright law, license structure, and most important: what would happen if the license were to be interpreted in court. We had an excuse for writing such things in the early days of Open Source when no lawyer would help us. We no longer have that excuse. Crayon licenses harm Open Source developers because they don't do what the developer expects. My most poignant experience with one was working on the appeal of Jacobsen v. Katzer. Bob Jacobsen, an innocent Open Source developer, essentially lost his case in the lower court due to the poor drafting of the Artistic License 1.0, one of the initial Open Source licenses, when the judge found it to be tantamount to the public domain. This loss would also have been very damaging to Open Source in general, had it been allowed to stand. Bob suffered very significant damage from this case. We are very fortunate that he persevered, and that we were able to overturn the decision on appeal. OSI should no longer approve crayon licenses, due to the potential they have to damage our own community. Thanks Bruce Perens bruce.vcf ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
RE: On the licensing terms of the open source licenses text
Larry Philippe - my take on this issue is that it is not a good idea to copy an open source license, if the author of the license text explicitly withholds permission. On the other hand, I have always assumed that the claim to copyright in an open source license text is both ironic and debatable. The irony arises from the fact that open source licenses not only are often (nearly always) are intended to be distributed by those who are not the purported author (the license often travels with the copy of the work), but the practice of posting approved open source liscenses on opensource.org connotes that the text may be used by others. Granted, these practices may not disrupt an author's rights, but it is an ironic position. The debatable aspect arises from the fact that by the nature of the special class or type of software license, most open source license texts are necessarily derivative of a preexisting free/open source license (except, perhaps, the first one or two original licenses). Few (if any) are going to draft an open source license without studying a preexisting license very closely. In addition, if there are terms-of-art, you will wisely likely want to use those terms rather than creating your own. Consequently, the copyright in most open source license texts is more illusion than real. Even so, this should not mean that you should copy a license text, change a few terms, claim it as your own, but identify it as the OSL, GPL, or whatever. As has been noted on this list often, the way you use a preexisting open source license as a template for your own use should be done with careful planning. -Rod -Original Message- From: Lawrence Rosen [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 7:08 PM To: 'Philippe Ombredanne' Cc: [EMAIL PROTECTED] Subject: RE: On the licensing terms of the open source licenses text Philippe Ombredanne wrote: So the questions are: How can I reuse the text of a license like the OSL to create a new license? Is this licensed under the OSL? Or restricted to Larry's terms? Can I create a new license, for instance the nexB public license, based on the text of the OSL, or other license text but with every reference to the OSL removed, except for copyright attributions, creating a derivative work of the license text? And if I use an existing OSI approved license as a base, would I need to go through the full legal commentary to submit it for approval? (BTW, I know this was debated in the past, but did not find any conclusion on the topic. -- Cheers Philippe Cheers, indeed! :-) I'm looking forward to hearing the discussion. I certainly don't want to be like some power-grabbing monopolist who claims more intellectual property rights than the law allows. What part, after all, of my license is copyrightable subject matter? Everything? We've made copyright so expansive that I expect to see such notices on graffiti soon. /Larry Lawrence Rosen Rosenlaw Einschlag, technology law offices (www.rosenlaw.com) General counsel, Open Source Initiative (www.opensource.org) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * fax: 707-485-1243 email: [EMAIL PROTECTED] -Original Message- From: Philippe Ombredanne [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 11:02 AM To: [EMAIL PROTECTED] Subject: On the licensing terms of the open source licenses text Dear licenses enthusiasts, I have a question about the licenses of the text of the licenses themselves. Very specifically, I wanted to create our own license, based on the OSL, but I am taking the OSL here as an example. And taking the OSL as example gives definitely a recursive feel to the topic... The OSL and many other licenses have fine prints like that: This license is Copyright (C) 2003-2004 Lawrence E. Rosen. All rights reserved. Permission is hereby granted to copy and distribute this license without modification. This license may not be modified without the express written permission of its copyright owner. This obviously restricts the reuse of the license text in other licenses. On the other hand, every web page on opensource.org has the following footer: Copyright C 2004 by the Open Source Initiative The contents of this website are licensed under the Open Software License 2.1 or Academic Free License 2.1 This could be construed as making the text of the licenses available under the OSL. So the questions are: How can I reuse the text of a license like the OSL to create a new license? Is this licensed under the OSL? Or restricted to Larry's terms? Can I create a new license, for instance the nexB public license, based on the text of the OSL, or other license text but with every reference to the OSL removed, except for copyright attributions, creating a derivative work of the license text? And if I use an existing OSI approved license as a base, would I need to go through the full legal commentary to
RE: the provide, license verbs
...Not the real world example that I was looking for but, admittedly, the hypo works. In fact, the USA Patriot Act might mean the hypo need not reference a dictatorship. Today, even in a democracy, lawful entry into a tech-savvy dissident's home by the government is possible under the circumstances and in the manner as the hypothetical. -Original Message- From: Mahesh T. Pai [mailto:[EMAIL PROTECTED] On Behalf Of Mahesh T. Pai Sent: Tuesday, July 06, 2004 2:36 AM To: [EMAIL PROTECTED] Subject: Re: the provide, license verbs Sorry for the late reply. Rod Dixon, J.D., LL.M. said on Wed, Jun 09, 2004 at 06:09:00PM -0400,: private and personal use. Who would bring such a lawsuit, and how would the suit get past a motion to dismiss? How about a dictatorship? Consider a tech-savvy dissident, who modified his legally acquired copy of software. The typical, contractual, acceptance-required _license_ does not allow him to do that though. The dictatorship raids the dissident's den, finds nothing incriminating; his hard disk is clean ... except for this modification prevented by the EULA. The Dictator can hand over the dissident to the BSA (or its equivalent), who will initiate proceedings for infringement of copyright. Rod Do you say the law prevents me from taking a legal copy of a copyrighted work, which is a program, and privately modifying that program for my own use? John Cowan says yes: http://linuxmafia.com/~rick/faq/modifications Dan Bernstein says no: http://cr.yp.to/softwarelaw.html -- Mahesh T. Pai http://paivakil.port5.com Distribute Free Software -- Help stamp out Software Hoarding! -- 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: Effect of the MySQL FLOSS License Exception?
I agree with every point Larry states. I also think that if an author chooses to adopt a license (the GPL) or is concerned about compatibility with the terms of the GPL, the author may find it prudent to take into account the views of the drafter(s) of the GPL...especially if they conflict with other interpretations of the GPL. One might then choose to ignore those views, but that is a different matter. For my part, I have never fount Richard Stallman's views on the interpretation of the GPL as to matters of linking to be entirely clear or uncontroversial with regard to likely legal meanings of derivative work; notwithstanding that courts are often imprecise about the meaning of derivative works as well. If this issue is important to anyone, I remain convinced that the best work around is to use something like the OSL or a draft of one's own license and clarify, clarify, clarify. - Rod - Rod Dixon, J.D., LL.M. www.cyberspaces.org This email never should be construed as legal advice. .. Original Message ... On Wed, 16 Jun 2004 22:56:19 -0700 Lawrence Rosen [EMAIL PROTECTED] wrote: Glen Low wrote: [Humor aside, if the code I'm linking with MySQL is on their approved FLOSS list, what functionally is the difference between MySQL being LGPL and it being GPL + FLOSS Exception?] Probably no difference at all. This entire matter has been blown way out of proportion because of the insistence of some that the reciprocity conditions of the GPL or LGPL reach to something more than derivative works. But if you read the actual terms of both licenses carefully in light of the copyright law definitions of *collective works* and *derivative works*, then mere linking to any Program -- treating the Program as a black box with hooks for connectivity -- does not lead to reciprocity under either license. The LGPL and the GPL have the same effect -- that is, NO EFFECT -- on the licenses of independent and separate other works that merely link. As for the MySQL License Exception, I believe its interpretation of the effects of the GPL, and its description of what happens when you create *collective works* with MySQL and other open source software, is accurate. I also happen to believe that this Exception doesn't need to be an exception at all, because that's how the GPL should be interpreted anyway. Independent and separate works can never be forced under the GPL if they are not *derivative works* of GPL programs. The MySQL folks have tried to eliminate confusion about their licenses by stating in their own words what the GPL and LGPL really do anyway. John Cowan is also right in describing this as benefit to MySQL AB. Improvements to the MySQL Program itself remain open source, and high-quality independent and separate works that interact with MySQL increase opportunities to sell MySQL AB software and services. The MySQL trademark remains a valuable symbol of quality. Open source companies like MySQL need to reassure their customers about the reach of the GPL and LGPL. I recently wrote a similarly reassuring paper about the LGPL for JBoss customers that they've posted on the jboss.org website. You can read it here: http://jboss.org/pdf/why_we_use_the_lgpl.pdf. /Larry Lawrence Rosen Rosenlaw Einschlag, technology law offices (www.rosenlaw.com) General counsel, Open Source Initiative (www.opensource.org) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * fax: 707-485-1243 email: [EMAIL PROTECTED] -- 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: Effect of the MySQL FLOSS License Exception?
Unfortunately, you started off wrong and ended with a questionable observation. First, it is not well settled that a binary is a derivative of source; that is akin to saying a copy is a derivative of the original. In a metaphysical sense, we can debate the point, but there is no debate in the copyright sense. As for Eben, his point is framed far out of context. - Rod - Rod Dixon, J.D., LL.M. www.cyberspaces.org This email never should be construed as legal advice. The sticky point is this: It's settled that a binary is a derivative work of its source. It's obvious that a source tarball is a mere collective work, or aggregation as the GPL calls it. What, then, is the status of a binary compiled from the tarball? It evidently is a derivative of the collection; is it a derivative of the source works as well? Larry says (in effect) no; Eben says yes. Infinite are the arguments of mages. -- But I am the real Strider, fortunately, John Cowan he said, looking down at them with his face [EMAIL PROTECTED] softened by a sudden smile. I am Aragorn son http://www.ccil.org/~/cowan of Arathorn, and if by life or death I can http://www.reutershealth.com save you, I will. --LotR Book I Chapter 10 -- 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: the provide, license verbs
Hmm... I would not uncritically accept the principle that no matter what a licensor says in her license, a licensee must follow the restriction because of an assumption that it is legally enforceable. The rub -- no doubt -- is that one must be careful not to ignore the terms of a license at the same time as one is aware of the tension created between this default rule and the subjectivity involved in choosing not to follow terms that seem unworkable. For example, most end-users, who never bothered to read their software license in the first place, were said to routinely violate proprietary license terms in the early 1990's that prohibited making a second copy of the program disk of a software application (for backup, archive, or any other purpose). I never read that anyone of those end-users, including myself, became defendants in a legal dispute brought by the licensor. Hence, my point that some aspect of our discussion is purely academic. Rod - Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] www.cyberspaces.org .. Original Message ... On Wed, 9 Jun 2004 22:32:52 -0400 No Spam [EMAIL PROTECTED] wrote: It's not entirely academic what do you with your legal copy of a program in the darkness of your room... :-) after all, what if you were legal corporation or entity, using it for your private use and making money from it? The GPL doesn't care. The QPL, reflecting Trolltech's concerns, does. Look at 4c and especially 6c. Obviously they are concerned about companies getting a legal albeit free copy, making changes and/or incorporating into their own proprietary products and neither releasing the code nor paying them, essentially defeating their revenue model. Cheers, Glen Low, Pixelglow Software www.pixelglow.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: the provide, license verbs (was: Dual licensing)
I essentially agree with Rick's comment, but it may be somewhat misleading. I suspect a copyright holder who issues a license would argue that the license changes everything. As such, if you are in lawful possession of software that is accompanied by a license, you are restricted to accepting the terms of the license or rejecting them. That's it. On the other hand, the default rules Rick mentions would apply to a work like a book, which is not customarily distributed with a license. Rod - Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] www.cyberspaces.org .. Original Message ... On Wed, 9 Jun 2004 08:33:15 -0700 Rick Moen [EMAIL PROTECTED] wrote: Quoting Marius Amado Alves ([EMAIL PROTECTED]): Sam Barnett-Cormack wrote: The author gives me a copy of the software... Under no license? Marius, if you receive a piece of software encumbered by copyright (as essentially all useful software is), you have the implied right to use and (if needed) compile the software -- as provided by copyright statute. Other rights such as the right of redistribution, and the creation and distribution of derivative works, are by default reserved to the copyright holder. So, if you (lawfully) acquire a piece of software, you have a bundle of rights by statutory action, by default. Upon acquiring it, you might find a licence grant from the copyright holder that is contingent on a stated set of obligations. If the obligations don't appeal to you, nothing requires you to accept the licence, but then you possess only the rights conveyed by statute (e.g., no right of redistribution). Copyright owners who don't want recipients to have that option often resort to clipwrap agreements (an intended instrument of contract law), instead. (There are other reasons some authors prefer such instruments, but that's a different discussion.) -- Cheers,Rehab is for quitters. Rick Moen [EMAIL PROTECTED] -- 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: the provide, license verbs
Now, that is a genuine academic argument. I am sure the issue will never be resolved to everyone's satisfaction...primarily because no one cares enough about what you do to software you lawfully possess and want to hack for private and personal use. Who would bring such a lawsuit, and how would the suit get past a motion to dismiss? Rod - Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] www.cyberspaces.org .. Original Message ... On Wed, 9 Jun 2004 11:29:14 -0700 Rick Moen [EMAIL PROTECTED] wrote: Quoting Stephen C. North ([EMAIL PROTECTED]): Do you say the law prevents me from taking a legal copy of a copyrighted work, which is a program, and privately modifying that program for my own use? John Cowan says yes: http://linuxmafia.com/~rick/faq/modifications Dan Bernstein says no: http://cr.yp.to/softwarelaw.html When you get that resolved, please let me know. -- 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: Dual licensing
If done appropriately, a comparison between 2 software programs that are similar in most respects - - except one distributed as a proprietary product (without antitrust violations, i.e., legally) and the other through open source dual -licensing - - the program that should do better is the latter, not because it has a closed source counterpart, but because of the benefits that follow from the open source version. No doubt there may be exceptions in practice (a project may not be managed carefully or there may be problems with free-riding), but, in the main, the dual licensing model will do better than the closed source proprietary model; hence, the significant feature of dual-licensing is its connection to the open source development method. If you disagree, then you disagree with some of the ideas underlying open source, which is not the same as making a case against the logic of the dual-licensing model. - Rod - Original Message - From: Marius Amado Alves [EMAIL PROTECTED] To: OSI license discussion [EMAIL PROTECTED] Sent: Monday, June 07, 2004 7:55 AM Subject: Re: Dual licensing Rod Dixon, J.D., LL.M. wrote: I agree with the point that the creative spark is not communitarian. My point -- if we are to use Eric Raymond's book as an example (see Raymond's busness model 8 Free the Software, Sell the Brand) -- is that dual licensing IS an authentic open source model. This is just words, but anyway: dual-licensing involves a closed source license as much as an open one; in business terms, even more, because that's where the money is. So dual-licensing is really less an open source model than a closed one. I'd really like to be shown any essential flaw in this reasoning. But as I said, it's just words, academic, not important, not pressing, don't waiste your time. Thanks. -- 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: Dual licensing
Though you protest that you are not against open source, I think your words betray that protestation; certainly, arguing that those who support or develop open source software never sell open source directly, there is always some 'trick' - - is not exactly a praiseworthy outlook. In that regard, I am doubtful that you are raising an earnest argument. Even so, your point overlooks a critical detail: there is no restriction against selling software. That the open source model renders it less likely that a vendor will succeed in selling open source software is not the same as a restriction against doing so. Of course, one aim of open source development, it seems to me, is that those who desire to make commercial use of the work of others add value before doing so. I do not understand how someone may properly characterize this as a trick or imply that success with open source is based on a delusion. - Rod Ok, since you bit the academic discussion, here it goes. Rod Dixon, J.D., LL.M. wrote: If done appropriately, a comparison between 2 software programs that are similar in most respects - - except one distributed as a proprietary product (without antitrust violations, i.e., legally) and the other through open source dual -licensing - - the program that should do better is the latter, not because it has a closed source counterpart, but because of the benefits that follow from the open source version. I fully agree. And of course with only the words closes and open you must call closed to the entirely closed and open to the partially open. No doubt there may be exceptions in practice (a project may not be managed carefully or there may be problems with free-riding), but, in the main, the dual licensing model will do better than the closed source proprietary model; hence, the significant feature of dual-licensing is its connection to the open source development method. If you disagree, then you disagree with some of the ideas underlying open source, which is not the same as making a case against the logic of the dual-licensing model. The dual-licensing requires a market need for *closed* source. How can this be in line with the open source ideals? (Please note I'm not at all against practising the dual-licensing model, given the current state of affairs.) -- 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: For Approval: Educational Community License
I agree that the license complies with the OSD. I also agree that your last paragraph could be clearer. I suspect that you could even delete it. The name and trademarks of copyright holder(s) may NOT be used in advertising or publicity pertaining to the Original or Derivative Works without specific, written prior permission. Title to copyright in the Original Work and any associated documentation will at all times remain with the copyright holders. The rights referred to in the clause above are exclusive rights by definition so permission is required regardless of inclusion of the clause in a license. If a trademark is used in the license and I have overlooked it, then the clause *might* help. - Rod Rod Dixon Blog: http://opensource.cyberspaces.org - Original Message - From: Ernest Prabhakar [EMAIL PROTECTED] To: Wheeler, Bradley C. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 4:58 PM Subject: Re: For Approval: Educational Community License : Hi Brad, : : A cursory examination doesn't reveal anything that looks like it : violates the OSD, but I did have a few comments: : : 1. While I think I understand the intent, your HTML version just : feels wrong: : http://wheeler.kelley.indiana.edu/ecl1.htm; : : One, despite the disclaimers, it looks like a sleazy attempt to pretend : compliance. I know you didn't mean that, but it just looks bad. : : Second, the usual reason for HTML is to provide better formatting. : Your bullet items in the HTML are all mangled up, and its a little hard : to say exactly what you're requesting : : 2. I have to ask: Did you look at the original Apache license? : : http://www.apache.org/licenses/LICENSE-1.1 : : Perhaps I'm being naive, but I would think you could readily create : your own version of that license simply by a) adding a clause about : clearly indicating modifications and b) genericizing the trademark : clause. : : I realize you're already close to it (since you share the MIT : heritage), but if there was anyway to adopt the phrasing -- and look : feel -- of Apache 1.1, it might reduce the learning curve still : further. : : Just my $.02. As I said, I don't see anything OSD-problematic, but I : did find the review a little harder than I felt it needed to be. : : Best of luck, : -- enp : IANAL, TINLA, etc., etc. : : : : On Jun 7, 2004, at 10:54 AM, Wheeler, Bradley C. wrote: : : [ Please discuss this license ] : : Greetings, : : The purpose of this message is to submit the Educational Community : License (ECL) for OSI certification. This request is driven by a : recent : acceleration of application software projects in higher education (over : a dozen current projects with new grants pending). There is a growing : concern that many of these projects will need to share code and : interoperate with each other to achieve their full potential for users. : In the present state, many of these projects are evolving on unique : licenses from their local host universities. There is a timely : opportunity and need for a common license that can be used for these : and : future projects. : : In a step towards realizing a common license, the Sakai Project : (www.sakaiproject.org http://www.sakaiproject.org/ ) ($6.8M project) : and the Open Source Portfolio Initiative (OSPI)(www.theospi.org : http://www.theospi.org/ ) ($1M project) - both funded by the Mellon : Foundation - have both agreed to use the proposed Educational : Community : License. This includes formal acceptance from the administration at : Foothill-De Anza Community College District, Indiana University, MIT, : Stanford University, the University of Michigan and several companies : who provide support for open source software in higher education (no : small feat to reach common agreement!). The IMS Global Learning : consortium (50 members) that works on interoperability matters and : sharing in the education community has also endorsed the ECL as it sees : a tremendous need for a common license. Other universities and : projects : have indicated their interest in using the license if it receives OSI : certification. As a board member for both the Sakai Project and OSPI, I : am submitting ECL on their behalf, and I can provide supporting letters : or emails from any of the institutions named here if those would be : helpful. : : ECL is conceived as a very open license regarding the creation of : derivative works, reuse of code, and freedom to commercialize. It : builds on the very successful university-commercial experiences of the : uPortal Project that also used a very unrestrictive license. It adds : some explicit restrictions deemed necessary to protect the : trademarks/brands of the copyright holders and provides for a lineage : of : modifications to help users understand the origins of their software. : : The title of the license is intended to further adoption among open : source projects in higher education
Re: Dual licensing
I am a little puzzled as to the controversy. I attended a law conference recently where a Microsoft attorney spoke on a panel identified as open source software. As odd as that was since there were no members of the open source community on the panel, Microsoft's long list of legal risks warning others away from developing open source software did not include the FUD that the software cannot be sold. In fact on that point I thought Microsoft accurately acknowledged that open source software can be sold successfully through a dual licensing model. Is there really any genuine doubt that this is occurring? - Rod : Marius Amado Alves [EMAIL PROTECTED] writes: : : For the 10th time someone is trying to say that you can sell open : source software. Some people including myself sustain that you can't, : in practice. (That is, you can charge, and even sell a couple of : copies, but you'll be out of business the next day, when someone : starts giving copies for peanuts.) I asked the questions I did for two : possibilities: : : That is a convincing reason why there is a cap on profits you can make : by selling open source software. If your profits get too high, : somebody will undercut you on price. However, it is not a reason for : why you can not sell open source software at all. : : : Again, this is beside the point of whether you can reasonably describe : non-open-source software as commercial open source. I maintain that : you can not. : : Ian : -- : 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: Dual licensing
Open source software refers to a development model as well as a software licensing legal regime. I will not bother to use exclamation points or ALL CAPS to make my point. - Rod - Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] www.cyberspaces.org .. Original Message ... On Sun, 06 Jun 2004 15:37:08 +0100 Marius Amado Alves [EMAIL PROTECTED] wrote: open source software can be sold successfully through a dual licensing model. For the 1th time, dual-licensing is not selling open source software. You're selling a closed license. You're relying on the market wanting closed. You're exploiting a need for the contrary of open source. -- 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: Dual licensing
I agree with the point that the creative spark is not communitarian. My point -- if we are to use Eric Raymond's book as an example (see Raymond's busness model 8 Free the Software, Sell the Brand) -- is that dual licensing IS an authentic open source model. - Rod - Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] www.cyberspaces.org .. Original Message ... On Sun, 6 Jun 2004 15:16:44 -0400 John Cowan [EMAIL PROTECTED] wrote: Rod Dixon, J.D., LL.M. scripsit: Open source software refers to a development model as well as a software licensing legal regime. Maybe in the press it does, but on the ground it does not. Only a small fraction of the projects on Sourceforge or announced at Freshmeat are developed in bazaar fashion. (Note that in TCATB, Eric uses cathedral to refer to a certain kind of open source software, not to closed source software.) The small one-person efforts may be more huts than cathedrals, but that does not mean they are developed by an unconventional development model. -- John Cowan -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Which license to use for MFC based software?
[snip] Basic) and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ (or Visual Basic) run-time library permitted under the GPL? Forgive me, if I am responding to the wrong question. The thread to this discussion is a little hard to follow. The answer is yes, if the question is strictly analyzed as a copyright question involving copyright law in the U.S. It is important to remember that whether dynamic linking to a shared library somehow creates a derivative work is a question of copyright law, not the interpretation of a software license. Since the GPL does not reach modifications that do not constitute derivate works (recall that the GPL is supposed to be a copyright license, not a contract), the Copyright Act applies in the first instance. In that regard, section 117(a)(1) may apply; that section ostensibly would permit an end-user, the lawful owner of a COPY of the copyright-protected program, to run an open source program that calls a run-time distributed by OS developer like Microsoft. Even if an open source program made a highly unpredictable call to a shared library during run-time and one could persuasively argue that in that instance the dynamic linking, itself, created a modified work, section 117(a)(1) would seem to render the adaptation permissible as a matter of Copyright law. - Rod Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] opensource.cyberspaces.org DISCLOSURE STATEMENT: This e-mail communication constitutes a written document that may be subject to whatever; it was not created during the course of an attorney client relationship. The content is offered as information only, not legal advice. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Which license to use for MFC based software?
Thanks for the summary, Rick. This is definitely a serious matter, if it turns away developers from open source. I still think Carsten may be able to accomplish his goals. The problem identified sounds less like a legal issue than it does a potential programmer's nightmare. The visual basic (or Visual C++) runtimes are likely to be distributed by Microsoft as part of the operating system. The lack of runtime distribution for programs made with Microsoft's visual tools was a problem with older versions of the OS, but I believe they have overcome this issue with Windows 2000 and XP, which probably have all the libraries needed for a typical app. to dynamically access a procedure in a shared library. As for the licensing issue, since Microsoft can only control the distribution of its copyright protected works, there should not be a problem with dynamic linking an open source work created in a popular visual language. As someone else suggested, if Microsoft's copyright protected libraries somehow provide a real stumbling block, there may be other shared libraries that constitute good substitutes. I am assuming that Carsten bought a Microsoft IDE in some visual language, and in exchange Microsoft granted a royalty-free license for distribution of shared libraries. Aside from the above, I must admit that it would be terrible to suggest that one may need to consult a lawyer to parse the software license(s) that may accompany Microsoft's tools, but it does sound as if there may be terms its licenses intending to bind end-users that are barely beyond nonsense. I am not sure what the end-user has obtained in exchange for all of the additional conditions cited by a previous post. - Rod - Original Message - From: Rick Moen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 7:06 PM Subject: Re: Which license to use for MFC based software? Quoting Rod Dixon, J.D., LL.M. ([EMAIL PROTECTED]): Forgive me, if I am responding to the wrong question. The thread to this discussion is a little hard to follow. Indeed, and I'll attempt to remedy that, below. The answer is yes, if the question is strictly analyzed as a copyright question involving copyright law in the U.S. It is important to remember that whether dynamic linking to a shared library somehow creates a derivative work is a question of copyright law, not the interpretation of a software license. Since the GPL does not reach modifications that do not constitute derivate works (recall that the GPL is supposed to be a copyright license, not a contract), the Copyright Act applies in the first instance. In that regard, section 117(a)(1) may apply; that section ostensibly would permit an end-user, the lawful owner of a COPY of the copyright-protected program, to run an open source program that calls a run-time distributed by OS developer like Microsoft. Even if an open source program made a highly unpredictable call to a shared library during run-time and one could persuasively argue that in that instance the dynamic linking, itself, created a modified work, section 117(a)(1) would seem to render the adaptation permissible as a matter of Copyright law. I just consulted the archive copy of Carsten Kuckuk's original post: He mentioned his understanding that Microsoft's MFC toolkit may not be used to create GPL codebases, and asked what alternative licensing regime he might use comes closest to the GNU GPL without running afoul of Microsoft Corporation's prohibitions. Several posts then ensued, reflecting different guesses about what specific impediment Carsten is worried about. Nick Moffitt posted a well-worded explanation of how to use non-GPLed libraries in otherwise GPLed works -- reflecting Nick's surmise that Carsten had in mind MFC libraries' licence-compatibility problem. Then, I posted, because I recalled a news item from two years ago, that Microsoft had begun inserting in its SDK EULA language a clause banning the SDKs' use in (1) developing copylefted code, or (2) distributing their components (such as runtime libraries) in conjunction with copylefted code. So, essentially, I was saying that Carsten's recollection (that Microsoft's MFC toolkit may not be used to create GPL codebases) may _indeed_ be correct, and that he should check its EULA for language similar to what I cited. (I also pointed out that that EULA language does its best to sabotage development using _all_ forms of copyleft.) Carsten clarified in a follow-up that he's speaking of development under either Microsoft Visual C++ or Microsoft Visual BASIC -- so he should indeed be concerned about the licensing of those toolkits' respective runtime libraries, as well as of their developer-use portions. (In a further follow-up, he detailed sundry restrictions in the terms of use for Visual Studio 6.0 and Visual Studio.NET 2003. And Evan pointed out the real solution -- open source
Re: Which license to use for MFC based software?
This is probably true. But, the legal basis for the GPL's control over re-distribution or subsequent distribution is that the underlying work is either a derivative of the original or the original itself. What is Microsoft's legal basis? Are they claiming that all works created with their visual programming tools are derivative works of the tool? derivative works of the visual programming language? Or, something else? I suspect that if their licenses reach out to control distribution terms of the copyright protected work developed by the end-user...then...Houston, we have a problem. - Rod - Original Message - From: Stephen C. North [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 02, 2004 8:09 PM Subject: Re: Which license to use for MFC based software? Isn't the INTENT of the GPL to be incompatible with things like the Microsoft EULA? And the INTENT of the Microsoft EULA to be incompatible with the GPL? So this question is really about defeating the purpose of these licenses. I don't see where that's in the spirit of agreeing to them. Why do it? Stephen North -- 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: Question re attribution for derived works...
I agree with John's point regarding that the fact that a BSD-style advertising clause should not create an OSD problem, but likely would be incompatible with the GPL. Still, my reading of the primary objection against the use of an advertising clause in free/open source software licenses is a prediction that downstream users/licensees would proliferate similar clauses inappropriately. A carefully drafted license could prevent that messy result. - Rod - Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] www.cyberspaces.org .. Original Message ... On Wed, 19 May 2004 00:39:00 -0700 Claire Giordano [EMAIL PROTECTED] wrote: I am wondering what you all think about the following open source license possibilities. Input much appreciated. Thanks. 1. I'd like to know what you would think about an open source license that required derived works to provide attribution to the open source community from which the works are derived. Contributor source file attribution appears to be common in the open source world, and I've also seen requirements for attribution in the written documentation. I'm wondering how feasible it would be to require people creating and distributing derived works to advertise (if they advertise) that their derived work was based on the open source technology in question. 2. I've heard that some community members might find an advertising attribution requirement unpalatable. So I'm considering whether the license should also contain a non-discriminatory buy-out clause for anyone who found the advertising attribution unpalatable (for a fee.) It's important to me to be fair and to give credit (in a visible, memorable way, which documentation and fine-print attribution sometimes are not) to the open source origin of derived works. I'm trying to find a way to do so fairly, within the context of an OSI approved license. Thoughts? Thx, Claire Giordano -- 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: Why open-source means free to distribute?
I think Larry will have to answer your question authoritatively. In my opinion, the distinctions assumed by your question are impertinent. OSI has the legal authority to control the use of its certification trade mark within the parameters it sets forth. If they say under condition X, vendor Y is not authorized to use the mark, vendor Y must follow that determination or risk infringing the mark. At this point, your question is really more straightforward than the one you posed, I think. You want to know: whether developer/vendor/whomever is authorized to use the mark. Rod On Fri, 7 May 2004, Alex Rousskov wrote: On Sat, 8 May 2004, Eugene Wee wrote: Alex Rousskov wrote: Where does it say that OSI certified mark cannot be used with a BSD license text titled Foo Open License v1.2? I suppose that might be: Use of these marks for software that is not distributed under an OSI approved license is an infringement of OSI's certification marks and is against the law. Found at: http://opensource.org/docs/certification_mark.php To interpret the above, one needs to know whether OSI approves the license text, the license title, or a combination of both (i.e., the core question you stripped). Alex. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Submitting a new license or using the current ones
: On Thu, 6 May 2004, Ian Lance Taylor wrote: : : I don't understand why there are so many licenses, if the : open-source specification is so rigid. : : I don't really understand it either. I mean, I know how we got here : step by step, but looking at the situation now it doesn't make much : sense. : : The license is supposed to be a legal document. Legal concepts (e.g., : public domain or software license), default warranties (that we have : to disclaim), and tricks to get around legal licensing limitations : (e.g., patents) change all the time. Thus, the number of licenses : submitted for OSI approval will probably continue to grow. : : One alternative is what Creative Commons are trying to do. They : control creation of licenses and, hence, are able to limit their : growth (and variety) with a simple, common-sense-based interface. I agree that CC has an elegant solution to the problem they are trying to fix. I predict that you will see more licenses added to CC's website, but, perhaps, not as many as we see on this list. License proliferation in open source (and free software) is a problem, but in the software context, innovative business models, differing business goals and wide-ranging business values inevitably lead to unique licensing needs. The activities on this very list provide abundant evidence that folks are frequently coming up with interesting and different development goals that often cannot be shoe-horned into a preexisting license. In this light, approved licenses should primarily serve as templates for new drafters. On the other hand, you might say that OSI could crush some of that innovation and force folks to squeeze their business and development objectives not only into conformity with the OSD, but into the language of one license chosen from a limited list of licenses. Is that what some are urging? I think that both the methods used by OSI and the alternative used by CC come with advantages and disadvantages. But, in my opinion, the principle that developers ought to be able to draft their own open source license (within the bounds of the OSD) is too important to throw out. I support what CC is doing, but the method they have chosen and the licenses they produce for users of their website seem a little too close to the practice of law (or, the creation of an attorney-client relationship) - - and all of what that entails. And, I still have significant reservations about the use of text open source licenses online. Having said that, I agree that a common-sense drafter-friendly interface of some of the different TYPES of open source licenses is a good idea. : : Sources which may not be distributed are not open source. I : strongly suggest that you not use that term. : : ... on this mailing list which is OSI-specific and uses OSI-specific : terminology. : : Alex. - Rod Rod Dixon Blog: http://opensource.cyberspaces.org : -- : 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: [OT?] US CA govt use of PDF fill-in forms
The PDF format is now an open standard, and other vendors operate in the PDF space. Once it is widely known among enough vendors that government agencies want to use puffs to create editable forms, I am sure others will enter the space, if they have not already done so. I doubt that there is a significant or long-term problem here. -Rod - Original Message - From: Ihab A.B. Awad [EMAIL PROTECTED] To: Mahesh T. Pai [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 26, 2004 12:59 PM Subject: Re: [OT?] US CA govt use of PDF fill-in forms : On Monday 26 April 2004 02:53, Mahesh T. Pai wrote: : Ihab A.B. Awad said on Sun, Apr 25, 2004 at 07:37:06PM -0700,: :Should the government be thereby institutionalizing this format :(Adobe Acrobat PDF) to the benefit of the one corporation (Adobe) :that provides tools to properly edit it? ... : : FSF India says the government should not use the portable document : format. See http://www.gnu.org.in/philosophy/mitrules.html : : Thank you for the link ... I didn't know about that! : : rant : : Actually, with all due respect to FSF India's opinion -- which is pretty much : what I would expect from FSF anywhere -- I claim the US tax agencies' policy : fails an even weaker standard: that of the availability of more than one : source for the software required to use the format. : : The killer here is that you *can* use the PDF form -- but you just can't save : an *editable* copy without paying $$$ to Adobe. So extra taxpayer money was : spent creating PDF forms (as opposed to simply providing PDF to be printed : and filled out in hardcopy). Then, to use this taxpayer-sponsored work, you : end up shoehorned into the marketing campaign of the one and only source of : software for it. : : /rant : : Peace, : : Ihab : : -- : Ihab A.B. Awad : Snr Scientific Programmer, Dept of Genetics : Stanford University : : -- : 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: Adaptive Public License
This is a good point. I also laud the effort by those who spent the past year or so trying to make it easier to use and adapt licenses. Unfortunately, occasionally something meant to be easy is more complex because it bends too many preexisting rules or customs. The easy way to make a modular license is to start out the same way FSF has done; think of the GPL as a base license and the LGPL as a modular adaptation. If there are certain known adaptations of your license, you can create them and distinctly name them; otherwise, you are asking OSI to approve licenses that do not yet exist, but could exist if someone made the adaptation. This brings us full circle to the proliferation of licenses. On the other hand, you can draft a license that can easily be used as a template for others, but you will not have the authority to control how the template is used (but that is the point of a template). Rod On Fri, 16 Apr 2004, Ernest Prabhakar wrote: Hi Carmen, I sympathize with your goal. I think there's really several things going on: a) You want to create a license for your project b) You want to make it easy for people to create variations of your license c) You'd like to get OSI approval once to cover all licenses In that sense, the APL is really a meta-license, which is intended to make it trivial to generate various OSI-compliant licenses. Is that a fair statement? There has been periodic talk of such a Universal License, and I applaud your willingness to undertake this beast. I suspect the problem is that the optional modules make life easier for the *licensor*, but painfully confusing for the *licensee*. I wonder if it might be more productive - and simpler - to break the problem down differently. One approach might be to create a Customizable Public License rather than an Adaptive one. 1. Create a baseline license (with no optional terms, though a few 'fill-in-the-blanks, like ), which reflects your immediate needs 2. As a separate document, define optional modules which could be used to modify the baseline APL. 3. Specify that people need to change the name when using a different version (and perhaps suggest a naming scheme which reflects the modules included). 4. Obtain OSI approval for the baseline license, and (separately, but simultaneously) approval that modifications associated with the various optional modules would NOT impact OSI approval. That way, it is still the responsibility of the licensors to create a coherent document, but if they follow a well-defined path they are effectively pre-approved of OSI certification. Would anyone else find that useful/interesting? -- Ernie P. On Apr 15, 2004, at 6:58 PM, Carmen Leeming wrote: I am sorry for the confusion in my previous email regarding our application of the Adaptive Public License. We have developed a specific program that we wish to distribute as open source. Our requirements were not met by any existing license. We therefore hired a lawyer to aid in drafting a new license that would fit the needs of our product. In the meantime, I have been promoting open source throughout my University and encouraging other groups to release their software as open source too. Since the University was spending a lot of money on this lawyer, we thought it best to try to meet the needs of the other projects that the University would like to release. Due to various research group restrictions, patent right clauses were desired in some cases and not in others. Different groups had ideas for how they wished changes to be documented as well. Another concern with a university is about how widespread software could be distributed for internal use without needing to release the source externally. For example, some universities own partial interest in start-up companies that spawned from research at the university. In some cases you may want to allow sharing of modifications to these entities without forcing the changes to be released publicly; in other cases you may want to maximize the openness of the software and prohibit widespread-internal distributions of closed source modifications. Seeing that the University of Victoria could gain more benefit from this license if we made it adaptable, that was the route we chose. We also had input from other universities about whether or not these features would meet their needs. We then added the jurisdictional option to allow other universities (or anyone else) to be able to use this license. I hope this clears up the issue of why we are applying. We developed a license to meet our needs, which are not limited to a single project. We could have submitted several similar licenses with the adaptive clauses pre-set, but felt that this would just add needlessly to the group of existing licenses. We felt a more elegant solution was to have one license that our various research
Re: Adaptive Public License
Michael - I agree with you regarding whether this license solves a problem that an existing license does not. I think the drafter will have to explain; otherwise, I would not recommend approval of the Adaptive Public License since it is not attached to a specific project and appears to be an example of the undesired proliferation of licenses. Rod On Thu, 15 Apr 2004, Michael Tiemann wrote: Russ Nelson called for more discuccion of this license, which does look interesting to me. The OSI board has certainly spent its share of time talking about license compatibility (or the lack thereof), and this license certainly encapsulates many of the issues we've discussed. My initial read of this license is that yes, it does satisfy the letter of the OSD, so that's a Good Thing. But the larger question that I must always ask is: if/when it becomes used by multiple third parties, what problems can it solve that other OSI-approved licenses don't solve. What is unclear to me is how this license addresses the question of what happens when two (or more) parties check the boxes differently in Exhibit A. Are there any incompatible choices within this framework, or are the combined licenses severable (meaning every individual part remains valid even when some parts offer different terms)? If the latter, then this is a very interesting license and I think we should move to approve. If the former, it's not clear to me that having a name for a license that preserves the incompatibility issue is all that valuable. In fact, it may be bad. Michael Tiemann -- 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: Adaptive Public License
It sounds as if you are attempting both to control the distribution of your license along with your software package and to control the distribution of the license as adapted for others; this is rather strange to me. I think there are, generally, three approaches to drafting open source licenses: you draft a license for a specific open source project regardless of whether someone else may want to use the license as a template, you draft a license for a project and/or that is well-suited to be used by others as a template (e.g., OSL v.2.0), or you adopt a license that already exists on the basis that it meets your needs and that its popularity or well-known status signals its terms to many open source users (e.g., GNU GPL). I do not see the Adaptive Public License fitting the last category since the license is adaptive; in other words, its terms will vary. Nearly any license can be a template so I am unsure why an adaptive license is needed. Consequently, it may make better sense to focus the drafting of your license on your software package and the needs of your business model, and leave the adapting to those who adapt. -Rod - Original Message - From: Carmen Leeming [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 15, 2004 4:50 PM Subject: Adaptive Public License : The way the Adaptive Public License is set up, only the Initial : Contributor sets the terms outlined in Exhibit A (all the adaptive : elements). Subsequent Contributors may not alter the variables outlined : by the Initial Contributor. However, Subsequent Contributors are not : bound by those terms if they package their work as an Independent : Module. An Independent Module may be released under a different license : (including a variation of the Adaptive Public License with a different : Exhibit A). : : In regards to combining different variants of the Adaptive Public : License, yes the combined licenses can be severable. One of the : licenses needs to be continued as the Initial Work -- subsequent : contributions would follow this license (unless they are Independent : Modules). The other work(s) being combined can be identified as : Independent Module(s), retaining their original variants of the : license. In a similar manner, an Initial Work with the Adaptive Public : License can be combined with other open source (or closed source) : licenses without absorbing contributions to the separately-licensed : Independent Modules. : : I know that this license is very long, but it is difficult to summarize : parts of it without losing the overall integrity of the document as : various parts are interrelated. The third paragraph in my submission : letter : (http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:6913:200305:bogcdnbbhnfbgpdea hob) : is the briefest way I can summarize the differences between the Adaptive : Public License and the MPL 1.1. Although that is the closest license to : this one, the Adaptive Public License was not directly derived from the : MPL -- it is not simply a matter of a few differing paragraphs. : : There is no existing license that contains all of the features that we : require for our project: able to have the governing jurisdiction in : Canada; able to have the main work as open source, but well-defined : separate modules as closed source or under a different open source : license; not being forced to have a patent license; able to define our : own set of documentation requirements; allowing limited attribution : requirements for the Initial Contributor. This license was not : developed for the sake of adding to the proliferation of licenses. The : University of Victoria has spent close to four years developing a large : software package that it would like to be able to share with the open : source community. The University was not willing to release the : software under one of the existing licenses as none of them could : provide all of the features listed above. We spent a year working with : a license lawyer developing the Adaptive Public License to meet the : requirements of the University. We purposely did not brand the license : with our name or our project title so the license could be useful to : others. We have had others inquire about using our license for their : software products, and there was a comment on this forum in March that : indicated support for use too, so we know that this is not a one-time : application of the license. : : Please let me know if you have any further questions. : : Thank you, : --Carmen Leeming : University of Victoria : -- : 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 potential transfer problem
I do not see section 205(e) creating a problem for open source at all. Rod On Fri, 19 Mar 2004, daniel wallace wrote: Any code developer who releases FOSS code under an unsigned, nonexclusive license retains the original copyright ownership rights. If the code developer subsequently legally transfers his copyrights to a new owner, the code released under the license is no longer protected from infringement claims by the new copyright owner. TITLE 17 - COPYRIGHTS CHAPTER 2 - COPYRIGHT OWNERSHIP AND TRANSFER Sec. 205. Recordation of transfers and other documents. (e) Priority Between Conflicting Transfer of Ownership and Nonexclusive License. - A nonexclusive license, whether recorded or not, prevails over a conflicting transfer of copyright ownership if the license is evidenced by a written instrument signed by the owner of the rights licensed or such owner's duly authorized agent, and if - (1) the license was taken before execution of the transfer; or (2) the license was taken in good faith before recordation of the transfer and without notice of it. Sec. 205 (e) states a sufficient condition for a nonexclusive license to prevail. Is it a necessary condition? IF it is signed THEN it prevails (a sufficient condition), but does... IF it prevails THEN it is signed (a necessary condition) hold true? Here are the remarks from the anointed USC (section (e) is formerly section (f)). ... under subsection (f) of section 205, a nonexclusive license in writing and signed, whether recorded or not, would be valid against a later transfer, and would also prevail as against a prior unrecorded transfer if taken in good faith and without notice. Objections were raised by motion picture producers, particularly to the provision allowing unrecorded nonexclusive licenses to prevail over subsequent transfers, on the ground that a nonexclusive license can have drastic effects on the value of a copyright. On the other hand, the impracticalities and burdens that would accompany any requirement of recordation of nonexclusive licenses outweigh the limited advantages of a statutory recordation system for them. As we have witnessed with the SCO debacle, any questions concerning nonexclusive license and copyright transfers should be examined in the short term so that any enterprising mischief makers (read Microsoft) can be neutralized. -- 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: LAB Public License proposal
I do not see an OSD issue for here. Consequently, I recommend approval of the CUA Office Public License. This license does raise interesting questions about what appears to be a choice of law matter. I am not sure why French law is presenting the problem the poster says it does, but software distributed on the Internet seems capable of a simpler solution than drafting licenses in the manner proposed by the current draft of the CUA Office Public License. After acknowledging the intentions of the drafter of the CUA Office Public License, sections 4, 10, 11, and 12 seem oddly worded. For example, it is difficult to unravel the meaning of this phrase from section 12: This LICENSE shall be governed by French law provisions (except to the extent applicable law, if any, provides otherwise), excluding its conflict-of-law provisions Except when? In addition, there are terms in this license that were borrowed from the previous license; some of these terms add a layer of confusion to the poster's license - - or, perhaps, the terms should be dropped from the original license as well. At any rate, sections 4, 10, 11, and 12 should be reviewed to eliminate terms that do not meaningfully add to the drafter's intent. This license should be easier to read than it is now. Since I am not providing legal advice, I cannot be more specific. You would benefit from having your legal counsel review the terms of this license before finalizing the draft. - Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org Le lundi 15 Mars 2004 21:35, Rod Dixon, J.D., LL.M. a Ă©crit : It might help if you highlighted the changes (using color text or bold facing). Is your explanation as to why you have declined to adopt the CUA Office Public License limited to the desire to comply with regulations in three jurisdictions? Would you be more specific? Rod A highlighted version is on line at http://www.lab-project.net/tests_priv/liclab-annotated.html for review. One of the reson we had to change some things from CUA Office Public License have to do with French laws imposing some legal mentions on all contractual papers or forms. We had to introduce a section for French Government End Users. In final, CUA Office Public License is great, only missing non USA specific legal information. This license only fills the gap. -- JCR aka DJ Anubis LAB Project Initiator coordinator -- 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: Source Distribution License
Alexander's point is not exactly correct, but I think the main point was on target; namely, in addressing questions concerning the copyrightability for software, the object code is not likely to be treated differently than the source code. In some cases, the distinction between object code and source gets pretty fuzzy and, in my opinion, treating the two differently would dislodge whatever is left of the logic in our copyright jurisprudence that applies to software. Having said that, Alexander's mistake appears to be his reference to the copyright office. While the copyright law may treat source code and object code similarly, the copyright office does not. Instead, the copyright office may accept a filing for registration of software in the form of object code only under what is called the rule of doubt. Ostensibly, the rule of doubt means that courts give even less deference to the copyright office's finding of copyrightability than the court would acknowledge, if it were assumed that the copyright office actually read the source code sample submitted with the copyright registration application. The application of the rule of doubt should mean that the party alleging copyright authorship on the basis of a work in object code has a heavier burden of proof than a software developer who files for copyright registration using source code. Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org : Mahesh T. Pai wrote: : [...] : General consensus is that binaries are modified/derived versions of : sources. : : AFAIK, The U.S. copyright office doesn't agree (the copyright : office regards the source code and object code as equivalent : for purposes of registration). : : regards, : alexander. : : -- : 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 must read for license law
I agree with John, but, if there is a connection, it is not readily apparent. Would you explain your point further? There may be a conceptually interesting question regarding whether a particular public license is a restriction on liberty or a grant of permission to do a thing that otherwise would be unlawful to do, but none of that seems particularly relevant to open source software licensing. The use of the term or phrase general public license or public license even may raise the question in what sense are those licenses public licenses rather than private agreements, but I doubt that any OSI-approved open source license using the phrase public license conveys a sense that the license presents the concern raised by the quoted 1953 law review article about government licensing schemes. Rod - Original Message - From: John Cowan [EMAIL PROTECTED] To: daniel wallace [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 13, 2004 8:10 PM Subject: Re: A must read for license law : daniel wallace scripsit: : : The following link is the best work on license : law that I have ever found: : : http://www.lawyerdude.8k.com/5943.html : : Disaster lurks for those who do not comprehend : the difference between a *malefaction* and a : *benefaction* in copyright license law. : : I do not believe (IANAL, TINLA) that the public licenses Lawyerdude : refers to have anything to do with the public licenses of the open : source world. He seems to be talking about the license to practice : law which he no longer has. : : -- : Values of beeta will give rise to dom! John Cowan : (5th/6th edition 'mv' said this if you triedhttp://www.ccil.org/~cowan : to rename '.' or '..' entries; see [EMAIL PROTECTED] : http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) : -- : license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: License Committee report - regarding NASA Open Source Agreement Version 1.1
I think the NASA Open Source Agreement is worthy of OSI's approval - - with revision, but it also raises issues worthy of discussion and, perhaps, adjustment to the OSD since the internationalization of intellectual property law will likely raise similar open source licensing issues for other governments. Regarding the issue concerning whether NASA may license software it cannot copyright in the U.S., the answer is yes, notwithstanding that significant harm to the conception of public domain for digital works is likely to follow. More generally, there may be good reason to add an article to the OSD regarding government open source licensing. Since it might be prudent to encourage open source licensing by governments for a number of reasons, OSI may want to consider under what conditions that this may be done. For instance, government bodies could be permitted/required to add a clause to the license safeguarding public domain rights where applicable. Further, it may be worth noting that government agencies like NASA could be encouraged to seek out open source developers when developing software rather than outsource development strictly to non-open source developers, which means the software is neither public domain (a government contractor may assert copyright), nor open source. With regard to the NASA license, I have three points. [1] The license contains an ambitious definition of display under section 1, which, effectively, imposes a restriction on the use of the software that I doubt is consistent with the spirit of a number of articles of the OSD. This definition may need revision to be more consistent with traditional Copyright law conceptions of display of a computer program. The user registration requirement/request line at the beginning of the license seems unclear as to purpose and, therefore, it is difficult to determine whether it is in compliance with article 7 of the OSD. Why is the government collecting user names, and is this part of the license intended to reach those licensees/sublicensees receiving the work as part of a redistribution? I do not view section 3.F of the license as answering my question since it is not clear why tracking registrations is needed either. [2] Regarding section 3.J, in all fairness, open source licenses used to distribute online software initially created by the U.S. government ought to carry a provision clearly indicating whether the export license from the Commerce department has been obtained and/or whether such a license is required. Notably, NASA IS ostensibly exporting the software since the open source license is not necessary, if the program is distributed within the United States or to U.S. citizens. Section 3.J should be revised. [3] Section 5.F should also be posted on NASA's website since the designated representative listed on any particular license in the hands of a licensee is likely to be outdated long before the license terminates. - Rod Rod Dixon Blog: http://opensource.cyberspaces.org : -- : : There is much discussion spent deciding whether NASA can copyright : software at all. The license itself says that no copyright is claimed : in the United States. : : The only serious concern that I can see is that the license requires : the recipient to indemnify the Government of the United States against : third party lawsuits. : : Title: NASA Open Source Agreement Version 1.1 : Submission: http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7698:200402:jfdgbalgdhgblndpmljm : License: http://www.nas.nasa.gov/Research/Software/Open-Source/NASA_Open_Source_Agreement_1.1.txt : Comments: ongoing as of this writing. : Recommend: more discussion. : : -- : --My blog is at angry-economist.russnelson.com | Coding in Python : Crynwr sells support for free software | PGPok | is like : 521 Pleasant Valley Rd. | +1 315 268 1925 voice | sucking on sugar. : Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Sweet! : -- : 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: International treatment of the public domain
I do not have an answer to the specific question, but I suspect the answer may reside in a treaty or an international agreement that is not a treaty. The Uruguay Round Agreements Act (URAA), for instance, allows works in the public domain in the U.S. to be scooped out of the public domain retroactively if those works whose source country is a member of the WTO or the Berne convention meets a set of criteria that the U.S. has agreed to. I doubt that this is a unilateral privilege so we may assume the public domain shrank in 1994 and thereafter. Still, I am unsure how this would affect an open source license since the license MAY be enforceable in the U.S. or, possibly, an international dispute resolution forum administered by WTO/WIPO -Rod [EMAIL PROTECTED] opensource.cyberspaces.org On Tue, 17 Feb 2004, Russell McOrmond wrote: I believe that the OSI is not USA only, so I hope this question does receive some discussion. On Mon, 16 Feb 2004, Russell Nelson wrote: [EMAIL PROTECTED] writes: So Americans can ignore the civil-servant version of the NOSA license with impunity, but not so Australians. Interesting ... so what happens if an American citizen takes public domain US Government software into Australia and starts redistributing it there? But I suppose that's a problem that the NOSA will fix, so at least for this discussion it's a moot point. What if any US citizen took this work that is under the public domain (for them) and applied a BSD (or any other) license and redistributed worldwide? It appears that with US government created works that every US citizen has the right to apply licenses to the work, so whether any specific citizen (or a group) applied a NOSA license doesn't seem all that relevant. Which license agreements apply to a Canadian like myself? I would suspect any of them -- whether it be the NOSA agreement or the BSD or whatever other license an American wishes to apply to this public domain work. If I don't like the NOSA agreement I can just call a friend in the USA who can offer me the work to me in a BSD license. I think there is an interesting question being opened up by this discussion. Given that term expiry is not the only way for a work to enter the public domain, and term expiry can be different in different countries (A Disney production gets 95 years in the USA but fortunately only 50 years in Canada), are the other methods to enter into the public domain also country specific? It was always my understanding that a work that was released into the public domain by its author (Such as by a public domain dedication http://creativecommons.org/licenses/publicdomain/ ) in the USA or any other country that this work was instantaneously in the public domain in all countries. This thread is outside the topic of license approval so is likely considered off-topic. This is unless we want to consider the worldwide applicability of the Creative Commons public domain dedication as an OSI license approval question. --- Russell McOrmond, Internet Consultant: http://www.flora.ca/ Perspective of a digital copyright reformer on Sheila Copps, MP. http://www.flora.ca/russell/drafts/copps-ndp.html Discuss at: http://www.lulu.com/forums/viewtopic.php?t=2757 -- 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: Initial Developer's Public License
Larry - For what it is worth, I think your analysis is exactly correct. -Rod On Wed, 11 Feb 2004, Lawrence E. Rosen wrote: Here are two examples that I think would not be allowed under OSL which are allowed under IDPL. A commercial database repair tool that uses the on disk structure definitions, compression/decompression routines and other parts of the Firebird database code. The repair tool combines that code with proprietary code to discover and repairs corruption. Developers of such a tool would publish the interfaces between the Firebird code and their own code, but would not be compelled to release their product under an open source license. A package for automatically compressing the stored format of the database. The actual compression code could remain proprietary. The developer could sell Firebird in half the space. However the interfaces to the compression code would be published under the IDPL, allowing others to create plug-replaceable compression packages. Ann, As I understand copyright law, the OSL and IDPL have the same effect. I don't see the plug-in applications you described as creating derivative works, except for the modifications you have to make to the Firebird code itself to plug-in those modules to those API interfaces. The changes to Firebird code would have to be distributed under the OSL, but only those changes. Licensees could implement other plug-in software to discover and repair corruption or to do compression -- and plug them in the same way. It makes no difference whether the plug-ins are open source or proprietary. This depends, of course, on my analysis of whether the combinations you described are derivative works. I suggested that they aren't, based on your brief descriptions. (Please don't draw specific legal conclusions from my preliminary read of your software architecture; I disclaim anything you might interpret as advice!) I gather your product is designed to work with independently-created and independently-owned plug-ins. If so, how does your simply linking to those plug-ins (or from those plug-ins to you) cause them to be brought under the terms of the OSL? A licensor under the OSL has no right to do that. No open source license can prohibit any licensee from creating proprietary combinations of independently-created proprietary and open source software that merely work together through APIs. Such combinations are not derivative works of software. Does anyone on this list disagree with that conclusion? If so, what factors about derivative works analysis in the software context am I forgetting that are relevant to Ann's brief examples? /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: The Copyright Act preempts the GPL
In addition to the point made, you might inquire whether what a machine does when compiling code is an apt comparison to what an individual does when translating text. My answer is no since machines cannot be authors under Copyright law. Rod On Mon, 9 Feb 2004, John Cowan wrote: Alexander Terekhov scripsit: To me, compilers (and tools like http://world.altavista.com) do nothing but transliteration, not translation in the legal sense. I may be wrong, of course. A strong point, certainly; but I think legal language, like ordinary language, applies mechanical to only a small subset of the acts that can actually be done by machines these days; roughly, those performable by machines that have only a small amount of state or none at all. Certainly machine translation is not translation in the full sense of the word, but the (very imperfect) state of the art requires considerably more state than seems to me consistent with the meaning of the word mechanical. -- All Norstrilians knew what laughter was:John Cowan it was pleasurable corrigible malfunction.http://www.reutershealth.com --Cordwainer Smith, _Norstrilia_[EMAIL PROTECTED] -- 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: The Copyright Act preempts the GPL
Hmm...there is a part of your argument that is appealing in a conceptual sense, and I think it would be correct to say that Copyright law has allowed for distinctions between the compiled program and source code. For example, one could refer to source code as a literal aspect of software and at least parts of the compiled program's non-literal aspects (e.g., user interface). With the use of IDE's to compile (especially for graphical user interfaces) programs, one could argue that the non-literal aspect (certainly some of it) of a program is machine generated. Even so, this may just be a modern path to the same point Copyright law already has arrived at from litigation and allegations in the 1990's involving Microsoft, Apple, Lotus, and a couple of others. Rod [EMAIL PROTECTED] On Mon, 9 Feb 2004, Ruth A. Kramer wrote: Alexander Terekhov scripsit: To me, compilers (and tools like http://world.altavista.com) do nothing but transliteration, not translation in the legal sense. I may be wrong, of course. I may be off the mark, but to me, part of the implied question (perhaps in an earlier post?) is whether a compiled program is a derivative work of the compiler? IANAL, but in my understanding it is not. It is, however, a derived work of the source code, IIUC. Randy Kramer -- 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: The Copyright Act preempts the GPL
I must be missing something from your argument. It sounds like you are describing copyright infringement. If so, the impediment can be removed if the court agrees. Rod On Mon, 9 Feb 2004, Peterson, Scott K (HP Legal) wrote: If, when impeded in some way from undertaking one of the actions exclusive to the copyright holder, a copyright holder could go to court and use the copyright rights to overcome the impediment - that would be an exercise of an affirmative right. As I am not aware of an example of a copyright holder exercising a right in such a way, I continue to find it most helpful to think of copyright as a negative right. -- Scott -Original Message- From: Tony Stanco [mailto:[EMAIL PROTECTED] Sent: Saturday, February 07, 2004 8:07 AM To: [EMAIL PROTECTED]; Peterson, Scott K (HP Legal); 'John Cowan' Cc: [EMAIL PROTECTED] Subject: Re: The Copyright Act preempts the GPL Scott, my understanding is the same as Larry's. Copyright provides exclusive plenary rights to the owner. Patents provide the owner only with the right to exclude others. I think the distinction was grounded in the fact that it would be hard to conflict with someone else's copyright in an original work (which usually stood alone), while complex, interrelated processes/machines could easily involve multiple and conflicting patents. As a result, patents are only negative rights and a person's exploitation of a particular patent in subject to the non existence of conflicting patent(s). Best regards, Tony - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Peterson, Scott K (HP Legal)' [EMAIL PROTECTED]; 'John Cowan' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, February 06, 2004 8:39 PM Subject: RE: The Copyright Act preempts the GPL Scott Peterson wrote: The rights provided under US copyright law are negative rights (the right to exclude others), not positive rights (the right to do something yourself). I don't think so, Scott. At least that's not how the copyright act reads: ...The owner of copyright under this title has the exclusive rights to do and to authorize any of the following The patent law is exactly the opposite. ...Every patent shall contain ... a grant to the patentee ... to exclude others from using or selling /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 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: The Copyright Act preempts the GPL
Putting aside the issue that a 3 line computer program may lack the minimal indicia of originality to be copyrightible in the first place, strictly speaking, what Bob may do with his derivative work (if that one line code is copyrightible) may depend upon whether Bob wants to distribute the work or use it (internally). In other words, section 117 and section 107 may limit the reach of Alan's right to control the distribution of derivative works. BTW, if you recall the courts' general confusion and disagreement over how far you may take section 107 in the video game cases, it becomes apparent that in some cases fair use is not an insignificant matter. In addition, when you apply judicial interpretations of derivative use, you begin to notice that the language of the Copyright Act is a mere starting point. How judicial doctrine on derivative use will be applied to software or other digital works is often an open question (e.g., Tasini v. New York Times modifications of collective work constituted new work, not derivative [revised] work). Consequently, to prove that a derivative work is infringing, courts have read into section 101 two general requirements: 1) the derivative work must incorporate some of the original copyrighted work, and 2) the infringing derivative work must be substantially similar to the original copyrighted work. To make these determinations, the court uses various tests, including a test one poster mentioned earlier (abstraction etc.). In my opinion, current judicial doctrine on derivative works - - in the proof of infringement context - - lacks practical use for software developers, but, as it stands, you cannot ignore it either. And, you may not want to ignore judicial doctrine if you authored the derivative work since the doctrine generally goes further than the words of the Copyright to render some ostensibly derivative works non-infringing in my opinion. Rod [EMAIL PROTECTED] On Sun, 8 Feb 2004, John Cowan wrote: Peter Fairbrother scripsit: Alan writes an original computer program. It is 3 lines long. It is called Hello world. Bob takes Alan's program and replaces line 2. The new program is called Goodbye asshole. Goodbye asshole is a derivative work. If Bob did not have Alan's permission to create a derivative work then he gets no rights at all. So far so good. If Bob had Alan's permission to create a derivative work then he gets the sole right to distribute line 2. He had that much even without Alan's permission, since line 2 is solely his work. This paragraph belongs to me, though only with your (implied) permission can I use it in this email, which is a derivative work of your email. (That is assuming that my use of your email is not a fair use, which I think it almost certainly is, but that's a different kettle of fish). He does not get any right to distribute lines 1 and 3. He cannot distribute Goodbye asshole including lines 1 and 3 without separate permission from Alan. Once the derivative work is lawfully created, Bob is the copyright owner, and has all the exclusive rights of the copyright owner. And now I'm going to shut up, because obviously we are looping, and I'm not going to convince you nor vice versa. -- And it was said that ever after, if anyJohn Cowan man looked in that Stone, unless he had a [EMAIL PROTECTED] great strength of will to turn it to other www.ccil.org/~cowan purpose, he saw only two aged hands withering www.reutershealth.com in flame. --The Pyre of Denethor -- 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: bare license
Yes, the issues are exactly as you quite effectively summarize. In my post, I was not expressing my opinion on the merits of the contract/license debate; rather, I was noting the primary issues usually involved in that debate. Rod - Original Message - From: daniel wallace [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 16, 2004 11:17 AM Subject: Re: bare license : If any of the rules and formalities of contracts you mention : are required to be enforced under state law, that involves an element : of state action. The GPL purports to overcome privity questions about : third party distribution ad infinitum. This appears to create a new : right against the world that is referred to in Procd v. Zeidenburg : by the 7th Circuit. This seems to imply the GPL would be preempted : by sec. 301 if any attempt is made to enforce the GPL under state action. : -- : 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: bare license
I do not think the reason why FSF favors the argument you mentioned -- that an open source license is a license, not a contract -- is a secret. A copyright license typically sets forth the rights granted by the licensor. The issue that occasionally arises is whether a copyright license like the GNU GPL must meet the rules and formalities typically associated with contracts (e.g., mutual assent). Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org - Original Message - From: dlw [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 9:02 AM Subject: bare license : I think I understand why the Free Software Foundation insists that : a license is not a contract. Their belief is grounded upon : a mistaken interpretation of the case law on licensing patents, : highlighted in a 1938 decision by the Supreme Court in : General Talking Pictures Corp. v. Western Electric Co., : Inc., 305 U.S. 124 : : : The question of law requiring decision is whether the restriction : in the license is to be given effect. That a restrictive license : is legal seems clear. Mitchell v. Hawley, 16 Wall. 544. As was said : in United States v. General Electric Co., 272 U.S. 476, 489 , 47 : S.Ct. 192, 196, the patentee may grant a license 'upon any : condition the performance of which is reasonably within the reward : which the patentee by the grant of the patent is entitled to secure.' : The restriction here imposed is of that character. The practice of : granting licenses for a restricted use is an old one, see Providence : Rubber Company v. Goodyear, 9 Wall. 788, 799, 800; Gamewall Fire-Alarm : Telegraph Co. v. Brooklyn, C.C., 14 F. 255. So far as appears, its : legality has never been questioned. The parties stipulated that 'it : is common practice where a patented invention is applicable to : different uses, to grant written licenses to manufacture under : United States Letters Patents restricted to one or more of the : several fields of use permitting the exclusive or non-exclusive use : of the invention by the licensee in one field and excluding in : another field. : : : The phrase above, the patentee may grant a license 'upon any : condition the performance of which is reasonably within the reward : which the patentee by the grant of the patent is entitled to : secure.' refers to the fact that any condition imposed in a bare : license (no contractual terms) may restrict only the use of the : exclusive rights (reward) of the patentee. The patentee : alone is the only person who can restrict his exclusive rights. : : The phrase quoted above does not apply analogously to all : exclusive rights in derivative copyrighted works. In patent law : there is no such thing as a derivative patent defined as two : distinct legal parties owning independent exclusive rights in : the same idea. : : Sec. 103 (b) The copyright in a compilation or derivative work extends : only to the material contributed by the author of such work... : The copyright in such work is independent of, and does not affect or : enlarge the scope, duration, ownership, or subsistence of, any : copyright protection in the preexisting material. : : An original author has an exclusive right to commission a derivative : work, but his exclusive rights encompass only his preexisting work : in the commissioned work. The original author must bargain for the : modifying author's exclusive rights. They exist independently of the : original author's exclusive rights and hence do not fall under the : scope of a bare license. They are not within the reward which the : copyright holder by the grant of the copyright is entitled to secure : of the original author. : : A summary of the above reasoning is a unilateral grant of permission : for a derivate copyright work does not exist within the scope of the : definition of a 'bare' license. : : -- : 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: For approval: Open Test License v1.1
Hmm... If you could answer yes or no to some of my questions I could possibly provide a helpful response. I think the way you have written the provision containing condition 3 is problematic, but it is not apparent - - not to me, at least - - why it is included in your software license. If you dropped it, you might have a more viable open source license. Have you considered protecting your reputation interest through trademark? - Rod : Is this one way condition 3 might work? Is the intent of condition 3 : to retain for the original copyright holder some degree of control : over what licensees say about test results? : : The intent is to prevent users from using standardizes test names to : name non-standard tests and their results. Such naming would mislead : those who read/use results and may damage OWNER's reputation. : : Non-standard tests include any violation of standard rules, including : modification of the software if standard rules require a specific : original version to be used. : : It is perfectly fine to use non-standard names for non-standard tests. : No permission is needed for that and no standard rules can prohibit : that. : : If the answers are yes, could you provide a specific example of what : you are trying to prevent when you say: We just do not want users : to fiddle with what is already standardized and frozen. It may be : easier to provide a suggestion on how to fix your clause. : : Does the above example and discussion clarify? Can the wording of : clause #3 be improved without adding 10 terminology paragraphs to the : license? : : Thank you, : : Alex. : : : 3. Publication of results from standardized tests contained within : :this software (TESTNAME, TESTNAME) must either strictly : :adhere to the execution rules for such tests or be accompanied : :by explicit prior written permission of OWNER. : -- : 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: For approval: Open Test License v1.1
You are correct that a weak trademark will require vigorous enforcement to avoid losing the distinctive quality of the mark; other than that, however, I am at a loss to come up with a pertinent distinction - - in terms of the size of the OWNER - - in how the job of enforcing your copyright license differs from enforcing a trademark license. You may want to undertake a careful re-consideration of your goal for condition 3, and see if it can be implemented in some other way. In the meantime, it sounds as if an existing approved open source license might meet your needs nicely. Rod - Original Message - From: Alex Rousskov [EMAIL PROTECTED] To: Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 09, 2004 7:59 PM Subject: Re: For approval: Open Test License v1.1 : : On Fri, 9 Jan 2004, Rod Dixon, J.D., LL.M. wrote: : : it is not apparent - - not to me, at least - - why it is included in : your software license. : : Clause #3 is included to prevent serious violations and cheating when : publishing standardized test results. Such publications often hurt : OWNERs and tool image and credibility. : : Have you considered protecting your reputation interest through : trademark? : : Yes, I have. AFAIK, the problem with trademarks is that they need to : be constantly enforced to stay in force. This is difficult to do for a : small, user-friendly company, informal development group, or an : individual author. : : Imagine: every time somebody publishes a test result with your : trademark in it, you have to contact the publisher, demand : changes/corrections/removal of test results, and threaten them with a : law suite if you think they even sightly violated the trademark usage : rules. You most likely need to pay somebody to draft such complains as : well. : : The publisher may be an innocent guy doing some simple testing that is : unlikely to be visible enough to affect your reputation. Thus, you : would not bother him, but you have to, because if you do not do that, : then when a real violation happens, the violator (now a big company : with lawyers, etc.) will tell you to go to hell with your trademark : claims because they will point to 50 cases (archived on the web) where : you failed to enforce the trademark. All those cases were minor : violations by innocent, low-profile guys, but that does not matter, : does it? : : Is my rough interpretation of the trademark law correct? Will the : owner have to enforce the trademark all the time and every time? If I : am wrong, trademarks would be the way to go, of course. : : Thanks, : : Alex. : : P.S. If trademarks do not work, I will try to give yes/no answers : to your original questions. It is difficult to do that because : your questions are using terminology and use cases that does not : match what we have in mind. That is why I tried to explain rather : than say yes/no. : : : : 3. Publication of results from standardized tests contained within : :this software (TESTNAME, TESTNAME) must either strictly : :adhere to the execution rules for such tests or be accompanied : :by explicit prior written permission of OWNER. : : -- : 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: For approval: Open Test License v1.1
The issue I see for the Open Test License v1.1 is with regard to the provision containing the third condition. This may not be strictly an OSD problem, but, it is not clear to me how condition three is triggered. As written, it seems to require a POTENTIAL licensee to obtain written permission from the owner of the copyright to the original program if the potential licensee intends to say my falcon (a derivative work) past Owner's test by 5 parsecs if parsecs are not a standardized way to measure whatever Owner's tools measure. Is this one way condition 3 might work? Is the intent of condition 3 to retain for the original copyright holder some degree of control over what licensees say about test results? If the answers are yes, could you provide a specific example of what you are trying to prevent when you say: We just do not want users to fiddle with what is already standardized and frozen. It may be easier to provide a suggestion on how to fix your clause. -Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org - Original Message - From: Alex Rousskov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 7:28 PM Subject: For approval: Open Test License v1.1 : Dear all, : : Please discuss a license that we would like to use for at : least one of our testing tools (http://www.web-polygraph.org/). Since : there are many testing tools being developed, we tried to make a more : general license template for others to enjoy and improve. The text of : the license is at the end of this e-mail. The following sections are : based on item #4 in the OSI approval instructions at : http://www.opensource.org/docs/certification_mark.php#approval : : : Comparison with existing licenses : - : : The first two conditions are taken from the BSD license. : : The disclaimer is taken from the Apache license. : : The third condition is specific to the problem domain and is the : primary reason for Open Test License existence. A test suite often : comes with standard workloads, tests, test collections, etc. For : example, SPEC has SPECWeb99, and Web Polygraph has PolyMix-4. : These standardized tests are used in the industry to optimize and : compare products. Users want to make statements like my product : passes test Foo or my product is the fastest in its category : based on test Bar. : : This creates an incentive for cheating among users/testers. : Cheating becomes much easier if the benchmark can be modified. On : the other hand, we want our users to be able to modify the : benchmark, including adding new tests. We just do not want users : to fiddle with what is already standardized and frozen. : : The third license clause attempts to make sure that, informally, : : (a) users are careful about using well-known, : standardized test names when publishing test results : : (b) users can publish benchmarking results and make : public statements without owner permission if they : follow standard test rules or use their own, custom, : test names (e.g., MySpookWeb2004, not SPECWeb99) : : (c) cheating users that alter a standardized test to : mislead others and to win can be stopped and/or : punished : : Open Group and Artistic licenses attempt to do similar things, but : are too specific (e.g., assuming a test is an executable) and : are too complicated (and, hence, scarry) for non-lawyers. Thus, : we did not want to reuse those licenses but wanted to come up with : something much simpler, more general, and, hopefully, nearly as : effective. : : Note that controlling standardized test usage via trademark law is : often not possible for entities that do not have resources to go : after each and every violation of the trademark usage rules. : Thus, for a popular test tool made by a small entity, the : trademark power may quickly be lost. On the other hand, a : license does not need to be always enforced to remain in force. : : : Compatibility : - : : The license does not prohibit or restrict distribution of Open : Test software in conjunction with software distributed under : other licenses. The license does not seem to permit : relicensing OWNER's software under different terms. Thus, I am not : sure how to answer the Which license do you think will take : precedence for derivative or combined works? question in general, : other than saying that all licenses may apply. IANAL, so : if the above answer is not satisfactory, please guide me. : : Plain text version : -- : : Attached below. : : : : Please discuss. : : Thank you, : : Alex. : : -- : Protocol performance, functionality, and reliability testing. : Tools, services, and know-how. : http://www.measurement-factory.com/ : : : Open Test License : : Version 1.1 : : Copyright (c
Re: Why?
: Why do organizations that release software under a permissive, : non-copyleft license, use a license in the first place? This is an interesting question. I am assuming that the poster is really asking why use a non-copyleft license rather than a dedication to the public domain, but since the poster added the query: if you are not interested in keeping your software free, then why would you release your software with a license, there may be a question concerning why use a license at all, if the license is a permissive, non-copyleft license? I will offer my opinion on the latter question first. As a general matter, I think those who are comitted to open source are better served by using an open source license than in not using one. As reasons, I would include those regarding how even the most permissive open source license is likely to support the value of open source software than no license. Aside from that, it is worth considering that software as a literary work under copyright law is not exactly like typical literary works. If you purchase a book, for example, its basic ideas are apparent upon your use or enjoyment of the work; not so with software where many/most of the ideas remain hidden in the source code. If you want to access the hidden ideas, you usually need a license. In some respects, therefore, the default rules of copyright might be said to disrupt a copyright holder's ability to go without a license, even if the intent is to allow the end-user the same or a similar level of access as a book reader might have. What is the : difference between BSD and public domain? : I understand the need for a license, the use of copyright law, to keep : software free through copy-left. But if you are not interested in : keeping your software free, then why would you release your software : with a license? I think this question is slightly confusing. The fact that the BSD is permissive does not mean it cannot be used successfully as the legal instrument for developing an open source software project. The original copyright holder may have competitors (and some degree of free-ridering), but there are ways to manage these projects; most important, competition among forks (or, proprietary free-riders) is neither by necessity a bad thing, nor equivalent to abandonment of rights in your software. Consequently, a BSD licensor is not stuck using the license or dedicating the work to the public domain. It seems to me that two key pieces of this puzzle is that the potential licensor first establishes what he or she wants to accomplish, then selects a legal strategy and method to implement the goal; only if you reverse the order of the pieces do you create the conundrum of comparing the BSD license to the public domain. As the poster noted if, however, one wants to dedicate a software work to the public domain (with access to the optimal source code assured), doing so is slightly more difficult in the US. than it once was. The poster seems to ask whether the public domain should shield dedicators from all or certain forms of liability? To answer a question with a question: Does the story of the trojan horse provide a likely answer? -Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Why?
I have puzzled over John's comment concerning the right to recapture the copyright. As a response to Rick's statement, I do not know what John means??? -Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org - Original Message - From: John Cowan [EMAIL PROTECTED] To: Rick Moen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, December 29, 2003 3:50 PM Subject: Re: Why? : Rick Moen scripsit: : : It should be pointed out that a public domain declaration would _not_ : be a licence, but rather an attempt to nullify copyright title (which : may or may not work, and may have differing results depending on : jurisdiction). : : In any case, the right to recapture the copyright under U.S. law is : not alienable. : : -- : Do I contradict myself?John Cowan : Very well then, I contradict myself.[EMAIL PROTECTED] : I am large, I contain multitudes. http://www.ccil.org/~cowan : --Walt Whitman, _Leaves of Grass_ http://www.reutershealth.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: For Approval: Panda3D Public License Version 1.0
Although we are discussing the specific terms of a particular license, of course, my comments are not meant to constitute or substitute for legal advice. The Panda3D license makes a much better license template than the APSL; even in revised form, the APSL is wordy and less than clear at times. I think your lawyer did a good job. I think this license will warrant OSD approval; I have a couple suggestions, however. Clause 1 appears to be your mutual assent clause. Good. I would suggest, however, that the last sentence couple sentences be clearly written in the conjunctive or disjunctive (I suspect the drafter meant to use the disjunctive). Clause 6 (the treaded anti-advertising clause) is understandable, but is it really needed? If there is no implied or explicit right to use a Disney trademark or service mark anyway, why is the clause necessary? The anti-advertising clauses have been a source of discontent with free software folks, but I do not think the OSD strictly applies. (Minor point here) Clause 7 is informative, but it says nothing about the relations between licensor and licensee; hence, I am not sure it warrants the prominence of an entire clause of the body of the license. Clause 8 is unclear after the first sentence, which is probably all that is needed. Sublicensing? I feel obligated to mention that using approved OSI licenses as useful templates in drafting makes good sense, but as touchstones does not. Rod Rod Dixon, J.D., LL.M. Author: Open Source Software Law Best points of contact: Blog: http://opensource.cyberspaces.org e-mail:[EMAIL PROTECTED] voice:202-361-0797 fax:202-521-9317 - Original Message - From: John Cowan [EMAIL PROTECTED] To: Jesse Schell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, December 22, 2003 10:51 PM Subject: Re: For Approval: Panda3D Public License Version 1.0 : Jesse Schell scripsit: : : I believe the license was loosely based on the Apple Public Source : License. The lawyer who drafted the Panda3D license left the company : some time ago, and I haven't been able to reach him. Obviously, the : Apple license itself wouldn't suffice, since it explicitly names Apple, : where the Panda3D license names Disney instead. : : If you globally replace Apple with Disney, the result will be : trivially Open Source and will be no problem. It's possible that Apple : might object, but not very likely. : : 4. [...] : An electronic copy of the source code for all modifications : made to the Software are to be forwarded to Licensor at : [EMAIL PROTECTED] within 90 days of the date of the : modifications. : : Clauses like this are unreasonably burdensome on the makers of distros, : who typically have to make hundreds of patches to get everything : working together. Having to send hundreds of copies of source code : to different locations every time there is a new release is just too : hard. : : The license should be changed to require that the licensor be notified : of the location from which modifications can be downloaded. In that : way, there is only a single transmission required from the licensee, : not a whole series of them. : : If this problem is fixed, I see no problems with OSI approval. IANAL, : TINLA, IANA OSI board member either. : : -- : You let them out again, Old Man Willow! John Cowan : What you be a-thinking of? You should not be waking! [EMAIL PROTECTED] : Eat earth! Dig deep! Drink water! Go to sleep! www.reutershealth.com : Bombadil is talking. www.ccil.org/~cowan : -- : 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: Which License should I pick?
If, as stated, the basic codebase is not going to be changed or enhanced by contributions from anyone other than those created by the original copyright holder, then dual-licensing is clearly possible by using a less restrictive license. To be fair, I would announce the fact that the codebase will be subject to dual-licensing as soon as you go public...that may matter to potential licensees. As for copyright transfers, I suppose if this were followed by most, the SCO-IBM litigation would be less likely than it is. Demanding an assignment of copyright certainly makes it easier to manage the legal aspects of an open source project, but it seems to me to be a harsh requirement imposed upon those who are already freely contributing something of value. Rod Rod Dixon Open Source Software Law Blog: http://opensource.cyberspaces.org - Original Message - From: Scott Long [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 7:05 PM Subject: Re: Which License should I pick? : On Tue, 9 Dec 2003, Nick Moffitt wrote: : : How do you currently accept submissions? Do you take patches? : Third-party code modules or files? Think of how you can make clear : the permissions granted to you by the contributors. : : Well, the project hasn't gone public yet, which is why I'm asking these : licensing questions. I don't anticipate changes to the basic code base, : but I do expect that people may want to write various modules. : : I wouldn't necessarily be unhappy if those modules remained third-party : (i.e., they don't become part of the project). Then, I could take care of : the core code myself and let a packager put it all together into a bundle, : right? How would the individual licenses of the third party modules affect : me, if they happened to be packaged together with my code? : : Thanks for your response, : Scott : : : -- : 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: Viral licenses (was: wxWindows library...)
I just noticed that the Supreme Court denied cert in the case. : An interesting case to watch is Liu v. PriceWaterHouse, wherein you might : say the agreement at issue, if validly enforced, is viral as to the : third-party Chinese programmers in a similar way that the GPL might be. : : : See, e.g., the Liu v. PriceWaterHouse case on petition for certiorari to the : U.S. Supreme Court. Liu v. Price Waterhouse, 182 F. Supp.2d 666 (N.D. Ill. : 2001), 64 USPQ2d 1463 (CA 7 2002). : : Rod : : Rod Dixon : Open Source Software Law : Blog: http://opensource.cyberspaces.org : : : : amado.alves wrote: : : : : I sense there are two senses to this word viral. I'm really : : interested in this so I'll appreciate any input. One sense is the GPL : is : : viral because it spreads itself over derivatives i.e. forces : derivatives : : to be distributed under GPL (if distributed at all, that is : subsumed).* : : Is there another sense, perhaps more 'legal'? Thanks a lot. : : : : Ah but you see, the GPL does not FORCE itself. : : : : : : Sorry, I still think GPL forces itself upon distributed derivatives is : a : : true sentence. : : : : If you distribute a work that is a derivative of GPL-licensed : : code, and you do not comply with the GPL, you simply violate : : the license. The copyright holder can then demand a) that you : : comply with the license or b) that you stop distribution of : : his code. The GPL would be viral if you could not choose : : option b). : : : : For me it is. Other words are: infecting (as 'bad' as viral), : : absorbing (better), reciprocating (maybe the best). : : : : The problem with viral and infecting is that they have : : very strong negative connotations, and create an image that : : GPL-licensed code is just as bad as a virus that wipes your : : harddisk. It also creates the impression that any code on : : the same harddisk will somehow automatically become GPL- : : licensed. : : : : It is true that you have to be quite careful when importing : : GPL-licensed code in your project. But this is no different : : from other third party code; you have to study the license, : : figure out the implications and deal with them. If you take : : proprietary code from some vendor, you sometimes also get : : very problematic conditions imposed upon you. : : : : The main problem with the GPL is that it is not very clearly : : written (if you're a lawyer) and the copyright holder(s) are : : typically not available to answer detailed questions. Often : : it is practically impossible to track down all copyright holders : : to get clarification or an exception for your usage. : : : : Arnoud : : : : -- : : Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself : : Patents, copyright and IPR explained for techies: : http://www.iusmentis.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 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Simple OS license?
As you stated, this license was discussed by this list already, and those
comments are worth considering. You mentioned that you like the license
because it is short, but it is also incomplete. There may be a better
version floating somewhere on the web. I think a good idea may be that you
re-read the LGPL and give that license serious re-consideration.
Rod
Rod Dixon, J.D., LL.M.
Author: Open Source Software Law
Best points of contact:
Blog: http://opensource.cyberspaces.org
e-mail:[EMAIL PROTECTED]
voice:202-361-0797
fax:202-521-9317
website: http://cyberspaces.org/dixon/
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 4:33 PM
Subject: Re: Simple OS license?
:
: Hi
:
: I just saw in the archives that this license were discussed around
: 2003/07/01 under
: thread heading Microsoft's near-OSD-compliant shared source license
:
: My question is still. If there's a problem with clause 2, how can it be
: fixed, or what other license to use.
:
: Regards
:
: Jacobus Vosloo
:
:
:
: Hi
:
: Will the license listed below be compatible with opensource standards?
: It is a template as published by Microsoft on their workspaces website
: (http://www.gotdotnet.com/community/workspaces/)
: I am considering this license because:
: It is short.
: It allows commercial derivatives. ie. should be non viral, and
: compatible with most other OS licenses.
:
: NB. Will it be compatible with other licenses? Especially ones like GNU
: GPL?
: Example: Will a library written under this license be includable in
another
: os project?
: If it is not compatible. Please advice on a license that is similar to the
: LGPL, but with more allowance for commercial distribution.
:
: Thanks for comments.
:
: Jacobus Vosloo
: Application Integrator for .Net
: Invision - DaimlerChrysler - East-London - South Africa
: Email: [EMAIL PROTECTED]
: Tel: +27 43 706 2477
: Fax: +27 43 706 2612
: Cell: +27 83 361 3203
:
: Any views expressed in this message are those of the individual sender,
: except where stated otherwise.
: Emails can contain viruses; make sure your system is protected before
: opening any attached files.
:
:
=
:
:
: Shared Source License for [INSERT PROJECT NAME HERE]
:
: This license governs use of the accompanying software ('Software'), and
: your
: use of the Software constitutes acceptance of this license.
:
: You may use the Software for any commercial or noncommercial purpose,
: including distributing derivative works.
:
: In return, we simply require that you agree:
: 1. Not to remove any copyright or other notices from the Software.
: 2. That if you distribute the Software in source code form you do so only
:under this license (i.e. you must include a complete copy of this
: license
:with your distribution), and if you distribute the Software solely in
:object form you only do so under a license that complies with this
:license.
: 3. That the Software comes as is, with no warranties. None whatsoever..
:This means no express, implied or statutory warranty, including without
:limitation, warranties of merchantability or fitness for a particular
:purpose or any warranty of title or non-infringement. Also, you must
: pass
:this disclaimer on whenever you distribute the Software or derivative
:works.
: 4. That no contributor to the Software will be liable for any of those
: types
:of damages known as indirect, special, consequential, or incidental
:related to the Software or this license, to the maximum extent the law
:permits, no matter what legal theory it's based on. Also, you must pass
:this limitation of liability on whenever you distribute the Software or
:derivative works.
: 5. That if you sue anyone over patents that you think may apply to the
:Software for a person's use of the Software, your license to the
: Software
:ends automatically.
: 6. That the patent rights, if any, granted in this license only apply to
: the
:Software, not to any derivative works you make.
: 7. That the Software is subject to U.S. export jurisdiction at the time it
:is licensed to you, and it may be subject to additional export or
import
:laws in other places. You agree to comply with all such laws and
:regulations that may apply to the Software after delivery of the
: software
:to you.
: 8. That if you are an agency of the U.S. Government, (i) Software provided
:pursuant to a solicitation issued on or after December 1, 1995, is
:provided with the commercial license rights set forth in this license,
:and (ii) Software provided pursuant to a solicitation issued prior to
:December 1, 1995, is provided with Restricted Rights as set forth in
:FAR, 48 C.F.R. 52.227-14 (June 1987) or DFAR, 48 C.F.R. 252.227-7013
:(Oct 1988), as applicable.
: 9. That your rights
Re: Silly question: are usage restrictions covered by the OSD?
: On Wed, 15 Oct 2003, Arnoud Engelfriet wrote: : This may be a silly question as I'm probably overlooking something, : but as far as I can tell the Open Source Definition does not : forbid any general restrictions on usage of software. The closest : thing is No Discrimination Against Fields of Endeavor, but : that only forbids exclusion of _some types_ of usage, not exclusions : on usage by everyone. : : Would something like You may only use this editor if you release : all works you create with it as open source software fail under : OSD #6, and if not, why would it fail the OSD? : : I would argue that your clause (you may only use this editor if ...) : fails OSD #6, because it prohibits the field of endeavor creating : non-open source software. What makes compliance with some of the OSD articles sometimes difficult, I think, are instances where the issue is framed outside of the more restrictive bounds of copyright interests. OSD 6 is one example and, perhaps, that is why it may be a good idea to revise it as Larry is proposing. When it comes to copyright, I think the term use, which lacks precision, can create tricky problems. It is probably fine to use the word use, but it helps to keep in mind what use may mean. When I read use in a copyright license I assume the license authorizes or restricts others to do one of the following copyright interests: [1] To reproduce the work in copies, [2] To prepare derivative works, [3] To publicly distribute copies, [4] To perform the work publicly, [5] To publicly display the work or [6] (in the case of digital sound recordings, to perform the work publicly by means of a digital audio transmission). If a use does not fit within the aforementioned, it is likely to be outside of the scope of copyright (but not always), which creates difficulty and complexity for a copyright license in my opinion. On the other hand, if what is meant by use is within the scope of the aforementioned, then the license ought to use the specific terms rather than the generic word use. Regarding OSD 6 and the clause you may only use this editor if, the problem is one of draftmanship. This is why lawyers are paid well. The provision, as written, is inconsistent with OSD 6, but, if it or a similar license were re-written in terms of copyright...you are quite likely to accomplish your goal. BTW, I am not offering legal advice, nor am I specifically refering to the licensor's example. As the question below suggests, the GPL accomplishes a similar task (in terms of imposing a subtle field restriction), but it does so by reference to copyright interests. The GPL's language AND structure reinforce its meaning. I am not sure why some license drafters try to avoid the GPL when the GPL actually does what they want to accomplish, which is not to say that the GPL always is best. : The question that this does not address is how your restriction : differs from the restriction in the GPL, (you may only create a : derived work from this software if ...). That would also seem to : prohibit the same field of endevour. However, the chief distinction is : that concept of derived work. There is no field of endeavor of : creating derived works from software that you are not the author of : unless the author grants you that right. (This is one of the authors : reserved rights under most theories of IP.) That is, without : permission to create a derived work, one cannot create derived works : at all, and thus it cannot be a field of endeavor. : I think this is at least partially correct. The GPL uses the copyright holders right to control the creation of derived works as well as the right to control public distribution of works to accomplish a similar goal. -Rod Rod Dixon, Blog: http://opensource.cyberspaces.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD#5 needs a patch?
: Chuck Swiger [EMAIL PROTECTED] writes: : : By this you mean that you do not see any particular problem with : Sean's license being incompatible with the GPL by it's own terms, : and that you view his license as being OSD-compliant? : : Very few people thought that Sean's license was not OSD-compliant. I : can only recall one. I argued against the license, but I said right : from the start that I thought it was OSD-compliant. : : Much of the discussion was on the broader, and far more political, : issue of whether the OSI should approve it even assuming that it was : OSD-compliant. : : That is, is the OSI a neutral organization which just certifies that : licenses meet the OSD, or is it the advocacy organization described on : the opensource.org web page, one which is ``dedicated to managing and : promoting the Open Source Definition for the good of the community, : specifically through the OSI Certified Open Source Software : certification mark and program.'' : : Obviously there can be many disagreements over just what is ``the good : of the community,'' but it may be that even before those : disagreements, we need to settle the disagreement about what type of : organization the OSI is. : : Ian : -- This seems to me to be a good point. Unless I am missing something, I cannot glean from the opensource website any other standard used in the certification mark program other than OSD-compliance (posting on the list of approved licenses seems ostensibly automatic once the OSI board agrees on OSD-compliance). On the open source website it states that: Use of these marks for software that is not distributed under an OSI approved license is an infringement of OSI's certification marks and is against the law. Consequently, perhaps for ease-of-use of the certification mark and to avoid misuse of the mark, the determination whether a license is OSD-compliant is the only pertinent issue. -Rod -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD#5 needs a patch?
6. Open source licenses may not discriminate against persons or groups, fields of endeavor or types and brands of technology. Proponents of open source software insist that software not be a battleground on which political or philosophical or business wars are waged. In many jurisdictions around the world, discrimination on the basis of race, age, religion, national origin, sex, sexual orientation, health status, and other personal characteristics is always illegal. This open source principle is intended to extend that broad list, not to replace it. To be consistent with this open source principle, all terms and conditions of the license must demonstrably encourage rather than discourage software freedom for all licensees. _ The sentence: This open source principle is intended to extend that broad list, not to replace it. raises exactly the issue it seems aimed at resolving; namely, whether the OSD should be a vehicle for expanding anti-discrimination law protections as an affirmative standard for approval of open source licensing. My thoughts on this are twofold: [1] that OSD 5 or the proposed OSD 6 should be explicitly limited to matters that generally are NOT already covered by laws; in other words, the OSD should restrict the term discrimination to apply to matters that are important to the goals of the open source community (see below), and [2] when it comes to matters of invidious discrimination the legal instrument (the license) as well as how the license is used might be pertinent to any meaningful enforcement of compliance with OSD 6. In this regard, it might be more effective to have license submitters attest to compliance with a notice statement rather than put OSI in the position of withholding approval on the basis of a textual conclusion about invidious discrimination. Regarding my first thought, if we accept the argument that the OSD should *generally* reflect the values of freedom of contract, and only set guidelines directly relevant to open source licensing, then the OSD's anti-discrimination clause should be restricted to very specific inherently connected matters rather than broadly read to encompass the broad list in OSD 6. What might that be? Well, for example, regarding the issue of encouraging governments to use open source software, OSD 5 or the proposed OSD 6 could clarify that licenses that contain terms which discriminate against (by prohibiting use of) free software governed by the GPL in E-government would not be in compliance with the OSD. Other examples might be licenses that discriminated against Linux users or the use of software for biometric research, unless expressly prohibited by law. My thoughts on this follow my belief that as a practical matter, the opprobrium that would attach to any license circulating in the open source community that discriminates on the basis of the factors listed in the proposed OSD 6 is likely to achieve the goal of OSD 6 without putting OSI in the position of actually having to affirmatively police a potentially cumbersome and difficult process. -Rod Rod Dixon, J.D., LL.M. http://www.cyberspaces.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD#5 needs a patch?
: On Tue, Oct 07, 2003 at 12:18:58AM -0300, Bruce Dodson wrote: : OSD#5 The license must not discriminate against any person : or group of persons. : : Does that need to be expanded to state explicitly that this : does not just apply to the license terms? i.e. Should it : say in addition that the license text itself must not : contain any discriminatory or derogatory statements against : any person or group? : : Example: Take the BSD license and add to it the following: : : ethnic group ARE PROBABLY NOT SMART ENOUGH OR SOBER ENOUGH : TO USE THIS SOFTWARE, BUT THEY ARE PERMITTED TO TRY, JUST : LIKE EVERYONE ELSE. AFTER ALL, WE WOULD NOT WANT TO : DISCRIMINATE. : : : (This comes to mind upon thinking about the DISCUSSION : section included in the proposed OSSAL license.) : : Has this come up yet? Wouldn't any license that otherwise complied with : the defintion by defintion allow such a statement to be removed from the : license file by the user if it offended them? I don't see how anyone : could imply that a statement like that is a license clause. : : 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. : : The problem with changes like what you're suggesting is they turn the : OSD into a moral position. My understanding is that the OSI was created : to avoid the moral imperative slant of the free software camp while : promoting the practical benefits open source software. The OSD serves : to lay out the properties of a license that gets the practical benefits. : : The non-discrimination clauses exist because a discriminatory license : eliminates one of the benefits of open source software. However, a : discriminatory or derogatory statement which has no effect on a groups : ability to use a piece of software per the current OSD would not alter : those benefits. : : That's not to say that such speach as you suggest is desireable. It's : just that it would be entering into a moral stance as opposed to a : practical and cost/benefit stance. : I will stop lurking for just a split second to say that I agree that the OSD is not a moral code. For the most part, a license speaks for itself. A licensor who drafts a license containing offensive language does so at his/her own peril. Obviously, some offensive language may run afoul a law. For example, license text that offends an individual in a manner that is defamatory might run afould libel law. Depending upon who the licensor is, there may be a number of other legal considerations. Apart from those issues, I see no reason why OSI would need to post a license on its website, if the board decided the terms offended the organization's mission and this type of discretion was not exercised often or arbitrarily, despite the license' compliance with the OSD. Rod Rod Dixon Cyberspaces.org [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Updated license - please comment
It has come to my attention off-list that I may need to clarify my comment on the proposed RSPL. I made 3 observations; namely, that since [1] section 2a of the proposed license is identical to section 2a of the GNU LGPL; [2] the proposed license has a similar purpose as the GNU LGPL (according the license poster); and [3] the GNU LGPL is an approved OSI License; that it is my judgment that there is no OSD-related problem with sections 2a or 2d of the RSPL, which I, like Mark, had initially questioned. I am still unsure why the GNU LGPL does not serve the poster's purpose...particularly since the original section 2d of the RSPL has been removed from the proposed license. Rod [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Updated license - please comment
I think there are two issues here: [1] the section 2a requirement that limits the rights granted to the public distribution of libraries and [2] the licensor's intent to permit dynamic linking of the open source library with non-free software. If this is correct, then section 3 of the LGPL, which seems to allow an irreversible switch to the GPL, is not pertinent to the licensor's need. Rod On Thu, 19 Jun 2003, Mark Rafn wrote: On Wed, 18 Jun 2003, Rod Dixon, J.D., LL.M. wrote: : Am I the only one who thinks 2a and 2d are unacceptible? It violates : OSD#3 by limiting the type of derived work, I think you have to evaluate the license in the context of what the author has told us about his purpose. I at least partially disagree. Open source licenses should be considered by OSI in the context of open source software. The GNU LGPL, for example, makes more sense when you consider its purpose. The LGPL made sense to me when I read LGPL section 3. Without that, I very much hope it wouldn't be considered open source. We are told that RSPL is intended to be used for libraries, which is similar to one the principle purposes of the GNU LGPL. The GNU LGPL is an OSD compliant and OSI-approved open source license. I have zero objection to RPI using the LGPL. In fact I heartily recommend it, and I believe it meets their needs at this point if they simply add an extra-license note that work submitted to RPI becomes the property of RPI. Section 2a, of the RSPL, which states that The modified work must itself be a software library is identical to the GNU LGPL. Hence, no problem there. This requirement is problem in the LGPL, and a big problem in the RPSL. It is no problem in the LGPL because LGPL section 3 makes it an optional requirement. In the RPSL, it's an absolute requirement. You cannot take restrictive bits of an open-source license, remove the permissive bits, and expect the result to be considered open-source. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- 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: Updated license - please comment
This version seems fine, given what we were told about the license last time. I read this license to have the same or similar purpose as the LGPL, and in that respect section 2(a) seems permissible. It is a slight restriction that could have a strategic purpose, but the author says the limitation is consistent with the LGPL and that sounds fine. It might be more acceptable if the provision did not impose a mandatory requirement, but, instead, used a permissive condition. Still, I do not see the issue as an OSD matter. - Rod On Wed, 18 Jun 2003, Christophe Dupre wrote: Following all the comments received from this list about a week ago, we've slightly modified the license. It now stands as follows. Cluase #2 was changed, and doesn't ask for automatic co-ownership of changes, but only those submitted for inclusion in central repository. Would this be more palatable to this group ? Is there any additional objection ? Thanks again for all the feedback. RENSSELAER SCOREC PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder saying it may be distributed under the terms of this Rensselaer Public License (also called this License). Each licensee is addressed as you. A library means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The Library, below, refers to any such software library or work which has been distributed under these terms. A work based on the Library means either the Library or any derivative work under copyright law. Source code for a work means the preferred form of the work for making modifications to it including any associated interface definition files, and scripts used to control compilation and installation of the library. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty 2. You may modify your copy of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. At your discretion, you may submit the differences between the Library and your work based on the Library for inclusion in the source code repository maintained by Rensselaer Polytechnic Institute. The mechanics of the submission are explained in the file named README distributed with the Library. Should you decide to submit the changes, you agree to provide Rensselaer Polytechnic Institute with a joint copyright ownership of the changes, and you agree to sign such a copyright assignment form at the request of Rensselaer Polytechnic Institute. 3. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three tears, to give any third party, at no charge, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of executable or object code is made made by offering access to copy from a designated place, then offering equivalent access
Re: Updated license - please comment
: : Am I the only one who thinks 2a and 2d are unacceptible? It violates : OSD#3 by limiting the type of derived work, I think you have to evaluate the license in the context of what the author has told us about his purpose. The GNU LGPL, for example, makes more sense when you consider its purpose. We are told that RSPL is intended to be used for libraries, which is similar to one the principle purposes of the GNU LGPL. The GNU LGPL is an OSD compliant and OSI-approved open source license. Section 2a, of the RSPL, which states that The modified work must itself be a software library is identical to the GNU LGPL. Hence, no problem there. The revised Section 2d of the RSPL appears to be the old section 2e, and replaces the troubling joint ownership provision. As it is written, section 2d now follows the language in what might be an identical provision in the GNU LGPL. Consequently, I do not see a problem here. Rod perhaps OSD#6 by limiting : itself to creators of software libraries, and perhaps OSD#8 by being : specific to the product software library. As far as I can tell, it : prevents anyone from distributing an application that statically links the : library into it (if such an application is a derived work of the library, : at least). : : It doesn't even seem close to me. Let me know if I'm insane, or reading : it wrong, but I can't see how such a restriction can be considered open : source. : : I know they're straight from the LGPL, but they are irrelevant there : because the LGPL is a pure superset of the GPL (see LGPL section 3), : unlike the license under discussion. : : Yes, this indicates that I think the LGPL without section 3 would : be non-open-source. : -- : Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ : -- : 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: New license - please comment
I am having some of the same difficulties as others with this draft. Section 2 has a couple of provisions that appear to be troubling because they seem highly restrictive, and it is not apparent why. If you could post something about what you are trying to accomplish, it might help. Your first post began by acknowledging that the existing approved open source licenses did not fit your needs, which is fine, but you did not state what that need was. Telling us more is helpful for a number of reasons, including highlighting why you borrowed provisions from the LGPL, instead of selecting that license for your own. Section 2(a) in the LGPL is tied to the peculiar purpose of the LGPL. Take a look at the preamble again to consider whether your project meets the same purpose (i.e. We use this license for certain libraries in order to permit linking those libraries into non-free programs.)- - if that's your purpose, then I would find your use of that provision consistent with the OSD. Section 2(d) is probably unnecessary (assuming it's enforceable) since you could simply require licensees to agree to a cross-license (a nonexclusive reproduction or distribution license), rather than demand an ownership interest in copyright (which I doubt many would be willing to grant you). Rod Rod Dixon, J.D., LL.M. http://www.cyberspaces.org/webzine/ [EMAIL PROTECTED] - Original Message - From: Christophe Dupre [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 9:16 PM Subject: New license - please comment : Hello, : my employer is considering releasing some components as open source. : We have looked at various licenses, but none seems to do exactly as we : need, so we have made this one. : : We would appreciate comments, especially with regards to OSI certification. : : : : RENSSELAER SCOREC PUBLIC LICENSE : TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION : : 0. This License Agreement applies to any software library or other : program which contains a notice placed by the copyright holder saying it : may be distributed under the terms of this Rensselaer Public : License (also called this License). Each licensee is addressed as you. : : A library means a collection of software functions and/or data : prepared so as to be conveniently linked with application programs : (which use some of those functions and data) to form executables. : : The Library, below, refers to any such software library or work which : has been distributed under these terms. A work based on the Library : means either the Library or any derivative work under copyright law. : : Source code for a work means the preferred form of the work for making : modifications to it including any associated interface definition files, : and scripts used to control compilation and installation of the library. : : 1. You may copy and distribute verbatim copies of the Library's complete : source code as you receive : it, in any medium, provided that you conspicuously and appropriately : publish on each copy an : appropriate copyright notice and disclaimer of warranty : : 2. You may modify your copy of the Library or any portion of it, thus : forming a work based on the : Library, and copy and distribute such modifications or work under the : terms of Section 1 above, provided : that you also meet all of these conditions: : a) The modified work must itself be a software library. : b) You must cause the files modified to carry prominent notices : stating that you changed the files and the date of any change. : c) You must cause the whole of the work to be licensed at no : charge to all third parties under the terms of this License. : d) You must provide Rensselaer Polytechnic Institute with a : joint copyright ownership. This does not need to be done : explicitely, redistribution of work based on the Library implies : your acceptance of joint ownership of the work based on the : Library. : e) If a facility in the modified Library refers to a function or : a table of data to be supplied by an application program that : uses the facility, other than as an argument passed when the : facility is invoked, then you must make a good faith effort to : ensure that, in the event an application does not supply such : function or table, the facility still operates, and performs : whatever part of its purpose remains meaningful. : These requirements apply to the modified work as a whole. If : identifiable sections of that work are not : derived from the Library, and can be reasonably considered independent : and separate works in themselves, then this License, and its terms, do : not apply to those sections when you distribute them as separate works. : : 3. You may copy and distribute the Library (or a portion or derivative : of it, under Section 2) in object code or executable form under the : terms of Sections 1 and 2 above provided that you also do one of the : following: : (a) Accompany it with the complete corresponding machine
Re: Please add Public Domain to license list
I, too, favor a more robust public domain for software than most acknowledge exists today. Unfortunately, this topic is infused with unclear distinctions, but what is apparent is a difference between what is real and what is ideal. David's position seems to border on idealistic expectations. If one can find truly public domain source code, by all means the finder should use it; nothing from OSI would be required. By definition, public domain source code is not protected by copyright, but open source software is, at least, subject to copyright protection; this distinction is rather significant. We should not equivocate about the distinctions between software controlled by an open source software license and source code found in the public domain. Rod [EMAIL PROTECTED] : Quoting David A. Wheeler ([EMAIL PROTECTED]): : : Actually, I've looked over some of the OSI-approved licenses. : I'm still not convinced that there's ever a good reason for : authors of software to use some of those approved licenses either :-). : : The OSI doesn't advocate particular licences: It approves _only_ their : claim to OSD-compliance. : : I wasn't aware that the OSI ever requires that all OSI : members like the side-effects of the release conditions - as : long as they meet the spirit letter of the OSD, they : should be approved. : : Your rhetoric is overreaching, again: OSI doesn't require anything, : other than that people wanting to use its certification mark meet : specified requirements, including usage of an approved licence. : : I'm not asking the OSI to RECOMMEND releasing software as public : domain, or to use public domain software. Just a clarification : that public domain source code (if truly public domain) : is open source software. : : Feel free to write such a clarification that's markedly less problematic : than the one you attempted before, then -- and don't forget to suggest : somewhere appropriate to post it. (The page of approved licences, which : you have urged, is an obvious non-starter.) : : -- : Cheers, Teach a man to make fire, and he will be warm : Rick Moen for a day. Set a man on fire, and he will be warm : [EMAIL PROTECTED] for the rest of his life. -- John A. Hrastar : -- : 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: Please add Public Domain to license list
[snip] : Don't let any of our criticisms on this topic lead you to believe that : none of us want OSI recognition of Public Domain software as Open : Source Software. That is not the case. There are of course some who do : feel that way, but many others including myself think it would be a : useful thing. This is the only point in David Johnson's post that surprised me, and I hope it is apparent that I am making a minor distinction. Certainly, without equivocating about the distinctions you acknowledge exist between open source and public domain software, an open source adherent is still free to act on principle by drafting a license that accomplishes the same goal. Correct? Leaving aside the questions regarding the legal viability of a public dedication of software, I think it is rather trivial for a specific programmer to *license* his/her software under terms that achieve the same ends as a push into the public domain (and, perhaps, the use of a programming language like Perl...or one that rendered reverse engineering trivial, if source code were not easily accessible to the end-user). David Johnson's points below show that the issue is different for OSI as a movement with multiple goals and viable business models in mind. Rod : : But you have to realize that there are many problems that would come : along with this recognition. The first problem is that of domains. : Public Domain is in a completely different domain that why OSI is : trying to define. PD has no copyright, while the OSI is trying to : define a classification of software that has copyrights. It's like : complaining that the Atlantic Salmon isn't listed in the Big British : Book of Birds. If you feel that the purpose of bird books is to list : all animals, then of course your complaint would be valid, but that is : not the purpose of bird books. : : The second problem is much more serious. How do you *know* that a piece : of software is in the public domain? You can know that Apache is Open : Source because it has the necessary attributes of a copyright and : license that can be used to verify its status. But it's very hard to : tell if a particular work which claims to be public domain really is. : This is because merely stating that you are placing your work into the : public domain is insufficient. Most works that claim to be public : domain are in fact not. A recognition of Public Domain by the OSI could : lead a lot of people into legal quagmires. : : So here's a question to you. What is your pressing need for such a : recognition? What problem is the lack of such recognition causing? : : -- : David Johnson : ___ : http://www.usermode.org : -- : 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: What about LGPL? Re: Compatibility of the AFL with the GPL
I realize that this question was specifically addressed to Larry and RMS, but please permit me to press my point once more since I am beginning to recognize that despite the reputation of lawyers for over-complicating matters, computer scientists seem to suffer from the same affliction. The final question the poster posed about his project is entirely unrelated to the initial quoted concern whether the AFL is incompatible with the GPL? It might be easier to address these matters if the dynamic/static linking questions and the LGPL are left independent from the generalized concern about the AFL and GPL. Most importantly, in my opinion, the resolution of what it means to say that one license is incompatible with another should not be construed as resolving any specific legal question about a particular project. You are quite likely to make wrong conclusions by performing that type of mental gymnastics, if you are not a lawyer. For example, although Andrew limited his question to a matter of interpreting a couple of software licenses, the fact is his question implicitly requires an application of copyright law as well; hence, any posted answer merely addressing the LGPL is incomplete and one would be foolish to follow. I provide this precaution in order to constructively pose how one should read our discussions, which tend toward both over-complicated queries and oversimiplied answers, but not necessarily in that order. -Rod On Fri, 14 Mar 2003, Andrew C. Oliver wrote: Lawrence E. Rosen wrote: Richard, Today you finally gave public reasons for your assertion that the AFL is incompatible with the GPL. Because you are simply wrong on the law and wrong-headed on a matter of principle, I must file this public response. So I think I understand the controvery regarding GPL and why GPL and ASL (aka AFL) don't work together. What about LGPL and ASL in the situation of Java? Apache has a long standing ban on LGPL being used in Java projects and I want to know if its justified. I asked if Eben Moglen's comments in slashdot on the subject were sufficient to lift the ban and Roy Fielding responded: No. What the FSF needs to say is that inclusion of the external interface names (methods, filenames, imports, etc.) defined by an LGPL jar file, so that a non-LGPL jar can make calls to the LGPL jar's implementation, does not cause the including work to be derived from the LGPL work even though java uses late-binding by name (requiring that names be copied into the derived executable), and thus does not (in and of itself) cause the package as a whole to be restricted to distribution as (L)GPL or as open source per section 6 of the LGPL. Most authors of Java software using the LGPL license intend to allow linking (basically the use of the java import of classes in their jar file). Who is right? Apache with their insistance that the LGPL is viral for Java software or the masses who think LGPLing their code causes modifiers to contribute but linking/use to be uninhibited even to proprietary software? (where the term link is not wholely appropriate for Java, I interperate it to mean including a jar in the classpath at compile-time and runtime and having import statement naming classes inside of a jar) On a personal note, clearing this up would help me greatly as I would like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache project I founded (http://jakarta.apache.org/poi) instead of our own collection classes. Secondly, I am considering releasing an upcoming Java codebase in LGPL or GPL, and while I understand the full ramifications of GPL, I do not feel I fully understand the ramifications of LGPL with regards to this issue. I would greatly appreciate if Mr. Stallman and Mr. Rosen could provide a definitive answer on this. Thank you, Andrew C. Oliver -- 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: Please add Public Domain to license list
The public domain is NOT viewed as synonymous with software licensed under an open source license. Rod On Fri, 14 Mar 2003, David A. Wheeler wrote: Hello - I'd like to ask OSI to add Public Domain to the open source software license list at: http://www.opensource.org/licenses/index.php I have several reasons for this request. First, it clarifies the status of public domain software. Some people do not realize that source code in the public domain is open source software. I've been having discussions with a lawyer specifically on that point - the lawyer doesn't think public domain software is open source software. If I could point to the OSI and say look! there it is!, it'd be much clearer. Second, a license text would help people who intend to make their source code public domain. Some programmers don't realize that copyright is now automatic, and that they HAVE to EXPLICITLY give it into the public domain for it to be public domain. And even if they know that, they may not know the right legal incantations to do so. Some suggested language would go a long way. Third, you could make it clear that the SOURCE CODE has to be in the public domain for this to work. Declaring that an object code is in the public domain isn't enough. Yes, strictly speaking public domain isn't a license. But it has all the workings of one, so for consistency's sake I think you can treat it as a license and all works out. Version 1.4 of the open source definition made this clear; its section 10 states that certification marks could be shown for for source code explicitly placed in the public domain. However, when section 10 was removed, this clarity was removed as well. The OSI has always had the position that public domain software is open source software. I just ask that the OSI clearly state this in their current text. Thank you very much. -- 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: Compatibility of the AFL with the GPL
My answer (or rather my question) is does Larry have an alter ego known as Joe Hacker who wants to get back at people on this list making the use of his license so complicated? ;-) More seriously, I think the hypo adds to rather than substracts from the confusion on this topic. The initial question concerned compatibility of the AFL with the GPL. In that respect, it is worth keeping in mind that compatibility is not a term of legal significance in software licensing matters. As I under the term, Stallman uses it to evaluate license provisions and how he thinks they may impact the GPL. I do not find difficulty in acknowledging that FSF is the arbiter of what they deem is compatible or not; this is particularly so in an environment like a list discussion since FSF would be expected to provide some rational basis for its determinations on compatibility - - to the extent the determinations are not considered rational, no one or few will care that the determinations exist. With regard to the AFL and GPL in Larry's hypo, I think Stallman has indicated ostensibly that since the AFL restricts BigLo's choice to identify or market its software product as Whizbanger Deluxe, (without permission...yadda, yadda, yadda) the AFL imposes a restriction that exceeds those imposed by the GPL. If this makes the AFL incompatible with the GPL, I do not think we can argue away the point. I think the point the FSF may be making is that they have a fairly high threshold for compatibility with the GPL, and that may be intended to exert some control over how these licenses interact in complex transactions. I think the hypo makes the point (inadvertently or otherwise) that compatibility with the GPL is not an issue concerning who might get sued for what. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Brian Behlendorf' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Eben Moglen' [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 11:46 PM Subject: RE: Compatibility of the AFL with the GPL : OK, guys, play with me one more round. This time, let's do it in the : form of a law school exam question and let's get the lawyers and IANALs : on this list to chime in: : : SCENARIO: Several faculty members at Prestigious University have created : a marvelous new package that takes input from a keyboard and displays it : on a monitor faster than any program ever has before. They decide to : release it to the public under the name WhizBanger. The P.U. general : counsel tells them to license it using the AFL. He registers, on behalf : of the University, the trademark WhizBanger for computer software that : reads from a keyboard and displays on a monitor. : : Linus Torvalds learns about WhizBanger and he and his team decide to : include WhizBanger in their new release of Linux. As usual, they : release their new Linux, with full source code, under the GPL. The : Debian project thinks the new release of Linux is wonderful. They : include the modified Linux in their new distribution, also under the : GPL. : : Brian Behlendorf learns about WhizBanger and he convinces the Apache : team to include WhizBanger in their new release of Apache. As usual, : they release with full source code under the Apache license. : : BigCo brings Debian Linux into its research labs. Its engineers, : thrilled to finally be using free software, incorporate Linux into a : computer product they call WhizBanger Deluxe. They claim in their : advertisements that this product is so wonderful that Linus Torvalds : uses it and he recommends it to his friends. WhizBanger Deluxe is : sold worldwide. There's an entry-level version that is released under : the GPL, and a full-function version that is released under a : proprietary license. : : MediumCo also brings Debian Linux and Apache into the company, using : those programs to do payroll and accounts payable functions. At a : review meeting with his patent attorney, the CEO of MediumCo discovers : that his company has a U.S. patent for a computer system that accepts : input from a keyboard and displays it on a screen. Dreaming of vast : royalties, he tells his attorneys to file a lawsuit against Prestigious : University for patent infringement by WhizBanger software. : : Meanwhile, Sally Developer, who respects and admires the Free Software : Foundation and has sworn to uphold the principles espoused by Richard : Stallman, discovers that Linus Torvalds included an AFL-licensed program : in Linux. She's pissed. She's so angry she's considering revoking her : license for a printer driver that's been a part of Linux since version : 1. : : Joe Hacker, a high school student, downloads copies
Re: A BSD-like license that isn't template-based
If RMS responds, would you post his response to the list? I have been curious about FSF's classification of the AFL as incompatible with the GPL. thanks, Rod - Original Message - From: John Cowan [EMAIL PROTECTED] To: Dave H [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 5:13 PM Subject: Re: A BSD-like license that isn't template-based : Dave H scripsit: : : I was wondering if there are any BSD-style licenses which are /not/ : template-based. The closest I've seen is Larry Rosen's Academic Free : License; however the Mutual Termination for Patent Action clause, : whilst laudable, gives it more teeth than the BSD license; also, : perhaps because of this clause, the FSF list it as being : GPL-incompatible. : : It seems that RMS believes it's the trademark exemption that makes the : AFL incompatible with the GPL. Steps are underway to better inform him. : : -- : There are three kinds of people in the world: John Cowan : those who can count, http://www.reutershealth.com : and those who can't.[EMAIL PROTECTED] : -- : 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: Antiwar License
If we think of OSD 5 as intending to prevent the restriction of choices or prevent the proliferation of licenses that lock out certain groups from participating in open source projects, doing so might decrease the likelihood that we will over-read the OSD, and apply it in a manner that seems ill-suited to open source. Hence, I doubt that military techs are going to be allowed to contribute to live open source projects...perhaps, necessarily so. In that light, however, one should be able to restrict (but not prohibit) certain uses of software in devices used to [?] as part of an open source software dual licensing approach to government uses. Rod - Original Message - From: Rick Moen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 02, 2003 9:29 PM Subject: Re: Antiwar License : Quoting Sergey Goldgaber ([EMAIL PROTECTED]): : : Along similar lines, wouldn't it be possible to create a license : prohibiting the use of one's software by the military, the Defense : Department, and military contractors? : : If your question is whether it's possible to write an OSI-approved : licence of that sort (and thus to qualify covered software for the OSI : Certified certification mark), I would say it isn't, as that would : clearly violate OSD provision 5 (No Discrimination Against Persons or : Groups) and provision 6 (No Discrimination Against Fields of Endeavor). : : If you're asking whether it's possible to write a licence that's not : OSD-compliant (i.e., _not_ open source), then I have no comment. : : -- : Cheers,There are only 10 types of people in this world -- : Rick Moen those who understand binary arithmetic and those who don't. : [EMAIL PROTECTED] : -- : 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: No Warranty License.
Actually, I think you are mistaken. The emphasis on the term discrimination in the OSD derives from concepts of freedom and opennness. For example, Microsoft has advocated that governments NOT use open source software in E-government projects. There is nothing unlawful about the discrimination against open source that arises from Microsoft's position. Similarly, the OSD's use of the term is not about what might be customarily viewed as unlawful discrimination, but about limiting choices in the manner that an E-government project would be subject to, if they adopted Microsoft's position. BTW, I use Microsoft only by way of example. Rod On Fri, 28 Feb 2003, Don Jarrell wrote: I believe Nathan has hit upon a problem not in Open Source but in our language and society as we have accepted distortion of the word discrimination. Purely it only means 'to distinguish or delineate' (IANW), but we tend to load the connotation with 'unreasonably' or 'illegally'. In looking at this discussion, I believe we are vacillating in the back of our minds between the denotation and connotation, as is done in other contexts. I believe there is nothing wrong in saying that a license (or even the OSD) 'Discriminates' conditions and situations - as it must to accomplish some effect. Whether that discrimination is unreasonable or driven by an illicit motive is a separate question. Cheers. dj * Don B Jarrell [EMAIL PROTECTED] 512 266 7126 home-office Digital Thinking Inc. 972 467 6793 cell * -Original Message- From: Nathan Kelley [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 4:53 AM To: Justin Chen-Wells; Rod Dixon J.D. LL.M. Cc: OSI License Discussion Subject: Re: discuss: No Warranty License. To Justin Chen-Wells, Rod Dixon J.D. LL.M. and OSI License Discussion subscribers, From: Justin Chen-Wells [EMAIL PROTECTED], From: Nathan Kelley [EMAIL PROTECTED], From: Justin Chen-Wells [EMAIL PROTECTED], From: Rod Dixon J.D. LL.M. [EMAIL PROTECTED], On the other hand supposing some government passes a law: No citizen shall accept a software license which requires publishing the source code of a derivative work. Would we then declare that the GPL is not OSD because it discriminates against people in that legislative jurisdiction? No, we wouldn't. But there is a difference between your scenario and that of the No Warranty License: your scenario says the user can't accept the license because their jurisdiction say they can't, whereas the No Warranty License says the user CAN accept the license, but they don't get any of the OSD-guaranteed rights if their jurisdiction doesn't allow limited liability. So, let's take one more step along this slippery slope: What about a license which says: You must read and understand this license before accepting it. Discrimination against the illiterate, the blind, the mentally challenged, and, for that matter, anyone who can't read English? That only holds if that statement is (a) completely inflexible, and (b) you interpret it literally instead of on the basis of its intent. On that basis, none of those groups would be legally able to do things like buy houses, gain employment, open bank accounts, obtain passports, or other such activities... but we know that they do every day. If we really wanted to, we could probably find discrimination in every sentence of every open-source license on file. But what's the point? We're interested in the source code being open, and attempting to compensate for every possible discrimination would get in the way of that. That's a truism universally, not just for open source. Those that are blind aren't allowed to drive; that's discriminatory, but which do you value more: no discrimination, or safe roads? To have both would be nice, and with technological and medical improvements, we might be able to have both, but that's in the future. For now, you need to choose. Those in the proprietary software business aren't allowed to re-use code from any software licensed under any OSD-compliant license in their proprietary products without conforming to the conditions of the license, making their product nonproprietary; that's discriminatory, but which do you value more: no discrimination, or open-source software? To have both would be nice, but until the way the world works changes, we're stuck with that choice. Perhaps it's unfair. But life's unfair. What we can do is make it less unfair without compromising ourselves or our goals. Accepting or rejecting licenses based on whether they match the spirit of the OSD as well
Re: discuss: EPD CORE OPEN SOURCE LICENSE - Version 0.1
Bill, My overall impression of this version of your license is that it contains unnecessary provisions, which you could delete given your stated purpose for the license, but before addressing that I think paragraph 3 needs a little work to fully establish that the license is an open source license. Let's start with OSD #2. It's not clear that paragraph 3 complies. Did you intend to say something about source code in the license grant clause? 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost-preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. -Rod - Original Message - From: Bill Moran [EMAIL PROTECTED] To: John Cowan [EMAIL PROTECTED] Cc: David Johnson [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 24, 2003 11:35 AM Subject: Re: discuss: EPD CORE OPEN SOURCE LICENSE - Version 0.1 : Thanks to everyone who has contributed suggestions so far. : : After further review, we're still not completely happy with the QPL and : wish to continue revision and discussion on the EPD Core license. : : I am posting a V.2 of this license, which has incorporated many of the : changes suggested earlier in this thread. Thanks to the suggestions from : the list, we are much happier with this version than the first version : and would like to continue discussion. : : -- : Bill Moran : Potential Technologies : http://www.potentialtech.com : : -- : : EPD CORE OPEN SOURCE LICENSE - Version 0.2 : : This EPD Core Open Source License (the License) applies to the EPD : Core software product (the software). : : This License identifies the terms under which you may use, copy, : distribute or modify Licensed Product. : : The overall purpose of this license is to make the software as useful : to the user community as possible, while still allowing a viable : business to result from its development and distribution. : : The terms of this License are: : : 1. Nothing in this license shall be interpreted to mean that any module : designed to work with or distributed with the software must be : distributed under this license. In no way shall anything in this : license be interpreted to limit the licenses under which modules : designed for the software may be published. In no way shall any : module's licensing terms or interaction with any other module or the : software be interpreted to alter or negate the terms of this license : or the license terms of any other module. : : 2. You are granted the non-exclusive rights set forth in this license : provided you agree to and comply with any and all conditions in this : license. Whole or partial distribution of the software signifies : acceptance of this license. : : 3. You may use or give away unmodified copies of the software, alone or : as a component of an aggregate software distribution containing : programs from several different sources. No royalty or other fee is : required. You may bnot/b charge any fee for the software. You may : charge a reasonable fee for producing and delivering media containing : the software. You may also charge a fee or license other softwares : provided on the same media, as long as it is made clear that the : software portion of the distribution covered by this license is : provided free of charge. : : 4. All distributions of the software must reproduce this License and : disclaimer in its entirety. : : 5. All distributions of this software must make available the entire : collection of files as officially distributed by the copyright owner, : including all documentation. : : 6. You may not, in any way, misrepresent this software as being part of : any aggregate product, or misrepresent the original developer and : copyright holder of the software. : : 7. You may use the software for any legal purpose. : : 8. Output generated by the software and information stored and organized : by the software is not covered by this License, nor is it the property : of the Copyright holders. : : 9. You may charge any fee you find reasonable to support this product. : : 10. You may modify the software in any manner that you see fit, and you : may charge a fee to do so with no royalties due to the Copyright : holder as long as the modifications abide by at least one of the : following conditions: : 1. The modifications are not distributed and are solely for your use, : or the use of your direct employer who authorized you to make
Re: discuss: No Warranty License.
One way around this apparent conundrum is adopt the suggestion in OSD. Point out the restriction that may exist, but do not actually incorporate the tersm of the restriction in your license. 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process. Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself. Rod [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Justin Chen-Wells [EMAIL PROTECTED] To: Nathan Kelley [EMAIL PROTECTED] Cc: OSI License Discussion [EMAIL PROTECTED] Sent: Thursday, February 27, 2003 8:53 AM Subject: Re: discuss: No Warranty License. : : You have to be careful with this: : : o Open source developers ought to be able to limit their : liability, otherwise many firms and individuals may be : unwilling or unable to contribute code : : o You risk binding the OSD to the union of the laws of every : jurisdiction on earth, no matter how crazy the laws may be : : The second point requires explanation. You have said that this No : Warranty License fails to comply because it discriminates against : people in a particular jurisdiction. Your reasoning was that the : laws of that region are beyond the control of its inhabitants : (questionable) and therefore preventing use of the software under : a particular legislative regime amounts to discrimination against : a group. : : There's some merit in that, as for example we wouldn't want to : accept a license which said the software could not be used, or : could only be used, in a democracy. : : On the other hand supposing some government passes a law: : : No citizen shall accept a software license which requires : publishing the source code of a derivative work. : : Would we then declare that the GPL is not OSD because it discriminates : against people in that legislative jurisdiction? : : In and of itself I don't think we want to reject a license merely : because of an incompatibility between a license and a law that : results in the inability of people subject to that law to accept : that license. : : Justin : : : On Thu, Feb 27, 2003 at 11:12:32PM +1100, Nathan Kelley wrote: : To OSI License Discussion subscribers, : : From: Anonymous Poster, : From: David Johnson [EMAIL PROTECTED], : : I have concluded that the No Warranty License does not conform to the : Open Source Definition. The offending clause is as follows: : : If the following disclaimer of warranty and liability is not valid due : to the laws in a jurisdiction then NO RIGHTS ARE GRANTED in that : jurisdiction without the express written permission of the copyright : holder. : : This violates Item 5 of the OSD, which states that The license must : not discriminate against any person or group of persons.. By not : granting equal rights to users, distributors and open-source developers : based on factors beyond their clear control (the laws of their : jurisdiction), they are being discriminated against. : : This also violates Item 7 of the OSD, which states that The rights : attached to the program must apply to all to whom the program is : redistributed without the need for execution of an additional license : by those parties.. Users, distributors and open-source developers in : affected jurisdictions cannot exercise the rights they are guaranteed : under the OSD for OSD-compliant licenses without obtaining additional : permission (license) from the author. : : Further, the only way to effectively enforce this license is to prevent : users in the affected jurisdictions from obtaining or using the : software, since as I understand it (IANAL, TINLA, CMIW), the wording of : a license cannot override the laws of a jurisdiction, nor physically : prevent someone from filing a suit on those laws; it might put you in a : more favorable position (that, if assent could be proven, the user : assented to the terms and has now violated that; what legal : significance this would have is questionable), but that's all. : : Since the offending clause forms the only tangible difference between : the No Warranty License and the BSD License, I recommend that the No : Warranty License be rejected. : : Basically, I want a BSD license but I don't want some chuckle-head in : a : country where warranty
Re: OSD Model Code -- Article 1 (Free Distribution)
The Artistic license v. 2.0 has been proposed and a copy is at dev.perl.org/rfc/346.html As you will note, clause 5 has been revised. Consequently, I do not see an issue here. I am assuming that once proposed changes to the OSD are presented some of the current license templates may not be in compliance, but this is a forward-looking process. Rod On Wed, 22 Jan 2003, Forrest J. Cavalier III wrote: From: Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] To:Forrest J. Cavalier III [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: OSD Model Code -- Article 1 (Free Distribution) Do you mean clause 5 of version 2.0 of the Artistic License? If so, would you agree that the proposed change, either your suggestion or Larry's, would avoid the problem caused by the current Art. 1 of the OSD or do you think there is still a problem with clause 5? http://www.opensource.org/licenses/artistic-license.php clause #5 reads: 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. -- 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: OSD Model Code -- Article 1 (Free Distribution)
I suppose I read the OSD as setting up a guideline ABOUT the distribution of aggregate software (Art. 1) while the GPL essentially excludes aggregated software from its terms; the latter is a negation of scope of applicability while the former is a shall not restrict. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Hence, under the GPL, whether a mere aggregation constitutes a compilation depends upon the facts. This is an entirely distinct matter from art. 1 of the OSD, which does not limit its scope in the same manner as the quoted excerpt from the GPL. Larry's proposed change would solve this problem by taking the OSD out of the aggregate software business, which essentially puts us closer to the GPL. Rod - Original Message - From: John Cowan [EMAIL PROTECTED] To: Mark Shewmaker [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'Rod Dixon' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 21, 2003 11:55 AM Subject: Re: OSD Model Code -- Article 1 (Free Distribution) : Mark Shewmaker scripsit: : : (That is, I've always assumed that you can't claim that you've put : together a mere aggregation of programs while at the same time : claiming that you've been creative enough in your selection to warrant a : compilation copyright on the whole thing.) : : As far as I can see, the term mere aggregation in the GPL is equivalent : to compilation in the Copyright Act. (IANAL, TINLA). Which leads to : a subsidiary question: : : Is there a distinct right in the copyright-bundle to control the use of : works in collective works (a species of compilations)? If there is no such : distinct right, is it subsidiary to the right to copy the work, or perhaps : the right to make derivative works? Collective works typically contain : only verbatim copies, suggesting that it is the right to copy that is : relevant; however, the statute everywhere treats compilations and derivative : works in the same way (with the exceptions of compilations of phonorecords : and compilations made by archivists for preservation, which are treated : separately). : : I'm worried that your new Article 1 might restrict licenses from making : claims on collections that are more than mere aggregations, because even : though those collections for which a compilation copyright is claimed : are necessarily a derivative work (IMHO), : : That doesn't seem to be the case. Compilations and derivative works are : distinct according to both the explicit definitions and the implicit usage : in the Act. : : Again, IANAL, TINLA. : : -- : Said Agatha Christie / To E. Philips Oppenheim John Cowan : Who is this Hemingway? / Who is this Proust? [EMAIL PROTECTED] : Who is this Vladimir / Whatchamacallum, http://www.reutershealth.com : This neopostrealist / Rabble? she groused. http://www.ccil.org/cowan : --author unknown to me; any suggestions? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD Model Code -- Article 1 (Free Distribution)
Do you mean clause 5 of version 2.0 of the Artistic License? If so, would you agree that the proposed change, either your suggestion or Larry's, would avoid the problem caused by the current Art. 1 of the OSD or do you think there is still a problem with clause 5? Rod - Original Message - From: Forrest J. Cavalier III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 22, 2003 12:37 AM Subject: Re: OSD Model Code -- Article 1 (Free Distribution) : : With my rewording, there's also no need for the confusing term : aggregate software distribution. We only need to rely on the : definition of the term copies in the Copyright Act. 17 USC 101. : : I like the clarity of Larry's , but I think the clumsy wording of : OSD #1 was to permit the Artistic License clause #5 to qualify. : : Please read the Artistic License clause #5 and see if the : new proposed wording will continue to treat that license : the same way. : : Forrest : : -- : 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: OSD Model Code -- Article 1 (Free Distribution)
Good point regarding misuse since the initial confusion arose from the use of aggregate software in the OSD. Under Art. 1-1, I will delete footnote 3. As for Larry's revision of Art. 1 of the OSD, that seems fine with me and consistent with the original annotated version of the OSD. In removing the reference to aggregate software distributions, we remove many fuzzy issues that could arise with those type of distributions. Rod - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Rod Dixon' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 2:26 PM Subject: OSD Model Code -- Article 1 (Free Distribution) Rod, In your commentary (§1-1) on Article 1 of the OSD (Free Distribution) you reference several cases on copyright misuse. That confuses me. The copyright misuse doctrine has no application for that article of the OSD. Article 1 now reads as follows: The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several sources. The license shall not require a royalty or other fee for such sale. I think this Article really means: The license must permit all licensees to make copies of the software without payment of additional royalties to the licensor. The license cannot restrict licensees from either selling or giving away those copies. How can this ever be copyright misuse, since this provision imposes no restrictions whatsoever on downstream licensees? There is merely a self-imposed limitation on the licensor's right to collect royalties for copies made by those licensees, a limitation he voluntarily accepted by deciding to license his software as open source. With my rewording, there's also no need for the confusing term aggregate software distribution. We only need to rely on the definition of the term copies in the Copyright Act. 17 USC §101. Should we reword the OSD where appropriate to achieve clarity? /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD Model Code -- Article 1 (Free Distribution)
Mark's point re-introduces the copyright misuse issue since he is correct that there is a grey area concerning the validity of license restrictions on copyrightable collective works are concerned. Larry's proposal avoids this problem as long as it is agreeable that the OSD should not have anything to say about aggregate distributions. I suspect that the number of instances in which this issue could arise are minimal; hence, leaving out references to aggregate software makes sense. Rod - Original Message - From: Mark Shewmaker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Rod Dixon' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 11:02 PM Subject: Re: OSD Model Code -- Article 1 (Free Distribution) : On Sun, 2003-01-19 at 14:26, Lawrence E. Rosen wrote: : : Article 1 now reads as follows: : : The license shall not restrict any party from selling or : giving away the software as a component of an aggregate : software distribution containing programs from several : sources. The license shall not require a royalty or : other fee for such sale. : : I think this Article really means: : : The license must permit all licensees to make copies of : the software without payment of additional royalties to : the licensor. The license cannot restrict licensees : from either selling or giving away those copies. : : [...] : : Should we reword the OSD where appropriate to achieve clarity? : : I'm worried that this rewording could change OSD requirements for the : case of code incorporated into collections for which compilation : copyrights are claimed. : : Going back for a moment to the case of the GPL: : : | In addition, mere aggregation of another work not based on the Program : | with the Program (or with a work based on the Program) on a volume of : | a storage or distribution medium does not bring the other work under : | the scope of this License. : : I have always assumed that if you put together a bunch of GPL programs : on a CD and sold it, that was one thing, but if instead you claimed that : you selected and put the programs together in some artistic or creative : fashion and claimed a compilation copyright on the whole thing, that it : would no longer be a mere aggregation, and that the collection as a : whole would have to be distributed on terms compatible with the GPL. : : (That is, I've always assumed that you can't claim that you've put : together a mere aggregation of programs while at the same time : claiming that you've been creative enough in your selection to warrant a : compilation copyright on the whole thing.) : : Although the current Article 1 restricts licenses from making claims on : aggregate collections that include covered code, it doesn't seem to make : such restrictions if the collections are more than just a mere : aggregation of covered code. : : I'm worried that your new Article 1 might restrict licenses from making : claims on collections that are more than mere aggregations, because even : though those collections for which a compilation copyright is claimed : are necessarily a derivative work (IMHO), programs would likely be : included as whole copies, and your new Article 1 says that the license : can't restrict licensees from selling or giving away copies, with no : exceptions made if in merely making the copy they're also making a : derivative work. : : (BTW, article 8 is a moot point. Even if the license allows the new : compilation to be distributed under the same license, Article 1 seems to : be implying that it can't make any particular requirements about the : compilation as a whole, such as saying it must be distributed under this : license.) : : That's my worry about your proposed change. (I'm not a lawyer here, so : maybe I'm thinking about this all wrong, or maybe I'm confused on some : basic points somewhere, but it seems to me as if your rewording would : really change things.) : : -Mark Shewmaker : [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD Model Code -- Article 1 (Free Distribution)
I think Larry's point is a plausible interpretation as well, but the point is well-taken by this discussion that the current version of Art. 1 needs revision. Unless there is a very good reason to include a guideline on aggregate software under Art. 1 of the OSD, which covers free distribution, I favor the clarity of Larry's initial suggestion for revising Art. 1. Rod - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Mark Shewmaker' [EMAIL PROTECTED] Cc: 'Rod Dixon' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 20, 2003 12:30 AM Subject: RE: OSD Model Code -- Article 1 (Free Distribution) I think you're confusing copies, collective works and derivative works. These are each defined in the Copyright Act, 17 USC §101. There is no such definition for component of an aggregate software distribution. Claiming a collective work copyright doesn't mean you've created a derivative work. Here's an example. If an author exercises great creativity to collect together into one work the best poems of the last 10 years, he is creating a collective work and not a derivative work. The degree of his creativity isn't a factor unless he exercises no creativity at all (e.g., simply a list of poems randomly selected), in which case his collective work copyright might not be valid. Here's another example. If an author exercises great creativity to find the best open source utilities for distribution on a single CD, he is creating a collective work and not a derivative work. He requires licenses to make copies, not licenses to create derivative works. That's true no matter how much creativity he put into bringing the collection together. /Larry Rosen -Original Message- From: Mark Shewmaker [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 19, 2003 8:03 PM To: [EMAIL PROTECTED] Cc: 'Rod Dixon'; [EMAIL PROTECTED] Subject: Re: OSD Model Code -- Article 1 (Free Distribution) On Sun, 2003-01-19 at 14:26, Lawrence E. Rosen wrote: Article 1 now reads as follows: The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several sources. The license shall not require a royalty or other fee for such sale. I think this Article really means: The license must permit all licensees to make copies of the software without payment of additional royalties to the licensor. The license cannot restrict licensees from either selling or giving away those copies. [...] Should we reword the OSD where appropriate to achieve clarity? I'm worried that this rewording could change OSD requirements for the case of code incorporated into collections for which compilation copyrights are claimed. Going back for a moment to the case of the GPL: | In addition, mere aggregation of another work not based on the Program | with the Program (or with a work based on the Program) on a volume of | a storage or distribution medium does not bring the other work under | the scope of this License. I have always assumed that if you put together a bunch of GPL programs on a CD and sold it, that was one thing, but if instead you claimed that you selected and put the programs together in some artistic or creative fashion and claimed a compilation copyright on the whole thing, that it would no longer be a mere aggregation, and that the collection as a whole would have to be distributed on terms compatible with the GPL. (That is, I've always assumed that you can't claim that you've put together a mere aggregation of programs while at the same time claiming that you've been creative enough in your selection to warrant a compilation copyright on the whole thing.) Although the current Article 1 restricts licenses from making claims on aggregate collections that include covered code, it doesn't seem to make such restrictions if the collections are more than just a mere aggregation of covered code. I'm worried that your new Article 1 might restrict licenses from making claims on collections that are more than mere aggregations, because even though those collections for which a compilation copyright is claimed are necessarily a derivative work (IMHO), programs would likely be included as whole copies, and your new Article 1 says that the license can't restrict licensees from selling or giving away copies, with no exceptions made if in merely making the copy they're also making a derivative work. (BTW, article 8 is a moot point. Even if the license allows the new compilation to be distributed under the same license, Article 1 seems to be implying that it can't make any particular requirements about the compilation as a whole, such as saying it must be distributed under this license.) That's my worry about your proposed change. (I'm not a lawyer here, so maybe I'm thinking about this all wrong, or maybe
Re: Model Code for the OSD
We are assuming that there has not been complete past compliance with some of the guidelines in the OSD; hence, this process is meant to make compliance easier by clarifying and updating the OSD. IMHO, I think we all know well-documented source code when we see it. Rod - Original Message - From: David Johnson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; 'Rod Dixon, J.D., LL.M.' [EMAIL PROTECTED]; 'Rod Dixon' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, January 18, 2003 10:08 PM Subject: Re: Model Code for the OSD : On Saturday 18 January 2003 09:39 am, Lawrence E. Rosen wrote: : I would prefer requiring all available documentation describing how to : modify the original work. That means that a developer cannot hide : documentation that IS available simply to make others' work more : difficult. /Larry : : I'm not even sure that deliberately obfuscated source code even extends to : the documentation. Removing documentation may be necessary to obfuscate : source code, but removing it is rarely sufficient. : : The only type of documentation that is included in source code is comments. : Since the quality of comments in OSS projects ranges from the superb to the : dismal, defining obfuscation in terms of code comments is problematic. To : take one example, why should my modification of apache keep comments in : place, when libsrvg has virtually none to begin with? : : Every section in the OSD specifically refers to the license or the rights : attached to the program, except for section two. It needs to be read : differently. : : My opinion is that deliberately obfuscated source code should be decoupled : from documentation. The quality and state of documentation is very : subjective, and should not be a part of the OSD. : : -- : David Johnson : ___ : http://www.usermode.org : pgp public key on website : -- : 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: Model Code for the OSD
David has proposed that Article 2 of the OSD not be read to require documented source code. To implement this change on our draft, I can delete from section 2-2 of the model code the explanatory passage that defines obfuscated to mean, among other things, undocumented code. I'll make this change by the end of the month unless others post views to the contrary. Rod - Original Message - From: David Johnson [EMAIL PROTECTED] To: Rod Dixon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 9:55 PM Subject: Re: Model Code for the OSD : On Friday 17 January 2003 09:57 am, Rod Dixon wrote: : Larry List members: at your convenience, please download the current : draft of the OSD's proposed model code. : : I have one nit. : : 4: Source code that is exceptionally difficult to read either because it is : not documented or is cryptically expressed is considered obfuscated source : code... : : This seems onerous. It is the bad habit of many developers not to document : their code. If the code itself is easily understandable by someone conversant : with the language and the problem domain, then the lack of documentation : should not count as obfuscation. I don't want to point any fingers, but there : are numerous examples of OSS projects with absolutely no documentation. : : -- : David Johnson : ___ : http://www.usermode.org : pgp public key on website : -- : 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: Request for license approval...
Hmm...I wish I understood what you were really asking. At any rate, be careful to note whether the author of a license is making a claim that the license, itself, is copyright-protected; if so, you should get permission before you copy it. Rod - Original Message - From: Bruce Dodson [EMAIL PROTECTED] To: John Cowan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 4:59 PM Subject: 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 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Derivative Work for Software Defined
Hmm...If I understood your proposal correctly, you were suggesting a useful framework to respond to the often difficult assessment of how to determine whether a licensee has created a derivative work. My response was that your proposal/suggestion that the abstraction-filtration-comparison (AFC) test be viewed as the appropo test was an intriguing suggestion. I then raised two primary concerns: [1] that what modifications constitute derivative works is the open source problem that licensors seem to struggle with and the AFC test is neither intended, nor useful for such matters and [2] at bottom, the AFC test is used by courts to determine what aspects, if any, of the allegedly infringing work constitute a copyrightable work that may have infringed the plaintiff's work. Although the circuits do not agree on how to apply this test, I doubt that one can find more than an isolated court opinion that has adopted the AFC test as a tool to determine the constituent elements of a derivative work. I agree that one principle underlying the AFC test - - that you filter out the non-literal (or, literal) element that is uncopyrightable - - is a helpful guideline in circumstances when a licensor is overreaching by claiming a licensee created a derivative work by copying/modifying/using a non-literal element from the original work. In such simple cases, a derivative work will not exist. I don't see examples of this type being typical open source issues, however. [snip] Sorry, Rod, but I'm going to have to disagree with you on this point. See Tradescape v. Shivram, 77 F.Supp.2d 408 (SDNY 1999). Comparing two works as whole against one another to see how significant the diffs are between them is absolutely not the test for derivative work in any Circuit. Although such an initial first look is sometimes performed, it is not determinative as it would too often lead a court to protect uncopyrightable portions of the original work. I think what you are addressing is whether the second author has significant originality to be deserving of her own copyright in the derivative work. See Torah Soft v. Drosnin, 136 F.Supp.2d 276 (SDNY 2001) (All that is needed for a finding of sufficient originality is a distinguishable variation that is not merely trivial). But, simply finding sufficient originality such that a second work deserves its own copyright doesn't impact the analysis of whether that second work is a derivative of the original. [snip] I am not sure that the point in your last paragraph about originality not impacting that analysis of a derivative work is correct or, at least, not without notable exception (e.g. whether a derivative work is created by the computer colorization of film seems inextricably tied to the originality question). Rod -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Derivative Work for Software Defined
It's an intriguing idea, Dan, but your initial point that a derivative work triggers the compliance with FOSS seems only partially correct. A public re-distribution of the original work, for example, would trigger compliance as well...to the extent that compliance issues arise. In your second paragraph, you indicate that the abstraction-filtration-comparison test established by the Second Circuit is aimed at determining what constitutes a derivative work. Are you confident of this claim? There may be a principled basis for your position, but laying out the test does not quite sufficiently make that point. The test is primarily targeted for a different purpose- - at least in the software context (all of these tests with various names, AFC, idea/expression dichotomy and so on seem to aid the court in separating ideas from expression to determine what's left of the alleged infringing work once the tests are applied...on the track toward resolving an infringement claim). Even assuming a court has the wherewithal to abstract and filter out ideas from expression in the literal and non-literal aspects of a computer program, I am not sure that process would be relevant to open source. I doubt that there would be the over-reaching by an open source copyright holder that is generally required to reach this phase of dispute since the purpose of these tests, ostensibly, is to allow the alleged infringer to go about his or her way if all that the court has before it, after application of the pertinent test, is uncopyrightable expression; it would be odd to see an open source developer attempt to make claim to that. Admittedly, it may be intriguing to determine whether these idea/expression tests are suitable for derivative software work analysis, but courts seem to be following a different track. At issue for courts, it seems to me, is a fuss over degrees of modification; namely, whether a modification is too trivial/simplistic or too transformative to be deemed derivative (imagine a scale with the balance being the derivative measurement). The MODEL CODE for the OSD will attempt to set out this distinction, we hope. rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Ravicher, Daniel (x2826) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 10:36 AM Subject: Derivative Work for Software Defined Free / Open Source Software (FOSS) licensing relies critically on the concept of derivative work since software that is independent, i.e. not derivative, of FOSS need not abide by the terms of the applicable FOSS license. Therefore, one is left to ask, just what is a derivative work? This article (http://www.pbwt.com/Attorney/files/ravicher_1.pdf) addresses that question. Your comments and thoughts would be most appreciated. Best, --Dan Daniel Ravicher Patterson Belknap Webb Tyler LLP 1133 Avenue of the Americas New York, NY 10036 212.336.2826 direct 212.336.7900 fax mailto:dravicher;pbwt.com http://www.pbwt.com/ -- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. == -- 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
Terrific explanation! Thanks. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 I've been following this discussion with interest. Since some of it is generated at least in part by Sybase's submission of a license for OSI certification (which is based on the OSI-approved Apple Public License, with the addition of a click-wrap structure as a preferred alternative and a few other far less material changes), I wanted to respond/add to a few points. 1. Use Restrictions. It is not Sybase's intent (by use of a clickwrap format or otherwise) to restrict the use of the software for any purpose. Our principal interest is in protecting ourselves and other Contributors from any liability arising out of any such use. Many of the existing OSI-approved license agreements, in addition to the Apple Public License that Sybase based it's license on, condition permission to use the software on agreement to the terms of the governing license. For example: * IBM Public License version 1.0 and Common Public License, opening recitals: ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. See also the license grants in these agreements (Section 2), as well as in other agreements, that specify that the grants are Subject to the terms of this Agreement. *Nokia Open Source License (NOKOS License), Exhibit A and the Sun Public License, Exhibit A - Both require a notice in the source code files that states: The contents of this file are subject tot the [License] . . .; you may not use this file except in compliance with the License. We are not trying to accomplish anything different from what these other approved agreements are trying to accomplish. These other agreements are clearly structured as contracts, not bare license grants,and use of the software is expressly conditioned on agreement to the terms provided. (This includes terms designed to protect the open source status of the software.) The only material difference in the Sybase agreement is the addition of the clickwrap concept as a preferred structure. 2. Clickwrap Structure. The key issue from our perspective, and the reason for incorporating a click-wrap concept as a preferred structure, is to make the disclaimers of warranty and liability, as well as other terms of the license, enforceable. We don't care how anybody uses the software that is subject to the agreement, but we don't want any claims or potential liability from any such use. Unless there is a structure that under current law gives some confidence that the disclaimers and limitations in particular will be enforced, there is a real disincentive for many entities to make software available on an open source basis. In my opinion, the current legal reality is that because of recent case law , structures - widely used as they are - that provide some notice of license terms but do not require a clear, unambiguous, affirmative manifestation of assent after an adequate opportunity to review may not be enforced by many courts in many cases. The language in the Sybase agreement does not require a click-wrap structure in all cases. It provides: Whenever reasonably feasible you should include the copy of this License in a click-wrap format, which requires affirmative acceptance by clicking on an I accept button or similar mechanism. If a click-wrap format is not included, you must include a statement that any use (including without limitation reproduction, modification or distribution) of the Software, and any other affirmative act that you define, constitutes acceptance of this License, and instructing the user not to use the Covered Code in any manner if the user does not accept all of the terms and conditions of the License. The alternative to click-wrap provided for is the same structure referred to above that is already in some OSI-approved license agreements, while adding the flexibility of allowing other affirmative acts to be defined. The reasonably feasible qualifier should address situations where clickwrap presents a technical problem. There may be better ways to provide the necessary flexibility, but the intent was to provide it. The reason for preferring clickwrap is that such a structure has been recognized and enforced by several courts. Other clear, unambiguous and affirmative manifestations of assent should be adequate, too - as noted in the article that Larry Rosen circulated, this is the key issue - so long as the user has an opportunity to view immediately accessible terms and reject them if he/she doesn't agree with them. But the courts haven't addressed all
Re: Newbie Question
My initial reaction was the same as John's reaction, but the OSD does not seem to provide clear answers on this. I was inclined to say that the OSD would require no answers to both questions, but as the poster mentioned, the text of the OSD is not that specific. - Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: John Cowan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 29, 2002 5:55 PM Subject: Re: Newbie Question [EMAIL PROTECTED] scripsit: 1. Is there a license which specifically disallows any forks or extensions which would limit the use of a program/package to a particular environment or OS? If not forks, then extensions only; if not environments, then OS. Frankly, such a thing sounds perverse. It means that the program cannot be adapted for a specific OS/environment, since such an adaptation would necessarily be limited to that OS/environment. For example, if your program were written for Linux, it could not be ported to Win32. I can't see how such a thing could possibly be consistent with the OSD. What evil are you trying to prevent? If you just want to make sure that the latest'n'greatest version can be adapted to all environments, just use a strong copyleft like the GPL, and it will never be possible to write code in the Win32 fork that can't be ported back to the Linux fork. -- XQuery Blueberry DOMJohn Cowan Entity parser dot-com [EMAIL PROTECTED] Abstract schemata http://www.reutershealth.com XPointer errata http://www.ccil.org/~cowan Infoset Unicode BOM --Richard Tobin -- 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: click-wrap is legally supportable?
Some of your hypotheticals are interesting, but I think you are missing the point. We are discussing licenses that are presumably issued by licensors. In that respect, it is in the interest of the licensor to follow the steps that might ensure that his or her license is enforceable. One of the steps relevant for the licensor is contract formation or for the licensee we might simply say mutual assent, which is where a mouse click might help. The questions Russ poses seem to be of the type: well, what about the licensee? Certainly, the interests of the licensor are not always consonant with those of the licensee, but this isn't a very compelling soapbox issue in my opinion. In particular, many on this list seem to have no aversion to the warranty disclaimer, which, if enforceable in a particular state, is not exactly user-friendly. Quite honestly, in the balance, I think that the clickwrap issue favors end-users more so (or is less one-sided) than a warranty disclaimer. Mutual assent is meant to ensure as best as practical that folks know what they are agreeing to be bound by, and in that light serves the interests of both parties...whereas the warranty disclaimer serves the interest of the licensor, violates consumer protection principles, but has the effect in open source of offering a trade of interests. I wonder if you are deemed to have accepted a click-wrap license if software requiring a click-wrap appears on your machine? Have you agreed to every license which was clicked past on your machine? What if an employee with no authority to bind the company to a contract clicked? What if someone who has no ability to enter into a contract clicked (e.g. your kid)? What if a repairman clicked? Or the cable guy clicked? In the various cases which are claimed as precedent, did the judge get asked these hard questions? -russ And, what about the envelopes left at your home from a stranger in a uniform that get tossed in the trash, unread. Might any of those items be binding? Upon who? Why? The point is I do not think we need to exploit circumstances involving mailmen, the cableguys, or the repairwomen to properly analyze how mutual assent applies to open source website licenses. A range of mechanisms might be appropriate to ensure mutual assent, including instances where a click is unnecessary. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
Despite the expressed sentiment of some OSI members, I doubt that any lawyer would advise support of this change to the OSD, if it pertains to the clickwrap issue. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 I'm going to propose a change the Open Source Definition at our board meeting next Thursday. It is simply this: 0) A license may not restrict use or modification of a lawfully obtained copy of a work. Anybody have problems with this? Does this have any problems? -- -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: a proposed change to the OSD
Calling an open source license a gift is nice semantics, but I am unsure what else that description gets us... Try asking yourself what is the remedy for breach/violation of an open source license that the copyright holder/licensor can pursue? In answering the question, it is not enough to say that no one will violate the license; I am asking a what if question (and, truth be told, open source licenses occasionally are violated). Not to ask and answer my own question, but I suspect the answer will be that the open source licensor/copyright holder will seek the same remedy as anyone else; namely, the copyright holder will enforce his or her copyright license. If so, there are obvious questions that the court will have to answer, which may include the mutual assent issue, if litigation is the route to remedy. I understand the desire to develop of a habit and practice that might ultimately impact the resolution of legal rights in the somewhat-distant future, but I do not understand the persistent inclination to ignore how courts have viewed these issues in the past, and likely will do so for some time in the future. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 26, 2002 1:01 PM Subject: RE: a proposed change to the OSD Lawrence E. Rosen writes: the courts are clear about the importance of such notices for contract formation. What attributes of a license make a contract necessary? I know that you need a contract to disclaim warranties, but I'm not sure that it's necessary to disclaim a warranty on a gift. I'll change my mind about this only after you succeed in changing the law. That's what I'm trying to do. I have mostly contempt for legislators, but judges and lawyers form law in a much wiser manner. There isn't an awful lot of precedent in regards the distribution of free software, and what precedent exists is only on a District level. I believe that, by codifying existing practice, we can change the law -- or at least affect judge's decisions. At the end of the day, Larry, the community doesn't want to use software for which it has to contract to use. Since it's our job as an industry advocacy group to encourage the production and use of open source software, it's our responsibility to tell the producers of open soruce that the users of open source aren't going to contract for its use. -- -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: discuss: Request for wxWindows License approval
There is a strong argument that wxWindows refers only to the windowing functionality that is a generic use. It's a strong argument, but that is all it is. You are correct that MS is not getting a favorable response from the court so far in the Lindows matter, but the USPTO also denied registration of windows trademarks initially, but relented after tenacious lawyers persisted. I have not analyzed your use of wxWindows. Please understand that I am certainly NOT positing a legal opinion on that. My comment was directed at OSI, which has its own trademark interests to consider, and it may be that OSI will ask you to have your lawyer submit a document showing the due diligence on this. If all turns out well, the irony is apparent when you consider the apposition of an open source mark with the claimed mark Windows. See http://www.microsoft.com/trademarks/t-mark/nopermit.htm Rod - Original Message - From: Julian Smart [EMAIL PROTECTED] To: Rod Dixon, J.D., LL.M. [EMAIL PROTECTED]; John Cowan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 3:17 AM Subject: Re: discuss: Request for wxWindows License approval At 21:09 22/10/2002 -0400, Rod Dixon, J.D., LL.M. wrote: I cannot resist calling out the irony and twists-of-fate of an OSI trademark certification of a wxWindows open source software product. If OSI has the temerity to grant that one, yall should send out a press release. Seriously, let's be careful with how we view other trademark matters when the expectation is that the OSI mark should be equally respected. [I am off the soapbox now]. Hi, Do you think you could clarify? I don't understand what you're referring to here... perhaps the fact that the name has 'Windows' in it? It's been 10 years and MS hasn't sued yet, and the Lindows case didn't go well for them. I certainly didn't intend to abuse the name, and in fact I was using Windows in a generic (windowing) sense (it's only the first 'w' that refers to the MS product :-)) Thanks, Julian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Request for wxWindows License approval
I cannot resist calling out the irony and twists-of-fate of an OSI trademark certification of a wxWindows open source software product. If OSI has the temerity to grant that one, yall should send out a press release. Seriously, let's be careful with how we view other trademark matters when the expectation is that the OSI mark should be equally respected. [I am off the soapbox now]. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: John Cowan [EMAIL PROTECTED] To: Julian Smart [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 1:43 PM Subject: Re: discuss: Request for wxWindows License approval Julian Smart scripsit: The wxWindows development team would be very grateful if you could consider the wxWindows license for OSI approval, to allow wxWindows to be OSI-certified. The current license is L-GPL plus an exception clause that can be summarised: The exception is that you may use, copy, link, modify and distribute under the user's own terms, binary object code versions of works based on the Library. IMO, this license is obviously compliant and should be fast-tracked. -- Henry S. Thompson said, / Syntactic, structural, John Cowan Value constraints we / Express on the fly. [EMAIL PROTECTED] Simon St. Laurent: Your / Incomprehensible http://www.reutershealth.com Abracadabralike / schemas must die!http://www.ccil.org/~cowan -- 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: Why is BSD OSI certified?
John, would you further clarify your point? I am unsure whether I understand the distinction you are making. An open source software license governs open source software. How did you splice this to get to Netscape 7.0? I can post part of Netscape's license, if necessary, but paragraph 5 (I think) raises exactly the point Alain raised (but with regard to the BSD). At issue is whether a developer can define their way out of open source by arguing that their product does not meet the definition. This is not the current purpose of the OSD so I am hopeful that I have misunderstood your point. Rod On Wed, 16 Oct 2002, John Cowan wrote: Alain =?iso-8859-1?Q?D=E9silets?= scripsit: Looking on OSI's web site, I see that BSD is OSI certified. However, one criteria for OSI certification is that: Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. OSD #2 is different from the other requirements: it says what a product must allow in order to be Open Source, rather than what the product's license must allow. A binary-only distribution is not itself Open Source, for the sufficient reason that it is not source at all, even if it was built from Open Source (BSD, MIT, AFL, etc.) components. The MPL is an Open Source license, and Mozilla is an Open Source product, but Netscape 7.0 is not an Open Source product, because not all of its source is available to us, even though most of its source is licensed under the MPL. -- John Cowan [EMAIL PROTECTED] http://www.reutershealth.com I amar prestar aen, han mathon ne nen,http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_ -- 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: Why is BSD OSI certified?
Rod Dixon scripsit: John, would you further clarify your point? I am unsure whether I understand the distinction you are making. An open source software license governs open source software. Although the OSI certifies licenses, the OSD is a definition of what it means for *software* to be Open Source. Eight of the nine restrictions are worded in terms of what the license of the software must provide for; but OSD #2 restricts the software directly, saying that unobscured source code for the program must be easily available, but in no way constraining the license. For purposes of clarification, all of the articles of the OSD may be viewed as referring to open source software distributed under the terms of an open source license. Article 2 of the OSD sets out a requirement that if the applicable license ignored the restriction or contained provisions that were contra, the license would not be consistent with Article 2. I suspect the OSI Board might reject such a license, if it were submitted. In that regard, I would not state that Article 2 of the OSD is just about software and not like the other articles. How did you splice this to get to Netscape 7.0? I can post part of Netscape's license, if necessary, but paragraph 5 (I think) raises exactly the point Alain raised (but with regard to the BSD). I suppose you mean the NPL. No, I meant what I stated. I posted an excerpt from the Netscape license below. The fact that it is difficult to view Netscape's license online is not your fault. Netscape's clickwrap in 7.0 is odd and I am unsure why the AOL/TW lawyers advised them to do what they are doing. But Netscape 7.0 is not distributed under the NPL, and indeed contains components whose source code is proprietary. Taken as a whole, Netscape 7.0 is as closed as Windows. I have been unsuccessful in finding a specific license for Netscape 7.0, but the general Netscape license at http://wp.netscape.com/terms/index.html#sw forbids modifying, selling, copying, or distributing anything not explicitly distributed under any other license such as the NPL or MPL. Take a look at paragraph 7. I do not know what to make of it...perhaps its terms are part of a concession to an earlier dispute. At any rate, one would have to reverse engineer their code to determine whether any of your assumptions are correct. How would one know whether version 7.0 is not covered code as defined by the NPL? This is a genuine open source conundrum, and I thought that was the type of issue you spotted in Article 2 of the OSD, but I stand corrected. [snip] - Rod NETSCAPE (r) 7.0 END-USER LICENSE AGREEMENT Redistribution Or Rental Not Permitted These terms apply to Netscape 7.0 BY CLICKING THE ACCEPT BUTTON OR INSTALLING OR USING THE NETSCAPE (r) 7.0 SOFTWARE (THE PRODUCT), YOU ARE CONSENTING TO BE BOUND BY AND BECOME A PARTY TO THIS AGREEMENT AND THE LICENSE AGREEMENT FOR AOL (r) INSTANT MESSENGER (tm) SOFTWARE ATTACHED BELOW, AS THE LICENSEE. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, YOU MUST NOT CLICK THE ACCEPT BUTTON, YOU MUST NOT INSTALL OR USE THE PRODUCT, AND YOU DO NOT BECOME A LICENSEE UNDER THIS AGREEMENT. 1. LICENSE AGREEMENT. As used in this Agreement, for residents of Europe, the Middle East or Africa, Netscape shall mean Netscape Communications Ireland Limited; for residents of Japan, Netscape shall mean Netscape Communications (Japan), Ltd.; for residents of all other countries, Netscape shall mean Netscape Communications Corporation. In this Agreement Licensor shall mean Netscape except under the following circumstances: (i) if Licensee acquired the Product as a bundled component of a third party product or service, then such third party shall be Licensor; and (ii) if any third party software is included as part of the Product installation and no license is presented for acceptance the first time that third party software is invoked, then the use of that third party software shall be governed by this Agreement, but the term Licensor, with respect to such third party software, shall mean the manufacturer of that software and not Netscape. With the exception of the situation described in (ii) above, the use of any included third party software product shall be governed by the third party's license agreement and not by this Agreement, whether that license agreement is presented for acceptance the first time that the third party software is invoked, is included in a file in electronic form, or is included in the package in printed form. If more than one license agreement was provided for the Product, and the terms vary, the order of precedence of those license agreements is as follows: a signed agreement, a license agreement available for review on the Netscape website, a printed or electronic agreement that states clearly that it supersedes other agreements, a printed agreement provided with the Product, an electronic agreement provided with the Product. 2
Re: Create new license or use MPL?
Despite the length of your question, it is fairly vague. You may want to post the draft of the license with an explanation. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 Hi people, Following the discussion about modified licenses and the desire to keep the number of licenses as little as possible, I have the following question. I'm working on a website project. My work involves Java, HTML, and plain content. I would like a license that covers all 3 types of work, or material. The spirit of the license should be like the MPL, which I think is a very nice license. But the MPL speaks of code in particular as material, not of any kind of material. So I'm not sure whether I could use the MPL for my work. Or can I? Will it cover all of my work, including the plain content? Currently, I have written a new license, which is essentially a copy of the MPL, in which I replaced all such terms as Covered Code by Covered Material. Is this better or does this nothing but increase the nr of licenses out there? If it's the latter, then I'm dumping my license. regards, Henry Pijffers -- Kopflos lauf ich durch die Nacht alleine Unterwegs ich rede mit mir Selbst Und verstehe kein Wort Von dem was ich mir erzähl -- 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: OCLC Office of Research Open Source License
As far as the OSD is concerned, generally, the ORPL 2.0 seems fine to me, except for a couple of license drafting matters. I would consider revising the grant clause (section 4) to reflect the initial grant, which was placed under section 1 (Your Rights). For clarity, it seems appropriate to use a grant clause that contains the rights granted by the licensor as section 1 is written. Section 4 is a bit more mysterious in that it reads like a cross-license for subsequent licensees? Is this section an attempt to show consideration? Lastly, I can understand why an original licensor would want section 4 to survive termination of the license, but I am unaware of the legal basis for that kind of outcome. Even so, assuming this is a grey area, would it be more plausible to specify the purposes for which the grant in section 4 survives termination rather than to say any reason? I am assuming that none of the reasons include termination by the licensor. Is this correct? - Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Terrall,Tom [EMAIL PROTECTED] Sent: Monday, September 30, 2002 10:39 AM Subject: discuss: OCLC Office of Research Open Source License [ Please discuss this license. -russ ] Open Source Initiative. September 23, 2002 Dears Sirs, We are submitting the OCLC Office of Research Public License 2.0 as a candidate for OSI Certification. Feel free to post the license to the license-discuss list. Let me know if I can assist in anyway. Thank you. Thomas L. Terrall Software Engineer License Approval Requirements 1. The OCLC Research Public License 2.0 (ORPL) is available for review at ( http://purl.oclc.org/oclc/research/ORPL/ ) 2. The ORPL 1.0 version was prepared by individuals, who are no longer at OCLC. It appeared to be most closely related to Mozilla Public License 1.0 (MPL) in content. ORPL 2.0 is a reworking of ORPL 1.0 guided by the Open Source Definition and MPL. Our legal department assisted with the legal language and necessary legal clauses. We hoped to improve the license by clarifying certain issues and by simplifying and reorganizing the content. We also made certain adaptations to our situation. Here are some of the differences between ORPL and MPL. i) ORPL does not allow for the executable code to be distributed with a different license. See MPL 3.6. ii) ORPL does not contain the content, Inability to Comply Due to Statute or Regulation. See MPL 4.0. iii) MPL allows licenser to grant additional rights to licensee. We did not see this was applicable to our case. iv) ORPL does not restrict in any way the commercial use of software while MPL is unclear (to me) on this matter. v) ORPL does not require the modifications made by a Contributor to be sent to the Original Contributor. vi) ORPL gives the required steps if there is a third party claim against a version of software. vii) ORPL explicitly states: This License provides you no implied rights or licenses to the intellectual property of any Contributor. viii) MPL gives a more detailed definition of Source Code, including interface definition files, compressed files, make files and so on. We did not include these details ix) MPL specifies a time interval for source code to be available for those licensees who request it. We did not include a time limit for this. x) ORPL does not cover the case that contributors will not offer warranty, support or liability protection to the code recipients. 3. Certain licenses are very simple, such as BSD, ORPL would have to take precedence over BSD in a Combined Work. A license such as MRL which requires Contributor updates to forwarded to the Original Contributor would take precedence over ORPL. I don't know of an entirely incompatible license. OCLC Office of Research Open Source License Section 1. Your Rights Subject to these terms and conditions of this License, the OCLC Office of Research (the Original Contributor) and each subsequent contributor (collectively with the Original Contributor, the Contributors) hereby grant you a non-exclusive, worldwide, no-charge, transferable license to execute, prepare derivative works of, and distribute (internally and externally), for commercial and noncommercial purposes, the original code contributed by Original Contributor and all Modifications (collectively called the Program). Section 2. Definitions A Modification to the Program is any addition to or deletion from the contents of any file of the Program and any new file that contains any part of the Program. If you make a Modification and distribute the Program externally you are a Contributor
Re: license name arrogance Re: Academic Free License
I agree with Reese's response to the original post about Larry. I think that post was particularly ill-mannered. Larry's intent was entirely misunderstood by the poster. The service that Larry is providing is generous, not grandiose. He is drafting software license templates, which necessarily are not attached to specific projects. In addition, Larry is using names that are general and clear enough so that those who may benefit from the template are aided in their selection of the appropriate license template to use for adoption of their own license. Lastly, it should go without saying on this list, but I'll say so anyway; lawyers who do work in software licensing (many of whom are primarily lawyers specializing in Intellectual Property) do not come cheap, and their services are in high demand these days. Hence, it is actually an understatement to say that the services Larry is providing ought to be appreciated. Occasionally, I am taken aback to see what appears to be reflexive attacks on lawyers on this list. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] Cyberspaces: Words-Not-Deeds: http://www.cyberspaces.org/webzine/ - Original Message - The other licenses were created for specific projects. The AFL and OSL are not, so I think that it is perfectly fine to give them generic names (and yes, they are superior in some way.) OSI should encourage specific license names unless a license is a product of wide community consent. Just a suggestion. How can a license gain such consent prior to having a name, and if it already had a well-known name would it be wise to change it? The only concern I have about the names is that Free and Open seems to be switched. The OSL is based on reciprocity, which is usually associated with Free Software, and the AFL is not, which is usually associated with Open Source (especially when seen in the light of RMS's rejection of Open Source.) -- 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: Legal soundness comes to open source distribution
Larry's comment sums up my point quite well when he states: [snip] Whatever else open source licenses do, they do not explicitly make a licensee the owner of a copy. The implications of the licensee not being an owner of the copy of software he/she has possession of go directly to Bernstein's point. At any rate, in the context of open source licensing, Bernstein's argument requires understanding how section 117 relates to section 109 with respect to the status of the end-user/licensee. The matter is not pertinent to this discussion, but someone raised the issue. [snip] Regardless of this confusing point, why does this make click-wrap problematic? That's a good question. In my previous post, I attempted to summarize the arguments presented because I had the same reaction. I think a few people had a near-visceral reaction to the very idea of click-wrap and the contractual-open-source-license. Even so, I have repeated that click-wrap is but one way to show an indicium of mutual assent. Although in unusual circumstances there may be practical difficulties implementing a click-response for user input, the opposition to the concept of mutual assent seems over-blown. If dialog boxes are too confusing, there are other ways to achieve the same result. I can imagine some strategic advantage denominating an open source whatever as a copyright license rather than a contract, but I am befuddled by the opposition to what ostensibly are simple steps to decrease the likelihood of a successful challenge to the validity of the license. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
I want to summarize what we have discussed on click-wrap because the issue is significant from the standpoint of the legal standing of open source licenses, and so I can include proposed responses in our research project on the OSD. It is my understanding that the issue initially involved the approval of a license, not a change to the OSD. The discussion of click-wrap then considered whether the fact that adding indicia of mutual assent to website agreements like open source licenses (e.g., a mouse click from the user) might have adverse implications for the position that open source licenses are non-contractual licenses. There was also some discussion concerning whether click-wrap conditions imposed on downstream or sub-licensees is practical (it may be difficult to implement). Finally, some raised the question whether the click-wrap condition is doomed to failure in cases where distribution is packaged with multiple programs carrying distinct licenses. Is this a fair summary? Rod - Original Message - From: David Johnson [EMAIL PROTECTED] To: Carol A. Kunze [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, August 14, 2002 12:00 AM Subject: Re: Legal soundness comes to open source distribution On Tuesday 13 August 2002 08:30 pm, Carol A. Kunze wrote: You have to OWN the copy. When I say that in a proprietary license the licensor reserves title to the copy, I am saying the licensor takes the view that the user does not OWN the copy. ... If you buy a house you can do what you want with it, if you rent it you only get the rights your lease give you. This is where the big disconnect occurs between the user and the manufacturer/licensor. When I rent a house, I KNOW that I am renting a house. But with software I have no clue. I have undergone every single motion of purchasing a product, obtained a sales receipt that itemizes a copy fo the software, yet I do not own it. Moreover, I don't even know this fact until the first time I try to use it. I am of the archaic and jurassic opinion that law that cannot be understood by the average layman is bad law. When the average consumer thinks they are buying a copy of Windows when they are not, because the law says they haven't, then the law is an accomplice to fraud. Skipping back to the middle of the last paragraph... The payment that is made is for a license to USE the software. From where I sit, it seems like the user is purchasing the right to VIEW the license. Only when they actually view the license and subsequently agree to it, do they gain the right to use the software. I still do not understand why the OSI definition would have to change. Why is the requirement for clickwrap any different from those licenses which OSI has blessed and which in fact are intended to be agreements? Can someone clue me in here? The main issue in my mind is not the simple click-wrap. That already exists in several forms for several Open Source products. Instead, the real issue (to me) is whether an Open Source license can require derivative works or downstream distribution to also use click-wrap. -- David Johnson ___ http://www.usermode.org pgp public key on website -- 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
I would be careful not to over-read the court's point. In Specht v. Netscape, the court is trying to highlight factors that distinguish browser-wrap from click-wrap since other courts have generally viewed browser-wrap contracts as lacking strong indicia of mutual assent. If the website appears to have merely set up a way to download software and provided potential downloaders with a notice (that is not hyperlinked) to read the license, then a court may view the notice as an invitation to read a license (browser-wrap) rather than conclude that there is sufficient indicia of mutual assent (e.g., click-wrap). To be clear, no court has REQUIRED a set of dialog boxes or buttons with I accept or I do not accept. Rather, the point is that the website that seeks potential user input (clicking buttons, pulling down menu items...whatever) may strengthen the licensor's claim that the contract/license is binding upon the parties because contract formation principles have been followed, and the court may infer that the license was read and that the licensee agreed to the terms. -Rod Lawrence E. Rosen wrote: 'Forrest J. Cavalier III' wrote: I would want to agree individually, not in bulk. Courts also insist that it should be that way. ... That is why I suggested in the notice that you there be a simple procedure to review all the licenses. Please review and agree to the terms of the Netscape SmartDownload software license agreement before downloading and using the software. (quoted from the quotation in Specht v. Netscape.) The court said that this language is simply an invitation to read the license, and merely because a user saw this text, it cannot be inferred that the license will bind the user. (aside - On strict legal grounds, I feel that the decision in Specht requires reconsideration) The name of each software program on this distribution and its applicable license is listed on the file LICENSE.TXT included with this distribution [, which you can read by clicking on REVIEW THE LICENSES below]. The court will say that this language is simply an invitation to read the licenses, and merely because a user saw this text and clicked on 'I agree, it cannot be inferred that the license will bind the user. Regards, Mahesh T Pai. Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.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: Legal soundness comes to open source distribution
Your questions actually raise many more issues than is apparent. The first critical hurdle we need to conquer is the confusion over whether open source licenses, which are presumed to be in compliance with the OSD, are properly denominated non-contractual licenses. I do not agree with that claim, but I do think that it is a claim that requires resolution. Although there may be strategic reasons for insisting that the GPL (or any other open source license) is merely a copyright license, there are consequences attached to the position. One way to consider this matter is to faithfully review the OSD to determine whether some of its articles exceed the boundaries of copyright law. If so, it may be unhelpful to ignore that fact in assessing whether an open source license is non-contractual. Regarding the question about giving up warranty rights, I am not familiar with any case explicitly on that point, but maybe someone else has more information on that matter. On the other hand, as is licensing is authorized under UCITA. In addition, the federal warranty law (Magnuson-Moss) only governs a WRITTEN warranty for consumer, mass-market goods, which, arguably, may include software distribution when the seller provides a written warranty. Generally, if a written warranty is provided, the seller cannot eliminate any implied warranty under the federal law; that condition might be what Brian is referring to by his reference to warranty rights. I believe the bottom line for open source licensing is that the federal law does not apply to as is licensing. You might conclude that as is licensing is not exactly consumer-friendly, but one might also view it as part of the trade-off for the freedom granted by the licensor. Rod Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Brian Behlendorf [EMAIL PROTECTED] To: Russell Nelson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, August 03, 2002 4:20 AM Subject: Re: Legal soundness comes to open source distribution On Fri, 2 Aug 2002, Russell Nelson wrote: From what various legal scholars tell me, a non-contractual license (such as the GPL) cannot cause you to give up your warranty rights. Is there a reference of some sort for this? It's about the only solid reason I see to need to go beyond copyright law. Is there any court precedent that suggests this? A case where someone was given something for free, with warranty disclaimed in a copyright license, and the court decided that warranty disclaimer was invalid? This is a pretty big delta to current understanding, so if a change as large as expanding the OSD to cover contracts is based upon this, we need more than hearsay. Are there any other reasons to consider allowing the OSD to cover contracts? My sense is that keeping it limited to copyright licenses has been key to its success to this point. Agreed. That's why I think we need to amend the OSD so that it clearly states that a license must not restrict use, modification, or redistribution of the software. The OSD, by applying to copyright licenses, already allows restrictions on redistribution. It'd be kinda toothless if it didn't... Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
I guess I am unsure of why there is such strong opposition to a clickwrap licensing requirement. The Netscape-Smart-download case follows the prevailing legal climate; namely, the licensor increases the risks of losing a legal challenge to the license (either under the enforcement of a license provision or the formation of the entire agreement) if the licensor does not carefully ensure that proof of mutual assent can be shown. Regarding Bruce's three questions: there are at least two federal laws that might be relevant to this question: Magnusson-Moss and E-SIGN, and there are likely to be nearly 50 state laws and 2 uniform codes relied upon by courts. In other words, I do think the correct answer to the first question is going to be yes. In response to question #1, I would ask another question: aside from ease on the license drafter, why would you want to impose terms (a disclaimer is still a license term, albiet a negation) under conditions that make it unclear to both parties whether the terms have been agreed to? This seems to run counter to the purpose of drafting terms. Questions 2 and 3 appear to be answered, in part, by the Netscape-Smart-Dowload opinion. I do not agree with all of the court's points (footnote 10 seems particularly distressing), but I think the court adopts the prevailing approach by characterizing the netscape license at issue as browser-wrap lacking manifestations of mutual assent. One final word of caution on this matter: once the OSI board resolves the approach to take on clickwrap, whether a particular warranty disclaimer will be enforced may depend upon a patchwork of state and federal consumer protection laws for mass market, open source licenses, which is likely to mean that some disclaimers may not be enforced even if they are enforceable. Rod Is there a reference of some sort for this? It's the case at http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07482.PDF . IMO it's not all that germane to warranty disclaimer, and I'm not buying the chain of extrapolation that leads from this case to the conclusion that click-wrap might be necessary. It's about the only solid reason I see to need to go beyond copyright law. It's not about copyright law at all. The warranty obligation does not follow the copyright. It's about: 1. Is a simple warranty disclaimer that does not require agreement adequate? 2. How do you need to present the warranty disclaimer? 3. Do you really need a contract that other parties actually agree to in some way, for example by clicking yes? It's reasonably clear that you need one if you want someone else to indemnify you. It's not nearly so clear that you need one if you simply want to disclaim warranties. Agreed. That's why I think we need to amend the OSD so that it clearly states that a license must not restrict use, modification, or redistribution of the software. I agree that there should be no restrictions on use, modification, or distribution _other_than_those_ necessary to implement the goals of Open Source, such as disclaiming the warranty, preserving the copyright statement, mandating source distribution when the licensor chooses that option, and mandating transmission of the license to all parties. A simple no restrictions equates to public domain. Larry Rosen: I am baffled by everyone's confusion and philosophical rantings. That's distressing. This is your own community, or should be, since you claim to represent them. If they are confused, shouldn't you blame your presentation of the issue? If they are philosophical, and you didn't expect that, could it be that you've lost touch with them? So far, I see some significantly better alternatives than click-through. The very first should be a set of guidelines for distributions and other environments where free software is installed that would cause them to inform the user that: 1) There are licenses. 2) They disclaim warranties. 3) This is how you view the licenses. 4) This is how you look at the source code to perform your own due diligence. In the case of a distribution, most of them already do this at distribution install time. Debian does display a click-through warranty disclaimer when you install it. It also has a login message disclaiming warranties, but only on the text login. Obviously, this needs to be beefed up. In the case of package installers on something other than a Linux distribution, where we have less control of the enivronment, perhaps click-through is appropriate, but I still would oppose allowing it to be a license requirement. A license that requires it is going to cause us no end of trouble with the environments where we can deal with the problem more easily. Thanks Bruce -- 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: Legal soundness comes to open source distribution
Your points have answered a couple of questions. If we look at this issue narrowly, it makes sense to say that clickwrap should not be a mandatory requirement of the OSD, but could be approved as appropriate for an open source licensor. The point being that there is nothing extraordinary about clickwrap/click-through method itself that sustains mutual assent; rather, there are many ways to accomplish this task that are more appealing as a practical matter. In that light, there are a number of ways to disclose a warranty disclaimer in a manner that best ensures that the end-user receives notice/consent. It is difficult to frame the warranty disclaimer issue abstractly and independently of the license because one walks from one potential quagmire to another despite the fact that a specific instance is probably a great deal less complicated. The bottom line is very close to how the discussion sees to have begun. If an open source licensor distributes software via a website, the license/warranty disclaimer/contract/ should make its way to the potential licensee in a manner that the netscape license in the smart-download case did not. Click-through dialog boxes seem to offer a level of assurance that a court might agree with the licensor that mutual assent is indicated. Clickwrap is not the only way to show mutual assent. More practical measures are certainly possible so I would agree that we should not get too affixed to clickwrap when less budernsome, but equally effective measures can be adopted. Should the OSD mandate a clickwrap measure? I agree with those who say no, but I would not undermine the importance of mutual assent when it is relevant. License drafters should be aware of the importance that contract formation rules have on the enforceability of the license regardless (and independent) of the terms. Is mutual consent relevant for warranty disclaimers only? I think this is a difficult question in the context of software licensing, but viewing the matter simply as a generic issue, my answer is: since an AS IS disclaimer is ostensibly not a promise of anykind, the effectiveness of the AS IS notice is likely to be controlled by consumer protection laws, rather than a genuine issue of copyright licensing (i.e. copyright law or contract law). Anyone with a consumer protection law background? I have made no further comment on the philosophical issues since they seem to raise the stakes of disunity more than the legal issues. Rod - Original Message - From: Bruce Perens [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, August 03, 2002 5:20 PM Subject: Re: Legal soundness comes to open source distribution Bruce Perens: 1. Is a simple warranty disclaimer that does not require agreement adequate? From: Rod Dixon [EMAIL PROTECTED] I do think the correct answer to the first question is going to be yes. In response to question #1, I would ask another question: aside from ease on the license drafter, why would you want to impose terms (a disclaimer is still a license term, albiet a negation) under conditions that make it unclear to both parties whether the terms have been agreed to? This is mostly an issue of practicality - and practicality is what drives many OSD questions. Debian, for example, has some 8000 packages, and a typical system will have 1000 to 3000 of them, some people install the whole kitchen sink which is probably around 6000 packages once package conflicts are resolved. The packages are produced by some 800 different package maintainers who are not employees of Debian and are not under the orders of any corporation. Of course there are many different owners for the software that is packaged. It's not clear that Debian is the warrantor, rather than the package maintainers and the copyright holders. There are at least 100 variations on the licenses, both different license versions and different entities offering the same licenses. If even one one-hundredth of the packages required click-wrap, it would not be practical to present them all. Imagine clicking through 30 licenses during an install. There would be no reasonable expectation that the installer had actually read the text of all of those licenses, which defeats the purpose of click-wrap. The same issue comes up in other venues, such as download sites, and applies to all other distributions, Red Hat, and so on, although most distributions are smaller than Debian and may have employees doing the packaging. The practical alternative is to present _once_ that there are licenses, that they in general disclaim warranties and that thus you should have no expectation of warranty, where you can find them, and the fact that since you have source you can perform your own due diligence. This seems to run counter to the purpose of drafting terms. Only if you are taking a vendor-centric
Re: Legal soundness comes to open source distribution
My response is yes. In fact, the OSD recommendations I am developing as part of the OSD Model Code proposal will include a suggestion on which article and what language might be best to accomplish this. I am hoping to post the complete proposal during the fall semester. - Rod Rod Dixon, J.D., LL.M. Visiting Assistant Professor of Law Rutgers University School of Law - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 01, 2002 11:18 PM Subject: Legal soundness comes to open source distribution At the July OSI board meeting last week, we approved the Academic Free License (think MIT/BSD/X11/Apache with a patent grant) and we sent four licenses back for reconsideration. Here's the hitch: we were asked to approve a license which includes a requirement for click-wrap. The submittor had already been asked if that requirement was a necessity. She said yes, because of various legal precedents. We consulted a few people and yes, it looks like a license without click-wrap is weaker at protecting your rights. So, folks, the lawyers are coming. The time is coming when you won't be able to distribute software unless you have presented the license to the user and their assent is necessary to access the software. Even free software. Our industry is maturing and we need to be more legally careful and rigorous. 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! -- -russ nelson http://russnelson.com | New Internet Acronym: Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | IANAE Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | I Am Not An Economist -- 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: Legal soundness comes to open source distribution
I agree with David that click-wrap (or click-through or web-wrap...) generally denotes what he describes as download-wrap licenses. Leaving aside the matter of use-wrap licensing, courts seem to viewing click-wrap licensing in two forms: the passive license and the active license. What is at issue, often, is electronic contract formation. In other words, did the user manifest consent to the terms of the license? In this regard, passive licenses or click-wraps that do not require the user to actually click a dialog box, slect something on a pull-down menu, or some other user interface input demonstrating I agree are less likely to be viewed as licenses that offer clear evidence that a user may have consented to the terms of the license. In my opinion, it is far better that this potential problem is fixed or avoided than ignored. Consequently, I think the OSD should include something on the click-wrap issue in its next iteration. With regard to the comment about whether it matters if the user sees the license, I suppose in a strictly technical sense it is true that manifestation of consent does not necessarily mean that licensors must prove that users must actually have seen the license to be bound or denominated a licensee, but a movement that prides itself on being generally consumer-friendly might be inclined to adopt a practice that more likely than not ensures that potential licensees read the copyright license to which they are bound. Therefore, I would suggest that in response to the prevailing legal climate and as a policy matter, the click-wrap issue is important enough to be considered in the next version of the OSD. - Rod [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: David Johnson [EMAIL PROTECTED] To: Russell Nelson [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, August 02, 2002 12:49 AM Subject: Re: Legal soundness comes to open source distribution On Thursday 01 August 2002 08:18 pm, Russell Nelson wrote: The submittor had already been asked if that requirement was a necessity. She said yes, because of various legal precedents. We consulted a few people and yes, it looks like a license without click-wrap is weaker at protecting your rights. So, folks, the lawyers are coming. Does that mean we should get to working cleaning out our flintlocks :-) Seriously, the problem here is the term click-wrap. There are two types of license presentation in use today that are referred to by this term. The first is where the license is presented during installation or first usage. The second is where the license is presented before one can aquire the software. I'll refer to the first as use-wrap and the second as download-wrap to avoid confusion. I have few problems with download-wrap if the only way to aquire the software is to click I agree. The user has no rights with regards to software which they do not possess. The problem is with use-wrap. By the time the user sees the license terms, they have already aquired the right to install and use the software, particularly so if they have aquired the software through a commercial transaction. If the license merely grants additional rights to the user, then use-wrap is no great problem. But if it lessens any rights already possessed by the user, then use-wrap is a serious wrong. I would have no problems with an Open Source license that mandates the use of download-wrap. But the mandate of use-wrap should never be part of an Open Source license. Just because the heathens do it doesn't mean we should as well. The time is coming when you won't be able to distribute software unless you have presented the license to the user and their assent is necessary to access the software. Even free software. Our industry is maturing and we need to be more legally careful and rigorous. First, this sounds like download-wrap, so the problem is not great. However, I still doubt that it is going to be necessary for most Open Source Software. The only rights the user will have to modify, distribute and copy the software must come from the license, and since those activities are normally the only activities regulated by OSS licenses, it does not matter if the user sees the license or not. The only potential problem is with the presentation of the warranty disclaimer. By all means, commercial software should be presenting the disclaimer to the user, whether by download-wrap or use-wrap. But a lack of merchantability disclaimer for non-merchanted software is not, in my non-lawyerly opinion, much of a problem. Besides which, I'm pretty certain that the primary purpose of proprietary click-wrap licenses is not to disclaim warranty. -- David Johnson ___ http://www.usermode.org pgp public key on website --
RE: Academic Free License
Thanks Larry, in light of your responses, I think the AFL achieves the goals you set out to accomplish. - Rod On Tue, 25 Jun 2002, Lawrence E. Rosen wrote: Hi Rod, Thanks as always for your cogent questions and comments. Well worthy of a reply Larry, I like the simplicity of the AFL, but there are two general issues I would like to raise as questions more than an expression of an opinion. 1) Why copyright the license text? Assuming that the text of a license is copyrightable, does the accompanying notice introduce confusion? Aside from the well-intentioned insistence on the adoption of the list of conditions, for distribution of software with the AFL, is it consistent with the objectives of open source to constrain (withhold permission for) modifications of the license? I have always puzzled over whether a suit for copyright infringement of the license text accomplishes anything that a software license does not accomplish in the context of open source??? I personally have no intention of ultimately holding copyright in that license. Perhaps an organization like Creative Commons, or an academic licensing organization, might accept copyright assignment from me of the Academic Free License (or an improved version of it). What I am concerned about is having multiple versions circulating around the web while we discuss and improve upon this draft. There is no effective means other than the copyright law to prevent people from circulating non-redlined modifications of my draft license that otherwise might become self-effectuating by a simple notice in software. So, which draft of the Academic Free License is currently the official one? Mine! under the authority of the Copyright Act. Assuming that the text of a license is copyrightable You may well raise that important issue. Copyrightability is a problem for any document that purports to both have utility (and legal effects) and is expressive. Can a software license be copyrighted? Can a set of rules for calculating your income tax? Can a specification for software be copyrighted if the only purpose of the document is to permit implementation of that specification? Can a published technical standard be copyrighted so as to prevent implementers from modifying their programs? Can a standard that is adopted as a statute by reference be copyrighted? (See the important Veeck case.) Why don't we take these questions to the cni-copyright list where attorneys can debate this to their hearts' content? In the meantime, I elected to claim copyright in the Academic Free License to guarantee some semblance of version control while people suggest improvements. 2) The AFL seems to be targeted for those licensors who need an open source license from Original Licensor -tolicensee, but not necessarily subsequent end-users. Is this correct or, does the 2 list of conditions clauses ostensibly impose a copyleft constraint? The Academic Free License is not intended to impose copyleft. I make no political statement here. I would personally probably prefer a license that imposed source code reciprocity for all derivative works. What I was trying to do in the Academic Free License was merely to clean up some problems I perceived to exist in the BSD, MIT, UoI/NCSA and Apache licenses. Under the AFL, Software is fully licensed for the creation of derivative works that may be either proprietary or open source. The original copyright notices in the Software must be displayed on all copies and derivative works. Other than that, there is no requirement to publish source code of derivative works (or of copies). The license is intended to be available directly from the licensor to anyone who obtains a copy of the Software. A sublicense is not required. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: UnitedLinux and open source
Begun, this free software war has!;-) rod On Fri, 14 Jun 2002, Russell Nelson wrote: John Cowan writes: The above program is not free software: see http://www.gnu.org/licenses/license-list.html#ArtisticLicense . You are presuming two things: 1) that a lack of acceptance is the same thing as rejection, and 2) that RMS defines free software. The term was in wide use before RMS came along. Anybody can call anything free software. Microsoft gives away free software (and calls it such). Free software is essentially meaningless, which is why OSI Certification of Open Source Software exists. Here's what I call free software: If you can get the source code, AND If you can make any changes you want to the source, AND If you can create binaries, AND If you can redistribute your changes and binaries, THEN It's free software. Please note that the GPLv2 does not provide all those freedoms. In my book, the GPLv2 isn't a free software license, and the GPLv3 that I've seen is even less of a free software license. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | Plan to be surprised. 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Surprise can not be planned for. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Be open to new light. -- 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: Uniform terminology (Re: UnitedLinux and open source)
I agree that there should be wide-spread agreement on the use of terms to describe important open source software and free software concepts, but that this should be done so more as a public relations matter than as a contract enforcement necessity. When adjudicating a breach of contract a court has a duty to interpret the terms of the contract, not the label ascribed to the contract. Hence we ought not hope that courts infer implied terms based on contract labels. If a litigant must rely upon the designated label of the software license (such as GPL, LGPL, or some other designation) as its primary means of providing a court with interpretative guidance of the contract terms, then the drafter of that license or the litigant is likely to be in trouble. Moreover, if you were suggesting that the implied terms doctrine might be a valid litigation-avoidance strategy, I strongly disagree; in my view, it is unwise for a software developer or vendor to hide behind contract labels to avoid genuine contract formation issues. Some might say that open source licenses are not likely to be governed by common law contract principles or commercial law, but, if that will be the case, I still doubt that courts will be hampered when interpreting an open source software license that extends no further than a grant of a copyright interest; under such circumstances, the court should, as they often do, rely upon well-established copyright concepts. As I see it, the standardization of open source terms could be most beneficial in the context of end-users, media, and members of the public...whom might find open source terms confusing or contradictory. Standard terms could help in expressing what open source is about in a systematic manner. Rod Dixon, J.D., LL.M. www.cyberspaces.org [EMAIL PROTECTED] My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Mahesh T Pai [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: David Johnson [EMAIL PROTECTED] Sent: Sunday, June 09, 2002 11:45 AM Subject: Uniform terminology (Re: UnitedLinux and open source) It is time for the software community to arrive at a consensus on terminology used in licenses. We should cease to behave like characters in Alice in Wonderland (each word shall mean exactly what I choose it to mean/nothing less, nothing more) There can be serious problems, especially in courts otherwise. What follows are a few reasons, as to why the software community should agree on standard terminology used in licensing terms. A few hundred years back, when international trade was still in its infancy, the merchants and traders used to have separate tailor-made contracts for each transaction; each with its own (and different terms). This may be compared to the the present day practice where a creator of a software package having a separate licensefor each different package, and frequently, different licences for different versions of the same package. (well, almost). Later on, the merchant community realised that tailor made contracts have much in common, and a classification is possible. They agreed on some standard terminology, and the benefits are there for all to see. For example, modern trade refers to a CIF (Cost, Insurance, and Frieght), or FoB (Free on Board), etc. types of contracts. The names may be short, but, the legal systems all over the world attribute to the parties several terms, which, if reduced to writing, may often cover several pages. Standardisation in more complicated scenarios is achieved through organisations like UNCITRAL. I guess that software licences are right now in the midst of a similar process of standardisation. Already, there is some kind of standardisation in software licences. This certification process, and the terms and phraseology used by software developers/vendors like this package is released under the ... and terminology like freeBSD type license, Mozilla type public license, GPL, LGPL, etc are examples of such standardisation. Few years from today, there time will come when the courts will fix liabilities on basis of names of the software license. This means, if it is shown that you knew that you are using software covered by the GPL, then, irrespective of whether you discussed or even actually knew of the actual detailed terms, the court will fix responsibility on the basis of implied terms doctrine. The way terms are implied now, based on names of contracts. (like FoB, CIF, etc). This is possible only if there is a industry-wide agreement on terminology. Therefore, it is time for us to set aside such elitist mentalities, (if it exists at all) and settle on some standard terminology. With Regards, Mahesh T Pai. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: an open source model code: osd 2002
Thanks David. Your points are helpful. We will add a definitions section and include a definition for free software. With regard to the model code for Article 2, we would like to amplify the meaning of source code in a practical sense rather than a conceptual sense. In doing so, it might be helpful to state that the source code should be in a form that others can actually use. Hence the requirement that the code be doucmented or well documented. As you state, there is a good deal of code that is not only poorly documented, but extremely cryptic. If we don't set some minimal standard here, then the open source code requirement is form over substance. What good is the source code if programmers can hardly read it? In some respects, the argument that source code is speech depends on the assumption that source code not only expresses ideas, but is INTENDED to do so. As we think about enhancing the OSD, whether the source code provided by the licensor is provided in a form that demonstrates the source code was written not to just run machines, but to express the ideas it contains so others might modify the code for innovative purposes should be an important factor for OSD compliance. I agree that providing well documented code is one way to achieve that goal and, perhaps, it is an onerous objective. what I am unsure of is whether we should be satisfied with the status quo or whether we should amplify Article 2 with something more than just saying the source code should not be deliberately obfuscated. Poorly expressed source code need not be deliberately obfuscated to end run the objective of what it means to provide open access to the source code. Agree? Rod On Wed, 22 May 2002, Charlie Root wrote: Rod Dixon wrote: Please take a moment or two to download a draft of the framework for our work on the OSD. We have only posted Article 1. We would like to hear your thoughts on the framework. It is our view that a model code is the most helpful framework for augmenting the Open Source Definition (OSD), but we would like to hear what the folks on license-discuss have to say. 1-2.1: The terms free software and open source are intermixed. There is nothing inherently wrong with this, but the term free software has not been previously defined. 2-2: The code should be well documented. I hesitate at this one. Although I strongly favor well commented source code, there are innumerable examples of poorly documented source code in the Open Source community. It would be very hard to distinguish code that is poorly documented because the writer is ignorant, lazy, or arrogant, from code poorly documented as an excercise in obfuscation. David -- 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
