RE: Derivative Work for Software Defined

2003-01-17 Thread Andre Hedrick
On Wed, 15 Jan 2003, John Cowan wrote: Because G+H is not merely G concatenated with H, Anybody who concatenates any source files specifically .c well go get them, they are do something bad. My points have always been and shall remain associated interface definition files aka header files,

RE: Derivative Work for Software Defined

2003-01-17 Thread PETERSON,SCOTT K (HP-USA,ex1)
Brian -- I agree with Larry that mere aggregations are collective works (at least in general; I would not discount the possibility that one might find some nuance of collective work that is not present in some mere aggregation). Also, I'd note that not all collective works are mere aggregations.

RE: Derivative Work for Software Defined

2003-01-17 Thread PETERSON,SCOTT K (HP-USA,ex1)
If one merely copies the original work unchanged, that falls under section 1 of the GPL, not section 2. Yes, but only source code: verbatim copies of the Program's source code (from section 1) -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company

RE: Derivative Work for Software Defined

2003-01-17 Thread PETERSON,SCOTT K (HP-USA,ex1)
I agree with the outcome of the book and magazine examples, but for a completely different reason: one involves copying the work of both authors and the other does not. I'm going to use these examples as an excuse to discuss some of the issues to which I believe people refer when they talk about

Re: Derivative Work for Software Defined

2003-01-17 Thread Ian Lance Taylor
Andre Hedrick [EMAIL PROTECTED] writes: However - the issue is not talking about .exe or .com files, but pluggin objects using the well known and publish API of the Linux Kernel. Why do you keep harping on this particular issue? Is anybody telling you that you can not distribute your

Re: Model Code for the OSD

2003-01-17 Thread David Johnson
On Friday 17 January 2003 09:57 am, Rod Dixon wrote: Larry List members: at your convenience, please download the current draft of the OSD's proposed model code. I have one nit. 4: Source code that is exceptionally difficult to read either because it is not documented or is cryptically