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: Linuxsampler license
I just wonder how can BSD/MIT/... be GPL compatible not having section 3 of the LGPL. Everything distributable under the terms of BSD/MIT, is also distributable under the terms of the GPL because BSD/MIT (2 and 3 clauses) is *less* restrictive than the GPL. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
On 9/16/05, Humberto Massa Guimarães [EMAIL PROTECTED] wrote: I just wonder how can BSD/MIT/... be GPL compatible not having section 3 of the LGPL. Everything distributable under the terms of BSD/MIT, is also distributable under the terms of the GPL because BSD/MIT (2 and 3 clauses) is *less* restrictive than the GPL. Being less restrictive doesn't make it the GPL. Neither BSD nor MIT allow you to turn their licensing terms and conditions into GPL terms and conditions. As a matter of fact, they do. They give you plenty of control over your derivative work when you make it -- including the power to make your derivative work available under a more restrictive license. This is exactly what copyleft licenses (L?GPL et alli) restrict -- if you make a derivative work and the original work is copyleft-licensed, you usually cannot make your derivative available under any license other than the original license itself. -- HTH, Massa
RE: Linuxsampler license
Derivative source code must stay under original license. You're right that BSD/MIT/... allow sublicensing under different terms for *binary form*... but that's just like the IBM's CPL, for example, which even Microsoft uses and likes (in spite of contractual obligation to provide access to [modified] source code under original license, may I note). No, no and no. Full text of MIT/X11 license: Permission is hereby granted, free of charge, to any person ^^ obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, ^^ ^^ publish, distribute, and/or sell copies of the Software, and to ^^^ permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. This is why this license style is also called 2-clause BSD: the only conditions are: 1. the copyright notice and the license text appear in all copies; and 2. the copyright notice and license text appear in supporting documentation. no conditions on source, binaries, or similar stuff. -- 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)
** 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
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
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)
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)
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)
** 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
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
** David Nusinow :: If someone is going to file a lawsuit, someone has to pay for it. If the two sides live in different places, one of them has to travel no matter what, and thus pay for that expense. If we say that choice of venue clauses aren't Free, then the person bringing the suit will very likely have to travel and pay the fee (or that's my interpretation of Humberto and Michael Poole's responses). If not, then the person defending the suit will have to pay the fee. Either way, there is a cost involved. Why are we choosing sides if such a cost can't be avoided? Because: 1. it's greater the probability that the licensee is poorer than the licensor; 2. the definition of user (as in we care about our users) fits the licensee better than the licensor -- even if it also fits the licensor; and, finally 3. in the case of a fork (fork == GOOD(TM)) people can end up with a license that make BOTH the licensee and the licensor pay some (possibly hefty) cost to litigate the terms of the license. Example of #3 above: I start a (small) companya that distributes a fork of Mozilla -- under MPL1.1 -- , with a lot of improvements. Someone in Argentina forks my fork, and disobeys some of MPL's rules. Now, to prosecute that someone, I have to travel to California -- because I also agreed to the venue of the MPL 1.1. Worse yet, someone in my home town could be the culprit, and I would still have to go California to prosecute him... probably. This does not seem Free Software to me. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: celestia and JPL license
I'm guessing 'By electing to download the material from this web site the user agrees: ... 2. to use a credit line in connection with images.' is a restriction on modification (DFSG #3). I don't think a credit line is enough to trigger DFSG#3, because it would fall under proper attribution of copyright IMHO. -- 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 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: CDDL, OpenSolaris, Choice-of-venue and the star package ...
I doubt that people who do not wish to become legally bound to appear at the the author's home court whenever he files a frivolous lawsuit can be meaningfully described as a group of persons that can be discriminated against. If everybody belongs to the group, is it meaningfull to discriminate against it? Try people who do not have enough money to travel to $VENUE to defend themselves from a frivolous lawsuit -- one that they will lose by defaulting their court appearance. I think Debian agrees that poor people in general is a group that is protected by DFSG#5. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: CDDL, OpenSolaris, Choice-of-venue and the star package ...
** Matthew Garrett :: Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Matthew Garrett [EMAIL PROTECTED] But that's already possible. The majority (all?) of licenses that we ship don't prevent me from being sued arbitrarily. The majority (all!) of license we ship do not demand that you agree *in advance* to waive your usual protections against arbitrary lawsuits in exotic courts. Why does the exotic courts aspect actually make any significant difference? Are you honestly asserting that the cost of me travelling to, say, Finland is going to be large compared to the costs of hiring a lawyer to defend me? Both are impossible costs to me. But, in my home jurisdiciton I have the option of the free legal counsel my court will appoint to me. The only difference that choice of venue makes is that it potentially increases the cost for me. By orders of magnitude. I'd like to see those figures. Within the UK alone, I can end up paying fairly large travel fees to deal with a court case. It may be that you do not have any concept of home court within the UK. That does not mean that the rest of the world's Debian users should be expected to suffer from that fault. If I'm living in the Scottish highlands, that doesn't help a great deal. I'll agree here ! Then why leave easy targets to lawsuit sharks ? How do we protect against that currently? We protect against leaving easy target by considering software non-free if its licence demands that you position yourself as an easier target that you would be without the license. Any license that imposes any restrictions on me leaves me an easier target than I would be without the license - it's much easier to find an excuse to sue someone over a piece of GPLed software than a piece of BSD licensed code. It's my opinion that the GPL is the least-free yet still-free (*) license. Anything with more restrictions than the GPL makes you an _easier_ target to the sharks, so anything with more restrictions is non-free. Bt this is just *my* opinion. (*) provided clause 8 is not invoked. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
The DFSG are not holy writ, but how about if I phrase it as discrimination against licensors without money? DFSG #5: No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. This implies, at least to me, that the _licensor_ is not allowed to discriminate against a person or group, because he/she is the one who chooses the license. -- 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)
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: fresh review of: CDDL
FWIW, the phrasing comes verbatim from MPL 1.1. MPL 1.1 is DFSG-free, right? not according to http://lists.debian.org/debian-legal/2004/06/msg00221.html -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
FRCP 8(a) requires any such claim to explain why the court has jurisdiction over the question and the defendant. How would your pleading address this? Why would US citizenship not be sufficient? Whose US citizenship? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
Why would US citizenship not be sufficient? Whose US citizenship? The plaintiff. No. Because the Court has no bearing on what would a non-US-citizen nor-US-resident (the defendant) will do. If the Court orders you (*) to stop distributing some software and you don't, the Police gets to your door and you go to Jail. If the Court orders me (*) to do something and I don't, they can't do anything unless I want to go to Disneyland. (*) I am obviously supposing you, the plaintiff, is an US citizen and resident. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
Whereas the alternative may be that licensors are unable to afford the enforcement of their license. Would you prefer to discriminate against them? YES. Please. The DFSG #5 says you should not discriminate the licensee; the licensor is OK. Debian does, in an active basis, discriminate against licensors: if they refuse to release source code; if they license their documentation under the GDFL, MPL (?), old QPL, etc, etc, etc. Free Software is about the licensors (copyright owners) relinquishing some of their rights to assure the rights of the commons. The legal system discriminates in favour of rich people. That's true regardless of license conditions. That's exactly why we (should) discriminate in favour of poor people. -- 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)
** 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)
** 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)
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)
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)
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)
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 :: 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: Rules for submitting licenses for review
** Sean Kellog :: On Saturday 27 August 2005 09:08 am, Ken Arromdee wrote: On Fri, 26 Aug 2005, Raul Miller wrote: That said, it looks to me like this license grants you the right to use those game mechanics, including making and distributiong modified versions of them. If you've spotted someplace in this license which prohibits that kind of thing, I'd appreciate it if you could point that out to me. Since game mechanics are not copyrightable, without a license at all you still have the right to use them. Although the license does grant you the right to use them, it grants you that with conditions. Granting you the right to use something under some conditions, when previously you could use it without conditions, is taking away rights, not granting them. Without violating any of my NDA's with Wizards here, I've got to say that they very much believe that game mechanics are copyrightable. The mechanics are a work of authorship put in a tangible form. There are ways around copyright law, like independent invention, that are not available with patent law... but aside from that, you would need a license if you intend to just copy the d20 system (or create a derivative thereof). If you still think that game mechanics are not copyrightable, can you point me to some authority to support your claim. I'd be interested to see how they are distinguished from things like cookbooks (which are copyrighted). -Sean Ok, without consulting 17USC, I can tell you that in Brasil, game mechanics are uncopyrightable *and* unpatentable: i.e., unprotected at all. Let's see, translation mine: Author's Rights Act (Lei 9610/98), art 8: ''' It won't be object of author's rights protection, as described by this Law: [...] II - schemes, plans or rules for performing mental acts, games, or businesses; [...] ''' Industrial Property (*) Act (Lei 9279/96), art 10: ''' It's not considered an invention or utility model (**): [...] VII - gaming rules; [...] ''' -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: May be non-copyrighted documment included in main?
** Sean Kellogg :: On Friday 19 August 2005 06:47 am, Humberto Massa Guimarães wrote: Nope. There are other kinds of transformation that configure derivative works: translation to other languages is one of them, and it does not involve copying parts at all. Translation is certainly considered copying. The text isn't the issue, it's the expression that is being copied. What you seem to be talking about is literal copying. But in the eyes of the law, translation is considered copying of the underlying expression. -Sean Sean, it may be that we are in different tunes because of our different jurisdictions here (I know you are a law student). But down here, non-automated translation is *not* considered copy... it's a transformation that generates a derivative work. Now, your _automated_ (gcc, babelfish) translation is considered a copy, but I was going for the non-automated type. And the DFSG require the possibility of making derivative works. -- Massa
Re: FAIwiki Copyrights
IANAL AFAIK there are about five versions of the Creative Commons License. He was talking about the attribution license... Some of them are very restricting. e.g. don't modify my beautiful painting. But a wiki is about allow others to modify ( improve it ) Question to [EMAIL PROTECTED]: Which license (and which version of it) is adviced for a wiki in the spirit of DFSG? MIT/BSD (2 or 3 clauses) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: LGPL module linked with a GPL lib
** Raul :: On 8/2/05, Michael K. Edwards [EMAIL PROTECTED] wrote: I'm just telling you how it looks to me, and pointing you to where I got what evidence I have so that you can judge for yourself. The FSF is notoriously unforthcoming about their financial dealings, and the cash flows involved are not chump change (see the numbers disclosed by Jamie Zawinski in the Lucid Emacs saga). Whether or not you think RMS and Eben Moglen are cashing in personally (about which I have no evidence), if you are willing to take their uncorroborated claims about the legal strategy at the heart of their enterprise at face value, you are a more trusting man than I. This sounds like something appropriate for the scandal column of a tabloid. But what's the relevance of this issue to debian-legal? IMHO its relevance to d-l is that, if such suspicions are indeed founded, the FSF GPL FAQ should not be taken by face value and that Debian should re-evaluate its position about GPL and linking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL module linked with a GPL lib
** Raul Miller ::
On 7/27/05, Humberto Massa Guimarães
[EMAIL PROTECTED] wrote:
Static linking can *not* create a derived work, because it is an
automatic process. Poster case: is hello, generated from hello.c:
#include stdio.h
int main(int argc, char** argv) {
printf(Hello\n);
return 0;
}
a derivative work of something it's (statically) linked to?
The answer is no, because derivative works, as intelligent
transformations, can only appear when you *create* a work.
As Andrew Suffield has pointed out, this is a strawman
argument. But I'd like to reiterate that point.
Strawman?
Fact: the creation of a derivative work is the application of some
transformation on the original work.
The above snippet (which isn't even copyrightable, for its sheer size and the
necessity of expressing the same thing in the same language) is NOT a
derivative work of ANY libc implementation, even if (for some implementation)
it NEEDED to be statically linked. Because when I created the snippet (and I
created it) I did NOT apply any transformation to anything else that is
copyrighted or event copyrightable.
The binary, OTOH, when statically linked, contains (parts of) the linked libc
implementation, copied, so the linked libc license terms must be followed to
distribute such binary, if possible at all.
Now, a dynamic linked binary does NOT contain ANY copyrightable parts of the
libc implementation. So, the distribution of the dynamic linked binary does NOT
depend on authorization from the copyrights holders of the libc implementation.
MORE SO because you can use such binary with another, compatible, libc
implementation.
Even if (as is our real case) you want to distribute together the binary and
the libc implementation, one being GPLd and the other,
GPL-incompatible-licensed, this is a case of mere agreegation because (a) the
GPL says so when you read it correctly, in opposition to a derivative work
under copyright law and (b) because you *are* just aggregating things. If you
develop another libc and install it in your system, and ldconfig away everyone
to it, one of the parts of this equation would have been completely erased.
*This* is the kind of interoperability that has protected in the Lexmark case,
for example.
Re: LGPL module linked with a GPL lib
** Michael Poole :: Potential penalties are irrelevant to my question. You assume a priori that such linking is a violation of the GPL. My question was why that assumption is valid. As I explained above, his citation of case law does not fit the facts. The only good answer people in d-l gave me to the question: why is the assumption that such linking is a violation of the GPL valid? is because Eben Moglen said so in the GPL FAQ, and he is a law teacher, so it must be true. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL module linked with a GPL lib
** Jeff Licquia :: On Tue, 2005-07-26 at 11:14 -0300, Humberto Massa Guimarães wrote: I find this discussion ultimately absurd. Debian is *not* distributing a derivative work. Debian does *not* distribute a work that includes both plugins/libraries. The fact that the things are (dynamically) linked at run time, especially combined with the fact that the plugins are opened with dlopen() and use stable API, is *more* than enough to lift any (inexistent IMHO) no-link requirement of the GPL. I find most of this response confusing. Yes, it is. I was ranting, because this discussion makes me see red. I apologize. First of all, it's clear that Debian *is* distributing a derived work based on GPLed libraries, called Debian GNU/Linux. The First of all, Debian GNU/Linux is *NOT* a derivative work of OpenSSL, GStreamer, nor any of its plugins. A derivative work has a definition in the statute (in the US case, 17USC). specific case in question may fall under the mere aggregation clause of the GPL, but then this is the point you should argue. I The last paragraph holds, independently of the mere aggregation value. abhor imprecision in these discussions, as they are the breeding ground for all kinds of myths and speculation. (Not that I am immune to imprecision, or that I am not occasionally a myth-monger in my own right. But I welcome the correction.) Second, you seem to be asserting that an app and its dynamically linked libraries do not constitute a derived work based on both for the purposes of the GPL. Rather than debate this point, I Yes. There is no derivative work status on the program that uses a library. I and M.K.Edwards, in the last 3 months or so, have brought a lot of arguments and case law to this extent to d-l, and my own and humble conclusion is that: especially in the case of dynamic linking (and more so in the case of dlopen()ing), the distribution by debian of both a program A and a linking-to-A B.so is subject only to the *separate* compliance to the terms of both A and B.so, independently of any terms applied only to derivative works of A or of B.so. think it best to point out that this runs counter to accepted precedent within Debian that dates back a long time; see the KDE/Qt controversy for a famous example. Basing conclusions on this past precedent is not absurd; indeed, it would seem that the onus is on you to prove your assertion. I do not have enough time right now to answer properly (ie, with the links to the discussions, examples, and caselaw that I, amongst others, presented here on d-l), but I trust that you can find them if you are interested. As I said two paragraphs above, I consider that I presented all my arguments in this direction, and (to me, at least) I consider my point proven. That's probably enough for starters. If I am indeed confused and you are correct, then there doesn't seem much point to proceed to the dlopen() question. Ok. -- HTH, Massa
Re: LGPL module linked with a GPL lib
** Jeff Licquia ::
On Wed, 2005-07-27 at 10:05 -0300, Humberto Massa Guimarães wrote:
First of all, Debian GNU/Linux is *NOT* a derivative work of
OpenSSL, GStreamer, nor any of its plugins. A derivative work
has a definition in the statute (in the US case, 17USC).
Hmm. I suppose this is part and parcel of the move in the USA to
copyright compilations or databases? I suppose I had never
thought of it that way.
Derivative works are those that result of a (non-automatable,
intelligent, intellectually novel) _transformation_ of a work.
Compilation works are those that are composed of other works, in
which the intellectual novelty resides in the selection and
arrangement of contents.
Debian, as a whole, is a compilation works on its packages.
Yes. There is no derivative work status on the program that uses
a library. I and M.K.Edwards, in the last 3 months or so, have
brought a lot of arguments and case law to this extent to d-l,
and my own and humble conclusion is that: especially in the case
of dynamic linking (and more so in the case of dlopen()ing), the
distribution by debian of both a program A and a linking-to-A
B.so is subject only to the *separate* compliance to the terms
of both A and B.so, independently of any terms applied only to
derivative works of A or of B.so.
Mr. Edwards, elsewhere, refers to the GFingerPoken thread, which I
had followed. There may be other threads I did not follow, and I
will look for them.
I confess to not seeing how the manner of linking makes a
difference from a copyright point of view. Static linking creates
a derived work, in that the resulting binary contains the library,
Static linking can *not* create a derived work, because it is an
automatic process. Poster case: is hello, generated from hello.c:
#include stdio.h
int main(int argc, char** argv) {
printf(Hello\n);
return 0;
}
a derivative work of something it's (statically) linked to?
The answer is no, because derivative works, as intelligent
transformations, can only appear when you *create* a work.
If I translate Helter Skelter to Portuguese -- not by babelfish --
then I am doing a derivative work. When I write the above hello.c,
not.
much as how a motion picture film contains its soundtrack. To me,
splitting the soundtrack off a movie, and creating a machine to
recombine them afterwards, does not cease to make the movie an
infringement on the soundtrack's copyright, which is equivalent to
the dynamic linking process. Is such a scheme really effective
from a legal standpoint in avoiding copyright liability?
No, because you can't change the soundtrack of a film without
changing the final result. OTOH, you can substitute (almost always)
glibc for dietlibc in a program and have the same result. Such
program does not *depend* on glibc for being what it is, and most
certainly is *not* the result of a transformation applied over
glibc.
Anyway, the person who recombines the film and track, in the
case of dynamic linking, is the *USER*, in the process of using the
program, and copyrights protection do not apply at that moment, as
per 17USC.
I do not have enough time right now to answer properly (ie, with
the links to the discussions, examples, and caselaw that I,
amongst others, presented here on d-l), but I trust that you can
find them if you are interested.
As I said two paragraphs above, I consider that I presented all
my arguments in this direction, and (to me, at least) I consider
my point proven.
That's great. Other people with legal expertese (the FSF legal
team, for example) have done the same, and have come to entirely
different conclusions. Others with legal expertese commented, as
I recall, on the KDE/Qt controversy back in the day, too, and I
don't recall seeing any argument against it that wasn't based on
emotion or wishful thinking (the KDE and Qt people are good
people, they wouldn't sue anyone).
I am not a lawyer, and thus am forced to accept arguments from
authority (and regurgitate them when necessary, as was the case in
this thread). It seems clear in my interaction with you that my
understanding of the copyright process is hopelessly inadequate
for evaluating these arguments; there always seems to be some
exception to the general rule that people can throw at any
position people can take.
And, it seems to me, that in the authority face-off, you lose.
I've never heard of you outside this forum. Mr. Edwards has
already admitted to a lack of formal legal training. The GPL, on
the other hand, has a law professor and a team of lawyers behind
it, as do other groups promoting free software and open source,
and their efforts at enforcing their view of the world have been
quite successful to date. Are you seriously telling me that these
people don't know what they're talking about regarding the law,
and that you do? On what basis can you make such an extraordinary
claim?
Now
Re: LGPL module linked with a GPL lib
** Loïc Minier :: Hi, On Mon, Jul 25, 2005, Jeff Licquia wrote: From the GPL: 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... So the particular details of how things are distributed in memory while running aren't directly relevant. Modification and distribution are what matters, and it's clear from looking at the packages that GStreamer is distributed in Debian in conjunction with GPLed bits in a manner that's more than mere aggregation. I'm not sure to understand: you mean that since some LGPL GStreamer plugins are shipped in Debian along with GPL packages and they can play together means that the whole is GPLed? Would it be ok to have a copyright file along these lines: The source code for all plugins in the GStreamer Plugins source package is licensed under the LGPL, however some plugins are built with the help of header files from GPL libraries, and will be linked to GPL libraries when loaded in memory. Thus, using these plugins will switch their license to GPL, and you can only use them in applications with a license compatible with the GPL. You should have received a copy of the GPL and LGPL licenses ... Is a list of plugins necessary? I guess it's up to the interested person to check, nowadays it's relatively easy with tags and Debian's copyright files, and I don't want to maintain such a list. I find this discussion ultimately absurd. Debian is *not* distributing a derivative work. Debian does *not* distribute a work that includes both plugins/libraries. The fact that the things are (dynamically) linked at run time, especially combined with the fact that the plugins are opened with dlopen() and use stable API, is *more* than enough to lift any (inexistent IMHO) no-link requirement of the GPL. Please don't do that. -- HTH, Massa
Re: A question about converting code to another programming langu age
Agreed, and in the vast majority of the cases the translation is a creative work. A babelfish translation would be a literal translation. an f2c translation is a literal (automatic) translation, so it's not a creative work. The copyrights of the original work apply to the translated work IMHO. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EUPL draft
Derivative Works: the works or software that could be created by the Licensee, based upon the Original Work or modifications thereof. This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in article 15. This definition should be left to the copyright law. Distribution and/or Communication: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, on-line or off-line, copies of the Work at the disposal of any other physical or legal person. This appears to include public performance (eg, using the software to drive a website), which will cause problems and be non-free IMHO. 5. Obligations of the Licensee The grant of the rights mentioned above is subject to some restrictions and obligations imposed on the Licensee. Those obligations are the following: ... Provision of Source Code: When distributing and/or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicates a website where this Source will be easily and freely available for as long as the Licensee continues to distribute and/or communicate the Work. This is the if you drive a website using this, then you have to distribute the source, when combined with #1. non-free IMHO. 10. Acceptance of the Licence The provisions of this Licence can be accepted by clicking on an icon I agree placed under the bottom of a window displaying the text of this Licence or by affirming consent in any other similar way, in accordance with rules of applicable law. Clicking on that icon indicates your clear and irrevocable acceptance of this Licence and all of its terms and conditions. Similarly, the creation by You of a Derivative Work or the Distribution and/or Communication by You of the Work or copies thereof indicates your clear and irrevocable acceptance of this Licence and all of its terms and conditions. This, together with the preamble's any use of this work, may be non-free. 11. Information to the public In case of any Distribution and/or Communication of the Work by You (for example, by offering to download the Work from a website) the distribution channel or media (for example, the website) must provide the following information to the public: your name, as new Licensor providing the Work, your geographic and electronic address, Whoa... dissident test alert! where the Licensor is registered in a trade or similar public register, the trade register in which the Licensor is entered and his registration number, the different technical steps to follow to conclude the Licence, prior to the Distribution and/or the Communication of the Work, what is to conclude the License? where the Licence contract will be accessible, the languages which can be used for the conclusion of the Licence. The Licence terms provided to the Licensee must be made available in a way that allows him to store and reproduce them. 14. Jurisdiction Any litigation resulting from the interpretation of this license, arising between the European Commission, as a Licensor, and any Licensee, will be subject to the jurisdiction of the European Court of Justice, as laid down in article 238 of the Treaty establishing the European Community. Any litigation arising between parties other than the European Commission, and resulting from the interpretation of this license, will be subject to the exclusive jurisdiction of the competent court: Whoa... discrimination: differentiates the EC amongst all licensors. · where the Licensor resides or conducts its primary business, if Licensor resides or conducts its primary business inside the European Union; · where the Licensee resides or conducts its primary business if Licensor resides or conducts its primary business outside the European Union; · where the Licensor resides or conducts its primary business, if both the Licensor and the Licensee reside or conduct their primary business outside the European Union. Discrimination: this is best left to each copyright law. 15. Applicable Law This License shall be governed by the law of the European Union country where the Licensor resides or has his registered office. This License shall be governed by the Belgian Law if a litigation arises between the European Commission, as a Licensor, and any Licensee. This License shall also be governed by the Belgian Law if the Licensor has no residence or registered office inside a European Union country. Ditto. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
** Matthew Garrett :: If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86 /drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? My take: preferred form for modification is a phrase with two verbs, ie, with many combinations of preferred by whom, and modification by whom: 1. preferred (by the author) form for modification (by the author) 2. preferred (by the current licensor) form for modification (by the current licensor) 3. preferred (by the current licensee) form for modification (by the current licensee) 4. preferred (by the author) form for modification (by any third-party) etc. etc. etc. My opinion? Is that we *should* use the GPL definition, but we should also clarify which combinations are acceptable. For instance, the option (4) above can be non-free; OTOH, the option (3) is clearly impractical (how can one guess which form will all of his licensees prefer?) If we think nv_hw.c is source, then our definition is closer to #2, anyway. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdts patent issue?
Software patents are not legal in Europe. Period. The European patent convention from 1972 explicitly excludes software from patentability. Attempts to pass legislation that would have allowed software to become patentable have failed. The worst thing we could do now is give in to the patent scare tactic and stop developing and distributing software that might infringe patents that might have some validity. Ditto, for Brasil. Software patents are explicitly excluded in our Industrial Property (= Patents + Trademarks) Act (Law 9279/96), section 10, V: 10. It shall not be considered invention or utility model: I - discoveries, scientific theories and mathematical methods; II - purely abstract conceptions; III - schemes, plans, principles or methods of commerce, accounting, finance, education, advertising, lottery or fiscalization; IV - literary, architetonic, artistic, scientific works or any aesthetical creation; V - computer programs by themselves; VI - information presentation; VII - game rules; VIII - surgical techniques or methods, as well as therapeutic or diagnosis methods for application both in human or animal bodies; IX - all or part of natural living beings and biological materials found in nature, even if in isolation, including the genome and germoplasma of any natural living being and biological natural processes. Obviously, only inventions (or utility models) can be patented. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Correct license
| 7. no permission is granted to distribute, publicly display, or | publicly perform modifications to the Distribution made using | proprietary materials that cannot be released in source format under | conditions of this license; While this is probably DFSG-free, it can be very obnoxious, depending on what the software does. IIRC restrictions on public performance are *not* DFSG-free. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317359: kde: ..3'rd Help-About $KDE-app tab calls th e GPL License Agreement, ie; a contract.
** Sean Kellogg :: On Sunday 10 July 2005 09:53 pm, Glenn Maynard wrote: On Sun, Jul 10, 2005 at 05:51:17PM -0700, Sean Kellogg wrote: Glenn, don't you think he's talking about technologically impractical. We all know how easy it is to circumvent click wrap licenses. But you HAVE to agree to the GPL to download the software, click wrap or not, so its not really impractical from a freedom sense. This is so wrong. The person OFFERING the software for download have to agree to the GPL, not the downloader. And anyway, it's not really easy to circumvent 12000 clickwrap licenses, one for each Debian package. Technically impractical *is* non-free. Marco believes, as far as I understand (from past messages), that a license requiring technically mpractical things as conditions for basic freedoms is free. A you must send 250 redundant copies of the source along with binaries, to make sure that the recipient gets at least one intact is technically impractical; a Linux distribution with two discs of source would have to ship five hundred. I hope such a restriction is clearly non-free. Yeah, your example makes sense because it requires you to do more than is required under the GPL (a violation of the GPL itself). But agreeing to the terms of the GPL is not an additional requirement ontop of the GPL. The gobbly gook in Section 5 of the Wrong again, agreeing to the terms of the GPL if all you want is to *use* the GPL'd software is an additional restriction, since the GPL *explicitly* grants such usage permission. GPL is, I would suggest, mostly unenforceable... part of the you can't say something is X when its actually Y and expext it to be treated as X doctrine. Its just like work for hire stuff, you can't declare it's a work for hire when its not. In response to an earlier suggestion, whether the GPL covers actions beyond modification and distribution... my copy of the GPL says, in section 1, that I have the right to make copies of code as I receive it. Now that is certainly interesting language. If I am given a copy of the software on CD by someone who agrees to the GPL, then it would seem I'm fine to keep the CD and do whatever even if I vigorously reject the GPL. Fair enough... but when I run 'apt-get', am I the one doing the copying or is the distributor doing the copying? I could really see it going either way but certainly if I come upon someone's computer, burn code to a CD on my own, I am engaged in copying. And, like I said before, the only thing that gives you the right to copy is the GPL, which means you have to agree to it. This is not ambiguous as you construct. The GPL section 1 says: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, *** in any medium ***, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. It's talking about source code, and that you can freely copy it verbatim and distribute such copies. So why does an author's decision to display those terms when you first install or to call it a License Agreement (desperate attempt to return to subject) violate the GPL or the DFSG? Because it takes away the rights the GPL already gave to the recipient: the right to use the software, without having to agree to nothing at all. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317359: kde: ..3'rd Help-About $KDE-app tab calls th e GPL License Agreement, ie; a contract.
** Sean Kellogg :: On Thursday 14 July 2005 09:16 am, Humberto Massa Guimarães wrote: Because it takes away the rights the GPL already gave to the recipient: the right to use the software, without having to agree to nothing at all. If you come upon the program on someone else's computer, and that someone else has consented to the GPL, then you're right on the money... that person does not have to agree to the GPL to just simply use the software. ? But I'm not talking about USE, I'm talking about the possession of a copy of the code. You are not permitted to have a copy of the code without Lawful possession of a copy is not forbidden, either in Brasil by our Author's Right Act (9610/98) nor by the Computer Programs Act (9609/98), nor in the USofA by 17USC; where lawful is defined as: you received this copy from a licensed distributor, as opposed by you hacked someone's computer and extracted it from it, you shoplifted a CD, or you got it from a warez site. permission under the law. Period, end of story, except no substitutions. I have already acknowledge the interesting legal argument that you do not need permission to hold a copy if you get it from a distributor who has permission to distribute, but I'm This is not an interesting legal argument: it's a legal FACT. If you acquire *any* copyrighted work lawfully from a distributor who has permission to distribute, this is the first sale that the first sale doctrine is about. not convinced and I have asked some smarter people than myself to look into it (they happen to be out of the office right now... so any response may take a while). But absent that theory, there is nothing that grants you the right to 'apt-get install GPL PROGRAM' other than the GPL itself. And the GPL grants this right right away, in its sections #0, paragraph 1 (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 #4 (parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance). You may consult your legal counsel, but I affirm that your legal counsel will tell you the same I did. Moreover, caselaw down here (and, IIRC, in the USofA too) says that the copies necessary to make a computer program run (from CD to HD, including installation, from HD to RAM, from RAM to on-chip-cache, etc) are NOT protected by copyrights. I.e.: you do NOT need to abide or agree to the GPL to possess, install, or run a GPLd program. It's there (wherever you got it) for you to use. -Sean -- HTH, Massa
Re: Bug#317359: kde: ..3'rd Help-About $KDE-app tab calls th e GPL License Agreement, ie; a contract.
** Michael K. Edwards :: On 7/14/05, Adam McKenna [EMAIL PROTECTED] wrote: On Thu, Jul 14, 2005 at 09:38:25AM -0700, Sean Kellogg wrote: But I'm not talking about USE, I'm talking about the possession of a copy of the code. You are not permitted to have a copy of the code without permission under the law. Period, end of story, except no substitutions. Please cite the part of copyright law that says this. Sean's a little bit right here (is that like a little bit pregnant?), in that copies made without authorization are in principle subject to seizure and forfeiture no matter who is presently holding them. AIUI (IANAL), that's true of stolen and converted property generally and specifically, under 17 USC 509, of copies whose unauthorized creation and distribution rises to the level of criminal infringement under 506(a). Michael, I normally agree with you, but you are way off-base this time. He was referring to copies that were LAWFULLY acquired from a LICENSED distributor. But that doesn't necessarily mean that possession of such a copy is itself a criminal act. Lots of people come back from trips abroad with counterfeit goods (infringing copyrights and/or trademarks) bought at a street fair or something, and while I don't think I would knowingly buy such a thing myself, I also wouldn't call the cops if a friend gave me one as a gift (and wasn't as far as I know, engaging in a commercial-scale fraud scheme, etc.). In fact, I was once sold a counterfeit copy of a Microsoft product, and it's not clear to me whether the person who sold it to me knew that it was counterfeit; my compromise (so far) has been not to narc but not to buy anything there ever again. Bona fide third parties are normally exempt. If you (inadvertently) buy stolen merchandise for 10% discount from store price, you can be considered a bona fide third party. If you buy the same merchandise for a 90% discount, then you are not. When working in the DA's office, I encountered this same problem over and over: should the office prosecute someone who bought for $40, from a thief, a tv set whose store price is $50? And if he bought it for $10? But this is a digression, and has nothing to do with Sean's affirmation: He affirmed that one has to agree to the GPL to possess a copy of a GPL'd program. This was to construe the argument that a GPL clickwrap on installation does not constitute an additional restriction over the GPL, which IMHO is false, because (IMHO again) the GPL (sections #0 §1 and #4) grant the right to use the program (and henceforth to copy it during installation, and then from HD to RAM, from RAM to on-chip-cache) unconditionally. -- HTH, Massa
Re: Bug#317359: kde: ..3'rd Help-About $KDE-app tab calls th e GPL License Agreement, ie; a contract.
** Sean Kellogg :: On Thursday 14 July 2005 11:56 am, Humberto Massa Guimarães wrote: He affirmed that one has to agree to the GPL to possess a copy of a GPL'd program. WHAT?! No, never. Possession is not the issue, the issue is copying. And I am not convinced that making an FTP connection and downloading the material from a licensed distributor does not constitute copying, thus requiring permission. It is an interesting legal argument... could be true, but it could also NOT be true. I'm really not sure. Can you CITE something? I withdraw, about the possession, altough you *have* mentioned possesion in: But I'm not talking about USE, I'm talking about the possession of a copy of the code. You are not permitted to have a copy of the code without (your words) But, about the FTP, the *distributor* is making the copy, you are not copying anything, you are getting your copy that the distributor already made. That happens, not only legally speaking, but in reality. The only thing you made was to *request* a copy and to *receive* a copy: what 17USC and 9609-9610/98 and the Berne convention assign as the copyright owner's monopolies is to *copy*, *modify* and *distribute* copies (modified or otherwise). Here's the way I'm thinking about it. Apple has a license agreement with Sony to distribute music. Apple can make as many copies as it wants under the agreement and distribute it to whomever and charge whatever it wants (including give it away for free). An Apple technician puts a copy of TMBG's Man, It's Loud in Here on a server, but fails to place the appropriate password protection on the server. I come along, discover this song is available for one and all, and download a copy. I agree to nothing in the process. Apple later discovers its mistake, removes the song, and threatens to sue me. What claims can it make? ABSOLUTELY NONE, unless *you* are re-distributing said song. You got it legally (I am assuming that in said site there was a link to a song and a click here to download, and NOT a to get this song you have to pay $10 and get your password, etc...) The obvious answer is conversion... but is there a copyright violation here? Strikes me that I have made an unauthorized copy, denied someone their ability to profit from their works. I smell statutory damages. No, no, and no. Because of the very way the Web functions, if I publish something on it, and I don't reserve any rights conspicuously and I don't put any technological measures to prevent someone's access (robots.txt included) then I am, for all purposes, distributing to those someone. /in/ /casu/, Apple was distributing for you, legally, lawfully, and you only requested and got your copy. Someone a while back mentioned first sale... which is an interesting place to go. Is the idea that every apt-get I do is actually a series of first sale transactions where the consideration is nothing? That would probably work, other than the fact that it leaves Debian in the unique position to revoke all of the first sale agreements because its not binding without some form of consideration. -- But I'd really like to return to the question that got us all started. Is calling the GPL a License Agreement a bug? Yes. The GPL must only be agreed to if you want to copy, modify or distribute (modified or otherwise) the GPL'd work. Apparently my you have to agree to the GPL anyway theory has gotten people all worked up... so, obviously that's not going to I'm not worked up, but I *do* disagree firmly with your theory. convince anyone on this list. So can someone explain to me why its NOT a license agreement? Do you not in fact have to agree to the GPL if you intend to use the rights under the GPL? I posted a document once to d-l, in what we call schema format down here in Brasil, explaining what are your rights under the GPL. If you want, I can send it to you, but people in d-l thought it was very difficult to understand. In short: If you have the lawful possession (*) of a GPL'd work, you can: 1. (unconditionally) use it, play it, run it, and even perform it to the world via web or television. 2. (subject to the conditions under section 1, and to the agreement to the terms of the license as a whole) re-distribute its source code verbatim, in whole or in parts, alone or in an anthology, extending to the receiver the license you received (the GPL). 3. (subject to the conditions under sections 1 and 2, and to the agreement to the terms of the license) modify its source code, and re-distribute the modified source code, in whole or in parts, alone or in an anthology; the work generated by your modifications, being a derivative work of the original, must be licensed to those you distribute it under the terms of the GPL. 4. (subject to the conditions under sections 1, 2, 3 and to the agreement to the terms of the license) re-distribute the binary or executable code
RE: MP3 decoder packaged with XMMS
** Diego Biurrun :: On Tue, Jul 12, 2005 at 02:38:29AM -0700, Steve Langasek wrote: On Mon, Jul 11, 2005 at 01:45:24PM +0200, Diego Biurrun wrote: On Mon, Jul 11, 2005 at 03:54:12AM -0700, Steve Langasek wrote: However, the reason Debian continues to include the mp3 decoder library is that this patent, like so many other software patents, does not appear to be actively enforced. This is the standard Debian uses in deciding whether to distribute the software; Red Hat evidently uses a different standard. Is that the standard Debian practise? Is that in the policy somewhere? Debian policy governs the technical details of package creation. This is a matter that's out of scope of the policy document; my comments reflect the de facto policy of the ftp team as I understand it. Maybe it's time to create some sort of patent/ftp/XXX policy then. The core of this thread revolves around the problem that Debian's stance towards patents is unclear and inconsistent. Some programs are jugded impossible to package due to patent problems, while others aren't. This is further complicated by the fact that some MP3 encoders and multimedia applications are packaged while others are not, even though they do the same things and thus fall under the scope of the same patents. I was under the impression that Debian *did* have a policy: if the patent is enforced, towards it, then the software will go to non_US -- to the benefit of the sane jurisdictions (as is the EU, in principle). AFAICT Debian includes many packages that violate software patents, even actively enforced ones. It's simply impossible to avoid. A very prominent example is libts/libdca, where the developers closed the project due to patent threats by DTC Inc.: http://packages.debian.org/stable/libdevel/libdts-dev http://developers.videolan.org/libdca.html DTS Inc. claims that distributing this software is a violation of their patent EP 864 146. At DTS Inc. request, we decided, as a precautionary measure, to provisionally suspend the distribution of libdca while reviewing DTS Inc. claim. This is not an acknowledgement of the validity of the claim. The previous name libdts was changed to libdca as a precautionary measure. So upstream hasn't even decided yet what to think of the patent claim, they've just taken things off-line as a precaution. That's a rather weak precedent for enforcement. VideoLAN is hosted by ECP, a university from Paris where the project originated. DTS Inc. sent ECP a cease and desist letter stating that they should stop developing libdts, get a patent license from them or prepare to get sued. The ECP lawyer tried to settle amicably without success. DTS requested fees amounting to thousands of dollars per day and the university did not want to go to court. That was more than one year ago and libdts is no longer distributed on its own and has been removed from VLC. Furthermore development on the library has stopped. That's as good a precedent for patent enforcement as you'll get. FUD at its best, but it worked. This is how the patent scare works. Diego Not down here, thanks God and our corrupt lawmakers. Seriously. Software patents are just plain Evil. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to the Affero General Public License
Hi Gregor. Let's see if I can understand your motivations, and help you. ** Gregor Richards :: In response to An interface to the program, not the program itself Am I the only person who fails to see this as a significant difference? I don't think the freedoms of Free Software should be limited to people who actually have copies of the software, but to all users of the software. You have to have in mind that when you copyleft something, you are not only (potentially at least) augmenting the commons freedom, but you are also diminishing the individual freedom of your licensees. What do I mean? Well, if you license your software under the MIT/BSD, you have given maximum freedom to your licensee, at the potential cost to the commons freedom, because your licensee can improve your software and make a proprietary version. If you license your software under the GPL, you potentially augment the commons freedom (because if someone improves your software, the improved version will necessarily stay free -- or not be distributed at all) at the cost of removing some freedom from your direct and indirect licensees. What the DFSG does, IMHO, is to strike a balance between minimum and maximum commons and licensees' freedoms. What has not being pacified yet, even here in d-l, is exactly if access to the interface of a program is equivalent -- in terms of the balance between commons and licensees' freedoms -- to the access to the program itself. And *that* is the opinion you seemed to express with am I the only person who fails to see this as a significant difference?. I, for one, see a very significant difference between having access to the program itself and to its interface... Including, but not restricted to, a hypotetical dissident organization for which access to the program (even in binary form) can reveal details of the organization to the Evil Government that simple, plain access to its interface (even in a publicly accessed server) can hide those issues. Your argument seems to be that there is no additional onus in giving to someone access to some program when you are giving this same person access to the interface of said program. I disagree, altough not strongly. it less than just a black hole. I don't see why the right to read the code behind this black hole of functionality should be limited only to binaries physically on a system, and not to programs running over a network. And I think there's too much weight being placed on the distinction between having a binary on one's system and running it through other means. Just my opinion though *shrugs* This is an interesting point-of-view. In fact, I see why many consider the public performance thing a loophole in the GPL. I regard, IMHO, the GPL as being (de facto, not by a guideline) the borderline commons versus licensees case of a Free Software license. Explaining: not many more-restrictive-than the GPL licenses are considered DFSG-free; even the GPL, if the licensor chooses to use its clause #8 (geographic distribution limitation), for instance, can be considered non-DFSG-free; and finally, many of the onerous-to-the-licensee exceptions in the GPL are, by design, reflected in the DFSG. This fact adds a difficulty when you try to give the commons an additional potential freedom, by onerating the licensee when he is not distributing, but only publically performing the work -- and you still want to consider your work DFSG-free. To clarify a little bit more on the public performance thing: if I GPL a song and establish that its partiture is the source code, if you record this song and send your .mp3 around, you must make the partiture available. If I license the same song by your new license, if you want to go to the nearest square and play it aloud in the guitar, you must make the partiture available also. That is the difference between distribution and public performance, and that is why I think there is an unacceptable additional onus to the licensee in the latter case. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to the Affero General Public License
** Mark Rafn :: On Wed, 22 Jun 2005, Gregor Richards wrote: The term Free Software is open to interpretation, the DFSG is not the be-all-end-all of what is and isn't Free. True. This is why I use and support Debian - it's the closest thing I can find to my personal definition of freedom. AOLMe too/AOL. And the process of discovering what is and what is not DFSG-free is another thing that attracts me to Debian. After all, according to www.gnu.org , the Affero General Public License is Free Software, and I should think that history would give them precedence in making such a decision. Well, no. debian-legal is the place that Debian discusses their definition. Nobody has precedence in defining our terms. Actually, the ftp-masters and other constituted Debian authorities have precedence, and debian-legal is only their consulting body. But the process and the discussions on d-l are a beautifully democratic part of this process, and it's so good that actually the ftpmasters often (always?) follow the d-l consensus. If FSF acceptance is your goal, can you not just use the Affero license? In response to Unworkable, but you give an out in the next section, so this clause will never be used. How is this unworkable? Certainly many, even most, protocols this would apply to have this support. I mean that it's a requirement that is obviously non-free as there are many applications for which it would be impossible. It cannot be a requirement of free software. In your example, it's not required, so it's not worth spending much time on. It would constitute unacceptable restrictions on the production of derivative works, possibly combined with discrimination agains fields of endeavour. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LPPL and source-less distribution
-- []s, Massa // First they came for the Jews and I did not speak out - because I was not a Jew. Then they came for the communists and I did not speak out - because I was not a communist. Then they came for the trade unionists and I did not speak out - because I was not a trade unionist. Then they came for me - and by then there was no one left to speak out for me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LPPL and source-less distribution
How can a text get lost? Hmpf. * Michael :: On 6/14/05, Bernhard R. Link [EMAIL PROTECTED] wrote: * Michael K. Edwards [EMAIL PROTECTED] [050613 21:21]: C'mon, Raul. The crack-smoking GPL refers to an interpretation (non-contract license, functional use results in a derivative work) that I and others have demonstrated to have no basis in law [...] You have expressed this your opinion multiple times. I think your increasing use of words like words and phrases like crack-smoking, deceitful etc make a good point about how 'convincing' your demonstrations were. Increasing? Not particularly. If it really bothers you, I'm happy to drop crack-smoking, and say I am pro-GPL-as-an-instrument-of law. But with respect to deceit: Eben Moglen has engaged for years in deceit about the nature of copyright law and licenses. I see no reason not to call it by its name. You know I agree with you in many things, but I see one reason: Diplomacy. With a capital D. The FSF holds the copyright interest and is responsible for developing and publicizing of a lot of free software; even if your (harsh) word is accurate, IMHO it would be more polite any of: error, mistaken position, propaganda euphemisms. -- HTH, Always, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: quake2 and german youth protection law
* Michael Below :: Baltasar Cevc [EMAIL PROTECTED] writes: [German text respectfully cut] § 15 Youth-Endangering Media (1) If the inclusion of media in the list of youth-endangering media has been announced according to § 24 par. 3 sentence 1, they may not be 1. offered, given to or otherwise made available to children or youth, The German Debian mirror does, in fact, otherwise make available the entire Quake2 for Debian GNU/Linux, without any age check whatsoever. The only way I see to solve this is that the German mirror erases automagically quake2*.deb from its mirror, including the reference to it in Packages.gz and other similar content files. The German mirror admin might want to see if any other packages contain similarly censored speech (such as Nazi/racist propaganda etc). Alternatively, the German mirror could ask for some form of authorization that proves the age of the downloader (like pr0n sites do). It's terrible, but it's the law. Or you could close the German mirror and German citizens would have to download debian from other countries with less censoring laws. 2. displayed, demonstrated, advertised or made available at a place children or youth may enter or look into, Nope. We don't do that. 3. distributed or offered on the street, in booths that customers usually don't enter, by mail-order or in commercial libraries, Nope. We don't do that either. 4. rented or otherwise let commercially, except in shops that may not be entered or looked into by children or youth, No, again. 5. imported by mail-order, No. 6. offered, advertised or announced at a place that children or youth may enter or look into, or by distribution of media outside of the relevant trade, This should be achieved by the Packages.gz censorship I mentioned. 7. produced, obtained, delivered, stocked or imported to be used according to No. 1 - 6, or to enable such use for another person. (3) Without need for inclusion in the list or announcement, the limitations of par. (1) also apply to media which is wholly or in the main the same as media whose inclusion in the list has been published. This does not apply to debian*.deb, because none of those are in the same media as Quake2 (the original id CDs). It's just a compatible game engine that happens to play the game files on the original id CDs. I'm quite sure it's the data after having read the above. Probably the data is more problematic, yes. But see my other mail, I think the quake2 package plus the quake2-data installer could at least be constructed as an advertisement or announcement for Quake II. It's not advertisement nor announcement, but it *is* making otherwise available, if your translation is correct. -- HTH, Massa
Re: quake2 and german youth protection law
* Måns Rullgård :: MJ Ray [EMAIL PROTECTED] writes: This looks like a bug in Germany rather than a bug in quake2. Does the German government have a bug tracking system? It's called Parliament :-) Actually, I don't know *how* is it called aus Deutsch, but you know what I mean. YMMV. -- HTH, Cheerfully, Respectfully, Massa
Re: Is this license DFSG free?
* Sean Kellogg :: On Saturday 11 June 2005 01:51 pm, Joe Smith wrote: flexability, but can you point to the particular clause that you feel hints at this sort of a requirement/prohibition? Nope, I can only give you a link but as I understand it the tests are commonly used. http://people.debian.org/~bap/dfsg-faq.html Well now, this strikes me as a problem from a political science perspective (my undergrad degree). Debian-legal, a self-appointed group of various legal, political, an philosophical stripes, is making substantive policy decisions based on thin air? Nope. Debian-legal only debates the issues and sometimes, if we are lucky, reaches some kind of consensus about them. Who makes the substantive policy decisions about the licenses: the ftpmasters. Then, if any debianer is against those decisions, he/she has access to constitutional remedies. The three thought experiment tests, while nice and good, fail traditional structural tests because they are not rationally based. Absent a rational basis there is no way to disagree with Why aren't they rationally based? I mean, really, they seem pretty rationally based to me. All of the tests (as are the DFSG) are designed to protect the freedom of speech the software freedom is about. them, and absent ammasing a super-majority to change the DFSG to repudiate the tests, they seem to be locked in stone. U.S. Courts, love of 'em or hate 'em, base everything they do two sources: 1) previous decisions, 2) decisions made by elected officials or their appointees. Debian-legal seems to have adopted #1, but failing #2 it chooses instead to insert its own opinion. Which brings us back to the self-selected nature of the group. #2 are the ftpmasters, the debian-legal is a consulting body whose consensus is generally (but not always) followed by ftpmasters. I don't want to be the wacko who just goes off on a long standing system that, all things considered, seem to be working pretty well... but I also know that our the new DPL has made it pretty clear that he wants Debian institutions to be looked at to make sure they are actually doing the Project's work. Perhaps this is the time to seriously consider how debian-legal functions and on what sort of basis it makes decisions. The problem is that you are basing your conclusions in wrong assumptions. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this license DFSG free?
* Sean Kellogg :: On Saturday 11 June 2005 03:21 pm, Anthony DeRobertis wrote: Sean Kellogg wrote: Well now, this strikes me as a problem from a political science perspective (my undergrad degree). Debian-legal, a self-appointed group of various legal, political, an philosophical stripes, is making substantive policy decisions based on thin air? No. Debian-legal does not make policy decisions. Debian-legal advises the ftp-masters, who make the actual policy decisions (and, it does seem that they generally agree with our advice). The ftp-masters are appointees of the elected project leader. Well, that's certainly a great deal better, structurally. I guess I've never really seen any ftp-master discussion on this list... but then again, I don't know their names, so I wouldn't really know who was who. But at least there is some amount of accountability. The fact remains that it is far too easy to criticize d-l if operations continue under this system. I've been on this list for almost 4 years, with special attention ever since I entered law school... I know the sort of round-and-round fights that go on here that later get presented in FAQ's as consensus. Do you care giving an example of this, please? I can't think of any. As I said, I've never actually heard an ftp-master agree or disagree with the list... but if I were in their position I would They (ftpmasters) make their voices heard off-list, in a most authoritative way: allowing something to enter the archive or not, or maybe even removing something from Debian. have a hard time accepting advice from a forum who can't point to language that backs their claim. ??! This is kind of offensive IMHO. Can you give examples, too? [And, FYI, if you check the mailing list's archives, you'll find that the currenty project leader helped in drafting some of those tests. So, I suppose, we could probably ask him to give those tests the project's official blessing. However, there does not seem to be any need to do so.] Yes, I know that he was involved with developing these tests, and I know that he takes a very expansive view of the DFSG. My point is not to impinge on the good leader's opinions... only to note that a poor organizational structure can still come to good decisions. More importantly, the DPL does not have authority to state that these tests are extensions of the DFSG. I may not be a DD, but I have read the Constitution :) Maybe your understanding of the Constitution and the Social Contract is the problem (maybe my understanding of them is the problem, too): To know what is and what is not DFSG-free is the job of the ftpmasters, guided by the Guidelines, and (at *their* discretion) aided by discussions on d-l. The FAQs, tests, summaries of d-l discussions exist only to aid d-l itself in further discussing. The dissident test is a good example of something that does not directly influence the ftpmasters but could influence d-l in reaching (partial?) consensus if some software is Free or not. /In/ /casu/, there is a strong feeling that if some software cannot pass the dissident test, it cannot be free software, because the ability to modify and distribute modified versions of the software is impaired (goes against the DFSG). -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this license DFSG free?
* Marco :: [EMAIL PROTECTED] wrote: It blatently fails DFSG 5, because the person modifying the software may not have internet access for emailing the changes. (Think perhaps a developing nation.) I still do not believe that this is discrimination against persons or groups. This is an unreasonable interpretation of the original meaning of DFSG.5. I, OTOH, do not believe that this is an unreasonable interpretation of DFSG 5. Why should you exclude from the Free Software process people that do not have the money to have proper internet access? This *is* the exact meaning conveyed by the word discrimination. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LPPL and source-less distribution
* Bernhard :: * Michael K. Edwards [EMAIL PROTECTED] [050611 20:05]: The FSF is not in the business of giving truthful advice about the law. Sorry to ask the following, but I am getting really curious and hope you do not feel insulted. But I really have to ask: Are you sponsored by, employed by or otherwise related to Microsoft or any other large company selling non-free software? While I can't speak for Michael, I tought you should know other people (such as myself) agree with him in many of his points, including that one above. And *I* am employed by the Legislative branch of the government of Minas Gerais, Brasil, which is conducting a massive migration to Free Software, and I do not have any financial interest whatsoever involving proprietary software. Furthermore, while IANAL, I *try* to base things I put on d-l in my reasonable knowledge of Brazilian law and legal research (I worked two years as a paralegal, and I have another two years of legal training). -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this license DFSG free?
* Marco :: [EMAIL PROTECTED] wrote: I still do not believe that this is discrimination against persons or groups. This is an unreasonable interpretation of the original meaning of DFSG.5. I, OTOH, do not believe that this is an unreasonable interpretation of DFSG 5. Why should you exclude from the Free Software process people that do not have the money to have proper internet access? Because this is not discriminating, if they care they can find the money, a sponsor or a different way to contribute. It is Find the money?!?!?!?!?!? *I* personally *do* care, and I couldn't find any money (ok, I found a tenner in the street when I was 15 -- but only once) to finance my involvement in the Free Software. discrimination only if it relates to an intrinsic quality of an individual or group, like you cannot use this software if you are black or you cannot use this software if you are the military. As opposed to you cannot modify nor distribute this software if you are *poor*?. I'm sorry, but I take offense and I think your interpretation is absurd. -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RES: Is this license DFSG free?
* Sean Kellogg :: On Saturday 11 June 2005 05:10 pm, Måns Rullgård wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: Sean Kellogg wrote: You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. Doesn't this violate the Dissident test and cause troubles for our poor totalitarian state citizen? No, because the following statement is allowed by the GPL, and does not reveal the identity of the dissident: This file was changed on December 10, 2004. Whether that's allowed by the GPL depends on the interpretation of the phrase stating that you changed the files. Agreed. The setence is ambigous if broken down sufficiently. However, if the Anthony's language is sufficient, it strikes me that the GPL is way too verbose. All you would need the GPL to say to require such a limited changelog would be provide a notice of the date of any change without reference to you. It is interesting the GPL-FAQ has nothing to say about the topic. The GPL is not a statute; its language is not to be read under the hermeneutics principle of each word counts, there is *no* ambiguity, but under the principle of any ambiguity is construed against the licensor, unless he can *prove* that the licensee understood otherwise IMHO. In the case that I am correct, the phrase stating that you changed the files can be read as including: /* I changed this file (Sat Jun 11 2005 12:00PM) */ -- HTH, Massa
Re: openssl vs. GPL question
De: Steve Langasek [mailto:[EMAIL PROTECTED] The phrase For an executable work, complete source code means all the source code for all modules it contains appears in the text of GPL section *3*, which is not specific to works based on the Program. Such lack of attention to license detail from one who has so much to say on the subject is truly appalling. So, are you arguing that things that *dynamically* link with some libraries do _contain_ said libraries? Because IMHO neither ruby-zoom _contains_ libyaz nor libyaz _contains_ openssl. Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RES: Where to put Open Transport Tycoon (openttd)
See the paragraph from Micro Star v. FormGen cited in my response to Raul. It's not the degree of indirection in reference to artworks, it's the fact that the game experience plagiarizes protectable expression from Transport Tycoon. Ok. I'm conviced you're probably right. -- Cheers, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RES: RES: Where to put Open Transport Tycoon (openttd)
De: Måns Rullgård [mailto:[EMAIL PROTECTED] Humberto Massa Guimarães [EMAIL PROTECTED] writes: See the paragraph from Micro Star v. FormGen cited in my response to Raul. It's not the degree of indirection in reference to artworks, it's the fact that the game experience plagiarizes protectable expression from Transport Tycoon. Ok. I'm conviced you're probably right. I'm not so convinced. It depends on how much of the game is defined in the data files, and how much is part of the engine, in other words, how generic the game engine is. You do have a point, too. But in the specific case of TTD, could the game engine be *really* generic? I don't really think so. -- HTH, Massa
RES: Open Transport Tycoon - if it was like freeciv
De: Per Eric Rosén [mailto:[EMAIL PROTECTED] A bit counterfact maybe but ... Let's say, if I liked the concept of TTD (which I did), and started to write a FreeTycoon like freeciv, without using any material from TTD at all, and also without requiring original TTD data for execution, how close could I make it to the original *rules* and behaviour? Rules and behaviour IMHO are (in Brasil at least) safe, even from patents. What would be a good translation for mise en scene? This is a concept that I find kind of difficult to explain. Would this change if I used bits of the free openttd *game engine* in my project? Or: can really this misa en scene extend to the rules - the alghoritm? That sounds more like patents. I.e. - in the FreeTycoon (or FreeTransportKing, for avoiding trademark stuff too ...) I'm not using any of the characters of ttd at all, but am taking a new selection of buses, ship types etc, use a roughly similiar - but better ruleset, and implement all with fresh (non-TTD) code and data. Anyway, you are *confessing* in your first paragraph that you are *transforming* the storyline that is part of the game TTD into another work. So, your FreeTycoon game *is*, for starters, a derivative work, since its first inception. Any scenery and/or characters you draw that resembles the original ones -- and interacts as would the original ones -- would be construed IMHO as proof of infringement (provided you don't have an authorization from the copyright holder to make a derivative work). Your question can be considered an analog to: ''I want to write this book about a young blonde girl from Russia that in her 12th birthday discovers that she is a witch and is sent to a witch school in Ukraine, team up with some friends, etc... The characters would be different (*), the scenery would not be the same...'' (*) altough many would be witch school students, some would be teachers, probably there is a principal in the school, etc...
Re: Open Transport Tycoon - if it was like freeciv
De: Per Eric Rosén [mailto:[EMAIL PROTECTED] On Tue, 17 May 2005, Humberto Massa Guimarães wrote: Rules and behaviour IMHO are (in Brasil at least) safe, even from patents. What would be a good translation for mise en scene? This is a concept that I find kind of difficult to explain. Anyway, you are *confessing* in your first paragraph that you are *transforming* the storyline that is part of the game TTD into another work. So, your FreeTycoon game *is*, for starters, a derivative work, since its first inception. Yes. Seems like in this case boils down to: what is the difference between a storyline and a ruleset? It's the difference between creativity and technique. And yes, this answer is a non-sequitur. To countinue my strangeness: If we viewed *civ and *tycoon as utility software :-) ? Like, freeciv - itsn't a game - it a reseach utilization simulation and modelling software ... And TT could probably be educational software for the operation of public transit, or if we made somthing more exact - a good schedule-simulation software for your transport department :-) In this case, you should relly be able to make competing software that fills some purpose. If the storyline is just a program that allows you to simulate public transport operation with advancing technology, it sould more like a (stupid) SW-patent than something that can be copyrighted. Or? If you do just that, a program that allows you to simulate public transport operation with advancing technology, you are probably safe, as you are if you make a game that allows you simulate a game of soccer. The devil is in the details: the closer you get to the details (the way streets and avenues are viewed and portrayed in TDD, or in my example the way you pass the ball and control the players in FIFA2005), the closer you get to capture what is really controlled by copyrights: the creative expression. I can say I like the idea of a Office suite with this and that look and features and then write a software package that many users even can't tell is something other than the original Office suite. Not sued yet. Or? Any scenery and/or characters you draw that resembles the original ones -- and interacts as would the original ones -- would be construed IMHO as proof of infringement (provided you don't have an authorization from the copyright holder to make a derivative work). Hmm. But isn't this *very* much how freeciv works? Yes it is, AFAIK. Both games IMHO are more of the concept/utilty-type, and have a pretty non-existing storyline (of the once upon a time ... kind). This is a real, valid point. -- HTH, Massa
Re: Where to put Open Transport Tycoon (openttd)
De: Michael K. Edwards [mailto:[EMAIL PROTECTED] The issue isn't functional cloning. It's the fact that a video game is a literary work in the sense of having characters, settings, plot lines, etc., and therefore can be infringed in the non-literal sense of Micro Star v. FormGen -- even by a new scenario written for the existing game engine! It seems (IMHO) that the issue here *is* functional cloning. The characters, the whole mise en scene of the game is in the *data* files. The game executable would function like a video player, presenting the data in the data files and interacting with the user. And *this* is exactly what is protected by art.6,III. I think you'll find, on review, that even the deliberate intent of evoking the original is enough to create an infringing derivative work. When I get a moment, I'll find the litigation associated with The Wind Done Gone. Just to reassert my point, with the data I have at the moment, I don't believe that the game executable does this more than mplayer evokes the content of copyrighted works. After all, if you want to play the game legally, you must have a legally-acquired copy of the original game to supply the artwork. Cheers, - Michael -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RES: What makes software copyrightable anyway?
This might be relevant if we planned on distributing only non-working copies of Quagga. The copies of Quagga that Debian distributes are non-working; try to execute a Debian package... Anyways, I'll repeat my earlier assertion: if working copies of Quagga do not use functionality specific to libssl then we're dealing with mere aggregation and are not violating the copyright. This is true regardless of whether or not anyone believes the copyright is enforceable, and regardless of whether or not Quagga is dynamically or statically linked. Learned my Technique of Proof by Repeated Assertion, don't ya? But you are 100% right: If Quagga doesn't use functionality specific to libssl, then we are not violating the copyright. Now, if it DOES use functionality specific to libssl, but not to the point where Quagga could be considered a derivative work of libssl, then... we are not violating the copyright. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RES: RES: What makes software copyrightable anyway?
De: Raul Miller [mailto:[EMAIL PROTECTED] On 5/13/05, Adam McKenna [EMAIL PROTECTED] wrote: On Fri, May 13, 2005 at 02:47:37PM -0400, Raul Miller wrote: We have a license to distribute said material and we are abiding by the terms of the license. You might as well say that book publishers are contributing to infringement because books are so easy to photocopy. Except book publishers have hundreds of years of track record where books were not easy to photocopy. So it's hard to see how you can draw this analogy. What did book publishers do, recently, that they weren't doing before, that made books easy to photocopy? Also, Napster wasn't distributing anything in violation of any copyright licenses, so I don't see how this argument of yours shows that that analogy is irrelevant. But we are more like a book publisher than Napster. We have a license to publish certain materials, and we do so. What the user does with the materials after they receive them legally from us is both none of our business and out of our control. Are you claiming that we have a license to distribute the work based on the program Quagga which also contains and uses openssl? I am. Debian does have a license (GPL) to distribute a work based on Quagga (the debian version of Quagga, both the source and the binary package). Debian is -- furthermore -- abiding to the conditions on which that licensed was acquired, namely: (2a) Debian put putting proeminent notices stating where it did change the files and the date of such changes, in our changelogs; (2b) Debian is redistributing said files under the terms of the GPL; (2c) as Quagga is a daemon this does not apply; (3a, combined with 3§2) when Debian distributes quagga.*\.deb, it also distributes from the same web site or CD set quagga-.*\.dsc, quagga-.*\.diff and quagga-.*\.orig.tar.gz. These are the only conditions to redistribute a derivative work of Quagga. If not, what are we discussing? If we were adding pointers to 'illegal' packages that random users have built to our web site, then you might be able to draw a comparison to Napster. But we aren't (as far as I know). I'm not trying to claim that our case is identical to Napster. I'm trying to use Napster to show that we can't always divorce ourselves from actions our users take. As I understand it, action at distance is not sufficient to absolve us of responsibility. Contributory infringment is something about the US law that I think is absolutely insane. Thank $DEITY we still don't have them. Why? Because it's exactly like making a locksmith tool, or publishing the material on how to pick a lock, illegal: the intent of a tool is never clear. I produce 3 hours of security videos per day, and the tool I use for archival of those videos (a DVD-writing driver, with its writing software) is exactly the same tool that permits me to copy Star Wars III. I use my how-to pick a lock to open my own car in the 2 or 3 times a year I lock the keys in. And so forth. Even so, I do not believe distribution of a dynamically linked Quagga with SSL enabled is a breach of the conditions of the GPL. Not in Brasil, not in the EU, not in the USofA. Unless Quagga's copyright holders say otherwise. And most certainly I do not believe distribution of source code to a possibly-SSL-enabled Quagga is a breach of the GPL, either. And I made my points ad exaustam about that. -- HTH, Massa
