Matthew Palmer <[EMAIL PROTECTED]> writes: > On Wed, Jul 21, 2004 at 02:52:08PM -0400, Brian Thomas Sniffen wrote: >> Matthew Palmer <[EMAIL PROTECTED]> writes: >> > I'm think of an analogy with a certain children's toy called a spirograph. >> > You may have heard of it, or maybe not. It basically consists of a large >> > ring, with cog teeth on the inside, and several smaller cogged circles, >> > each >> > with lots of holes in it. You placed the circle in the ring and a pen in >> > one of the holes, and turned it around and around. It created beautiful >> > patterns. >> >> Yes. I know what you mean. >> >> > But it's simply the result of a mechanical process. The only copyright >> > that >> > could exist in a spirograph artwork would be the selection of circle, pen >> > hole, and pen colour -- equivalent to source code. >> >> But what if the spirograph cogs were not uniform? What if they had >> wiggly sides, and so contained the essence of some spirograph >> drawings? Those are your programs. They are copyrightable. >> >> Now imagine the outer wheel is also nonuniform, and has been >> creatively sculpted. It has an impact on the output as well. >> >> The output is just a mechanical transformation, yes -- but of the pair >> (wheel, cog). It carries copyrightable elements of both along. > > I think I see your argument. Your saying that, in the case of the compiler, > creative decisions made by the author of that compiler have affected the > end-result of the compilation effort. The compiler author's choice of > design has changed your compiled program. > > I think this could be expressed as an "affected" theory of determining > derivative works. I've heard a similar theory espoused as to why programs > are derivative works of the libraries they use -- because your creative work > wouldn't be in the form it is in if it weren't for the influence of the > library's API. In this case, the form of your compiled work is influenced > by the compiler author's design decisions. > > I understand it, but I don't think my mind is letting me truly believe it. > The problem I see it is that this argument would very easily make every work > compiled by GCC a derivative work of GCC, and hence need to be distributed > under the terms of the GPL, if it weren't for the "clarification" by the FSF > about GCC considering programs as pure input data. A similar conclusion > would also hold true of every other compiler out there -- and I can't recall > seeing licence grants over the compiler output from MSVS, only on the > runtime libraries.
I see compilers -- and not just LISP compilers -- all the time, which claim to control how their output may be used. The intel compiler, for example, has an expensive license if you wish to build products for commercial sale. Metrowerks Codewarrior used to be under a similar license; I assume it still is. >> As it happens, it's not *just* the OCaml compiler which is licensed >> under the QPL. It is the byte compiler, the native-code compiler, the >> debugger, the interactive toplevel, the OCaml-specific 'lex' and >> 'yacc' tools, the linker, the documentation generator, and the camlp4 >> macro engine, pretty-printer and preprocessor. > >>From recollection, GNU bison has a large waiver over their template parser > files (bison.simple and bison.hairy) because they are copied verbatim into > the output source, and the FSF didn't want to limit use of bison to > GPL-compatible software. I don't suppose you happen to know if the > equivalent parts of the OCaml yacc have similar waivers (or are considered > part of the "runtime library" LGPL set)? They don't appear to be in the LGPL'd code, and I don't see such waivers on cursory inspection. After the last week, though, somebody *else* is going to have to ask the OCaml maintainer. I'm not interested in continuing the flood of abuse into my inbox. -Brian -- Brian Sniffen [EMAIL PROTECTED]
