Re: [License-discuss] Copyright Free Software Foundation, but license not GPL
Karl, Robin means that the work is dedicated to FSF and placed under a BSD or MIT license. These are compatible with the GPL and FSF is fine with it. Thanks Bruce On 4/17/2013 10:04 AM, Karl Fogel wrote: Robin Winning robin.winn...@cyaninc.com writes: I am a contracts manager at software company, and in addition to doing contracts, I now find myself reviewing the licenses associated with the open source packages my company has acquired. I have become quite familiar with the GPL/LGPL/AGPL suite of licenses, as well as the other, permissive licenses: MIT, BSD, etc. Here's my question: quite frequently, the programmer makes the Free Software Foundation the copyright holder, but then attaches a license that is not in the GPL family. Is that a valid combination? It's technically valid, in that the FSF (as a non-profit corporation) can hold copyrightable assets under any licenses it wants. But it's likely usually a mistake, in the sense that the FSF probably has no idea these works are being donated to it under these non-GPL licenses, and because there is usually no need to make the FSF the copyright holder -- except in certain cases where the FSF is actually involved in the development or maintenance of the software, in which case they would have discussed this with the programmer and, in most cases, the FSF would have insisted on one of the GPL family of licenses (though there are some exceptions to that). I'm not a lawyer and this is not legal advice. There are plenty of people who can give you real legal advice if you need; we may be able to help you find those people. In the case of ncurses, I was able to research and determine that when they assigned their copyright to the Free Software Foundation, the FSF gave ncurses a special carve-out allowing them to use a permissive license. However, all the rest of the open source packages I have come across that assert Copyright Free Software Foundation but are accompanied by non-GPL licenses do not seem to have that sort of special arrangement. Nice researching (re ncurses)! Maybe I'm overthinking this, but it seems contradictory to me, and I don't know how to characterize the license in terms of permissive or restrictive. It's not contradictory, but it's probably often a mistake by a programmer who thinks that putting a license's terms on some software implies that the software's copyright must now be held by whatever entity wrote that license -- which, of course, is not the case and not the norm. -Karl ___ 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: [License-discuss] what would de-listing of licenses look like?
Ben, Yes, my testimony was to establish the economic interest in attribution of Open Source software. However, it's going too far to say that the license terms were not a problem. The judge's finding starting at Plaintiff's Claim Sounds in Contract, Not Copyright is that the Artistic License 1.0 text is self-invalidating. It's not so clear that a better drafted license would have reduced us to basing the appeal on the economic value of attribution alone. Thanks Bruce Ben Tilly bti...@gmail.com wrote: I do not believe that you are fairly describing the cause of what happened. At issue was not the drafting of the license, it was the fact that it was the first time that the legal idea of follow the license or we sue for copyright had ever been tested in a US court for software that had been given away to the world on generous terms. The judge's ruling was based on the fact that software was given away, for free, with no expectation of a reward. Therefore there was no loss in its being appropriated by a third party. The fact that the software was available to everyone on generous terms meant that there was no cause under copyright law. The judge ruled that the license could be viewed as a contract, but of course the basic elements of a valid contract were missing and so you couldn't sue under that either. If the hobbyist had used the GPL as a license, the same facts would have existed, and the judge could easily have ruled the same way. In fact the reason why the case was so important is exactly because the precedent undermined the enforceability of all open source licenses where no contract existed. For verification, the judge's ruling and reasoning are available at http://jmri.sourceforge.net/k/docket/158.pdf. On Wed, Mar 6, 2013 at 10:09 PM, Bruce Perens br...@perens.com wrote: The license isn't really standing up when you have to file a writ of certiorari after a judge throws his hands up at the license text and pronounces it to be tantamount to a dedication to the public domain. That was no easy appeal to win, and the Open Source developer was seriously damaged by the cost and the 5-year process. It cost me a good deal of time and work too. A license that stands up would, I hope, require much less time to dispute and would be parsed as intended by the court. So, what the Artistic License 1.0 made much more difficult for the poor Open Source developer is exactly what I'd like to fix. And yet the Artistic 1.0 is not the one I thought of first upon seeing this discussion in progress. We have much worse. Thanks Bruce John Cowan co...@mercury.ccil.org wrote: Bruce Perens scripsit: 1. They are ambiguous or likely to perform in court in unexpected ways, should they ever be litigated. And thus they are harmful to their users. De-listing is a prompt to the organization that originally created the license to replace it with an accepted license or to submit a new version with greater legal competence in its construction. These would be the crayon licenses, mostly, those written without legal counsel. And yet the Artistic License 1.0, which is riddled with ambiguities and a prototypical crayon license, is one of the few that has been tested in court -- and stood up. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] what would de-listing of licenses look like?
We appreciate what we got. But my point is that maybe with a well written license Victoria Hall would have finished the case on her own in the lower court. Lawrence Rosen lro...@rosenlaw.com wrote: I note that the plaintiff in the Jacobsen v Katzer case won on appeal to the CAFC. So reading the judge's decision in the district court is kind of irrelevant at this point. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] what would de-listing of licenses look like?
The justification for de-listing presently accepted licenses is that: 1. They are ambiguous or likely to perform in court in unexpected ways, should they ever be litigated. And thus they are harmful to their users. De-listing is a prompt to the organization that originally created the license to replace it with an accepted license or to submit a new version with greater legal competence in its construction. These would be the crayon licenses, mostly, those written without legal counsel. 2. They don't comply with the OSD and were accepted in error. 3. They are both redundant /and /rarely used. Those are the only justifications. You don't get to de-list something because you don't like its politics. I think you need to have a committee review a proposal to de-list, with arguments from the submitter regarding the problems in the license, and with advice from an attorney on whether the suggested problems are really problems. Thanks Bruce On 03/06/2013 08:23 PM, Luis Villa wrote: On Wed, Mar 6, 2013 at 11:48 AM, Richard Fontana font...@sharpeleven.org wrote: The Frameworx license is one of those OSI-approved licenses that I believe was approved in haste. If OSI had such a procedure, I would recommend that the Frameworx license be reviewed for de-listing. Any recommendations on what such a process would look like, Richard? I'm not super-enthused about the idea, but don't want to rule out anything without at least some discussion. Luis ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss attachment: bruce.vcf___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] what would de-listing of licenses look like?
The license isn't really standing up when you have to file a writ of certiorari after a judge throws his hands up at the license text and pronounces it to be tantamount to a dedication to the public domain. That was no easy appeal to win, and the Open Source developer was seriously damaged by the cost and the 5-year process. It cost me a good deal of time and work too. A license that stands up would, I hope, require much less time to dispute and would be parsed as intended by the court. So, what the Artistic License 1.0 made much more difficult for the poor Open Source developer is exactly what I'd like to fix. And yet the Artistic 1.0 is not the one I thought of first upon seeing this discussion in progress. We have much worse. Thanks Bruce John Cowan co...@mercury.ccil.org wrote: Bruce Perens scripsit: And yet the Artistic License 1.0, which is riddled with ambiguities and a prototypical crayon license, is one of the few that has been tested in court -- and stood up. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] what would de-listing of licenses look like?
It isn't the least bit difficult to diagnose when no lawyer was involved in drafting a license. At the start we had an excuse because no lawyer would help us. The only excuse those licenses have today is disinterest in fixing the problem. Luis Villa l...@tieguy.org wrote: On Wed, Mar 6, 2013 at 10:15 PM, John Cowan co...@mercury.ccil.org wrote: Bruce Perens scripsit: So, what the Artistic License 1.0 made much more difficult for the poor Open Source developer is exactly what I'd like to fix. And yet the Artistic 1.0 is not the one I thought of first upon seeing this discussion in progress. We have much worse. Please itemize. I don't think we do anyone any favors by having extensive public discussions of the legal/drafting weaknesses of existing licenses, so please don't. The point stands that some licenses are poorly drafted, and that in a perfect world where we could easily identify and evaluate such licenses, we would probably no longer publicize/endorse them. That said, as Richard pointed out, this is an extremely difficult issue to evaluate. It is inherently subjective, and a matter requiring expertise. Given that, I see no evidence that OSI (or anyone) could perform it in a reasonable, objective, efficient manner, so I'm not very interested in pursuing it. Luis ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] List moderation and CoC enforcement [was Re: proposal for revising (and making relevant) the code of conduct]
* *On-list*: discussing conduct on-list, either as part of another message or as a standalone thread, is always acceptable. Pretty often this sort of discussion has triggered an instant flame-fest. And I have to agree with John. If there's a breach of civility, direct confrontation is unlikely to solve it. It's best if moderators actually moderate. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License which requires watermarking? (Attribution Provision)
On 01/01/2013 02:08 PM, Ken Arromdee wrote: Some people use ordinary GPL on libraries with the intent of crippling competing commercial reuse (since any competitors have to release their source and competitors wouldn't want to do that). Is the GPL also considered unfree when applied to libraries? No. Be careful to avoid confusing the creation of derivative works with use, which are two separate rights under copyright law. And although badgeware should in general be rejected, crippling commercial reuse is the wrong reason to reject badgeware. The reason to reject it is that it complicates simple use. We'd really like it to be possible for people to use software without the need for some compliance process. That line is crossed when you create a derivative work. If you have to be sure to put badges on your web site for some set of software you use, possibly a very large set, then you have to keep track of the software and its license terms just to use it, and simple use is no longer simple. There is also no limit to the potential number of badges you might have to display. attachment: bruce.vcf___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License which requires watermarking? (Attribution Provision)
Would that we all had infinite budgets for going to court :-) But short of having them, many businesses choose, quite sensibly, to err on the conservative side of this sort of issue and will honor the license whether or not a court would make them do so. This will also get them through an MA intellectual property audit in better shape than otherwise. I do know a company that spent money, including on me, to argue just this sort of issue recently. They spent more than most businesses would be able to endure. Thanks Bruce On 01/01/2013 05:23 PM, Lawrence Rosen wrote: Really? That's not wise. How would the choice of license affect the *legal* determination of whether the resulting work is or is not a derivative work for which source code must be disclosed? attachment: bruce.vcf___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Adobe DNG SDK License Agreement
The documentation license isn't OSD compliant, it limits number of copies and disallows derivative works. The software license looks like it could be. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] plain text license versions?
On 09/10/2012 01:38 PM, Rick Moen wrote: Quoting Karl Fogel (kfo...@red-bean.com): It's better to question reasoning than motivations, on this list and probably most others. Karl, I question why you didn't call a halt when the discussion was obviously becoming a testosterone contest past the point of any useful content. OK, you'll never have the time to moderate. That's fine. What isn't fine is that you don't find someone else to do it. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] plain text license versions?
On 09/07/2012 11:24 AM, Rick Moen wrote: I don't think you are approaching this discussion with a serious attitude, attention to the subject, and/or a sense of perspective. Is this really a serious discussion? It sounds to me more like a contest of how many silly things some of us can get away with doing or advising our clients to do, in avoiding a requirement that is brain-dead simple and no sweat for anyone to fulfill. Some lawyers and IP specialists enjoy sophomoric discussions of legal theory that has little value in real life. I guess they can blow off steam here, at least until it gets /too /annoying. I hope they don't waste their clients time on such things. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] licenses and software in books
So, I have 24 titles in my old book series that have mostly dealt with this issue. Conveying the license text in print form is not an odious requirement. There are 200 to 400 pages of tutorial material, to dedicate two to a small-print rendition of GPL is no hardship. Nobody ever requested the source code on a CD. Where appropriate, it was available for download. If anyone tries to contest that download is not an appropriate medium under the terms GPL2, they are doing it to be difficult, not to get the source. We would have had the means to deal with such a person. In general, all parties went to the project (for example, Samba) for the source code. A book isn't a computer program. While we could fulfill the GPL terms easily enough, we could have also made a case that the program inclusions in the book were quotations in a critical work, and should have been handled as such. We had no power to issue waivers, since we weren't the copyright holder of the software. Thanks Bruce On 09/06/2012 02:55 PM, Rick Moen wrote: Quoting John Cowan (co...@mercury.ccil.org): The difficulty is that text often winds up in printed books, and then you either have to distribute a CD with the book containing the editable source, or be prepared to issue such CDs for no more than the cost of distributing them. Both are expensive and awkward activities, and neither is well-supported by the printed-book sales channels that exist. Emphasis added: _Um, hello? Waiver._ ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] plain text license versions?
On 09/06/2012 03:07 PM, Luis Villa wrote: Custom waivers (particularly for something trivial like this) are just another form of the same mess. Posit that I am creating a version of the old Lyons Unix book, containing the Linux source code. How many copyright holders must grant me a waiver? Is the answer the same across all jurisdictions? It is easier to print the GPL than it is to even /start /analyzing questions like rights in a compilation vs. rights in a collective work. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] plain text license versions?
Larry wrote: I think it would be FAR more useful to have a simple license statement in the source tree of each program that points to the OFFICIAL version of that license on the OSI website. You are very optimistic regarding the longevity of OSI. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] relationship between opensource code and the copyrighted works it produces?
On 09/05/2012 08:19 AM, Karl Fogel wrote: My understanding (I am not a lawyer) is that copyright only applies to creative works -- specifically, to works resulting from human creativity, or to the portion of a work that results from human creativity. This is why, for example, the information in a phone book cannot be copyrighted, but a song reciting those numbers could be. Or indeed, a work containing a creative form of organizing or presenting the phone numbers could be copyrighted, while the data could be /extracted from it/ and would not be covered by copyright. There is one thing to watch out for: do your tools embed the copyrighted work of others in your work? It used to be that Inkscape /did, /and the same has been true for other tools.//In the case of Inkscape, it placed a raster texture called Sand in SVG works, and that texture was under Creative Commons Attribution 2.5 . Wikipedians were uploading SVG images to Wikipedia and dedicating them to the public domain, but they had this embedded texture that was /not /public domain. I think that Inkscape has since been cleaned up. You can see the Wikimedia Commons discussion at http://wikimedia.7.n6.nabble.com/Licensing-for-textures-within-SVG-files-td1473913.html Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] plain text license versions?
Arguing the merit of plain text vs. HTML is just Lilliput v. Blefuscu. Provide both, for different reasons. Plain-text is a better source for cut-and-paste operations. In general plain text divides the actual license text from any attached commentary, making it clear which is which. There is no universally-accepted standard for indicating the character set of plain text in the data, rather than in an external indication such as the HTTP Content-Type header. There is an assumption, sometimes wrong, that plain-text is ASCII. ASCII isn't capable of representing non-Latin character sets. Web servers often misrepresent the character set of plain text, since the content-type indication is set in an external file rather than the content itself. HTML provides some desirable features: Web page producers are more conscious of the need to represent the page character set accurately. It is possible for a web site to enforce that all pages be UTF-8, and for most national characters to be represented accurately. However, not all sites are this well-disciplined, and there are regional issues such as the Han unification in UTF-8 that can cause an undesirable rendering of a character for languages like Japanese. In logogramic languages, getting a character wrong in a legal document is much more likely to cause an unintended change of meaning. This is not to say that plain text could render these characters at all. HTML provides internal anchors which can be referenced by external documents, providing a way to link to a particular paragraph (or finer, if provided) from an email or article. HTML provides a wealth of methods for rendering commentary internal to the document. It can be called out by changes in font, color, or position. It can be hidden and revealed using javascript, CSS, or document structure, and selected by hover-over or click. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] OSI approved license without original license and reproduction of notices required in redistributions?
There are two different fundamental forms of copyright regime. One is based upon the right to copy, and the other is based upon the moral rights of authors. A number of European nations, for example, are moral rights regimes, while the U.S. is based upon the right to copy. However, even in the United States, there is moral rights law, but it is often in state law. For example, the California Art Preservation Act. http://en.wikipedia.org/wiki/California_Art_Preservation_Act Thanks Bruce On 07/16/2012 07:16 AM, Johnny Solbu wrote: The reasoning behind it is to give credit to the authors. To ensure that happens, the law make it as a statutory requirement. The author cannot waive this right. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Is it possible to use code or knowledge from Manuals/Wiki/Blog/Resonal pages?
For my legal protection, don't treat this information as if it came from an attorney 'cause I'm not one. There are various free attorneys who help Open Source projects, you can ask them if necessary. On 07/10/2012 06:30 AM, Oleksandr Gavenko wrote: Is it possible use knowledge I get form these sources? In case of patent I think no... Copyright would allow you to do so. The generally-used strategy regarding patents for an Open Source project is to proceed on the assumption that there isn't one until you are informed otherwise, and then ask legal counsel for advice. If you are some deep-pockets company, the strategy is different but you would also have your own attorneys to advise you. And it also depends upon the purpose. Publishing information about a patented process doesn't infringe, using the process potentially does. I don't understand this. For example I use copyleft licence for my program and Wikipedia use copyleft (share alike) license for its content. I got conflict? Which copyleft license? There can be copyleft licenses that are not compatible with each other in the specific terms of the license. Even GPL2 vs. GPL3. Are all of the pieces clearly under the same license or compatible licenses? Sometimes it is a lot of work to figure that out. And be sure to attribute the pieces correctly, and provide information about their licensing. Wikipedia free for knowledge but non-free for use it in free software with different statements for freedom? Generally what you find in Wikipedia is an explanation of an algorithm. This algorithm isn't copyrightable, but the specific way it is written can have copyrightable parts. So, the easy way to deal with this is to look at how it works and write your own version. The more complicated way would be to develop an understanding of the functional vs. expressive dichotomy in copyright law, in which case you would start by reading the decision in CAI vs. Altai. Interesting also case of non-free references and standards. They define a coupe of constants, without which you can't develop certain types of protocol. You need to copy a large part of constants and adapt many symbolic names for these constants... Is that valid? We just had a re-iteration of the functional vs. expressive debate in the Oracle v. Google case regarding Java. It made it even more clear that the functional part of the Java specification was not copyrightable. You get to use the constants, function names, etc. The problem would not be copyright, but patents. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL linking exceptions
On 07/05/2012 06:30 PM, Chris Travers wrote: Generally RMS seems to think this is not permissible, and most other people outside the FSF don't listen. It is not permissible to modify the GPL text directly. That restriction has teeth. However, I can't think of a legal mechanism that could be applied to prevent exceptions to the GPL that are in separate text. It would be different if there were contractual restrictions connected with the use of the GPL text. But there are none. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages
On 06/11/2012 12:18 AM, Henrik Ingo wrote: To be clear, NuSphere did not embed MySQL in their product, rather they embedded closed source components into MySQL Per Eben's testimony, the Gemini storage engine, using the MySQL API for storage engines. Which would be a funny relevation after a couple decades of successful GPL enforcements and several companies building a successful business on a more strict interpretation of GPL / the law. I'm not going to advise people that they can mix GPL and proprietary software with impunity. And I will continue my own dual-licensing business. But I'm not going to be certain of my ability to prevail in court. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages
On 06/11/2012 12:52 AM, Rick Moen wrote:
{scratches head} I think you must somehow be massively misreading what
I said. Perhaps you thought I'd expressed a view about using an API
(somehow) creating a derivative work? I didn't say anything of the sort.
It's regarding your statement:
it doesn't seem likely to cast light on other areas of copyright
law. In particular, it cases none on what suffices to create a new
work and what is a derivative work.
The point is that there's not /anything else/ in that body of law that
would make the proposed work derivative.
attachment: bruce.vcf
smime.p7s
Description: S/MIME Cryptographic Signature
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages
On 06/09/2012 01:53 AM, Rick Moen wrote: Read caselaw. I'm done. I'm glad Rick's done. There is a good chance that you, not Rick, are right. Recent case law is that APIs are bright lines between separate works and that connections across APIs do not create derivative works. And this is regardless of the way software is linked. Go read the recent finding in Oracle v. Google, it only reinforces that point. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] license for code used for scientific results?
On 04/30/2012 08:36 AM, Kevin Hunter wrote: I'm not looking for responses along the lines of you can't enforce it so ignore it. I'm very specifically focused on the licensing aspect. Hi Kevin, People who understand what they're doing won't generally write a license that can't be enforced because it makes them look stupid. What you need is a contract, not a license. In general the Open Source licenses only deal with copyright, and you can't compel some action unrelated to copyright, like publication of research results, with a simple license. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] license for code used for scientific results?
On 04/30/2012 10:13 AM, John Cowan wrote: Conditional copyright licenses are most closely analogous to conditional licenses to enter land :-) Well, this is more than a bit of a stretch, but I can argue it this way if you like. Of course, in civil law land, licenses are contracts, period. The difference is in how they are enforced. To enforce a license to enter land, the plaintiff can ask for criminal action on basis of tresspass, tresspass being a greater offense than breach of contract. The defendant claims there was a license and the plaintiff shows why one did not exist in those particular circumstances. Similarly, the plaintiff sues for copyright infringement rather than breach of contract, and doesn't set out to prove consent and otherwise build a contract case. The only value in licenses is that they can be enforced. If you don't care about enforcement, publish what you want as a guideline, and live with the fact that not everyone will follow it. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] license for code used for scientific results?
Kevin, If you want to make everything fit in the framework of Free Software, you can get a lawyer for free through the Software Freedom Conservancy, and there is a well-established history of them going to court for their clients. But you have to fit in their parameters of Free Software. It's worth discussing with Brad Kuhn. Maybe he'll see a way. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Is the old style MIT license a Free Software license
On 03/13/2012 12:31 PM, Karl Fogel wrote: I believe the without fee here refers to payment to the original licensor Yes. The statement is permission [to exercise a number of rights] is hereby granted without fee. If it were permission [to exercise a number of rights] without fee is hereby granted, the answer would be different. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]
On 03/09/2012 11:41 AM, Rick Moen wrote: As an afterthought, OSI _might_ decide to adopt a policy that all new licences should at least not disclaim/waive any implicit patent waiver that might be created against patents held by licensor (estoppel defence) -- or establish some other minimum requirement on that subject. ... If OSI elects to impose such a minimum requirement, it wouldn't necessarily need to amend OSD, but rather could find that OSD#2 implies it. In other words, do what has previously been done, but consistently. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC0 incompliant with OSD on patents, [was: MXM compared to CC0 ]
On 03/08/2012 12:51 PM, Rick Moen wrote: the notion that anyone who thinks new licences ought to address patent issues in some way is logically obliged to try to revoke BSD licence's OSI Certified status (or formally deprecate the licence) is absurd, and we could have done without those and similar time-wasting polemics. And they should stop now, please. (3) Irrespective of CC0's merits as a fallback permissive licence, the document's fundamental reason for existing is foolhardy: the delusional belief that creative works can be safely magicked into the public domain despite a worldwide copyright regime, and the equally delusional belief that it's even desirable to try (and thereby, among other problems, have no protection against warranty claims). Which makes it not tremendously worthy of the continuing effort to get it approved, IMO. most of us agree that it's useful for newly crafted licences to permit at least implicit patent defences if not explicit patent rights, and that modern licences that address such matters are, all other things being equal, a better idea than ones that don't DiBona called for it to be explicit in licenses going forward, I agree. Let's not ignore how the times have changed and what we have learned since starting with Open Source. -- but that saying that is miles away from saying BSD should be formally deprecated. To be put in whatever hole is reserved for all if you do this, you must also shoot yourself in the foot arguments. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] combining GPL and proprietary software - was: CC withdrawl of CC0 from OSI process
On 03/01/2012 11:57 PM, Chris Travers wrote: Ok, so part of avoiding lawsuits is to avoid areas where folks think they can sue about. Not quite, because neophytes think they can sue about anything. Sometimes lawyers cooperate in this, because they think the victim will settle or otherwise change their behavior without ever getting near a court. So, it has to be an area where there is not such a bright line that litigation would immediately fail and that any competent attorney would know that. As an example, the abortive attempt of Astrolabe to sue Olsen over the timezone database had the obvious flaw that it attempted to assert copyright law over facts like legislative changes to daylight savings time. When the defendant showed them a fully-written pleading for a Rule 11 sanction, Astrolabe withdrew. No gray area there. So the FSF's statements are important here Only because they have good counsel and have successfully enforced the license many times. In contrast, Linus Torvalds' various confusing and conflicting mailing list statements about what is OK and not OK under the GPL were not something you could rely on. I think he now knows not to make them. I can tell you that if I ask two different lawyers with different ideological views regarding free software what the implications of mixing BSD and GPL3 files in the same project, I get two different answers. The fact that there are courts is evidence that lawyers frequently disagree. However, you should resist the temptation to waste your time on the areas of contention. They are known and can be engineered around. There are cases where no amount of isolation will protect you from having created a derivative work. For example, suppose I write a graphics driver which recognizes Doom's OpenGL calls, and transforms them in some interesting way. We have cases about just this that you can read. They are Goloob v. Nintendo, and Micro Star v. Formgen. But you are really far now from combining GPL and proprietary software, which doesn't present the problems of transforming visual output which is itself a creative work. What I am saying is there's a difference between you saying Linking is legally dubipus under the GPL and me saying As far as LedgerSMB is concerned, we interpret the GPL not to restrict linking and mere use of API's, but believe that inheritance may be run into trouble. At least given that I am more or less the de facto leader of the LedgerSMB project. The first is an attempt to describe the license in the abstract. The second is a representation on behalf of a project as to what license rights we believe we are granting. As I understand it, these are very different statements Yes, but if Dieter wished to enforce his license in a way contrary to your sentiment, your statements would have little meaning because his contribution is independent of you and your policies and precedes your involvement. Even in the case of other developers who are concurrent with you, they are either independent copyright holders or share-holders in a collective work, and haven't ceded you the right to represent their legal interest. If they gave me, as an expert witness, the task of showing your statements to be naive and unreliable, it wouldn't be much of a problem. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] due diligence - was: CC withdrawl of CC0 from OSI process
It is indeed the case that the failures I see are in companies rather than among charity developers. However, it's a stretch to state that they already pay for lawyers! I sometimes get paid to read their depositions and explain them to the judge. Invariably, the failure is by an engineer or manager who interprets a license without proper use of legal counsel. Software engineers in companies have the daily task of combining copyrighted property of multiple parties. They still graduate college today without the capability of recognizing the issues or using counsel to resolve them appropriately. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] combining GPL and proprietary software - was: CC withdrawl of CC0 from OSI process
On 03/02/2012 10:38 AM, Chad Perrin wrote: On the other hand, a fully-written pleading for a Rule 11 sanction is beyond the means of someone who cannot afford a competent attorney. Since Olson was a Free Software developer, EFF provided his attorney pro-bono. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Linking question
Larry Rosen wrote: Is anything else required under the GPL or by the Busybox copyright owners? Specifically, is any of my client's proprietary software subject to disclosure? Must my client help anyone -- through product documentation or the disclosure of his proprietary code that he has purposely linked statically to Busybox -- to replace or upgrade Busybox itself in those millions of distributed proprietary wireless devices? I am aware of a number of negotiations with Bradley Kuhn regarding Busybox and uClibc enforcement. Bradley was not representing my interest. When I was involved, I was working for the manufacturer's attorney and had waived my own copyright interest with regard to that customer. Some of the cases I know of played out before my involvement with that customer, and some with my direct involvement. The parties didn't wish to contest whether they were in compliance or not. They instead took the route of requesting forgiveness for infringement as a settlement or before a suit was filed, since the terms to get that forgiveness end up being far less expensive than fighting the case. In order to get this forgiveness, all parties that I know of have been required to provide complete and corresponding source code for /all /software with a Free Software license in the system, regardless of its connection with Busybox or whether SFC or SFLC was representing the interest of the developers of that software. When there was static linking to uClibc, it had to become dynamic. Parties had to provide source code for run-time loaded kernel drivers. Once a set of Complete and Corresponding Source Code for a release was constructed, that release was made available to customers as an update, and I suspect was automatically updated in some devices. I have not heard that anyone was required to cause every customer to update. In all cases, Bradley was reasonable and a pleasure to work with. When he became overloaded and was unable to respond to companies in time, he did not enforce upon those companies obligations that he otherwise could have. Of course, Larry, I understand that this is not what you think should happen. However, it appears to be how a lawsuit or something that could have become a lawsuit has been resolved, in every case that I know of. Thanks Bruce On 03/02/2012 11:13 AM, Lawrence Rosen wrote: Is anything else required under the GPL or by the Busybox copyright owners? Specifically, is any of my client's proprietary software subject to disclosure? Must my client help anyone -- through product documentation or the disclosure of his proprietary code that he has purposely linked statically to Busybox -- to replace or upgrade Busybox itself in those millions of distributed proprietary wireless devices? attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] combining GPL and proprietary software - was: CC withdrawl of CC0 from OSI process
On 03/02/2012 11:34 AM, Chad Perrin wrote: Something tells me it is not reasonable to just always expect that writing open source code guarantees the EFF's help. Sure. But folks who have asked me for help got me free, and I've sometimes found them an attorney too. This is something I would otherwise charge $7.50 per minute for. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
The fact that we have not resolved some questions doesn't mean that we don't have /any/ bright lines. I have previously published guidelines that would keep you far from any fuzzy issues, while allowing you to build whatever you wish. On 03/01/2012 07:42 PM, John Cowan wrote: Which is as much to say, the wise person will use proprietary software to the full extent he can afford it, because there is no issue of copyright licensure, there is indemnity de facto or ex contractu from patent lawsuits, etc. etc. This leads to a vast amount of wheel-reinvention, but overall that is cheaper than defending lawsuits. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On 03/01/2012 08:02 PM, Chris Travers wrote: How do I know if this license applies? Just assume it does, because you don't really have to decide this question to be safe. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On 03/01/2012 08:32 PM, Chris Travers wrote: I am not at all sure that line works once you get into trying to bridge GPL'd and proprietary apps Read http://www.datamation.com/osrc/article.php/3801396/Bruce-Perens-Combining-GPL-and-Proprietary-Software.htm Does it matter how I do this? Very definitely. Is it possible to accidently create a derivative work in the process? If you don't know what to do, you probably will, because the easiest ways do create them are the ones that are more legally risky. However, it's not terribly hard to build stuff in the more safe ways. What do I have to avoid on a technical level (because I am thinking technically when programming, not legally) to be sure I am safe? It's in the article, at least for a number of general cases. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On 02/27/2012 12:57 AM, David Woolley wrote: The software analogy is flawed in that software has to be understood by a machine and is written in a language with very precisely defined semantics. Legal documents are written to be interpreted by a human and, unfortunately, legal language is not a simple formal language The structure of laws, courts, and contracts is indeed a machine that executes statements of rules. That it does so /fuzzily/ and through human rather than machine elements is not necessarily a /flaw /of the system, in that it is invariably asked to handle unforseen problems, and extends itself by doing so. A machine-executed language for legal rule sets is a frequently expressed, unachieved dream. But any program in such a language would necessarily be closed in its capabilities, and would need to fall back on humans for those unforseen problems. So, you wouldn't lose the courts or the arguing over what something really means. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On 02/26/2012 02:03 PM, Chad Perrin wrote: Explain to me how wanting to enforce a crapton of additional terms is realism instead of a more-restrictive license. When the terms are grants, or specifications of what must be granted in derivative works. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On 02/26/2012 02:31 PM, David Woolley wrote: The reality is that the people who have to comply with licences are not professional lawyers. This is always in my thoughts when considering any Open Source license. We can fail these people in two ways: 1. Provide them with a license that they might not understand. 2. Provide them with a license that won't hold up in court. The second damages them more. The first can be solved with explanation separate from the license. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] What would be necessary to consider the unlicense?
On 02/26/2012 04:05 PM, Clark C. Evans wrote: If it is a broken license, perhaps those with legal expertise might provide suggestions to fix it? I am having trouble finding a benefit that would come from fixing it, that we don't already have from short-and-sweet licenses like BSD. What you would to be as good as BSD would be a public domain declaration coupled with a covenant not-to-sue that extends to the patent claims of the dedicator that are necessary to utilize the work as it was dedicated. And a warranty disclaimer to protect the donor. It ends up not being shorter nor simpler. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] What would be necessary to consider the unlicense?
On 02/26/2012 05:50 PM, Clark C. Evans wrote: So, what makes unlicense and these public domain statements alluring is that they serve as vehicles for their authors make a statement about public policy. Yes, but the sentiment is so poorly directed that it's the one from /Henry VI. /For all of the talk, there is no credible political organization working against software patenting today. In the past I've tried to get support for one, to no avail. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On 02/26/2012 09:00 PM, Chad Perrin wrote: I suspect a better approach to understandable, legally well-formed license production might be to get someone who wants a very simple license to write it, and only *then* get the lawyers involved. While you're at it, be prepared to make the lawyers explain everything they want to change, and to tell them no a lot. The problem with your software, Chad, is that it's much too complicated for /no reason./ There's no reason for half of that crapton to be in there. We could cut it down to 10% of its present complexity if we had a /user /who wanted a really simple program write it first, and then we could have a programmer make it work correctly. While the programmer did that, we would make him explain /everything /that he was doing, and we would tell him no a lot to curb his natural tendency to add unnecessary complexity. :-) The pieces you don't like aren't there because anyone likes to put them there or because the people who wrote the license are idiots. There have been a lot of court cases in history. From those cases, we know a number of things that go wrong in courts. We want you not to get trapped by the same stuff. I had to help Bob Jacobsen, an Open Source developer who chose one of those over-simple licenses, the Artistic License 1.0, written by Larry Wall the Programmer. Bob had someone who both used his program in a product without even attributing it to him, and /also /asked Bob for lots of money for infringing his patent and tried to get Bob fired from his job by filing an FOIA with his employer. This was all over /model train software./ When Bob turned to Larry's Artistic License to help him get the guy off of his back, the Artistic License failed in court. We put a good team together and turned that around on appeal, but it was a close thing. By the time we were done, Bob had spent 5 years on the case, was out a good deal of money, and his relationship with his employer was damaged. We might not be able to help the next Bob who comes along and uses one of those licenses written in crayon. You can protect your friends by not encouraging them to do that. Thanks Bruce attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Reply to various recent postings on the crayon license issue
On 12/20/2011 11:41 AM, Richard Fontana wrote: Can you tell me how many licenses are in Fedora? If it's 300, it's something of a self-created problem, but then you'd be in lots of company. The numerosity itself is not a problem This is how an attorney confirms an unpleasant truth. 300 licenses in there. If you need to hear argument about the numerosity being a problem, I can refer you to a list of other attorneys and embedded system producers. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Reply to various recent postings on the crayon license issue
On 12/19/2011 09:54 AM, Tom Callaway wrote: nor are we the author of any of the licenses we track(1)), so we're not the appropriate entity to submit what we find to the OSI for approval. Can you tell me how many licenses are in Fedora? If it's 300, it's something of a self-created problem, but then you'd be in lots of company. Robin Miller, whom I had no idea was still around our community, wrote: Do we really need that many open source licenses? Of course not. My customers are advised to choose three for their own use. These three would include a gift-style license (think BSD), a sharing-with-rules license (think GPL) and something in-between. All three must be compatible with each other so that the customer is not in the situation of producing code that is incompatible with other of their works for no good reason. There are legitimate business (or personal) purposes for each style of license. For example, if you are making a standard, BSD is great because everybody loves to get a gift and everyone will be happy to use your standard code and do things your way. If you don't want your competitor to run away with your project without returning value to you, GPL imposes rules that bring competitors together well enough to make good software. And if you want to enhance the world of Free Software without being UNICEF to the world's richest corporations, GPL's nice for that, too. Or maybe Affero GPL if you are particularly concerned about Google and its ilk. But way back when this was a new endeavor, we were tickled pink to get a new license from Mozilla or IBM, it meant that they took the Open Soure movement seriously! :-) The one thing I didn't plan for was an embarrassment of riches. I hope you are all at some time blessed with perfect foresight. I have never been so blessed and am happy to have done as well as I did when we had to make up what we were doing as we went along and had limited information about fields like intellectual property and no professional help. OSI took a stab at license unification some years ago but,, as far as I can tell, didn't want to tip as many oxcarts as deprecating accepted licenses would do. And thus nothing was done. At least this is my surmise, I have been kept at a distance from OSI activities these last 10 years. Richard Fontana: While there is very little in life that is certain, we can be reasonably certain that Red Hat will never submit that particular [Freedom Font] license for OSI review. Font licenses seem to be a cesspool for some reason. The SIL Open Font license remains my prototype for crayon licenses, there is one line that says the license is null and void in regard to an embedded version of the covered font, which either places that version of the font in the public domain or makes it all-rights-reserved, depending on your preferred interpretation. The license is expected to magically come back into force if you ever remove the font from its embedded context. The OSI of that time certified this work of crayon and we're stuck with it. Jeremy Reed: Some copyright owners are stubborn and may respond negatively even on a polite request. Would that it were so easy. A good many of them are dead people or bankrupt business entities, and their assigns know nothing of Open Source or even that they own the property. Some (like an early but still relevant SSL developer) are contractually bound to never touch that software again. Rod Dixon: Wow! I must add that I do not think I would have seen a comment like this posted by Bruce Perens 10 years ago. RMS is lucky to have had the help of Eben Moglen back then, but we had no help at all from legal professionals for a long time. Lawyers were not willing to be seen to be involved with us, it would have offended their normal intellectual property customers. Very much has changed, and it is hard for some folks to imagine the way things used to be. Over the past 10 years I have spent a lot of time with lawyers and courts, indeed it is half my income of late. So, now I understand things that we had no clue about then. Thanks Bruce ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a Free Island Public License?
Sorry, I missed that it wasn't intended for submission. The author should back up and state a /list of goals, /rather than present the argument as pseudo-legal drafting. Thanks Bruce On 12/16/2011 10:23 PM, Karl Fogel wrote: It was never submitted -- I don't think Clark intended to, in fact. attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] a Free Island Public License?
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 attachment: bruce.vcf smime.p7s Description: S/MIME Cryptographic Signature ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: OSD#5 needs a patch?
Okay, I guess I see that. I didn't see it as entirely a case of moral positioning. In the example that I created, if I were a member of ethnic group, I would feel like I were not as welcome to use the software as others are. Moreover, depending on what exactly was said, I might also find it repulsive to propagate the message by redistributing the program, whether I am a member of ethnic group or not. Thus it seemed to me that, when a licensor tries to discourage a person or group from using the software, it shouldn't matter whether they are trying to accomplish that through legal force or through insults and intimidation. However, I realize that argument must seem a little fuzzy, and perhaps a little too idealistic as well, for all of you lawyers :-). Thanks, Bruce - Original Message - From: Rick Moen [EMAIL PROTECTED] I'm pretty sure the OSD is concerned solely with licences' actual effect, not their attitude problems. - Original Message - From: Rod Dixon, J.D., LL.M. [EMAIL PROTECTED] I will stop lurking for just a split second to say that I agree that the OSD is not a moral code. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD#5 needs a patch?
Well, the copy attached to Sean's introductory email (also on his web site) states among other things: ..the most expendable, unimportant engineers work on GPL software and the better software engineers work on BSDL-licensed software. In a gift economy / meritocracy like ours, that's just about the worst thing you can say about a group of peers. By the way I don't think Sean's a hateful person. I don't even think he cares whether anyone uses his license. I just think he was having some fun at our expense. Sincerely, Bruce - Original Message - From: Ben Reser [EMAIL PROTECTED] Newsgroups: gmane.comp.licenses.open-source.general Sent: Tuesday, October 07, 2003 1:27 AM Subject: Re: OSD#5 needs a patch? It doesn't seem to me that the OSSAL is making any discriminatory or derogatory statements in its DISCUSSION section. IMHO it's based on some misguided goals though. But that is an entirely different matter. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Academic Free License version 2.0
I think this change is mostly-positive. The only negative aspect that I see is that it's twice as long as the previous revision. AFL 1.2 had stricken a nice balance between brevity and precision. May I suggest that, alongside AFL 2.0, you publish one last license in the AFL 1.x series, based on AFL 1.2 but with the applicable OSL 2.0 revisions merged in, i.e. sublicenseable, and with the revised, more palatable Termination for Patent Action clause? In addition, considering how different the wording of AFL 2.0 is from 1.x (even though the effect is similar), and the fact that there may be projects using 1.x, please do not withdraw the AFL 1.x when 2.0 is approved. I would like to see them both in the list of approved licenses. - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] Newsgroups: gmane.comp.licenses.open-source.general Sent: Wednesday, July 16, 2003 10:05 PM Subject: Academic Free License version 2.0 To License-Discuss (and others interested persons on BCC): Version 2.0 of the Academic Free License (AFL) is hereby submitted for your review and for the approval of the OSI Board of Directors. It can be found at http://rosenlaw.com/afl2.0.html. Most academic-style licenses follow the BSD model -- short, generous and uncomplicated. [See http://opensource.org/licenses/bsd-license.php] Simply put, academic licenses permit derivative works to become a part of other software, including proprietary software, for any purpose whatsoever. Unfortunately, those licenses often omit many details, leaving to the imagination how certain things are to work in an open source/proprietary world. The AFL fills in those gaps. It addresses issues of patent, trademark, warranty, jurisdiction and venue, contributor recognition, etc., in ways entirely consistent with the BSD philosophy of open source. AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose wh atsoever, including to create derivative works. This new version of the AFL also helps eliminate possible confusion between academic-style licenses and reciprocal licenses [see, for example, the GPL, www.fsf.org/licenses/gpl.html, and the Open Software License (OSL), www.rosenlaw.com/osl2.0.html]. Reciprocity requires that any Derivative Works be licensed under the same license as the Original Work. Reciprocal and non-reciprocal open source licenses ought to be the same -- except with respect to provisions dealing with reciprocity. Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision. A redlined comparison of AFL2.0 and OSL2.0 is at http://rosenlaw.com/afl2.0-redline.pdf. When you suggest changes to the AFL, please consider how that language would read in the OSL, and vice versa. Suggestions regarding both AFL2.0 and OSL2.0 will be welcomed. Feel free to ask questions or complain here on license-discuss. The OSI board of directors needs your input before they decide whether to approve these licenses. In the meantime, I encourage you to think about using the Academic Free License version 2.0 instead of the BSD, MIT and Apache licenses, and their variants, that have proliferated on OSI's approved license list. /Lawrence Rosen Rosenlaw Einschlag, a technology law firm General counsel, Open Source Initiative 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * fax: 707-485-1243 email: [EMAIL PROTECTED] www.rosenlaw.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Problems in Open Source Licensing
For cases 2 and 3: who is to say that I haven't, in the past, distributed the code to someone else and they happened to distribute a copy back to me? For that matter, did I really get it directly from you, or did I get it from someone else, who was redistributing it under the GPL? If you're trying to un-GPL something that you have previously GPL'd, you're going to have a very hard time suing anyone who has a copy of the code from before you did that. Best you can do is stop distributing it, and hope that your software was unpopular enough that no one else will bother to redistribute it either. - Bruce - IANAL - From: John Cowan [EMAIL PROTECTED] To: Jeremy Malcolm [EMAIL PROTECTED] CC: C. Hamacher [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Problems in Open Source Licensing Date: Mon, 17 Feb 2003 00:26:45 -0500 (EST) Jeremy Malcolm scripsit: [L]et's take the simpler case of releasing my own code under the GPL. Do you see anything that would prevent me from withdrawing those licensing terms? Short of contract or estoppel, and assuming that I adequately communicate the revocation of licence to my users, how can I be prevented from changing the licensing terms whenever and however I like? I think there are three cases: 1) Users who have already relied on the GPL to distribute or modify your code 2) Users who are at present relying on the GPL to distribute etc. 3) Users who intend in the future to rely on the GPL to distribute etc. As to case 1, I think you are pretty clearly estopped from doing anything about their existing distributions or modifications; they relied on your licensing terms in good faith. Case 3 users, OTOH, are screwed. Case 2 is obviously intermediate. (IANAL, TINLA) Licence conditions have to be reasonable, contract conditions don't. Excellent. That means the infamous MSOSL, which I bruited about onthis list a few years ago, can be freely dismissed. (This was a putative Open Source license which required the licensee to consume moose by-product as a condition of the license, for those of you who have mercifully forgotten.) -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --_The Hobbit_ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
historical permission notice and disclaimer - ready to go?
So, is this template ready to be put before the board and considered for approval? Is there anything that should change before this happens? Can I assume that, if someone was strongly against this template, I would have heard about it by now? One final question: should this be published with the documentation and examples that I put together for the approval process, or should it just be published in its bare form? http://www.geocities.com/brucedodson.rm/hist_pnd.htm For the list archive, here is the template in its absolute barest form, copied from the web page: -- copyright notice Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies[,] [and] that both [that] [the] copyright notice and this permission notice appear in supporting documentation[, and that the name [of] copyright holder [or related entities] not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission]. [copyright holder makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty.] [copyright holder DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS[,][.] IN NO EVENT SHALL copyright holder BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.] -- Regards, Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: approval request: Historical Permission Notice and Disclaimer
So far, no discussion. Is that a good thing or a bad thing? http://www.geocities.com/brucedodson.rm/hist_pnd.htm Regards, Bruce - Original Message - From: Bruce Dodson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 12:11 AM Subject: discuss: approval request: Historical Permission Notice and Disclaimer [ Please discuss this template. It's a clever idea. You'd have thought that someone would have thought of it before. Bruce has sent a few changes since his submission. Please consult his web page (URL at bottom) for the exact current submission. -russ ] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
discuss: approval request: Historical Permission Notice and Disclaimer
[ Please discuss this template. It's a clever idea. You'd have
thought that someone would have thought of it before. Bruce has
sent a few changes since his submission. Please consult his web page
(URL at bottom) for the exact current submission. -russ ]
I would like to ask that the following permission notice
template be approved by the OSI board.
This template is distilled from a permission notice that is
used in many packages, including two that I work with in my
own open source contributions: Scintilla, and OGDI (Open
Geospatial Datastore Interface). A better known example of
this template is the CWI Permission Notice on Python 1.5.x.
The license for ATT / Lucent AWK also follows the pattern.
Python is now under a different, OSI-approved license.
However, so many other packages remain under this style
of permission notice, and some of these will never
change their license. Thus it is important to recognize
this template so that these packages can be acknowledged
as OSI certified open source software.
Also, more to the point for my own interest in this
template: Suppose I distribute a work that includes
code that I licensed under this style of permission
notice. I want to be able to put my own code under
AFL, affirm that the CWI-style permission notice still
applies to the library that I used; and call the
package as a whole OSI Certified.
I am suggesting the name Historical Permission Notice
and Disclaimer, since it implies that this template
isn't really intended / recommended for new software,
but is meant to acknowledge software that has
historically been licensed under these general terms.
Explanation of the Template:
Angle brackets hold fields, e.g. copyright holder.
If a field appears more than once, subsequent appearances might
use a short form of the same name. The CWI notice for Python
1.5.x is an example of a case where this was done.
Square brackets hold optional text, e.g. [or related entities].
Squiggly braces hold alternative spellings for some required
word. This is to try to accomodate trivial variations such
as are found in the Scintilla license. e.g. {the|that}.
A license can have variations in capitalization and
whitespace, and still be considered an instance of this
template.
The template:
-BEGIN-
[license name]
Copyright [(C)] year(s) [by] copyright holder[.]
[All rights reserved][.]
Permission to use, copy, modify and distribute this software and
its documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies, [and]
that both {the|that} copyright notice and this permission notice appear
in supporting documentation[, and that the name [of] copyright holder
[or related entities] not be used in advertising or publicity
pertaining to distribution of the software without specific, written
prior permission]. [copyright holder makes no representations about
the suitability of this software for any purpose. It is provided as
is without express or implied warranty.]
[copyright holder DISCLAIMS ALL WARRANTIES WITH REGARD
TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS{,|.} IN NO EVENT SHALL
copyright holder(s) BE LIABLE FOR ANY SPECIAL, INDIRECT
OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.]
-END-
Since this template is meant to retro-fit onto existing
licenses, there's little room for negotiation on the
wording. The notice has ambiguities that make it hard
to recommend when licenses like AFL are available, but
these can't be fixed, or the template would not fit the
existing licenses any more. (This template is clearly
for old software, not new software. That much is
evident in the name.)
There may be other licenses which are practically
identical to this one, but which differ in some tiny,
inconsequential way. Discussion on license-discuss
might reveal ways to easily accomodate these. (An
example: Scintilla uses and that both that license
and ..., while most other instances use and that
both the license and...) However, it is unlikely
that we will accomodate every possible nuance in
version 1 of this template. The 20/80 rule applies.
I think I have handled the most common variations
in this draft.
In accordance with the approval process, I've placed
a copy of the license on a web web page:
http://www.geocities.com/brucedodson.rm/hist_pnd.htm
_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Duemetri Public License (DPL) Version 1.0
The pain you speak of, is this from a purely legal stand point? If so, in what manner does it hinder or cause pain to an end user? I'm not a lawyer so I never speak from a legal standpoint, even when I'm talking about licenses. The pain is from a technical standpoint. If I make a modification that I think others would also enjoy, I had better hope the project team accepts it into the core; otherwise it will be not only onerous for me to maintain (just ask Christian Tismer), but also onerous for the end user to build from source. (The same end user who might be quite comfortable following instructions that say type configure; then type make; then type make install, might be deeply mistified by tools like diff and patch.) What this constraint does accomplish is that if deep philosophical differences leave one with no choice but to fork (q.v. XEmacs), it makes it much harder for the forkers to succeed in taking mindshare away from the original developers. But if the original developer abandons the project, it also makes it more difficult for the code to take on a life of its own, and find another owner to care for it. My dislike of QPL does not apply to QT itself, since Troll Tech is kind enough to make that available under GPL as well. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Request for license approval...
Is it true that changing proper names is not a problem? I had always been of the impression that, e.g. I couldn't just use the Apache License, change the proper names, and call my software OSI Certified. - Original Message - From: John Cowan [EMAIL PROTECTED] I urge you instead to see if you can reuse one of the 39 existing licenses (generally speaking, changing proper names in them is not a problem). That way you will not add to the queue and you will be able to call your software OSI Certified right away. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
time frame between request for approval and acknowledgement of request?
What should one expect as a reasonable time period between the sumission of a license-approval request, and some acknowledgement that the request has been made? -- Background: On November 6, I wrote to license-discuss suggesting that the style of permission notice used in Python 1.5, OGDI, Lucent AWK, Scintilla, etc. should be considered for approval by the board. On November 9, I made a formal request to that effect. A draft of the template is here: http://www.geocities.com/brucedodson.rm/hist_pnd.htm I structured the request as a template so that it would match the minor variations in wording / punctuation / proper names in these OSD-compliant licenses. Otherwise I would have to make a separate request for each license. The board is already overworked, and so am I. -- I realize the actual time to discuss the license and process the request will vary from one case to the next, and can be months. However, I just want to know that I'm in the queue. Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: time frame between request for approval and acknowledgement of request?
I understand that, Russ, and I have a great respect for the work that you do. The role of filter is not a glamorous one. It certainly isn't a job that I would want, and yet there you are, doing it. I was just looking for an ACK that my email hadn't been eaten by your junk mail filter or whatever. Now I have that. Thank you; now I can go back to waiting, more patiently than before. I'm a volunteer, Bruce, with a TODO list longer than your arm. The problem with license submittals is that I try to pre-vet them, so that the license-discuss people don't have to waste their time with licenses that are obviously unacceptable. Yours has not been pre-vetted yet. It will be. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | it's better to be free 521 Pleasant Valley Rd. | +1 315 268 1925 voice | than to be correct. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Duemetri Public License (DPL) Version 1.0
The QPL uses the same tactic to control distribution of customized versions of Qt. But this creates is a pain for developers and end-users alike. At least your term #8 provides an alternative, changing this requirement to distribute patches into something that's optional. But it's confusing the way 7 and 8 seem to contradict one another. As a licensee, I would be scratching my head, unsure whether I was compliant or not. Please consider dropping term 7, and simply leaving term 8. Given the choice, most developers would choose that option anyway, because distributing patches creates extra burden for the end-user. Even term 8 creates a difficult situation. You have a license whose first line says, The software is called RAINBOW, and then says that for modified works, The software must not be called RAINBOW. If I were you, I would check out the AFL 1.2. That version might not have been approved yet when you made your request. Depending on what business requirement points 7 and 8 of your license are meant to serve, you might find that the AFL's Attribution Rights provision can be leveraged to deliver the same business value in a different way. Then you'd have a professionally written license, you wouldn't have to go through a long drawn out process to try to get your license approved, and you can get on with writing your software. - Original Message - From: Graziano Poretti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 21, 2002 12:01 AM Subject: discuss: Duemetri Public License (DPL) Version 1.0 [ Please discuss this license. Graziano reports that the only change from the Zope license are terms 7 and 8. -russ ] hi we would like to start an open source project on a product called rainbow. the 1st version of the license is at http://www.duemetri.it/licenza.htm http://www.duemetri.it/licenza.htm the most similar license is the ZOPE public license. the changes occur for the Integrity of The Author's Source Code - point #4 of OSD. according with this point, we prefer that the free distribution of source and binary would be granted with the release of official versions and modifications can be installed using the patch files only. the developers community will check and test all the patches in order to release the new official version including all new features (tested and with a sufficient documentation). thanks for ur time ... sincerely --- Graziano Poretti - DUE METRI http://support.facile.duemetri.net http://support.facile.duemetri.net/ - Per creare e gestire un portale in 20 minuti http://www.duemetri.it http://www.duemetri.it/ tel.: 0039 184 42163 Fax: 0039 184 462673 -- License follows Duemetri Public License (DPL) Version 1.0 1. The software is called ``RAINBOW'' 2. This software is Copyright (c) Duemetri sas (tm) and Contributors. All rights reserved 3. Redistributions in source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 4. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 5. The name Duemetri sas (tm) must not be used to endorse or promote products derived from this software without prior written permission from Duemetri sas 6. If any files are modified, you must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. Disclaimer THIS SOFTWARE IS PROVIDED BY DUEMETRI SAS ''AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DUEMETRI SAS OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 7. The official version of the product will be released by Duemetri sas. The distribution of the modified product in source or binary form is allowed as official version and ``patch files''. 8. The distribution of modified versions of the software without using ``patch files'' is allowed. In this case is fobidden to use the term ``Rainbow'' as the name (or part of it) of the product -- License ends -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [kmself@ix.netcom.com: Re: We are looking for an open source licensethat...]
Just remember, if I can't sell your stuff, it ain't open source. extrapolate some of the benefits of the GPL. I have worked for companies that will not use free software for fear of tainting their development efforts and having their propietary code made free. [CFC] Yes, there are companies like that. Their fear is their loss, and for most open source software it's unfounded. There are also companies who have opened their source just so that they can gain access to code which is only available under GPL. You can't hold onto your custodianship of this technology through licensing restrictions. [WBD] I think you mean and still release the product as open source, because today we do a perfectly good job of retaining our technology through licensing restrictions. [CFC] That's right. I meant, if you want to call your license an open source license, you can't... So, you believe reinventing the wheel is a good thing (as long as the reinvented wheel is an open one (and the old wheel wasn't))? [CFC] That's what many of us believe, yes. It does lead to some good things, like Linux. so far, no one has offered to pay me what I expect as a salary and allow me to write the software that I want to write and also give it away, and I don't really expect... [CFC] If you're serious about this, tweak your expectations. -bruce _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: [kmself@ix.netcom.com: Re: We are looking for an open source licensethat...]
From: Chris F Clark [EMAIL PROTECTED] It is more to discourage commercial users from using the open source version. [CFC] I don't know if you're going to see much support here for a license that discourages use of the open source version, by any particular group. We want to encourage the use of open source, not only by those who are already using it, but also by newcomers. However, we do not wish to deprive open source developers the bounty of our labor and have no qualms their using our tool to build open source programs that they give away. [CFC] What you seem to be suggesting is what FSF calls semi-free. http://www.fsf.org/philosophy/categories.html#semi-freeSoftware Then by protecting your revenue stream, you would be depriving us of the full bounty of our own own labors. Use of your software would be a poison pill, that prevents us from selling the the open source programs that we build. (Some of us will never sell our software, but all of us, and all of our licensees, retain that option.) We make a certain profit by being the sole provider of this software and we cannot afford to have that revenue stream dry up completely. [CFC] You can't hold onto your custodianship of this technology through licensing restrictions. If you open-source your technology, there are two ways to keep ownership of the project: (1) adopt a cooperative attitude; work with the community while continuing to maintain yourself as the leader in this technology. (2) hope that no one else is interested in it. Netscape has done it right with Mozilla.org. Borland/Interbase has not, and so there is Firebird. ...Rational Rose... [CFC] If Rational started giving away Rose gratis for open source development, while still maintaining it as non-open software (whether that is by closed source, shared source, semi-free), I believe it could hurt the open source community, since it could take mindshare away from legitimate open source CASE projects like ArgoUML. -bruce _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
The amount of damages that courts would award might vary considerably from one jurisdiction to the next, even if the license is interpreted exactly the same way. Without naming any names wink, some countries are just more litigious than others; some courts, more punitive. - Original Message - From: David Woolley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 5:47 PM Subject: Re: Approval Requested for AFL 1.2 and OSL 1.1 think the terms of the OSL are different, or will be interpreted differently, in those other countries? It is true that the OSL -- and The fact that you said that the choice of law was determined by the licensor; if it is unlikely to change, there will be less uncertainty for licensees if it is fixed as, say US law. As I see it, the only reason to need to specify that the law is defined by the licensor is that the interpretation *can* differ for different licensors (of which one program may have many). -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Express and implied warranties in software licenses
Thank you very much for clearing up my FUD. Well, I have never hidden the fact that I'm no legal scholar, and this is proof once again that a little knowledge can be a dangerous thing. I can only speak for myself, but between this and the discussions we had privately, I'm finally comfortable with the warranty. I would no longer let it stop me from using AFL in situations where I might currently use MIT or Apache-style licenses. bruce - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Bruce Dodson' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 07, 2002 2:59 AM Subject: Express and implied warranties in software licenses Bruce Dodson wrote: snip The other two concerns -- about whether I'm on the hook for other warranties besides the one that is offered explicitly (Magnusson Moss). You are repeating the notion, occasionally mentioned on license-discuss, that if an open source license offers any warranties at all then the implied warranties of merchantability and fitness for a particular purpose cannot be disclaimed. (See 15 U.S.C. §2308 [no supplier may disclaim or modify any implied warranty on a consumer product if such supplier makes any written warranty].) The Magnusson-Moss act deals with consumer products, meaning any tangible personal property which is distributed in commerce and which is normally used for personal, family, or household purposes (including any such property intended to be attached to or installed in any real property without regard to whether it is so attached or installed). 15 U.S.C. §2301. That does not include software because it is not tangible personal property. Software is intellectual property. If you combine software with a consumer product (e.g., a PDA or telephone), or distribute it on a tangible CD-ROM, arguably the entire consumer product would be subject to Magnusson-Moss rules. But the term written warranty in the act is defined as follows: (A) any written affirmation of fact or written promise made in connection with the sale of a consumer product by a supplier to a buyer which relates to the nature of the material or workmanship and affirms or promises that such material or workmanship is defect free or will meet a specified level of performance over a specified period of time, or (B) any undertaking in writing in connection with the sale by a supplier of a consumer product to refund, repair, replace, or take other remedial action with respect to such product in the event that such product fails to meet the specifications set forth in the undertaking, which written affirmation, promise, or undertaking becomes part of the basis of the bargain between a supplier and a buyer for purposes other than resale of such product. 15 U.S.C. §2301. I don't read the narrow express warranty in the OSL or AFL as meeting the criteria under either A or B. The notion that one runs afoul of Magnusson-Moss if a software license gives any written warranty whatsoever is not justified in law. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
From: Mike Nordell [EMAIL PROTECTED] Bruce Dodson top-posted: Derivative Works means derivative works based upon the Original Work, as upposed to derivative works based upon Marvel Comics characters, or derivative works based upon previously-unreleased Elvis tracks. Since the definition of this isn't yet established in the license text, how would I know? If you take out the parenthesized Derivative Works, the license reads derivative works based upon the Original Work, just as I said. Anyway I was just stating my opinion as a layman who is NOT confused by this license. (That doesn't mean I would use it. That will not happen for either of these licenses until I see some open discussion that makes me comfortable with the warranty.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Plan 9 license
I disagree. (I know, I do that a lot, but I mean well.) It's best if licenses are simply either approved or not approved. There is no list of licenses that have been rejected or withdrawn; that would be punitive. By the same token, there should be no special status given to licenses in limbo. Perhaps OSI would list licenses that have ended in limbo (neither rejected nor approved) and/or list licenses that claim to be open source but which are not (yet) certified by the OSI. -- ralph -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
a template for the CWI permission notice (Python 1.5.x) and similar licenses
I would like to suggest that a license template like the one below be put forward for approval by the OSI board. This is not really intended for new software. Nevertheless it's pragmatic to approve it since many OSD-compliant licenses follow this template. Examples include Scintilla/SciTE, Lucent AWK, OGDI, Python 1.5.x, and derivatives. This is not a license that we would recommend for new software - for that, AFL will do a better job. (Heck, MIT would do almost the same job as this new template, and is already approved.) However, I want to be able to use components licensed under these terms, combine them with other open source software (say, stuff I write and license under AFL), and still call the result OSI certified. Explanation of the Template: Square brakets hold optional text. Angle brackets hold fields, as usual. If a field appears more than once, subsequent appearances might use a short form, e.g. see copyright holder in the Python 1.5.x and in the AWK license. Small variations in capitalization and whitespace do not matter. The template: [license name] Copyright [(C)] year(s) [by] copyright holder[.] [All rights reserved][.] Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies, [and] that both the copyright notice and this permission notice appear in supporting documentation[, and that the name [of] copyright holder [or related entities] not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission]. [copyright holder makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty.] [copyright holder DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL copyright holder(s) BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.] Examples of licenses that follow this template: -- License for Scintilla and SciTE Copyright 1998-2002 by Neil Hodgson [EMAIL PROTECTED] All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * This license omits the optional no-endorsement clause, and includes the long disclaimer. It also has a typo, I think (and that both that copyright notice) but maybe it was intentional; if so I suppose it could be incorporated into the template. --- License for ATT AWK Copyright (C) Lucent Technologies 1997 All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that the copyright notice and this permission notice and warranty disclaimer appear in supporting documentation, and that the name Lucent Technologies or any of its entities not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. LUCENT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL LUCENT OR ANY OF ITS ENTITIES BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * This template includes the no-endorsement clause and the long disclaimer. --- License for OGDI - Open Geospatial Datastore Interface Much of OGDI is implicitly or explicitly under the following two licenses (year varies a bit): Copyright (C) 1995 Logiciels et Applications Scientifiques (L.A.S.) Inc Permission to use, copy, modify and distribute this software and its documentation for any purpose and without fee is hereby granted, provided
Re: Approval Requested for AFL 1.2 and OSL 1.1
It seems clear to me, yet another non-lawyer:
Derivative Works means derivative works based upon the Original Work, as
upposed to derivative works based upon Marvel Comics characters, or
derivative works based upon previously-unreleased Elvis tracks.
Prepare - it doesn't say to prepare yourself to create [Derivative
Works]. It says to prepare [Derivative Works]. Like when you're
preparing dinner - after you have finished preparing it, you have something
that you can eat. No offense, but Duh.
Cheers,
Bruce
- Original Message -
From: Mike Nordell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 05, 2002 10:56 PM
Subject: Approval Requested for AFL 1.2 and OSL 1.1
From my wording, I think it's quite obvious that IANAL.
Lawrence E. Rosen wrote:
[link to OSL 1.1]
I must say, I read just down to 1 b) before I got hickups.
to prepare... What is prepare? To fork a CVS copy in preparation for
some
real work? To... I don't know.
No, the prepare phrase is way too vague for me to like it - especially
since it seems to be completely superfluous. Why would I need a grant to
prepare something? Someone is going to look over my shoulder to say Hey
there, it looks like you're 'preparing' derived works here!. Someone is
going to dissect my brain while it's running and say It seems like a
preparation... for even _thinking_ of doing something (which is a form of
preparation).
I think you should either reword or just drop it.
What would happen if to prepare was replaced with to create? That
wouldn't try to forbid people to even think, would it?
I also have complaints about the 100% reduncance in explaining that
derivative works is _really_ ('Derivative Works'). I believe it is a
great merit to explain something before it's used. In this case
derivative
works (capitalize however you like) could be explained before it was
used.
That would 1) obviate the need to write it twice in the same point, 2)
make
(reasonably) sure the reader knew what it was.
Besides that? Actually, that was enough for me to stop reading. Sorry
Lawrence, I'm sure you put great effort in creating this, but this
developer
didn't agree even with pt 1.
/Mike
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
I can offer something without entering a relationship with each recipient. I have software published on SourceForge; I entered into an agreement with SourceForge but I have no relationship with the people who downloaded my stuff from there. The people who downloaded might or might not have a relationship with SourceForge; that is no concern of mine. Likewise with Tripod, and other places where I have published stuff. Mahesh, you're switching back and forth between liability and warranty, using the words interchangeably, which is confusing. Warranty is a product that can be offered or not offered. Implied warranties are an implicit part of another product (which can be expressly excluded in many places). Liability is not a product to be offered; it's a completely different beast. If there is no contract, you can't contract away liability. But if there's no direct relationship between you and the recipient (such as a contract), it's hard to conceive of a way that you could be held liable in the first place. At least I, a mere software developer, cannot conceive of one. As for warranty, I was sure that I can always say I'm offering something as is. That's just a statement that I'm not offering any warranty products in addition to my software product. As for implicit warranties of merchantability etc., I will always use a license that says those don't apply, but why should the recipient care about merchantability if they didn't buy it? (And if they did buy it, they probably have a contract with whoever sold it to them, but not with me because I wasn't involved in the transaction.) THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW - I'm guessing the GPL says that for other reasons, that have to do with the fact that some jurisdictions don't let you remove the implied warranties of merchantability and fitness. I doubt this matters much for the software that FSF gives away, although it might make a difference for the CDs that they sell. I am only guessing. - Original Message - From: Mahesh T Pai [EMAIL PROTECTED] To: David Johnson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 02, 2002 5:10 AM Subject: Re: a proposed change to the OSD David Johnson wrote: I still haven't come to grips yet with the concept that a contract is required for disclaimers of warranty. It seems to me that there must be another mechanism that achieves the same result. You have to make the terms under which you are offering something clear. Situations where a single person (eg. a software developer) entering into relationships with several persons ( eg, by distributing several copies of the same s/w) on same terms (that is, under the same license) are not always treated as *pure* (mark the word pure) contractual by courts - at least, in the common-law world. When you disclaim liability you have to make such disclaimer it clear and tell the court that you have informed the recipient of s/w that he knew, at least you took sufficient steps to inform the other guy about the existence of the disclaimer. If the relationship is contractual, this disclaimer will help you, if not, (status based) nothing will. That is why, the GNU GPL (and most other licenses) use the phrase THERE IS NO WARRANTY FOR THE PROGRAM, TO THE *EXTENT PERMITTED BY APPLICABLE LAW* in paragraph 11. Regards, Mahesh T Pai. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
Thanks John and Larry. Now I am starting to see. That's very frightening to think about, but I still find it hard to believe. With the manufacturer / retailer situation, the manufacturer got paid for the goods, and there was a chain of contracts even though there was no privity between manufacturer and final recipient. Does all of this apply equally to my situation, where I am making the software available purely as a gift? (I realize others among us are selling their open source products, and I have no problem with that, but that's not what I'm doing.) -- Forget about privity for a second. That's a red herring. My cat just strolled in, so now I have other things on my mind: Someone gave this cat to me; she was free to a good home. They said she was healthy, and it turned out they were right. If I found that she had some health problem when I got her, could I have expected the original owners to pay the veterinary expenses based on some theory of implied warranty? If I had decided to return her, could I have expected to be compensated some amount so I could buy a replacement cat from Pets R Us? Don't be stupid, Bruce, of course not, says my conscience. Does the law disagree? Also, does it give a different answer for software than for cats? - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'John Cowan' [EMAIL PROTECTED]; 'Bruce Dodson' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'David Johnson' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, November 02, 2002 8:15 PM Subject: RE: a proposed change to the OSD That used to be the law. But people got tired of buying useless and/or dangerously defective products from stores and getting this answer: Store: I had no way to know it was useless/defective: try the manufacturer. Manufacturer: You and we have no privity of contract: try the store. So after enough people got angry enough, the law was changed. Now manufacturers are liable for the useless/defective products they produce *to the ultimate consumer*, under a fiction of implied warranty: the manufacturer is deemed to have issued such a warranty whether he has or not. The warranty disclaimer is an attempt to dispose of this obligation, and 1) it may not work at all in some jurisdictions, and 2) it surely will not work unless the manufacturer SHOUTS it at the consumer in an unmistakable place. Yes, what John says is true. And so we find ourselves in a situation where manufactured products intended for consumers are covered by mandatory warranties under federal law. (Even some products that contain Linux software in them!) And there are effective product liability and consumer protection statutes in nearly all states that make manufacturers and distributors liable for the crap they foist on the unsuspecting public. Someday UCITA may do these things for software. Do you want that? Do you want the open source community to try to influence the shaping of laws like UCITA? For those who fantasize a different kind of world, let's make it so. In the meantime, we're stuck with contract law the way it is. Or at least the way it is in the US. How is it different in other countries? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSL 1.1 treatment of documentation
I took it to mean any technical documentation which is provided by a licensor, which may make the source code more accessible to a licensee. Then you would be compelled to provide such documentation as was provided to you when you received your copy of the source code. So, access in the sense of making source code accessible. That's my interpretation as a layman; it might not be the same one that Larry had in mind. However I think it could be spelled out more clearly. If you use excerpts of that that documentation in a book, and the documentation was considered to be under OSL, then it seems you would have to make the full text available under OSL. Is that right? Then, Forrest's question: what about a book that isn't a derivative work? Could contract law and some technically inept judge compell the book publisher to release the book's source code (DocBook / TeX / whatever) under OSL? - Original Message - From: Forrest J. Cavalier III [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 1:53 PM Subject: RE: OSL 1.1 treatment of documentation Lawrence E. Rosen [EMAIL PROTECTED] wrote in part: 3) Grant of Source Code License. The term Source Code means the preferred form of the Original Work for making modifications to it and all available documentation describing how to access and modify the Original Work. access is not well-defined. Is your intent to compel book publishers to give away the text of their books written for users of the Work? No, and I don't think the word access conveys that meaning. accessed appears in OSL 1.1 paragraph 5. And it seems that use is different than access. Can you explain what you meant in each paragraph? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSL 1.1 treatment of documentation
(Larry said...) Not if it ain't a Derivative Work, I'd say. ... What do you think? I think the same. Common sense tells me that a book that isn't a derivative work should be outside the scope of the contract. This concept is probably non-technical enough that even a judge would be able to grasp it. (Forrest said...) Seems to me by the OSL paragraph 3, a book publisher is compelled to include a machine-readable copy of their book if they provide a copy of the Original work. Common sense also tells me including the software on a CD in the back cover of a book doesn't make the book a derivative work - it just makes the book a distribution medium of sorts. Larry: Although common sense seems to lead to the right answers, it is true that the wording is cumbersome. Maybe the problem is that it's hard to define which documentation you mean without creating a self-referencing definition for Source Code. Then perhaps it would be easier to make this clear if you defined two terms, so the Technical Documentation is not part of the Source Code, but must also be included. That could look something like this: The term Source Code means the preferred form of the Original Work for making modifications to it. The term Technical Documentation means all available documentation describing how to access and modify the Source Code. Licensor hereby agrees to provide a machine-readable copy of the Source Code and Technical Documentation along with each copy of the Original Work that Licensor distributes. Licensor reserves the right to satisfy this obligation by placing a machine-readable copy of the Source Code and Technical Documentation in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work, and by publishing the address of that information repository in a notice immediately following the copyright notice that applies to the Original Work. (Hey, it's just a thought. I ain't no lawyer.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
From: Dr. David Alan Gilbert [EMAIL PROTECTED] Can you explain to me (and the list) what the definition of a 'use restriction' is? IANAL, of course. For software, use is execution of the software. Copyright law doesn't speak much of software at all, so we can't rely on that for a definition and must look at court cases for precedents. Creation of derived works is a separate right from use under copyright law. It can be restricted separately from use, and vice versa. The act of modifying software creates a derived work that is partially your copyright, and partially that of the original contributor. Public performance is a separate right as well, but in the U.S. it is defined to apply to plays and audiovisual media, and _not_ to software. There is some contention regarding whether linking creates a derived work, and exactly one court case on the topic that isn't definitive. Dynamic linking, server-izing, and cross-process procedure call schemes like CORBA make this more complicated. With CORBA, you can use a library without ever linking to it, and it would be difficult to proves in court that a derived work would be created. In many of these schemes, the derived work, if one exists, is created on the user's system at run-time and it's going to be difficult to prove in court that it's _distributed_ as a derived work. All of this makes it questionable that the GPL's linking provisions with regard to source-code disclosure would be enforced in court. In an effort to create a more clearly enforcible GPL-like license, Larry has relied on _use_ restriction rather than restriction of the creation of derived works in his new license. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
From: Dr. David Alan Gilbert [EMAIL PROTECTED] but also would need to give them rights to grant use licenses on the derivative? You directly license all users of your portion of the derivative work. The creator of the derivative work does the same. The alternative is to propogate a right to sublicense, which is more complicated so it's generally not handled that way. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
From: Russell Nelson [EMAIL PROTECTED] No, it doesn't. The GPL only has a few minor terms covering use. The GPL relies on the act of distribution for enforcing its conditions. And those conditions mostly hinge on the right to create derived works rather than the right to use. Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
My only concern is how this would interact with Larry's new license. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: a proposed change to the OSD
From: Dr. David Alan Gilbert [EMAIL PROTECTED] Well I was thinking about GPL on libraries since that restricts what you are allowed to link the library against; (No I'm not trying to get into an argument about the merits or not of this). Copyright law spells out a number of rights, including use and creation of derived works. GPL attempts to restrict the creation of derived works and contends that linking creates a derived work. This position is not a use restriction, but may not be enforcible in court - we need more cases to know for sure. Other licenses, like Larry's latest effort, do this with something that is more clearly enforcible but rely on a use restriction. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Revised versions of the OSL and AFL
I like the revised AFL. It's getting to the point where I may even use it. I have just one concern, and that is with the warranty of copyright which appears in both of these licenses. I think there must be a better way to achieve that - it smells like a cludge to me - but since I'm not a lawyer I won't venture any ideas. It would be very helpful for me (and I assume for some others) to see some public discussion of how / whether this warranty would work in practice. If a discussion like that happens here, I promise to stay out of it! Bruce - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 12:44 PM Subject: Revised versions of the OSL and AFL New versions of the Open Software License (OSL) and the Academic Free License (AFL) are now available for your review. They are posted at: www.rosenlaw.com/osl1.1.html www.rosenlaw.com/afl1.2.html Both licenses now contain an Attribution Rights provision. Other minor changes have been made to clarify the language and to make the licenses (a little) easier to read. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Moral Rights (was Simplified Artistic License (A Proposed Compromise))
I don't know if this is quite what Larry was saying, but I for one consider it an unfair tactic to try to discourage RSW from seeking approval. Russ and other board members may think he is misguided in believing that others will want to use his license, and might even be right, but that does not change your obligation to approve his license if it is OSD compliant. RSW he has shown a lot of patience, and has been flexible in incorporating requested changes (even those that have nothing to do with OSD). Nevertheless his mounting frustration has also shown through at times, and I empathize. For what it's worth, I think his license is better for having gone through this process. Once any remaining significant issues are worked out you should approve his license. That said, I think RSW might benefit from seeking some professional legal advice before requesting final approval, just to make sure that the license that gets approved is one that truly meets his needs. Question: can the OSI's approval process be changed so that OSD-compliant licenses are approved, but not automatically published on the website? i.e. 8. Once we are assured that the license conforms to the Open Source Definition and has received thorough discussion on license-discuss or by other reviewers, and there are no remaining issues that we judge significant, we will notify you that the license has been approved. At our discretion, we may also publish a copy of the license on our website. - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] I am unhappy with the current status of this request. Robert Samuel White (RSW) is absolutely within his rights to obtain approval for his license if it satisfies the published criteria on OSI's website. Russ Nelson is also absolutely correct in worrying, as do all members of the board of directors of OSI, about the proliferation of licenses that only serve to confuse and confound the community. -Original Message- From: Robert Samuel White [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 2:18 PM To: 'Russell Nelson' Cc: [EMAIL PROTECTED] Subject: RE: Simplified Artistic License (A Proposed Compromise) I've decided to just forget it. I'm going to use my license and forget about OSI approving it. I didn't want this much controversy. I was very patient and listened to every one's comments on the list, and I adjusted my license as recommended, all with the misguided belief that my license would be approved as long as it met the conditions of the OSD. I support OSI, the OSD, and the open source community. So I guess this is the end. Have a wonderful life and keep up the good work. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Procedure for using an approved license
For what it's worth, so far Netscape has been very responsible and careful about not making ad-hoc changes to their license. Look at the trouble they've been going to recently, to try and get all of their code MPL/GPL/LGPL tri-licensed. It would have been easy to take advantage of their right to change the license, to streamline this process, but they did not. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Moral Rights (was Simplified Artistic License (A Proposed Compromise))
You misunderstood me, Larry. I was not saying that YOU were trying to discourage RSW from pursuing approval. On the contrary I was surmising, without putting words in your mouth, that you'd agree that this would be unconscionable. As for Russ and others, I don't have any opinion on what they said. Too much was said in private email for me to form an opinion. I can only look to the result, which was an RSW discouraged to the point where he was ready to say have a nice life and walk away. Bruce - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Bruce Dodson' [EMAIL PROTECTED]; 'Robert Samuel White' [EMAIL PROTECTED]; 'Russell Nelson' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, October 06, 2002 9:00 PM Subject: RE: Moral Rights (was Simplified Artistic License (A Proposed Compromise)) I don't know if this is quite what Larry was saying, but I for one consider it an unfair tactic to try to discourage RSW from seeking approval. Russ and other board members may think he is misguided in believing that others will want to use his license, and might even be right, but that does not change your obligation to approve his license if it is OSD compliant. That certainly wasn't what I was saying, and I don't think it was what Russ and the other board members were saying. We've all said many times that, if RSW's license is OSD-compatible, it will be approved. I do recommend, however, that RSW seek an attorney's advice. I recommend that to everyone who wants to roll his own license. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: Modified Artistic License (eNetwizard Content Application Server)
In one of my licenses, I use the phrase the copyright holders and contributing authors instead of my own name, in the disclaimers. The BSD license says copyright holders and contributors, and the AFL goes one step further, saying licensor, contributors, and copyright owners. (I think licensor might be important for AFL due to the embedded patent license - the licensor might have a patent on the software, and might not be a copyright holder. However this is just a guess.) I am not a lawyer, Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
how NOT to form a contract? (second try)
I have published software under an MIT-style License, and I don't know if that makes a good contract or not, but I get the feeling that it's pretty vague, and that I might be better off to treat it as a permission notice and not enter into contracts with all my users. This ties back to recent discussions of click-wrap contracts, pros and cons. However, let's put that debate aside and think mostly about the GPL, where there is no debate about whether or not it should be used as a contract. (RMS says it should not.) I have in the past presented my license terms on the License Agreement page provided by my install builder. This page has a note saying if you do not accept, you cannot install this software. I have also seen the GPL presented that way. I still want to show the license terms during the install, but I don't want the user to see this as a click-wrap contract. To make it clear that I do not agree to enter into a contract with the person installing the software, I have been thinking about presenting it on a page marked Information rather than License Agreement, and prefacing the license with a note like the following: This software is protected by copyright law and is made available under the following license. The copyright holders do not intend for these license terms to form a contractual agreement. Does that make sense? Bruce (IANAL / YANML) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
I kept my own email short because I knew there were other people, better qualified to speak on this. Rod, thanks for stepping forward. You presented the facts more thoroughly than I could. By the way, although you say you disagree with me, I don't think I disagree with you. I'm not sure where that leaves us. My issue with Bernstein is that he presents his opinion as if it were historical fact. This is dangerous for the unsuspecting reader. One part of his opinion is that Microsoft's end user license agreements (and, by extension, all software license agreements) are not enforceable; that you can simply ignore the license terms and do whatever you want with the software. That part of his argument really doesn't hold water for me. From: Rod Dixon [EMAIL PROTECTED] Last point: I do not think anyone made the argument that open source licenses that are contracts are not enforceable. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
I thought that section 117 was about the right to crack a program's copy protection (if necessary) in order to make a legitimate backup copy. Well, that's an oversimplification, but I think it's closer to the truth than Mr. Bernstein's argument. It goes to show that you shouldn't believe every opinion that you read on the Internet. (Follow the references back to the source; the quotes under patches both seem to be taken out of context. If you read them in their intended context you might find that they don't support Mr. Bernstein's opinion nearly as well.) Bruce - Original Message - From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 6:59 PM Subject: Re: Legal soundness comes to open source distribution [ Catching up on mail from ten days ago ] Carol A. Kunze writes: Here is the theoretical difference between proprietary and traditional (GPL, BSD) free software. With the former the user agrees to a license and does not get title to the copy of the program. Without agreeing to the license (and the use restrictions in it), the user has no legal right to use the copy of the software that they possess but do not own. Basically, its a license transaction where the user has no ownership in the copy of the software they possess. My understanding is that, if you have legally acquired a copy of the software, you have the right to run it. http://cr.yp.to/softwarelaw.html Absent a contract otherwise, a user can do anything they want to their copy, including use it, modify it, give it away, or resell it to someone else. So why form a contract, then? To get a warranty disclaimer. To get the recipient to agree that they lose their patent grant if they sue for patent infringement. If we can get those things without a contract, that would be a perfect world. The question here is whether we should amend the Open Source Definition so that it is clear whether click-wrap licenses are allowable or not. We could go either way, but we want to hear from you first. Your opinions solicited, and engaged! OSI has already blessed licenses which are intended to be agreements or contracts (see IBM license), so I'm confused about what the point is here.And why OSI definition would have to change. Am I missing something? They're not enforcable, at least as I understand it. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Open Source Click-Wrap Notice
Er, I agree. :-). But, as an open source author, does the limitation of liability protect me? The contract that the end user clicked is between the distributor and the end user; does it protect the original developer, who is a third-party? (Or is the distributor is seen as an agent, facilitating a contract on behalf of each developer?) Good, common sense. That is why I suggested in the notice that you there be a simple procedure to review all the licenses... OSI-approved licenses. For many of us, that may be all we need to know without reviewing each license in detail. We will click on I AGREE knowing that we are agreeing to something reasonable. But we will still AGREE! /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open Source Click-Wrap Notice
Here, here. I agree completely that this would be absurd. Yet I still worry. Hopefully the law will eventually agree with us on this point. In Canada we have a good samaritan law; I don't know whether something like that exists in the USA. The good samaritan law says that, in an emergency, if you accidentally hurt the victim while you were trying to help, you can't be held liable. Although open source development isn't done in an emergency situation, it is done by many whose only goal is to help people, and who don't ask any compensation other than a nod of recognition. Wouldn't it be nice if, to the extent that open source development is an altruistic act, we were afforded the same kind of protection that a volunteer fire department gets? Sadly, wishing doesn't make it so. From: Carol A. Kunze [EMAIL PROTECTED] information on mushrooms would pass out of existence. The same would apply to open source. If developers are sued they'll stop writing free software. The idea of imposing liability for potentially millions of copies of a program for which the developer received no compensation is absurd. Please note - this is theory, not current law. _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open Source Click-Wrap Notice
Let me try to make it clear that I know the good samaritan laws don't apply to software or any other non-emergency situation - only for emergencies, where the time it takes to get a waiver signed could otherwise cost a life (or a house). I am also quite aware that liability has nothing to do with motivation - e.g. that if i give someone a lift downtown, and we get into a car accident, and my passenger gets hurt, I can be sued even though I was trying to be nice. Nevertheless the good samaritan laws are for the common good, and so would be a law that prevents someone from suing me for things I contribute to the open source commons. That is the extent of my analogy. I am not drawing any equivalence between the reasons why liability is inappropriate in these two situations. I am also aware that wishing for a thing doesn't make it true. I think we are on the same page. As for bandages vs. underlying problems: In open source, the need to have open source licenses seen as contracts, so that liability can be disclaimed, is a bandage. I'll take the bandage rather than expose myself to continued risk, but I hope the underlying problem will not be forgotten. From: David Johnson [EMAIL PROTECTED] Although open source development isn't done in an emergency situation, it is done by many whose only goal is to help people, and who don't ask any compensation other than a nod of recognition. There is a very good reason why the various good samaritan laws specify acts performed during emergency and/or urgent situations only. Liability, as I understand it, is unconcerned with the actor's motivation, but only with the results of the action. Good Samaritan laws are exceptions to the rules for exceptional circumstances. There are some good reasons for limiting liability for Open Source software. But the goal of helping people is not one of them. The good samaritan laws are bandages on a system that is slowly but surely being broken through abuse. We don't need more bandages, we need correct the underlying problems. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
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
Re: Legal soundness comes to open source distribution
On Sat, Aug 03, 2002 at 12:17:10PM -0700, Lawrence E. Rosen wrote: Bruce, are you going to respond to any of my other comments besides my expression of bafflement? Sure, no problem. Or are you going to simply blame me for the confusion and lack of legal understanding on the part of *some* of the leaders of the open source community about whether licenses are contracts? That is Brian Behlendorf of Collab.net you are talking about. His company offers training on Open Source licensing. HP buys it. If you are not getting through to Brian, backing up and starting again would be advised, because you are surely losing the rest of the audience. I invite you to address directly my argument that the MPL (and similar licenses) is clearly, obviously, without question or doubt, a contract and not merely a copyright license. Oh, I considered this so obvious that it wasn't necessary for me to comment upon it, and certainly I would not have disputed it. But it is peripheral to the issue of a warranty _disclaimer_, which like a copyright permission, does _not_ necessarily have to be in the form of a contract. The decision addresses a preliminary matter, specifically whether a license that contains an arbitration clause can be enforced against licensees. There are many license terms that I believe would require a contract. _Indemnification_ is one that is germane to this argument. Choice of venue and arbitration probably require a contract too. But I'm not convinced that a simple disclaimer of warranty requires a contract. Many of my clients (licensors and licensees alike) demand an arbitration clause in their licenses for the simple reasons of cost avoidance and risk reduction. Were I writing a proprietary software license, I would certainly ask for indemnification, choice of venue, an arbitration clause, and anything else that would be likely to hurt the other guy, and I would ask for them to be expressed in the most forceful possible way - I might even require internet registration so that I had confirmation that the licensee had agreed. After all, that sort of license is entirely one-sided - it's written for the copyright holder and nobody else. If I am able to express those terms at all when pursuing Open Source, I may not be able to express them with the greatest possible force, because they place an undue burden on the other participants, and are not likely to be accepted. This is simply the difference between a vendor-customer relationship and a partnership with a community. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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 view. Vendor-centric licenses are drawn with maximum possible terms to protect the vendor. Open Source licenses are drawn to protect the vendor as much as possible while still being practical and fair to redistribute and deploy throughout a broad community of users and derivative developers who are not motivated to accept an odious license. That means that we deliberately make some things easy - for example the act of copying and redistributing a software distribution, and installing and using that distribution. We may reduce the software producer's capability to defend themselves, by a reasonable amount, in order to achieve those goals. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Legal soundness comes to open source distribution
From: Rod Dixon [EMAIL PROTECTED] 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. I'd better clear this up. There was no proposal for click-wrap to be a a mandiatory requirement of the _OSD_. The question was whether or not the OSD should allow a license that requires click-wrap. I mantain that it's not appropriate for the OSD to allow it. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
[Whew!] I'm glad I checked this again before going to bed. From now on until this approval process is done, I will talk about my WILLINGNESS to make changes here on the list first, but I will not actually MAKE the changes until someone from OSI tells me whether that will help or harm my bid for license approval. Maybe that will help things go smoothly. (Russ: if we reach an impasse or if too many changes are required, then we can talk candidly, privately, about whether I should continue this bid or not.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
I made a revision to the SHPTRANS License Template. http://gisdeveloper.tripod.com/shptrans_license_template.html The changes are highlighted in the HTML. For those looking at the text version which Russ posted: I reversed the order of the first two conditions, got rid of the required brief notice, and replaced it with a required pointer to the complete license. Before, the notice distilled to This work is licensed under the license terms for this work, which should have accompanied this work. That was circular and, in a product using libraries under various licenses, probably ambiguous. Also, in the description of what I mean by complete license agreement I reversed the items disclaimers and provisions to provisions and disclaimers - not for any legal reason; it just sounds better that way. The first two conditions were: a. The above copyright notice must appear in all copies or substantial portions of the software. The copyright notice must be followed immediately by the complete text of this license agreement, or by the following brief notice: This work is distributed on an as is basis without warranty of any kind. For more information, and to understand your rights and obligations, please refer to the complete license agreement for software short name, which should have accompanied this work. The same license agreement applies to derivative works. This work may also be redistributed and/or modified under the terms of the GNU General Public License, version 2 or any later version, as published by the Free Software Foundation. b. A verbatim copy of this license agreement (including the above copyright notice, this permission notice, and the following disclaimers and provisions) must appear in the documentation and/or in other materials accompanying the software. They are now: a. A verbatim copy of this license agreement (including the above copyright notice, this permission notice, and the following provisions and disclaimers) must appear in the documentation and/or in other materials accompanying the software. b. The above copyright notice must appear in all copies or substantial portions of the software. The copyright notice must be followed immediately by the complete text of this license agreement, or by a pointer stating where the complete license is found. regards, bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
I thought this process was one in which the license is submitted for discussion, minor revisions are made if needed, and the license is eventually accepted or rejected. From your web page describing the approval process: 6. At the same time, we will monitor the license-discuss list and work with you to resolve any problems uncovered in public comment. How can one resolve problems if one is not allowed to change the license? Or, on the other side of the coin, how can you hope to work with me to resolve a problem, if I am not allowed to admit when changes might be warranted? And let's be realistic: my change was minor: it amounted to removing a requirement for a boilerplate notice pointing to the license agreement; replacing it with a requirement for a free-form pointer to the license agreement. The new form just makes it easier for the recipient / distributor to do the right thing and unambiguously identify the license terms. Anyway, you've made your executive decision. It seems clear that the wasted time was primarily mine. Lawrence made some useful comments today after he had already read about the change I made; no one (other than me) had made any comments at all up to that point. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: ESST license
If copyright statute says that all rights not explicitly granted are reserved to the copyright holder, doesn't that mean the user ought to have gone looking for a license to make sure they had the right to use it? If the premise is that you are not aware, then the assumption should be that you have no rights at all in the software. Trouble is that in some jurisdictions, the usage is not a right that can be restricted. It makes sense: If I receive a book, I can read it. If I receive software, I can use it. So that's why, in those countries, you can't assume the recipient read your license just because they exercised their right to use it. This is part of the reason why, for example, the GPL's teeth are attached to things like modification and distribution. For most people (except lawyers) this is not a problem - after all, what harm can an isolated end user do? Regards, Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: SHPTRANS License Template
So far there have been no comments on the list since I submitted this template for approval. I have tried to address the concerns raised in the previous discussions (copyleft lite? and simple copyleft...) Perhaps those who had suggestions for the previous versions could tell me whether I addressed their concerns adequately, and whether they see any new shortcomings in the current revision? Several of the comments from the previous iterations revolved around the question of GPL compatibility. To make sure I got that right, I sent a copy of the template over to the folks at FSF. They confirmed that, when the GNU Copyleft provision is included, a license created from this template is GPL compatible. So, that question is now put to rest and we can focus on the other aspects of the license, such as its ability to stand on its own. Regards, Bruce - Original Message - From: Russell Nelson [EMAIL PROTECTED] [ Please discuss this license. This version is different from earlier versions seen here. I have appended the license text to Bruce's email. Please note that the license must stand on its own, since GPL compatibility is an option, not a requirement. -russ ] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: discuss: WGPL (WebGPL)
I think the GPL itself would be fine for web pages, as long as you make it clear that your page content is source code as far as you're concerned. You can do that by putting the GPL's license notice in a comment block. But the trouble there, I guess, is that GPL's idea of linkage doesn't mesh with the web's idea of linkage... I think the GPL scope would end up extending to content that you embed (e.g. JavaScript files) but not to other pages that you link to. Has anyone looked at the Design Science License http://www.dsl.org/ as an open source license? It seems to me this would make sense for content that doesn't meet a strict definition of software in everyone's book (e.g. a web page) and would also work for parts of the content that are unambiguously software. - Original Message - From: Ken Arromdee [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 28, 2002 2:25 AM Subject: Re: discuss: WGPL (WebGPL) Does this license make it illegal to use an ad-filtering proxy on the page without accepting the license? After all, using an ad-filtering proxy copies and modifies the page, and it's not clear that this is 'running the Web'. What about putting the page on a site like Geocities which automatically modifies the code? Geocities ad-popup code is not GPL, after all. What exactly is a web page? More specifically, are framed content, inlined images, etc. considered part of the web page? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
thanks for helpful suggestions - (simple copyleft license template)
Thanks for your help with the license template, folks. Although my last few revisions have not generated any discussion on the list itself, helpful comments have continued to trickle in through private email. I have now submitted my license template to the OSI for approval. In case you want to look at the final draft, it's at this URL: http://gisdeveloper.tripod.com/shptrans_license_template.html http://gisdeveloper.tripod.com/shptrans_license_template.txt Thanks again, Bruce _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: open source applications with closed source components
If your program was written in Visual Basic, it would depend on the Visual Basic runtime, which is a framework. There are lots of open source applications written in VB. You should not include the proprietary components in your source kit, but should instead list them as requirements. It would also be best if you made a good-faith attempt to remove those requirements, or stated a willingness to accept patches which remove the requirements. For the convenience of end users, you can still include the proprietary parts in the binary distribution. Then your source kit would be for an incomplete program, but would be OSI Certified. There are lots of incomplete OSI certified products out there. Mozilla was incomplete when it was launched. In a few cases a closed-source requirement can remain in the software indefinately, and no one will object. For example, if your open source component is an Adobe Photoshop plugin, it may reasonably depend on Photoshop. (No one will be put out by this because the only people who would want that software are those who have Photoshop.) Although I haven't quite answered your question, I hope that helps. Bruce From: Edwin Zacharias [EMAIL PROTECTED] To: Bruce Dodson [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: open source applications with closed source components Date: Mon, 15 Jul 2002 16:59:28 -0400 MIME-Version: 1.0 (Apple Message framework v482) Received: from ns.crynwr.com ([192.203.178.14]) by mc1-f39.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 14:00:30 -0700 Received: (qmail 21484 invoked by uid 566); 15 Jul 2002 21:00:41 - Received: (qmail 21465 invoked from network); 15 Jul 2002 21:00:37 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Delivered-To: mailing list [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] X-Mailer: Apple Mail (2.482) Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 15 Jul 2002 21:00:30.0390 (UTC) FILETIME=[A72B6D60:01C22C42] On Monday, July 15, 2002, at 03:30 PM, Bruce Dodson wrote: Do your recipients have permission to distribute the two closed-source frameworks freely with their apps? For the sake of argument, lets say that the closed-source frameworks have to be purchased by the user. So, to run the binary you have to buy a closed-source operating system and two closed-source frameworks. Nothings stopping anyone from porting the source of my app to an open-source OS and open-source frameworks. It just hasn't been done yet. - Edwin -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: open source applications with closed source components
Do your recipients have permission to distribute the two closed-source frameworks freely with their apps? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
