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. Best Wishes, Chris Travers _______________________________________________ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss