Re: Is "VIGRA Artistic License" licence free and GPL-compatible ?
@ 26/09/2005 18:39 : wrote Jacobo Tarrio : > El lunes, 26 de septiembre de 2005 a las 19:34:00 +0200, Claus > Färber escribía: > a. place your modifications in the Public Domain or otherwise make them Freely Available, for example by allowing the Copyright Holder to include your modifications in the Standard Version of the Library. >>> This goes beyond copyleft and is non-free, because it violates >>> DFSG#3, restricting the distribution of derivative works. >> Why? All you have to do is to make the modifications "freely >> available". Putting them under a license that is compatible >> (e.g. "Public Domain") >> seems to be enough. > > Because the DFSG say that the license must allow distribution of > modified works under the same terms as the original one. > > However, this one forces modified works to be in the Public > Domain, which is nowhere near the terms of the original work. > > Moreover, forced distribution of modified versions is considered > non-free (one should be allowed to create private modifications). > Not only this. One should also be allowed to create modifications, and distribute said modifications, only obligated to pass source code for the recipiend of those modifications. (IIRC this is the /raison/ /d'etre/ of the "desert island" test.) -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux Documentation Project License (LDPL) v2.0
@ 26/09/2005 17:31 : wrote Francesco Poli : > On Mon, 26 Sep 2005 17:33:25 +0200 Josselin Mouette wrote: > >> Le lundi 26 septembre 2005 à 12:09 -0300, Humberto Massa a écrit >> : >>> > 2. The person making the modifications must be >>> > identified. >>> >>> Yellow alert -- dissident test. Marco d'Itri is extremely vocal >>> against the Dissident Test, but I think anonymity is necessary >>> for Free Software. >> "Identified" doesn't mean it should be identified by a real name. >> A pseudonym is perfectly acceptable. > > As I already said, I'm not so convinced that a pseudonym > "identifies" a person. In fact, it does (almost) the opposite, I > would say. It builds a 'fake' identity, but hides the real > identity of its owner. > > IMHO, it's not so clear that a pseudonym would be perfectly > acceptable... > > [...] >>> Substitute "source format", in the following paragraph, by "in >>> the format the original author chose to write and modify the >>> work OR in the format the derivative work's author chose to >>> write and modify the work OR in any format that could >>> demonstrably be translated back and forth to one of those >>> formats without loss of information." >> This wording is even worse than "source format", IMHO. > > Here, Josselin, I agree with you. The best definition of source > that I know of is the one found in the GPL. > We will have to agree on disagreeing, then. :-) The definition on the GPL (section 3, paragraph 1 [1]) has many ambiguities, the main one IMHO being: "Preferred form for making modifications". Preferred by whom? Preferred by the upstream author? Preferred by some mid-stream modifier (Debian, for instance)? Preferred by the last downstream modifier (the user, making customizations)? Where does this leave binary blobs embedded in kernel sources, for instance? [1] "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. " -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is "VIGRA Artistic License" licence free and GPL-compatible ?
@ 26/09/2005 13:30 : wrote Florent Bayle : Le Lundi 26 Septembre 2005 17:21, Humberto Massa a écrit : [...] And it's not GPL-compatible at all. Does that means that I can't use this library in a program under GPL ? In that case, how can some GPL'ed programs be linked with Win32 libraries under Windows ? Sorry for these stupid questions, but I've some difficulties with all these licencing problems. This is another, different, can of worms. The "canon" here says you cannot use this library in a GPL'd program unless you are the copyright owner of the GPL'd program and add to the license an exception "you can link with VIGRA, even though it's not GPL'd". -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is "VIGRA Artistic License" licence free and GPL-compatible ?
@ 26/09/2005 05:28 : wrote Florent Bayle : Since someone want to package[1] Vigra library[2], I wan't to know if VIGRA Artistic License[3] is DFSG compatible and if I can use this library in a GPL'ed program. As far as I can see, this licence is free, but not compatible with GPL, because of : "4. You may otherwise modify your copy of this Library in any way, provided that you insert a prominent notice in each changed file" But I'm not a lawyer, and it's why I want your point of view. Thanks. [1] : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251616 [2] : http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ [3] : http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/LICENSE full text of the license: > The VIGRA Artistic License > == > (modeled after the Perl Artistic License) > > > Preamble > > > VIGRA may be copied, such that the author maintains some semblance > of artistic control over the development of the library, while > giving the users of the library the right to use and distribute > VIGRA in a more-or-less customary fashion, plus the right to make > reasonable modifications. > > > Definitions > --- > > "Copyright Holder" of the VIGRA library is Ullrich Koethe, > Cognitive Systems Group, University of Hamburg, Germany. > > "Library" refers to the collection of files distributed by the > Copyright Holder under the name "VIGRA" (including this LICENSE > file and all accompanying documentation), and derivatives of that > collection of files created through textual modification. > > "Standard Version" refers to the Library if it has not been > modified, or has been modified in accordance with the wishes of > the Copyright Holder as specified below. > > "You" is you, if you're thinking about using, copying, modifying > or distributing this Library. > > "Freely Available" means that no fee is charged for the item. It > also means that recipients of the item may redistribute it under > the same conditions they received it. > > "Reasonable copying fee" is whatever you can justify on the basis > of media cost, duplication charges, time of people involved, and > so on. (You will not be required to justify it to the Copyright > Holder, but only to the computing community at large as a market > that must bear the fee.) > > > License terms > - > > 1. You may make and give away verbatim copies of the Standard > Version of this Library without restriction, provided that you > duplicate all of the original copyright notices, this license, and > associated disclaimers. > > 2. The Standard Version of the Library may be distributed as part > of a collection of software, provided no more than a reasonable > copying fee is charged for the software collection. > > 3. You may apply bug fixes and portability fixes derived from the > Public Domain or from the Copyright Holder. A Library modified in > such a way shall still be considered the Standard Version. > > 4. You may otherwise modify your copy of this Library in any way, > provided that you insert a prominent notice in each changed file > stating how and when you changed that file, and provided that you > do at least ONE of the following: > > a. place your modifications in the Public Domain or otherwise > make them Freely Available, for example by allowing the > Copyright Holder to include your modifications in the Standard > Version of the Library. This goes beyond copyleft and is non-free, because it violates DFSG#3, restricting the distribution of derivative works. > > b. use the modified Library only within your corporation or > organization. > > c. make other distribution arrangements with the Copyright > Holder. > > 5. You may distribute programs which use this Library in object > code or executable form without restriction. > > 6. Any object code generated as a result of using this Library > does not fall under the copyright of this Library, but belongs to > whomever generated it, and may be sold commercially. > > 7. The name of the Copyright Holder or the Library may not be used > to endorse or promote products derived from this software without > specific prior written permission. > > 8. THIS LIBRARY IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR > IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED > WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE. > >IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY >SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY >KIND OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA >OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF SUCH >DAMAGES, OR ON ANY THEORY OF LIABILITY ARISING OUT OF OR IN >CONNECTION WITH THE USE OR PERFORMANCE OF THIS LIBRARY. > IMHO works licensed under this would be free if (and only if) clause (4.a.) is changed by something less abrangent like "your modifications and any modified version of the Libra
Re: Linux Documentation Project License (LDPL) v2.0
@ 24/09/2005 14:22 : wrote Francesco Poli :
> Hi all! :)
>
> The default LDP license v2.0 is adopted by a number of HOWTOs,
> some of them currently distributed in main. The problem is: I'm
> *not* conviced that such documents comply with the DFSG. I would
> like to discuss the DFSG-compliance of a work released solely
> under this license (excluding other legal issues, such as
> trademarks, patents, and so forth).
>
>
> =-=-=-=-= License text follows: =-=-=-=-=
>
>
>LINUX DOCUMENTATION PROJECT LICENSE (LDPL) v2.0, 12 January
>1998
>
> I. COPYRIGHT
>
> The copyright to each Linux Documentation Project (LDP)
> document is owned by its author or authors.
>
> II. LICENSE
>
> The following license terms apply to all LDP documents, unless
> otherwise stated in the document. The LDP documents may be
> reproduced and distributed in whole or in part, in any medium
> physical or electronic, provided that this license notice is
> displayed in the reproduction. Commercial redistribution is
> permitted and encouraged. Thirty days advance notice via email
> to the author(s) of redistribution is appreciated, to give the
> authors time to provide updated documents.
AOK so far.
>
> A. REQUIREMENTS OF MODIFIED WORKS
>
> All modified documents, including translations,
> anthologies, and partial documents, must meet the
> following requirements:
Oops. Anthologies? See my rant on "mere aggregation" below.
>
> 1. The modified version must be labeled as such.
Borderline, but free.
> 2. The person making the modifications must be
> identified.
Yellow alert -- dissident test. Marco d'Itri is extremely vocal
against the Dissident Test, but I think anonymity is necessary for
Free Software.
> 3. Acknowledgement of the original author must be
> retained.
OK
> 4. The location of the original unmodified document be
> identified.
This may get annoying when mixing various same-license docs, but OK
IIRC.
> 5. The original author's (or authors') name(s) may not be
> used to assert or imply endorsement of the resulting
> document without the original author's (or authors')
> permission.
OK.
>
> In addition it is requested that:
More requests, they are all OK, because they are not mandatory.
>
> 1. The modifications (including deletions) be noted.
> 2. The author be notified by email of the modification
> in advance of redistribution, if an email address is
> provided in the document.
>
> As a special exception, anthologies of LDP documents may
> include a single copy of these license terms in a
> conspicuous location within the anthology and replace
> other copies of this license with a reference to the
> single copy of the license without the document being
> considered "modified" for the purposes of this section.
>
> Mere aggregation of LDP documents with other documents or
> programs on the same media shall not cause this license to
> apply to those other works.
I hate this GPL phrase ("mere aggregation" = Lawyer-bomb). How does
one differentiate between an anthology work (covered by section "A"
above) and a "mere aggregation"? What is "the same media"? Does a
single ELF executable aggregating things -- including docs covered
by this license count as "the same media"?
>
> All translations, derivative documents, or modified
> documents that incorporate any LDP document may not have
> more restrictive license terms than these, except that you
> may require distributors to make the resulting document
> available in source format.
Another lawyer-bomb: "source format". Especially without definition.
>
> LDP documents are available in source format via the LDP
> home page at http://sunsite.unc.edu/LDP/.
>
>
> ---
>
> LDP Policy Appendices
>
> A. TO USE THE LDP LICENSE
>
> LDP authors who want to use the LDP License should put the
> following statement in their document:
>
> Copyright (c) by . This document may be distributed only
> subject to the terms and conditions set forth in the LDP
> License at .
>
> Authors may include a copy of the license in their documents,
> as well. If they do so, they have the option of ommitting the
> appendices.
>
> B. TO USE THE LDP LICENSE, BUT PREVENT MODIFICATION
>
> LDP authors who want to prevent modification to their document
> should put the following statement in their document:
>
> Copyright (c) by . This document may be distributed only
> subject to the terms and conditions set forth in the LDP
> License at , except that this document must not be
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: 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
> 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: GPL, yet again. (The kernel is a lot like a shared library)
> We SHOULD be taking an individual work and analyzing it > for creative content. Not cooking up arbitrary hypotheses > and pretending they mean something I am going to try taking some hours this weekend and verify one of the programs + libcurl + openssl cases. I'll get back to you next week. > I don't have a specific answer. That depends on the creative content > of X and Y. > > But, in general terms, I'd be looking for creative ideas (ideas first > expressed in Y) which are incorporated into X. For example, if > X will serve as a replacement for Y, that would strongly hint (but > not guarantee) that X is a derivative of Y. One last thing: not even this. Following this reason, the GNUTLS SSL shim would be a derivative work of OpenSSL. And it's not. Remember, the whole argument I'm giving is: 1. the GPL can only restrict the distributions of an original work or its derivatives; and 2. the only way to determine if a work is a derivative work of another is going thru the abstraction/filtration/comparison process. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
** 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 s
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
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 void sort(I, I);
---
ends up in a program a.out because a.cc #included , 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, bu
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)
> 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)
> 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: 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: 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: 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. > > > &
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 ...
> > 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: 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: 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: 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: 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 ...
> 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: 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: GPL, yet again. (The kernel is a lot like a shared library)
> On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa > Guimar?es wrote: > > > If you're going to make an argument at odds with established > > > understanding and industry practice then you'll have to > come up with > > > more than that. > > > > > > There's an awful lot of lawyers and law professors who > think that the > > > GPL works. Go start by arguing with them. > > > > I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. > > You are the one who is supposedly attempting to offer an argument > here. Not me. I'm just telling you why yours is broken. That doesn't No, you are not "telling me why my argument is broken". If you are trying, you're not being very clear. Why is my argument broken exactly? > require a counter-argument in this case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: GPL, yet again. (The kernel is a lot like a shared library)
** Sean Kellogg :: > On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: > > There's an awful lot of lawyers and law professors who think > > that the GPL works. Go start by arguing with them. > > Based on my readings of law review articles and the common legal > arguments surrounding the GPL, the reason it works is because the > GPL is a contract. The linking clause is a contractual term that > you must agree to in order to receive a copyright license. Pretty > standard forbearance. But... there is _no_ linking clause in the GPL (*). Unless you are telling me that the "How to Apply These Terms to Your New Programs" is a binding part of the contract, which I will also dispute, because the mentioned title is immediately after a big, all-caps "END OF TERMS AND CONDITIONS" in the GPL. > > I know of no legal professional, outside of the FSF, who believes > the GPL stands up as a pure copyright license. Ditto. (*) see: $ grep -n -i -C link gpl.txt 336-This General Public License does not permit incorporating your program into 337-proprietary programs. If your program is a subroutine library, you may 338:consider it more useful to permit linking proprietary applications with the 339-library. If this is what you want to do, use the GNU Library General 340-Public License instead of this License. $ grep -n -i -C how.to.apply.these gpl.txt 280- END OF TERMS AND CONDITIONS 281- 282:How to Apply These Terms to Your New Programs 283- 284- If you develop a new program, and you want it to be of the greatest -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
> 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)
> > 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)
> 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)
> 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)
** 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
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)
** 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)
** 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: 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: May be non-copyrighted documment included in main?
** MJ Ray :: > Francesco Poli <[EMAIL PROTECTED]> wrote: > > On 18 Aug 2005 17:37:05 GMT MJ Ray wrote: > > > As such, the permission granted to copy it and use any part with > > > attribution is needed and might be sufficient > > With no permission to modify? > > It's a hack, but you can use the part before the word changed and > the part after the word changed, with another word in between. It > would be far far far nicer to hDve explicit permission, but being > allowed to copy parts *might* be sufficient. 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. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
** 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
** 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
> > 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
** 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
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 form
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
** 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.7&view=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 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
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 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.
** 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: 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
** 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. > Me too. 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: 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: LPPL and source-less distribution
(Puzzled) Who's who in your analogy? > Leviticus 24:16: And he that blasphemeth the name of the LORD, he > shall surely be put to death, and all the congregation shall certainly > stone him: as well the stranger, as he that is born in the land, when > he blasphemeth the name of the Lord, shall be put to death. > > I think stoning has been replaced by flaming nowadays. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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
* Florian Weimer :: > * Måns Rullgård: > > > I was of the impression that Quake 2 had been placed on an > > official list of restricted publications, and that this was the > > primary cause of concern. > > Does Debian distribute the data files? The engine itself is not > on the German Index Librorum Prohibitorum. > > But this doesn't matter at all. Our guardians became frustrated > with the necessity to index both the German translation and the > original, so they installed a mandatory rating system for computer > games (similar to movies in Germany and other countries). The > main problem isn't that quake2 is a violent game, but that it's a > game. "M-x tetris RET" has the same problem. And so, what seems to be the solution to this problem? -- HTH, Massa
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: 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]
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: 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]
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: > > >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: 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?
* 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: Creating a Debtags 'license' facet
* Andrew Suffield :: > On Thu, Jun 09, 2005 at 12:17:42PM +0200, Enrico Zini wrote: > > On Fri, Jun 03, 2005 at 10:06:48PM +0100, Andrew Suffield wrote: > > > On Fri, Jun 03, 2005 at 04:20:05PM +0200, Enrico Zini wrote: > > > You've got a problem with this one, because licenses can be > > > combined conjunctively and disjunctively. So a package might > > > be both entirely under foo and entirely under bar (foo || > > > bar), or it might be partially under foo and partially under > > > bar (foo && bar). > > > > If that is the only problem, a package can be tagged with more > > than one tag even from the same facet, which would be good > > enough to categorise your two examples. > > Imagine a package that can be distributed if you meet the terms > of: > > - the GPL > - both the MIT license and the 4-clause BSD license, > simultaneously > - both the MIT license and the Artistic license, simultaneously > > How would you tag this, so as to capture all this information? ( GPL ) || ( MIT && 4BSD ) || ( MIT && Artistic ) ?? :-) this is the easy one, what if some files are provided under each of those licenses? GPL + (MIT && 4BSD) + (MIT && Artistic)? Mozilla would be (GPL || MPL) + (GPL || ...) + ... ?? -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New 'Public Domain' Licence
* M.K.Edwards :: > So I think it turns out I was right in the first place: continued > verbatim copying and distribution counts as "utilization", and the > only scope for argument is about how much bug-fixing you can do > after termination without being sued for "preparing" a new > derivative work. anyway, to take this thread back to the topic, I ask: is there anything that would be accomplished by a "public domain" license that is *not* accomplished by putting the work under the MIT license? I don't think so. And, if I am right, to avoid license proliferation and other undesired (and undesirable) interactions with various jurisdictions' laws, it seems to me that the best thing to do if you want to donate your work to the public would be putting it under the MIT license. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
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
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...
RES: Where to put Open Transport Tycoon (openttd)
De: MJ Ray [mailto:[EMAIL PROTECTED] > > "Michael K. Edwards" <[EMAIL PROTECTED]> wrote: > > Have you read any of the OpenTTD web site? Here's a couple of > > snippets from the "About" page: > > > > An open source clone of the Microprose game "Transport > > Tycoon Deluxe". > > > > OpenTTD is modeled after the original Transport Tycoon game by > > Chris Sawyer and enhances the game experience dramatically. Many > > features were inspired by TTDPatch while others are original. > > [...] This is precisely the relationship that a game > > sequel bears to the original . [...] > > I disagree. A sequel would have (a) different game/s and not just > a different game engine. This seems much closer to an alternative > player for the same files (the mplayer model) than the Duke Nukem > case you cited repeatedly, as far as I can tell. I ended up agreeing with him after considering that the gaming experience contained in the code could be considered part of the "mise en scene" of the game and, as such, part of copyrightable creative expression. > > I'm also disappointed by the mix of personal attacks, analogies, > detailed case specifics and foreign languages in this thread. > Please try to explain to the laymen instead of handwaving. I took a little bit of offense reading this last paragraph; in parts: * personal attacks: yeah, this was the low point of this thread, and I think both Raul and Michael should moderate themselves... myself, if I exceeded any courtesy boundaries, I apologize; * analogies and detailed case specifics: well, I imagined that a debian-legal discussion, to be able to reach *any* meaningful conclusion about matters of law, should be akin to a real-world legal discussion (full of analogies and detailed case specifics); * foreign languages: it would not be difficult to understand that this point is the one I took most offense in your comment; I try not to disrespect the English-language nature of the list, and I make the effort to translate (the best I can in my limited knowledge of English and English-legalese) every statute, case law, and doctrine information that I have in Portuguese; if in some rare occasions I quote the original or try to give a Spanish translation, it's intenting to make myself more clear. Do you reaaly think I (or other) over-used foreing languages in this thread? Could you give an example, so I (or others) could *not* make the same mistake again, please? -- Thanks, HTH, 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: 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]
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: Where to put Open Transport Tycoon (openttd)
De: Michael K. Edwards [mailto:[EMAIL PROTECTED]
> Note that there is no question (IANAL, TINLA) that openttd
> infringes the copyright on Transport Tycoon in any jurisdiction
> that recognizes the doctrine of "mise en scene", i. e., pretty
> much any jurisdiction that has a copyright law. See Micro Star v.
> FormGen.
I don't recall if 17USC117 makes any mention of it, but functional
cloning of any program is protected by Brazilian Computer Programs
Law in art.6, III (''It does not constitute infringement on the
computer program author's rights: [...] III - the occurrence of a
program similar to other, preexistent, when the similarity is by
force of the functional application characteristics _or_ of the
observance of technical or normative regulations _or_ limitation of
alternative form for its expression'' -- underlines and terrible
English translation are mine).
>
> In general, Debian should not be distributing game clones, in
> main, in contrib, or anywhere else. The fact that copyright
> holders rarely bother to pursue legal action against half-assed
> clones of obsolete games does not mean that they are legitimate in
> the eyes of the law.
The mise en scene infringement would only be in the case of the
maps and scenery of the game, which, in casu, won't be distributed
by Debian. Anyway, you are quite right that game clones are not
completely legitimate in principle, exactly because they would
*normally* come with the infringing sprites, maps, sceneries, etc.
>
> Cheers,
> - Michael
--
HTH
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
-- 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
Re: What makes software copyrightable anyway?
De: Raul Miller [mailto:[EMAIL PROTECTED] > > > On 5/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> > wrote: > > "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... > > I'm not sure what you mean here. > > I can do something like: > > $ apt-get install quagga ... > Starting Quagga daemons (prio:10):. > $ What did Debian distribute? A working copy of Quagga? No, the only "working" copy of Quagga is in *YOUR* machine, after *you* got it from the Net or CD, installed the files in the right places, etc. > > This shows that installing the package is equivalent to running > quagga. More of the same. The package does not come installed from Debian. > > According to the debian readme, this doesn't have ssl, even if > you've installed the suggested libsnmp. To run the version which > includes ssl support, I have to use different commands, such as: > > mkdir t > cd t > I_WANT_OPENSSL=yes apt-get -b source quagga > dpkg -i quagga*.deb > > These commands are easily deduced from the debian readme. > > Of course, this might not work on the first try, because you might > also need to install some of the dependencies (such as libcap-dev, > tetex-bin and texinfo). And, of course, you need to be root or > you can't install debian packages. But "it might not work" is not > the same thing as "it won't work". > It still does not configure that Debian is distributing some "working" version of Quagga. > And, clearly, there is some intent to distribute a version of > Quagga with SSL support. > > So, what can we do about this? What are the exact terms of distribution of Quagga, libssl, and libsnmp? > > Personally, I like Ted T'so's suggestion (that Quagga be packaged > with an alternate ssl implementation so that we can legally > distribute quagga with ssl support). As long as there isn't some > significant aspect of quagga which only work with the versions of > ssl which have silly trademark promoting requirements (like > requiring the openssl.org boilerplate to be present when you > mention openssl's features) we should be fine. I don't think it's necessary. But I do think that we should ask the guys from Quagga to clarify their license (add a linking exemption). If they don't agree, then, as a matter of courtesy, we should try the other remedies, not excluding zapping Quagga out of the repo if needed. > > If we don't do that, we might cause someone or some group (perhaps > some of us) to get stuck with paying openssl.org some heavy > license fee, to release openssl under gpl compatible terms. Or, > maybe we'll create a situation requiring some other sort of > settlement. And, if that's not necessary, why should we do such a > thing? > > I don't know what the probability of legal action is in this > specific case, nor what the probabilities are that it would > succeed, but as a general rule (where this doesn't leave us stuck > in contradictions) we try to respect upstream's wishes in the > context of their software. > > For a strictly legal point of view, I'll quote > http://practice.findlaw.com/20questions-1203.html > > "More copyright litigation can definitely be expected ." > > On the social contract side of the fence: giving some precedence > and respect to the stated wishes and requirements of upstream > (when dealing with their software) tends to be in the best > interests of the free software community. > Agreed. -- HTH, Massa
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]
Re: What makes software copyrightable anyway?
Michael K. Edwards wrote: >On 5/12/05, Humberto Massa <[EMAIL PROTECTED]> wrote: > >>Anyway, I was not talking about distributing the "working" >>hello_world (if you are referring to the working set of it in RAM, >>after loaded -- after all, this is the only thing that "performs" >>when a file is dynalinked) > >Note also that all of the early precedents in the US with respect >to run-time copyright infringement, unauthorized computer >maintenance, etc. have been supplanted by 17 USC 117. Run-time >copies are unreachable by copyright infringement claims in the US. In Brasil we have a similar clause in our Computer Programs Law (art.6,IV) that stipulates that any actions indispensable to make (authorized) use of the program are non-infringing. > >Cheers, >- Michael > -- Cheers, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Michael K. Edwards wrote: >Note that your argument contains correct logic but incorrect facts. >libsnmp is more or less BSD licensed ( >http://www.net-snmp.org/about/license.html ). It is Quagga that is >GPL'ed. Substitute, say, a GPL'ed HTTP client library in place of >libsnmp, and it's all good. > Yes, that's why I used "Considering..." (I am without WWW access for some time at day-work-time to check the facts -- I do my fact-checking by night, my arguing by day) -- Cheers, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: The working hello_world program is a collection. This program (hello_world) taken in isolation will not perform. This is irrelevant. Its creative status independs of its performance. You are saying that hello_world in isolation will not perform. Neither will the debian package of the daemon that links with libsnmp and libssl. Neither will the (dynamically linked) executables inside such package. Anyway, I was not talking about distributing the "working" hello_world (if you are referring to the working set of it in RAM, after loaded -- after all, this is the only thing that "performs" when a file is dynalinked) -- HTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: On 5/12/05, Humberto Massa <[EMAIL PROTECTED]> wrote: I will do my "repeated assertion" act: It's a dynamically linked executable, for the love of $DEITY! Which makes it a collective work. Collective works can be eligible for copyright protection, even if the only creative effort that went into them is the selection and arrangement of their contents. DY-NA-MI-CA-LLY. It does not contain any part of any other work. How can it be a collective work? You can argue that hello_world is insufficiently creative to be eligible for copyright protection, but that argument can't hold in the general case. No, I was considering hello_world sufficiently creative for the sake of argument. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote:
>On 5/12/05, Humberto Massa <[EMAIL PROTECTED]> wrote:
>
>>Suppose the libc runtime is given in some system by a work named
>>gpld_libc. Is hello_world.c a derivative work of gpld_libc ? I
>>don't think so.
>>
>>#include
>>
>>int main(int, char**)
>>{
>> puts("Hi");
>> return 0;
>>}
>>
>>
>>What is a dynamically compiled file hello_world? An intangible
>>medium containing: my hello_world.c work, translated automatically
>>+ (possibly) some (non-protectable by virtue of defining an
>>interface) bits grinded by the compiler/linker, extracted from
>>gpld_libc (eg, compiler macros, etc). Can I distribute it under
>>any license I see fit? Yes, I think so.
>
>That depends on what went into the binary.
>
Usually, in a dynamically-linked binary (as is the case you
responded to), the only links extraneous to the original work are
those that are not protectable.
>
>For example, if hello_world now provides fourth order Runga-Kutta
>solutions, I'd probably need to know whether the code which
>provides this functionality is licensed such that I can
>redistribute it.
>
I object, because this paragraph is irrelevant. I already stated
what is hello_world.c, and it's unreasonable to think that its
dynamically linking would provide or even contain
Runga-Kutta-whatever.
>If hello_world does nothing more than print a string, this might
>not be a big issue. Or it might be. For example, if "print a
>string" requires a full copy of some proprietary firmware because
>the compiler target was an emulator for some proprietary hardware.
>
I will do my "repeated assertion" act: It's a dynamically linked
executable, for the love of $DEITY!
>
>I"ll avoid presenting any GPL examples, since that seems overly
>contentious.
>
Oh, but those are the juicy ones.
-- HTH Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote:
On 5/12/05, Humberto Massa <[EMAIL PROTECTED]> wrote:
You inverted the "do more" and "do less". Publishing an arbitrary set
of
anthologies is "do more" as compared to publishing one story.
Ok, here's my current understanding: permission to distribute sources
does not constitute permission to distribute binaries. The principle
under Brazilian law seems to be that restrictions on distribution of
sources automatically apply to binaries.
You managed to mangle something very simple.
1. Permission to distribute sources is ... a permission to distribute
sources.
2. Permission to distribute binaries is ... a permission to distribute
binaries.
3. Permission to distribute some work is ... a permission to distribute
said work in any form, and fixated in any medium, tangible or
intangible, including binary and source form.
Which one is given in the GPL? #1 and #2.
GPL#1 gives you permission to distribute verbatim copies of the source,
in any medium.
GPL#2 gives you permission to make derivative works, as long as you do
one of 2.a, 2.b, or 2.c; furthermore (IMHO at least) it gives you
permission to make anthology works containing the original work; and it
gives you permission to distribute your derivative or anthology work.
GPL#3 gives you permission to distribute executable or binary copies of
the work as long as you do one of 3.a (possibly combined with 3§2), 3.b,
or 3.c; furthermore, it gives you permission to distribute (your)
derivative work in executable or binary form, provided you already did
one of 2.a, 2.b, 2.c, under the same conditions.
Suppose the libc runtime is given in some system by a work named
gpld_libc. Is hello_world.c a derivative work of gpld_libc ? I don't
think so.
#include
int main(int, char**) {
puts("Hi"); return 0;
}
What is a dynamically compiled file hello_world? An intangible medium
containing: my hello_world.c work, translated automatically + (possibly)
some (non-protectable by virtue of defining an interface) bits grinded
by the compiler/linker, extracted from gpld_libc (eg, compiler macros,
etc). Can I distribute it under any license I see fit? Yes, I think so.
What is a statically compiled file hello_world? An intangible medium
containing: my hello_world.c work, translated automatically +
(automatically) selected parts of gpld_libc. Can I distribute it under
any license I see fit? Yes, I think so... as long as I obey 3.a (c/w
3§2), 3.b, or 3.c WRT glibc (as I am now distributing glibc together
with my hello_world program).
This certainly clarifies arguments about the GPL in the context of
Brazilian law.
I hope it is more clear now.
Thanks,
Ok. Now (again) back to the libssl problem.
Is a daemon "dx.c" that when compiled, links with libsnmp, and
indirectly with libssl, a derivative work of any of them? In principle, no.
Considering dx.c is not a derivative work of libsnmp nor of libssl, and
that libsnmp is GPLd and libssl is BSD/4-clause-licensed (incompatible
licenses), can I distribute an executable file, statically compiled,
that contains dx.c + libsnmp + libssl? Yes, as long as I do one of 3.a,
3.b, 3.c WRT libsnmp.
Under the same assumptions, can I distribute an executable file,
dynamically compiled of dx.c? YES. With NO STRINGS ATTACHED. Under any
license I see fit, provided I am the copyright holder of dx.c.
I want to explain that I understand why Debian tries to avoid this kind
of situation, as a matter of courtesy (supposing the copyright owner of
libsnmp interprets the GPL the same as the FSF FAQ), but it seems to me
that clarifications and explicit linking exceptions should be sought
*first*, and that the "offending" software should be removed only if the
copyright holder *denies* such clarifications.
--
HTH,
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Contract and Tort Law and the GPL
Raul Miller wrote: It's been suggested that existing case law with respect to copyrights always is based on contract law, and that the GPL can only be understood in terms of contract law. (...) However, there is the other option: Tort Law. I don't know and I won't try to figure out if your argument hold any merit in the USofA jurisdiction. But I just want it to be known that it does not hold any water in Brasil or any similar jurisdiction because: a) we don't have tort law as defined in the USofA (unfortunately, we don't even have punitive damages); b) all software licenses are considered "computer program use license contracts" under the Computer Programs Law (9609/98) and, as such, are to be read under our contract law, that is defined by our Civil Code combined with our Consumer Protection Act, with the specific limitations in 9609/98. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: That is your mistake: it's not the pages that carry protection, it's the words and illustrations on the pages (as in abstract, intelectual entities) that carry protection. I thought copyright was protection for creative works in tangible form. You seem to be saying that copyright is protection for creative works in intangible form? Even in 17USC (102), copyright is a protection to something that is "fixed in a tangible medium [...] or communicated in any way". It is the abstract thing that is protected, not the concrete. >In this situation, for the GPL to grant you license to make copies, >you would have to rely on the GPL's grant to make verbatim copies >of the program. If the transformations needed to build the program >are not considered verbatim under Brazilian law, then the GPL fails >to grant license to make copies in those cases. No, because of the principle that if you can do copies of the source, and aggregate it with other stuff, then you can apply automated transformations on it. He who can do more (copy the source, redistribute), can do less (copy the binary, redistribute) as long as the conditions are met. In other words, if a book publisher has permission to publish a story, the publisher also has permission to publish an arbitrary set of anthologies which contain that story -- no additional permissions are needed (at least with respect to that story)? You inverted the "do more" and "do less". Publishing an arbitrary set of anthologies is "do more" as compared to publishing one story. Thanks, -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: >On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: > >>Raul Miller wrote: >> >On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: >> >>We have a "brocardo" (legal axiom) in our doctrine: "He who can >> >>do more, can do less" (horrid translation to "quem pode mais, >> >>pode menos" ["Quién puede más, puede menos" in Spanish]). So, >> >>if the binary is the result of an automated, >> >>non-easily-reversible process over the source, and if you grant >> >>me the right to distribute the source (ie, I can do more), you >> >>are implicitly granting me the right to distribute the binary >> >>(ie, I can do less). Now, you can in the conditions to your >> >>grant, explicit that if I am distributing it in another form, >> >>then I must distribute it in the source form (or do at least >> >>one of the things section 3 enumerates, in the case of the >> >>GPL). >> > >> >Ok, this doesn't sound like the source is equivalent to the >> >binary but that the binary is protected the same way the source >> >is. In other words, you probably have a special legal category >> >for "derivative which is not creative enough to be granted >> >copyright protection which is distinct from the original". >> >>Not really. The work is the content, not the form. Suppose two >>(dead-tree) copies of my book "How to Die...", one being a >>hardcover, and the other begin a paperback. Suppose further that >>the imagery in the cover, etc are identical in both books. > > >This doesn't sound like an application of that legal principle. > >You don't get a paperback from a hardback, or a hardback from a >paperback. You produce each independently. Intelectually, no. You don't produce either, intelectually. You just print them, physically. What you do produce, intelectually, is the content of both (which is the same in casu, and you produced only one time). > >This legal principle seems more analogous to: If the hardback is >protected by copyright then pages ripped out of the hardback are >protected by copyright. The pages ripped out are not equivalent to >the hardback, but they carry the same protections. > That is your mistake: it's not the pages that carry protection, it's the words and illustrations on the pages (as in abstract, intelectual entities) that carry protection. See, in 9610/98, art 7, caput, we have ''Intelectual works protected [by this Law] are the creations of the spirit, expressed by any means and fixated in any medium or support, tangible or intangible, known or to be invented in the futures, as for example:'' (hideous translation and braces are mine). This is AFAIK boilerplate text copied directly from the Berne text (I may be wrong in this account, tho). >>I am not convinced of this, either: the word "transformation" was >>in the quotation of 17USC101 WRT derivations. And no case law >>presented in those threads lead me to believe that automated >>transformations are to be regarded as derivative works. > > >Well... the GPL does clarify what it means by a "work based on the >Program" in a fashion which I believe does incorporate transformed >works. However, you've asserted that this would not be the case >under Brazilian law. > Yes, I believe that the "namely" part does not carry any weight in any law, but I am pretty sure of it under Brazilian Law. >If that's so, it might very well be the case that under Brazilian >law there are anthologies which are not considered, under law, to >be derivatives. > Yes. Anthologies are not derivatives under Brazilian Law. They carry copyright protection, too, but they are definitively not derivatives. > >In this situation, for the GPL to grant you license to make copies, >you would have to rely on the GPL's grant to make verbatim copies >of the program. If the transformations needed to build the program >are not considered verbatim under Brazilian law, then the GPL fails >to grant license to make copies in those cases. No, because of the principle that if you can do copies of the source, and aggregate it with other stuff, then you can apply automated transformations on it. He who can do more (copy the source, redistribute), can do less (copy the binary, redistribute) as long as the conditions are met. > >If I sincerely belived this to be the case, I'd consider it a bug >in the GPL and would report the details of why this is likely to be >the case to the FSF. I do. And I consider it a bug in the GPL (as opposed to the stated intent of
Re: What makes software copyrightable anyway?
Raul Miller wrote: >On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: > >>Raul Miller wrote: >> >>>On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: >>> >>>>Nope. Binaries are the same work as (the anthology of) their >>>>sources, in the eye of the Law 9609/98. >>>If I understand you correctly, this means that under Brazilian >>>law, distribution of binaries would satisfy a legal requirement >>>that source be distributed. >>> >>No, because a legal requirement that source be distributed (as in >>GPL section 3) is exactly that: a requirement that the *source* is >>distributed. Not less. The fact that the source is *equivalent* to >>the (corresponding) binary WRT copyright law has nothing to do >>with the requirement. > > >But if they're equivalent with respect to copyright law, they are >equivalent for license grants under copyright law. > >>We have a "brocardo" (legal axiom) in our doctrine: "He who can do >>more, can do less" (horrid translation to "quem pode mais, pode >>menos" ["Quién puede más, puede menos" in Spanish]). So, if the >>binary is the result of an automated, non-easily-reversible >>process over the source, and if you grant me the right to >>distribute the source (ie, I can do more), you are implicitly >>granting me the right to distribute the binary (ie, I can do >>less). Now, you can in the conditions to your grant, explicit that >>if I am distributing it in another form, then I must distribute it >>in the source form (or do at least one of the things section 3 >>enumerates, in the case of the GPL). > > >Ok, this doesn't sound like the source is equivalent to the binary >but that the binary is protected the same way the source is. In >other words, you probably have a special legal category for >"derivative which is not creative enough to be granted copyright >protection which is distinct from the original". Not really. The work is the content, not the form. Suppose two (dead-tree) copies of my book "How to Die...", one being a hardcover, and the other begin a paperback. Suppose further that the imagery in the cover, etc are identical in both books. The work, on which I grant copyright licenses, is the contents of the book, its sequence of words and illustrations, not the form. The two books are only ONE work WRT copyright law. When we do a translation, for instance, from Portuguese to English, the translator is doing a derivative work because he has to intelectually choose the words he will use in the other language, in a non-automatable fashion. If I grant RMPH the right to publish my work, without restriction of form, then they can get my text, pass it thru Babelfish, and publish it in English or German or Japonese, as long as they don't modify it. Now, when I grant them the right to publish my work, I usually *will* restrict the form with clauses as such: "RMPH can publish this book verbatim, in the original Portuguese language, with this exact typesetting, and its cover must be made of leather with gold-plated letters and drawings." This is where resides the difference between binary and source: form/medium. And form/medium is not part of the work, it is as external to it as is the material of the cover of a book. This way, you grant the exact same protections to hello_world.c and to hello_world because they are the same work, but the author has the option to specify the form/medium: "you can only redistribute hello_world.c in its verbatim source code form by any medium or in ELF compiled with gcc form, and the distribution medium is a 3.5in diskette." > >In this case, I'd assert that the word "derivative" in American law >should be translated such that it includes (rather than excludes) >this concept from Brazilian law. I am not convinced of this, either: the word "transformation" was in the quotation of 17USC101 WRT derivations. And no case law presented in those threads lead me to believe that automated transformations are to be regarded as derivative works. > >>>If this is really the case, the GPL is just a more complex >>>version of > >the BSD license, under Brazilian law. > >>Nope. Again, what exactly are you trying to know? > > >I'm trying to establish what the words you're using mean. Maybe I was more clear now? > >Thanks, > -- HTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: However, on the flip side -- if binaries are the same work as the sources under the eyes of the law, then you can't construct any licenses which treat sources differently from binaries. They're the same. Anyone who has the right to distribute binaries also has the right to distribute sources. Nope. You still can stipulate the form in your license. In the lines of "I grant to Raul Miller Publishing House the right to publish my book How to Die without a Penny for Dummies, as long as said publisher makes it in the form of a hardcover." I'm not sure if that's really the case, but if it is the case it certainly addresses some of the problems which triggered the GPL in the first place. Nope. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: If the GPL does not apply, all parts are non-GPLed parts. Ok. The question with libsnmp is whether the routing daemon uses the SSL functionality. If not, there should be no problem -- it's mere aggregation, and we're just being sloppy about our packaging. If the routing daemon does use the SSL code then we've got a licensing problem. Why? My argument is exactly that, using or not SSL functionality, as long as the aggregation obeys libssl's license, there is no licensing problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: Nope. Binaries are the same work as (the anthology of) their sources, in the eye of the Law 9609/98. If I understand you correctly, this means that under Brazilian law, distribution of binaries would satisfy a legal requirement that source be distributed. ?!?!?! No, because a legal requirement that source be distributed (as in GPL section 3) is exactly that: a requirement that the *source* is distributed. Not less. The fact that the source is *equivalent* to the (corresponding) binary WRT copyright law has nothing to do with the requirement. We have a "brocardo" (legal axiom) in our doctrine: "He who can do more, can do less" (horrid translation to "quem pode mais, pode menos" ["Quién puede más, puede menos" in Spanish]). So, if the binary is the result of an automated, non-easily-reversible process over the source, and if you grant me the right to distribute the source (ie, I can do more), you are implicitly granting me the right to distribute the binary (ie, I can do less). Now, you can in the conditions to your grant, explicit that if I am distributing it in another form, then I must distribute it in the source form (or do at least one of the things section 3 enumerates, in the case of the GPL). If this is really the case, the GPL is just a more complex version of the BSD license, under Brazilian law. Nope. Again, what exactly are you trying to know? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: Once again: if Section 0 does not apply, then the GPL does not apply, and therefore the GPL can't grant you license to copy that work. Ok... are you arguing that you *still* have to comply to the license of the non-GPLd parts? If so, yes, you are right. But where (in practice) does this takes us eg, IRT libsnmp (which was the start of the discussion)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: Nope. Binaries are the same work as (the anthology of) their sources, in the eye of the Law 9609/98. Hmm... I'd have expected them to be viewed as translations of the original. Fortunately, even if you are correct, most of the potentially contested works would likely have to be translated from English to Portugese, so they'll probably still be derivatives of GPLed works. And, even if that's not the case, the development process itself would tend to guarantee that any significant GPLed works are derivatives of other GPLed works. So you'd still be allowed to distribute them. What was the question? If you want to know if you are allowed to distribute GPL'd binaries, yes, you are, because the GPL (which is the "computer program use license contract" under 9609/98) grants to the licensee the right to redistribute. The GPL imposes, though, some conditions (section 3) that you must meet so you can redistribute the binaries. -- HTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: (presenting a very reasonable argument, but...) >Let's say that we have a court case which involves some contested >GPLed work. How should we proceed? > >First, let's consider a work which doesn't have any binaries. This >would be no different from any other copyright case -- you have to >show that the work in question is copyrighted under the GPL, and >you'd have to show that the terms of the GPL are being violated. >This should be relatively simple, and we can neglect sections 2 and >3 (which are clearly being complied with if the rest of the license >is being followed). > >Now let's imagine that we've got a case which involves binaries. >What do we have to do? > >First, we need exhibits: the sources, and the binaries. Out of >consideration for the court, we want to pick examples which are as >simple as possible while representing all of the important >contested issues. So let's imagine we have Exhibit A (the sources) >and Exhibit B (the binary). [We need to also show that this binary >is representative of something which is being distributed, but >that's not really different from what you have to do in other >copyright cases, so I'll ignore that part.] > >Second, we need to show that Exhibit B is derived from Exhibit A. >Again, we want to present this in a simple and easily >understandable form, and we want to also present complete >information. > >Once we've shown that B is derived from A, we can start examining >the terms of the GPL to make sure that they are being followed. > >For example, let's say now that we're the defending party, and we >want to show that the mere aggregation clause applies. To do this, >we would show that the disputed work could be replaced by something >trivial, and that having done so, the program is still the same >program -- we might do this by showing that it still has the same >behavior. Your argument here is interesting but it can be used to *prove* mere aggregation... and... > >Switching sides again, if someone asserted that the mere >aggregation clause applied, and used program behavior to make that >assertion, and I believed that mere aggregation did not apply, I >would show how the program failed to operate in some independent >context, with the disputed section removed. It can *not* be used to *disprove* mere aggregation... because the defendant can substitute the disputed part for something *not* trivial (as in, substituting libssl by libtls or something) and the program will continue to work as usual. > >Is that clear enough? > >Now, back to the argument: an argument has been raised that the GPL >is flawed because a "work based on the Program" defined in two >parts, where the first part asserts that "work based on the >Program" is a derivative work. The assertion has been made that >the second part of that definition is meaningless. > >Let's assume that this assertion is true, that the second part of >that definition is meaningless. Let's further assume that I can >construct an example case where a work isn't covered by the GPL >because the second part of that definition is meaningless. What >would that mean? It would mean you have a work that is a mere aggregation, and the GPL explicitly permits the licensee to distribute the merely-aggregated work. > >Since Section 0 says that the GPL grants you license to distribute >this work, and since there's no part of the GPL that grants you >license where Section 0 does not apply, in our hypothetical case we >would have shown that the GPL does not grant you license to >distribute this work. You are still ignoring section 2, paragraph 3. My argument is the following: any work containing the Program or parts of it that is not a derivative work of the Program is, necessarily, an anthology work containing such part of the Program and, as such, is permitted by GPL #2§3 as a (mere) aggregation. > >At this point, either: > >A) Copyright law doesn't apply, so it doesn't matter that you don't >have license, or > >B) The GPL doesn't apply, so it doesn't matter that the GPL doesn't >grant you license, of > >C) Distributing the work is prohibited by law. > >My argument is that if you reach C) by ignoring the second half of >the definition of "work based on the Program", that you're doing >something wrong. > >Does that make sense? > Yes. But I agree to disagree with you. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Raul Miller wrote: On 5/11/05, Humberto Massa <[EMAIL PROTECTED]> wrote: 2.a. it specifies (art. 7, XII) that computer programs are protected by copyrights. 2.b. it further specifies (art. 7 § 1) that computer programs have specific legal provisions (all contained, nowadays, in our Computer Programs Law [Lei 9609/98]). But, presumably, binaries are still considered to be derived from their sources? Nope. Binaries are the same work as (the anthology of) their sources, in the eye of the Law 9609/98. -- Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
Michael K. Edwards wrote: When I try to reconcile early case law -- just from the US circuit courts -- on the copies, derivative works, collections, and dungheaps made during run-time, and which routine uses are infringing and which aren't, the little engine in my non-lawyer head threatens to throw a rod. And that's still how it is thirty years later, because the people whose job it is to do something about it have run aground. Instead of a workable Federal statute, parallel to copyright, patent, and (Federal) trademark -- something that balances public and special interests to set ground rules for fair trade in this new class of intangible goods -- we in the US get abortions such as patents on mathematical laws and business models on one hand and UCITA (a dead letter outside the DC catchbasin) on the other. And can you really say that Europe or Latin America or Australasiafrica is doing any better? It seems to me that in Brasil the situation is a little better: 1. we are not a common law jurisdiction. 2. our copyrights statute -- Author's Rights Law (Lei 9610/98) -- is fairly recent. 2.a. it specifies (art. 7, XII) that computer programs are protected by copyrights. 2.b. it further specifies (art. 7 § 1) that computer programs have specific legal provisions (all contained, nowadays, in our Computer Programs Law [Lei 9609/98]). 3. our trademarks+patents statute -- Industrial Property Law (Lei 9279/96) -- is also fairly recent. 3.a. it has the (genius IMHO) art. 10 that excludes from patent protection (translation mine): '' I - discoveries, scientific theories and mathematical methods; II - purely abstract conceptions; III - schemes, plans, principles or methods applied to commerce, accounting, finances, education, publicity, fiscalization or lotteries; IV - literary, architetonic, artistic, scientific works or any aesthetical creation; V - computer programs; VI - information presentations; VII - gaming rules; VIII - operatory or surgical methods and techniques, as well as therapeutical or diagnosis methods, for applications on human or animal bodies; and IX - all or part of natural living beings and biological materials encountered in nature, even if isolated, including genoma and germoplasm [?] of any natural living being and natural biologic processes. '' 4. even if, unfortunately, our Computer Programs law treats all computer program copyrights licenses as use licenses contracts, we have a Consumer Defense Act that puts strict limits in what types of clauses should be allowed in such contracts. Unless, of course, you give it away. Then you start charging people a dollar a minute for answers and five dollars a minute for right answers, unless Mystery Guy's already looked at it in which case it's a hundred-dollar flat fee (it's going to be a hard one but you'll get net help out of him). That's based on some kind of rational cost + profit economics instead of an endless overhang of sunk costs and residuals. Dumb looks, of course, are still free. This, surprisingly enough, works even though it makes sense -- ask IBM. Hmm, that only matters for stuff that raises questions instead of answers them by itself. But that, actually, is where the money in _software_ is (as opposed to software monopolies) -- stuff that lets you do more, better, so you have new questions to ask. Add a premium for real originality, too, if it's clear that some kinds of innovation can't be funded without it. Software patents are anathema around here and I'm not even going to try to root for them when today's USPTO is playing goalkeeper; but believe it or not, that would be fixable if software economics wasn't a pipe dream. This scenario have the further advantage of generating more jobs, and -- important for thirdworlders -- more *local* jobs. It generates more jobs here AND abroad, and this is maybe the most important point of Free Software macroeconomics IMHO. For starters, you recognize that bits on disk aren't really a single type of good, they're two. No, not 0s and 1s. Not Program and Data either, that's so 1950. You've got your digital "soft goods" like recorded music and movies and e-books and video games and other kinds of e-toys -- consumables that people feed into orifices other than their mouths. And then you've got the software that runs the world. I don't know if I see the difference, but... So yes, U. S. Federal District Court of Indiana, take the GPL away from us open-source zealots. And put it in the law books where it belongs. Cheers, - Michael (RMS, Linus, if you ever read this I hope you think it is funny and not insulting.) With all respect I have for both, I don't know if RMS's coding is superior to Linus'... :-) Massa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
