Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/16/05, Dalibor Topic [EMAIL PROTECTED] wrote: Alexander Terekhov wrote: My, what a lunacy. Regarding FSF's derivative works theory, I suspect that the FSF objective is to establish basis for insanity defense -- the only thing that might help when someone finally decides to go after them. You may want to follow in the footsteps of Mr. Daniel Wallace, Wallace decided to go after the GPL and he is asking for injunctive relieve. He's not asking to put the FSF's officers in jail. Hint: http://www.kilpatrickstockton.com/publications/downloads/6.22.04AntitrustLegalAlert.pdf the maximum prison sentence is increased to 10 years from 3 years. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
Alexander Terekhov wrote: On 9/16/05, Dalibor Topic [EMAIL PROTECTED] wrote: Alexander Terekhov wrote: My, what a lunacy. Regarding FSF's derivative works theory, I suspect that the FSF objective is to establish basis for insanity defense -- the only thing that might help when someone finally decides to go after them. You may want to follow in the footsteps of Mr. Daniel Wallace, Wallace decided to go after the GPL and he is asking for injunctive relieve. He's not asking to put the FSF's officers in jail. Are you asking to put FSF's officers in jail? morbidly curious, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/16/05, Dalibor Topic [EMAIL PROTECTED] wrote: [...] Are you asking to put FSF's officers in jail? I'm not an Attorney General. But to fulfill your curiosity, I'd rather extradite the entire gang to North Korea with no right to return. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
We SHOULD be taking an individual work and analyzing it for creative content. Not cooking up arbitrary hypotheses and pretending they mean something I am going to try taking some hours this weekend and verify one of the programs + libcurl + openssl cases. I'll get back to you next week. I don't have a specific answer. That depends on the creative content of X and Y. But, in general terms, I'd be looking for creative ideas (ideas first expressed in Y) which are incorporated into X. For example, if X will serve as a replacement for Y, that would strongly hint (but not guarantee) that X is a derivative of Y. One last thing: not even this. Following this reason, the GNUTLS SSL shim would be a derivative work of OpenSSL. And it's not. Remember, the whole argument I'm giving is: 1. the GPL can only restrict the distributions of an original work or its derivatives; and 2. the only way to determine if a work is a derivative work of another is going thru the abstraction/filtration/comparison process. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Alexander Terekhov [EMAIL PROTECTED] writes: On 9/14/05, Andrew Suffield [EMAIL PROTECTED] wrote: [...] As an anarchist I You're brainwashed GNUtian. Wow. I think that's the *least relevant* rejoinder I've ever seen. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/16/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: [...] 1. the GPL can only restrict the distributions of an original work or its derivatives; Modulo first sale (which is nonexistent in the GNU Republic). and 2. the only way to determine if a work is a derivative work of another is going thru the abstraction/filtration/comparison process. http://www.digital-law-online.com/lpdi1.0/treatise24.html (IV. Applying The AFC Test) quote Elements are filtered out of consideration on the basis of broad criteria, including: - The element's expression was dictated by reasons of efficiency, such as when it is the best way of performing a particular function. - The element's expression was dictated by external factors, such as using an existing file format or interoperating with another program. - The element's expression is a conventional way of writing something in the particular programming language or machine running the program. - The element, at the particular level of abstraction, is an unprotectable process and not protectable expression. - The element is taken from the public domain or is an unprotectable fact. Any protection for elements dictated by efficiency or external factors or processes must come from patents or trade secrets, if at all, and not from copyright. /quote See also http://www.innovationlaw.org/lawforum/pages/heer.doc (The Case against Copyright Protection of Non-literal Elements of Computer Software) regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/16/05, Rich Walker [EMAIL PROTECTED] wrote: Alexander Terekhov [EMAIL PROTECTED] writes: On 9/14/05, Andrew Suffield [EMAIL PROTECTED] wrote: [...] As an anarchist I You're brainwashed GNUtian. Wow. Anarchists are anti-copyright and against fake free software. http://timtyler.org/fake_free_software/ At least when it comes to [L]GPL, GNUtians are quite pro-copyright... nevermind that they confuse engineering dependencies with copyright infringement, don't grok first sale, and happen to believe in Moglens pure copyright license, not a contract lunacy. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
Alexander Terekhov [EMAIL PROTECTED] writes: On 9/16/05, Rich Walker [EMAIL PROTECTED] wrote: Alexander Terekhov [EMAIL PROTECTED] writes: On 9/14/05, Andrew Suffield [EMAIL PROTECTED] wrote: [...] As an anarchist I You're brainwashed GNUtian. Wow. Anarchists are anti-copyright and against fake free software. You *are* aware that anarchism isn't a monolithic block, aren't you. http://timtyler.org/fake_free_software/ An interesting restatement of the BSD vs GPL argument. Of course, it relies on an unstated definition of the word Free. At least when it comes to [L]GPL, GNUtians are quite pro-copyright... nevermind that they confuse engineering dependencies with copyright infringement, don't grok first sale, and happen to believe in Moglens pure copyright license, not a contract lunacy. I always thought that the GPL was an interesting hack using the methods of copyright and contract law to create a public commons that hopefully could be kept inviolate. Which, funnily enough, is a very anarchist thing to do (look at housing co-operatives for another example). cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
** Raul Miller ::
On 9/12/05, Humberto Massa Guimarães [EMAIL PROTECTED]
wrote:
Assume every work eligible for copyright protection, for the
sake of the argument, and for $DEITY's sake. AND we're
talking ONLY about dynamic linking. AND, to boot, that those
bits that end up in a compiled work by way of being in a .h
file (for instance) are not eligible for copyright
protection.
This is even more confusing. assume every work eligible for
copyright protection...are not eligible for copyright
protection? In principle, I ought to be able to figure out
what you're saying by looking at the grammar of your
sentences, but in this case I can't.
I thought that one was simple:
1. please assume every work mentioned in the argument (unless
otherwise noted) eligible for copyright protection;
Ok. This leaves open the question of how thin that protection
would be (which in turn depends on the specific work(s) in
question). But it does eliminate some scenarios.
Assume that programX is a complex (1 SLOC) program, written by
a single author, and completely original.
2. please assume we are talking (unless otherwise noted) about
dynamic linking; and
Dynamic linking of what, with what, in what fashion?
Everything that is a part of the programX /per/ /se/ may be
statically linked, but every library not written by the programX's
author is dynamically linked.
3. please assume that those bits that end up in a compiled work
by way of being in .h file or any other similar thing are not
eligible for copyright protection (this is an explicit exception
to #1 above).
So basically, any bits which are in the executable which would not
be there if all .h files were removed are not eligible for
copyright protection? That's tantamount to saying that the binary
isn't copyrightable.
Why? if I do in my source code
---
#include cstdio
void f() { write(fileno(STDERR), ola Raul\n, 9); }
---
and then I remove the #include, meaning *no* bits of cstdio are
included in my program, I get a compilation error, but *my* program
copyright status is unaltered IMHO. If I want to make it compile
again, I just need to alter this to:
---
void f() { extern int C write(short, const void *, unsigned);
write(2, ola Raul\n, 9); }
---
and voila. I have a program which does not include *any* bits from
cstdio. Are you arguing that the copyright status of my program
changed?
(just to be clear, assume I did the same throughout a very complex
program instead of the simple example I gave).
Alternatively, you're trying to make some kind of statement about
the mechanisms of the compilation process and the information
density of .h files, but that kind of reasoning seems to beg the
question of what's derived from what.
No. I am just stating what some codelaw from Brasil I have already
mentioned here (and IIRC some US caselaw MKE dug up): computer
programs have parts of them which are not eligible for copyright
protection because of the use of said parts as descriptions of
interface -- such parts are extremely limited in the creativity
versus the functionality they present. One classic example of said
parts are *.h files. I am NOT saying that every single bit of .h
files is uncopyrightable. I AM saying, instead, that TYPICALLY every
bit of information that ends up in the a.out file that came from a
library .h file, in the case of C programs, especially, in
non-protected.
One of the confusing things is where you say by way of being
in a .h file (for instance). As an instance of what?
Yes. one nice example are text of non-trivial inlined functions.
So, perhaps you're saying that all .h files in the cases you're
interested in are trivial?
No, you got me wrong. I am saying that if the text of
---
template class I void sort(I, I);
---
ends up in a program a.out because a.cc #included algorithm, this
sort of partial copy is part of the limitations of the copyright
statute -- i.e., in that specific case, the text of sort() would NOT
be protected by copyrights. Why? In Brasil, mainly because an
drop-in alternative STL could bring to the same program other text
-- or none at all (in the case sort() is not inlined in the
alternative STL).
Processes are not fixed in a material form. If they are, they
cease to be processes and are instead something else (perhaps a
symbolic description of some process).
I was not talking about processes, but about the RESULT of
processes. For instance, if I translate this e-mail from English to
Spanish, this is a process. The translated e-mail is the result of
said process, and it's fixed on a material medium (my HD). The
translated e-mail, supposing the original was eligible for copyright
protection, is a derivative work of the original. THAT is the
definition of derivation: the RESULT of processes. In case of
Brasil, the result of intelectually-novel transformations.
The copyright law itself defined a
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote:
Ok. This leaves open the question of how thin that protection
would be (which in turn depends on the specific work(s) in
question). But it does eliminate some scenarios.
Assume that programX is a complex (1 SLOC) program, written by
a single author, and completely original.
I don't know what completely original means.
Computer programs are always built on the work of others.
Ok, maybe I should make an exception for Chuck Moore. After all, he
invented his own language, designs his own VLSI, and so on. But
most people base their work on other people's work.
Anyways, if I take you literally -- if a work really is completely original,
then obviously it's not a derivative work. But in the current context,
I'm dubious that there are any real examples that fit your description.
2. please assume we are talking (unless otherwise noted) about
dynamic linking; and
Dynamic linking of what, with what, in what fashion?
Everything that is a part of the programX /per/ /se/ may be
statically linked, but every library not written by the programX's
author is dynamically linked.
This begs the question.
3. please assume that those bits that end up in a compiled work
by way of being in .h file or any other similar thing are not
eligible for copyright protection (this is an explicit exception
to #1 above).
So basically, any bits which are in the executable which would not
be there if all .h files were removed are not eligible for
copyright protection? That's tantamount to saying that the binary
isn't copyrightable.
Why? if I do in my source code
---
#include cstdio
void f() { write(fileno(STDERR), ola Raul\n, 9); }
---
and then I remove the #include, meaning *no* bits of cstdio are
included in my program, I get a compilation error, but *my* program
copyright status is unaltered IMHO. If I want to make it compile
again, I just need to alter this to:
---
void f() { extern int C write(short, const void *, unsigned);
write(2, ola Raul\n, 9); }
---
and voila. I have a program which does not include *any* bits from
cstdio. Are you arguing that the copyright status of my program
changed?
No, I'm arguing that this is a trivial example -- beneath
the notice of copyright law.
(just to be clear, assume I did the same throughout a very complex
program instead of the simple example I gave).
In that case you're including the .h file contents in your program,
and this really devolves to a question of whether those specific
contents were copyrightable.
If the contents are trivial (as in your example here), then your copying
is beneath the notice of copyright law. But if the contents are
complex (as might be implied by the assumption you're asking me
to make) then you've got a copyright issue.
Alternatively, you're trying to make some kind of statement about
the mechanisms of the compilation process and the information
density of .h files, but that kind of reasoning seems to beg the
question of what's derived from what.
No. I am just stating what some codelaw from Brasil I have already
mentioned here (and IIRC some US caselaw MKE dug up): computer
programs have parts of them which are not eligible for copyright
protection because of the use of said parts as descriptions of
interface -- such parts are extremely limited in the creativity
versus the functionality they present.
This is true for some cases involving some computer programs.
If it were a universal truth, you could quote the relevant law for me,
and we wouldn't be having this discussion.
One classic example of said
parts are *.h files. I am NOT saying that every single bit of .h
files is uncopyrightable. I AM saying, instead, that TYPICALLY every
bit of information that ends up in the a.out file that came from a
library .h file, in the case of C programs, especially, in
non-protected.
TYPICALLY, *.h files are made available under terms such that this
isn't an issue. This is because most people want this kind of thing
to be generally available.
There are additional cases where *.h files are not copyrightable
because their creative contents are trivial (and in some cases
this is because they're derived with minor changes from something
available under a more permissive license).
But are we talking about the typical case? You can show something
is true for the typical case, but when you get to a specific case
you still have to analyze it on its own merits.
One of the confusing things is where you say by way of being
in a .h file (for instance). As an instance of what?
Yes. one nice example are text of non-trivial inlined functions.
So, perhaps you're saying that all .h files in the cases you're
interested in are trivial?
No, you got me wrong. I am saying that if the text of
---
template class I void sort(I, I);
---
ends up in a program a.out because a.cc
Re: GPL, yet again. (The kernel is a lot like a shared library)
** Raul Miller :: On 9/15/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Ok. This leaves open the question of how thin that protection would be (which in turn depends on the specific work(s) in question). But it does eliminate some scenarios. Assume that programX is a complex (1 SLOC) program, written by a single author, and completely original. I don't know what completely original means. Anyways, if I take you literally -- if a work really is completely original, then obviously it's not a derivative work. But in the current context, I'm dubious that there are any real examples that fit your description. Remember what I said some messages ago: we must start from somewhere simple, to get to some conclusions and then, later, add the complexities. By completely original I meant programX's author sat down and wrote the whole thing without copying code from anyone. He could (should?) have used #includes, etc., but those (for now) are not relevant. 2. please assume we are talking (unless otherwise noted) about dynamic linking; and Dynamic linking of what, with what, in what fashion? Everything that is a part of the programX /per/ /se/ may be statically linked, but every library not written by the programX's author is dynamically linked. This begs the question. What begs what question? [removed parts] and voila. I have a program which does not include *any* bits from cstdio. Are you arguing that the copyright status of my program changed? No, I'm arguing that this is a trivial example -- beneath the notice of copyright law. I specifically said (below) that you were to assume that I'm talking about a complex program, and that the simple thing I did above was repeated throughtout said complex program, to eliminate the this is not protected case. (just to be clear, assume I did the same throughout a very complex program instead of the simple example I gave). In that case you're including the .h file contents in your program, and this really devolves to a question of whether those specific contents were copyrightable. If the contents are trivial (as in your example here), then your copying is beneath the notice of copyright law. But if the contents are complex (as might be implied by the assumption you're asking me to make) then you've got a copyright issue. My point is exactly: by law (codelaw in Brasil and caselaw IIRC in the US) I do NOT get a copyright issue because the law permits me to do just that, up to a point. Alternatively, you're trying to make some kind of statement about the mechanisms of the compilation process and the information density of .h files, but that kind of reasoning seems to beg the question of what's derived from what. No. I am just stating what some codelaw from Brasil I have already mentioned here (and IIRC some US caselaw MKE dug up): computer programs have parts of them which are not eligible for copyright protection because of the use of said parts as descriptions of interface -- such parts are extremely limited in the creativity versus the functionality they present. This is true for some cases involving some computer programs. If it were a universal truth, you could quote the relevant law for me, and we wouldn't be having this discussion. I already did. I cited in March or April in our discussion codelaw from Brasil and some caselaw that specified exactly that. In Brazilian codelaw, with a quick search I find: Law 9609/98 (Computer Programs Act): Art. 6. Do not constitute infringement on the computer program's author's rights: [...] III- the ocorrence of similarity with another preexistent program when it's decorrent from the functional characteristics of its application, from the observance of normative or techinical precepts [*], or from limitation of an alternate form for its expression. Sorry for the horrid translation, but the law is written using an inverted verb predicate: subject1; subject2; subject3 construction that exists in Portuguese (especially used in legalese Portuguese). The clause marked with [*] normative or technical precepts was already tested in our courts as encompassing published APIs. That is to say: there are limited ways of describing (for instance) the OpenSSL API as an openssl.h file, or even as a set of *.h files, so similar *.h files are not infringing. This is why I told you on-list, four or five months ago, that *.h files are in principle not protected. Explaining better: is not that they are not protected: is that copyright protection is EXTREMELY selective when you are talking of things that are TYPICALLY in *.h files. IIRC Michael K. Edwards brought relevant similar US codelaw or caselaw. One classic example of said parts are *.h files. I am NOT saying that every single bit of .h files is uncopyrightable. I AM saying, instead, that TYPICALLY every bit of information that ends up in the
Re: GPL, yet again. (The kernel is a lot like a shared library)
permission for a compilation work. Copyright doesn't establish exclusive right to prepare (original) compilations (the term compilation includes collective works). Compilation is entirely separate work from its constituents. You'd need permission to prepare a derivative compilation (by modifying some preexisting compilation), but what's because you are preparing a derivative work, not an original compilation. HOUSE REPORT NO. 94-1476 Section 103 complements section 102: A compilation or derivative work is copyrightable if it represents an ''original work of authorship'' and falls within one or more of the categories listed in section 102. Read together, the two sections make plain that the criteria of copyrightable subject matter stated in section 102 apply with full force to works that are entirely original and to those containing preexisting material. Section 103(b) is also intended to define, more sharply and clearly than does section 7 of the present law (section 7 of former title 17), the important interrelationship and correlation between protection of preexisting and of ''new'' material in a particular work. The most important point here is one that is commonly misunderstood today: copyright in a ''new version'' covers only the material added by the later author, and has no effect one way or the other on the copyright or public domain status of the preexisting material. Between them the terms ''compilations'' and ''derivative works'' which are defined in section 101 comprehend every copyrightable work that employs preexisting material or data of any kind. There is necessarily some overlapping between the two, but they basically represent different concepts. A ''compilation'' results from a process of selecting, bringing together, organizing, and arranging previously existing material of all kinds, regardless of whether the individual items in the material have been or ever could have been subject to copyright. A ''derivative work,'' on the other hand, requires a process of recasting, transforming, or adapting ''one or more preexisting works''; the ''preexisting work'' must come within the general subject matter of copyright set forth in section 102, regardless of whether it is or was ever copyrighted. The second part of the sentence that makes up section 103(a) deals with the status of a compilation or derivative work unlawfully employing preexisting copyrighted material. In providing that protection does not extend to ''any part of the work in which such material has been used unlawfully,'' the bill prevents an infringer from benefiting, through copyright protection, from committing an unlawful act, but preserves protection for those parts of the work that do not employ the preexisting work. Thus, an unauthorized translation of a novel could not be copyrighted at all, but the owner of copyright in an anthology of poetry could sue someone who infringed the whole anthology, even though the infringer proves that publication of one of the poems was unauthorized. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: [...] The license on visual studio doesn't really matter here. What matters is the license on the SDK (which has fairly generous terms for stuff you write yourself). It follows that if sell a Windows program that you've made without Microsoft SDK which has generous terms (what are they, BTW?)... Do you sincerely think MS would have such generosity? Those terms are there because the army of in-house-lawyers knew that other, more restrictive terms would be unenforceable. .. you may end up in jail for distributing unauthorized derivatives. That's how freedom works in the GNU Republic. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Alexander Terekhov [EMAIL PROTECTED] wrote: On 9/15/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: [...] The license on visual studio doesn't really matter here. What matters is the license on the SDK (which has fairly generous terms for stuff you write yourself). It follows that if sell a Windows program that you've made without Microsoft SDK which has generous terms (what are they, BTW?)... When you're talking about what you need to build generic programs which just work (as opposed to the development tools required to build them or anything really fancy), Microsoft tends to make that stuff freely distributable. Of course, once you're using their system you're under repeated low-grade pressure to buy more stuff, but the first hits are free. -- Raul
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Raul Miller [EMAIL PROTECTED] wrote: [...] It follows that if sell a Windows program that you've made without if you sell, I meant. Microsoft SDK which has generous terms (what are they, BTW?)... When you're talking about what you need to build generic programs I said Windows program, not generic. A program that uses MS API. In the GNU Republic, you can't even distribute copies in source code (without risking to end up in jail)... unless it happens to work under buggy WINE as well (i.e. use nothing really fancy that WINEers have not yet implemented). http://web.novalis.org/talks/compliance-for-developers/slide-49.html My, what a lunacy. Regarding FSF's derivative works theory, I suspect that the FSF objective is to establish basis for insanity defense -- the only thing that might help when someone finally decides to go after them. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: ** Raul Miller :: On 9/15/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Ok. This leaves open the question of how thin that protection would be (which in turn depends on the specific work(s) in question). But it does eliminate some scenarios. Assume that programX is a complex (1 SLOC) program, written by a single author, and completely original. I don't know what completely original means. Anyways, if I take you literally -- if a work really is completely original, then obviously it's not a derivative work. But in the current context, I'm dubious that there are any real examples that fit your description. Remember what I said some messages ago: we must start from somewhere simple, to get to some conclusions and then, later, add the complexities. By completely original I meant programX's author sat down and wrote the whole thing without copying code from anyone. He could (should?) have used #includes, etc., but those (for now) are not relevant. That's not starting out simple. Starting out simple starts us without any #includes. 2. please assume we are talking (unless otherwise noted) about dynamic linking; and Dynamic linking of what, with what, in what fashion? Everything that is a part of the programX /per/ /se/ may be statically linked, but every library not written by the programX's author is dynamically linked. This begs the question. What begs what question? What is the scope of the copyright problem? [removed parts] and voila. I have a program which does not include *any* bits from cstdio. Are you arguing that the copyright status of my program changed? No, I'm arguing that this is a trivial example -- beneath the notice of copyright law. I specifically said (below) that you were to assume that I'm talking about a complex program, and that the simple thing I did above was repeated throughtout said complex program, to eliminate the this is not protected case. You explicitly left that case in for the #includes. Basically, you're arguing both sides of the fence. You're arguing that everything is protected except for the stuff that's not. And that's fine, except it isn't a basis for proving anything else. We SHOULD be taking an individual work and analyzing it for creative content. Not cooking up arbitrary hypotheses and pretending they mean something If it were a universal truth, you could quote the relevant law for me, and we wouldn't be having this discussion. I already did. I cited in March or April in our discussion codelaw from Brasil and some caselaw that specified exactly that. In Brazilian codelaw, with a quick search I find: Law 9609/98 (Computer Programs Act): Art. 6. Do not constitute infringement on the computer program's author's rights: [...] III- the ocorrence of similarity with another preexistent program when it's decorrent from the functional characteristics of its application, from the observance of normative or techinical precepts [*], or from limitation of an alternate form for its expression. Sorry for the horrid translation, but the law is written using an inverted verb predicate: subject1; subject2; subject3 construction that exists in Portuguese (especially used in legalese Portuguese). The clause marked with [*] normative or technical precepts was already tested in our courts as encompassing published APIs. That is to say: there are limited ways of describing (for instance) the OpenSSL API as an openssl.h file, or even as a set of *.h files, so similar *.h files are not infringing. This is why I told you on-list, four or five months ago, that *.h files are in principle not protected. Explaining better: is not that they are not protected: is that copyright protection is EXTREMELY selective when you are talking of things that are TYPICALLY in *.h files. Ok, I'm not educated enough to read the law in its original Portuguese, so let's assume that your interpretation is correct. IIRC Michael K. Edwards brought relevant similar US codelaw or caselaw. The caselaw he referred to does not have anywhere near the sweeping impact that you claim for the Brasilian code. Mind you, the Brasilian approach might very well be superior, from a technological point of view or a philosophical point of view. It's just that that's not the law up north. One classic example of said parts are *.h files. I am NOT saying that every single bit of .h files is uncopyrightable. I AM saying, instead, that TYPICALLY every bit of information that ends up in the a.out file that came from a library .h file, in the case of C programs, especially, in non-protected. TYPICALLY, *.h files are made available under terms such that this isn't an issue. This is because most people want this kind of thing to be generally available. No. OpenSSL *.h
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Alexander Terekhov [EMAIL PROTECTED] wrote: On 9/15/05, Raul Miller [EMAIL PROTECTED] wrote: Microsoft SDK which has generous terms (what are they, BTW?)... When you're talking about what you need to build generic programs I said Windows program, not generic. A program that uses MS API. That's no conflict. There are generic windows programs. By generic I meant, for example, using the win32 api and not an office api. -- Raul
Re: GPL, yet again. (The kernel is a lot like a shared library)
Alexander Terekhov wrote: My, what a lunacy. Regarding FSF's derivative works theory, I suspect that the FSF objective is to establish basis for insanity defense -- the only thing that might help when someone finally decides to go after them. You may want to follow in the footsteps of Mr. Daniel Wallace, a famous platiff [1] trying to make fascinating claims about the GPL in court. cheers from the gnu.misc.discuss peanut gallery, dalibor topic [1] http://en.wikipedia.org/wiki/Daniel_Wallace_%28plaintiff%29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Tue, Sep 13, 2005 at 04:06:00AM +0200, Claus F?rber wrote: Andrew Suffield [EMAIL PROTECTED] schrieb/wrote: On Fri, Sep 09, 2005 at 05:52:00PM +0200, Claus F?rber wrote: So one of the assumptions made above is wrong. The one where you assumed that dynamic linking was relevent. I've been saying that all along. You were also saying that C is probably a derivative of O: | I do not know how a program that really used openssl, calling its | functions, could avoid being a derivative. I can't rule it out but (The typical case for dynamic linking is that there are function calls.) For a high-level argumentation like mine, it does not matter whether the legal link between C and O is created by dynamic linking, incorporating function calls, or anything else, the result is always the same: If O can be replaced by M, the assumption that B/C is a derivative of O, must be wrong. The difference is that when you talk about dynamic linking, the 'replacement' means fiddling with linker options or package dependencies. It is indeed nonsense to conclude that doing these things would change the copyright status of the program using the libraries. When you talk about writing programs, 'replacement' means rewriting parts of it. I don't think anybody here is going to find it difficult to believe that rewriting the program to use M instead of O would change the copyright status of the program you are rewriting parts of. Your entire argument is based on the fact that it's nonsense for dynamic linking because replacing one external run-time library with another shouldn't change the copyright status of the program using it. Yes, it's nonsense - but you're the one who introduced it. The introduction of dynamic linking was the mistaken assumption. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
The difference is that when you talk about dynamic linking, the 'replacement' means fiddling with linker options or package dependencies. It is indeed nonsense to conclude that doing these things would change the copyright status of the program using the libraries. in the case of dynamic linking, IMHO, 'replacement' means: cd /usr/lib rm libopenssl.so ln -sf libnovossl.so libopenssl.so This did not change programX; next time programX is loaded, it will execute with libnovossl instead of libopenssl. I can't see how can programX possibly be a derivative work of libopenssl or of libnvossl. Can you please explain it to me, like if I was a four-year-old? I am asking politely. Your entire argument is based on the fact that it's nonsense for dynamic linking because replacing one external run-time library with another shouldn't change the copyright status of the program using it. Yes, it's nonsense - but you're the one who introduced it. The introduction of dynamic linking was the mistaken assumption. Why is the introduction of dynamic linking the mistaken assumption? Almost every program vs. lib relationship in Debian is via dynamic linking. What is really on the table here is: Debian distributes programX.deb (containing /usr/bin/programX), openssl.deb (containing /usr/lib/libopenssl.so.X.Y), and novossl.deb (containing /usr/lib/libnovossl.so.X.Y). [programX = GPL, novossl = GPL] I want to know exactly why and how the GPL forbids the postinst script for any of the libraries of setting up the /usr/lib/libssl.so symlink pointing to its own library. If someone gives me a nice, logically sound argument, I'll shut up. -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 14, 2005 at 01:14:21AM +0200, Alexander Terekhov wrote: Hint: http://europa.eu.int/idabc/servlets/Doc?id=21197 (... Besides, too overbroad a viral effect ...) This document is a report from two french bureaucrats and one employee of Unisys corp, recommending methods of licensing which are in line with the aims of the EU. Can't see the relevence. These are people working for the EU deciding what to do with software they write. They are not people deciding what laws to make. This sentence continues: [...] Each author is the sole person entitled to decide upon the ways of exploiting his/her work. As an anarchist I wholeheartedly support this principle, it being the core of anarchist philosophy. Unfortunately it is not the case that the law reflects it, nor does market practice. Authors very rarely have sole entitlement to decide what may be done with their work. Only in the realm of GPLed software do they often have any say in the decision at all. With MIT-style licensing they abandon any such control; with commercial licensing they yield it all to the control of their employer. Those commission folks don't quite see the light regarding static linking yet... but that's correctable. I support any efforts to defang copyright and remove such wanton disrespect for individual liberty from the law. However, the simple fact remains that no such efforts have, to date, been effective. We have to deal with the world as it is, not as we would like it to be. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 14, 2005 at 01:20:17PM -0300, Humberto Massa Guimar?es wrote: I can't see how can programX possibly be a derivative work of libopenssl or of libnvossl. Can you please explain it to me, like if I was a four-year-old? You stole somebody else's work when you wrote programX. Piracy is wrong. You are destroying the hopes and dreams of an entire industry. [0] Your entire argument is based on the fact that it's nonsense for dynamic linking because replacing one external run-time library with another shouldn't change the copyright status of the program using it. Yes, it's nonsense - but you're the one who introduced it. The introduction of dynamic linking was the mistaken assumption. Why is the introduction of dynamic linking the mistaken assumption? This was explained in the part you deleted. [0] This appears to be the way it is explained to four-year-olds -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
RE: GPL, yet again. (The kernel is a lot like a shared library)
You stole somebody else's work when you wrote programX. Piracy is wrong. You are destroying the hopes and dreams of an entire industry. [0] [0] This appears to be the way it is explained to four-year-olds You apparently do not have kids. Especially four-year-olds. Mine is already 6 and he would ask me why? why did the library exist? why can't i write a program that uses some library? besides, your answer could be considered child abuse in some jurisdictions, and you would have to pay some pain and suffering when it comes up later in therapy. Now seriously, can you please explain to me: 1. do you think programX is a derivative work of libopenssl? 2. why? 3. do you think programX is a derivative work of libnovossl? 4. why? I keep making questions, and you keep giving me non-sequiturs. You said that this: When you talk about writing programs, 'replacement' means rewriting parts of it. I don't think anybody here is going to find it difficult to believe that rewriting the program to use M instead of O would change the copyright status of the program you are rewriting parts of. is the answer to why dynlinking is irrelevant. I even agree with you that dynlinking is irrelevant, altough with another spin, but it does not matter to the case on discussion. The case in discussion, AFAIK, is: 5. can Debian distribute programX.deb? 6. why? 7. can Debian distribute openssl.deb? 8. why? 9. can Debian distribute novossl.deb? 10. why? 11. can Debian distribute each and every combination of the three packages above? 12. why? 13. can openssl install itself as /usr/lib/libssl.so? 14. why? 15. can novossl install itself as /usr/lib/libssl.so? 16. why? 17. can they use alternatives to regulate who is installed as /usr/lib/libssl.so? 18. why? The questions above assume that /usr/bin/programX is dynlinked to whatever /usr/lib/libssl.so exists, for simplicity of argument. Throughout this mail, I made you eighteen simple questions. I would appreciate immensely if you (or anyone else on-list, for that matter) answered those questions. I think, honestly, that I am trying to do something worthy here (eliminate a lot of bts entries that I consider pseudo-bugs, for instance), and that I am trying to help. I have much respect for your contributions as a DD, and I think you ought to have the same respect for the contributions I am trying to give to Debian, too. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 14, 2005 at 01:53:10PM -0300, Humberto Massa Guimar?es wrote: Now seriously, can you please explain to me: 1. do you think programX is a derivative work of libopenssl? 2. why? 3. do you think programX is a derivative work of libnovossl? 4. why? I keep making questions, and you keep giving me non-sequiturs. You keep asking questions that don't have answers because you phrase them in terms of dynamic linking all the time. None of these four questions are answerable because the only thing you've said is that programX is dynamically linked to libssl and that both these packages contain a libssl file. THAT IS NOT RELEVANT INFORMATION. As I said the last time you asked this exact same question, it depends on all the stuff you haven't said. I also sketched out the conditions for the various possible answers. I'm not going to repeat it again. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
Now seriously, can you please explain to me: 1. do you think programX is a derivative work of libopenssl? 2. why? 3. do you think programX is a derivative work of libnovossl? 4. why? I keep making questions, and you keep giving me non-sequiturs. You keep asking questions that don't have answers because you phrase them in terms of dynamic linking all the time. None of these four questions are answerable because the only thing you've said is that programX is dynamically linked to libssl and that both these packages contain a libssl file. THAT IS NOT RELEVANT INFORMATION. What is the relevant information, then? I'll provide it. As I said the last time you asked this exact same question, it depends on all the stuff you haven't said. I also sketched out the conditions for the various possible answers. I'm not going to repeat it again. Please, point me to the sketch, because I could not find it. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/14/05, Andrew Suffield [EMAIL PROTECTED] wrote: [...] As an anarchist I You're brainwashed GNUtian. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/12/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Assume every work eligible for copyright protection, for the sake of the argument, and for $DEITY's sake. AND we're talking ONLY about dynamic linking. AND, to boot, that those bits that end up in a compiled work by way of being in a .h file (for instance) are not eligible for copyright protection. This is even more confusing. assume every work eligible for copyright protection...are not eligible for copyright protection? In principle, I ought to be able to figure out what you're saying by looking at the grammar of your sentences, but in this case I can't. I thought that one was simple: 1. please assume every work mentioned in the argument (unless otherwise noted) eligible for copyright protection; Ok. This leaves open the question of how thin that protection would be (which in turn depends on the specific work(s) in question). But it does eliminate some scenarios. 2. please assume we are talking (unless otherwise noted) about dynamic linking; and Dynamic linking of what, with what, in what fashion? 3. please assume that those bits that end up in a compiled work by way of being in .h file or any other similar thing are not eligible for copyright protection (this is an explicit exception to #1 above). So basically, any bits which are in the executable which would not be there if all .h files were removed are not eligible for copyright protection? That's tantamount to saying that the binary isn't copyrightable. Alternatively, you're trying to make some kind of statement about the mechanisms of the compilation process and the information density of .h files, but that kind of reasoning seems to beg the question of what's derived from what. One of the confusing things is where you say by way of being in a .h file (for instance). As an instance of what? Yes. one nice example are text of non-trivial inlined functions. So, perhaps you're saying that all .h files in the cases you're interested in are trivial? Is B a derivative of M? Is A a derivative of M? -- those are the million-dollar questions. I don't think so, because there is no intellectually-novel transformation of M that produces A or B. I'm trying to find an interpretation of this sentence that has some meaning and I'm clueless. As a general rule, all derivative works are produced by humans. As a general rule, when we talk about transformations we're talking about processes -- something outside the scope of copyright law (thought not outside the realm of human activity). Why is it outside the scope of copyright law? Processes are not fixed in a material form. If they are, they cease to be processes and are instead something else (perhaps a symbolic description of some process). The copyright law itself defined a derivation as the result of said processes. 17USC enumerates some processes, and Brazilian Author's Rights acts defines them. I don't know what you're talking about here. [For now, I'm skipping sentences which seem to depend on this intellectually novel transformation sentence for their meaning.] Intellectualy novel transformation is the text of the code law that defines derivative work in Brasil. I suspect -- but I don't have the time right now to confirm -- that this text (which is already in one of my recent posts) is directly copied from the Geneva convention text. IOW, it's the letter of the law. I think I know what you're talking about here. Basically: stuff can be copyrighted if it's something which has concrete existence, which a person put creative effort into making. For example, a person could write something with a pen, and that could be copyrighted. Now, you could look at what a pen does -- it mechanically transfers ink onto paper, and if you focussed just on that, you wouldn't have anything copyrightable. Further, you could take this work and you could run it through a photocopier -- so running it through a photocopier does not in and of itself make a work copyrightable. But, still, the output of the photocopier might have copyright protection because of something which happened earlier -- before the photocopier was used. This same rule must apply works which use dynamic linking. The dynamic linking doesn't mean that the work is protected by copyright. It doesn't say who has the copyrights. It might be an interesting thing to discuss, but dynamic linking isn't a process which makes a work a copyrighted work or a derivative work or not a copyrighted work or not a derivative work. Dynamic linking does have something to do with the copyright status of a work, because it has something to do with the existence of the work -- and only works that exist get copyright protection. Similarly, the binding on a book has something to do with the copyright protection on that book. The binding serves to show that the book is a work as a whole. But
Re: GPL, yet again. (The kernel is a lot like a shared library)
Andrew Suffield [EMAIL PROTECTED] schrieb/wrote: On Fri, Sep 09, 2005 at 05:52:00PM +0200, Claus F?rber wrote: So one of the assumptions made above is wrong. The one where you assumed that dynamic linking was relevent. I've been saying that all along. You were also saying that C is probably a derivative of O: | I do not know how a program that really used openssl, calling its | functions, could avoid being a derivative. I can't rule it out but (The typical case for dynamic linking is that there are function calls.) For a high-level argumentation like mine, it does not matter whether the legal link between C and O is created by dynamic linking, incorporating function calls, or anything else, the result is always the same: If O can be replaced by M, the assumption that B/C is a derivative of O, must be wrong. (Of course, this is only true if you can make an M that is not a derivative of O either, which depends on wheter the interface is elegible for copyright.) Claus -- http://www.faerber.muc.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/12/05, Yorick Cool [EMAIL PROTECTED] wrote: [...] Well, either you consider the FSF's positions are authoritative and then you have to accept them all (including the dynamic linking business), or you admit you can depart with any of their assertions. And where can I find more details on this rather curious legal doctrine? [...] And, as an aside, in civil law at least, the court has full power as to how to qualify an act -- say it is a contract, or license, or whatever -- but is bound by the parties intent of the act's intended effects, in the limit of what the law allows. Oh yeah. As if FSF.org might sue me in my home EU court alleging GPL violation regarding linking... Dream on. They have no balls. But just in case... per Rome Convention on the law applicable to contractual obligations, I'll simply trigger straight-away US doctrine of copyright misuse (licensor's home law). Bye-bye FSF's copyrights on [L]GPL'd works. Long live [L]GPL-copyright impotent FSF. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Tue, Sep 13, 2005 at 09:51:29PM +0200, Alexander Terekhov wrote: And, as an aside, in civil law at least, the court has full power as to how to qualify an act -- say it is a contract, or license, or whatever -- but is bound by the parties intent of the act's intended effects, in the limit of what the law allows. Oh yeah. As if FSF.org might sue me in my home EU court alleging GPL violation regarding linking... Dream on. They have no balls. But just in case... per Rome Convention on the law applicable to contractual obligations, I'll simply trigger straight-away US doctrine of copyright misuse (licensor's home law). WTF? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Tue, Sep 13, 2005 at 09:51:29PM +0200, Alexander Terekhov wrote: Alexander On 9/12/05, Yorick Cool [EMAIL PROTECTED] wrote: Alexander [...] Alexander Well, either you consider the FSF's positions are authoritative and then you have to Alexander accept them all (including the dynamic linking business), or you admit Alexander you can depart with any of their assertions. Alexander Alexander And where can I find more details on this rather curious legal doctrine? It's called logic. Or consistency. Take your pick. Alexander And, as an aside, in civil law at least, the court has full power as to how to qualify an Alexander act -- say it is a contract, or license, or whatever -- but is bound by the parties intent Alexander of the act's intended effects, in the limit of what the law allows. Alexander Alexander Oh yeah. As if FSF.org might sue me in my home EU court alleging GPL violation Alexander regarding linking... Dream on. They have no balls. But just in case... per Rome Alexander Convention on the law applicable to contractual obligations, I'll Alexander simply trigger Alexander straight-away US doctrine of copyright misuse (licensor's home law). Bye-bye Alexander FSF's copyrights on [L]GPL'd works. Long live [L]GPL-copyright impotent FSF. You are aware that the FSF is not the only GPL licensor, right? -- Yorick Cool Chercheur au CRID Rempart de la Vierge, 5 B-5000 Namur Tel: + 32 (0)81 72 47 62 /+32 (0)81 51 37 75 Fax: + 32 (0)81 72 52 02 signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/14/05, Yorick Cool [EMAIL PROTECTED] wrote: [... FSF: assert(!is_contract(GPL)); ...] Alexander Well, either you consider the FSF's positions are authoritative and then you have to Alexander accept them all (including the dynamic linking business), or you admit Alexander you can depart with any of their assertions. Alexander Alexander And where can I find more details on this rather curious legal doctrine? It's called logic. Or consistency. Take your pick. I pick GPL Section 5. 5. You are not required to accept this License, since you have not signed it. Good. I'm not required to accept it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. That may be true in the GNU Republic. Exclusive distribution right is about copies (material objects), not works. 17 USC 117(a) does grant permission to modify and create private adaptations (go read CONTU). And 17 USC 109(a) states: Notwithstanding the provisions of section 106 (3), the owner of a particular copy or phonorecord lawfully made under this title, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord. These actions are prohibited by law if you do not accept this License. I suppose they mean some unwritten GNU law. I don't mind. Therefore, by modifying or distributing the Program ... I do nothing that requires acceptance (and imposes contractual obligations). Alexander And, as an aside, in civil law at least, the court has full power as to how to qualify an Alexander act -- say it is a contract, or license, or whatever -- but is bound by the parties intent Alexander of the act's intended effects, in the limit of what the law allows. Alexander Alexander Oh yeah. As if FSF.org might sue me in my home EU court alleging GPL violation Alexander regarding linking... Dream on. They have no balls. But just in case... per Rome Alexander Convention on the law applicable to contractual obligations, I'll Alexander simply trigger Alexander straight-away US doctrine of copyright misuse (licensor's home law). Bye-bye Alexander FSF's copyrights on [L]GPL'd works. Long live [L]GPL-copyright impotent FSF. You are aware that the FSF is not the only GPL licensor, right? Right. And? Hint: http://europa.eu.int/idabc/servlets/Doc?id=21197 (... Besides, too overbroad a viral effect ...) Those commission folks don't quite see the light regarding static linking yet... but that's correctable. regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 14, 2005 at 01:14:21AM +0200, Alexander Terekhov wrote: However, nothing else grants you permission to modify or distribute the Program or its derivative works. That may be true in the GNU Republic. Exclusive distribution right is about copies (material objects), not works. Contrary to popular belief, this list does not exist to serve as a safe haven for the legally delusional. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/14/05, Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Sep 14, 2005 at 01:14:21AM +0200, Alexander Terekhov wrote: However, nothing else grants you permission to modify or distribute the Program or its derivative works. That may be true in the GNU Republic. Exclusive distribution right is about copies (material objects), not works. Contrary to popular belief, this list does not exist to serve as a safe haven for the legally delusional. And who's legally delusional? Start with 17 USC 101. Copies are material objects. Works are intangible things fixed in copies. Fixation of work in a material object (brains and retinas aside for a moment) produces exact copy of that work. Got it? Now read 17 USC 106(3) and 109. Next we can talk about static linking and 117 (... Any exact copies prepared in accordance with the provisions of this section may be leased, sold, or otherwise transferred, along with the copy from which such copies were prepared, only as part of the lease, sale, ...) and downloading (I mean lawfully made copies from which such copies were prepared -- see above). quotes from dmca/sec-104-report-vol-2|3.pdf Red Hat, Inc.: Let me just clarify that I don't think anyone today intends to impact our licensing practices. I haven't seen anything in the comments, nor have I heard anything today that makes me think someone does have that intention. What we're concerned about are unintended consequences of any amendments to Section 109. The primary difference between digital and nondigital products with respect to Section 109 is that the former are frequently licensed. ... product is also available for free downloaded from the Internet without the printed documentation, without the box, and without the installation service. Many open source and free software products also embody the concept of copyleft. ... We are asking that amendments not be recommended that would jeopardize the ability of open source and free software licensor to require [blah blah] Time Warner, Inc.: We note that the initial downloading of a copy, from an authorized source to a purchaser's computer, can result in lawful ownership of a copy stored in a tangible medium. Library Associations: First, as conceded by Time Warner, digital transmissions can result in the fixation of a tangible copy. By intentionally engaging in digital transmissions with the awareness that a tangible copy is made on the recipient's computer, copyright owners are indeed transferring ownership of a copy of the work to lawful recipients. Second, the position advanced by Time Warner and the Copyright Industry Organizations is premised on a formalistic reading of a particular codification of the first sale doctrine. When technological change renders the literal meaning of a statutory provision ambiguous, that provision must be construed in light of its basic purpose and should not be so narrowly construed as to permit evasion because of changing habits due to new inventions and discoveries. Twentieth Century Music Corp. v. Aiken, 422 U.S. 151, 156-158 (1975). The basic purpose of the first sale doctrine is to facilitate the continued flow of property throughout society. http://www.copyright.gov/reports/studies/dmca/reply/Reply008.pdf regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Sun, Sep 11, 2005 at 11:20:51PM -0700, Michael K. Edwards wrote: Michael Are you saying these people are on record in believing that the GPL Michael works in the sense we are discussing -- forbidding the distribution, Michael on terms other than the GPL's, of code that uses a GPL library (or Michael other form of modular software component) through its published API? Michael Can you provide URLs or other citations to back this up? Especially Michael those that cite any actual law in support of their position? Actually, no. I was under the impression you were saying Moglen was the only one to consider that the GPL worked at all. I was apparently mistaken, and you were only referring to the linking problem. Regarding that, Lessig does support it, in either The future of Ideas or Free culture. Rosen is skeptical about the FSF's position and seems not to endorse it. AFAIK, MacGowan and Samuelson haven't voiced an opinion on the question. The other two (belgian law professors) are pretty mich convinced, mostly by my own article on the subject. The reasoning is pretty simple. As Sean said, it is based on the understanding that the GPL is a contract. As such, it has to be interpreted in the light of the parties intent. For those cases where the FSF is the licensor, the FSF's intent is clear and well known. When intent is unknown, we have to refer to common practice. That means that one has to refer to the perception specialists in the relevant field (in this case, free software developpers) understand things. Insofar as it is commonly held that the GPL requires that programs linking to GPL'ed libraries be licensed under the GPL, that requirement is to be considered part of the contract. I shall stress that this reasoning is held in belgian law, and should be applicable in most legal systems based on civil law. I will not voice an opinion regarding common law systems. Michael But no qualified source that I have yet found, other than those Michael directly affiliated with the FSF, seems to be willing to endorse the Michael dynamic linking ban any further than well, the FSF makes these Michael claims, and it's hard to tell what a court will think. I personally Michael don't think it's very hard to tell what a US court will think (at Michael least at the circuit court level and assuming competent lawyering) -- Michael it's pretty clear from cases like Lotus and Lexmark that attempts to Michael extend the copyright monopoly to forbid interoperation are frowned Michael upon. As far as I can tell (I'm not a programmer), the dynamic linking ban has very few to do with the Lexmark case for instance. Not being able to use shared libraries does not, AFAIK, stop you from making interoperable software, at worse it hinders pure integration, not interoperability. Let's not forget that in the Lexmark case, Lexmark was trying to stop another manufacturer from making ink cartidges for it's printers *at all*. The dynamic linking ban does not stop you from making programs using the libraries in the slightest. It only puts *one* condition on it. Quite a different case. And even if you don't use the library, you can still make a program interoperable with the target system, just write your own functions and what will you. And if that is too hard/expensive, then maybe your program would have been a derivative of the library after all... But again, I might be wrong on this. Michael It's particularly bad news when the legal monopoly is combined Michael with market dominance in a given niche -- and there are a number of Michael sectors in which the FSF and Microsoft have a near-total duopoly, and Michael where neither demonstrates any qualms about leveraging its advantages Michael to squeeze bit players out of neighboring niches. I'm not quite sure where you're going with your competition law references. There aren't that any areas I can think of in which I would say the FSF has significant market power. As to the OpenSSL case per se, it isn't clear enough for me to emit a judgement. -- Yorick Cool Chercheur au CRID Rempart de la Vierge, 5 B-5000 Namur Tel: + 32 (0)81 72 47 62 /+32 (0)81 51 37 75 Fax: + 32 (0)81 72 52 02 signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
** Raul Miller :: On 9/9/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Raul, 90% of your questions (below) are rethoric. Given the context, I haven't a clue what that means. This could be anywhere from begging the question to a desire to focus on some useful 10% of my questions. No, 90% of the questions are is this eligible for copyright protection?. Assume every work eligible for copyright protection, for the sake of the argument, and for $DEITY's sake. AND we're talking ONLY about dynamic linking. AND, to boot, that those bits that end up in a compiled work by way of being in a .h file (for instance) are not eligible for copyright protection. This is even more confusing. assume every work eligible for copyright protection...are not eligible for copyright protection? In principle, I ought to be able to figure out what you're saying by looking at the grammar of your sentences, but in this case I can't. I thought that one was simple: 1. please assume every work mentioned in the argument (unless otherwise noted) eligible for copyright protection; 2. please assume we are talking (unless otherwise noted) about dynamic linking; and 3. please assume that those bits that end up in a compiled work by way of being in .h file or any other similar thing are not eligible for copyright protection (this is an explicit exception to #1 above). One of the confusing things is where you say by way of being in a .h file (for instance). As an instance of what? Yes. one nice example are text of non-trivial inlined functions. If I start by assuming the conclusion you want to draw is correct, I can work backwords and fit the pieces together so they make sense, but that's not the same thing as these pieces being a valid argument that your conclusion is correct. All the assumptions above create a simplified model, that we can refine later -- if we can come to any conclusion at all. In other words, let's just start with the conclusion we want to draw? Oh well, on to the questions: ** Raul Miller :: On 09 Sep 2005 17:52:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. (Question: is B a derivative of M? For that matter is A a derivative of M? Is B a derivative of M? Is A a derivative of M? -- those are the million-dollar questions. I don't think so, because there is no intellectually-novel transformation of M that produces A or B. I'm trying to find an interpretation of this sentence that has some meaning and I'm clueless. As a general rule, all derivative works are produced by humans. As a general rule, when we talk about transformations we're talking about processes -- something outside the scope of copyright law (thought not outside the realm of human activity). Why is it outside the scope of copyright law? The copyright law itself defined a derivation as the result of said processes. 17USC enumerates some processes, and Brazilian Author's Rights acts defines them. What I'm not getting is how the presence or absence of some process which is outside the scope of copyright law has any bearing on the question of whether one work is a derivative work of some other work. The processes are not outside the scope of copyright law. [For now, I'm skipping sentences which seem to depend on this intellectually novel transformation sentence for their meaning.] Intellectualy novel transformation is the text of the code law that defines derivative work in Brasil. I suspect -- but I don't have the time right now to confirm -- that this text (which is already in one of my recent posts) is directly copied from the Geneva convention text. IOW, it's the letter of the law. for copyright protection?) 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. (M can be fully compatible with O without B being identical to C. And I've some other questions about the nature of B and C -- see above.) Imagine that B and C are actually the same program, and you'll see the argument. From my point of view, the technical features of a system (what gets linked against what, and what the system does, etc.) are not the deciding factors. They're just evidence about what the nature of the creative work under discussion. Evidence, in and of itself, does not decide the case. Evidence just paints a part of the picture. I fail to see the correlation of the paragraph above and the argument above it. In other words, B and C could actually be the same program where B is an
Re: GPL, yet again. (The kernel is a lot like a shared library)
Yorick Cool wrote: [...] The reasoning is pretty simple. As Sean said, it is based on the understanding that the GPL is a contract. Yeah. Except that everybody and his dog knows that the FSF's position is that GPL != contract. Moglen and RMS now call it The Constitution (of the GNU Republic, I suppose). http://groups.google.com/group/gnu.misc.discuss/msg/41227555ca18833b C'mon, the GPL drafter RMS is on record: http://groups.google.com/group/gnu.misc.discuss/msg/8464781e78e421cb regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Mon, Sep 12, 2005 at 09:22:27PM +0200, Alexander Terekhov wrote: Alexander Yorick Cool wrote: Alexander On Fri, Sep 09, 2005 at 02:32:13PM -0700, Michael K. Edwards wrote: Alexander Michael On 9/9/05, Andrew Suffield [EMAIL PROTECTED] wrote: Alexander Michael I am acutely disinterested in that debate because it's long and Alexander Michael boring, but there's a lot of law professors who like it and think that Alexander Michael the GPL does work. I suggest you go argue with them instead. Alexander Michael Alexander Michael Name one other than Mr. Moglen. Alexander Alexander Larry Lessig? Alexander Alexander CC share-alike licenses don't try to infect compilations (collective Alexander works). So? That changes nothing to the fact Lessig considers the GPL -- the license we're talking about -- covers dynamic linking. Alexander Alexander Larry Rosen? I said myself that he was skeptical of the FSF's positions. -- Yorick Cool Chercheur au CRID Rempart de la Vierge, 5 B-5000 Namur Tel: + 32 (0)81 72 47 62 /+32 (0)81 51 37 75 Fax: + 32 (0)81 72 52 02 signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Mon, Sep 12, 2005 at 09:39:14PM +0200, Alexander Terekhov wrote: Alexander Yorick Cool wrote: Alexander [...] Alexander The reasoning is pretty simple. As Sean said, it is based on the Alexander understanding that the GPL is a contract. Alexander Alexander Yeah. Except that everybody and his dog knows that the FSF's Alexander position is that GPL != contract. Moglen and RMS now call it Alexander The Constitution (of the GNU Republic, I suppose). Well, either you consider the FSF's positions are authoritative and then you have to accept them all (including the dynamic linking business), or you admit you can depart with any of their assertions. In this case, the FSF's opinion notwithstanding, the GPL is a contract, there is no solid legal reasoning to suggest otherwise. On the linking issue, there are arguments for both positions. And, as an aside, in civil law at least, the court has full power as to how to qualify an act -- say it is a contract, or license, or whatever -- but is bound by the parties intent of the act's intended effects, in the limit of what the law allows. Alexander C'mon, the GPL drafter RMS is on record: When he speaks as it's drafter, he has no authority, legally speaking -- expect if his view reflects common practice. If he speaks as a licensor, his view is authoritative insofar as it is accepted by the licensee. -- Yorick Cool Chercheur au CRID Rempart de la Vierge, 5 B-5000 Namur Tel: + 32 (0)81 72 47 62 /+32 (0)81 51 37 75 Fax: + 32 (0)81 72 52 02 signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/12/05, Yorick Cool [EMAIL PROTECTED] wrote: [...] Alexander Larry Lessig? Alexander Alexander CC share-alike licenses don't try to infect compilations (collective Alexander works). So? That changes nothing to the fact Lessig considers the GPL -- the license we're talking about -- covers dynamic linking. Apropos Lessig... I just wonder what he thinks about allegedly fabricated/garbled* responses from RMS and Moglen regarding derivative works and linking that you can find in the paper that was written for him (upon his request, I'd guess) by Matt Asay. http://www.linuxdevices.com/files/misc/asay-paper.pdf (by Matt Asay, written for Professor Larry Lessig) *) http://xfree86.org/pipermail/forum/2004-March/004301.html http://xfree86.org/pipermail/forum/2004-April/004306.html http://xfree86.org/pipermail/forum/2004-April/004308.html http://xfree86.org/pipermail/forum/2004-April/004309.html http://xfree86.org/pipermail/forum/2004-April/004321.html http://xfree86.org/pipermail/forum/2004-April/004353.html http://xfree86.org/pipermail/forum/2004-April/004358.html http://xfree86.org/pipermail/forum/2004-April/004384.html regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
Michael K. Edwards wrote: [...] I will grant you Lawrence Lessig even though a few minutes' Googling http://www.google.com/search?q=Lessig+GPL+insane yields http://weblog.ipcentral.info/archives/2005/02/thoughts_on_sof.html Quite refreshing. ;-) quote Similar concerns from an another lawyer: What composes a derivative work of software under copyright law is one of almost complete opacity. Add that to the ambiguous language of the GPL, referring only in part to derivative works, and the result is absolute opacity, or in your words, absolute vagueness, or in Lessig's words, insane complexity. Is the SFLC going to legally clarify this issue of derivative, especially in cases where they raise the spectre of criminal infringement charges? Will the SFLC create some guidelines do provide notice which combinations are subject to copyright and which ones are per-empted by patents? I doubt so. They like using copyright laws that help their cause (102a), and like ignoring copyright laws that hurt their cause (102b). After all, ignoring the law is one thing anarchists like. To quote Eben Moglen: This use of intellectual property rules to create a commons in cyberspace is the central institutional structure enabling the anarchist triumph. http://emoglen.law.columbia.edu/my_pubs/anarchism.html I would like to know why law-abiding companies like IBM and Intel, which fund the OSDL which funds the SFLC, why such law-abiding companies are funding those espousing anarchist goals? Are they going to create a defense fund for software pirates next - pirates are anarchists as well? /quote Seriously (apropos per-empted by patents), see also http://www.innovationlaw.org/lawforum/pages/heer.doc (The Case against Copyright Protection of Non-literal Elements of Computer Software) quote Altai has been viewed as a landmark decision as it incorporates many traditional principles of copyright law into a single analytical framework seemingly suitable for computer software. However, when honestly applied, the abstraction-filtration- comparison test eliminates protection for computer programs by entirely filtering out not only the individual elements of computer programs such as software objects but also the compilation of selection and arrangement expression that is the program's structure, since both are designed with efficiency in mind. [...] It is more appropriate to consider the software objects of a computer program as analogous to the gears, pulleys, and levers of a mechanical invention, as by its very nature, the design of computer software is intended to optimize functionality by making a program run faster, use less memory, or be easier for the programmer to modify. When viewed as a collection of software objects combined in such a way as to optimally perform various tasks, the design of computer software closely resembles the design of functional devices protected by patent law rather than the non-functional, non-literal elements of creative authorial works protected under copyright law. /quote regards, alexander.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Fri, Sep 09, 2005 at 02:32:13PM -0700, Michael K. Edwards wrote: Michael On 9/9/05, Andrew Suffield [EMAIL PROTECTED] wrote: Michael I am acutely disinterested in that debate because it's long and Michael boring, but there's a lot of law professors who like it and think that Michael the GPL does work. I suggest you go argue with them instead. Michael Michael Name one other than Mr. Moglen. Larry Lessig? Larry Rosen? Séverine Dussollier? Etienne Montero? Dave MacGowan? Pam Samuelson? -- Yorick Cool Chercheur au CRID Rempart de la Vierge, 5 B-5000 Namur Tel: + 32 (0)81 72 47 62 /+32 (0)81 51 37 75 Fax: + 32 (0)81 72 52 02 signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/9/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: Raul, 90% of your questions (below) are rethoric. Given the context, I haven't a clue what that means. This could be anywhere from begging the question to a desire to focus on some useful 10% of my questions. Assume every work eligible for copyright protection, for the sake of the argument, and for $DEITY's sake. AND we're talking ONLY about dynamic linking. AND, to boot, that those bits that end up in a compiled work by way of being in a .h file (for instance) are not eligible for copyright protection. This is even more confusing. assume every work eligible for copyright protection...are not eligible for copyright protection? In principle, I ought to be able to figure out what you're saying by looking at the grammar of your sentences, but in this case I can't. One of the confusing things is where you say by way of being in a .h file (for instance). As an instance of what? If I start by assuming the conclusion you want to draw is correct, I can work backwords and fit the pieces together so they make sense, but that's not the same thing as these pieces being a valid argument that your conclusion is correct. All the assumptions above create a simplified model, that we can refine later -- if we can come to any conclusion at all. In other words, let's just start with the conclusion we want to draw? Oh well, on to the questions: ** Raul Miller :: On 09 Sep 2005 17:52:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. (Question: is B a derivative of M? For that matter is A a derivative of M? Is B a derivative of M? Is A a derivative of M? -- those are the million-dollar questions. I don't think so, because there is no intellectually-novel transformation of M that produces A or B. I'm trying to find an interpretation of this sentence that has some meaning and I'm clueless. As a general rule, all derivative works are produced by humans. As a general rule, when we talk about transformations we're talking about processes -- something outside the scope of copyright law (thought not outside the realm of human activity). What I'm not getting is how the presence or absence of some process which is outside the scope of copyright law has any bearing on the question of whether one work is a derivative work of some other work. [For now, I'm skipping sentences which seem to depend on this intellectually novel transformation sentence for their meaning.] for copyright protection?) 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. (M can be fully compatible with O without B being identical to C. And I've some other questions about the nature of B and C -- see above.) Imagine that B and C are actually the same program, and you'll see the argument. From my point of view, the technical features of a system (what gets linked against what, and what the system does, etc.) are not the deciding factors. They're just evidence about what the nature of the creative work under discussion. Evidence, in and of itself, does not decide the case. Evidence just paints a part of the picture. In other words, B and C could actually be the same program where B is an independent work, where B is a derivative of O, or where B is a derivative of M or where B is a derivative of both O and M. Now, obviously, other facts about these cases would have to be different for each of these possibilities. And there's plenty of room to argue about exactly where the boundaries between these cases would be. And, there's potential to argue about what licenses on these works would mean in each of these different cases. I can see other things which rather obviously could be wrong. But there's too few details here to really say for sure. Hope I enlightened you. I don't think I've been enlightened. Unless your point was that I should assume the conclusion so that the argument makes sense. Well, you can replace Debian can't distribute C by Debian can't distribute C unless M is available. But this is very strange as it would mean that the advent of M changes the copyright status of C, which is actually derieved from A and O. One of the issues here is that in the typical case the advertising clause isn't enforced, nor is it enforceable. So, in the typical case, it isn't a restriction on redistribution, and can't be a problem with the GPL. Not relevant. Suppose advertising clause enforceable and actively enforced. I'm interested in what you mean by relevant here. Do you mean
RE: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa Guimar?es wrote: If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. That doesn't No, you are not telling me why my argument is broken. If you are trying, you're not being very clear. Why is my argument broken exactly? require a counter-argument in this case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Andrew Suffield [EMAIL PROTECTED] schrieb/wrote: You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. You are actually creating straw mans which are broken. The original argument isn't. The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. 2. Library O is licensed under the a BSD-like license, which contains an advertisting clause. = Debian can still distribute O. Program C is a derivative of A, which dynamically links against O. = Debian can't distribute C. 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. So one of the assumptions made above is wrong. The only assumption that is not obviously right is: Debian can't distribute C. Well, you can replace Debian can't distribute C by Debian can't distribute C unless M is available. But this is very strange as it would mean that the advent of M changes the copyright status of C, which is actually derieved from A and O. Claus -- http://www.faerber.muc.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 09 Sep 2005 17:52:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. (Question: is B a derivative of M? For that matter is A a derivative of M? Is A+M a work eligible for copyright protection? Is B+M a work eligible for copyright protection?) 2. Library O is licensed under the a BSD-like license, which contains an advertisting clause. = Debian can still distribute O. Program C is a derivative of A, which dynamically links against O. = Debian can't distribute C. (Question: is C a derivative of O? Is C+O a work eligible for copyright protection?) 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. (M can be fully compatible with O without B being identical to C. And I've some other questions about the nature of B and C -- see above.) So one of the assumptions made above is wrong. The only assumption that is not obviously right is: Debian can't distribute C. I can see other things which rather obviously could be wrong. But there's too few details here to really say for sure. Well, you can replace Debian can't distribute C by Debian can't distribute C unless M is available. But this is very strange as it would mean that the advent of M changes the copyright status of C, which is actually derieved from A and O. One of the issues here is that in the typical case the advertising clause isn't enforced, nor is it enforceable. So, in the typical case, it isn't a restriction on redistribution, and can't be a problem with the GPL. Further, in the cases where it could be an issue, it's likely a trademark issue rather than a copyright issue, so it's still not a restriction on redistribution. Unless... well, we probably could cook up a hypothetical case where this advertising clause is a copyright problem. But your above presentation has enough problems even without this kind of hypothesis. Put differently, what you're probably arguing is that there are programs (and libraries) which don't have much creativity in them, and so aren't eligible for more than an absolute minimum of protection. But this kind of argument is rather specific to those kinds of programs and those kinds of libraries. You might even argue that most programs (or libraries, or exported elements of libraries, or code bases, or whatever) are lacking in creativity, but this argument can never apply to all programs/libraries. -- Raul
Re: GPL, yet again. (The kernel is a lot like a shared library)
Raul, 90% of your questions (below) are rethoric. Assume every work eligible for copyright protection, for the sake of the argument, and for $DEITY's sake. AND we're talking ONLY about dynamic linking. AND, to boot, that those bits that end up in a compiled work by way of being in a .h file (for instance) are not eligible for copyright protection. All the assumptions above create a simplified model, that we can refine later -- if we can come to any conclusion at all. ** Raul Miller :: On 09 Sep 2005 17:52:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. (Question: is B a derivative of M? For that matter is A a derivative of M? Is B a derivative of M? Is A a derivative of M? -- those are the million-dollar questions. I don't think so, because there is no intellectually-novel transformation of M that produces A or B. The GPL text would think it is -- at least for its own a work based on the Program definition of a derivative work IFF we were talking about static linking, which we're not. AT LEAST NOT INTRINSECALLY (sorry for the caps, but this is important -- there *is* the possibility of A or B being derivative works of M, but for this to be determined the criteria of abstraction, filtration, comparison would have to be fullfilled -- for the sake of our simplification, we assume NOT: like a program that uses SHA1() and MD5() is NOT a derivative work of OpenSSL and a program that uses printf() is NOT a derivative work of glibc) Is A+M a work eligible for copyright protection? Is B+M a work eligible for copyright protection?) 2. Library O is licensed under the a BSD-like license, which contains an advertisting clause. = Debian can still distribute O. Program C is a derivative of A, which dynamically links against O. = Debian can't distribute C. (Question: is C a derivative of O? Is C+O a work eligible See above. for copyright protection?) 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. (M can be fully compatible with O without B being identical to C. And I've some other questions about the nature of B and C -- see above.) Imagine that B and C are actually the same program, and you'll see the argument. So one of the assumptions made above is wrong. The only assumption that is not obviously right is: Debian can't distribute C. I can see other things which rather obviously could be wrong. But there's too few details here to really say for sure. Hope I enlightened you. Well, you can replace Debian can't distribute C by Debian can't distribute C unless M is available. But this is very strange as it would mean that the advent of M changes the copyright status of C, which is actually derieved from A and O. One of the issues here is that in the typical case the advertising clause isn't enforced, nor is it enforceable. So, in the typical case, it isn't a restriction on redistribution, and can't be a problem with the GPL. Not relevant. Suppose advertising clause enforceable and actively enforced. Further, in the cases where it could be an issue, it's likely a trademark issue rather than a copyright issue, so it's still not a restriction on redistribution. Unless... well, we probably could cook up a hypothetical case where this advertising clause is a copyright problem. But your above presentation has enough problems even without this kind of hypothesis. Please, back to the subject, so we can construct a coherent thinking framework... Put differently, what you're probably arguing is that there are programs (and libraries) which don't have much creativity in them, and so aren't eligible for more than an absolute minimum of protection. But this kind of argument is rather specific to those kinds of programs and those kinds of libraries. No! Is glibc below your line of don't have much creativity? or OpenSSL? It's not below my line. The problem /in/ /casu/ is: can a GPLd program that dynamic links with a GPL-imcompatible-licensed library be distributed at all? Especially if there is another, fully compatible, GPLd, library that is distributed in the same set as the program and the library? You might even argue that most programs (or libraries, or exported elements of libraries, or code bases, or whatever) are lacking in creativity, but this argument can never apply to all programs/libraries. I never said any of this, nor did Claus. -- HTH, Massa
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Fri, Sep 09, 2005 at 05:52:00PM +0200, Claus F?rber wrote: So one of the assumptions made above is wrong. The one where you assumed that dynamic linking was relevent. I've been saying that all along. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Fri, Sep 09, 2005 at 09:54:04AM -0300, Humberto Massa Guimar?es wrote: On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa Guimar?es wrote: If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. That doesn't No, you are not telling me why my argument is broken. If you are trying, you're not being very clear. Why is my argument broken exactly? By trivially continuing it to the next obvious point, it concludes that the GPL doesn't work. Therefore it's broken somewhere. Figuring out where is left as an exercise for the students. I really don't care about the details. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
[EMAIL PROTECTED] (Claus Färber) writes: Andrew Suffield [EMAIL PROTECTED] schrieb/wrote: You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. You are actually creating straw mans which are broken. The original argument isn't. The argument, simplified, basically goes like this: 1. Program A is licensed under the GPL. = Debian can distribute A. Library M is licensed under the GPL. = Debian can distribute M. Program B is a derivative of A, which dynamically links against M. = Debian can distribute B. 2. Library O is licensed under the a BSD-like license, which contains an advertisting clause. = Debian can still distribute O. Program C is a derivative of A, which dynamically links against O. = Debian can't distribute C. 3. Library M is fully compatible to O. So programs B and C are actually identical. = Debian can and can't distribute B/C at the same time. = This can't be right. So one of the assumptions made above is wrong. The only assumption that is not obviously right is: Debian can't distribute C. Well, you can replace Debian can't distribute C by Debian can't distribute C unless M is available. But this is very strange as it would mean that the advent of M changes the copyright status of C, which is actually derieved from A and O. This is the argument that has been rehashed here countless times. Each time, the reply has been something like you're wrong, with no explanations whatsoever. I can only take this to mean that they are out of real arguments, but refuse to admit it, just like the FSF themselves. I'm giving up this discussion for now, until people perhaps decide to start using logic and reason, rather than philosophy and religion to reach their conclusions. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Andrew Suffield [EMAIL PROTECTED] writes: On Fri, Sep 09, 2005 at 09:54:04AM -0300, Humberto Massa Guimar?es wrote: On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa Guimar?es wrote: If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. That doesn't No, you are not telling me why my argument is broken. If you are trying, you're not being very clear. Why is my argument broken exactly? By trivially continuing it to the next obvious point, it concludes that the GPL doesn't work. Therefore it's broken somewhere. Figuring out where is left as an exercise for the students. I really don't care about the details. Ah, but this is based on the assumption that the GPL actually does work. The argument was intended to show that it doesn't, and apparently succeeds at this. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Fri, Sep 09, 2005 at 09:30:17PM +0100, M?ns Rullg?rd wrote: No, you are not telling me why my argument is broken. If you are trying, you're not being very clear. Why is my argument broken exactly? By trivially continuing it to the next obvious point, it concludes that the GPL doesn't work. Therefore it's broken somewhere. Figuring out where is left as an exercise for the students. I really don't care about the details. Ah, but this is based on the assumption that the GPL actually does work. The argument was intended to show that it doesn't, and apparently succeeds at this. I am acutely disinterested in that debate because it's long and boring, but there's a lot of law professors who like it and think that the GPL does work. I suggest you go argue with them instead. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/9/05, Andrew Suffield [EMAIL PROTECTED] wrote: I am acutely disinterested in that debate because it's long and boring, but there's a lot of law professors who like it and think that the GPL does work. I suggest you go argue with them instead. Name one other than Mr. Moglen. - Michael
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 07, 2005 at 04:08:51PM -0700, Mark Rafn wrote: On Wed, 7 Sep 2005, Joe Smith wrote: It is generally belived that the GPL 'derivative' clauses may actually be upheld in the case of static libraries. The fact that linking the .o's of the library directly with your program is equivelent to linking the library with the object files of your program, seems to verify this. The question still debated is whether Shared libraries are like this also. I haven't heard it debated very hotly in recent memory. General acceptance seems to be that it applies equally to static and dynamic linking. Dynamic linking DOES open up the possibility of distributing the using code and not distributing the library itself. The combination of the two may be un-distributable, however. Notice that the important thing here is not wheter the files are linked together and how, but wheter the combined work of them results in a derivative work, the way things are linked is only a technical detail of it, and the barrer to derivative works is a well defined interface between them or something such. The linux kernel 'copying' file states this: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. If that statement is true and if it does not qualify as a licence exception, then the following argument would hold: I think this is a license exception (or at least a clarification that applies specifically to this work). It is not a statement about GPL-licensed work in general. To quote RMS (this morning on the OpenSolaris list : The user programs link with libc but not directly with the kernel. People generally consider the kernel and libc not to be one combined program, so the GPL will not have effects across that boundary. Friendly, Sven LUther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Sean Kellogg [EMAIL PROTECTED] writes: The thing is that the kernel is indeed much like a library, but not like a static one. The kernel is a lot like a shared library in that it exists in memory, and has functions that can be called. It is different mainly in that it stays in memory, and on some architectures has special capabilities not available to regular shared libraries. Note that it is not different by being a critical part of the operating system, as other libraries, especially things like the c library, or even the runtime linking library (ld.so) I've written about this very issue in law school. It seems to me there are two ways to view the issue. One is that the GPL is a Contract (*shudder*) and thus the parties are free to restrict what is done with code they distribute. Consider it a contract that says you can have this code, but only if you free the code you combine it with... otherwise you can't have the code That is a perfectly fine contract, mutual promises and all. However, many say that the GPL is not a contract and must be considered a pure license and the sole product of copyright law. If so, then the GPL can only exercise power over (s)106 rights (US copyright law). Any item outside of those rights cannot be controlled by the license. The GPL tries to do this by claiming a derived work or out-and-out copying. I think you very much hit it on the head by asking whether it is either... and based on my understanding of what is and is not a derivative work, what constitutes copying, and applicable caselaw, I don't think it is. But then again, I think the GPL is a contract... so I don't see it as much of a problem. Even if the GPL is a contract, it doesn't matter. Read section 0: 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The Program, below, refers to any such program or work, and 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. (Hereinafter, translation is included without limitation in the term modification.) Each licensee is addressed as you. Note particularly the phrase derivative work under copyright law. Whatever terms the parties of the contract agree to, they apply only to the program itself and the aforementioned derivatives, specifically not other programs that merely use the code covered by the contract. The contradictory rephrasing following the colon doesn't pose any problems either, as a program dynamically linked to a library doesn't contain the library, or any parts of it. All it does is makes reference to it, and does so in a very non-specific way. The section continues: 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). Whether that is true depends on what the Program does. The phrase running the Program is not directly applicable to a library, so we have to assume that for libraries, this translates into using the library, i.e. causing its code to be run, typically by running a program that uses the library. This act being unrestricted per the quoted paragraph, it follows that any program can link with a GPL library, no matter what license that program has. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
* Måns Rullgård: The phrase running the Program is not directly applicable to a library, so we have to assume that for libraries, this translates into using the library, i.e. causing its code to be run, typically by running a program that uses the library. This act being unrestricted per the quoted paragraph, it follows that any program can link with a GPL library, no matter what license that program has. This only supports the widely held belief that you can do what you want with GPLed software inside your own four walls, without thinking too much about copyright issues. (I think this is quite an important freedom!) Usually, the interesting question is if you are permitted to distribute the linked program, and if dynamic linking makes a difference.
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 10:27:20AM +0200, Florian Weimer wrote: * Måns Rullgård: The phrase running the Program is not directly applicable to a library, so we have to assume that for libraries, this translates into using the library, i.e. causing its code to be run, typically by running a program that uses the library. This act being unrestricted per the quoted paragraph, it follows that any program can link with a GPL library, no matter what license that program has. This only supports the widely held belief that you can do what you want with GPLed software inside your own four walls, without thinking too much about copyright issues. (I think this is quite an important freedom!) Indeed, the GPL only applies to redistribution, this is a widely known fact. And you only have to redistribut the source to the ones you are giving the binaries to, not the world at large. Usually, the interesting question is if you are permitted to distribute the linked program, and if dynamic linking makes a difference. nope, the only difference between dynamic linking and static linking is if you use the LGPL. I am told that also the distribution of something in the sole intent of being linked with GPL code, is already problematic, but that is up to interpretation i guess. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
** Mark Rafn :: On Wed, 7 Sep 2005, Joe Smith wrote: It is generally belived that the GPL 'derivative' clauses may actually be upheld in the case of static libraries. The fact that linking the .o's of the library directly with your program is equivelent to linking the library with the object files of your program, seems to verify this. The question still debated is whether Shared libraries are like this also. I haven't heard it debated very hotly in recent memory. General acceptance seems to be that it applies equally to static and dynamic linking. Dynamic linking DOES open up the possibility of distributing the using code and not distributing the library itself. The combination of the two may be un-distributable, however. One of two apply: either both Michael K. Edwards and I are in your killfile OR you haven't payed a lot of attention lately. My (and his) argument goes more or less like this: 1. GPL section 0 defines the expression a work based on the Program, which will be used in the rest of the license as being either the Program or any derivative work under copyright law; after that, it paraphrases (separating the explanation with a colon) trying to explain what a derivative work is under copyright law, and failing, because it says 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. which is blatantly false, because the definition of a derivative work is the work that results on an intellectually-novel transformation over the original work. 1.1. this leads me to the conclusion that (1) above defines a work based on the Program as a synonym for a derivative work of the Program (or the Program itself). 2. GPL section 0, paragraph 1 states that 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. Hold on to your hats and I'll mention this later. 3. GPL section 2, paragraph 3 states that mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3.1. this leads me to the conclusion that, even if at some point in time (run-time) the works (GPL-incompatible library and GPLd program, for instance) will be combined to form interdependent chunks of computer memory, as the program is NOT a derivative work of the library nor vice-versa, distributing in the same CD, website, or whatever both the program package and the library package will invoke section 2 paragraph 3, because they are not interdependent in the moment of the distribution. 3.2. and, in the light of (2) above, this is even not contributory infringement, because the GPL section 0 paragraph 1 _explicitly_ licenses the final user to do what he needs to _use_ the program. 3.3. it seems to me that it's absurd to think, for instance, that Debian cannot dynamic link a GPLd program with OpenSSL. Why? Because if I write a completely-compatible MassaSSL library and install it in my system just in the same places/names/sonames/whatever OpenSSL is installed, this would change the copyright status of _the_ _program_!! Because of the argument above, I don't think the combination of the two would be undistributable at all. Why is all that different in the case of static linking? Because in the case of static linking, the intermingled executable can be considered (altough I don't think so) not merely aggregated, as the fixups are already resolved, etc, etc. The linux kernel 'copying' file states this: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. If that statement is true and if it does not qualify as a licence exception, then the following argument would hold: I think this is a license exception (or at least a clarification that applies specifically to this work). It is not a statement about GPL-licensed work in general. In this, you are right. NOTE! The GPL does *not* cover programs that use shared library services by normal function calls - this is merely considered normal use of the shared library, and does *not* fall under the heading of derived work. The copyright holder of a given library would have to make that statement for the library in question for it to apply. Agreed. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 01:22:07PM -0300, Humberto Massa Guimar?es wrote: 3.3. it seems to me that it's absurd to think, for instance, that Debian cannot dynamic link a GPLd program with OpenSSL. Why? Because if I write a completely-compatible MassaSSL library and install it in my system just in the same places/names/sonames/whatever OpenSSL is installed, this would change the copyright status of _the_ _program_!! This says that there can be no such thing as copyright infringement for creating a derivative of a piece of software, because you can always replace the original with a reimplementation that wouldn't be infringement. While it may be an interesting legal theory that copyright infringement in software can only apply to verbatim copying (and one that has been proposed before by various crackpots), I would not like to rely on it in court, because it's absurd. I'll leave it as an exercise for the students to find where the argument went wrong; the mere existence of a flawed conclusion is enough to convince me that it went wrong *somewhere*. Go back and do it again in a manner that concludes derivative works are normally infringement, and explains why this case is different. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 07, 2005 at 06:50:00PM -0400, Joe Smith wrote: While I would like to belive that the FSF knew exactly what they were doing, I am not certain. It is generally belived that the GPL 'derivative' clauses may actually be upheld in the case of static libraries. The fact that linking the .o's of the library directly with your program is equivelent to linking the library with the object files of your program, seems to verify this. The question still debated is whether Shared libraries are like this also. It's the wrong question. This is a FAQ here. Stop thinking about libraries. Libraries are not relevant. You're getting misled by technial details of how libraries are implemented, when in fact the whole issue is a red herring. Start thinking about source. The question you need to ask yourself is: Is this piece of software, in source form, a derivative of openssl? If it has been written to include and extend the behaviour of openssl by calling its functions - for example, the piece of software is an implementation of HTTPS, an SSL-derived protocol - then the source is probably a derivative of openssl. The shared library form is then trivially a derivative because it's a transformation of the source, but we don't actually care about that - the fact that the source is a derivative is enough to be a blocking issue. You will note that this allows for the possibility of software linked to openssl that is not a derivative of it. The trivial example is to take a copy of GNU hello, and add -lssl to LDFLAGS. That doesn't make it a derivative of openssl. You will also note that this excludes the possibility of being able to evade copyright law via technicalities of how you build the software. That's an expected property of a well-formulated law. I do not know how a program that really used openssl, calling its functions, could avoid being a derivative. I can't rule it out but I've never seen a plausible argument for it and I can't imagine what one would look like. If anybody wants to try arguing that case here, expect it to be a really hard sell. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
** Andrew Suffield :: On Thu, Sep 08, 2005 at 01:22:07PM -0300, Humberto Massa Guimar?es wrote: 3.3. it seems to me that it's absurd to think, for instance, that Debian cannot dynamic link a GPLd program with OpenSSL. Why? Because if I write a completely-compatible MassaSSL library and install it in my system just in the same places/names/sonames/whatever OpenSSL is installed, this would change the copyright status of _the_ _program_!! This says that there can be no such thing as copyright infringement for creating a derivative of a piece of software, because you can always replace the original with a reimplementation that wouldn't be infringement. my knowledge of the English language is still worse than I tought, because I do not have any recollection of meaning what you said _at_ _all_. Remember: DERIVATIVE == TRANSFORMATION. While it may be an interesting legal theory that copyright infringement in software can only apply to verbatim copying (and one that has been proposed before by various crackpots), I would not like to rely on it in court, because it's absurd. I have not said _at_ _all_ something absurd as you state in your paragraph above. Calling me (directly or indirectly) a crackpot will not change this. I do know what I'm talking about and I think you are not being polite. I'll leave it as an exercise for the students to find where the argument went wrong; the mere existence of a flawed conclusion is enough to convince me that it went wrong *somewhere*. Go back and do it again in a manner that concludes derivative works are normally infringement, and explains why this case is different. The problem here is that you got to a flawed conclusion that I did not state at all, so the error resides entirely in your parser, AFAIK. You seem to be saying that if a program has x = MD5(a, b, c, d); in its text, then it *is* a derivative work of OpenSSL. What I said is exactly the opposite of this: the presence of the above line does not imply at all that some program is an OpenSSL derivative. And it's not. The usage of a library by a program does NOT transform said library in ANY aspect. My point is exactly that, throughout all my argument: a work based on the Program == derivative work under copyright law == the result of an intellectualy-novel transformation applied over the original work. Usage of a library, especially thru its published API != transformation applied over the library == usage of a library != a work based on the Program == usage of a library != said library must be GPL-compatible Maybe my English was clearer now? Mind you, the problem with ike-scan (today on-list) was exactly this: it (optionally) calls MD5 and/or SHA1 from OpenSSL, offering an alternative implementation if OpenSSL is not available (OpenSSL's implementation being better performant). No court that I know of would regard ike-scan as being a derivative work (nor a work based on) OpenSSL. And I had my share of court work. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
** Andrew Suffield ::
On Wed, Sep 07, 2005 at 06:50:00PM -0400, Joe Smith wrote:
While I would like to belive that the FSF knew exactly what they
were doing, I am not certain.
It is generally belived that the GPL 'derivative' clauses may
actually be upheld in the case of static libraries. The fact
that linking the .o's of the library directly with your program
is equivelent to linking the library with the object files of
your program, seems to verify this.
The question still debated is whether Shared libraries are like
this also.
It's the wrong question. This is a FAQ here.
Stop thinking about libraries. Libraries are not relevant. You're
getting misled by technial details of how libraries are
implemented, when in fact the whole issue is a red herring. Start
thinking about source.
The question you need to ask yourself is: Is this piece of
software, in source form, a derivative of openssl?
Up to this point, you are 100% correct.
If it has been written to include and extend the behaviour of
openssl by calling its functions - for example, the piece of
software is an implementation of HTTPS, an SSL-derived protocol -
then the source is probably a derivative of openssl.
NO Please, no!!! Never !!! Substitute that for:
If it has be written applying any kind of intellectually-novel
(which rules out *any* kind of automated/automatable) TRANSFORMATION
over the source code of OpenSSL -- for instance, assuming OpenSSL is
written in C, if you port function-by-function the code to Pascal,
having to think and apply your craft in the art of programming to do
so, then the source is a derivative of openssl.
What you said is false, and its falsehood is trivially demonstrated
-- imagine the following C program:
#include stdio.h
int search_ascii_for_my_name_amongst_the_digits_of_pi(char *name) {
//... non-trivial implementation here.
}
int main(int argc, char **argv) {
printf(hello, %s!\nyour name is in the %dth digit of pi!\n,
argv[1],
search_ascii_for_my_name_amongst_the_digits_of_pi(argv[1]));
return 0;
}
-- end
the program above includes and extends the functionality of libc, by
calling its functions to make it print your name (given to it in the
command-line) and where is the ascii for your name in pi. It's a
derivative work of libc, as per your reasoning. Ah, but which libc?
MSVCRT? BSD libc? glibc?
The shared library form is then trivially a derivative because
it's a transformation of the source, but we don't actually care
about that - the fact that the source is a derivative is enough to
be a blocking issue.
Beware of the use of transformation here... transformation of
source into binary form (static, shared, library, program) is NOT
intellectually-novel. Does _not_ generate a new copyrightable work,
the work is still the same, it does just generate a copy that is in
another format.
You will note that this allows for the possibility of software
linked to openssl that is not a derivative of it. The trivial
example is to take a copy of GNU hello, and add -lssl to
LDFLAGS. That doesn't make it a derivative of openssl.
hello is not derivative of openssl even if you make it print the MD5
and SHA1 of the string hello, world., as calculated by openssl.
No intellectually-novel transformation was applied over openssl.
You will also note that this excludes the possibility of being
able to evade copyright law via technicalities of how you build
the software. That's an expected property of a well-formulated
law.
Yes. And this is exactly WHY you are wrong. If my program above
could be deemed a derivative work on MSVCRT, this would open a
Pandora box.
I do not know how a program that really used openssl, calling its
functions, could avoid being a derivative. I can't rule it out but
Because you seem not to know what a derivative is. I repeat, and I
refer you to 17USC: transformation, transformation and
transformation.
I've never seen a plausible argument for it and I can't imagine
what one would look like. If anybody wants to try arguing that
case here, expect it to be a really hard sell.
--
HTH,
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thursday 08 September 2005 10:22 am, Andrew Suffield wrote: On Wed, Sep 07, 2005 at 06:50:00PM -0400, Joe Smith wrote: While I would like to belive that the FSF knew exactly what they were doing, I am not certain. It is generally belived that the GPL 'derivative' clauses may actually be upheld in the case of static libraries. The fact that linking the .o's of the library directly with your program is equivelent to linking the library with the object files of your program, seems to verify this. The question still debated is whether Shared libraries are like this also. It's the wrong question. This is a FAQ here. Stop thinking about libraries. Libraries are not relevant. You're getting misled by technial details of how libraries are implemented, when in fact the whole issue is a red herring. Start thinking about source. The question you need to ask yourself is: Is this piece of software, in source form, a derivative of openssl? If it has been written to include and extend the behaviour of openssl by calling its functions - for example, the piece of software is an implementation of HTTPS, an SSL-derived protocol - then the source is probably a derivative of openssl. Your definition of derivative is not based on the law, and I don't believe the question is whether it extends the behavior. That would be a definition based on use, which is not a copyright concept (outside of the termination clause). Here is the US definition of a derivative: - A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”. URL: http://www.copyright.gov/title17/92chap1.html#101 - The language has certain ambiguities, in particular there is an open question as to whether a derivative work must be an original work of authorship. Sure, the second sentence seems to make that clear, but the first sentence doesn't seem to support it. Suffice to say, the argument is the stuff of many law review articles. But what is clear is that a derivative work requires an act of copying the original work of authorship. The caselaw in question is Lee v. A.R.T. Co. (125 F.3d 580) where someone took a piece of art they purchased, fused it to an ashtray or something and then resold it. The original artist said that was a derivative work and the sale was illegal. The court found that it was not a derivative work because no copies were being made. A legal copy was merged with something else and the first sale doctrine bared A.R.T. Co. from prohibiting resale of its original art. So with shared libraries the question is not whether it extends functionality, but whether there is copying going on to create a new work (possibly of authorship). Well sure, there is some sort of copying going on... bits and pieces of the shared library must be compiled into the finished binary, but that brings us to another fun copyright question. Are those bits and pieces, in of themselves, copyrightable? Consider Sega Enterprises Ltd. v. Accolade Inc. (977 F.2d 151) where the court said that you couldn't protect header type materials via copyright and that Accolade was free to develop games for the Sony PS without having to pay Sony's licensing fees for using its fancy libraries. It was based on the idea that the bits Accolade needed to copy where not eligible for copyright protection. Seems to me those signs all point to the idea the the mere linking against a dynamically linked library does not constitute a copyrighted work. -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: GPL, yet again. (The kernel is a lot like a shared library)
Seems to me those signs all point to the idea the the mere linking against a dynamically linked library does not constitute a copyrighted work. s/copyrighted/derivative/ ?? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thursday 08 September 2005 10:47 am, Humberto Mass Guimarães wrote: Seems to me those signs all point to the idea the the mere linking against a dynamically linked library does not constitute a copyrighted work. s/copyrighted/derivative/ ?? Good save The linked work is still eligible for copyright... provided it meets all the standards of authorship. You're little regex, by the way, is an excellent example of a program that is not eligible. -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: GPL, yet again. (The kernel is a lot like a shared library)
Here is the US definition of a derivative: - A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”. URL: http://www.copyright.gov/title17/92chap1.html#101 Here is Brazilian definition of derivative, just for the kicks (*): art. 5º - [...] VIII - work: [...] g) derivative - the one that, while constituting an intellectually-novel creation, is the result of a transformation applied over the original work; [...] (Lei 9610/98 - Lei de Direitos Autorais/Author's Rights Act) (translation mine) (*) no, not really, but I think it's more approximate to the Berne Convention definition, too. -- HTH, Massa
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 10:46:32AM -0700, Sean Kellogg wrote: But what is clear is that a derivative work requires an act of copying the original work of authorship. The caselaw in question is Lee v. A.R.T. Co. (125 F.3d 580) where someone took a piece of art they purchased, fused it to an ashtray or something and then resold it. The original artist said that was a derivative work and the sale was illegal. The court found that it was not a derivative work because no copies were being made. A legal copy was merged with something else and the first sale doctrine bared A.R.T. Co. from prohibiting resale of its original art. So with shared libraries the question is not whether it extends functionality, snip irrelevant distraction about technicalities of shared libraries It'd be nice if this fairly optimistic view of copyright as applied to software would be upheld in the real world, because it would mean we could stop worrying about derivative works and modify[0] anything we liked; the only limitation would be on distribution (be even nicer if we could scrap that too, which would mean copyright wouldn't exist and the only requirement for being free software would be that you have the source). But I'm not hopeful that it would be, particularly since all the corporations and lawyers seem to think otherwise. Also, this completely defeats the GPL, permitting proprietary software to be based on it and making it functionally equivalent to the LGPL. Of course, if this were upheld in court, everybody would just leap to using contracts instead of licenses, and explicitly prohibiting quasi-derivation-via-merging. Enough courts have already upheld that you can substitute a contract for a copyright license and ignore all the limitations of copyright law. [0] I can trivially implement, in a matter of a few hours, a system which will let you modify any piece of software you have on a given platform in a manner that could only be described as 'merging it with something else'. If your platform is perl or some similar ASCII-text script, the system is patch(1). With minimal extra effort I can ensure that this happens only at execution time, and that no copies are stored. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 02:27:45PM -0300, Humberto Massa Guimar?es wrote: ** Andrew Suffield :: On Thu, Sep 08, 2005 at 01:22:07PM -0300, Humberto Massa Guimar?es wrote: 3.3. it seems to me that it's absurd to think, for instance, that Debian cannot dynamic link a GPLd program with OpenSSL. Why? Because if I write a completely-compatible MassaSSL library and install it in my system just in the same places/names/sonames/whatever OpenSSL is installed, this would change the copyright status of _the_ _program_!! This says that there can be no such thing as copyright infringement for creating a derivative of a piece of software, because you can always replace the original with a reimplementation that wouldn't be infringement. my knowledge of the English language is still worse than I tought, because I do not have any recollection of meaning what you said _at_ _all_. Remember: DERIVATIVE == TRANSFORMATION. Word games, no change in meaning. You're saying that Only the verbatim copying of a copyrighted text, possibly with modifications, can constitute copyright infringement; all other actions are legal. The rest of your mail just ranted the same thing several times. My point stands. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
Remember: DERIVATIVE == TRANSFORMATION. Word games, no change in meaning. You're saying that Only the verbatim copying of a copyrighted text, possibly with modifications, can constitute copyright infringement; all other actions are legal. The rest of your mail just ranted the same thing several times. My point stands. Nope. I didn't the first time, and I didn't now. You are being a child, not giving any reasonable reasoning, and trying to put words in my mouth. Me and Sean Kellog (in this same thread) we're trying to demonstrate (via showing of code law, case law, etc -- things that *really* matter in the *real* world) our point of view. Besides, I was a paralegal for two years, in a District Attorney's office and I have participated in legal research for prosecuting copyright infringers -- I _do_ know what I'm talking about, in the real world. And in no moment I showed for you the lack of respect you are showing for me right now. I did _not_ just ranted the same. I did offer you an example of how you are simply plain wrong -- as is the GPL FSF FAQ -- when you say that linking to a library creates a derivative work. A derivative work is NOT what you want it to be... it's a very well-defined (by code law and case law) legal entity. And it happens to differ (a lot) of what you think it is. Go in my example (that you so impolitely skipped in this response) and give me _any_ _good_ argument on why my program is or is not a derivative work of libc. Then, give me an argument on what libc (MSVCRT, BSD libc, or glibc) you think my program is a derivative work of, and why. I'll give you counter- arguments, and you'll see I'm right. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 03:32:26PM -0300, Humberto Massa Guimar?es wrote: I did _not_ just ranted the same. I did offer you an example of how you are simply plain wrong -- as is the GPL FSF FAQ -- when you say that linking to a library creates a derivative work. Argument from authority and a straw man, yawn. A derivative work is NOT what you want it to be... it's a very well-defined (by code law and case law) legal entity. And it happens to differ (a lot) of what you think it is. If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. Based on my readings of law review articles and the common legal arguments surrounding the GPL, the reason it works is because the GPL is a contract. The linking clause is a contractual term that you must agree to in order to receive a copyright license. Pretty standard forbearance. I know of no legal professional, outside of the FSF, who believes the GPL stands up as a pure copyright license. -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair c: 206.498.8207 e: [EMAIL PROTECTED] w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: GPL, yet again. (The kernel is a lot like a shared library)
If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. I asked you: why? you answered: strawman and ad hominem. You could not provide an argument. The established practice is nothing more than respect (which I have, too) for RMS's/FSF's contributions to Free Software. It does not mean that the GPL has the meaning they convey. I am still waiting for a good argument coming from you. Respectfully, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Sean Kellogg [EMAIL PROTECTED] writes: On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. Based on my readings of law review articles and the common legal arguments surrounding the GPL, the reason it works is because the GPL is a contract. The linking clause is a contractual term that you must agree to in order to receive a copyright license. Pretty standard forbearance. Which linking clause? The one in the FAQ? That's not in any way part of the license/contract. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: GPL, yet again. (The kernel is a lot like a shared library)
** Sean Kellogg :: On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. Based on my readings of law review articles and the common legal arguments surrounding the GPL, the reason it works is because the GPL is a contract. The linking clause is a contractual term that you must agree to in order to receive a copyright license. Pretty standard forbearance. But... there is _no_ linking clause in the GPL (*). Unless you are telling me that the How to Apply These Terms to Your New Programs is a binding part of the contract, which I will also dispute, because the mentioned title is immediately after a big, all-caps END OF TERMS AND CONDITIONS in the GPL. I know of no legal professional, outside of the FSF, who believes the GPL stands up as a pure copyright license. Ditto. (*) see: $ grep -n -i -C link gpl.txt 336-This General Public License does not permit incorporating your program into 337-proprietary programs. If your program is a subroutine library, you may 338:consider it more useful to permit linking proprietary applications with the 339-library. If this is what you want to do, use the GNU Library General 340-Public License instead of this License. $ grep -n -i -C how.to.apply.these gpl.txt 280- END OF TERMS AND CONDITIONS 281- 282:How to Apply These Terms to Your New Programs 283- 284- If you develop a new program, and you want it to be of the greatest -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 11:53:57AM -0700, Sean Kellogg wrote: On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. Based on my readings of law review articles and the common legal arguments surrounding the GPL, the reason it works is because the GPL is a contract. The linking clause is a contractual term that you must agree to in order to receive a copyright license. Pretty standard forbearance. Then your entire argument is irrelevent. If the GPL stands as a contract then it's valid, period. And there is no 'linking clause' in the GPL. The string 'link' only occurs once in the whole COPYING file, and that's in the postamble, not the license. The *only* thing there is, is the restriction on derivatives, which operates how I described or not at all. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa Guimar?es wrote: If you're going to make an argument at odds with established understanding and industry practice then you'll have to come up with more than that. There's an awful lot of lawyers and law professors who think that the GPL works. Go start by arguing with them. I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. You are the one who is supposedly attempting to offer an argument here. Not me. I'm just telling you why yours is broken. That doesn't require a counter-argument in this case. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, 7 Sep 2005, Joe Smith wrote: It is generally belived that the GPL 'derivative' clauses may actually be upheld in the case of static libraries. The fact that linking the .o's of the library directly with your program is equivelent to linking the library with the object files of your program, seems to verify this. The question still debated is whether Shared libraries are like this also. I haven't heard it debated very hotly in recent memory. General acceptance seems to be that it applies equally to static and dynamic linking. Dynamic linking DOES open up the possibility of distributing the using code and not distributing the library itself. The combination of the two may be un-distributable, however. The linux kernel 'copying' file states this: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. If that statement is true and if it does not qualify as a licence exception, then the following argument would hold: I think this is a license exception (or at least a clarification that applies specifically to this work). It is not a statement about GPL-licensed work in general. NOTE! The GPL does *not* cover programs that use shared library services by normal function calls - this is merely considered normal use of the shared library, and does *not* fall under the heading of derived work. The copyright holder of a given library would have to make that statement for the library in question for it to apply. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wednesday 07 September 2005 03:50 pm, Joe Smith wrote: If that statement is true and if it does not qualify as a licence exception, then I think Linus and the KernelDev team has been pretty consistent that they consider it their interpretation of the GPL as applied to their software. As a party to the exchange, they are free to define terms as they see fit. the following argument would hold: NOTE! The GPL does *not* cover programs that use shared library services by normal function calls - this is merely considered normal use of the shared library, and does *not* fall under the heading of derived work. The thing is that the kernel is indeed much like a library, but not like a static one. The kernel is a lot like a shared library in that it exists in memory, and has functions that can be called. It is different mainly in that it stays in memory, and on some architectures has special capabilities not available to regular shared libraries. Note that it is not different by being a critical part of the operating system, as other libraries, especially things like the c library, or even the runtime linking library (ld.so) I've written about this very issue in law school. It seems to me there are two ways to view the issue. One is that the GPL is a Contract (*shudder*) and thus the parties are free to restrict what is done with code they distribute. Consider it a contract that says you can have this code, but only if you free the code you combine it with... otherwise you can't have the code That is a perfectly fine contract, mutual promises and all. However, many say that the GPL is not a contract and must be considered a pure license and the sole product of copyright law. If so, then the GPL can only exercise power over (s)106 rights (US copyright law). Any item outside of those rights cannot be controlled by the license. The GPL tries to do this by claiming a derived work or out-and-out copying. I think you very much hit it on the head by asking whether it is either... and based on my understanding of what is and is not a derivative work, what constitutes copying, and applicable caselaw, I don't think it is. But then again, I think the GPL is a contract... so I don't see it as much of a problem. -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
