Derivative/collective works and OSL
david.dillard at veritas.com
Mon Feb 7 15:38:40 UTC 2005
More reply inline...
> -----Original Message-----
> From: Chuck Swiger [mailto:chuck at codefab.com]
> Sent: Monday, February 07, 2005 1:21 AM
> To: David Dillard
> Cc: license-discuss at opensource.org
> Subject: Re: Derivative/collective works and OSL
> David Dillard wrote:
> >> [ ... ] You can compile a source code file with one
> compiler into an
> >> object file, decompile the object file via a disassembler
> or debugger
> >> like gdb, and then recompile that result into a new object
> file using
> >> a different compiler.
> >> You will end up with a program that has the same exact
> behavior and
> >> meaning as the original program.
> > It has the same behavior, but the process of deassembling
> isn't going
> > to give you something equivalent to what you started with (assuming
> > some sort of high-level language).
> It is true that source code contains comments intended for
> developers to read as well as the instructions intended for
> the machine to execute.
> As far as the computer or the end-user running the compiled
> program is concerned, source-code comments are invisible,
> non-functional, and have no meaning or impact on the behavior
> of the program.
I'm not talking about comments, I'm talking about function names, variable
names, class names, etc. All of which have no meaning to a computer, but
hopefully have great meaning to a developer.
> > Thus, what you have after disassembly isn't nearly as easy to
> > successfully modify as the original.
> Sure. The original source code is the preferred version of a
> program for a developer to work with. A compiled version is
> the same program, only in the preferred format for a
> particular computer architecture to execute.
> [ ... ]
> >>> ...and if when compiled it is still a collective work, then it is
> >>> not derivative of any of the works contained in the tarball.
> >> You can't compile a tarball without extracting the
> contents any more
> >> than one could read a book mailed to you in a box without opening
> >> that box, first.
> > I don't think you want to go there. Someone could easily write a
> > compiler or a compiler preprocessor so that you could
> indeed compile a tarball.
> And just how would this compiler preprocessor work? Would it
> not extract the contents of the tarball precisely as I'd said
Exactly. Which is why saying that "you can't compile a tarball" has no real
meaning. Thus, why go there?
> There are filesystems out there which compress files
> transparently to the user, and decompress the data when the
> file is accessed. The fact that an compressed file has a
> different sequence of bits on disk than an uncompressed file
> is a matter of packaging: the contents of the file remain the
> same. Tar, zip, and other archive formats used for source
> code are lossless, so you can get the original contents back
> exactly. Even with the comments, too. :-)
At the user level this is true. But it has to go thru a transformation
process. Read those disk sectors directly and the contents of the file are
not the same (please keep in mind that I work for a company that does things
like that in products ;-)).
More information about the License-discuss