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,
:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 10:40 PM
To: Lawrence E. Rosen
Cc: [EMAIL PROTECTED]
Subject: RE: Derivative Work for Software Defined
On Thu, 16 Jan 2003, Lawrence E. Rosen wrote:
Can someone clear up the difference between mere
aggregation and a collective work?
As far as I
One Cambridge Center
Cambridge, MA 02142
[EMAIL PROTECTED]
-Original Message-
From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 11:08 PM
To: 'Brian Behlendorf'
Cc: [EMAIL PROTECTED]
Subject: RE: Derivative Work for Software Defined
OK, so I thought
]
-Original Message-
From: David Johnson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 10:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Derivative Work for Software Defined
On Wednesday 15 January 2003 07:14 am, PETERSON,SCOTT K (HP-USA,ex1) wrote:
That is not the same thing
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
(Scott, quote the GPL:)
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or collective
works based on the Program.
Can someone clear up
Can someone clear up the difference between mere
aggregation and a collective work?
As far as I can tell, a mere aggregation IS a collective work. The
former term has no meaning in the copyright law.
Is Red Hat Linux a
collective work or a mere aggregation of many different
software
On Thursday 16 January 2003 08:37 am, Brian Behlendorf wrote:
Can someone clear up the difference between mere aggregation and a
collective work? Is Red Hat Linux a collective work or a mere
aggregation of many different software packages, some of them GPL,
some under other open source
On Thu, 16 Jan 2003, Lawrence E. Rosen wrote:
Can someone clear up the difference between mere
aggregation and a collective work?
As far as I can tell, a mere aggregation IS a collective work. The
former term has no meaning in the copyright law.
OK, so I thought the GPL distinguished
OK, so I thought the GPL distinguished between the two - that
having a GPL program (I'm not thinking of the kernel here or
other things reasonably determined to be part of an
operating system, an allowance the GPL
makes) on the same CD as non-GPL bits, in a situation such as
a Red Hat
,ex1)
Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED];
[EMAIL PROTECTED]; 'Ian Lance Taylor'
Subject: RE: Derivative Work for Software Defined
Scott--
My critique of Larry's analysis is to say that considering whether A is a
derivative work of B is not necessarily the end of the analysis. What I
-USA,ex1)
Cc: [EMAIL PROTECTED]
Subject: Re: Derivative Work for Software Defined
On Tuesday 14 January 2003 01:56 pm, PETERSON,SCOTT K (HP-USA,ex1) wrote:
Larry --
You keep returning to contract obligations. But, I'm not relying on any
contract obligations. Any distribution that includes
)
Cc: [EMAIL PROTECTED]
Subject: Re: Derivative Work for Software Defined
On Tuesday 14 January 2003 01:56 pm, PETERSON,SCOTT K (HP-USA,ex1) wrote:
Larry --
You keep returning to contract obligations. But, I'm not relying on any
contract obligations. Any distribution that includes copyrightable
Someone has brought to my attention a scenario that may help to illustrate
what I've been talking about. So, I'm going to try few more letters of the
alphabet.
Assume that there is a standard API defined in a spec.
One author writes an application G that conforms to that spec (using the
API; I
PETERSON,SCOTT K \(HP-USA,ex1\) [EMAIL PROTECTED] writes:
Assume that there is a standard API defined in a spec.
One author writes an application G that conforms to that spec (using the
API; I think of this as sitting on top of the API) and offers this under the
GPL.
A second author writes
PETERSON,SCOTT K (HP-USA,ex1) scripsit:
Subtleties abound. So, I may very well be missing something. If so, I'm
hoping that someone on this list can set me straight.
IMHO you are as straight as you can be. Every work that is is to be distributed
must be examined to see if it is a derivative
Assume that someone statically links
object modules compiled from G and object modules compiled
from H into a single executable file (call this executable file G+H).
I believe that there is wide agreement that the GPL is
interpreted such that the author of G has not given
permission
Center
Cambridge, MA 02142
phone: 617-551-7612
mobile: 978-764-8615
[EMAIL PROTECTED]
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 12:54 PM
To: PETERSON,SCOTT K (HP-USA,ex1)
Cc: [EMAIL PROTECTED]
Subject: Re: Derivative Work
PETERSON,SCOTT K \(HP-USA,ex1\) [EMAIL PROTECTED] writes:
The only issue is whether G+H is a derived work of G, and that seems
obvious.
I think there is an additional issue, and one for which the resolution is
not necessarily obvious: to what sort of combinations of G and H does the
Lawrence E. Rosen scripsit:
Assume that someone statically links
object modules compiled from G and object modules compiled
from H into a single executable file (call this executable file G+H).
I believe that there is wide agreement that the GPL is
interpreted such that the author
Since it is settled that object code is a derivative work of
its source code, it seems to me to be maximally perverse to
argue that object code is not a derivative work of *part* of
its source code. A fortiori, the static-linking case seems
to me uncontroversial even in the absence of a
Scott,
You keep returning to contract obligations. But, I'm not
relying on any contract obligations. Any distribution that
includes copyrightable material from B needs the permission
of B's copyright owner. The hypothetical that I've presented
includes distribution of B. Thus, B's
On Wednesday 15 January 2003 07:14 am, PETERSON,SCOTT K (HP-USA,ex1) wrote:
That is not the same thing as saying that D has the positive
legal right to combine anything that D wants with X's material when
distributing X's material. To distribute both X's material and Y's
material, D requires
To: 'PETERSON,SCOTT K (HP-USA,ex1)'; 'Andre Hedrick'; 'Ian Lance Taylor'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Derivative Work for Software Defined
Scott,
I think your response would be appropriate if the GPL were a contract
rather than a mere copyright license. The GPL is intended
'
Subject: RE: Derivative Work for Software Defined
Larry --
I want to become a believer that the appropriate analysis
only requires determination of whether A is a derivative of
B. But I just don't see how that analysis squares with that
paragraph of section 2. I am stuck on that legal rule
-USA,ex1)'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Andre Hedrick';
'Ian Lance Taylor'
Subject: RE: Derivative Work for Software Defined
Scott,
I never suggested that a software license (speaking generally, now)
only requires a determination of whether A is a derivative of B.
Contracts set
: Tuesday, January 14, 2003 12:24 PM
To: 'PETERSON,SCOTT K (HP-USA,ex1)'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Andre Hedrick';
'Ian Lance Taylor'
Subject: RE: Derivative Work for Software Defined
Scott,
I never suggested that a software license (speaking generally, now)
only requires
On Tuesday 14 January 2003 01:56 pm, PETERSON,SCOTT K (HP-USA,ex1) wrote:
Larry --
You keep returning to contract obligations. But, I'm not relying on any
contract obligations. Any distribution that includes copyrightable material
from B needs the permission of B's copyright owner. The
Hedrick'; 'Ian Lance Taylor'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Derivative Work for Software Defined
I continue to believe that these confusing messages about derivative
works entirely miss the mark. Where in the statutory or case law can
one find support for such conclusions
]
-Original Message-
From: Ravicher, Daniel (x2826) [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 1:39 PM
To: 'PETERSON,SCOTT K (HP-USA,ex1)'; '[EMAIL PROTECTED]'; 'Andre
Hedrick'; 'Ian Lance Taylor'
Cc: [EMAIL PROTECTED]
Subject: RE: Derivative Work for Software Defined
Yes
On Tue, 7 Jan 2003, David Johnson wrote:
On Tuesday 07 January 2003 10:15 pm, Andre Hedrick wrote:
New twist:
user_space.c kernel_space.c
#include signal.h #include kernel/signal.h
#include kernel/signal.h
Arromdee [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 11:23 AM
To: [EMAIL PROTECTED]
Subject: Re: Derivative Work for Software Defined
On 8 Jan 2003, Ian Lance Taylor wrote:
But, again, it's not unclear for Linux.
Linus has clearly stated that
loadable binary modules are OK
On Monday 06 January 2003 11:05 pm, Ian Lance Taylor wrote:
It seems to me that you are drawing a distinct line between things
which are technically very similar. You may well be right to do so.
But I'm not sure why you are so confident.
I see three broad classes of dynamic and runtime
Okay now let me really rock the boat!
contributory infringement
indirect infringement
also the NeXT objective C release
Now add in a few cannonballs of the high board.
Using new FPGA compilers to bind and lock execution content into hardware
devices know as CAM or
the expression of
that interface. From this basis, I still advise
clients to use the abstraction layer approach.
Cheers. dj
-Original Message-
From: David Johnson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 2:21 AM
To: [EMAIL PROTECTED]
Subject: Re: Derivative Work
On Tuesday 07 January 2003 11:32 am, Don Jarrell wrote:
... Consider taking a
cast of a three-dimensional object. One does not
have an identical-looking thing, but more like a
mirror image, which still duplicates the curves,
or interface of the original and the cast.
Interesting thoughts,
New twist:
user_space.c kernel_space.c
#include signal.h #include kernel/signal.h
#include kernel/signal.h#include asm/signal.h
#include asm/signal.h
Where does signal.h from the compiler obtain its
On Tuesday 07 January 2003 10:15 pm, Andre Hedrick wrote:
New twist:
user_space.c kernel_space.c
#include signal.h #include kernel/signal.h
#include kernel/signal.h#include asm/signal.h
#include
On Mon, 6 Jan 2003, Andy Tai wrote:
You sell proprietary, or non-Free, software. How dare
you say you are doing the right thing? :-( :-)
rant
I am sorry the kids are hungary, and robbing banks is to much work.
After 5 years of giving away IP for free, I guess people expect to remain
hersey
On 6 Jan 2003, Ian Lance Taylor wrote:
[EMAIL PROTECTED] writes:
One of the questions about Derivative Work as it relates to binary
only loadable objects, is the creation of a boundary layer of execution.
Specifically, the design and publishing an API which properly glues into
an open
I continue to believe that these confusing messages about derivative
works entirely miss the mark. Where in the statutory or case law can
one find support for such conclusions as are reflected in these
messages?
If you don't create a work based upon one or more preexisting works
then you have
On 6 Jan 2003, Ian Lance Taylor wrote:
Andre Hedrick [EMAIL PROTECTED] writes:
One of the questions about Derivative Work as it relates to binary
only loadable objects, is the creation of a boundary layer of execution.
Specifically, the design and publishing an API which properly
Lawrence E. Rosen [EMAIL PROTECTED] writes:
If you don't create a work based upon one or more preexisting works
then you have simply not created a derivative work. 17 U.S.C. ยง101.
How in the world does an independently-written piece of software that
communicates with another
On Monday 06 January 2003 06:24 pm, Ian Lance Taylor wrote:
When writing a binary loadable module in Linux, can you really be
described as using a published API? I'm not aware of any meaningful
publishing of that API other than the Linux sources themselves, and
it's worth noting that API
Andre Hedrick [EMAIL PROTECTED] writes:
I ship and sell binary only products, so I have an interest in not
restricting people.
Other than your customers, presumably. Restrictions cut both ways.
In what way would a restrict cut both ways here?
Binary only products
So what if most of the Linux kernel is loadable modules? Probably
Linux is not a derivative work of those loadable modules, but instead a
compilation or collective work. The GPL doesn't require you to publish
the source code of either of those types of work.
But there are other reasons to
On Monday 06 January 2003 08:57 pm, Lawrence E. Rosen wrote:
...in order to gain an understanding of the unprotected
functional elements of the program...
By stating unprotected functional elements, the court has ruled that such
beasties actually exist! It implies that functionality is
Lawrence E. Rosen [EMAIL PROTECTED] writes:
So what if most of the Linux kernel is loadable modules? Probably
Linux is not a derivative work of those loadable modules, but instead a
compilation or collective work. The GPL doesn't require you to publish
the source code of either of those
One of the questions about Derivative Work as it relates to binary
only loadable objects, is the creation of a boundary layer of execution.
Specifically, the design and publishing an API which properly glues into
an open source gpl program or kernel(ie loadable modules services) designed
to
Thanks for your comments, Rod.
A public
re-distribution of the original work, for example, would trigger
compliance as well...to the extent that compliance issues arise.
Correct, I've subsumed in the meaning of derivative work an exact copy of
the original work, at least partially, because,
for analysis.
Best,
--Dan
-Original Message-
From: David Johnson [mailto:david;usermode.org]
Sent: Tuesday, November 12, 2002 10:25 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Derivative Work for Software Defined
On Tuesday 12 November 2002 07:36 am, Ravicher, Daniel \(x2826
Hmm...If I understood your proposal correctly, you were suggesting a useful
framework to respond to the often difficult assessment of how to determine
whether a licensee has created a derivative work. My response was that your
proposal/suggestion that the abstraction-filtration-comparison (AFC)
It's an intriguing idea, Dan, but your initial point that a derivative work
triggers the compliance with FOSS seems only partially correct. A public
re-distribution of the original work, for example, would trigger
compliance as well...to the extent that compliance issues arise.
In your second
On Tuesday 12 November 2002 07:36 am, Ravicher, Daniel \(x2826\) wrote:
Free / Open Source Software (FOSS) licensing relies critically on the
concept of
derivative work since software that is independent, i.e. not derivative, of
FOSS need not abide by the terms of the applicable FOSS license.
54 matches
Mail list logo
