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] 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: 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: 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
Open Standards: Principles and Practice
Please see http://perens.com/OpenStandards/ for a proposed policy on Open Standards. I will be submitting this to a number of Free Software organizations once it's done. The issue of patents in standards has come to a head, and I took some time to get this started. I am still working on the OSD change that we've been discussing, don't fear. There are a lot of standards organizations, and every one of them has a different definition of an Open Standard. Almost all standards organizations allow the incorporation of software patents, discriminatory licensing, or other features that seriously damage the open-ness of the standard. With the Debian Free Software Guidelines, later known as the Open Source Definition, we were successful in defining the terms of discourse for an entire industry. We're at that sort of cusp once more, but this time concerning Open Standards rather than Open Source. Of late, we have evidence of a number of companies attempting to use patents coupled with standards to erect toll booths on the Internet in a way that would, intentionally or coincidentally, exclude Free Software. As with the DFSG, it's time to draw a line in the stand and defend it. Thus, I am presenting to you the first draft of Open Standards: Principles and Practice. My intent is to refine this draft with community input, much as we refined the DFSG as Debian policy in a month-long discussion on Debian's private developer list. I made some mistakes with the DFSG text and the Open Source organization that I don't want to repeat - I'll be watching out for them, you do too. Please go to http://perens.com/OpenStandards/ . There is a link for the current draft, and a link for the disucssion list. Thanks Bruce Perens -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of
Thanks, Joyce. What I have suggested to FSF is that the definition of deploy, for their use, must be tightened up to only apply to the situations in which one would otherwise be pushing that source code button, and only for derived works. Thanks Bruce From: Joyce Chow [EMAIL PROTECTED] Sorry, I've only been following this thread for a bit and this is really not central to the discussion, but a clarification is needed: APSL Section 2.2(d) applies to any deployment of Covered Code (not just Deployed Modifications). The intent is that if you distribute APSL'ed code in only binary form, you need to tell the recipient that the corresponding source for it is available under the APSL and how to get it. I believe it's a fairly common concept that a number of open source licenses have. The actual language reads: (d) if You Deploy Covered Code in object code, executable form only, You must include a prominent notice, in the code itself as well as in related documentation, stating that Source Code of the Covered Code is available under the terms of this License with information on how and where to obtain such Source Code. - Joyce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
source code button
Richard and Eben, I feel that the draft GPL change for the ASP issue chooses the wrong balance point between the right to privacy and the right to modify. In my opinion, the correct solution would be to require publication of derived works, with one-time notification to FSF of the publication URL, when those works are deployed in the form of a service to others. I think you can make the language about this limited enough that there would be no more privacy issues than those that would be created by the source button. I am the creator of a GPL-ed embedded system: Busybox. I would not be able to use the source button on busybox because of the system size constraints. Embedded systems are subject to the ASP problem - Busybox is used for routers and appliance servers. But I really wouldn't want to use the source button on any of my software, because I feel it breaks the efficiency of the software to drag its source code around with each and every runnable copy. It feels awkward and kludgy. Source should live on a well-known internet server where it can be easily retrieved and archived. It doesn't need to be a ball and chain. I understand that you have criticized the APSL implementation of a publication requirement upon deployment. But your implementation can restrict deployment to just those situations where a user might push that button, and no others. The source button also seems to be too interface-specific to me. I can think of any number of services where there is not a direct user-interface in the form of an HTML form, etc., but just a set of RPC calls. It might be difficult to find a source button in that setting, even if one exists. I've gotten both HP and Prentice Hall to use your licenses, and I'm sure I've influenced many others to do so. My preference for GPL-like licensing is well-known. If _I_ don't want to use this license, I don't think you'd be very successful in finding other takers. Please go back to drafting. Thanks Bruce Perens -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of
From: David Johnson [EMAIL PROTECTED] You don't have the APSL quite right. Clause 2.2d only applies to Your Deployed Modifications. Clause 2.2d merely requires a prominent notice of the license for binary only deployments. It can only be triggered by the creation of a derivative work, since compilation is considered derivation. I prefer this to the proposed GPL change. A whole lot. Is there anything I should know before I write Eben and Richard to tell them that? Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
OSD modification regarding what license can require of user
out to be poison the well defenses. Thus, there seem to be a few sorts of requirement on the user that I think _should_ be permitted by the OSD. All of them are intended to further the goals of Open Source or Free Software. Can you think of more that should be added to this list? Thanks Bruce On Sun, Feb 10, 2002 at 11:35:15PM -0500, Russell Nelson wrote: Steve Mallett writes: On February 9, 2002 04:50 pm, Bruce Perens wrote: I'd be happy to write the first draft and coordinate comments and changes to it. Of course it would be a group project as I'd need to consult lots of people - attorneys, community leaders, a discussion list, etc. Cool. I suspect that some of the things I am worried about fail the current OSD under use restrictions, but not as explicitly as I'd like. There is much in the OSD which is insufficiently explicit. For example, we have maintained that there are no possible restrictions a license could put on users, because there is no possible mechanism one could use to constraint them, because no approved license can require that the user execute a license (OSD#7). It frightens me that no one has (on the list) bothered to ask what the additions might address. Bruce? Bruce isn't an idiot. He wouldn't propose additions we wouldn't be likely to accept. -- -russ nelson http://russnelson.com | Crypto without a threat Crynwr sells support for free software | PGPok | model is like cookies 521 Pleasant Valley Rd. | +1 315 268 1925 voice | without milk. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
To save time, can we just agree that I have absolutely horrible motives, that I'm a Microsoft plant, and that I'm reporting to the Illuminati, and get back to discussing the license? Well, if you had submitted the license without the manifesto attached, people would have considered the license rather than the manifesto. It seems to be your own fault. It looks to me as if 4(c) of the license fails OSD #7 because an open-to-closed transition is _required_ by the license, rather than by the license of the derivative work. If such a transition were to be optional, it might pass, depending on the language you use, but you would be effectively back to the BSD license. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
John Cowan: I don't understand how this breaches the spirit of the GPL any more than providing ASP-style access to the unmodified work does (i.e. not at all). If you are free to make private mods to GPLed programs for your own use, why not for others' use? This is just timesharing under a new name. Well, I could answer that in two, conflicting ways. If distribution becomes irrelevant, the spirit of the GPL in that respect is obsolete, isn't it? On the other hand, Richard treats this as a privacy issue. I contend that a publicly performed GPL work with a private implementation does indeed contradict the spirit of the GPL. Then, you get into the question of what is the entity in which privacy applies? In the GPL, it is the entity within which there is no need to distribute. This has always been sort of vague to me, because it's not clear if a corporation and all of its employees are a single entity, or if distribution takes place between employees, or between employees and the corporation. Then, bring in complications like consultants and companies working under contract but not part of the same legal entity as the corporation. Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
From: John Cowan [EMAIL PROTECTED] I don't see how that could happen, unless bandwidth (including the last mile) becomes too cheap to meter. Think about think clients and internet appliances. If a lot of people go to thin clients because they want to oursource their system administration, then the paradigm changes. It's not at all clear to me that when I send you bits, you massage them on your own computer, and you send me different bits back, that this constitutes a public performance of anything. You would not doubt that it was a public performance if those bits were a television broadcast. Suppose A publishes a GPLed book describing some arcane subject, and B obtains a copy of it. C now mails questions to B along with payment, and B answers the questions out of the book and mails back the replies. In principle, C could read the book himself, but may not have the time or desire.) Surely A's rights are not impinged on here? If B cut and pasted the answers _directly_ from the book, and did so to an extent greater than the simple occassional quoting within a larger work allowed as fair use, B would indeed be conveying a copyrighted work to C, and the license would apply. If B, on the other hand, conveyed the _knowledge_ rather than its representation as created by A, there would not be any conveyance of A's copyrighted work. But that's not really what we're talking about here. B is not answering C based on mere knowledge of the output of A's program. B is providing C with a means of accessing A's program as if C was the party to whom the work had been licensed. Although C can't see the source or binary code of the copyrighted work, it is executed upon his behalf, at his command, and he gains the benefit of its execution. Are things different if B adds his own marginal notes to the book? There is a boundary to fair use, I don't think marginalia would fit one within it. Is B really required by (the spirit of) the GPL to make those notes available to C? I submit that this is the case. But the implementation of copyright law and the current text of the GPL both leave a lot to be desired when this sort of question comes up. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
On Wed, Mar 13, 2002 at 10:24:02PM +, Thorsten Glaser wrote: Or A, to look from a different side on this? No. The terms of the GPL don't require you to give source code to the person to whom you distribute the binary. If you fail to do so, the copyright holder can sue you for infringement, but unless you manage to give the copyright holder a binary, they can't compel you to give the source code to them. Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
CORRECTION: Re: OSD modification regarding what license can require of user
Darn. I garbled. Delete the don't. The terms of the GPL require you to give source code to the person to whom you distribute the binary. And nobody else. The copyright holder can sue for infringement but can't compel the infringer to give the copyright holder a copy of the source code. He can compel the infringer to give the source code to the person to whom he gave the binary. Hopefully this parses better. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
From: John Cowan [EMAIL PROTECTED] To be concrete, suppose I provide a fast grepping service. Grep is an over-simple case, which might lead you to trivialize the problem. Consider Evolution, OpenOffice, or GNU Emacs. Postulate that someone makes a way for somebody to use one of those programs as if it were running natively on their computer, without ever activating the distribution terms of the GPL. And that same someone makes significant enhancements which he does not disclose in either source or binary form. Consider this from the perspective of the creator of Evolution, OpenOffice, or GNU Emacs. This person has put an immense amount of work out in the public with the expectation that improvements that are widely used would be distributed, and thus would be returned to them. And they aren't. Is this fair to them? I contend that this sort of activity should be placed outside of the covenant represented by the GPL. Richard and Eben don't necessarily agree with me - yet. One thing that we learned in deploying the OSD is that the world would surprise us, and that the language would end up being more important than we thought. I don't want to be surprised as much the next time around. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
From: Brian Behlendorf [EMAIL PROTECTED] Yep, like making it available through VNC, for example. A very clear violation of the spirit of the GPL; I'm glad you agree. but the grey area between this and the examples in the earlier messages seems very hard to divide between clear and non. It seems that the role of the user is key. Is the user running the program? Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of
Bruce wrote (in part) Is this fair to them? I contend that this sort of activity should be placed outside of the covenant represented by the GPL. Richard and Eben don't necessarily agree with me - yet. On Thu, Mar 14, 2002 at 12:37:06AM -0500, Forrest J. Cavalier III wrote: Is the goal here guaranteeing freedom of use, or is it trying to increase the amount of source which must be published? I'm not sure the FSF folks would make a distinction between the two. My concern here is that, as a result of those court tests of the GPL that have not yet happened, we may run up against a situation in which _copyright_law_is_inadequate_ to implement the GPL's agenda. And they may have to fall back upon contract law, including some form of tear-open license, and even one which applies to the user. Some say that they already have a tear-open license, due to the presence of the words you agree in the GPL. FSF would not make such a change lightly, and not soon. Richard is the most self-consistent person I know, and it would offend him to do this. But if it becomes necessary for them to go down that path, and the result ends up being non-OSD-compliant, this becomes another wedge between FSF and OSI. I've created enough schism around here, I don't want to make more. And I don't feel I can bet on OSI being agile enough to accomodate FSF when the need for change happens, so I want to leave the room now. At the same time, I don't want there to be a possibility of it being abused. But you could drop the entire GPL argument, and just consider indemnification of the developer and distributor by the user. No way are any of us going to accept liability for free software, we can't afford to do so. Yet there are various laws existing or in process that threaten us with just that. If it takes a tear-open license to protect ourselves from liability, I don't want to be left in the position of being constrained from using one. Bruce, I know you are at the collecting ideas stage, and discussing details and mechanisms under development may just be inflammatory at this point. But can you share some more of your thoughts? There isn't much more than what I have posted. If any of you would be more comfortable discussing this on the phone, you are welcome to call the number on my web site during 10 AM to 7 PM US-Pacific time. Going in the other direction (to allow OSI approval of licenses which are binding only under contract law, and not copyright law) is going to require sacrificing OSD #1, right? No, I don't yet see that. I think that most of the rights that you are concerned about are explicit in the OSD anyway, and in the licenses approved under the OSD, and don't really depend on whether or not the user owns their copy. It was my understanding that it can be hard to convince a court that a gratis download binds the recipient to a contract/license. (Because there is no consideration.) We're in good shape as far as liability is concerned if that works both ways. If these changes are made, the OSD will have to be expanded in order to explicitly require each license include the fair use and other permissions already in 17 USC, as well as explicitly prohibit other usage restrictions. Well, I am a little concerned that 17 USC is part of the _US_ code. In Europe they have this moral right of authorship which is not parallel to the way we do things here. Thus, I think we need some explicit language regarding the use permission in the license, for no other reason that it should apply across national boundaries. Is that kind of complex rewrite what you are considering? No, I want this to fit in one paragraph. This is something more than The license must not place any restrictions on use, but not much more. Something in the form of The only permissible use restrictions are X, Y, and Z. Goals that I can't fit in such a simple form will probably not be achieved. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
Bruce wrote (in part) So, what if it turns out that the present GPL doens't hold up with regard to dynamic linking? Some future version of the GPL might have to place a constraint on the user regarding combination of works on the user's system that would, if it were distributed in that form, be considered a derived work. I think that should be allowed by the OSD. On Thu, Mar 14, 2002 at 01:05:34AM -0500, Forrest J. Cavalier III wrote: Did you somehow mean constraint on the publisher regarding combination of works on the user's system? If we really _can_ implement this as a constraint on the distributor, rather than the user, that would leave us in _much_ better shape. Would you like to float some sample legal language to implement that? I have access to a legal staff to review it. If we can assure ourselves that it's possible, that leaves indemnification and the ASP problem. Indemnification is a must, IMO. The ASP problem, in contrast, is a wish-list item we could lose. freedom and requirement are direct opposites. Of course. I hope you accept that we _don't_ live in the libertarian utopia. Thus, some turning of the dominant legal structure upon its head is necessary. Our only avenue for doing that is the creative use of legal restriction. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of
On Thu, Mar 14, 2002 at 01:40:08AM -0500, Forrest J. Cavalier III wrote: The OSI approved the APSL, with clauses 2.2c-d, which require publication of sources upon deployment. Great. I'd like to hear comments upon the probability that this can be enforced, and the way the license must be presented to the user. So Bruce, (correct me if I am wrong), your goal is OSD changes which better ensure user freedom, but still allow approval of the APSL (and as-yet-unwritten licenses with clauses like you mentioned.) Yes about maximizing user freedom, and I can state the other half of that in a more positive manner: The quid-pro-quo between the original contributor and subsequent creators of derived works, as exemplified in the GPL but not limited to the GPL, is a critical component of Open Source. Open Source might well fail if it ever becomes impossible to enforce such a quid-pro-quo. It should _not_ be mandiatory that _every_ OSI-approved license stipulate a quid-pro-quo, only that it be possible to implement one within an OSI-approved license. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of
On Thu, Mar 14, 2002 at 02:21:52AM -0500, Forrest J. Cavalier III wrote: The rights to use the program must not be conditional, except for conditions on uses performed in service to any non-licensed party. Are you sure that this language works in context of OSD #7? Also, you should probably state it as a series of permissions followed by a negation of anything not explicitly permitted. A mistake of the OSD is that it says what you can't do rather than what you can. This allows for too many loopholes. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
Mitchell, A possibly naive question: The text you submitted is a _broad_ definition that is in common use. Is there a similar _narrow_ definition as well? I don't see that this text would be the right way for a quid-pro-quo license to define the legal entity in which distribution doesn't happen, because that entity would include beta-testers under contract, would it not? Maybe even _users_ under contract or NDA? On the other hand, there are applications in a quid-pro-quo license _would_ use this definition, Your Licensed Patents comes to mind. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
Unfortunately, the OSD is not very well written. Of course we had no idea, at the time, that the scope of application of this portion of the Debian Social Contract would grow so large. I think that we'd better fix this particular problem regarding use before we get to the more pervasive issues of the OSD. I am willing to attack those, and can get some money and attorney resources to do so, but it would be a longer haul. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
From: Steve Mallett [EMAIL PROTECTED] On February 9, 2002 04:50 pm, Bruce Perens wrote: It frightens me that no one has (on the list) bothered to ask what the additions might address. Bruce? Badgeware, snoopware, etc., where the requirement is attached to _use_. IMO these already fail the OSD, but not explicitly enough. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
From: Russell Nelson [EMAIL PROTECTED] Bruce Perens writes: I think there needs to be language added to the OSD, protecting the user and developer from odd burdens that the licensor wishes to impose upon them. Russ Nelson: Are you volunteering to write this language yourself, or volunteering someone else? I'd be happy to write the first draft and coordinate comments and changes to it. Of course it would be a group project as I'd need to consult lots of people - attorneys, community leaders, a discussion list, etc. I suspect that some of the things I am worried about fail the current OSD under use restrictions, but not as explicitly as I'd like. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
Someone please tell Russ his qmail is rejecting me. Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
On Mon, Jan 21, 2002 at 09:34:10AM -0800, Lawrence E. Rosen wrote: But I still have a concern. I have always argued that we should review and approve licenses according to a published standard. This prevents us from being (or appearing to be) arbitrary and capricious. So where in the OSD, or in the GPL, do we make it clear that potentially burdensome license requirements (however those are defined) are not allowed? Larry, I'm not sure we can create a definition of burdensome, even in statutory language, that would be sufficient for inclusion in the OSD. However, you can make it part of the published role of the OSI board to review proposed licenses for undue burden on the developer and user, and you can give some examples - the combinatorial problem, user burdens such as badgeware, etc. This is an activity that the OSI has previously carried out well, and I most strongly urge that they should continue to do so. To fail to do that will inevitably lead to all sorts of perversions of Open Source as people figure out creative loopholes. I do not believe, and never have, that any version of the OSD should be applied as an automated process. Do courts never consider the spirit of the law? I think you are coming at this from an urge to eliminate any possible litigation situations in which an OSI decision is challenged. There has to be some risk, but you can still make this a fruitless game for the challenger without decerebrating the license approval process. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
Are you assuming that they will not admit new ones? After my conversation with Larry today, and getting a better idea of the way he wants the license approval process to work, I'm going to change my stance. I think there needs to be language added to the OSD, protecting the user and developer from odd burdens that the licensor wishes to impose upon them. These burdens are mostly not directly connected with software development. For example: usage-reporting, or taking attribution to a greater level than simply putting developer's names with the software license on a disk where the end-user or creator of a derived work can read them. Such language needs to be general enough to admit whatever new burdens people decide to invent. You should not be asked to bind the developer's name as a sign on thy hand and as frontlets between thy eyes. Thanks Bruce On Mon, Jan 21, 2002 at 10:39:42PM -0700, Richard Stallman wrote: So where in the OSD, or in the GPL, do we make it clear that potentially burdensome license requirements (however those are defined) are not allowed? I recommend you allow them but deprecate them. That is what we do. We always did recognize the old BSD license as a free software license, but we said people should avoid it because of its annoying practical consequences. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Advertising Clauses in Licenses
On Sun, Jan 20, 2002 at 12:07:53PM -0800, Lawrence E. Rosen wrote: I am unmoved by this perceived threat to free or open source software. Perhaps you've never had to put together a Linux distribution, or an embedded Linux product. Consider the overhead this places on Debian, which has up to 5000 packages in a distribution. Some volunteer has to go through and check each of those 5000 packages for an acknowledgement requirement with every release, and make sure that the end-user documentation stays in sync, which is one less person making free software for a pretty long time. The individuals and communities who create free and open source software deserve to receive credit for their contributions. Is it asking too much to require the authors of derivative works to acknowledge the contributions through simple notices? Every package generally gets to publish its credits in the place in the user software, where the online copyright statement is kept. This can be managed automaticaly, so it's not a hassle. But to put it in the user manuals and advertising can become quite a burden. One of the goals of the OSD was to have software that the user could run without having to read the license or take any special action. Note that this is the user, not the creator of a derived work. But if the software licenses ask the user to put badges on their home page, that really blows the premise that the user can run it without having to investigate anything. Suppose the list of contributions grows long. Is it expecting too much for the authors of derivative works to include a text file listing those contributions along with the software? No, not as long as it can be handled automaticaly, as with the files in (on Debian) /usr/share/doc/package-name . Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: NCSA Open Source License
On Thu, Jan 17, 2002 at 02:38:20PM -0800, Lawrence E. Rosen wrote: Bruce, the so-called advertising clause in the Apache license is extremely important. As I stated in one of my columns in Linux Journal, trademark protection is, in some respects, even more important to open source companies than copyright protection. Hi Larry, You saw advertising, and read trademark. But these are separable issues. I agree with you regarding the importance of trademark protection. That's why I wrote the integrity provision in the OSD. The obnoxious advertising clauses concern me, such as the _original_ BSD/Apache advertising clause, which really is deprecated by both U.C. Berkeley and the Apache project. Badgeware is even worse, because of its potential combinatorial effect - 1000 badges on my homepage. OSI has (wisely) resisted badgeware so far. In accepting trademark-protecting licenses, the names of protected trademarks should be in template form. Otherwise, you could easily have to review and accept 500 versions of the Vovida license, with only names varying between each version. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
NCSA Open Source License
I am corresponding with NCSA regarding some work Open Source work that they would be doing with partial funding from HP. One of the Open Source licenses they use is the BSD license, but with the preliminary paragraph of the MIT license replacing the BSD preliminary paragraph. This creates a somewhat more explicit grant of rights than the BSD version, but they are the same rights. Although the NCSA license is not currently OSI-accepted, it combines acceptable elements of two other OSI-accepted licenses. There are currently at least 4 variations of the MIT license on OSI's accepted list: MIT, BSD, Apache, X.com. I don't want to suggest that NCSA petition OSI to accept yet another variation. While OSI and friends have given up on the prospect of generating a unified Open Source license, it appears that it would at least be possible for OSI and the community to drive unification of the MIT variants into a single license with two optional portions: the generally-deprecated advertising clause used by Apache, and the choice-of-jurisdiction used by X.com . Thanks Bruce Perens -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: NCSA Open Source License
That would be three licenses, I think. OK - one might consider that it's one license _text_ rather than 4, but yes it's three licenses. Is it possible to sucessfully lobby Apache to get rid of the advertising clause? They probably have enough experience now to see it's had no positive effect. Then we are down to two, with the sole optional portion being choice-of-venue. Venue is problematical - OSI has accepted a license specifying California. If an applier of the X.com license changes that to their own home state other than Calfifornia, it's no longer an OSI-accepted license. But I don't think OSI really has preferences for one state over another. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: NCSA Open Source License
Yes, I saw the present advertising clause. It's close to being a no-op, but if you want it there, I guess I can't make much headway in this. Well, what do you folks plan to do when faced with yet another BSD/MIT license? Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: NCSA Open Source License
From: Russell Nelson [EMAIL PROTECTED] Approve it. We judge licenses by one set of criteria: the OSD. We do, it is admitted, sometimes attempt to convince people to use an existing license. Feel free to try this with NCSA. Yes, I'm trying. I will probably bring you folks in to help at some point. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Spirit of OSD - was[Fails OSD #1.]
On Tue, Nov 13, 2001 at 09:26:53AM -0400, Steve Mallett wrote: While its not 'statutory' do you still consider it the 'definition' of open-source? Yes. Indeed, I don't believe a statutory-language definition would work as a manifesto, the way the OSD does. Imagine if the declaration of independence had been written in statutory language. I don't believe it's possible to make a legal document without taking the romance out of it. Recognizing the weaknesses (and strengths) of speaking in symbolic terms. Is there anything _else_ that you feel helps define the 'spirit' of the OSD? Writings, postings etc The Debian Social Contract - the OSD is derived from part of that. My old paper on the OSD at http://perens.com/OSD.html . *I apologize fully for sounding like a philosophy prof. No problem. The license attempt that started this thread is did remind me of a certain sophomore philosophy exercise. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Fails OSD #1. [Re: OSD compliant shareware]
Hi Forrest, I think it's possible to create any number of licenses that violate the spirit of the OSD while following the letter. However, I don't think this example is one of them. Your #4 doesn't pass OSD #1, which requires that sale be permitted. It's been pointed out that: 1. The OSD is not written in statutory language. 2. That it says what you _can't_ do rather than what you can and thus makes it easy to find loopholes, because there is an unbounded set of activities that it does not restrict. 3. That it was created before we had any experience interpreting it and before there was a DMCA at all. It still makes a _wonderful_ manifesto, its success speaks for that. But to apply it blindly would be foolhardy. I imagine that there is an unbounded set of licenses that appear to be OSD-compliant yet are so pernicious in their terms as to be outside of the spirit of the OSD. I haven't read the decision in MAI vs Peak, but DMCA itself is up for review and if the case really is definitive, it's questionable that it will remain so. Thanks Bruce On Tue, Nov 13, 2001 at 05:00:32PM -0500, Forrest J. Cavalier III wrote: Bruce, In September 2001 on the [EMAIL PROTECTED] mailing list, there was a posting referencing the appeal court ruling of MAI vs Peak. It is the understanding that parts of the ruling were overturned by the DMCA, (specifically adding an allowed use at 17 USC 117 (c)) But one of the opinions in the ruling is troublesome to the OSD. I understand the OSD is written with the assumption that the use of software is protected by 17 USC 117, (one copy is at http://www4.law.cornell.edu/uscode/17/117.html), which allows the owner of a copy to make copies (into RAM for example) for the purposes of running the program. Buried in the MAI vs Peak decision, (one copy is at http://www.law.cornell.edu/copyright/cases/991_F2d_511.htm) is the statement that a licensee is not an owner, and 17 USC 117 protection would not apply. (See the footnote 5.) 5. Since MAI licensed its software, the Peak customers do not qualify as owners of the software and are not eligible for protection under 117. This means the copying of the program into RAM is governed by the terms of the license. I have written what I think is an OSD compliant shareware license (below), and some on the license-discuss list were unable to use the OSD to reject the license. (Some even said that maybe the OSD was supposed to permit this kind of shareware.) I am writing in the hopes that you could share - insights into the creation of the OSD, (why it did not explicitly protect the right to use,) - and how (if?) the OSD should best be amended to address the issue of use, assuming 17 USC 117 is not applicable permission. Thank you. Forrest J. Cavalier III Mib Software Open Source Shareware The trick is to distribute the shareware as source only. In that case, in order to run it, it must be compiled, and (unless you are compiling and linking in memory), that creates a derivative work, a right reserved to the copyright owner. Then use the GPL method of forcing a license agreement without signing one. (Clause 2 and 4 are the interesting parts. Parts are heavily borrowed from other licenses.) The one improvement needed is that someone could make a binary, pay the $20, and then users of that copy would not have to pay. (They accept the license only when they made a copy or derivative work.) There would have to be a copyleft clauses too, so that the license on the binary would be preserved. (I left that out for easier reading.) To head off OSD #7 objections, under this license running is not a right attached to the program. If you own the copy, that right is supplied by 17 USC 117. If you accept the license, that right is supplied by paying the $20 fee. - Copyright (c) year copyright holders 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty, and agree and comply with the terms of this license. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may compile this into an executable form, or modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above. 3. You may not copy, modify, sublicense, or distribute
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
Greg London [EMAIL PROTECTED] wrote (in part) It seems to me that the MIT does not meet item #2 of the OSD, then. An Open Source license is _not_ required to prohibit someone from making a version of the software that is closed source. And since someone can do that without changing the license, simply by refusing to distribute source, we needed to talk about more than just the license. The MIT license very definitely allows source code to be passed on, and if a version of a MIT-licensed program includes source code, it is an Open Source program. In general, people who don't distribute the source change the license to All Rights Reserved, but they don't have to. So, it's pretty clear that there can be MIT-licensed programs that are not Open Source. Thus, we really do need to make a distinction between the _license_ and the _product_. In my reading (and yours too), it is possible to distribute software under an OSI certified license, and fail to meet OSD #2. That is correct. Having source code is a required condition, over and above the license language, for a program to be Open Source. That seems like a problem which should be discussed somewhere. Not really. The license is OSI-certified. The fact that available source code does not exist means the program is not Open Source, despite the fact that the license which has been applied to it is OSI-certified. This is also the case for Public Domain software, for which we clearly _can_not_ change the license, because there is no license. Both the MIT license and Public Domain fit under both the OSD and RMS's definition of Free Software, and to change the OSD to exclude them would be a travesty. What should be done about it? Explain this issue in the OSD commentary. Is the OSI going to certifying distribution mechanisms as well as licenses? (Unlikely) I don't think it's necessary over and above the current simple statement that there must be source. It's pretty clear that if the program doesn't include Source, it's not Open. It hardly seems likely that the BSD and MIT, (et al) licenses which don't guarantee downstream source are going to be decertified. Remember that the definition was written to fit the licenses, not the other way around. We had the BSD, GPL, Artistic and Public Domain, and we were sure they were Free Software. Then we needed to set down what Free Software was so that we could figure out what other licenses were suitable for inclusion in Debian. Does OSD #2 need to be reworked? I don't think so. I hope that Bruce can comment on this point. Be careful what you wish for :-) Actually, even the GPL does not prohibit a particular form of proprietary work. If you _never_distribute_ your GPL derivative, it can be proprietary. Thanks Bruce -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Simple Public License, Please Review
From: Justin Wells [EMAIL PROTECTED] Subject to your license, recipients may use the work on one or more computers, and may create backup copies of it, but may not otherwise copy, distribute, lend, sublicense, or adapt it. Just reading this piece in isolation, I would think it fails the OSD paragraph 7, but I think you mean it to apply to someone else's code, not yours. Right? Thanks Bruce
OSI board asleep at the switch?
I submitted a Novell license for certification to
[EMAIL PROTECTED] a month ago. To date I have seen not one
reply from the OSI board. Someone at Novell was able to contact Brian
Behlendorf directly yesterday, and got him to review the license in question.
But mail to [EMAIL PROTECTED] seems to be going into /dev/null .
Previously, I submitted the ATT license (which had been accepted by the regular
commentators of the license-discuss list after a round of changes) and found,
months later, that nobody from OSI had been reading license-discuss, and thus
they missed the submission. The license-approval mailing list was created to
address that problem, after it became clear in a discussion with the OSI board
that the license approval procedure wasn't clearly stated.
I called Peter Deutsch to discuss this yesterday, but found that he has
dropped off of the OSI board. This wasn't announced. Perhaps I am looking
in the wrong place, but I can't find the OSI board roster on the web site.
The OSI board has responsibilities to the entire free software community and
every one of its members. They need to work harder to stay on top of them.
A mail log of the messages in question is attached to this message.
Thanks
Bruce Perens
From bruce Tue Apr 4 11:54:52 2000
To: [EMAIL PROTECTED]
Subject: Mail to license-approval getting lost?
Hi,
I have signed an agreement to operate as a consultant to Novell. In
that capacity I sent you guys a license for approval. I have seen no
acknowledgement of my message whatsoever. A query I sent about the
message was similarly unanswered.
We've had a problem before where you guys turned out to be not reading
license submissions. I hope that's not what is happening now.
I would like to hear whether or not OSI has problems with the license
I submitted, so that I can fix any issues with which you have difficulty.
Thanks
Bruce
From bruce Fri Mar 31 13:18:55 2000
To: [EMAIL PROTECTED]
Subject: did you guys drop the ball
Hi,
I sent this Novell license revision in to [EMAIL PROTECTED]
a while ago and got one feedback from license discuss but absolutely nothing
from the board. Did you guys drop the ball?
Thanks
Bruce
From [EMAIL PROTECTED] Wed Mar 8
11:43:01 2000
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from ns.crynwr.com (unknown [192.203.178.14])
by perens.com (Postfix) with SMTP id 3AFF61FF001
for [EMAIL PROTECTED]; Wed, 8 Mar 2000 11:43:00 -0800 (PST)
Received: (qmail 8284 invoked by uid 566); 8 Mar 2000 19:43:07 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 8275 invoked from network); 8 Mar 2000 19:43:06 -
Date: Wed, 8 Mar 2000 11:42:26 -0800
From: Bruce Perens [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Novell license revision
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu"
User-Agent: Mutt/1.0.1i
Sender: [EMAIL PROTECTED]
Status: O
--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
The enclosed Novell license revision is submitted for OSI approval and
public discussion.
Thanks
Bruce Perens
--sdtB3X0nJg68CQEu
Content-Type: application/pdf
Content-Disposition: attachment; filename="Novell.pdf"
Content-Transfer-Encoding: base64
JVBERi0xLjINJeLjz9MNCjYgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDkgDS9IIFsg
ODExIDE2NiBdIA0vTCA4OTE0IA0vRSA2MjY3IA0vTiAyIA0vVCA4Njc3IA0+PiANZW5kb2Jq
DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB4cmVmDTYgMTMgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDYyMCAw
MDAwMCBuDQowMDAwMDAwNjczIDAwMDAwIG4NCjAwMDAwMDA5NzcgMDAwMDAgbg0KMDAwMDAw
MTE3OCAwMDAwMCBuDQowMDAwMDAyMjc5IDAwMDAwIG4NCjAwMDAwMDI1NTkgMDAwMDAgbg0K
MDAwMDAwMjgyOSAwMDAwMCBuDQowMDAwMDAzOTI2IDAwMDAwIG4NCjAwMDAwMDYwMjMgMDAw
MDAgbg0KMDAwMDAwNjA0NSAwMDAwMCBuDQowMDAwMDAwODExIDAwMDAwIG4NCjAwMDAwMDA5
NTcgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxOQ0vSW5mbyA0IDAgUiANL0VuY3J5cHQg
OCAwIFIgDS9Sb290IDcgMCBSIA0vUHJldiA4NjY4IA0vSURbPDM1M2VmYjgxZDQyNzBkZTUy
NDljYzFmYTlkZmU2Yjc3PjwzNTNlZmI4MWQ0MjcwZGU1MjQ5Y2MxZmE5ZGZlNmI3Nz5dDT4+
DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgIA03IDAgb2JqDTw8IA0vUGFnZXMgNSAwIFIgDS9U
eXBlIC9DYXRhbG9nIA0+PiANZW5kb2JqDTggMCBvYmoNPDwgDS9GaWx0ZXIgL1N0YW5kYXJk
IA0vViAxIA0vUiAyIA0vTyAoIFXHVscuGtcCYI6BlqytRHrTLRfP9YMjX23RX+19q2cpDS9V
ICghx/Z5UaL1OPftw4ySuqPDX+Ok5VOFj+82QL6oXo+9yCkNL1AgLTYwIA0+PiANZW5kb2Jq
DTE3IDAgb2JqDTw8IC9TIDQzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTggMCBS
ID4+IA1zdHJlYW0NCrirf0+pzY9GFyuaT14M8iZ1/j04vIRBXQGvvJmvhE+hHhi6bLDG1+cx
6GK8Ch3xbJS6f+UXPO43LRoTzZRGDWVuZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmoNNjIgDWVu
ZG9iag05IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA1IDAgUiANL1Jlc291cmNl
cyA8PCAvRm9udCA8PCAvRjAgMTAgMCBSIC9GMSAxMyAwIFIgPj4gL1Byb2NTZXQgMTYgMCBS
ID4+IA0vQ29udGVudHMgMTQgMCBSIA0vTWVkaWFCb3ggWyAwIDAg
Re: OSI board asleep at the switch?
I'm told privately that this is incompetence and not conspiracy. But that doesn't make it any less of a problem. We need to track this. Thanks Bruce
Re: OSI board asleep at the switch?
OK, I stand corrected about the board listing. Thanks Bruce
Re: OSI board asleep at the switch?
From: "Matthew C. Weigel" [EMAIL PROTECTED] I am hoping also that the difficulty so many have had with unsusbscribing is due to similar issues. That's up to Russ Nelson [EMAIL PROTECTED] . Since he sells commercial support for the list manager program, he should be able to fix it :-) Thanks Bruce
Re: Simple Public License, Please Review
For the sole purpose of taking action against an infringer of our copyrights, including actions seeking remedies, compensation, or the recovery of damages, anyone engaged in the lawful distribution of our software shall be considered a beneficial owner of the rights to copy and distribute it, and therefore has the authority to pursue such actions. It sounds as if you're attempting to assign the right to prosecute an infringement of a right that the prosecuting party doesn't own. It's so much of a doublethink that I doubt any court would accept it. You're going to need an attorney to have the slightest chance of making this work. Thanks Bruce
Novell license revision
The enclosed Novell license revision is submitted for OSI approval and public discussion. Thanks Bruce Perens Novell.pdf
Re: Proprietary software for Linux
From: Mark Wells [EMAIL PROTECTED] How is that different from writing something and assigning the copyright to your employer? If you write something and assign the copyright to your employer, you are operating under the assumption that such an assumption is _necessary_ because your employer's ownership of your work is less than complete. This might be a consequence of your employment agreement, for example. But if you have not negociated otherwise, assignment of your work to your employer is meaningless because your employer already owns the work that you do for hire. It was never yours to assign. Bruce
RE: Proprietary software for Linux
From: Mark Wells [EMAIL PROTECTED] Legally these contributors are probably considered to be assigning their rights to the copyright holder. Not at all. They are all individually copyright holders as long as their contribution is non-trivial (over 10 lines), and any one of them can sue for infringement, or they can do it together. Assignment of copyright doesn't happen unless you deliberately write down and sign that you are assigning the copyright. It does not happen by contributing a modification to GPL software. If I contribute code to a project that's under the GPL, I'm doing it with the understanding that the GPL will protect my code. There might be an implied contract here. If I'm *not* assigning my rights to the copyright holder, then I'm licensing my own code under the GPL, and if I can show that any of it made it into the part of the project that's in dispute, I have standing as a copyright holder. Right. You can be the one to sue, but if your code can be "written out" easily it is to your advantage to band together with other copyright holders to make a stronger case. Thanks Bruce
Re: Proprietary software for Linux
From: Mark Wells [EMAIL PROTECTED] Anyway, transfers of copyright don't require a formal contract--work-for-hire is an obvious counterexample. When you work for hire, your work is in general owned by the person who hired you to do the work, unless you negociate otherwise. This is _not_ a transfer of copyright - you never did own it in this case. Thanks Bruce
Re: the skinny -- a LEGAL *nightmare*
From: Nelson Rush [EMAIL PROTECTED] It's obvious this draft wasn't written up by a lawyer A lawyer is very definitely involved. I agree that "Distribute the distributions" is poor language, but you're going overboard in your condemnation. You've got some valid points in there, I see no reason to flame you to high heaven except for one thing. Don't begin a negociation by calling the other party an idiot. That is what you imply in your grammar criticism. Consider that they are under time pressure and are in unfamiliar waters as far as Open Source is concerned. Cut them a bit more slack, please. As far as I've seen, they want the project to work and want to play by our rules. Thanks Bruce
Novell Cooperative License version 1.0
Here's the draft Novell license. Please note the arbitration and attorney's cost issue. I'd like to hear arguments about its fairness or lack therof. After we're finished with the public review and possible editing cycles with Novell, I will submit this to the OSI board for certification. Note that _I_am_not_ the person who determines OSI certification. I make recommendations which they are free to ignore. Thanks Bruce Novell Cooperative License 1.0 (NCL) 1. A Contributor is an individual or organization that makes code available under the NCL by placing a Notice in computer programming code or documentation (Contributions). A Notice states that the Contributions are being made available under the NCL, and follows the format provided in Exhibit A hereto. 2. Subject to the terms and conditions of this NCL, each Contributor to the software grants you a worldwide, royalty-free, non-exclusive license under its applicable intellectual property rights to use, reproduce, modify, display, perform, sublicense and distribute the Contributions and derivative works thereof, in source and binary code form. 3. In consideration of, and as a condition to, the licenses granted to you under this license, you agree to comply with the each of the following requirements with respect to any distribution by You of the Contributions and/or derivative works thereof, in source code or binary code form (Distributions): 1. If you distribute the Distributions in binary code form, then you must make the Distributions available in source code form to all binary code licensees via a generally accessible distribution mechanism, such as installation media or a well-known, publicly accessible web site; 2. You may distribute the Distributions in source code form only under the NCL, and you may distribute the Distributions in binary code form only under the NCL or a license agreement containing a prominent notice informing recipients how to obtain the Distributions in source code form under the NCL; 3. If the Distributions contain derivative works created by you, you must place a Notice in the source code of the derivative works stating that your derivative works are being made available under the NCL; 4. You shall not remove notices from the Distributions; 5. Neither Novell's trademarks or trade names, nor the trademarks or trade names of any Contributors, may be used to endorse or promote products derived from this software without specific prior written permission; and, 6. Your distribution of Distributions must be in compliance with relevant law and government regulations. 4. Novell may publish revised versions of the NCL from time to time; you may license Contributions under this version or any subsequent versions. If You modify the NCL, you must remove all references to Novell other than a prominent notice that your version contains different terms than the NCL. 5. If you fail to cure a material breach of this Agreement within sixty (60) days of receipt of written notice from a Contributor, you and the Contributor shall immediately submit to binding arbitration to be completed within six (6) months in compliance with the rules of the American Arbitration Association before an arbitrator competent in the field of computer law. Any determination by the arbitrator shall be final and binding on all parties and may be entered as a final judgment in any court of competent jurisdiction. If the Contributor prevails, You shall pay the Contributors costs and attorneys fees, and the licenses granted to you by the Contributor shall be revoked unless you cure the breach within a reasonable time specified by the arbitrator. If you prevail and the Contributors allegation of breach was brought in bad faith, the Contributor shall pay your costs and attorneys fees. 6. THE LICENSES GRANTED HEREUNDER ARE GRANTED ON AN "AS IS'' BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES THAT THE CONTRIBUTIONS ARE FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. Notwithstanding the foregoing, each Contributor represents that to the best of its knowledge the Contributor has sufficient rights to grant licenses to its contributions as conveyed by the NCL. 7. IN NO EVENT SHALL NOVELL, YOU OR ANY OTHER CONTRIBUTOR 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). SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU. EXHIBIT A NOVELL COOPERATIVE LICENSE NOTICE The
graphviz license
I think we came to a satisfactory close on the graphviz license a while back. Has OSI voted on it? Thanks Bruce
