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 making pronouncements that have no discernable relation to the criteria actually used. _______________________________________________ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss