Re: Qt/Embedded
on Mon, Nov 13, 2000 at 11:45:11PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Monday 13 November 2000 10:58 pm, [EMAIL PROTECTED] wrote: > > As I understand, the "Independent and separate" language refers to > > programs which don't cross the link-layer boundary. Though this is a > > bit fuzzy in definition. Whether you can get away with shipping, say, > > binaries and object files, I'm not sure. As seperate entities, shipped > > separately, possibly. Together, probably not. > > Is this "link-layer" boundary defined in copyright law? It certainly > isn't in the GPL. RMS seems to draw his line there, but does he have > any concrete reasons for drawing it there? (I'm sure he does, I just > don't know what they are). I'm told by a friend in the legal profession that there is some argument over this issue among lawyers. I've been trying to frame the argument, not argue the conclusion, for why pgm + linked libs would be considered derivative works of both program and libraries. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
From: David Johnson <[EMAIL PROTECTED]> Date: Sat, 18 Nov 2000 10:49:11 -0800 On Saturday 18 November 2000 04:32 am, [EMAIL PROTECTED] wrote: > You're aquainted with how a linker works? It's the linking of object > code plus libraries which creates the machine-code executable. For a > dynamically linked program, this step occurs at runtime. The runtime > executable *does* contain, in machine code form (see above WRT > derivative works), the referenced portions of the library. For a few linkers, maybe. For others no. Though I admit ignorance to the inner workings of linux-ld, it's my understanding that the application code in memory only references the library code. The program's space in memory does not contain the library, only addresses to the library functions. The linker resolves the symbolic names to actual addresses at runtime. I believe the situation is the same for all unices, along with DOS/Windows. You are describing shared libraries, which on Windows are known as DLLs. Not all versions of Unix/Linux support shared libraries (I believe they were first implemented in SVR3). Not all libraries are implemented as shared libraries. DOS does not support shared libraries. Very few embedded systems support shared libraries. For clarity, the alternative to shared libraries, in which the library code really is included in the program, can be referred to as archive libraries. On most Unix systems, libraries whose names end in ".a" are archive libraries, while libraries whose names end in ".so", or ".so.VERSION", are shared libraries. Ian
Re: Qt/Embedded
G'day all. On Saturday 18 November 2000 04:32 am, [EMAIL PROTECTED] wrote: > > You're aquainted with how a linker works? [...] On Sat, Nov 18, 2000 at 10:49:11AM -0800, David Johnson wrote: > For a few linkers, maybe. For others no. [...] If I may ask a meta-question here... This question has come up before when talking about referencing libraries from source code. Some languages do not textually include any source code from the library when linking it in, using some kind of automatically generated "interface file" instead. Some (e.g. C, assuming the programmer plays by a standard coding convention) textually include only that information which is necessary to access resources in the library. Some (e.g. C++) may textually include actual code. Would a real court actually rule on this? It seems so... uhm... outside the scope, if you know what I mean. It could mean that a given generic licence (e.g. GPL) could be enforcable on one platform but not on another, or in one language but not in another, depending on how the platform or language developer chose to implement some standard feature, and while I don't claim to know the minds of US judges, this does seem to be an area that they'd rather not get into. I would think they'd rather rule on the principle of linking, or the principle of library use, as opposed to ruling on specific techniques to implement those features. Or is this just wishful thinking? :-) Cheers, Andrew Bromage
Re: Qt/Embedded
David Johnson wrote: > >On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote: > > > The idea is that, if a program is a work, and if (as the courts have > > held, in Mai v. Peak) a program in memory meets the fixed and tangible > > requirements of copyright law, and is therefore a copy under copyright > > law, then a program linked to a library at runtime is a derivative work. > >I've heard this before, but I've always dismissed it as hearsay. I will >have >to look up Mai v Peak. The implications of this are mind-boggling! Does >Stephen King have rights to my brain because I've read his books and >they're >now in my memory? Yes. :-) And if your brain, influenced by Mr. King puts out a work that looks like something he wrote, he can sue you for it! Cheers, Ben PS IANAL and I partly wrote that just to tease you. :-) _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: Qt/Embedded
On Saturday 18 November 2000 04:32 am, [EMAIL PROTECTED] wrote: > You're aquainted with how a linker works? It's the linking of object > code plus libraries which creates the machine-code executable. For a > dynamically linked program, this step occurs at runtime. The runtime > executable *does* contain, in machine code form (see above WRT > derivative works), the referenced portions of the library. For a few linkers, maybe. For others no. Though I admit ignorance to the inner workings of linux-ld, it's my understanding that the application code in memory only references the library code. The program's space in memory does not contain the library, only addresses to the library functions. The linker resolves the symbolic names to actual addresses at runtime. I believe the situation is the same for all unices, along with DOS/Windows. -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Sat, Nov 18, 2000 at 06:46:01AM -0500, Eric Jacobs ([EMAIL PROTECTED]) wrote: > > On Sat, 18 Nov 2000, [EMAIL PROTECTED] wrote: > > > > > I don't see how this follows. > > > > You don't see how what follows? That linking is a corrolate of Mai v. > > Peak, or the principles established in Mai v. Peak? > > That linking has anything to do with Mai v. Peak. You and David are chasing the same rabbit. You're running in the right direction... See my response to David. While I'm not entirely clear on the logic, my understanding is that, if the code plus linked libraries in memory is a derivative work (we'll take this as given for the moment, and fight about it later if we need to), then a special circumstance arises when a system is shipped with disaggregated code plus libraries, with the intent that, at runtime, the user create the combined derivative work by running the program. The user's act would appear to be allowable under 117. The argument I think I've seen used is that the party shipping the combination of code is necessitating an infringement of the terms of the GPL. As this isn't the party running the code, or the owner of the copy, they wouldn't be afforded the same 117 exemption. Maybe. This has been hashed out in gnu.misc.discuss many times, I may try digging through archives. A search earlier tonight through Google on "GPL link layer boundary copyright" turned up results but nothing meaningful. <...> > > > Whether "a program linked to a library at runtime is a derivative > > > work" is a different question. > > > > The answer is unambiguous: it's a derivative work. Whether or not it > > is a *protected* work is another question. > > Given the vagueness of the statutory definition of "derivative work" in > 17 USC 101, I can hardly agree that the answer is unambiguous. I disagree: A ``derivative work'' is a work based upon one or more preexisting works, such as [list ommitted] or any other form in which a work may be recast, transformed, or adapted. (17 USC 101) > The GPL states: "... a 'work based on the Program' means either the > Program or any derivative work under copyright law; that is to say, a > work containing the Program or a portion of it, either verbatim or > with modifications and/or translated into another language." (Section > 0, GNU GPL v 2). A program linked to a library at runtime would not be > a derivative work (because it does not contain the library or a > portion of it.) You're aquainted with how a linker works? It's the linking of object code plus libraries which creates the machine-code executable. For a dynamically linked program, this step occurs at runtime. The runtime executable *does* contain, in machine code form (see above WRT derivative works), the referenced portions of the library. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
On Sat, 18 Nov 2000, [EMAIL PROTECTED] wrote:
>
> > I don't see how this follows.
>
> You don't see how what follows? That linking is a corrolate of Mai v.
> Peak, or the principles established in Mai v. Peak?
That linking has anything to do with Mai v. Peak.
:
> > Mai v Peak establishes that because a computer program has to be
> > copied to memory to be used, one can be guilty of copyright
> > infringement merely by using the work.
>
> If one is not the "the owner of a copy" of a program.
>
> If you are the owner of a copy, your rights to produce this in-memory
> copy are addressed by 17 USC 117. If not, my understanding is that the
> rights must be granted under the licensing provisions of the software,
> or made available through one of the limitations on exclusive rights.
And if such in-memory copying is an "essential step in the utilization
of the computer software in conjuction with a machine."
> > The court did not seem to cover Section 117 of Title 17 very
> > thoroughly and it seems to me that similar cases could argue under
> > 117(a)(1) especially.
>
> Opinions vary. I'd say the court considered 117, though. Specifically:
>
> The law also supports the conclusion that Peak's loading of
> copyrighted software into RAM creates a "copy" of that software in
> violation of the Copyright Act. In Apple Computer, Inc. v. Formula
> Int'l, Inc., 594 F.Supp. 617, 621 (C.D.Cal. 1984), the district
> court held that the copying of copyrighted software onto silicon
> chips and subsequent sale of those chips is not protected by 117 of
> the Copyright Act. Section 117 allows "the `owner' 5 of a copy of a
> computer program to make or authorize the making of another copy"
> without infringing copyright law, if it "is an essential step in the
> utilization of the computer program" or if the new copy is "for
> archival purposes only." 17 U.S.C. 117 (Supp. 1988). 6 One of the
> grounds for finding that 117 did not apply was the court's
> conclusion that the permanent copying of the software onto the
> silicon chips was not an "essential step" in the utilization of the
> software because the software could be used through RAM without
> making a permanent copy.
This has to do with making a permanent copy, which is probably not
what dynamic linking will be doing.
> <...>
>
> We have found no case which specifically holds that the copying of
> software into RAM creates a "copy" under the Copyright Act. However,
> it is generally accepted that the loading of software into a
> computer constitutes the creation of a copy under the Copyright Act.
> See e.g. Vault Corp. v. Quaid Software Ltd., 847 F.2d 255, 260 (5th
> Cir. 1988) ("the act of loading a program from a medium of storage
> into a computer's memory creates a copy of the program"); 2 Nimmer
> on Copyright, 8.08 at 8-105 (1983) ("Inputting a computer program
> entails the preparation of a copy."); Final Report of the National
> Commission on the New Technological Uses of Copyrighted Works, at 13
> (1978) ("the placement of a work into a computer is the preparation
> of a copy"). We recognize that these authorities are somewhat
> troubling since they do not specify that a copy is created
> regardless of whether the software is loaded into the RAM, the hard
> disk or the read only memory ("ROM"). However, since we find that
> the copy created in the RAM can be "perceived, reproduced, or
> otherwise communicated," we hold that the loading of software into
> the RAM creates a copy under the Copyright Act. 17 U.S.C. 101. We
> affirm the district court's grant of summary judgment as well as the
> permanent injunction as it relates to this issue.
This establishes that copies in RAM are indeed protected by
copyright law, but doesn't address 17 USC 117.
>
> http://laws.lp.findlaw.com/9th/2/991/511.html
>
> > Even under the conclusion of Mai v Peak, the effect on the GPL would
> > be to require users to proliferate "written offers" (or copies of the
> > source code) and "prominent notices" of modifications (if the program
> > is modified) throughout their computer's RAM and other temporary
> > storage locations as they are operating a GPL'd program.
>
> No. GPL specifically provides this right, or rather, doesn't deny any
> rights necessary to run a program:
>
> Activities other than copying, distribution and modification are not
> covered by this License; they are outside its scope. The act of
> running the Program is not restricted, and the output from the
> Program is covered only if its contents constitute a work based on
> the Program (independent of having been made by running the
> Program).
>
> (GNU GPL v 2, June, 1991)
Correct. But under Mai v Peak, copying a program into RAM to run it
(not the running itself) is copying that would have to be licens
Re: Qt/Embedded
on Fri, Nov 17, 2000 at 10:44:39PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Friday 17 November 2000 09:41 pm, [EMAIL PROTECTED] wrote: > > > > The legal test of copyrightability (what is copyrightable) is > > > "original works of authorship, fixed in a tangible medium" [1]. > > > Or at least the second part of that. > > > > > This seems to be a different issue. Those are good attributes for > > > what can be copyrighted. But it doesn't follow that they are > > > necessarily the same attributes for what can be regulated by the > > > copyright holder. One specific example is a movie. The author can > > > restrict how a movie is shown, even if it is displayed fleetingly > > > on a movie screen, failing the "fixed" attribute. > > > > Film and video qualify. Performance is an exlusive right. > > Okay, what am I missing here. Something is not following... > > First you say that the copyright holder can restrict software in RAM > because it is "fixed in a tangible medium". But you referenced a > phrase that seems to apply to "copyrightability". So I questioned this > by giving the example of film and video "display", which in not fixed > in a tangible medium (the celluloid is, the transient images of light > are not). Copyright in film is conveyed by fixation in celluloid, video, digital, or other form. The film is protected by copyright. One of the exclusive rights under US law is that of public performance. Read the law, I'm not going to explain it to you paragraph by paragraph. > Then you switch over to performance! No, you switched to movies. I responded, briefly, identifying the missing links of your argument. > Perhaps I don't understand the word "copyrightability". I assumes it > to mean "a work that can be copyrighted." See the reference two posts prior to the US Library of Congress Circular on copyright, including a discussion of what is copyrightable. > So, apropos to the original question: does the GPL restrict dynamic > linkage because it makes a derivitive work in the user's RAM? (the > electrical states in a RAM chip being classified as "fixed in a > tangible medium") Or does it restrict dynamic linkage because it is a > performance? Or does it restrict it because the user has entered into > an agreement with the author (which would be binding regardless of > copyright law)? Derivative work in RAM, with, as I understand, an argument of "contributory infringement" being made for works which are distributed as object plus libraries. I'd be more comfortable hearing from the lawyers here (Larry, you awake?). -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
on Fri, Nov 17, 2000 at 10:53:23PM -0500, Eric Jacobs ([EMAIL PROTECTED]) wrote:
>
> On Fri, 17 Nov 2000, David Johnson wrote:
> >
> > On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote:
> >
> > > The idea is that, if a program is a work, and if (as the courts
> > > have held, in Mai v. Peak) a program in memory meets the fixed and
> > > tangible requirements of copyright law, and is therefore a copy
> > > under copyright law, then a program linked to a library at runtime
> > > is a derivative work.
>
> I don't see how this follows.
You don't see how what follows? That linking is a corrolate of Mai v.
Peak, or the principles established in Mai v. Peak?
> > I've heard this before, but I've always dismissed it as hearsay. I
> > will have to look up Mai v Peak. The implications of this are
> > mind-boggling! Does Stephen King have rights to my brain because
> > I've read his books and they're now in my memory?
>
> If that is what the license requires, then yes.
Barring substantive legal foundations for that conclusion, I'm afraid I
remain unconvinced. However, a claim to programs in computer memory is
pretty much what Mai validates, for licensed software.
> Mai v Peak establishes that because a computer program has to be
> copied to memory to be used, one can be guilty of copyright
> infringement merely by using the work.
If one is not the "the owner of a copy" of a program.
If you are the owner of a copy, your rights to produce this in-memory
copy are addressed by 17 USC 117. If not, my understanding is that the
rights must be granted under the licensing provisions of the software,
or made available through one of the limitations on exclusive rights.
> The court did not seem to cover Section 117 of Title 17 very
> thoroughly and it seems to me that similar cases could argue under
> 117(a)(1) especially.
Opinions vary. I'd say the court considered 117, though. Specifically:
The law also supports the conclusion that Peak's loading of
copyrighted software into RAM creates a "copy" of that software in
violation of the Copyright Act. In Apple Computer, Inc. v. Formula
Int'l, Inc., 594 F.Supp. 617, 621 (C.D.Cal. 1984), the district
court held that the copying of copyrighted software onto silicon
chips and subsequent sale of those chips is not protected by 117 of
the Copyright Act. Section 117 allows "the `owner' 5 of a copy of a
computer program to make or authorize the making of another copy"
without infringing copyright law, if it "is an essential step in the
utilization of the computer program" or if the new copy is "for
archival purposes only." 17 U.S.C. 117 (Supp. 1988). 6 One of the
grounds for finding that 117 did not apply was the court's
conclusion that the permanent copying of the software onto the
silicon chips was not an "essential step" in the utilization of the
software because the software could be used through RAM without
making a permanent copy.
<...>
We have found no case which specifically holds that the copying of
software into RAM creates a "copy" under the Copyright Act. However,
it is generally accepted that the loading of software into a
computer constitutes the creation of a copy under the Copyright Act.
See e.g. Vault Corp. v. Quaid Software Ltd., 847 F.2d 255, 260 (5th
Cir. 1988) ("the act of loading a program from a medium of storage
into a computer's memory creates a copy of the program"); 2 Nimmer
on Copyright, 8.08 at 8-105 (1983) ("Inputting a computer program
entails the preparation of a copy."); Final Report of the National
Commission on the New Technological Uses of Copyrighted Works, at 13
(1978) ("the placement of a work into a computer is the preparation
of a copy"). We recognize that these authorities are somewhat
troubling since they do not specify that a copy is created
regardless of whether the software is loaded into the RAM, the hard
disk or the read only memory ("ROM"). However, since we find that
the copy created in the RAM can be "perceived, reproduced, or
otherwise communicated," we hold that the loading of software into
the RAM creates a copy under the Copyright Act. 17 U.S.C. 101. We
affirm the district court's grant of summary judgment as well as the
permanent injunction as it relates to this issue.
http://laws.lp.findlaw.com/9th/2/991/511.html
> Even under the conclusion of Mai v Peak, the effect on the GPL would
> be to require users to proliferate "written offers" (or copies of the
> source code) and "prominent notices" of modifications (if the program
> is modified) throughout their computer's RAM and other temporary
> storage locations as they are operating a GPL'd program.
No. GPL specifically provides this right, or rather, doesn't deny any
rights necessary to run a program:
Activities other than copying, distribution and modification are not
covered by
Re: Qt/Embedded
On Friday 17 November 2000 09:41 pm, [EMAIL PROTECTED] wrote: > > > > The legal test of copyrightability (what is copyrightable) is "original > > works of authorship, fixed in a tangible medium" [1]. Or at least the > > second part of that. > > > This seems to be a different issue. Those are good attributes for what > > can be copyrighted. But it doesn't follow that they are necessarily > > the same attributes for what can be regulated by the copyright holder. > > One specific example is a movie. The author can restrict how a movie > > is shown, even if it is displayed fleetingly on a movie screen, > > failing the "fixed" attribute. > > Film and video qualify. Performance is an exlusive right. Okay, what am I missing here. Something is not following... First you say that the copyright holder can restrict software in RAM because it is "fixed in a tangible medium". But you referenced a phrase that seems to apply to "copyrightability". So I questioned this by giving the example of film and video "display", which in not fixed in a tangible medium (the celluloid is, the transient images of light are not). Then you switch over to performance! I wasn't arguing that authors could not restrict theaters from showing films, because I know very well that they can. But they restrict them based on performance, *not* because the transient photons on a screen are considered a copy of the work. This seems to me to be two completely different things. Perhaps I don't understand the word "copyrightability". I assumes it to mean "a work that can be copyrighted." So, apropos to the original question: does the GPL restrict dynamic linkage because it makes a derivitive work in the user's RAM? (the electrical states in a RAM chip being classified as "fixed in a tangible medium") Or does it restrict dynamic linkage because it is a performance? Or does it restrict it because the user has entered into an agreement with the author (which would be binding regardless of copyright law)? > > In any case, restricting the user based on the presence of the > > software in RAM is a bad precedence for Open Source licenses to take. > > The *use* of the software should not be restricted in any way. > > Regulating it based on derivation and distribution is much better. > > But grasshopper, our enemy's strength is our strength. The same > protections and provisions which apply to proprietary software apply > equally to free software. If in-memory operations on software were > exempted from the domain of copyright law, this would be a large hole > through which software intended to be used only with other free software > might be used otherwise. No true as I (in my layman's view) understand it. A license agreement would still restrict the user in any way that the author wishes. Such a license might sneak through the cracks of the OSD, it would be contrary to the general tone of Free Software, since the first "freedom" of Free Software is the freedom to run the software for any purpose. A license that attempted to regulate what a user can do with the software and his or her RAM would strike me as anti-free. In-memory restrictions *should* be exempted from the domain of copyright law. What I do with a copyrighted work in the privacy of my own home and own RAM is no one's business. -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Fri, Nov 17, 2000 at 08:22:57PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Friday 17 November 2000 08:02 pm, [EMAIL PROTECTED] wrote: > > > > I've heard this before, but I've always dismissed it as hearsay. I > > > will have to look up Mai v Peak. The implications of this are > > > mind-boggling! Does Stephen King have rights to my brain because I've > > > read his books and they're now in my memory? > > > > The legal test of copyrightability (what is copyrightable) is "original > > works of authorship, fixed in a tangible medium" [1]. Or at least the > > second part of that. > > This seems to be a different issue. Those are good attributes for what > can be copyrighted. But it doesn't follow that they are necessarily > the same attributes for what can be regulated by the copyright holder. > One specific example is a movie. The author can restrict how a movie > is shown, even if it is displayed fleetingly on a movie screen, > failing the "fixed" attribute. Film and video qualify. Performance is an exlusive right. You'd do yourself a favor to become aquainted with the fundamentals of copyright law. 17 USC 101 - 122 are a good start, you can find them here: http://www4.law.cornell.edu/uscode/17/ch1.html I'm assuming US law for the discussion, it covers a lot of ground in any event. > In any case, restricting the user based on the presence of the > software in RAM is a bad precedence for Open Source licenses to take. > The *use* of the software should not be restricted in any way. > Regulating it based on derivation and distribution is much better. But grasshopper, our enemy's strength is our strength. The same protections and provisions which apply to proprietary software apply equally to free software. If in-memory operations on software were exempted from the domain of copyright law, this would be a large hole through which software intended to be used only with other free software might be used otherwise. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
On Friday 17 November 2000 08:02 pm, [EMAIL PROTECTED] wrote: > > I've heard this before, but I've always dismissed it as hearsay. I > > will have to look up Mai v Peak. The implications of this are > > mind-boggling! Does Stephen King have rights to my brain because I've > > read his books and they're now in my memory? > > The legal test of copyrightability (what is copyrightable) is "original > works of authorship, fixed in a tangible medium" [1]. Or at least the > second part of that. This seems to be a different issue. Those are good attributes for what can be copyrighted. But it doesn't follow that they are necessarily the same attributes for what can be regulated by the copyright holder. One specific example is a movie. The author can restrict how a movie is shown, even if it is displayed fleetingly on a movie screen, failing the "fixed" attribute. In any case, restricting the user based on the presence of the software in RAM is a bad precedence for Open Source licenses to take. The *use* of the software should not be restricted in any way. Regulating it based on derivation and distribution is much better. -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Fri, Nov 17, 2000 at 05:29:20PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote: > > > The idea is that, if a program is a work, and if (as the courts have > > held, in Mai v. Peak) a program in memory meets the fixed and > > tangible requirements of copyright law, and is therefore a copy > > under copyright law, then a program linked to a library at runtime > > is a derivative work. > > I've heard this before, but I've always dismissed it as hearsay. I > will have to look up Mai v Peak. The implications of this are > mind-boggling! Does Stephen King have rights to my brain because I've > read his books and they're now in my memory? The legal test of copyrightability (what is copyrightable) is "original works of authorship, fixed in a tangible medium" [1]. Or at least the second part of that. "Original" -- not a copy of another work. "Authorship" -- some creative threshold (however low) must exist. "Fixed" -- persisting over some period of time. "Tangible" -- capable of being perceived by others. Your own thoughts might meet the first three tests, but fail the fourth -- there is not yet a mindreading machine. What the LoC and/or Congress will decide when this time comes, I cannot say. IA(S)NAL (still) [1] http://www.loc.gov/copyright/circs/circ1.html#wwp -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
On Fri, 17 Nov 2000, David Johnson wrote: > > On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote: > > > The idea is that, if a program is a work, and if (as the courts have > > held, in Mai v. Peak) a program in memory meets the fixed and tangible > > requirements of copyright law, and is therefore a copy under copyright > > law, then a program linked to a library at runtime is a derivative > work. I don't see how this follows. > I've heard this before, but I've always dismissed it as hearsay. I will > have > to look up Mai v Peak. The implications of this are mind-boggling! Does > Stephen King have rights to my brain because I've read his books and > they're > now in my memory? If that is what the license requires, then yes. Mai v Peak establishes that because a computer program has to be copied to memory to be used, one can be guilty of copyright infringement merely by using the work. The court did not seem to cover Section 117 of Title 17 very thoroughly and it seems to me that similar cases could argue under 117(a)(1) especially. Even under the conclusion of Mai v Peak, the effect on the GPL would be to require users to proliferate "written offers" (or copies of the source code) and "prominent notices" of modifications (if the program is modified) throughout their computer's RAM and other temporary storage locations as they are operating a GPL'd program. Whether "a program linked to a library at runtime is a derivative work" is a different question. IANAL.
Re: Qt/Embedded
On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote: > The idea is that, if a program is a work, and if (as the courts have > held, in Mai v. Peak) a program in memory meets the fixed and tangible > requirements of copyright law, and is therefore a copy under copyright > law, then a program linked to a library at runtime is a derivative work. I've heard this before, but I've always dismissed it as hearsay. I will have to look up Mai v Peak. The implications of this are mind-boggling! Does Stephen King have rights to my brain because I've read his books and they're now in my memory? -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Mon, Nov 13, 2000 at 11:45:11PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Monday 13 November 2000 10:58 pm, [EMAIL PROTECTED] wrote: > > > Besides, the point of the BSD/MIT licenses is to allow this > > licensing transitivity. You'd similarly not be able to redistribute > > code derived from BSD/MIT terms after combining it with a typical > > proprietary license. > > Including the source code is one thing, but dynamically linking to a > library is a different beast. The typical proprietary license > (actually all of them that I can think of) place no restrictions on > how I can license my own application if I dynamically linking to them. > That sort of restriction seems to be limited to the Open Source world. > To be fair however, most proprietary libraries have other restrictions > that more than make up for their liberalism in this area. The difference is this: - A proprietary software development library has to both allow you to distribute product *and* provide a revenue stream for the library vendor. - A free software library may want to promote use of the library and/or the idea of free software itself. In the case of the GNU GPL, you've got an ideological document -- it's aim is to propogate its own core idea of free software. This may include restrictions on how a library can be linked to a program not covered under the same terms as the library. The GNU LGPL was developed to loosen these requirements somewhat. There are a couple of instances of proprietary libraries and/or development environments which essentially place stringent limitations on how code written for them can be used, particularly if runtime environments are required. It's really a matter of ideology though. > > Sorry. And I can't spell it either, or I might've noticed. > > > > As I understand, the "Independent and separate" language refers to > > programs which don't cross the link-layer boundary. Though this is > > a bit fuzzy in definition. Whether you can get away with shipping, > > say, binaries and object files, I'm not sure. As seperate entities, > > shipped separately, possibly. Together, probably not. > > Is this "link-layer" boundary defined in copyright law? It certainly > isn't in the GPL. RMS seems to draw his line there, but does he have > any concrete reasons for drawing it there? (I'm sure he does, I just > don't know what they are). The idea is that, if a program is a work, and if (as the courts have held, in Mai v. Peak) a program in memory meets the fixed and tangible requirements of copyright law, and is therefore a copy under copyright law, then a program linked to a library at runtime is a derivative work. There's some conflating of this under copyright law -- I believe the US statute doesn't restrict running a program by the "rightful owner" (language which raises interesting questions in the context of, say, contractors or casual visitors to a workplace). But essentially, the idea is that the GNU GPL is still working with accepted notions under law as to what a work is, and what constitutes derivative works of it, under copyright law. > But this is getting off topic. All I need to know is my legal standing > if I distribute two nearly identical BSD licensed packages, one linked > to QT/X11 and the other to Qt/Embedded. As near as I can tell, the > only real difference between them would be a different library name > sent to the linker. I don't know the answer to that. > -- > David Johnson > ___ > http://www.usermode.org -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
On Monday 13 November 2000 10:58 pm, [EMAIL PROTECTED] wrote: > Besides, the point of the BSD/MIT licenses is to allow this licensing > transitivity. You'd similarly not be able to redistribute code derived > from BSD/MIT terms after combining it with a typical proprietary > license. Including the source code is one thing, but dynamically linking to a library is a different beast. The typical proprietary license (actually all of them that I can think of) place no restrictions on how I can license my own application if I dynamically linking to them. That sort of restriction seems to be limited to the Open Source world. To be fair however, most proprietary libraries have other restrictions that more than make up for their liberalism in this area. > Sorry. And I can't spell it either, or I might've noticed. > > As I understand, the "Independent and separate" language refers to > programs which don't cross the link-layer boundary. Though this is a > bit fuzzy in definition. Whether you can get away with shipping, say, > binaries and object files, I'm not sure. As seperate entities, shipped > separately, possibly. Together, probably not. Is this "link-layer" boundary defined in copyright law? It certainly isn't in the GPL. RMS seems to draw his line there, but does he have any concrete reasons for drawing it there? (I'm sure he does, I just don't know what they are). But this is getting off topic. All I need to know is my legal standing if I distribute two nearly identical BSD licensed packages, one linked to QT/X11 and the other to Qt/Embedded. As near as I can tell, the only real difference between them would be a different library name sent to the linker. -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Mon, Nov 13, 2000 at 06:56:42PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Monday 13 November 2000 12:25 am, [EMAIL PROTECTED] wrote: > > > The governing principles are, as I understand, these: > > > > - The GPL requires that derived works of the original work not add or > > remove licensing and/or redistribution terms. > > > > - The BSD (non-advertising clause) and MIT licenses allow modification > > of distribution terms, so long as a copyright notice is retained. > > > > - The copyright notice requirement of the BSD/MIT licenses is > > consistant with a similar copyright notice requirement of the GNU > > GPL. Therefore the BSD/MIT licenses are convertible to the GPL. > > All true enough. However, that still means that I can't license my > application under the BSD license. Because if my application is a > derivative work (and RMS thinks it is), then my BSD license removes > distribution terms. This is perfectly acceptable on my end, as I'm > not distributing any GPL code. Yes. BSD/MIT is one-way transitive to GPL. You can start with BSD/MIT code and end with GPL code. You can't take the GPLd code, or derivatives, and release it under BSD/MIT terms again. > > In the instance you describe above, BSD/MIT code could link to or > > incorporate GPL code, but only if the derived work were distributed > > under the terms of the GNU GPL. > > But then I'm not distributing it under the BSD/MIT license :-) It's > sort of like saying I can vote Democrat or Republican, so long as I > vote Democrat. It makes no sense to say its okay to use the BSD > license so long as I distribute under the GPL. The key is that there are licenses which don't offer this transitivity. The MozPL, as an example, isn't compatible with the GPL unless special measures (say, dual licensing) are taken. Besides, the point of the BSD/MIT licenses is to allow this licensing transitivity. You'd similarly not be able to redistribute code derived from BSD/MIT terms after combining it with a typical proprietary license. > > I'm not sure what specifically you're referring to here. > > "Independent and seperate works" doesn't appear in the GPL, what are > > you quoting? > > Okay, okay. So I spelled "seperate" wrong! Look under section 2, the fifth > paragraph, and the second sentence. Sorry. And I can't spell it either, or I might've noticed. As I understand, the "Independent and separate" language refers to programs which don't cross the link-layer boundary. Though this is a bit fuzzy in definition. Whether you can get away with shipping, say, binaries and object files, I'm not sure. As seperate entities, shipped separately, possibly. Together, probably not. IANAL. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
On Monday 13 November 2000 12:25 am, [EMAIL PROTECTED] wrote: > The governing principles are, as I understand, these: > > - The GPL requires that derived works of the original work not add or > remove licensing and/or redistribution terms. > > - The BSD (non-advertising clause) and MIT licenses allow modification > of distribution terms, so long as a copyright notice is retained. > > - The copyright notice requirement of the BSD/MIT licenses is > consistant with a similar copyright notice requirement of the GNU > GPL. Therefore the BSD/MIT licenses are convertible to the GPL. All true enough. However, that still means that I can't license my application under the BSD license. Because if my application is a derivative work (and RMS thinks it is), then my BSD license removes distribution terms. This is perfectly acceptable on my end, as I'm not distributing any GPL code. > In the instance you describe above, BSD/MIT code could link to or > incorporate GPL code, but only if the derived work were distributed > under the terms of the GNU GPL. But then I'm not distributing it under the BSD/MIT license :-) It's sort of like saying I can vote Democrat or Republican, so long as I vote Democrat. It makes no sense to say its okay to use the BSD license so long as I distribute under the GPL. > I'm not sure what specifically you're referring to here. "Independent > and seperate works" doesn't appear in the GPL, what are you quoting? Okay, okay. So I spelled "seperate" wrong! Look under section 2, the fifth paragraph, and the second sentence. -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Sun, Nov 12, 2000 at 11:53:23PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > On Sunday 12 November 2000 11:07 pm, [EMAIL PROTECTED] wrote: > > > > Will a BSD or MIT application even be able to use these #ifdefs so > > > that the end user can recompile in private? > > > > Oblig: IANAL > > > > It's generally accepted that the MIT license is convertible to GPL, as > > is BSD without advertising clause. Programs licensed under such terms > > might be considered GPLd if linked to the Qt libraries. > > I understood it to be in the opposite direction. The GPL apparently > considers dynamic linkage to be derivation of the copyrighted work, > but derivation has a definite direction. > > A GPL application could link to or incorporate BSD/MIT code, but that > BSD/MIT code could not link to or incorporate GPL code. ObligLarryRosenMemorialDisclaimer: IANAL. The governing principles are, as I understand, these: - The GPL requires that derived works of the original work not add or remove licensing and/or redistribution terms. - The BSD (non-advertising clause) and MIT licenses allow modification of distribution terms, so long as a copyright notice is retained. - The copyright notice requirement of the BSD/MIT licenses is consistant with a similar copyright notice requirement of the GNU GPL. Therefore the BSD/MIT licenses are convertible to the GPL. In the instance you describe above, BSD/MIT code could link to or incorporate GPL code, but only if the derived work were distributed under the terms of the GNU GPL. > Under section 2 of the GPL it seems to be okay as it is the > distribution of the whole that must be under the GPL, not the > individual "independent and separate works". However, section 3 says > that all source code must be distribute under the terms of section 1, > which says "publish on each copy an appropriate copyright notice" and > "give any other recipients of the Program a copy of this License". > > This is kind of confusing, as section 1 pertains only to the original > work (verbatim copies), while section 2 pertains to derivative or > collective works. So does section 3 mean to apply section 1 OR section > 2 as appropriate, or is it saying that section 1 AND section 2 be > applied to all parts regardless of whether they are original, > derivative or collective? I'm not sure what specifically you're referring to here. "Independent and seperate works" doesn't appear in the GPL, what are you quoting? I read Section 3 to refer to distribution under either section 1 or section 2: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: ...the use of "Sections 1 _and_ 2" is confusing. One of the real lawyers care to step forward? > > Mozilla is going to be released under a dual or multi-license > > scheme, including the GNU GPL, and possibly the GNU LGPL, as well as > > the MozPL and some legacy NPL code (last I'd heard, NPL was being > > strongly deprecated in favor of MozPL). There's an announcement of > > same at http://www.mozilla.org/. > > Can a dual-licensed work be linked to GPL code if one of the licenses > is not compatible with the GPL? This would be a pretty big loophole. The theory as I understand is that if code 'A' licensed under multiple licenses, and allowing distribution or modification under any given single one of these licenses, is joined with code 'B' licensed under terms compabible with only a subset of the multiple licenses, then the combined work 'AB' accesses 'A' under only the compatible subset of licenses. In tangible terms, if Mozilla project code were incorporated with other code under terms compatible with the MozPL but not the GPL, the governing Mozilla license would be the MozPL. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Qt/Embedded
On Sunday 12 November 2000 11:07 pm, [EMAIL PROTECTED] wrote: > > Will a BSD or MIT application even be able to use these #ifdefs so > > that the end user can recompile in private? > > Oblig: IANAL > > It's generally accepted that the MIT license is convertible to GPL, as > is BSD without advertising clause. Programs licensed under such terms > might be considered GPLd if linked to the Qt libraries. I understood it to be in the opposite direction. The GPL apparently considers dynamic linkage to be derivation of the copyrighted work, but derivation has a definite direction. A GPL application could link to or incorporate BSD/MIT code, but that BSD/MIT code could not link to or incorporate GPL code. Under section 2 of the GPL it seems to be okay as it is the distribution of the whole that must be under the GPL, not the individual "independent and separate works". However, section 3 says that all source code must be distribute under the terms of section 1, which says "publish on each copy an appropriate copyright notice" and "give any other recipients of the Program a copy of this License". This is kind of confusing, as section 1 pertains only to the original work (verbatim copies), while section 2 pertains to derivative or collective works. So does section 3 mean to apply section 1 OR section 2 as appropriate, or is it saying that section 1 AND section 2 be applied to all parts regardless of whether they are original, derivative or collective? > Mozilla is going to be released under a dual or multi-license scheme, > including the GNU GPL, and possibly the GNU LGPL, as well as the MozPL > and some legacy NPL code (last I'd heard, NPL was being strongly > deprecated in favor of MozPL). There's an announcement of same at > http://www.mozilla.org/. Can a dual-licensed work be linked to GPL code if one of the licenses is not compatible with the GPL? This would be a pretty big loophole. -- David Johnson ___ http://www.usermode.org
Re: Qt/Embedded
on Sun, Nov 12, 2000 at 09:40:10PM -0800, David Johnson ([EMAIL PROTECTED]) wrote: > When Trolltech announced that they were offering their Qt/Embedded product > under the GPL, I initially assumed that it would be a dual GPL/QPL license > just like Qt/X11. I was wrong. It is only under the GPL and their proprietary > license. > > This brings up an interesting quandery. There are lots of non-GPL > applications that use Qt. What will their relationship with Qt/Embedded be? Not sure. This is a specific issue that's been raised by Sun and Netscape in deciding to dual license their technologies under a combination of GNU GPL and other licenses. > On one hand the GPL dictates the license of all applications that > reference the library's interface. On the other hand, the interface > for for Qt/Embedded is nearly identical to Qt/X11, so that many > programs can be ported with a few #ifdefs and a recompile. > > Will a BSD or MIT application even be able to use these #ifdefs so > that the end user can recompile in private? Oblig: IANAL It's generally accepted that the MIT license is convertible to GPL, as is BSD without advertising clause. Programs licensed under such terms might be considered GPLd if linked to the Qt libraries. > Will embedded platforms be off limits to these applications? For GPL > authors, this is a non-issue, but for the rest of us its frustrating > (imagine the next version of GTK+ being under the GPL license and > you're a Mozilla developer). Mozilla is going to be released under a dual or multi-license scheme, including the GNU GPL, and possibly the GNU LGPL, as well as the MozPL and some legacy NPL code (last I'd heard, NPL was being strongly deprecated in favor of MozPL). There's an announcement of same at http://www.mozilla.org/. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
