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