Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
Quoting Chad Perrin (per...@apotheon.com): You seem here to be saying Let's not worry about it. You'll get sued, or you won't. There's no perfect answer, so don't bother trying to come up with somewhat better answers. That is not what I said, and very far from what I meant. And you actually know that, but desire to waste everyone's time anyway. What I meant included things like 'People in general and very large corporations have no problem deploying open source software including codebases under popular reciprocal licences without infringing copyrights, through the simple expedient of not attempting to play aggressive brinksmanship games with property rights. Someone else might volunteer to give random coders free legal advice about whereexactly the brink is, but I have many better things to do with my time.' ___ 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
Quoting Chad Perrin (per...@apotheon.com): I think the point was [...] I believe I was having a discussion with Chris Travers. Didn't I ask you to kindly go away and chew up someone else's time? ___ 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
-Original Message- A truly independent open source software developer probably has nothing to fear other than personal embarrassment. It is the larger companies, including acquirers or consolidators of open source software and the corporate users of that software, who need to undertake due diligence. For them, reading and understanding open source licenses isn't rocket science; it is merely a cost of doing software business. These companies already pay for lawyers to advise them, as they should. :-) Larry, I don't disagree with this, but I feel obliged to point out that truly independent open source softare developers sometimes make available combinations of code which violate license terms. And their work is then included in the work of others. Given the ease with which open source code can be transmitted and re-combined in today's world, the failure of one is quickly amplified by many. This leaves consumers - whether they be corporations or downstream OSS organizations - in the position of identifying and addressing their errors. I am not suggesting that there is a solution to this. I just wanted to make it clear that it is a big problem, not a small one. Unfortunately, I've never seen an attempt to collectively share the results of due diligence work, so the effort is wastefully replicated by each and every consumer. ___ 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
Mike Milinkovich wrote: I don't disagree with this, but I feel obliged to point out that truly independent open source softare developers sometimes make available combinations of code which violate license terms. And their work is then included in the work of others. Given the ease with which open source code can be transmitted and re-combined in today's world, the failure of one is quickly amplified by many. This leaves consumers - whether they be corporations or downstream OSS organizations - in the position of identifying and addressing their errors. I am not suggesting that there is a solution to this. I just wanted to make it clear that it is a big problem, not a small one. Unfortunately, I've never seen an attempt to collectively share the results of due diligence work, so the effort is wastefully replicated by each and every consumer. I agree with you about the problem. I have repeatedly suggested that Apache do code scans on its distributed software so that every downstream customer doesn't have to do it. But we have neither the interest nor the money to deal with hypothetical problems in a volunteer environment. We exercise diligence, but it is rather ad hoc. How does Eclipse help solve the problem for its software? /Larry -Original Message- From: license-discuss-boun...@opensource.org [mailto:license-discuss- boun...@opensource.org] On Behalf Of Mike Milinkovich Sent: Friday, March 02, 2012 11:24 AM To: license-discuss@opensource.org Subject: Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process -Original Message- A truly independent open source software developer probably has nothing to fear other than personal embarrassment. It is the larger companies, including acquirers or consolidators of open source software and the corporate users of that software, who need to undertake due diligence. For them, reading and understanding open source licenses isn't rocket science; it is merely a cost of doing software business. These companies already pay for lawyers to advise them, as they should. :-) Larry, I don't disagree with this, but I feel obliged to point out that truly independent open source softare developers sometimes make available combinations of code which violate license terms. And their work is then included in the work of others. Given the ease with which open source code can be transmitted and re-combined in today's world, the failure of one is quickly amplified by many. This leaves consumers - whether they be corporations or downstream OSS organizations - in the position of identifying and addressing their errors. I am not suggesting that there is a solution to this. I just wanted to make it clear that it is a big problem, not a small one. Unfortunately, I've never seen an attempt to collectively share the results of due diligence work, so the effort is wastefully replicated by each and every consumer. ___ 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] [License-review] CC withdrawl of CC0 from OSI process
On Fri, Mar 02, 2012 at 11:18:12AM -0800, Rick Moen wrote: Quoting Chad Perrin (per...@apotheon.com): You seem here to be saying Let's not worry about it. You'll get sued, or you won't. There's no perfect answer, so don't bother trying to come up with somewhat better answers. That is not what I said, and very far from what I meant. And you actually know that, but desire to waste everyone's time anyway. 1. The use of the word seem was not accidental. 2. I said I didn't think you actually meant that (but you cut that part out). 3. It *seemed* like you were saying that in part because of the previous comments to which you replied. Context matters. 4. Your condescending self-importance is not helping. What I meant included things like 'People in general and very large corporations have no problem deploying open source software including codebases under popular reciprocal licences without infringing copyrights, through the simple expedient of not attempting to play aggressive brinksmanship games with property rights. Someone else might volunteer to give random coders free legal advice about whereexactly the brink is, but I have many better things to do with my time.' I think you have a strange impression that people are talking about trying to get away with something sketchy when, in fact, most people here are probably just talking about trying to get away with writing useful code. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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 Fri, Mar 02, 2012 at 11:20:58AM -0800, Rick Moen wrote: Quoting Chad Perrin (per...@apotheon.com): I think the point was [...] I believe I was having a discussion with Chris Travers. Didn't I ask you to kindly go away and chew up someone else's time? Yes, you *are* the sort of person who likes to pretend a public discussion on a public mailing list is your private property. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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
-Original Message- I agree with you about the problem. I have repeatedly suggested that Apache do code scans on its distributed software so that every downstream customer doesn't have to do it. But we have neither the interest nor the money to deal with hypothetical problems in a volunteer environment. We exercise diligence, but it is rather ad hoc. How does Eclipse help solve the problem for its software? Larry, The Eclipse Foundation has a dedicated staff which does scans on every line of incoming code, including all third-party dependencies no matter how deeply nested. Our IP diligence process is as good as the best practices by large ISVs. You can see a high-level overview at [1] [1] http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf ___ 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
Quoting Chris Travers (ch...@metatrontech.com): Derrida's theories on text and meaning are entirely applicable to legal agreements even if we pretend they aren't. I note without special objection that you pretty much ignored my point and moved the goalposts. No worries. I doubt you really expected to debate deconstructionism, anyway. At least, I sure hope not. 1) There isn't a lot of case law on what constitutes derivative works in software as a whole, and it isn't clear to what extent this may be an evolving field. And it may not be clear how it will evolve until one gets into court. I hear this stuff asserted a great deal by technology people who repeat, conciously or not, pronouncements by other technology people -- without actually bothering to consider (or, actually, learn) how copyright law and legal citations work. The concept of 'derivative work' has a quite well developed framework[1] in caselaw. A creative work in one of the statutorially covered categories is conceived to have elements that can be conceptually classified as either expressive or functional. Elements whose content is dictated by functional demands (e.g., compatibility), as well as those taken from the public domain, are not eligible for copyright protection. Only those deemed expressive are. Even if nobody had ever filed a copyright suit over a computer program before -- hence we didn't have CAI v. Altai, Micro Star v. Formgen, Lotus Dev. Corp v. Paperback Software, Whelan Associates v. Jaslow Dental Laboratory, CMS Software Design Sys v. Info Designs, Apple Computer v. Franklin Computer, Williams Electronics v. Artic International, etc. to guide us -- these well developed concepts would have existed from leading cases derived from music, literature, movies, theatre, and all the other categories of copyrightable works. Likewise, various defences (fair use, copyright invalidity, independent creation, de-minimus, statutory limitations on holder righs, expiry, forfeit, preemption, permission, misuse, abandonment, acquiescence, estoppel, unclean hands, other equitable defences) exist and are well developed for reasons owing little or nothing to do with software yet are directly applicable there. So, actually, 'There hasn't been a lot of case law on what constitutes derivative works in software is an extremely silly argument for at least two reasons. 1. Your representation of fact is profoundly mistaken. (See litany of case citations above, for starters.) 2. Even if that _were_ true, judges' notion of what is a derivative work is easily discernible from, and is consistent in, every other type of copyright case. 2) Therefore a book which doesn't include in fairly clear detail the various possibilities as to what courts *might* do is fundamentally incomplete. This claim is pretty hilarious, seen in reasonable context after actually bothering to understand how the law works -- unless of course you are one of the people trying to figure out to the micrometre just how close you can skirt infringement and get away from it. That's that edge case thing, so utterly beloved of many technology people, to which I alluded earlier. But I'm not going to waste time on that. I mostly wanted to point out a type of rhetoric that's been rising in prominence around here: '[basic minor fact of life foo] is a Problem.' Inability to deterministically predict with metronomic precision what will and will not be a derivative work, and be utterly certain that a court will rule that way is a Problem. The fact that coders might have to work at understanding the fine details of the more-complex software licences is a Problem. The fact that MIT/X wastes a whole 13 lines is a Problem. [Licence foo] lacking lavish and strong defences against patent trolls is a Problem. The possibility that a plain-English explanation accompanying a licence might fail to convey some nuance of the licence itself is a Problem. Inability to determine absolutely for certain that some particular conduct with software is immune from risk of successful litigation without hiring expensive legal help is a Problem. Must be nice to have time for such hobbies. I remember thinking that way, and then I left college. Out in the real world, we have to deal with shades of grey and lack of perfect knowledge, which is why a wise person will not spend huge amounts of time pondering whether you can get away with particular types of deployments without having created an unauthorised derivative work, but rather will be cautious and let someone else land in court. In LedgerSMB, we have publically said that linking is fine, but OO inheritance implies a level of expressive intimacy that implies derivation, as does using our code as a basis for your code. In other words, you can use our API, but you cannot create your own API based on it. I'd suggest you actually bother to read some caselaw rather than going around
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
Rick Moen scripsit: Out in the real world, we have to deal with shades of grey and lack of perfect knowledge, which is why a wise person will not spend huge amounts of time pondering whether you can get away with particular types of deployments without having created an unauthorised derivative work, but rather will be cautious and let someone else land in court. 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. -- Note that nobody these days would clamor for fundamental lawsJohn Cowan of *the theory of kangaroos*, showing why pseudo-kangaroos are co...@ccil.org physically, logically, metaphysically impossible.http://www.ccil.org/~cowan Kangaroos are wonderful, but not *that* wonderful. --Dan Dennett on zombies ___ 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
Rick; I think you are missing one key point in your reply to me. In short: Part of the point is to realize that the engineer's question is What do I have to do to stay safe? How do I know if this license applies? Any answer you can give to the engineer's question will be both heavily overinclusive and underinclusive because the frameworks do not match. The point of a software license is not to give lawyers an opportunity to have long discussions with the engineers. The point is to give engineers an idea of what they can do with the software or not. That derivative works law is relatively developed as a framework does not mean that it is something where an engineer can know in advance what behaviors are likely to raise problems, or even that a lawyer will be able to say with certainty how a court will resolve many of those problems. On to the longer version. Here's the fundamental problem as I understand it: Copyright law is about protecting creative expression. Software authoring and engineering is about creating functional tools. Functional elements are not subject to copyright, nor are creative elements closely tied to those at least in the US (this is as I understand it very much settled law). This of course leads to the AFC tests etc. This is why I don't think that linking ever creates derivative works by itself. At most you are copying some header files or the like and merely depending on external sources is not the same thing as being derivative of them. This being said using two products together can create derivative works. If I distribute third party CSS files for your web application (let's be extreme here and say it's an HTML5 game), then the result that is generated by the user's web browser may in fact be a derivative work, and so may my module (I can look up the case that lead me to this conclusion if you'd like). Thus I might be subject to the requirements of the GPL here. This was the big issue when we contacted the translation authors for SQL-Ledger who licensed their work under the GPL and SQL-Ledger changed the license (back at 2.8.0). It's not enough that there is functional connection, but the fact that there is *expressive* derivation in the output suggested to us that this pressure could legitimately be brought to bear. Now, maybe the strings don't have very many ways of being translated, and so they are purely functional and de minimis requirements are not met. Maybe not There isn't a clear way for us to tell. The reason why we draw the line where we do is this: We are not claiming that every use of inheritance leads to derivation. That of course is fact sensitive and requires lawyers and probably judges to resolve. However, we can say with reasonable certainty that the mere use of our API's is not protected by copyright. However, once you get into inheritance, I think the situation changes in ways which are meaningful for the AFC type test. In particular the expressive elements in the inheriting class are more closely tied to those in the inherited class (the API's functionally merge, and so forth--- it's not a matter of mere exposure of the API, but rather the way it is exposed, namely as part of the other copyrighted module, which makes a difference in our view). So we get back to the problem that Bruce was trying to answer, which is how we explain what a license allows to non-lawyers. And more to the point, letting an engineer be able to answer, the question of what exactly do you have to take out to make that application clearly non-infringing? Inheritance is a nice line to draw there. Best Wishes, Chris Travers ___ 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
Quoting Chris Travers (ch...@metatrontech.com): Rick; I think you are missing one key point in your reply to me. I didn't miss that. In short: Part of the point is to realize that the engineer's question is What do I have to do to stay safe? How do I know if this license applies? 'Law being complex is a Problem.' Making the world perfect is somewhere on my to-do list, but the task will not get much love today. Anyway, I actually spent quite a bit of time painstakingly explaining to you why your premise was wrong and your entire framing of the issue is wrong-headed from the start. Now, with quite breathtaking speed, you have come back with a lot more. I'm out of time, for now. Sorry. (By the way, I was already short of time enough that I forgot the numbered footnote, earlier. That should have been something like: [1] Particulars to follow will be somewhat USA-centric, for which my apologies to the international subscriber base.) Anyway, at a quick glance, you really need to take care that you aren't twisting the concepts of 'functional element' and 'expressive element' outside their intended meaning in copyright law when you spin out doubtfully related expressions like 'functional connection' and 'expressive derivation'. I'd suggest more reading of caselaw and fewer amateur theoretical constructions, if you want to come up with something relevant to actual law. So we get back to the problem that Bruce was trying to answer, which is how we explain what a license allows to non-lawyers. 'Laymen not finding complex licensing as easy to read as a dinner menu is a Problem' is IMVAO an utter waste of time. However, if that's your idea of a hobby, enjoy. ___ 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 Thu, Mar 1, 2012 at 8:06 PM, Bruce Perens br...@perens.com wrote: 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. I am not at all sure that line works once you get into trying to bridge GPL'd and proprietary apps, which is an important thing to the adoption of free/open source software generally, particularly for larger business systems. For example, support I have a customer that needs to move data back and forth between LedgerSMB and, say, Quickbooks or Sage 500. Does it matter how I do this? Is it possible to accidently create a derivative work in the process? 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? If I assume the license always applies, and I interpret it as expansively as possible, such connectors become problematic. Best Wishes, Chris Travers ___ 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 Thu, Mar 1, 2012 at 8:40 PM, Bruce Perens br...@perens.com wrote: 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. Bruce; The questions above were rhetorical. Now that we agree that the above questions I asked are valid questions. I notice you say Don't assume that you can put proprietary kernel drivers in a run-time loadable kernel module. The legality of such a practice is dubious, and there have not been sufficient cases to say reliably what would happen if you were to get sued, which comes back down to the linking question. You seem to say do not link and thus repeat more or less what the FSF says (and what Rosen spends a good time arguing against in his book, and he is by no means alone--- at least in any law review articles I have been able to find and read the overall trend is overwhelmingly against seeing linking as having much to do with derivation). So this gets to the problem that I think we are both trying to solve, which seems to be a fools errand: giving an engineering answer to a legal question. My sense (as a non-lawyer) is that communications from a project are very much likely to affect the scope of the license, and that downstream developers are likely to be able to reasonably rely on communications from a project that some practices are safe in their eyes. So this is where the discussions help. Best Wishes, Chris Travers ___ 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 Thu, Mar 1, 2012 at 9:44 PM, Bruce Perens br...@perens.com wrote: On 03/01/2012 09:09 PM, Chris Travers wrote: You seem to say do not link and thus repeat more or less what the FSF says (and what Rosen spends a good time arguing against in his book, and he is by no means alone--- at least in any law review articles I have been able to find and read the overall trend is overwhelmingly against seeing linking as having much to do with derivation). My goal isn't to help my customers win after they're sued, it's to prevent them from ever being in a lawsuit at all. And you do that by staying away from some issues. Ok, so part of avoiding lawsuits is to avoid areas where folks think they can sue about. So the FSF's statements are important here. Despite the fact that Larry and those law review folks are sure about the linking question, every party who would benefit from a case going according to Larry's interpretation has settled their case with the GPL licensor rather than invest what is necessary for a court to make a determination. That's why discussion of the murkey middle ground is important. So, what do you do? You stay away from that issue and arrive at an engineering solution that avoids it. It also depends on what your relationship is to your audience, and this is the big issue with explanations that exist apart from the license. The FSF can interpret the GPL one way and Linus and the Linux community in a different way, and if they are public about their views, the license grant may actually be different. I don't see what's so hard to understand about that. I think for practical reasons we like to pretend that there is one true interpretation of the GPL v2 but in fact I don't think that necessarily is the case. The GPL v3 tries to make progress there, but 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. which seems to be a fools errand: giving an engineering answer to a legal question. Only a fool's errand if the engineer doesn't have good legal support, or if the lawyer isn't able to work with engineers. I address that a little differently, by acting as a consulting engineer who works for the attorney and has experience in this particular sort of case. A fool's errand because the models simply don't match. 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. Maybe if I detect Doom is the one running, I make walls transparent, or something. The two programs may be running on different processors, may share no code or expressive structures, but because the output is pretty clearly a derivative work may in some cases be derivative itself. There is no line where you can draw technically where everything on one side is safe, and if you draw one where everything is not safe, there's a good chance a lot of stuff on the other side is not safe. My sense (as a non-lawyer) is that communications from a project are very much likely to affect the scope of the license, and that downstream developers are likely to be able to reasonably rely on communications from a project that some practices are safe in their eyes. About the worst thing engineers can do is attempt to make legal determinations without proper counsel and the necessary training. They invariably get it wrong and they can be made to look really stupid in court by a competent expert witness. Relying on what they say about legal issues of their own projects would be ill-advised. Instead, learn how to engineer around the gray areas. So here's the thing 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.. Best Wishes, Chris Travers ___ 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 Tue, Feb 28, 2012 at 10:44 AM, Rick Moen r...@linuxmafia.com wrote: Quoting Chris Travers (ch...@metatrontech.com): Any layman who wants to understand why this doesn't work needs only to pick up any of Derrida's books at the corner used book store. Anyone who cannot distinguish between the accessibility of Larry Rosen's extremely lucid work and Jacques Derrida's ridiculously obscure text has much bigger problems. Derrida's theories on text and meaning are entirely applicable to legal agreements even if we pretend they aren't. Rosen's work is very lucid, insightful, and interesting. It certainly is one of the works I would refer people to. However, there are a couple points I would make: 1) There isn't a lot of case law on what constitutes derivative works in software as a whole, and it isn't clear to what extent this may be an evolving field. And it may not be clear how it will evolve until one gets into court. 2) Therefore a book which doesn't include in fairly clear detail the various possibilities as to what courts *might* do is fundamentally incomplete. There is often a world of difference (that the FSF exploits as much as they can, btw) between what you can be sure of as a licensor and what you can be sure of as a licensee. However, as a reminder, it is _not_ necessary to read a comprehensive book on open source licensing to have a reasonable knowledge of how a major open source licence, particularly a simple permissive one, is constructed and why. But this gets back I think to the problem with the idea that separate explanations are sufficient, or even the question of how much abuse a license needs to prevent. You have essentially two separate aspects of a software license and these need not overlap exactly: 1) You have the legal contract which needs to be specific enough to protect against the worst of the abuses. 2) You have a social contract which rewards those who fill social expectations. Consequently if I go out and, say, distribute psql linked to readline (GNU GPL) and openSSL (incompatible with the GPL) as most Linux distributors do, I am *probably* safe from legal retaliation by the FSF for two reasons: 1) This is probably within the bounds of the GPL for the reasons Larry Rosen articulates, though the FSF claims not and who knows what a court would rule given the additional explanations and so forth, but it's a serious risk that the FSF might be ruled against. 2) This is clearly within the overall accepted social contract of the GPL culture. If the FSF starts going after BSD projects because of which other open source libraries they are linking to, this has social costs as well. All human communication is subject to areas of ambiguity and irreducible complexity. The more you try to specify, the more you will run into conflicts and omissions. Thank you, Captain Edge Case. Edge cases include all kinds of things that have been discussed to death on this list including: 1) Linking GPL libraries to proprietary software 2) Linking proprietary libraries to GPL software (The above while very likely inside the scope of what is permitted by the GPL is certainly outside the GPL social contract.) 3) Taking BSD software and distributing it under the GPL without changing the code. Does the GPL v3 require allowing this? If so, is the BSD license incompatible? (Even if, as the FSF claims, not inside the scope of what is permitted, still within the GPL social contract) And as much as folks like to pretend that legalese is a programming language, it's not. I hope you're addressing this bit of packaged Polonius-grade wisdom to someone else, as I certainly have had no such illusion. How many times have I said on this mailing list that the law (and judges) are not Turing machines? Let's find out. Not directed at you. However the point is that with any contract you have three categories of behaviors: 1) Behaviors where the first party can be sure of a ruling in his favor 2) Behaviors where the second party can be sure of a ruling in his favor 3) Behaviors everyone avoids because there is at least some uncertainty as to whether that would go to court and . The problem with a lot of these discussions is that they ignore that third category. Being aware of where the uncertainty is on both sides is very helpful. I keep coming back to the question of How do I, exactly, determine whether my software counts as a derivative work? How certain am I that this is what a court would hold? Like it or not, I agree that linking is irrelevant to the GPL, but I recognize that what the FSF has done has been to draw a bright line around something that is a very murky issue. In LedgerSMB, we have publically said that linking is fine, but OO inheritance implies a level of expressive intimacy that implies derivation, as does using our code as a basis for your code. In other words, you can use our API, but you cannot create your own API based on it.
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On Sun, Feb 26, 2012 at 4:50 PM, Bruce Perens br...@perens.com wrote: 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. If the first can be solved with an explanation separate from the license, why not use that instead? Of course we don't use that instead because the explanation is not the same as the license. I also wonder whether in court a defendant could successfully argue that the explanation is itself a license as well and therefore when they disagree, the most permissive interpretation of either wins? I think it's important to keep licenses short, understandable in plain English (outside of formulaic warranty disclaimers), and to the point. Sure there will be some abuse in some corners, but the alternative is to write increasingly long, complex, and unintelligible licenses whose main virtue is giving lawyers something to argue about what exactly they mean in court... Best Wishes, Chris Travers ___ 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 Mon, Feb 27, 2012 at 12:00 AM, Rick Moen r...@linuxmafia.com wrote: Oh, bushwah. Any layman who wants to understand in even paranoid levels of detail the major licences and has two hours to spare can pull down the PDF of Larry Rosen's book free of charge, among other methods of arriving at that understanding. And any of them who cannot comprehend MIT/X after two hours even without Larry's book probably should rethink running a business. Any layman who wants to understand why this doesn't work needs only to pick up any of Derrida's books at the corner used book store. All human communication is subject to areas of ambiguity and irreducible complexity. The more you try to specify, the more you will run into conflicts and omissions. And as much as folks like to pretend that legalese is a programming language, it's not. Best Wishes, Chris Travers ___ 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
Quoting Chris Travers (ch...@metatrontech.com): Any layman who wants to understand why this doesn't work needs only to pick up any of Derrida's books at the corner used book store. Anyone who cannot distinguish between the accessibility of Larry Rosen's extremely lucid work and Jacques Derrida's ridiculously obscure text has much bigger problems. However, as a reminder, it is _not_ necessary to read a comprehensive book on open source licensing to have a reasonable knowledge of how a major open source licence, particularly a simple permissive one, is constructed and why. All human communication is subject to areas of ambiguity and irreducible complexity. The more you try to specify, the more you will run into conflicts and omissions. Thank you, Captain Edge Case. And as much as folks like to pretend that legalese is a programming language, it's not. I hope you're addressing this bit of packaged Polonius-grade wisdom to someone else, as I certainly have had no such illusion. How many times have I said on this mailing list that the law (and judges) are not Turing machines? Let's find out. ~ $ grep 'Turing machine' Mail/license-discuss law is a Turing machine. The difference is that judges are not Turing machines. ObReminder: The law is not a Turing machine: Judges interpret terms anything that looks like a Turing machine against a variety of inputs. Turing machine, with the result that they try to hurl goofy licences As has been said in this space before, judges are not Turing machines, like the fact that a Turing machine cannot be set up to decide what is a $ Eight times, if you include this posting. ___ 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
Quoting David Woolley (for...@david-woolley.me.uk): Rick Moen wrote: It's called 'realism'. The reason well written licences have an irreducible complexity about them is that they are obliged to deal with real legal issues, e.g., the way warranty disclaimers are required to be The reality is that the people who have to comply with licences are not professional lawyers. If they are presented with lots of legalese, they are likely to ignore it, as most people do with shrink wrap licence agreements, or the legal stuff hidden in low contrast, small font links at the bottom of web pages, which the designers would rather not have there at all. 1. The likes of MIT/X should be highly comprehensible as to their general purport by, say, school leavers, even if they gloss over many of the details and don't follow the nuances. 2. A large and underappreciated part of the value of well-known, major open source licences lies in the fact that they are broadly understood, and so do not need to be minutely scrutinised by everyone to understand what they're about. I suspect that licences with lots of legalese discriminate against medium size enterprises. Oh, bushwah. Any layman who wants to understand in even paranoid levels of detail the major licences and has two hours to spare can pull down the PDF of Larry Rosen's book free of charge, among other methods of arriving at that understanding. And any of them who cannot comprehend MIT/X after two hours even without Larry's book probably should rethink running a business. -- Cheers, Remember: its means it is, and it's Rick Moenis the possessive form of it. r...@linuxmafia.com -- FakeAPStylebook McQ! (4x80) ___ 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 Sun, Feb 26, 2012 at 09:41:01PM -0800, Bruce Perens wrote: 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. This may surprise you, but I don't think that actually proves what you probably think it does. Y'know what? A user willing and able to dive into writing code for his or her own purposes should be encouraged to do so, and experienced software developers who are willing to offer some peer review or mentoring can provide an invaluable service in helping a novice programmer learn how to serve his or her own needs better than any outsider trying to second guess his or her desires ever could. So, yeah, that's pretty much *exactly* what I have in mind. Thanks for the excellent analogy supporting my point so beautifully. 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. Tell that to the guy who doesn't want the crashes every couple hours feature of an overcomplicated word processor or operating system, or the guy who doesn't want the What the hell is *that* doing in this license?! feature of a legal unwittingly misrepresented as having much simpler legal effects than were explicitly described in the license text itself (let alone those license terms that have *unintended* effects). You yourself have questioned some terms that are not fully disclosed in recent discussion, but now you act like this stuff doesn't matter. Sure, they're there for a specific reason, and the people who wrote the license are probably not idiots (in fact, I think they're probably quite smart about this stuff), but the fact remains that the legal density of the license text and necessary inadequacy of a plain English simplification leaves potential license users or accepters with a potentially disastrous misunderstanding of terms. 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. Instead, people should get trapped by the simple fact they do not understand the licenses in question, I suppose -- or perhaps open source software development and open culture art are only for people with lawyers on retainer. Once more, I'm not talking about things like This turn of phrase is necessary to cover specific case-law eventualities. I'm talking about This license explicitly disclaims any patent license, setting me up for a patent suit trap. That license limits what technologies I can use to redistribute this work, which means I'm violating its terms when I distribute it on iTunes. The other license specifies software in a definitions section in a way that makes my use of the covered work, which is a combination of example code and English explanation, only partially protected from copyright infringment suits if I redistribute it. The fact a lawyer wrote a license does not in any way whatsoever guarantee that people will not misunderstand the licenses, especially when all they're reading is a terribly under-explained summary (because full explanation would require a hefty chapter of a book, if for no other reason). It really does not matter, for the purposes of my point, how well the lawyer did achieving legal text that will for decades to come stand up to court test as satisfying the literal request (in every detail) of the guy who commissioned the lawyer's work. 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./ There is a difference between an overly-simple license that tries to do too much and a *properly* simple license that tries to do the minimum acceptable amount of stuff so that mere mortals are still capable of reading it when crafted by a qualified professional. Feature creep is as much a problem
Re: [License-discuss] [License-review] CC withdrawl of CC0 from OSI process
On Mon, Feb 27, 2012 at 12:08:17AM -0800, Rick Moen wrote: Quoting Chad Perrin: Explain to me how wanting to enforce a crapton of additional terms is realism instead of a more-restrictive license. Mu. This request has nothing to do with what I said, and I just don't have that time to waste. If that has nothing to do with what you said, what you said must have nothing to do with the points to which you replied. Anyway, I already pointed out extremely basic problems with 'Unlicense' on licence-review. . . . which you say as though I were somehow disagreeing here. That mystifies me. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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 Mon, Feb 27, 2012 at 12:00:00AM -0800, Rick Moen wrote: Quoting David Woolley: I suspect that licences with lots of legalese discriminate against medium size enterprises. Oh, bushwah. Any layman who wants to understand in even paranoid levels of detail the major licences and has two hours to spare can pull down the PDF of Larry Rosen's book free of charge, among other methods of arriving at that understanding. And any of them who cannot comprehend MIT/X after two hours even without Larry's book probably should rethink running a business. I don't think David Woolley was saying the MIT/X11 License was lots of legalese. I think the point was about licenses at least three times the size of that one. That, at least, is how I understood it; CC0 pushes that barrier to understanding for the layman pretty hard, and many (longer) licenses blow right through it like it wasn't even there, such as a few very popular OSI-approved licenses longer than any Microsoft EULA I have ever seen. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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 Mon, Feb 27, 2012 at 12:15:51AM -0800, Rick Moen wrote: Quoting Chad Perrin (per...@apotheon.com): If that has nothing to do with what you said, what you said must have nothing to do with the points to which you replied. This comment does not strike me as either logical or constructive. However, please do have a pleasant day. Please explain to me how pointing out a miscommunication (where what I said to you was relevant to what I had previously said, indicating that if it was not relevant to your reply to what I previously said your comment was also probably not relevant to what I had previously said) does not appear to be logical or constructive so I may avoid that error in the future. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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 2/26/12 5:31 PM, David Woolley for...@david-woolley.me.uk wrote: The reality is that the people who have to comply with licences are not professional lawyers. This is why CC is liked in the creative community. That and a broad range of licenses to meet a variety of needs. ___ 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
Quoting Chad Perrin (per...@apotheon.com): Please explain to me No thank you. Please do have a pleasant day. -- Cheers, 'LEGO' is the plural. The singular is 'Legum.' Rick Moen -- FakeAPStylebook r...@linuxmafia.com McQ! (4x80) ___ 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:41 PM, Bruce Perens wrote: 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. That's inappropriate FUD on the Artistic License. The ruling in question on the Jacobsen v. Katzer case was not specific to the Artistic License 1.0, it was a statement that violation of the conditions of *any* nonexclusive open source license would not be grounds for a copyright infringement claim. Fortunately, we did all join together and get that reversed. Please keep in mind that while copyright-based licenses are well established in general, there is very little actual precedent in case law. A large part of establishing that case law will be a matter of working together, and *not* flinging FUD at other people's licenses. Allison ___ 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
Bruce Perens wrote: 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. Where I would see a particular advantage in a machine processable language, would in handling ANDs, ORs and the scope of particular conditions. There was a recent example of UK secondary legislation that made an AND/OR/negation type of mistake, in the wording of a statutory notice that was supposed to summarise primary legislation. As a result, it appeared to imply that certain sorts of debts to a landlord could never be recovered. 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. -- David Woolley Emails are not formal business letters, whatever businesses may want. RFC1855 says there should be an address here, but, in a world of spam, that is no longer good advice, as archive address hiding may not work. ___ 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
[Moved to license-discuss, as this thread has become highly offtopic for license-review.] Quoting Chad Perrin (per...@apotheon.com): It doesn't help much that it seems like everyone working with lawyers wants to produce horribly complex systems of license restrictions, so that almost the only people who *can* read them are lawyers. (Cry me a river.) It's called 'realism'. The reason well written licences have an irreducible complexity about them is that they are obliged to deal with real legal issues, e.g., the way warranty disclaimers are required to be specific and 'prominent' (which ends up meaning all capital letters) as a result of Uniform Commercial Code caselaw. Defective efforts like 'Unlicense' are what happens when naive coders attempt to create permissive licences, with results about as sad and unfortunate as would be the case if typical coders were to attempt to practice law. ___ 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 Sun, Feb 26, 2012 at 12:28:03AM -0800, Rick Moen wrote: [Moved to license-discuss, as this thread has become highly offtopic for license-review.] Quoting Chad Perrin (per...@apotheon.com): It doesn't help much that it seems like everyone working with lawyers wants to produce horribly complex systems of license restrictions, so that almost the only people who *can* read them are lawyers. (Cry me a river.) It's called 'realism'. The reason well written licences have an irreducible complexity about them is that they are obliged to deal with real legal issues, e.g., the way warranty disclaimers are required to be specific and 'prominent' (which ends up meaning all capital letters) as a result of Uniform Commercial Code caselaw. Explain to me how wanting to enforce a crapton of additional terms is realism instead of a more-restrictive license. I'm not talking about needing three lines to say what takes one in plain English: I'm talking about adding stuff like restrictions on deployment or distribution technologies, special-case license combination exceptions, and other stuff that would really be entirely unnecessary if people would just stop trying to micromanage each others' lives. Defective efforts like 'Unlicense' are what happens when naive coders attempt to create permissive licences, with results about as sad and unfortunate as would be the case if typical coders were to attempt to practice law. . . . and yet, the Unlicense is lengthier than (for instance) the ISC and MIT/X11 licenses, which are better written from a legal standpoint. That's because the Unlicense is trying to *do* more, and not just because it wasn't written by lawyers or with lawyers on tap to help tighten up the language for legal purposes. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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 Sun, Feb 26, 2012 at 12:28:03AM -0800, Rick Moen wrote: (Cry me a river.) By the way, your asshole-ish attitude is hilarious when you're addressing something I didn't even say. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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
Rick Moen wrote: It's called 'realism'. The reason well written licences have an irreducible complexity about them is that they are obliged to deal with real legal issues, e.g., the way warranty disclaimers are required to be The reality is that the people who have to comply with licences are not professional lawyers. If they are presented with lots of legalese, they are likely to ignore it, as most people do with shrink wrap licence agreements, or the legal stuff hidden in low contrast, small font links at the bottom of web pages, which the designers would rather not have there at all. I suspect that licences with lots of legalese discriminate against medium size enterprises. Very small ones, and individuals, are not worth suing, and very big one have bigger lawyers than yours. The medium sized enterprise is not going to want to bring in a lawyer every time a design specification is reviewed, so, if their management cannot understand the licence, they may just play safe by looking for different solutions. -- David Woolley Emails are not formal business letters, whatever businesses may want. RFC1855 says there should be an address here, but, in a world of spam, that is no longer good advice, as archive address hiding may not work. ___ 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] [License-review] CC withdrawl of CC0 from OSI process
On Sun, Feb 26, 2012 at 04:50:16PM -0800, Bruce Perens wrote: 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. . . . which, judging by some Creative Commons examples (as the most obvious case of a license author/organization taking exactly that approach), is prone to being misleading and/or incomplete. Legal rigor is good, but pages of dense legalese coupled with plain English explanations that give people mistaken impressions because it's just not reasonable to expect a nuanced understanding of the sheer complexity of the license suggests to me that there's something wrong. What's wrong is usually the metric crapton of terms heaped on such licenses. 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. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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] [License-review] CC withdrawl of CC0 from OSI process
Quoting Bruce Perens (br...@perens.com): 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. Moreover, if we had our druthers, we'd prefer that hapless recipients and third-party reusers of works released under badly conceived crayon licences don't get hurt: Sadly for those of us who are friends of Papa Darwin, the people who make incompetent attempts to handwave away copyright and caselaw realities with such licences don't hurt _only_ or even primarily themselves. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
