Re: "Derivative Work" for Software Defined
"PETERSON,SCOTT K (HP-USA,ex1)" wrote: > 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. Part of the problem is that the term "mere aggregation" itself is ill-defined. An aggregation is a part-whole relationship. Winston et al [1] differentiates between three different types of parts: Functional parts are restricted, by their function, in their spatial or temporal location. For example, the handle of a cup can only be placed in a limited number of positions if it is to function as a handle. Homeomerous parts are of the same kind of thing as their wholes, for example `slice-pie', while non-homeomerous parts are different from their wholes, for example, `tree-forest'. Separable parts can, in principle, be separated from the whole, for example, `handle-cup', while inseparable parts cannot, for example `steel-bike'. Aggregation of different parts results in different characteristics of the whole ([1] defines a taxonomy of six part-whole relationships.) An example that illustrates that not all aggregations are transitive is that an arm is part of a musician, the musician is part of an orchestra, but the arm is not part of the orchestra (except, perhaps, in the minds of determined software developers creating an object-oriented model of an orchestra.) Getting back on topic, I believe that the interrelationship between mereology (the study of part-whole relationships), software, and law is important to bring clarity to this topic. Unfortunately, I am not familiar with such work. [1] Morton Winston, Roger Chaffin, Douglas Herrmann "A Taxonomy of Part-Whole Relations" Cognitive Science, vol. 11, pp. 417-444, 1987 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
Ian Lance Taylor scripsit: > It's true, as I believe Ken Aromdee pointed out, that because Linus > does not require copyright assignments, there are other copyright > holders involved. In any event, since it is most unlikely that those developers have registered their copyrights (speaking of the U.S. only here), even in the most flagrant breach of the license they would be restricted to actual, provable, money damages. And how likely is that? IANAL, TINLA. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
Andre Hedrick <[EMAIL PROTECTED]> writes: > > Think clearly. The GPL does not claim ownership of your work. It > > merely puts conditions on distributing your work combined with GPL > > work. The question you are raising is whether #including a GPL header > > file means that your work has been combined with GPL work. I don't > > think there is a definitive answer to that question. > > Without an answer, you leave all works in question. > The very question becomes the barrier to allow or permit the distribution. > If one is not sure, the distribution clause will be binding hook to > capture the entire as GPL, the 'who' is anyone raising the issue. Well, no, the ``who'' can only be the copyright owner of the work. Nobody else has any standing. > > (But I think there is a definitive answer for Linux, as opposed to > > some arbitrary work under the GPL, so why are you still worrying about > > this?) > > > > > GPL states you can change and do whatever you want, provide you return the > > > changes. > > > > No, it doesn't. Read it again. The GPL has no requirement for > > returning any changes to anybody. If you distribute source alongside > > your binaries, it has no requirement that you distribute source to > > anybody else. > > One does not ship the source alongside the binaries, what does that mean? Read the GPL, section 3. > Here is a real case of a local NAS/SAN company in Fremont, CA. > They have modifed my, and stated such to me they have, GPL drivers > which I share copyright with the folks who came before me. They ship and > sell product based on that those works. The do not ship source code with > the product. > > In this real example above, are they in GPL and/or Copyright violation? Based on what you say, they are presumably following GPL section 3b. If they are not, they are violating the GPL, and the copyright of the people who wrote the code they modified. > > distribute just enough source code to be able to use your binary > > modules, and you make the end-user build the source code. As with all > > these cases, nobody knows for sure whether it would be considered > > legal or not. I'm not aware that anybody has ever actually done it. > > Would you like a list of examples and the URL's to find and use them as > examples? Most of these effect my work in the open source world. Most of > these interfere or break the operations of my public works. > > Offline, I will disclose only. If you know of people who are violating the GPL, I encourage you to inform the copyright holders and the FSF. See http://www.fsf.org/licenses/gpl-violation.html > > Of course, I'm sure we're all clear that this has nothing to do with > > anything you want to do, because Linux already clearly permits binary > > modules. Right? > > "Right?" is the suggestion it may not be. > > If it was bloody simple then I would not be seeking the answer for myself. > Additionally if it is not legal, then all the vendors out there shipping > product w/ binary modules are in violation and must be brought back into > line. Why are you not satisfied by Linus's clear statement? It's true, as I believe Ken Aromdee pointed out, that because Linus does not require copyright assignments, there are other copyright holders involved. However, I would think that anybody who tried to make a claim would have a very hard time arguing that they did not understand the terms under which Linus accepts patches. (I personally think Linus is making a mistake in not requiring copyright assignments, but he has his reasons.) Wearing my hat as a businessperson, if I were in a business of distributing binary Linux loadable modules, I wouldn't worry about the legal issues associated with the GPL (I might worry about other issues, but not that one). As I know from experience, software businesses have much more serious IP issues to worry about in the patent realm; mostly you just have to charge ahead and hope for the best, since otherwise you will get nothing done. Lawsuits are for huge corporations or for people with nothing better to do. There is no such thing as a lawsuit-proof business, and in any case, for a small business, an unwarranted lawsuit is 90% as bad as a reasonable one. (In my last business, we burned way too much time and money in an absurd real estate dispute; we won completely in the end--for us, winning was getting free of the lawsuit, which was started by the other two parties, and we won our legal fees--but nothing will ever give us our time back.) Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
On 17 Jan 2003, Ian Lance Taylor wrote:
> 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 Linux loadable modules without
> source? Anybody at all?
See below:
> > Now lets move off to the land of Commerial OS's, specifically MicroSoft.
> > If any of you think a single judge would allow Bill Gates and company
> > to claim ownership of a third parties "ORIGINAL WORK" which is designed to
> > operate and expand the uses of the MicroSoft Operating System, please pass
> > around whatever you guys are smoking.
>
> Think clearly. The GPL does not claim ownership of your work. It
> merely puts conditions on distributing your work combined with GPL
> work. The question you are raising is whether #including a GPL header
> file means that your work has been combined with GPL work. I don't
> think there is a definitive answer to that question.
Without an answer, you leave all works in question.
The very question becomes the barrier to allow or permit the distribution.
If one is not sure, the distribution clause will be binding hook to
capture the entire as GPL, the 'who' is anyone raising the issue.
> (But I think there is a definitive answer for Linux, as opposed to
> some arbitrary work under the GPL, so why are you still worrying about
> this?)
>
> > GPL states you can change and do whatever you want, provide you return the
> > changes.
>
> No, it doesn't. Read it again. The GPL has no requirement for
> returning any changes to anybody. If you distribute source alongside
> your binaries, it has no requirement that you distribute source to
> anybody else.
One does not ship the source alongside the binaries, what does that mean?
Here is a real case of a local NAS/SAN company in Fremont, CA.
They have modifed my, and stated such to me they have, GPL drivers
which I share copyright with the folks who came before me. They ship and
sell product based on that those works. The do not ship source code with
the product.
In this real example above, are they in GPL and/or Copyright violation?
> > Now that I can do whatever and create whatever, and in this model I will
> > copy verbatium every operational function regardless of any associated
> > flag tatoo'd to the API symbols list. This secondary abstraction object
> > layer will be dual licensed as OSL/LGPL. Therefore it is permitted to use
> > any and all exported sysmbols regardless of games played.
>
> If you literally ``copy verbatim,'' then you have to follow the
> permissions granted by the copyright owner (in section 6, note
> ``subject to these terms and conditions''). Since the original is
> under the GPL, that more or less requires that your new code be under
> the GPL as well. That prohibits you from distributing it under an
> OSL/LGPL license.
>
> If you use a clean room approach to creating the new header files,
> then I expect that your approach is legal.
True a late night mistake.
The copy meant to refer to the '.c' which is under OSL/LGPL.
CONST STRUCT PTR VALUE PTR clapi_ (CONST STRUCT PTR VALUE PTR blah)
{
CONST STRUCT PTR VALUE PTR linux_((linux_struct) blah);
}
> > So one sells the work or program on a single media, and make them download
> > or purchase the associated GPL programs to use and execute the non-GPL
> > product. This bypasses the distribution controls and hooks of the
> > tarbaby-license. Also this makes the final destination, the enduser.
> > Distribution is over and ability to dictate the usage is gone, section
> > six (6). Now argue out of this box.
>
> This is an old argument, often called ``user does the link;'' you
Never would distribute any source code and force the user to perform said
task.
> distribute just enough source code to be able to use your binary
> modules, and you make the end-user build the source code. As with all
> these cases, nobody knows for sure whether it would be considered
> legal or not. I'm not aware that anybody has ever actually done it.
Would you like a list of examples and the URL's to find and use them as
examples? Most of these effect my work in the open source world. Most of
these interfere or break the operations of my public works.
Offline, I will disclose only.
The next arguement is the following:
If they true abstraction, then the distributed object would not need
updating, just the source wrappers. Right?
> Of course, I'm sure we're all clear that this has nothing to do with
> anything you want to do, because Linux already clearly permits binary
> modules. Right?
"Right?" is the suggestion it may not be.
If it was bloody simple then I would not be seeking the answer for myself.
Additionally if it is not legal, then all the vendors out there shipping
product w/ binary modules are in v
Re: "Derivative Work" for Software Defined
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 Linux loadable modules without source? Anybody at all? > Now lets move off to the land of Commerial OS's, specifically MicroSoft. > If any of you think a single judge would allow Bill Gates and company > to claim ownership of a third parties "ORIGINAL WORK" which is designed to > operate and expand the uses of the MicroSoft Operating System, please pass > around whatever you guys are smoking. Think clearly. The GPL does not claim ownership of your work. It merely puts conditions on distributing your work combined with GPL work. The question you are raising is whether #including a GPL header file means that your work has been combined with GPL work. I don't think there is a definitive answer to that question. (But I think there is a definitive answer for Linux, as opposed to some arbitrary work under the GPL, so why are you still worrying about this?) > GPL states you can change and do whatever you want, provide you return the > changes. No, it doesn't. Read it again. The GPL has no requirement for returning any changes to anybody. If you distribute source alongside your binaries, it has no requirement that you distribute source to anybody else. > Now that I can do whatever and create whatever, and in this model I will > copy verbatium every operational function regardless of any associated > flag tatoo'd to the API symbols list. This secondary abstraction object > layer will be dual licensed as OSL/LGPL. Therefore it is permitted to use > any and all exported sysmbols regardless of games played. If you literally ``copy verbatim,'' then you have to follow the permissions granted by the copyright owner (in section 6, note ``subject to these terms and conditions''). Since the original is under the GPL, that more or less requires that your new code be under the GPL as well. That prohibits you from distributing it under an OSL/LGPL license. If you use a clean room approach to creating the new header files, then I expect that your approach is legal. > So one sells the work or program on a single media, and make them download > or purchase the associated GPL programs to use and execute the non-GPL > product. This bypasses the distribution controls and hooks of the > tarbaby-license. Also this makes the final destination, the enduser. > Distribution is over and ability to dictate the usage is gone, section > six (6). Now argue out of this box. This is an old argument, often called ``user does the link;'' you distribute just enough source code to be able to use your binary modules, and you make the end-user build the source code. As with all these cases, nobody knows for sure whether it would be considered legal or not. I'm not aware that anybody has ever actually done it. Of course, I'm sure we're all clear that this has nothing to do with anything you want to do, because Linux already clearly permits binary modules. Right? Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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 "contracts" v. "[something else]". I'm not my self comfortable that "contract" is the right word to use for one side of this contrast (I believe that, analytically, contract law has a role in both of these), but I'll use it here because I don't see another term readily at hand. To set up some terminology, let's assume that the two parties are an author of some material and a user who wants to do something with that material. I believe that the "contract" situation is one in which it is necessary to get the user's specific agreement to the contract terms - something by which they have manifest their assent to being obligated to the terms of the agreement such as might be indicated by signing a paper document or clicking an 'accept' button. Without such assent, there is no legal mechanism that the author can prevent the user from doing the thing stated in the agreement. In the "something else" case, the thing that the user wants to do is something about which there is a public law (as contrasted with the private law of a contract) that says that the user can't do the thing without the author's permission. The public law of interest, of course, is copyright law. So, if what the user wants to do anything that is an exclusive right of the author under the copyright law, then the author can legally prevent that behavior of the user, even if the user has never agreed with the author to take on any obligations to the author. I emphasize the word to point out a detail that I think is getting lost in some discussions. In the book example: "affect the distribution of Dean Koontz books that happened to be sitting on the same book shelf " - without that sort of separate "contract" that I've described, this is true. But that fact has nothing to do with how the relationship between the book. It is because your hypothetical does not include doing anything that is an exclusive right of King - you have not assumed that the person distributing Koontz also wants to do something that needs King's permission, such as copy and distribute King's book. For example, King might offer the permission to copy and distribute his book on the condition that the person doing so not distribute Koontz's book. Note that in the magazine example, permission IS required because the hypothetical assumes copying and distribution of stories by both authors. The significant difference between the two is the copying, not whether a collective work is protected under the copyright law. -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 phone: 617-551-7612 mobile: 978-764-8615 [EMAIL PROTECTED] -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 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 permission of both X and Y. X could decide to decline > to give that permission for the case where X's material was distributed on > the same medium with Y's material. Reading a later message from you, I finally see what the '+' means in your "A+B". It means a separate object C that is derived from both A and B. This isn't aggregation. I believe the proper term is "compilation", which is a form of derivative work. For example, Stephen King couldn't place a copyright-based license on his books that would affect the distribution of Dean Koontz books that happened to be sitting on the same book shelf. Neither could he do it for a story of his published in a magazine. But he *could* use a copyright-based license that affected the distribution of the magazine, which also happened to contain a story by Dean Koontz. A magazine is an example of a compilation. It's what you would call "A+B". The copyrights of the individual stories and articles cannot affect each other, but they could affect the magazine. A+B Magazine requires the permission of both author A and author B to publish their stories. But A+B Magazine does not need the permission of A in order to publish B, or vice versa, without a contract in place to the contrary. O
RE: "Derivative Work" for Software Defined
> 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 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 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 Linux CD, was OK because it was "mere aggregation", > which the GPL explicitly allows, and not a "collective work", > which the GPL states > *would* be under the GPL. Maybe "mere aggregation" has no > meaning w/r/t copyright law, but am I mistaken in thinking > the GPL makes the distinction? I don't understand these subtle distinctions people are reading into the GPL. Section 2 of the GPL grants permission to "modify your copy or copies of the Program or any portion of it." In that context, I have never understood the reference within that section to "the right to control the distribution of ... collective works based on the Program." A collective work is defined clearly in copyright law and is different from a modified (or derivative) work. One does not modify a work in the course of creating a collective work. If one merely copies the original work unchanged, that falls under section 1 of the GPL, not section 2. Those words in section 2 dealing with "mere aggregation" seem out of place. I'm even more confused about the words "work based on the Program," but I've addressed that before and won't repeat it now. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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. I read the GPL as giving permission to distribute the GPL-licensed code with code under incompatible licenses when a part of some collective works (at least those that are mere aggregations)(see the paragraph in GPL section 2 that mentions mere aggregations), but not when a part of all collective works (see the two paragraphs preceding the mere aggregations paragraph). -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -Original Message- From: Brian Behlendorf [mailto:[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 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 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 Linux CD, was OK because it was "mere aggregation", which the GPL explicitly allows, and not a "collective work", which the GPL states *would* be under the GPL. Maybe "mere aggregation" has no meaning w/r/t copyright law, but am I mistaken in thinking the GPL makes the distinction? Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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", ".h", and the unprotected API. > but the result of combining > compiled-G and compiled-H into an executable form. This is a bogus statement, and excessively broad. What do you thing #include <__insert_api_header_dot_h> does? The operation of #include is nothing but a simple concatenation. Now given the contents of a 'dot h' file, please tell me what you are going to run as an executable program? Given the contents general are a list of define's, typedef's, struct's, extern's, const's, classes' G is nothing but a header file. (api descriptions) H is nothing but a c-code file. (original work) cc -O2 -c -o G.o G.h cc[error] no G.c found to generate G.o cc -O2 -c -o H.o H.c cc[error] unknown struct or variable in line XXX of H.c ld -r -o G+H.exe G.o H.o ld[error] no objects found to link. 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. Now lets move off to the land of Commerial OS's, specifically MicroSoft. If any of you think a single judge would allow Bill Gates and company to claim ownership of a third parties "ORIGINAL WORK" which is designed to operate and expand the uses of the MicroSoft Operating System, please pass around whatever you guys are smoking. GPL states you can change and do whatever you want, provide you return the changes. These changes generally mean, alterations of existing works. No where does it state, a new work has to be lost to this tarbaby of a license. Please try to use simple logic, and quit confusing horses and wishes. What is my position of authority, one of the authors who has created lots of files. Now let me really screws in the thumbs. GPL version 2 Linux Kernel + New Original Work w/ Export CLAPI I am about ready to dig out an old project of mine and then bait everyone of you to come after me with your silly GPL drum "Derivative Work". Commerial Linux API, pronounced CLA(y) PI(e). -- CLA(y) is a moldable media capable of taking any form -- PI(e) 1) for the irrational zealots who hurt growth. 2) calm the irrational vendors have about "1". This was designed to allow commerial binary only module vendor to use a full abstracted interface to run anything they want. If you tell me I can not create this work, I will cite GPL against you for restricting and impose policies that limit my use. Clearly you will be in the wrong, but I am dying hear one of you prove me wrong here. I believe it is section six (6). -- 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. -- If you tell me I can not do this, then you have to explain away the above. I will be back with some popcorn, to enjoy the show. Now that I can do whatever and create whatever, and in this model I will copy verbatium every operational function regardless of any associated flag tatoo'd to the API symbols list. This secondary abstraction object layer will be dual licensed as OSL/LGPL. Therefore it is permitted to use any and all exported sysmbols regardless of games played. Since the associated headers for CLAPI are no needed to created the new module+its exported api, I do not have to redistribute 'it' or the 'set'. This is supported by the paragraph under section two (2). -- These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. -- Now my set of header(s) will grant me access regardless, and you have nothing to say and not a thing you can do about it. Try and prevent me from creating such a work, you will beaten silly with section six (6) of GPL license. Now try to force me to release my headers, we goto court. Below is your bases to think you can force the releasing the header
RE: "Derivative Work" for Software Defined
> 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 Linux CD, was OK because it was "mere aggregation", > which the GPL explicitly allows, and not a "collective work", > which the GPL states > *would* be under the GPL. Maybe "mere aggregation" has no > meaning w/r/t copyright law, but am I mistaken in thinking > the GPL makes the distinction? I don't understand these subtle distinctions people are reading into the GPL. Section 2 of the GPL grants permission to "modify your copy or copies of the Program or any portion of it." In that context, I have never understood the reference within that section to "the right to control the distribution of ... collective works based on the Program." A collective work is defined clearly in copyright law and is different from a modified (or derivative) work. One does not modify a work in the course of creating a collective work. If one merely copies the original work unchanged, that falls under section 1 of the GPL, not section 2. Those words in section 2 dealing with "mere aggregation" seem out of place. I'm even more confused about the words "work based on the Program," but I've addressed that before and won't repeat it now. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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 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 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 Linux CD, was OK because it was "mere aggregation", which the GPL explicitly allows, and not a "collective work", which the GPL states *would* be under the GPL. Maybe "mere aggregation" has no meaning w/r/t copyright law, but am I mistaken in thinking the GPL makes the distinction? Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 licenses, some of them not? >From Title 17, Section 101 - Definitions: 'A ''collective work'' is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.' 'A ''compilation'' is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term ''compilation'' includes collective works.' I can find no references to "aggregation" except in an unrelated area dealing with transmissions. I suspect the term is used in the GPL as a synonym for "collective work". -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
> 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 packages, some of them GPL, some under other open > source licenses, some of them not? I believe it is a collective work. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
(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 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 licenses, some of them not? Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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 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 permission of both X and Y. X could decide to decline > to give that permission for the case where X's material was distributed on > the same medium with Y's material. Reading a later message from you, I finally see what the '+' means in your "A+B". It means a separate object C that is derived from both A and B. This isn't aggregation. I believe the proper term is "compilation", which is a form of derivative work. For example, Stephen King couldn't place a copyright-based license on his books that would affect the distribution of Dean Koontz books that happened to be sitting on the same book shelf. Neither could he do it for a story of his published in a magazine. But he *could* use a copyright-based license that affected the distribution of the magazine, which also happened to contain a story by Dean Koontz. A magazine is an example of a compilation. It's what you would call "A+B". The copyrights of the individual stories and articles cannot affect each other, but they could affect the magazine. A+B Magazine requires the permission of both author A and author B to publish their stories. But A+B Magazine does not need the permission of A in order to publish B, or vice versa, without a contract in place to the contrary. On the other hand, A could use a copyright-based license that would affect the distribution of A+B Magazine. Such a license might force the magazine not to publish both stories in the same issue. The GPL section two is addressing such a situation. It states that the license does not cover other articles in the magazine, but that it does affect the magazine. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
> 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 case on all > fours with it. Did I argue that? When? I may be perverse, but "maximally" so? > > I am still not certain what is meant by the phrase "work > based on the > > Program." Under your scenario, G and H are entirely independent > > creations. If G+H requires merely the making of copies of > G and H, an > > act permitted without restriction by the GPL, then why is it a > > derivative work? Why is that a work based on the Program? > > Because G+H is not merely G concatenated with H, but the > result of combining compiled-G and compiled-H into an executable form. Here we go again. Where do you see the words "concatenated" or "combining ... into an executable form" anywhere in copyright law or in the GPL? What do those words mean? What is to make your interpretation of those words have any importance to a federal judge? I'm not deliberately pretending that I don't speak English. I know what those words mean in common parlance. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 of G has not given > > permission for distribution of that single executable file. > > I don't know that there is widespread agreement to either of those > propositions. Indeed, isn't that really what we've all been discussing? > [I must admit, I once publicly argued the point your way, but I have > since recanted because I couldn't find any statutory or case law support > for my earlier position.] 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 case on all fours with it. > I am still not certain what is meant by the phrase "work based on the > Program." Under your scenario, G and H are entirely independent > creations. If G+H requires merely the making of copies of G and H, an > act permitted without restriction by the GPL, then why is it a > derivative work? Why is that a work based on the Program? Because G+H is not merely G concatenated with H, but the result of combining compiled-G and compiled-H into an executable form. -- They do not preach John Cowan that their God will rouse them[EMAIL PROTECTED] A little before the nuts work loose.http://www.ccil.org/~cowan They do not teach http://www.reutershealth.com that His Pity allows them --Rudyard Kipling, to drop their job when they damn-well choose. "The Sons of Martha" -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
> 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 for distribution of that single executable file. > (I also believe there is less widespread agreement on the > alternative where the linking occurs at runtime.) I don't know that there is widespread agreement to either of those propositions. Indeed, isn't that really what we've all been discussing? [I must admit, I once publicly argued the point your way, but I have since recanted because I couldn't find any statutory or case law support for my earlier position.] > H is not a derivative work of G. So, how does one get to this > widely agreed result? I believe that that interpretation > assumes that G+H is a "work based on the Program". So, it > looks to me like it is generally agreed that the GPL does > indeed concern itself with whether G and H are parts of > something larger (not necessarily every larger thing, but at > least some sorts of larger things). Thus, it seems that > stopping analysis at the point of determining that H is not a > derivative of G is failing to complete the analysis needed to > judge compliance with the GPL. I am still not certain what is meant by the phrase "work based on the Program." Under your scenario, G and H are entirely independent creations. If G+H requires merely the making of copies of G and H, an act permitted without restriction by the GPL, then why is it a derivative work? Why is that a work based on the Program? /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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 permission is needed. > I'm trying to understand the conditions the copyright owner > has attached to the copyright owner's offer of permission to > distribute B (the conditions in the GPL). So, the conditions > specified in the GPL are relevant to what someone needs to do > in order to legally distribute A+B, without regard to whether > A+B is has some special status as a protected copyrightable > work (B's protectable status is enough). I keep returning to contract obligations because under copyright law there are only a limited set of exclusive rights that may be licensed, namely to make copies, prepare derivative works, distribute copies, perform and display. Where in the statute is there any reference to an exclusive right to make a "work based on the Program" or a "Larger Work"? How is a court to interpret those phrases? Why should the court even try to do so? Are those things more than a derivative work or less? Why is the licensor's interpretation of those phrases in any way binding upon licensees? The GPL grants an unlimited right to make copies but a conditional right to make derivative works (with some other words in the license about a limited right to make a "work based on the Program"). The only way a judge can interpret that license is to determine whether what is being made -- your A+B, for example, where A is the GPL-licensed work -- involves making a copy of A or creating a derivative work of A. If the former, then the license is clear that there are no reciprocal obligations. If the latter, then the license is also clear that the author of A+B must disclose his source code. That's the question we've all been struggling with. Does linking require merely the making of a copy or is it the creation of a derivative work? We're now back at square one. How does the language you quoted from section 2 help the judge perform that analysis? Why should the judge care at all that those other words are in the license, given that there is no proof whatsoever that the licensee either read or assented to that extra language? If the GPL is just a copyright license then none of that extra language matters. The only question is, has a license been granted to make a copy or to create a derivative work? But if you've got a contract to which the licensee assented, then the licensee is bound by the entire contract. The court is required to interpret a contract in light of the entire document, attempting to find a consistent interpretation that most nearly satisfies the agreed objectives of the parties. The definitions in the contract will guide its interpretation. I am perplexed by the apparent reluctance of the authors of the GPL and by you to allow the GPL to *also* be treated as a contract. If one does that, all the problems you're pointing out disappear. There will no longer be any ambiguity because the *contract* would have to be interpreted as a whole, not merely as a copyright license. What would the GPL lose by also being treated as a contract? The GPL would have much to gain by being treated as a contract. Most importantly, it would become enforceable by any licensor and not just by a copyright holder. Your invitation to "sit back in the comfort of some overstuffed chairs, possibly with a beverage in hand, and have a relaxing interactive discussion" is gratefully accepted. Depending upon the beverage I might even be convinced of the correctness of your analysis, but that will take more than one drink. :-) I think we're both going to be in Seattle soon at the same meeting, so perhaps then /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
"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 > condition in section 2 of the GPL extend? In other words, what sorts of > things are G+Hs rather than just G aggregated with H? I don't see why that is relevant for the example which you presented. Can you explain? I must admit that I don't know what you are driving at in this series of messages. That part of section 2 of the GPL seems to me to be aimed at clarifying the GPL authors' interpretation of what derived work, or ``a work based on the program,'' means in the context of computer software. I think it's important to note that that part of section 2 doesn't actually claim any rights over work which is not derived from the GPL-covered work. The only point of that text is to clarify that the authors of the GPL don't intend certain cases of distribution to be covered by the GPL. And they say what those cases are: work which ``can be reasonably considered independent and separate works in themselves.'' I would say that if you have a G+H case which is not, in law, derived from GPL-covered G, then the GPL does not apply (this test is not currently useful because the law does not exist). I would also say that if you have a G+H case which is, in law, derived from GPL-covered G, but which ``can be reasonably considered independent'' of G, then the GPL does not apply. So now that I've said that, I see that you could be asking how to decide those cases in which G+H is, in law, derived from G, but which at the same time might possibly ``be reasonably considered independent'' of G. If that is your question, my personal answer would be two-fold. First, we don't know if there are any such cases, because we don't know what the law says about whether G+H is derived from G. Second, if we did know the law, I doubt there would be any such cases; I suspect that if any G+H were, in law, derived from G, then nobody would reasonably consider such a G+H to be independent of G. So my personal feeling is that you may be trying to clarify a category which does not exist. I interpret that part of section 2 of the GPL as the GPL author's attempt to provide guidance in the absence of law, not in replacement of law. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
"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 work of any GPLed work and also a derivative work of a work licensed under an incompatible license. If so, its distribution is forbidden by the GPL. -- Some people open all the Windows; John Cowan wise wives welcome the spring [EMAIL PROTECTED] by moving the Unix. http://www.reutershealth.com --ad for Unix Book Units (U.K.) http://www.ccil.org/~cowan (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
Ian -- "But it's clear that G+H is covered by the GPL regardless of the status of H." This is exactly what I've been getting at. "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 condition in section 2 of the GPL extend? In other words, what sorts of things are G+Hs rather than just G aggregated with H? -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge 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" for Software Defined "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 a library H that conforms to that spec (implementing > the API; I think of this as sitting under the API) and offers this under a > GPL-incompatible license. > Assume that G and H were wholly unaware of each other's work. Thus, G is not > a derivative work of H and H is not a derivative work of G. > 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 for distribution of that single > executable file. (I also believe there is less widespread agreement on the > alternative where the linking occurs at runtime.) Well, more precisely, distribution of the executable generated from G+H must be accompanied by the source code of G and H, or by an offer to provide that source code to any caller. > H is not a derivative work of G. So, how does one get to this widely agreed > result? I believe that that interpretation assumes that G+H is a "work based > on the Program". So, it looks to me like it is generally agreed that the GPL > does indeed concern itself with whether G and H are parts of something > larger (not necessarily every larger thing, but at least some sorts of > larger things). Thus, it seems that stopping analysis at the point of > determining that H is not a derivative of G is failing to complete the > analysis needed to judge compliance with the GPL. The GPL covers G+H because G is under the GPL, and G+H is a derived work of G. I see no issue here of whether G and H are parts of something larger. I see no issue of whether H is a derived work of G. The only issue is whether G+H is a derived work of G, and that seems obvious. You don't even have to think about the legal status of H to determine that G+H is covered by the GPL. Thinking about the legal status of H may cause you to believe that G+H may not be covered by the GPL--e.g., H may be under a proprietary license of some sort--which would imply that distribution of G+H is forbidden. But it's clear that G+H is covered by the GPL regardless of the status of H. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
"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 a library H that conforms to that spec (implementing > the API; I think of this as sitting under the API) and offers this under a > GPL-incompatible license. > Assume that G and H were wholly unaware of each other's work. Thus, G is not > a derivative work of H and H is not a derivative work of G. > 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 for distribution of that single > executable file. (I also believe there is less widespread agreement on the > alternative where the linking occurs at runtime.) Well, more precisely, distribution of the executable generated from G+H must be accompanied by the source code of G and H, or by an offer to provide that source code to any caller. > H is not a derivative work of G. So, how does one get to this widely agreed > result? I believe that that interpretation assumes that G+H is a "work based > on the Program". So, it looks to me like it is generally agreed that the GPL > does indeed concern itself with whether G and H are parts of something > larger (not necessarily every larger thing, but at least some sorts of > larger things). Thus, it seems that stopping analysis at the point of > determining that H is not a derivative of G is failing to complete the > analysis needed to judge compliance with the GPL. The GPL covers G+H because G is under the GPL, and G+H is a derived work of G. I see no issue here of whether G and H are parts of something larger. I see no issue of whether H is a derived work of G. The only issue is whether G+H is a derived work of G, and that seems obvious. You don't even have to think about the legal status of H to determine that G+H is covered by the GPL. Thinking about the legal status of H may cause you to believe that G+H may not be covered by the GPL--e.g., H may be under a proprietary license of some sort--which would imply that distribution of G+H is forbidden. But it's clear that G+H is covered by the GPL regardless of the status of H. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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 think of this as sitting on top of the API) and offers this under the GPL. A second author writes a library H that conforms to that spec (implementing the API; I think of this as sitting under the API) and offers this under a GPL-incompatible license. Assume that G and H were wholly unaware of each other's work. Thus, G is not a derivative work of H and H is not a derivative work of G. 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 for distribution of that single executable file. (I also believe there is less widespread agreement on the alternative where the linking occurs at runtime.) H is not a derivative work of G. So, how does one get to this widely agreed result? I believe that that interpretation assumes that G+H is a "work based on the Program". So, it looks to me like it is generally agreed that the GPL does indeed concern itself with whether G and H are parts of something larger (not necessarily every larger thing, but at least some sorts of larger things). Thus, it seems that stopping analysis at the point of determining that H is not a derivative of G is failing to complete the analysis needed to judge compliance with the GPL. Subtleties abound. So, I may very well be missing something. If so, I'm hoping that someone on this list can set me straight. -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
David -- "They do not have the right to control the distribution of other works." I agree. But that misses the point. Assume two bodies of copyrightable material in which the copyright in each is owned by a different person (X and Y) and neither body of copyrightable material includes any copyrightable material from the other person. Assume that D would like to distribute both of these As you say, X cannot prevent distribution of Y's material. 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 permission of both X and Y. X could decide to decline to give that permission for the case where X's material was distributed on the same medium with Y's material. I use the extreme restriction above to illustrate the legal possibilities. The GPL does not go as far as the arrangement hypothesized for X above. The GPL explicitly permits combined distribution of mere aggregations on a single medium. I use this example to point out why I see no basis for the argument that a restriction on material of others can't legally happen in a permission-based arrangement. "But can they control the distribution of other works that reside on the same media as their own? That's your question in a nutshell, I think." Not that's not a question in my mind. It is clear that that is legally possible. It is also clear that the GPL does go that far, as indicated by the "mere aggregation" language in the GPL. Instead, the GPL limits its copyleft scope to material that has some more particular relationship to the material originally licensed under the GPL. For the following discussion, I'll reuse the hypothetical in an earlier message: assume some code A and some code B. Assume that B is licensed under the GPL and that one is trying to answer the question, "When I distribute A and B together, must A be distributed under the GPL?" Some appear to assert that the only relationship that matters under the GPL is whether A is a derivative work of B. That interpretation appears to me to be inconsistent with the plain language of the GPL: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. "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." So, the question I've been trying to ask is how one can interpret that language in a way that is consistent with the view that all that matters is whether A is a derivative work of B. -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 phone: 617-551-7612 mobile: 978-764-8615 [EMAIL PROTECTED] -Original Message- From: David Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 11:30 PM To: PETERSON,SCOTT K (HP-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 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 permission is needed. > I'm trying to understand the conditions the copyright owner has attached to > the copyright owner's offer of permission to distribute B (the conditions > in the GPL). So, the conditions specified in the GPL are relevant to what > someone needs to do in order to legally distribute A+B, without regard to > whether A+B is has some special status as a protected copyrightable work > (B's protectable status is enough). Authors have the right to control the distribution of their own works. They do not have the right to control the distribution of other works. But can they control the distribution of other works that reside on the same media as their own? That's your question in a nutshell, I think. I don'
RE: "Derivative Work" for Software Defined
RESEND David -- "They do not have the right to control the distribution of other works." I agree. But that misses the point. Assume two bodies of copyrightable material in which the copyright in each is owned by a different person (X and Y) and neither body of copyrightable material includes any copyrightable material from the other person. Assume that D would like to distribute both of these As you say, X cannot prevent distribution of Y's material. 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 permission of both X and Y. X could decide to decline to give that permission for the case where X's material was distributed on the same medium with Y's material. I use the extreme restriction above to illustrate the legal possibilities. The GPL does not go as far as the arrangement hypothesized for X above. The GPL explicitly permits combined distribution of mere aggregations on a single medium. I use this example to point out why I see no basis for the argument that a restriction on material of others can't legally happen in a permission-based arrangement. "But can they control the distribution of other works that reside on the same media as their own? That's your question in a nutshell, I think." Not that's not a question in my mind. It is clear that that is legally possible. It is also clear that the GPL does go that far, as indicated by the "mere aggregation" language in the GPL. Instead, the GPL limits its copyleft scope to material that has some more particular relationship to the material originally licensed under the GPL. For the following discussion, I'll reuse the hypothetical in an earlier message: assume some code A and some code B. Assume that B is licensed under the GPL and that one is trying to answer the question, "When I distribute A and B together, must A be distributed under the GPL?" Some appear to assert that the only relationship that matters under the GPL is whether A is a derivative work of B. That interpretation appears to me to be inconsistent with the plain language of the GPL: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. "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." So, the question I've been trying to ask is how one can interpret that language in a way that is consistent with the view that all that matters is whether A is a derivative work of B. -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 phone: 617-551-7612 mobile: 978-764-8615 [EMAIL PROTECTED] -Original Message- From: David Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 11:30 PM To: PETERSON,SCOTT K (HP-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 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 permission is needed. > I'm trying to understand the conditions the copyright owner has attached to > the copyright owner's offer of permission to distribute B (the conditions > in the GPL). So, the conditions specified in the GPL are relevant to what > someone needs to do in order to legally distribute A+B, without regard to > whether A+B is has some special status as a protected copyrightable work > (B's protectable status is enough). Authors have the right to control the distribution of their own works. They do not have the right to control the distribution of other works. But can they control the distribution of other works that reside on the same media as their own? That's your question in a nutshell, I think. I don
RE: "Derivative Work" for Software Defined
Andre -- The only point that I really want to make in these messages is the following: I observe interpretations of the GPL have been offered that appear to me to be inconsistent with the language of the GPL. I'm trying to understand how I might be misreading that apparently inconsistent language in the GPL. As in an earlier message, "I want to become a believer ...". But, I can't embrace an interpretation of the GPL that I can't reconcile with the language of the GPL. For more detail, see the message to David Johnson that I sent a few minutes ago. -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 phone: 617-551-7612 mobile: 978-764-8615 [EMAIL PROTECTED] -Original Message- From: Andre Hedrick [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 5:32 PM To: PETERSON,SCOTT K (HP-USA,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 ^^ Provide one does not introduce subjective points, but where are the points of fact and not beliefs? > failed to point out in my previous message (and what I'll try to make > explicit here) is the following: I believe that one should also consider the ^^ Where is your proof in the equation of facts. A+B == AB == BA == A^B == B^A or ~= Ae^B ~= e^AB > question of whether A+B is one program. In that case, A+B is a "work based > on the Program" and A+B is a derivative work of the Program, even though A > might not be a derivative work of B. I see this as being wholly consistent > with sections 0 and 2. What you do not have is a test to discriminate. What you have not addressed is A+C == A' and C+B == B'. C == the abstraction between the two items or their communication path. C may be the resulting derived work, but the copyright is own by the author of the original work A. A has the legal right to use C however it wishes. C also complies with any issues B has in the tainting by GPL. So we have both A and B disassociated, and C is joint operation. Comments? Andre Hedrick LAD Storage Consulting Group IANAL, but Storage Technologist. On Tue, 14 Jan 2003, 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 hypothetical that > I've presented includes distribution of B. Thus, B's permission is needed. > I'm trying to understand the conditions the copyright owner has attached to > the copyright owner's offer of permission to distribute B (the conditions in > the GPL). So, the conditions specified in the GPL are relevant to what > someone needs to do in order to legally distribute A+B, without regard to > whether A+B is has some special status as a protected copyrightable work > (B's protectable status is enough). > > I think you may be saying that if A is not a copyright infringement of B, > then there is no copyright problem and thus the GPL is not relevant. That's > fine for distribution of A by itself. However, the person who wants to > distribute A and B together (even if only as a mere aggregation) still needs > the permission of the B's copyright owner and thus, needs to know what > conditions the GPL might require. (Look up both sleeves. No contract > obligation in sight. Really!) > > I may not be understanding what you are saying, and we may be talking in > circles. Perhaps we should await some opportunity when we can sit back in > the comfort of some overstuffed chairs, possibly with a beverage in hand, > and have a relaxing interactive discussion. > > -- Scott > > I can now see how confusing my use of A+B is. That is based on a > hypothetical in a parallel discussion branch - I introduced it in my reply > to David Ravicher: > - > It is apparent that I have been unclear about what I meant, so let me try a > hypothetical. > > Assume some code A and some code B. Assume that B is licensed under the GPL > and that one is trying to answer the question, "When I distribute A and B > together, must A be distributed under the GPL?" > 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
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 material > from B needs the permission of B's copyright owner. The hypothetical that > I've presented includes distribution of B. Thus, B's permission is needed. > I'm trying to understand the conditions the copyright owner has attached to > the copyright owner's offer of permission to distribute B (the conditions > in the GPL). So, the conditions specified in the GPL are relevant to what > someone needs to do in order to legally distribute A+B, without regard to > whether A+B is has some special status as a protected copyrightable work > (B's protectable status is enough). Authors have the right to control the distribution of their own works. They do not have the right to control the distribution of other works. But can they control the distribution of other works that reside on the same media as their own? That's your question in a nutshell, I think. I don't think they can without a contract. But it doesn't matter because copyright covers the case where A+B is a derivative work, and the GPL covers the case where A+B are separate works aggregated. What other cases are there that don't reside in obscure corners? Side note: The way I understand GPL section 2, is that the "whole" must be under the GPL, but the individual parts do not. An example of this would be kdebase, which includes BSD, Artistic, QPL and GPL applications tarballed together into a single GPL licensed file. Another would be the Linux kernel where a few source files are under the BSD license, but the kernel itself must still be under the GPL. In both cases you can extract the non-GPL pieces and distribute them separately under their original license. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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 ^^ Provide one does not introduce subjective points, but where are the points of fact and not beliefs? > failed to point out in my previous message (and what I'll try to make > explicit here) is the following: I believe that one should also consider the ^^ Where is your proof in the equation of facts. A+B == AB == BA == A^B == B^A or ~= Ae^B ~= e^AB > question of whether A+B is one program. In that case, A+B is a "work based > on the Program" and A+B is a derivative work of the Program, even though A > might not be a derivative work of B. I see this as being wholly consistent > with sections 0 and 2. What you do not have is a test to discriminate. What you have not addressed is A+C == A' and C+B == B'. C == the abstraction between the two items or their communication path. C may be the resulting derived work, but the copyright is own by the author of the original work A. A has the legal right to use C however it wishes. C also complies with any issues B has in the tainting by GPL. So we have both A and B disassociated, and C is joint operation. Comments? Andre Hedrick LAD Storage Consulting Group IANAL, but Storage Technologist. On Tue, 14 Jan 2003, 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 hypothetical that > I've presented includes distribution of B. Thus, B's permission is needed. > I'm trying to understand the conditions the copyright owner has attached to > the copyright owner's offer of permission to distribute B (the conditions in > the GPL). So, the conditions specified in the GPL are relevant to what > someone needs to do in order to legally distribute A+B, without regard to > whether A+B is has some special status as a protected copyrightable work > (B's protectable status is enough). > > I think you may be saying that if A is not a copyright infringement of B, > then there is no copyright problem and thus the GPL is not relevant. That's > fine for distribution of A by itself. However, the person who wants to > distribute A and B together (even if only as a mere aggregation) still needs > the permission of the B's copyright owner and thus, needs to know what > conditions the GPL might require. (Look up both sleeves. No contract > obligation in sight. Really!) > > I may not be understanding what you are saying, and we may be talking in > circles. Perhaps we should await some opportunity when we can sit back in > the comfort of some overstuffed chairs, possibly with a beverage in hand, > and have a relaxing interactive discussion. > > -- Scott > > I can now see how confusing my use of A+B is. That is based on a > hypothetical in a parallel discussion branch - I introduced it in my reply > to David Ravicher: > - > It is apparent that I have been unclear about what I meant, so let me try a > hypothetical. > > Assume some code A and some code B. Assume that B is licensed under the GPL > and that one is trying to answer the question, "When I distribute A and B > together, must A be distributed under the GPL?" > 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 > failed to point out in my previous message (and what I'll try to make > explicit here) is the following: I believe that one should also consider the > question of whether A+B is one program. In that case, A+B is a "work based > on the Program" and A+B is a derivative work of the Program, even though A > might not be a derivative work of B. I see this as being wholly consistent > with sections 0 and 2. > > What I don't understand is that, if all one needs to do is to answer the > question, "Is A a derivative work of B?", then what is the point of the > paragraph in section 2 that I quoted in my earlier message (below). > - > __ > Scott K. Peterson > Corporate Counsel > Hewlett-Packard Company > One Cambridge Center > Cambridge, MA 02142 > [EMAIL PROTECTED] > > -Original Message- > From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 12:24 PM > To: 'PETERSON,SCOTT K (HP-USA,ex1)' >
RE: "Derivative Work" for Software Defined
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 hypothetical that I've presented includes distribution of B. Thus, B's permission is needed. I'm trying to understand the conditions the copyright owner has attached to the copyright owner's offer of permission to distribute B (the conditions in the GPL). So, the conditions specified in the GPL are relevant to what someone needs to do in order to legally distribute A+B, without regard to whether A+B is has some special status as a protected copyrightable work (B's protectable status is enough). I think you may be saying that if A is not a copyright infringement of B, then there is no copyright problem and thus the GPL is not relevant. That's fine for distribution of A by itself. However, the person who wants to distribute A and B together (even if only as a mere aggregation) still needs the permission of the B's copyright owner and thus, needs to know what conditions the GPL might require. (Look up both sleeves. No contract obligation in sight. Really!) I may not be understanding what you are saying, and we may be talking in circles. Perhaps we should await some opportunity when we can sit back in the comfort of some overstuffed chairs, possibly with a beverage in hand, and have a relaxing interactive discussion. -- Scott I can now see how confusing my use of A+B is. That is based on a hypothetical in a parallel discussion branch - I introduced it in my reply to David Ravicher: - It is apparent that I have been unclear about what I meant, so let me try a hypothetical. Assume some code A and some code B. Assume that B is licensed under the GPL and that one is trying to answer the question, "When I distribute A and B together, must A be distributed under the GPL?" 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 failed to point out in my previous message (and what I'll try to make explicit here) is the following: I believe that one should also consider the question of whether A+B is one program. In that case, A+B is a "work based on the Program" and A+B is a derivative work of the Program, even though A might not be a derivative work of B. I see this as being wholly consistent with sections 0 and 2. What I don't understand is that, if all one needs to do is to answer the question, "Is A a derivative work of B?", then what is the point of the paragraph in section 2 that I quoted in my earlier message (below). - __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: 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 a determination of whether A is a derivative of B." Contracts set their own law, and definitions matter. Theoretically one can write a license that sets reciprocity conditions that apply to works that link to each other in any way at all, or that merely coexist on the same medium. I won't prejudge whether such a license would be compatible with the OSD, but at least it would be legally effective to do so. But when a license purports NOT to be a contract and intends to be interpreted in the same way worldwide under copyright law alone, then I don't understand how you can go beyond what that law provides. Does the "legal rule of construction" that you refer to have any application outside of contract law? For a copyright license that is to be interpreted under copyright law, why would a court construct anything more than what the statutory or case law requires? How can a licensee be bound to interpretive language in a *mere* copyright license? I don't think it is true that "if A+B is one work under copyright law, then it is a derivative work of both A and B." (I'm not quoting you precisely because your email is slightly garbled; have I misquoted you?) What does the "+" mean in your mathematical expression "A+B"? Suppose A is Windows and B is Excel. Are either of those programs derivative works of the other simply because thay are "plussed" together onto the same disk, or even link to each other in the course of their execution on a computer? What SHOULD the courts do with the language you quoted from section 2
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 their own law, and definitions matter. Theoretically one can write a license that sets reciprocity conditions that apply to works that link to each other in any way at all, or that merely coexist on the same medium. I won't prejudge whether such a license would be compatible with the OSD, but at least it would be legally effective to do so. But when a license purports NOT to be a contract and intends to be interpreted in the same way worldwide under copyright law alone, then I don't understand how you can go beyond what that law provides. Does the "legal rule of construction" that you refer to have any application outside of contract law? For a copyright license that is to be interpreted under copyright law, why would a court construct anything more than what the statutory or case law requires? How can a licensee be bound to interpretive language in a *mere* copyright license? I don't think it is true that "if A+B is one work under copyright law, then it is a derivative work of both A and B." (I'm not quoting you precisely because your email is slightly garbled; have I misquoted you?) What does the "+" mean in your mathematical expression "A+B"? Suppose A is Windows and B is Excel. Are either of those programs derivative works of the other simply because thay are "plussed" together onto the same disk, or even link to each other in the course of their execution on a computer? What SHOULD the courts do with the language you quoted from section 2 of the GPL? I'm not really sure. Perhaps a broader interpretation of the term "derivative works" as applied to software will be accepted ultimately by the courts because of a community concensus that such an interpretation is appropriate. But I'd sure like to offer more than precatory language in a copyright license itself to support such an interpretation, such as one or more decisions by one or more federal courts. Nobody, including the most fervent advocates of the GPL, have ever provided such authority. /Larry > -Original Message- > From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 6:52 AM > To: '[EMAIL PROTECTED]' > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > 'Andre Hedrick'; 'Ian Lance Taylor' > 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 of > construction that says that in judging various possible > interpretations, one should weigh more heavily those > interpretations that give meaning to all of the provisions. > > Is this a point on which you think that the authors of the > GPL were wrong in their understanding of copyright law? Or, > what is your understanding of the meaning of the paragraph of > section 2 that I quoted? > > I am not assuming that the GPL does more than leverage the > copyright law. If > A+B is one work under the copyright law, then A+B is a > derivative of B > A+and > requires B's permission for distribution. Thus, it is > unnecessary to find a contractual obligation to restrict the > distribution of A+B. > > -- Scott > __ > Scott K. Peterson > Corporate Counsel > Hewlett-Packard Company > One Cambridge Center > Cambridge, MA 02142 > [EMAIL PROTECTED] > > > -Original Message- > From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 11:13 PM > 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 by its authors to be interpreted and enforced under > copyright law. There is no basis in that law for the > definition of "derivative work" that is implied by the GPL > language you quoted. How can you assume that a licensee > accepted such a broadened definition of "derivative work" > absent his assent to a contract? > > The MPL also attempts to apply to more than derivative works. > While I don't particularly understand its reach, at least it > is to be enforced as a contract and
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 of construction that says that in judging various possible interpretations, one should weigh more heavily those interpretations that give meaning to all of the provisions. Is this a point on which you think that the authors of the GPL were wrong in their understanding of copyright law? Or, what is your understanding of the meaning of the paragraph of section 2 that I quoted? I am not assuming that the GPL does more than leverage the copyright law. If A+B is one work under the copyright law, then A+B is a derivative of B and requires B's permission for distribution. Thus, it is unnecessary to find a contractual obligation to restrict the distribution of A+B. -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 11:13 PM 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 by its authors to be interpreted and enforced under copyright law. There is no basis in that law for the definition of "derivative work" that is implied by the GPL language you quoted. How can you assume that a licensee accepted such a broadened definition of "derivative work" absent his assent to a contract? The MPL also attempts to apply to more than derivative works. While I don't particularly understand its reach, at least it is to be enforced as a contract and thus the definitions in that contract are relevant. That, for me, is the essential difference between a copyright license and a contract. The GPL can't do more than copyright law allows -- because that's how its authors want it to be treated. I don't understand how GPL licensors can benefit from contract provisions. /Larry > -Original Message- > From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 10:30 AM > To: '[EMAIL PROTECTED]'; 'Andre Hedrick'; 'Ian Lance Taylor' > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: "Derivative Work" for Software Defined > > > Larry -- > > I think that you place too much emphasis on the concept of > "derivative work". It seems clear that section 2 of the GPL > is about more than merely derivative works. If all that > matters is whether something is a derivative work, then what > does the following paragraph from section 2 mean: > > "These requirements apply to the modified work as a whole. > If identifiable sections of that work are not derived from > the Program, and can be reasonably considered independent and > separate works in themselves, then this License, and its > terms, do not apply to those sections when you distribute > them as separate works. But when you distribute the same > sections as part of a whole which is a work based on the > Program, the distribution of the whole must be on the terms > of this License, whose permissions for other licensees extend > to the entire whole, and thus to each and every part > regardless of who wrote it." > > -- Scott > __ > Scott K. Peterson > Corporate Counsel > Hewlett-Packard Company > One Cambridge Center > Cambridge, MA 02142 > [EMAIL PROTECTED] > > > -Original Message- > From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 06, 2003 7:36 PM > To: 'Andre 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 as are reflected in these messages? > > 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 independently-written piece of software through > a published API ever become a derivative work of that other > softw
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 by its authors to be interpreted and enforced under copyright law. There is no basis in that law for the definition of "derivative work" that is implied by the GPL language you quoted. How can you assume that a licensee accepted such a broadened definition of "derivative work" absent his assent to a contract? The MPL also attempts to apply to more than derivative works. While I don't particularly understand its reach, at least it is to be enforced as a contract and thus the definitions in that contract are relevant. That, for me, is the essential difference between a copyright license and a contract. The GPL can't do more than copyright law allows -- because that's how its authors want it to be treated. I don't understand how GPL licensors can benefit from contract provisions. /Larry > -Original Message- > From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 10:30 AM > To: '[EMAIL PROTECTED]'; 'Andre Hedrick'; 'Ian Lance Taylor' > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: "Derivative Work" for Software Defined > > > Larry -- > > I think that you place too much emphasis on the concept of > "derivative work". It seems clear that section 2 of the GPL > is about more than merely derivative works. If all that > matters is whether something is a derivative work, then what > does the following paragraph from section 2 mean: > > "These requirements apply to the modified work as a whole. > If identifiable sections of that work are not derived from > the Program, and can be reasonably considered independent and > separate works in themselves, then this License, and its > terms, do not apply to those sections when you distribute > them as separate works. But when you distribute the same > sections as part of a whole which is a work based on the > Program, the distribution of the whole must be on the terms > of this License, whose permissions for other licensees extend > to the entire whole, and thus to each and every part > regardless of who wrote it." > > -- Scott > __ > Scott K. Peterson > Corporate Counsel > Hewlett-Packard Company > One Cambridge Center > Cambridge, MA 02142 > [EMAIL PROTECTED] > > > -----Original Message----- > From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 06, 2003 7:36 PM > To: 'Andre 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 as are reflected in these messages? > > 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 independently-written piece of software through > a published API ever become a derivative work of that other > software? Where in the GPL does it say that it can become a > derivative work? > > Nothing in the Copyright Act addresses the *use* of software > in this way. If the GPL is enforced under the copyright law, > then how could a court ever conclude that it reaches to such > API-connected pre-existing works that merely get used together? > > /Larry Rosen > > > > > 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 provide an execution layer > > between the > > > > GPL and Commerial private code. Where as no GPL code in > > any form is > > > > allowed to touch the Commerial code. The converse is true, > > > > obviously. The execution layer or boundary. Now using this > > > > reference from 1995, many companies have gotten legal positions > > > > about binary modules. > > > > > > > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaav > a.hels > > > inki.fi > > &g
Re: "Derivative Work" for Software Defined
On Monday 13 January 2003 02:20 pm, PETERSON,SCOTT K (HP-USA,ex1) wrote: > the question of whether A+B is one program. In that case, A+B is a "work > based on the Program" and A+B is a derivative work of the Program, even > though A might not be a derivative work of B. I see this as being wholly > consistent with sections 0 and 2. If A+B is a derivative of B, then A+B must follow the rules of the GPL. But this does not mean that A by itself must do so as well. And the GPL certainly allows A to be distributed in aggregate with B and A+B. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
It is apparent that I have been unclear about what I meant, so let me try a hypothetical. Assume some code A and some code B. Assume that B is licensed under the GPL and that one is trying to answer the question, "When I distribute A and B together, must A be distributed under the GPL?" 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 failed to point out in my previous message (and what I'll try to make explicit here) is the following: I believe that one should also consider the question of whether A+B is one program. In that case, A+B is a "work based on the Program" and A+B is a derivative work of the Program, even though A might not be a derivative work of B. I see this as being wholly consistent with sections 0 and 2. What I don't understand is that, if all one needs to do is to answer the question, "Is A a derivative work of B?", then what is the point of the paragraph in section 2 that I quoted in my earlier message (below). -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -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, but Section 0 of the GPL defines "a work based on the Program", as in "when you distribute the same sections as part of a whole which is __a work based on the Program__", as such: "a "work based on the Program" means either the Program or any derivative work under copyright law" So, the GPL does appear to rely on the definition of derivative work under copyright law for drawing the line between those works that are covered and those that are not. Plus, for the GPL to impact the rights of folks with respect to programs that are not derivative works, it must be a contract, something FSF expressly says it is not (see: http://www.nccusl.org/nccusl/meetings/UCITA_Materials/kunze-ucita.pdf). If its not a contract, then copyright law precludes the finding of any infringement by the distribution of an independent (synonymous with not derivative) work. --Dan Daniel Ravicher Patterson Belknap Webb & Tyler LLP 1133 Avenue of the Americas New York, NY 10036 212.336.2826 direct 212.336.7900 fax mailto:[EMAIL PROTECTED] http://www.pbwt.com/ -Original Message- From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 1:30 PM To: '[EMAIL PROTECTED]'; 'Andre Hedrick'; 'Ian Lance Taylor' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: "Derivative Work" for Software Defined Larry -- I think that you place too much emphasis on the concept of "derivative work". It seems clear that section 2 of the GPL is about more than merely derivative works. If all that matters is whether something is a derivative work, then what does the following paragraph from section 2 mean: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -Original Message----- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 7:36 PM To: 'Andre 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 as are reflected in these messages? 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 independently-written piece of software through a published API ever become a derivative work of that other software? Whe
RE: "Derivative Work" for Software Defined
Yes, but Section 0 of the GPL defines "a work based on the Program", as in "when you distribute the same sections as part of a whole which is __a work based on the Program__", as such: "a "work based on the Program" means either the Program or any derivative work under copyright law" So, the GPL does appear to rely on the definition of derivative work under copyright law for drawing the line between those works that are covered and those that are not. Plus, for the GPL to impact the rights of folks with respect to programs that are not derivative works, it must be a contract, something FSF expressly says it is not (see: http://www.nccusl.org/nccusl/meetings/UCITA_Materials/kunze-ucita.pdf). If its not a contract, then copyright law precludes the finding of any infringement by the distribution of an independent (synonymous with not derivative) work. --Dan Daniel Ravicher Patterson Belknap Webb & Tyler LLP 1133 Avenue of the Americas New York, NY 10036 212.336.2826 direct 212.336.7900 fax mailto:[EMAIL PROTECTED] http://www.pbwt.com/ -Original Message- From: PETERSON,SCOTT K (HP-USA,ex1) [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 1:30 PM To: '[EMAIL PROTECTED]'; 'Andre Hedrick'; 'Ian Lance Taylor' Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: "Derivative Work" for Software Defined Larry -- I think that you place too much emphasis on the concept of "derivative work". It seems clear that section 2 of the GPL is about more than merely derivative works. If all that matters is whether something is a derivative work, then what does the following paragraph from section 2 mean: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 7:36 PM To: 'Andre 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 as are reflected in these messages? 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 independently-written piece of software through a published API ever become a derivative work of that other software? Where in the GPL does it say that it can become a derivative work? Nothing in the Copyright Act addresses the *use* of software in this way. If the GPL is enforced under the copyright law, then how could a court ever conclude that it reaches to such API-connected pre-existing works that merely get used together? /Larry Rosen > > > 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 provide an execution layer > between the > > > GPL and Commerial private code. Where as no GPL code in > any form is > > > allowed to touch the Commerial code. The converse is true, > > > obviously. The execution layer or boundary. Now using this > > > reference from 1995, many companies have gotten legal positions > > > about binary modules. > > > > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaav a.hels > > inki.fi > > What Linus says presumably is valid for Linux. RMS agrees with that > in the message you forwarded. It doesn't necessarily apply to any > program other than Linux. Note in particular the last paragraph in > Linus's message. If all one is using are headers or .h files and everything else is from s
RE: "Derivative Work" for Software Defined
Larry -- I think that you place too much emphasis on the concept of "derivative work". It seems clear that section 2 of the GPL is about more than merely derivative works. If all that matters is whether something is a derivative work, then what does the following paragraph from section 2 mean: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." -- Scott __ Scott K. Peterson Corporate Counsel Hewlett-Packard Company One Cambridge Center Cambridge, MA 02142 [EMAIL PROTECTED] -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 7:36 PM To: 'Andre 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 as are reflected in these messages? 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 independently-written piece of software through a published API ever become a derivative work of that other software? Where in the GPL does it say that it can become a derivative work? Nothing in the Copyright Act addresses the *use* of software in this way. If the GPL is enforced under the copyright law, then how could a court ever conclude that it reaches to such API-connected pre-existing works that merely get used together? /Larry Rosen > > > 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 provide an execution layer > between the > > > GPL and Commerial private code. Where as no GPL code in > any form is > > > allowed to touch the Commerial code. The converse is true, > > > obviously. The execution layer or boundary. Now using this > > > reference from 1995, many companies have gotten legal positions > > > about binary modules. > > > > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaav a.hels > > inki.fi > > What Linus says presumably is valid for Linux. RMS agrees with that > in the message you forwarded. It doesn't necessarily apply to any > program other than Linux. Note in particular the last paragraph in > Linus's message. If all one is using are headers or .h files and everything else is from scratch, does using the headers under the statement above comply with the intent? I am not seeking an opinion without paying for it. > > 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? I am a little naive, but always try to do the right thing. Regards, Andre -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
This, IMO, is one of the messiest parts of most
alleged "Open Source" licenses. When one sees a
collection of terms from the several contributors
in a chain, does that mean the user has a licensee-
licensor relationship with each of them ? What
about conflicts between those sets of terms ? Is
sublicensing through the most recent modifier to be
assumed, so that only those terms apply ?
Without any clarification on superiority, integration,
or sublicensing, and no distinct binding effect/action
on any of these unsigned "things" ("copyright notice",
"terms of use", "disclaimers", ... whatever) a lot
of these important issues remain clouded. And, it
only gets worse when expository language on history
and philosophy are included in the "license", often
giving rise to MORE conflict or ambiguity.
Drawing from over a year of research, and over 20 years
in licensing, I have been working on my own agreement
template suite that not only covers the strict legal
grant but also address the ongoing integrity of the
agreement and describes a pattern of operation and
some important information/communication standards
intended to make an Open Source community project a
bit more 'business-like'. I would certainly like to
use this list for a review in a couple of weeks.
Cheers. dj
*
Don B Jarrell [EMAIL PROTECTED]
Digital Thinking Inc.
*
> -Original Message-
> From: Ken 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 for Linux.
> There is no confusion
> > there.
>
> But Linus doesn't own the copyright of all
> of the code in Linux. If this
> is just a personal exemption granted by
> Linus and isn't based on a legal
> definition of "derivative work", it wouldn't
> apply to the whole thing, just
> to the parts that he himself wrote. I don't
> think a kernel containing only
> the parts Linus owns personally would be much use.
>
> --
> license-discuss archive is at
http://crynwr.com/cgi-bin/ezmlm-cgi?3
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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 for Linux. There is no confusion > there. But Linus doesn't own the copyright of all of the code in Linux. If this is just a personal exemption granted by Linus and isn't based on a legal definition of "derivative work", it wouldn't apply to the whole thing, just to the parts that he himself wrote. I don't think a kernel containing only the parts Linus owns personally would be much use. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
Andre Hedrick <[EMAIL PROTECTED]> writes:
> If one was to go through the pain of creating a set of headers from
> scratch that happen to behave just like the one is the kernel snapshot
> they are referrencing, as a manual to the API. This obviously is
> extracting the ideas in :
>
> ./linux-{snapshot_version}/include/{asm,linux,...}
>
> and creating a new original work :
>
> ./new-work-{snapshot_version}/include/{asm,os,...}
>
> These headers are now clean and original works?
I would say that they probably are. Certainly I and others used
simple versions of this technique when reverse engineering existing
object file formats for the GNU binutils. The results can be found in
the various subdirectories of include in a binutils distribution.
> If so, how does calling such functions which now are clean and will allow
> one to load in to a kernel anything you want, behave between licenses?
> Is the kernel/program a GPL object or is it an LGPL object ?
This is one of the many cases which I think remain unclear, as has
already been discussed.
But, again, it's not unclear for Linux. Linus has clearly stated that
loadable binary modules are OK for Linux. There is no confusion
there.
> More and more this looks unfriendly to binary vendor, and the BSD's seem
> the path to take.
Again, it's a concern for another GPL OS which supports loadable
modules, but it's not a concern for Linux.
Ian
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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#include
> > #include #include
> > #include
> >
> > Where does "signal.h" from the compiler obtain its included references?
>
> It's an old twist that has already been addressed. First, the GPL attached to
> the Linux kernel makes an exception for this case. Second, signal.h is a
> standard POSIX header present on all Unix systems.
>
> Is my helloworld.c program derivative of Linux? No, because it's not running
> under Linux...
Well I feel dumb as a brick. So if user-space is clean.
If one was to go through the pain of creating a set of headers from
scratch that happen to behave just like the one is the kernel snapshot
they are referrencing, as a manual to the API. This obviously is
extracting the ideas in :
./linux-{snapshot_version}/include/{asm,linux,...}
and creating a new original work :
./new-work-{snapshot_version}/include/{asm,os,...}
These headers are now clean and original works?
If so, how does calling such functions which now are clean and will allow
one to load in to a kernel anything you want, behave between licenses?
Is the kernel/program a GPL object or is it an LGPL object ?
The latter seems to have some understand as clean.
The former is what? Is this the grey zone or the exact boundary which
makes binary modules a problem? If it is then regardless of the headers,
the vendor is in the wrong. There are a bunch of business which are in
deep trouble. If it is not then where is all the issues coming from?
(other than silly developers like me)
How does an embedded linux development kit vendor bypass the issues?
Do they thumb the nose?
Does calling or loading a GPL and non-GPL togather alter the non-GPL ?
Obvious linking it would.
How does loading v/s linking behave in address space?
People claim loading == linking.
cat /proc/kcore > vmlinuz ; gdb vmlinuz
Now the vendor of the binary module did not create this new object,
the enduser did.
Is the vendor responsible for the enduser's creation of the combined work?
If the vendor prevents the existance of "/proc/kcore" does that thwart the
enduser's ability to create such an object ?
More and more this looks unfriendly to binary vendor, and the BSD's seem
the path to take.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
IANAL, but a Storage Technologist.
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
On Tuesday 07 January 2003 10:15 pm, Andre Hedrick wrote: > New twist: > > user_space.c kernel_space.c > #include#include > #include #include > #include > > Where does "signal.h" from the compiler obtain its included references? It's an old twist that has already been addressed. First, the GPL attached to the Linux kernel makes an exception for this case. Second, signal.h is a standard POSIX header present on all Unix systems. Is my helloworld.c program derivative of Linux? No, because it's not running under Linux... -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
New twist: user_space.c kernel_space.c #include#include #include #include #include Where does "signal.h" from the compiler obtain its included references? #include #include #include Each of thes are successive including works to create a combined work. How can the user space cascading series of inclusions, be different than a kernel space cascading series of inclusions ? If this is the case then every user space program is a derived work forced it become GPL. This logic has to be true. How could the user space "signal.h" not taint user space if it derives it s operational/functional nature from the cascading inclusions? If user space is not tainted, how is kernel space tainted? Is there a magical ether to was away the taint? If there is, then what stops one from washing all the license out of kernel space? If it does not, then it means the cascading inclusions do not taint. This new logic means anthing calling kernel inclusions can not be tainted. So now the GPL taint is gone ?? Wash, rinse, repeat : now with copyright. Does this mean copyright taint is gone ?? Does that make the classic "hello.c" copyright tainted for using the headers? If user space passing of headers which were included from the kernel they were executed against, makes user space clean, why kernel space? This is a very fun puzzle which looks like the case for binary modules and derived works is a pile of dung. Anybody with answers? Andre Hedrick LAD Storage Consulting Group IANAL, but a Storage Technologies. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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, but it is incorrect to make an analogy between the shape of a sculpture and the API of a library. This is because the shape of a sculpture is part of its copyrightable expression. But in the normal case, the API of a library is not part of the expression of the library. Here is a better (but still flawed) non-digital analogy: a text book. This book will have footnotes, bibliographies, and a whole bunch of other references to other text books. But it is not a derivative work. Throwing in just a tiny bit of digital-ness, put the same book online, and make all the footnotes hyperlinks. Is this now a derivative work? I still say no. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
Since I am new, I would normally lurk for a while, but I am familiar with this issue in some historical, practical arguments. By way of introduction, I should clarify that I am neither hands-on programmer (now) nor attorney, but I have done a lot of licensing, development, etc in the past. And, I am now consulting software companies on licensing/SEP, especially on the OS-proprietary boundary. The issue of an API in the context of a derivative work has been argued successfully along the lines of a non-digital analogy. While those often break down, I believe this one may be apt. 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. Applied to the API context, an API which "fits" a GPL-licensed interface is arguable derived from 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" for Software Defined > > > 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 linkage. > > The first is an ordinary application linking > to an ordinary library. In the > absence of non-trivial macros and inlines, > the application is not a > derivative work IMO. > > The second is the case of a kernel module, > plugin, or similar. Regardless of > the existance of an "official" API, > derivation is doubtful if the underlying > kernel, application or library is used in > it's normal and customary manner. > There's a bit more gray here though. > > The third is a module or plugin that > requires a derivation in order to work. > Such a derivation could be a wrapper, > embedded hooks in the application, etc. > The non-GPL module would then be calling a > GPL derivation, pretending it's > really case one or two above. This is not > allowed, IMO, as it is doing an > end-run around the licensing. > > And then you have the whole issue of intent > and the stickiness it brings. I > would be in much firmer ground if I created > a driver for some new hardware > than if I created a module to bypass a major > subsystem. > > > For example, with a very small > modification to gcc (say, ten lines of > > code), I could make it support loadable > compiler passes. I am clearly > > permitted to publish that modification > under the terms of the GPL. > > Following your argument, I could then > distribute binary compiler > > passes for gcc. Those compiler passes > would no more be derivative > > works of gcc than loadable modules are > derivative works of Linux. > > This would be case three above. Not allowed > (or at least in a very dark grey > area). This was the case with NeXT's > Objective C compiler, I believe. In > order to get such a scheme to work, gcc has > to be modified to support it. > > > My point is that if you are correct that > binary loadable modules are > > clearly not derivative works, then it is > clearly OK to produce binary > > only pieces of a wide variety of GPL programs. > > Mere linkage by itself is not demonstrative > of derivation. I think this was an > underlying assumption that Larry was making. > This is in contrast to the > widely held belief among GPL advocates that > dynamic linkage always causes > derivations. > > > For what it's worth, I'm pretty sure the > FSF does not think the line > > is there--I'm pretty sure they think a > binary gcc compiler pass would > > count as a derivative work. > > Their opinion has great bearing on their > behavior with regards to the law, but > little bearing on the law itself. Yes, they > have more lawyers on their side > than there are on mine. But somehow I > suspect those lawyers are slightly > biased ;-) > > In the case of binary compiler passes, they > are probably correct. But in the > case of dynamic linkage itself I believe > they are incorrect. In my > non-Harvard and layman opinion... > > -- > David Johnson > ___ > http://www.usermode.org > pgp public key on website > -- > license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 Content Addressable Memory. Since there is a lock
to extract or install the execution/runtime operations, and this is
physical hardware (simple terms may be firmware). If one installs an
original work, its associated API for the work into this media, and
provides an open source (GPL or whatever) licensed driver to function with
the original work, does this null the "Derivative Work" argument?
If it does ::
How is this different than using the same open source (GPL or whatever)
licensed driver calling, the API of the original work, and linking the two
objects to create a new "combination" binary work?
The effect I am driving towards is the difference between mapping/function
hooking the original work in the CAM, an copying it into executable
memory.
original_work+api | linking | api+GPL_driver_wrapper == binary module
closed open
original_work+api | CAM | api+GPL_driver_wrapper == binary module
hardwareopen
Obvious the both cases the GPL_driver_wrapper is open_sourced, but the sum
of the latter is/appears to be GPL clean.
The former has the GPL_driver_wrapper open_sourced, but the sum results in
a different effect and is labled GPL_Tainted/Grey_zoned.
The operation and functional they are identical.
Politically they are not.
Legally who knows.
I see CAM products as a means to follow the hardware + open_sourced driver
guidelines.
Others will see it as the intent to do bad things to GPL.
How is the determination made the firmware/content in the CAM is different
than the BIOS/FW of any other HBA's (host bus adaptors).
If CAM + driver is legal for GPL, and it must be.
What is different with object + driver ?
Cheers,
Andre Hedrick
LAD Storage Consulting Group
IANAL, but a Storage Technologist.
On 6 Jan 2003, Ian Lance Taylor wrote:
> "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 types of work.
> >
> > But there are other reasons to conclude that there is nothing improper
> > about reading the Linux source code to determine how to make programs
> > work with Linux. At least until the DMCA muddied the waters, the courts
> > held that it was fair use to reverse engineer software to determine how
> > it works ("in order to gain an understanding of the unprotected
> > functional elements of the program"). Sega v. Accolade (9th Cir. 1992)
> > 997 F.2d 1510. Why should looking at *published* source code for that
> > same purpose be any different? There is no copyright infringement if
> > one doesn't copy or create derivative works of the protected expressive
> > elements of a program.
> >
> > So what if the Linux APIs change constantly? That only means that
> > relying on the source code rather than a published API is a risky
> > endeavor.
> >
> > Once again, I will argue, one doesn't create a derivative work merely by
> > figuring out how to make two independently-written programs work
> > together. If you're trying to convince people that creating a loadable
> > module for Linux is creating a derivative work, you should come up with
> > a better justification for that opinion than what's been proffered here
> > so far.
> >
> > That's about as clear an answer as I have, subject to anyone citing a
> > clearer statement on the subject by a federal court.
>
> 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.
>
> For example, with a very small modification to gcc (say, ten lines of
> code), I could make it support loadable compiler passes. I am clearly
> permitted to publish that modification under the terms of the GPL.
> Following your argument, I could then distribute binary compiler
> passes for gcc. Those compiler passes would no more be derivative
> works of gcc than loadable modules are derivative works of Linux.
>
> This could similarly be done for many other GPL programs, such as
> Emacs or the GIMP.
>
> In fact, this has actually been done in the Linux distribution of the
> binutils, to support demangler libraries distributed only in binary
> form. When last I checked, the patches required had not been accepted
> into the main GNU distribution. When I was the binutils maintainer, I
> didn't think it was worth fighting over (the binary demangler library
> was for a proprietary compiler which was disappearing anyhow). But
> it's a real ex
Re: "Derivative Work" for Software Defined
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 linkage. The first is an ordinary application linking to an ordinary library. In the absence of non-trivial macros and inlines, the application is not a derivative work IMO. The second is the case of a kernel module, plugin, or similar. Regardless of the existance of an "official" API, derivation is doubtful if the underlying kernel, application or library is used in it's normal and customary manner. There's a bit more gray here though. The third is a module or plugin that requires a derivation in order to work. Such a derivation could be a wrapper, embedded hooks in the application, etc. The non-GPL module would then be calling a GPL derivation, pretending it's really case one or two above. This is not allowed, IMO, as it is doing an end-run around the licensing. And then you have the whole issue of intent and the stickiness it brings. I would be in much firmer ground if I created a driver for some new hardware than if I created a module to bypass a major subsystem. > For example, with a very small modification to gcc (say, ten lines of > code), I could make it support loadable compiler passes. I am clearly > permitted to publish that modification under the terms of the GPL. > Following your argument, I could then distribute binary compiler > passes for gcc. Those compiler passes would no more be derivative > works of gcc than loadable modules are derivative works of Linux. This would be case three above. Not allowed (or at least in a very dark grey area). This was the case with NeXT's Objective C compiler, I believe. In order to get such a scheme to work, gcc has to be modified to support it. > My point is that if you are correct that binary loadable modules are > clearly not derivative works, then it is clearly OK to produce binary > only pieces of a wide variety of GPL programs. Mere linkage by itself is not demonstrative of derivation. I think this was an underlying assumption that Larry was making. This is in contrast to the widely held belief among GPL advocates that dynamic linkage always causes derivations. > For what it's worth, I'm pretty sure the FSF does not think the line > is there--I'm pretty sure they think a binary gcc compiler pass would > count as a derivative work. Their opinion has great bearing on their behavior with regards to the law, but little bearing on the law itself. Yes, they have more lawyers on their side than there are on mine. But somehow I suspect those lawyers are slightly biased ;-) In the case of binary compiler passes, they are probably correct. But in the case of dynamic linkage itself I believe they are incorrect. In my non-Harvard and layman opinion... -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
"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 types of work.
>
> But there are other reasons to conclude that there is nothing improper
> about reading the Linux source code to determine how to make programs
> work with Linux. At least until the DMCA muddied the waters, the courts
> held that it was fair use to reverse engineer software to determine how
> it works ("in order to gain an understanding of the unprotected
> functional elements of the program"). Sega v. Accolade (9th Cir. 1992)
> 997 F.2d 1510. Why should looking at *published* source code for that
> same purpose be any different? There is no copyright infringement if
> one doesn't copy or create derivative works of the protected expressive
> elements of a program.
>
> So what if the Linux APIs change constantly? That only means that
> relying on the source code rather than a published API is a risky
> endeavor.
>
> Once again, I will argue, one doesn't create a derivative work merely by
> figuring out how to make two independently-written programs work
> together. If you're trying to convince people that creating a loadable
> module for Linux is creating a derivative work, you should come up with
> a better justification for that opinion than what's been proffered here
> so far.
>
> That's about as clear an answer as I have, subject to anyone citing a
> clearer statement on the subject by a federal court.
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.
For example, with a very small modification to gcc (say, ten lines of
code), I could make it support loadable compiler passes. I am clearly
permitted to publish that modification under the terms of the GPL.
Following your argument, I could then distribute binary compiler
passes for gcc. Those compiler passes would no more be derivative
works of gcc than loadable modules are derivative works of Linux.
This could similarly be done for many other GPL programs, such as
Emacs or the GIMP.
In fact, this has actually been done in the Linux distribution of the
binutils, to support demangler libraries distributed only in binary
form. When last I checked, the patches required had not been accepted
into the main GNU distribution. When I was the binutils maintainer, I
didn't think it was worth fighting over (the binary demangler library
was for a proprietary compiler which was disappearing anyhow). But
it's a real example of somebody who actually did what I suggest above.
My point is that if you are correct that binary loadable modules are
clearly not derivative works, then it is clearly OK to produce binary
only pieces of a wide variety of GPL programs.
My feeling is that the issue is muddier than you are suggesting.
Presumably there is a line somewhere between what is and what is not a
derivative work. But I don't see any obvious reason that the line is
at loadable modules.
For what it's worth, I'm pretty sure the FSF does not think the line
is there--I'm pretty sure they think a binary gcc compiler pass would
count as a derivative work.
Obviously, none of this is meant to suggest that binary modules are
not OK for Linux. They are OK, because Linus has made it clear that
they are OK. But it's not clear to me that they would be OK if Linus
had not made that statement.
Ian
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 different from the copyrightable expression. Since a system/function call only accesses the functionality, it should be permitted. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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 conclude that there is nothing improper
about reading the Linux source code to determine how to make programs
work with Linux. At least until the DMCA muddied the waters, the courts
held that it was fair use to reverse engineer software to determine how
it works ("in order to gain an understanding of the unprotected
functional elements of the program"). Sega v. Accolade (9th Cir. 1992)
997 F.2d 1510. Why should looking at *published* source code for that
same purpose be any different? There is no copyright infringement if
one doesn't copy or create derivative works of the protected expressive
elements of a program.
So what if the Linux APIs change constantly? That only means that
relying on the source code rather than a published API is a risky
endeavor.
Once again, I will argue, one doesn't create a derivative work merely by
figuring out how to make two independently-written programs work
together. If you're trying to convince people that creating a loadable
module for Linux is creating a derivative work, you should come up with
a better justification for that opinion than what's been proffered here
so far.
That's about as clear an answer as I have, subject to anyone citing a
clearer statement on the subject by a federal court.
/Larry Rosen
> 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 changes
> regularly as the kernel changes.
>
> It seems to be me that a loadable module is not so very
> different from a straightforward enhancement of the existing
> source. After all, most of the Linux kernel is loadable modules.
>
> I really don't think there is any clear answer to whether a
> loadable module is a derivative work or not.
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 changes regularly as the kernel changes. Loadable kernel modules are in a grey area. The Linux team certainly has the right to say "this API is internal and not for public use". But at the same time they can't say a certain API is public for some people but private for others. Merely marking a symbol "GPL" isn't good enough. If it's in a header file meant for public consumption then it's a published API. It's the "public consumption" part that's the grey area. That could be potentially any header file, since they are all available to the public. It depends upon how they are used. p.s. I'm not arguing that you can make an "end run" around the GPL using kernel modules. That is a different case. -- David Johnson ___ http://www.usermode.org pgp public key on website -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 restrict your customers, by comparison to source > > code products. I'm not questioning your decision to sell binary only > > products; I'm just pointing out that by following a scheme of not > > restricting module distributors, you are choosing to restrict module > > users. It's not a case of ``not restricting people,'' as you put it; > > it's a case of choosing which restrictions to use. > > ``not restricting'' access to my house when the bank issues a forclosure > (sp). I am here to sell to cover my costs, build a small war chest. > Dump the product to opensource at that point and move to the next > generation of new technology. > > Develop, Sell, War Chest, Release :: repeat > > What more could the open source want, other than to confuse "wishes and > horses" ? I repeat, I'm not questioning your decision to sell binary only products. I won't bother repeating my actual point again. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
"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 independently-written piece of software > through a published API ever become a derivative work of that other > software? Where in the GPL does it say that it can become a derivative > work? 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 changes regularly as the kernel changes. It seems to be me that a loadable module is not so very different from a straightforward enhancement of the existing source. After all, most of the Linux kernel is loadable modules. I really don't think there is any clear answer to whether a loadable module is a derivative work or not. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 glues into > > > > an open source gpl program or kernel(ie loadable modules services) designed > > > > to provide an execution layer between the GPL and Commerial private code. > > > > Where as no GPL code in any form is allowed to touch the Commerial code. > > > > The converse is true, obviously. The execution layer or boundary. > > > > Now using this reference from 1995, many companies have gotten legal > > > > positions about binary modules. > > > > > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsinki.fi > > > > > > What Linus says presumably is valid for Linux. RMS agrees with that > > > in the message you forwarded. It doesn't necessarily apply to any > > > program other than Linux. Note in particular the last paragraph in > > > Linus's message. > > > > If all one is using are headers or .h files and everything else is from > > scratch, does using the headers under the statement above comply with the > > intent? > > > > I am not seeking an opinion without paying for it. > > I guess I'm not sure which you mean when you say ``the statement > above.'' The statement by Linus or the statement by RMS? I expect > that the answer is different. > > I think it's clear that you can sell binary loadable modules for > Linux--or, at any rate, as clear as it can be in the absence of actual > law or precedent. Given Linus's public statements, I personally would > have no legal concerns about a business plan based on selling binary > modules for Linux. > > If you're talking about something other than Linux, it might help if > you said what you are talking about. > > I am not a lawyer. My experience is that different lawyers will give > you different advice in this area. The IANAL leaves a concern. > > > > > 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 restrict your customers, by comparison to source > code products. I'm not questioning your decision to sell binary only > products; I'm just pointing out that by following a scheme of not > restricting module distributors, you are choosing to restrict module > users. It's not a case of ``not restricting people,'' as you put it; > it's a case of choosing which restrictions to use. ``not restricting'' access to my house when the bank issues a forclosure (sp). I am here to sell to cover my costs, build a small war chest. Dump the product to opensource at that point and move to the next generation of new technology. Develop, Sell, War Chest, Release :: repeat What more could the open source want, other than to confuse "wishes and horses" ? --Andre -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
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 as are reflected in these messages? 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 independently-written piece of software through a published API ever become a derivative work of that other software? Where in the GPL does it say that it can become a derivative work? Nothing in the Copyright Act addresses the *use* of software in this way. If the GPL is enforced under the copyright law, then how could a court ever conclude that it reaches to such API-connected pre-existing works that merely get used together? /Larry Rosen > > > 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 provide an execution layer > between the > > > GPL and Commerial private code. Where as no GPL code in > any form is > > > allowed to touch the Commerial code. The converse is true, > > > obviously. The execution layer or boundary. Now using this > > > reference from 1995, many companies have gotten legal positions > > > about binary modules. > > > > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaav a.hels > > inki.fi > > What Linus says presumably is valid for Linux. RMS agrees with that > in the message you forwarded. It doesn't necessarily apply to any > program other than Linux. Note in particular the last paragraph in > Linus's message. If all one is using are headers or .h files and everything else is from scratch, does using the headers under the statement above comply with the intent? I am not seeking an opinion without paying for it. > > 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? I am a little naive, but always try to do the right thing. Regards, Andre -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 glues into > > > an open source gpl program or kernel(ie loadable modules services) designed > > > to provide an execution layer between the GPL and Commerial private code. > > > Where as no GPL code in any form is allowed to touch the Commerial code. > > > The converse is true, obviously. The execution layer or boundary. > > > Now using this reference from 1995, many companies have gotten legal > > > positions about binary modules. > > > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsinki.fi > > > > What Linus says presumably is valid for Linux. RMS agrees with that > > in the message you forwarded. It doesn't necessarily apply to any > > program other than Linux. Note in particular the last paragraph in > > Linus's message. > > If all one is using are headers or .h files and everything else is from > scratch, does using the headers under the statement above comply with the > intent? > > I am not seeking an opinion without paying for it. I guess I'm not sure which you mean when you say ``the statement above.'' The statement by Linus or the statement by RMS? I expect that the answer is different. I think it's clear that you can sell binary loadable modules for Linux--or, at any rate, as clear as it can be in the absence of actual law or precedent. Given Linus's public statements, I personally would have no legal concerns about a business plan based on selling binary modules for Linux. If you're talking about something other than Linux, it might help if you said what you are talking about. I am not a lawyer. My experience is that different lawyers will give you different advice in this area. > > > 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 restrict your customers, by comparison to source code products. I'm not questioning your decision to sell binary only products; I'm just pointing out that by following a scheme of not restricting module distributors, you are choosing to restrict module users. It's not a case of ``not restricting people,'' as you put it; it's a case of choosing which restrictions to use. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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? :-( :-) 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 kisses (fat arse, small brain) waiting for welware source code. Well, was planning to opensource it after recovering development costs. Also to destroy the competition's ability to use vendor unique operations to better enable the community. --Andre -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
--- Andre Hedrick <[EMAIL PROTECTED]> wrote: > On 6 Jan 2003, Ian Lance Taylor wrote: > > > 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? > > I am a little naive, but always try to do the right > thing. > > Andre You sell proprietary, or non-Free, software. How dare you say you are doing the right thing? :-( :-) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 source gpl program or kernel(ie loadable modules services) designed > > to provide an execution layer between the GPL and Commerial private code. > > Where as no GPL code in any form is allowed to touch the Commerial code. > > The converse is true, obviously. The execution layer or boundary. > > Now using this reference from 1995, many companies have gotten legal > > positions about binary modules. > > > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsinki.fi > > What Linus says presumably is valid for Linux. RMS agrees with that > in the message you forwarded. It doesn't necessarily apply to any > program other than Linux. Note in particular the last paragraph in > Linus's message. If all one is using are headers or .h files and everything else is from scratch, does using the headers under the statement above comply with the intent? I am not seeking an opinion without paying for it. > > 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? I am a little naive, but always try to do the right thing. Regards, Andre -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
[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 source gpl program or kernel(ie loadable modules services) designed > to provide an execution layer between the GPL and Commerial private code. > Where as no GPL code in any form is allowed to touch the Commerial code. > The converse is true, obviously. The execution layer or boundary. > Now using this reference from 1995, many companies have gotten legal > positions about binary modules. > > http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsinki.fi What Linus says presumably is valid for Linux. RMS agrees with that in the message you forwarded. It doesn't necessarily apply to any program other than Linux. Note in particular the last paragraph in Linus's message. > Now what is position can be derived legally in a position or brief to > prevent binary modules period. I am against denying anyone the freedom > of choice to use closed source objects or only open source ones. This sort of question depends upon the legal definition of ``derived work.'' Unfortunately, that term is not defined by the law or the courts for this sort of thing. Personally I suspect that weight would be given to explicit statements like those of Linus and RMS--i.e., Linux permits binary modules, other GPL programs do not (unless the author gives explicit permission). > 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. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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 provide an execution layer between the GPL and Commerial private code. Where as no GPL code in any form is allowed to touch the Commerial code. The converse is true, obviously. The execution layer or boundary. Now using this reference from 1995, many companies have gotten legal positions about binary modules. http://groups.google.com/groups?as_umsgid=4b0rbb%245iu%40klaava.helsinki.fi Now there is: -- Forwarded message -- Date: Sat, 04 Jan 2003 18:44:49 -0500 From: Richard Stallman <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Gauntlet Set NOW! Linus has the right to permit this, with his code, and so do other contributors to Linux. In the GNU Project we usually don't permit this, and the FSF believes the GPL does not in general permit it, but occasionally we make an exception when it seems best to do so. I have no opinion yet about what Andre said, because I cannot form a clear picture of what he plans to do; I don't know whether it would violate the GPL, or whether the issue would involve the FSF. We do not enforce the GPL for Linux in any case; that is the responsibility of the copyright holders of Linux. -- Forwarded message -- A public point about who enforces the rules. Now what is position can be derived legally in a position or brief to prevent binary modules period. I am against denying anyone the freedom of choice to use closed source objects or only open source ones. I ship and sell binary only products, so I have an interest in not restricting people. Regards, Andre Hedrick -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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) test be
viewed as the appropo test was an intriguing suggestion.
I then raised two primary concerns: [1] that what "modifications" constitute
derivative works is the open source problem that licensors seem to struggle
with and the AFC test is neither intended, nor useful for such matters and
[2] at bottom, the AFC test is used by courts to determine what aspects, if
any, of the allegedly infringing work constitute a copyrightable work that
may have infringed the plaintiff's work. Although the circuits do not agree
on how to apply this test, I doubt that one can find more than an isolated
court opinion that has adopted the AFC test as a tool to determine the
constituent elements of a derivative work.
I agree that one principle underlying the AFC test - - that you "filter" out
the non-literal (or, literal) element that is uncopyrightable - - is a
helpful guideline in circumstances when a licensor is overreaching by
claiming a licensee created a derivative work by copying/modifying/using a
non-literal element from the original work. In such simple cases, a
derivative work will not exist. I don't see examples of this type being
typical open source issues, however.
[snip]
Sorry, Rod, but I'm going to have to disagree with you on this point. See
Tradescape v. Shivram, 77 F.Supp.2d 408 (SDNY 1999). Comparing two works as
whole against one another to see how "significant" the diffs are between
them is absolutely not the test for derivative work in any Circuit.
Although such an initial "first look" is sometimes performed, it is not
determinative as it would too often lead a court to protect uncopyrightable
portions of the original work.
I think what you are addressing is whether the second author has significant
originality to be deserving of her own copyright in the derivative work.
See Torah Soft v. Drosnin, 136 F.Supp.2d 276 (SDNY 2001) ("All that is
needed for a finding of sufficient originality is a distinguishable
variation that is not merely trivial"). But, simply finding sufficient
originality such that a second work deserves its own copyright doesn't
impact the analysis of whether that second work is a derivative of the
original.
[snip]
I am not sure that the point in your last paragraph about originality not
impacting that analysis of a derivative work is correct or, at least, not
without notable exception (e.g. whether a derivative work is created by the
computer colorization of film seems inextricably tied to the originality
question).
Rod
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
Thanks for your comments, David.
I attempted in my article to present the law and apologize that it didn't
fulfill your purposes. One resolution of your issues is to either bring a
Declaratory Judgment Action seeking to have a court answer your questions or
you could seek an opinion of counsel regarding whether one work, such as
your five line macro, template, linkage and inheritance examples, is a
derivative of an original. BTW, I concede that such analysis may not be as
simple as we'd all liked it to be, but this is in part because a court will
not heed to a technician forcing it to talk techy speak. Rather, to be
legally sound, one must speak legalease.
On that note, whether the AFC test would apply easily to certain factual
examples or not would be highly irrelevant to the court's stare decisis
obligation. Courts loathe to throw out established doctrine simply because
one says it doesn't fit the facts very well. One can try to fashion their
own test, that they think better works with specific facts, but good luck
getting a court to adopt it.
Lastly, upon reflection, I'm not so sure the AFC test wouldn't work just
fine with all of your hypotheticals. The linking issue, despite the
incorrect statements of some technicians in the community that it turns on
static vs. dynamic, is rather straight forward. The five line macro seems
similarly resolvable, and the templates and inheritance issues aren't nearly
as complicated as many fact patterns presented 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\) 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.
> Therefore, one
> is left to ask, just what is a "derivative work?" This article
> (http://www.pbwt.com/Attorney/files/ravicher_1.pdf) addresses that
> question. Your comments and thoughts would be most appreciated.
Some good information, but it doesn't really address the important questions
that may be facing open source developers:
1) If I include a five line macro in my software, will it be a derivative
work? (ditto for inline and regular functions) Is there a difference if this
macro is copied via cut-and-paste versus a reference to a header file?
2) What about templates and template instantiation by the compiler? This is
an
important issue in C++. There are some major works that are nothing but
templates (stl, libsig++).
3) What about dynamic and runtime linkage? Is the mere availability of
functionality at runtime sufficient to determine derivation? Are all GUI
Windows programs derivatives of Microsoft's win32.dll?
3a) Related: does it make a difference if the library in question exports a
standard or otherwise common API?
4) Does OO inheritance (ei class derivation) constitute derivation in terms
of
copyright?
The AFC test might help a tiny bit for 1 and 2, but not for 3 or 4.
--
David Johnson
___
http://www.usermode.org
pgp public key on website
--
Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this message (or responsible for delivery
of the message to such person), you may not copy or deliver this message to
anyone. In such case, you should destroy this message and kindly notify the
sender by reply email. Please advise immediately if you or your employer
do not consent to Internet email for messages of this kind.
==
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: "Derivative Work" for Software Defined
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, in some cases, distributing
an exact copy of the original work would not implicate the copyright laws if
that original work has no copyrightable interests. As such, no compliance
with the license is necessary for such re-distribution of such an original
work either.
I see your point, though, that distribution of an unmodified original work
may be seen by some as a different analysis from distribution of a
derivative work. However, knowing that a court will first strip down an
original work to its copyright protectable elements leads one to see that
what one is actually distributing as "an exact copy of the [supposed]
original work," is in fact a derivative work of the protectable portions of
the original work. So, in effect, the court will not compare what is
re-distributed with the whole of what is the original licensed work, unless
every portion of that original licensed work is copyright protectable, which
may or may not be likely.
> In your second paragraph, you indicate that the
> abstraction-filtration-comparison test established by the Second Circuit
is
> aimed at determining what constitutes a derivative work. Are you confident
> of this claim? There may be a principled basis for your position, but
> laying out the test does not quite sufficiently make that point.
I'm absolutely confident that the AFC test, in certain Circuits, is the test
for determining whether a second computer software work is indeed a
derivative work of (aka is "substantially similar to"; aka "is not an
independent or separate work from") an original computer software work. In
other Circuits, a different, at least in name, standard exists. This is not
based on principles, but the case law that I cited and if you KeyCite or
Sheppardize those cases, you'll find many more cases to support the
conclusion.
> I doubt that there would be the over-reaching by an open source
> copyright holder that is generally required to reach this phase of dispute
> since the purpose of these tests, ostensibly, is to allow the alleged
> infringer to go about his or her way if all that the court has before it,
> after application of the pertinent test, is uncopyrightable expression; it
> would be odd to see an open source developer attempt to make claim to
that.
I guess we'll have to agree to disagree here. My open source clients care
very much about defending their and the community's rights, to the fullest
extent that they exist, and routinely expect third-party infringers (esp
non-open source companies) to respect and conform to their rights. They
don't see this as "over-reaching", but rather protecting erosion of the
community's hard work and effort. If MS was to incorporate some copyright
protectable elements of open source code, I don't think it unwise for the
open source community to be vigilant about using the law that is good for
the goose and applying it to the gander.
Yes, of course there are disagreements about whether the current state of
copyright law vis-à-vis software is wise. But, beyond those policy based
arguments that typically distract and detract from the community's more
important efforts, as a simple objective based decision, playing by the
rules to win, albeit perhaps being bad rules, is typically what those who
have invested significant resources will decide to do.
> Admittedly, it may be intriguing to determine whether these
idea/expression
> tests are suitable for derivative software work analysis, but courts seem
to
> be following a different track. At issue for courts, it seems to me, is a
> fuss over degrees of "modification;" namely, whether a modification is too
> trivial/simplistic or "too" transformative to be deemed derivative
(imagine
> a scale with the balance being the derivative measurement).
Sorry, Rod, but I'm going to have to disagree with you on this point. See
Tradescape v. Shivram, 77 F.Supp.2d 408 (SDNY 1999). Comparing two works as
whole against one another to see how "significant" the diffs are between
them is absolutely not the test for derivative work in any Circuit.
Although such an initial "first look" is sometimes performed, it is not
determinative as it would too often lead a court to protect uncopyrightable
portions of the original work.
I think what you are addressing is whether the second author has significant
originality to be deserving of her own copyright in the derivative work.
See Torah Soft v. Drosnin, 136 F.Supp.2d 276 (SDNY 2001) ("All that is
needed for a finding of sufficient originality is a distinguishable
variation that is not merely trivial"). But, simply finding sufficient
originality such that a second work deserves its own copyright doesn't
impact the
Re: "Derivative Work" for Software Defined
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.
> Therefore, one
> is left to ask, just what is a "derivative work?" This article
> (http://www.pbwt.com/Attorney/files/ravicher_1.pdf) addresses that
> question. Your comments and thoughts would be most appreciated.
Some good information, but it doesn't really address the important questions
that may be facing open source developers:
1) If I include a five line macro in my software, will it be a derivative
work? (ditto for inline and regular functions) Is there a difference if this
macro is copied via cut-and-paste versus a reference to a header file?
2) What about templates and template instantiation by the compiler? This is an
important issue in C++. There are some major works that are nothing but
templates (stl, libsig++).
3) What about dynamic and runtime linkage? Is the mere availability of
functionality at runtime sufficient to determine derivation? Are all GUI
Windows programs derivatives of Microsoft's win32.dll?
3a) Related: does it make a difference if the library in question exports a
standard or otherwise common API?
4) Does OO inheritance (ei class derivation) constitute derivation in terms of
copyright?
The AFC test might help a tiny bit for 1 and 2, but not for 3 or 4.
--
David Johnson
___
http://www.usermode.org
pgp public key on website
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: "Derivative Work" for Software Defined
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 paragraph, you indicate that the
abstraction-filtration-comparison test established by the Second Circuit is
aimed at determining what constitutes a derivative work. Are you confident
of this claim? There may be a principled basis for your position, but
laying out the test does not quite sufficiently make that point.
The test is primarily targeted for a different purpose- - at least in the
software context (all of these tests with various names, AFC,
idea/expression dichotomy and so on seem to aid the court in separating
ideas from expression to determine what's left of the alleged infringing
work once the tests are applied...on the track toward resolving an
infringement claim). Even assuming a court has the wherewithal to abstract
and filter out ideas from expression in the literal and non-literal aspects
of a computer program, I am not sure that process would be relevant to open
source. I doubt that there would be the over-reaching by an open source
copyright holder that is generally required to reach this phase of dispute
since the purpose of these tests, ostensibly, is to allow the alleged
infringer to go about his or her way if all that the court has before it,
after application of the pertinent test, is uncopyrightable expression; it
would be odd to see an open source developer attempt to make claim to that.
Admittedly, it may be intriguing to determine whether these idea/expression
tests are suitable for derivative software work analysis, but courts seem to
be following a different track. At issue for courts, it seems to me, is a
fuss over degrees of "modification;" namely, whether a modification is too
trivial/simplistic or "too" transformative to be deemed derivative (imagine
a scale with the balance being the derivative measurement). The MODEL CODE
for the OSD will attempt to set out this distinction, we hope.
rod
Rod Dixon
Visiting Assistant Professor of Law
Rutgers University Law School - Camden
[EMAIL PROTECTED]
http://www.cyberspaces.org/dixon/
My papers on the Social Science Research Network (SSRN) are available
through the following url: http://papers.ssrn.com/author=240132
- Original Message -
From: "Ravicher, Daniel (x2826)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 12, 2002 10:36 AM
Subject: "Derivative Work" for Software Defined
> 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.
Therefore,
> one
> is left to ask, just what is a "derivative work?" This article
> (http://www.pbwt.com/Attorney/files/ravicher_1.pdf) addresses that
question.
> Your comments and thoughts would be most appreciated.
>
> Best,
> --Dan
>
> Daniel Ravicher
> Patterson Belknap Webb & Tyler LLP
> 1133 Avenue of the Americas
> New York, NY 10036
> 212.336.2826 direct
> 212.336.7900 fax
> mailto:dravicher@;pbwt.com
> http://www.pbwt.com/
>
> --
> Privileged/Confidential Information may be contained in this message. If
you
> are not the addressee indicated in this message (or responsible for
delivery
> of the message to such person), you may not copy or deliver this message
to
> anyone. In such case, you should destroy this message and kindly notify
the
> sender by reply email. Please advise immediately if you or your employer
> do not consent to Internet email for messages of this kind.
>
>
==
>
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
