Derivative/collective works and OSL
chuck at codefab.com
Mon Feb 7 18:46:07 UTC 2005
On Feb 7, 2005, at 10:38 AM, David Dillard wrote:
>> 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,
> names, class names, etc. All of which have no meaning to a computer,
> hopefully have great meaning to a developer.
Modern object formats like ELF encode function names, variable names,
class names, source code file name and line # information, and more
into the symbol table (SHT_SYMTAB), dynamic relocation information
(SHT_HASH, SHT_DYNAMIC, etc) and other sections (SHT_NOTE).
Even if you strip debugging information out, you will still have
information all external symbols and all dynamicly relocatable entry
[ ... ]
>> 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?
I was responding to the comment "...and if when compiled it is still a
collective work, then it is not derivative of any of the works
contained in the tarball."
I make a distinction between what the compiler toolchain does and what
the compiler itself (cc1) does. The C preprocessor makes
transformations to source code (macro expansion, resolving #include
references, conditional compilation, etc) which change the input source
code into a format which the compiler proper can handle.
If cpp can untar or unzip compressed source files, fine, but the
compiler proper doesn't see that as input.
>> 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 ;-)).
Indeed you do. :-)
If we compare reading the disk sectors before and after defragmenting a
filesystem, one would discover that lots of them have changed. Have we
changed the contents of any the files by doing so? Or is the
transformation process of defragging a disk completely transparent...?
More information about the License-discuss