From: Anton v. S. <an...@ap...> - 2004-09-04 00:30:03
|
MJ Ray wrote: > On 2004-09-03 22:42:59 +0100 Anton van Straaten > <an...@ap...> wrote: > > > [...] In order to do this, we > > have to comply with the requirements in clause 6, > > which are straightforward in our case. > > So, the printed cookbook has to come with machine-readable > source of all contributions? According to clause 6(c), it would only need to come with a written offer to provide that source "for a charge no more than the cost of performing this distribution", which is simple enough to provide. However, books like this often come with a CD of source code, in which case clause 6 could be taken care of that way. > I'm not convinced that you can appeal to clause 6. You are not > including "portions of the Library" but rather the entire Library. That's not the intent, but perhaps that needs to be clarified. The only thing that any contributor has the right to grant a license for is their own contribution(s). When a contributor agrees to license their contribution under the LGPL, that says nothing about the Cookbook as a whole. The status of the Cookbook as a whole is covered by the agreement the contributor enters into in order to contribute, in which the compilation copyright is asserted. > > [...] Regarding source and object form, the FSF didn't see fit to > > include definitions of those in the LGPL. > > Yes, they did one of those. See clause 0 for "Source code". Thanks. I was mistaken about the lack of a definition of "source code", but of course the LGPL definition of source code matches the one I gave, in terms of its application to the Cookbook. However, the LGPL does not define object code. In any case, my point still stands: both are unambiguous for the purposes of the Cookbook, although I think we should define "object code" anyway. > Have you read the licence? Yes. However, in writing my last message, I was misled by your claim that we didn't have "very careful agreed definition of source and object forms", when you apparently really meant that only the object form was at issue. > > [...] In the Cookbook's case, the formatted output, > > whether on the web or the pages of a book, is obviously > > the object form. > > Is that object code, or merely a translation of the formatting? > The content doesn't seem to get transformed much. It's a mechanical translation of the source form to an object form. A comparison of the two forms shows significant differences. If we include a definition like the Apache one, which specifically covers "generated documentation", then there's no doubt of it's applicability. > > [...] We're not talking about wanting to deal with a > > "free-software-copyright-fearing publisher", we're talking about a > > publisher who might want reasonable legal protection on their > investment. [...] > > Are you claiming that free software does not have reasonable legal > protection? Not at all. However, a publisher of entirely free content doesn't have any legal protection against others making and selling exact duplicates of the work. > Also, there's no advance to pay, authors and editors working for > free... is the publisher really investing much in this? The investment is in the time of their employees in helping to produce the book; in the cost of the first print run; in shipment to bookstores, and in marketing and legal expenses, etc. It's precisely that investment that we're looking to benefit from, and why this whole issue arises in the first place. > > If such a combination were not permitted, the LGPL wouldn't work for > > its primary purpose, to allow libraries to be combined into other works > > that aren't under free licenses. > > Do you think LGPL allows you to take source code from many LGPL works, > merely combine it and claim the resulting work is not LGPL'd? You couldn't claim that the LGPL'd work is no longer LGPL'd, but we're not doing that. The work we're claiming rights to is a compilation, "which by reason of the selection or arrangement of their contents constitute intellectual creations" (WIPO), and thus are considered legally worthy of protection. If all the Cookbook contributors simply uploaded their work to an FTP site, for example, the Cookbook wouldn't exist in the form we're trying to protect. The only reason it does exist in that form is because of work that we've done and that we and our publishers will do, which includes: (i) making a web site available to receive the work, store it, render it, and publish it (ii) designing and implementing a system to compile the work in a coherent and usable way (iii) preparing the book for publication It is particularly point (ii) which qualifies the compilation as an intellectual creation in its own right, separately identifiable and protectable, apart from its individual contributions. > Maybe I'm not seeing the cookbook situation the same as you do. I think that's a given. ;-) > I think you can claim it permits linking an Anton-License'd TOC, > foreword and index as a work using the libraries That's more or less what we are claiming, for the Schematics Editors. We're also telling contributors that the right to create compilations which use the metadata associated with contributions is granted exclusively to the Schematics Editors, and is not included under the LGPL license. > but then free software authors can shred those > unread and write new ones... Free software authors can certainly do that, as long as the compilation they create differs from ours in a significant enough way to constitute a separate intellectual creation, and as long as they don't use the Cookbook metadata to create their compilation. Those two points may more or less amount to the same thing. Philosophy of Freedom --------------------- There are multiple threads in this discussion - aside from the question of whether our current approach is legally valid, there's also the question of whether it is in some way counter to the principles of free software. Certainly, there'd be no issue in this respect if the Cookbook was entirely free. However, I think if you re-read the FSF's statement about why _not_ to use the LGPL [1], you might find that the reasons for the approach we're trying to take are not really at odds with the FSF's intent. We're not taking away the real freedoms which the FSF is concerned with providing to free software developers and others. The negative situations described in that document do not really apply to the Cookbook. All the source code in the Cookbook will be freely available to developers, and I think there are excellent reasons not to put it under full GPL (yet another separate discussion, I suppose). As I've previously said, if any ordinary code library is produced from the Cookbook, that should certainly be LGPL in its entirety. Insisting on total freedom for the Cookbook runs the risk of making the perfect the enemy of the good. Of course, that's a separate question from whether our current approach is legally viable; if it isn't, we should obviously find one that is. Anton [1] http://www.gnu.org/philosophy/why-not-lgpl.html |