On Saturday 25 January 2003 21:59, Stefano Mazzocchi wrote: > Unfortunately, this is not the case. Those mock classes will have to be > LGPL-ed as well and we won't be able to ship them with our stuff anyway > (because of ASF policies)
Well, LGPL allows you to distribute un-modified code unrestricted, providing a link back to the original project for source code (you don't need to ship the source). LGPL is NOT viral to the "linked" (which is questionable what that is in the letter of the law) code, only the modifications and "derived work" (also somewhat blur). The mock classes can not be created, Stefano reasons, because you have to take the same interfaces, hence "derive work" from those interfaces. But here is one interesting point, only those mock classes need to be LGPL and contributed back to the original project. Some well organized projects even allow "dummy" runtime implementations without violating LGPL, where you re-distribute their developer jar(s) for proper builds, which are often lean, and/or the implementation jars separately for the runtime environment. BUT, it is a clogmaire (spelling?) out of proportions, and I suggest that ASF continues its policy, that Stefano is reciting. Also note that a 3rd Party can take Cocoon (ASF) and XYZ (LGPL) and GLUE (LGPL) as a bundle. > LGPL was written for C code. Java, being highly dynamic, doesn't really > distringuish between what is a library and what is your code. And the > FSF likes it to be that way since they don't like java (being a non-free > language from their point of view) > > One day we'll have cocoon blocks and these problems will be solved but > for now, we won't ship xGPL classes from official ASF distributions. That sounds good!!!! When can I have it?? Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
