Derivative/collective works and OSL

[David Dillard]

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 
> above...?

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 ;-)).


> 
> --
> -Chuck
>