Re: Proposed statement wrt GNU FDL
On Wed, 2003-05-07 at 02:14, Branden Robinson wrote: Another good argument against the GNU FDL. Not to mention that publishing known false statements, like claiming it is a GNU Manual or that the FSF publishes copies, is of dubious legality. signature.asc Description: This is a digitally signed message part
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, 2003-05-07 at 19:11, Edmund GRIMLEY EVANS wrote: P is not a derived work of GPLLib, but P+GPLLib is likely to be a derived work of GPLLib, in which case it is not allowed to distribute them together. In [EMAIL PROTECTED], I posted the legal definition of a derivative work in the United States at least, taken from Title 17 USC, Section 101. To repeat: 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''. (Title 17 USC, Sec. 101) From the definition, I don't see how it could be argued that P is not a derivative work of GPLLib, unless P happens to be on the same CD-ROM (ftp site, etc.) as GPLLib. I can see (though not agree with) that the binary image created in memory may be a derivative work. But the GPL allows arbitrary use, so there is no license violation. If it dumps core, though, you may not be able to redistribute the core. :-) BTW: Beware DFSG 1 when arguing that P alone is distributable, GPLLib alone is distributable, but together, they are not. This isn't always true, such as with the system components exception to the GPL, but its something to certainly be wary of. I think an interpretation of either that DFSG and GPL that renders the GPL non-free is strange. However, you could certainly distribute P on its own if you could reasonably claim that P is useful without GPLLib. I'll further argue that P is not based upon GPLLib in any meaningful manner; it includes absolutely no part of GPLLib. There are other implementations of grep, ls, etc, so it would certainly be all right to distribute the GPL-incompatible shell script on its own. Sure. Assuming, of course, that the shell script doesn't use any GNU extensions, which is quite a big assumption. Many scripts use GNU extensions. Especially on Debian, which is a GNU system after all. How many other tars accept a j option, for example? It ain't in SUSv2. Neither is z, for that matter. which is probably doable if the script makes relatively minor use of grep, etc I think you'd have a very hard time finding scripts which make minor use of GPL utilities. Even our cat program (like everything else in coreutils) is GPL. So is our echo program. signature.asc Description: This is a digitally signed message part
Re: LPPL and non-discrimination
On Tue, 2003-05-06 at 13:38, Jonathan Fine wrote: Suppose ABC Software takes a DFL and from it creates a new license (call it ABC-DFL) by adding the clause: If the licensee is ABC Software Inc then the licensee may freely incorporate this work into its proprietary software. My question is this: Does this ABC-DFL license meet the Debian Free Software Guidelines? It probably leaves a bad taste in the mouth of everyone on this list, but yes. You're coming closest to violating DFSG 3, if, for example, the license required me to actively notify ABC Software, Inc. of the changes. signature.asc Description: This is a digitally signed message part
Re: LPPL and non-discrimination
On Thu, May 08, 2003 at 02:03:34AM -0400, Anthony DeRobertis wrote: It probably leaves a bad taste in the mouth of everyone on this list, but yes. You're coming closest to violating DFSG 3, if, for example, the license required me to actively notify ABC Software, Inc. of the changes. Some of Branden's arguments in http://lists.debian.org/debian-legal/2003/debian-legal-200303/msg00829.html may be relevant to the license Jonathan asked about, but probably not with respect to DFSG5/6, so it may not be relevant to his real question. That is, the text he gave may pass DFSG5/6, but be non-free for other reasons. I don't know if there was any consensus reached from the above post. -- Glenn Maynard
Re: PHP-Nuke License Conclusion?
Scripsit Branden Robinson [EMAIL PROTECTED] On Wed, May 07, 2003 at 04:53:03PM +0200, Henning Makholm wrote: Scripsit Branden Robinson [EMAIL PROTECTED] Debian interprets this License and herein to mean the conditions of the GNU GPL expressed in its text; no more and no less. s/Debian/Branden Robinson/ I hadn't noticed any objections to my analysis, Well, good job then that you managed to reply to mine. (Don't have the archive link with me right now, but will dig). -- Henning Makholm Jeg forstår mig på at anvende sådanne midler på folks legemer, at jeg kan varme eller afkøle dem, som jeg vil, og få dem til at kaste op, hvis det er det, jeg vil, eller give afføring og meget andet af den slags.
Re: various opinions on Debian vs the GFDL
Scripsit Anthony Towns aj@azure.humbug.org.au An XML score satisfies all these requirements as a way of representing music. We're not talking about music; we're talking about *sound recordings*. All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. If you accept it for sound recordings, yoy should accept it for every other kind of data as well, and the whole GFDL concept of opaque/transparent formats goes down the drain. (Which means that yours is not an interpretation of transparent that is likely to be used by a court). Simply being able to cut up the sound and insert your own pre-recorded sound effects is probably enough to satisfy that requirement actually Says who? So you call it free even if you can't remove something? * you can revise it with a text editor easily enough Only for certain kinds of changes. That's not enough. to be is Anthony My name is easy, eg; Not without losing any semblance of sensible prosody. * the format's been designed to make it as easy as possible to modify, not arranged to thward anything As easy as possible is still not easy enough to quialify as possible. The questions at hand here are can you license sound stuff under the GNU FDL, and, if not, can the GNU FDL possible be DFSG-free. I think the answer to the first question is yes, and, even ignoring that, I'm not really convinced the answer to the second is no. If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. -- Henning Makholm That's okay. I'm hoping to convince the millions of open-minded people like Hrunkner Unnerby.
Re: various opinions on Debian vs the GFDL
On Thu, May 08, 2003 at 09:24:21AM +0200, Henning Makholm wrote: Please respect Debian list policy and my Mail-Followup-To header, and don't Cc me. An XML score satisfies all these requirements as a way of representing music. We're not talking about music; we're talking about *sound recordings*. Actually, we're just talking about embedding sound in a GNU FDL document. Music, in case you hadn't noticed, is one form sound takes. All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. Well, no, it's not. The question is what changes do you want to make. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. Simply being able to cut up the sound and insert your own pre-recorded sound effects is probably enough to satisfy that requirement actually Says who? So you call it free even if you can't remove something? Seems pretty easy to me to delete a tag and its contents form an XML file. * you can revise it with a text editor easily enough Only for certain kinds of changes. That's not enough. Really? How do you remove all the buffer overflows from mozilla with a text editor? A lot of analysis, study, and tedious editing, no? Same thing with most of the edits you want to do to a sound file. Some things are easy, some things aren't. Big deal. to be is Anthony My name is easy, eg; Not without losing any semblance of sensible prosody. Again, so what? The sorts of revisions you can do with sound are fundamentally limited; that you can't easily do everything conceivable means nothing at all. * the format's been designed to make it as easy as possible to modify, not arranged to thward anything As easy as possible is still not easy enough to quialify as possible. That's completely irrelevant too: the question that's answering is whether the formats specifically designed to thwart modifications. It's not. The questions at hand here are can you license sound stuff under the GNU FDL, and, if not, can the GNU FDL possible be DFSG-free. I think the answer to the first question is yes, and, even ignoring that, I'm not really convinced the answer to the second is no. If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpYONySb4uWG.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED]: However, you could certainly distribute P on its own if you could reasonably claim that P is useful without GPLLib. I'll further argue that P is not based upon GPLLib in any meaningful manner; it includes absolutely no part of GPLLib. If P is useless without GPLLib, then it might be argued that by distributing P you are encouraging people to link it with GPLLib and are thus indirectly distributing a combined work P+GPLLib which infringes GPLLib's licence. That's why the existence of alternative implementations of GPLLib is important. (Even the existence of alternative GPL implementations might help.) However, if Debian were to distribute P and GPLLib in such a way that P uses GPLLib by default, then I would guess there is potentially a problem even if there are alternative non-GPL implementations of the library. which is probably doable if the script makes relatively minor use of grep, etc I think you'd have a very hard time finding scripts which make minor use of GPL utilities. Even our cat program (like everything else in coreutils) is GPL. So is our echo program. I suppose I should explain what I mean by minor, though I'm not quite sure myself. Perhaps one could compare with the situation where someone distributes a summary of someone else's novel, compared with where someone distributes a criticism of the novel that also summarises it in the course of criticising it. I don't have any legal evidence for this idea, but I suspect that in addition to how much is taken from or used from another work, what else a work contains may be relevant in deciding whether it is a derived or an independent work. Edmund
Re: various opinions on Debian vs the GFDL
Scripsit Anthony Towns aj@azure.humbug.org.au On Thu, May 08, 2003 at 09:24:21AM +0200, Henning Makholm wrote: We're not talking about music; we're talking about *sound recordings*.=20 Actually, we're just talking about embedding sound in a GNU FDL document. Music, in case you hadn't noticed, is one form sound takes. But not the only one. All the XML scores in the world will not allow me to recreate a particular sound recording (made with real live musicians, in the case it contains music). Therefore, an XML score is not source. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. If one need to use a compiler that only you have, I'd say that your binary is not free. Samples and recordings are more difficult, mainly because the concept of revision doesn't really exist, per se. One possibility is just to do a hex dump -- it's as straightforwardly editable with a hex editor as _anything_ is, after all Any opaque format is straightforwardly editable with a hex editor. Well, no, it's not. It was your claim that sound could be edited in hex form. If that is true, then anything else can be similarly edited in hex form. The question is what changes do you want to make. Nowhere in the GFDL does it say that it is OK for a transparent format to make only certain kinds of changes possible. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. And if you want to change the words of a poem read alouf, I don't think you're going to be able to do that if I give you a hexdump of a PCM file. OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. My point is exactly that *no* way of editing sound files will allow me to do the kind of changes we normally require for freedom. Only for certain kinds of changes. That's not enough. Really? How do you remove all the buffer overflows from mozilla with a text editor? A lot of analysis, study, and tedious editing, no? Yes, but it's possible in principle. Same thing with most of the edits you want to do to a sound file. No, they are not possible in principle. Not without losing any semblance of sensible prosody. Again, so what? So I cannot reasonably make trivial edits and have results that have reasonable quality. The sorts of revisions you can do with sound are fundamentally limited; Exactly. Therefore, sound is opaque no matter what format it is in. That's completely irrelevant too: the question that's answering is whether the formats specifically designed to thwart modifications. The thwart modifications language in the GFDL applies only to unconventional uses of otherwise transparent formats. The definition of transparency is; | A Transparent copy of the Document means a machine-readable copy, | represented in a format whose specification is available to the | general public, that is suitable for revising the document | straightforwardly with generic text editors or (for images composed | of pixels) generic paint programs or (for drawings) some widely | available drawing editor, and that is suitable for input to text | formatters or for automatic translation to a variety of formats | suitable for input to text formatters. I maintain that this effectively excludes any conceivable sound format. If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. I *cannot* distribute a transparent copy of my spoken performance, because no such copy is possible, as argued above. -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: LPPL and non-discrimination
Scripsit Richard Braakman [EMAIL PROTECTED] The NPL (Netscape Public License; parts of Mozilla still use it) has this feature. Check out part V of the Additional Terms: V.2. Other Products. Netscape may include Covered Code in products other than the Netscape's Branded Code which are released by Netscape during the two (2) years following the release date of the Original Code, without such additional products becoming subject to the terms of this License, and may license such additional products on different terms from those contained in this License. Uh... does Covered Code include modifications that third parties make? If so, then we have a problem. -- Henning MakholmDe kan rejse hid og did i verden nok så flot Og er helt fortrolig med alverdens militær
Re: Bug#168554: Status of Sarge Release Issues (Updated for May)
Branden Robinson [EMAIL PROTECTED] wrote: Actually it does. GNU TLS's OpenSSL compatibility layer is licensed under the GPL, not the LGPL, last time I checked. This would cause problems for at least some works we distribute. Indeed it is. I was referring to MySQL in particular, not debian in general. It still has implications, but maybe less nasty. -- MJR http://mjr.towers.org.uk/ IM: [EMAIL PROTECTED] This is my home web site. This for Jabber Messaging. How's my writing? Let me know via any of my contact details.
Re: LPPL and non-discrimination
On Thu, May 08, 2003 at 11:35:07AM +0200, Henning Makholm wrote: Uh... does Covered Code include modifications that third parties make? If so, then we have a problem. 1.3. Covered Code means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof. (Note that this came up during the initial discussions about the NPL; I don't know if those discussions were held on debian-legal, though.) It might not be a very big problem. The NPL is per-file, not per-program. I checked some files in mozilla looking for NPL-licensed ones, and all the ones I found were triple-licensed NPL/GPL/LGPL. I didn't do the scripting work needed for a thorough scan, though. Richard Braakman
Re: various opinions on Debian vs the GFDL
On Thu, May 08, 2003 at 11:30:15AM +0200, Henning Makholm wrote: OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. My point is exactly that *no* way of editing sound files will allow me to do the kind of changes we normally require for freedom. ... If it is not possible to license sound under GFDL (which I believe it is not), then the GFDL says that I must not make a modification of the work that consists of reading it aloud on a sound recording. I think that's quite easily non-free. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. I *cannot* distribute a transparent copy of my spoken performance, because no such copy is possible, as argued above. This argument might have been convincing several years ago, but it kinda flounders when coming on the heels of a series of (commercial) games which used text-to-speech technology instead of prerecorded audio data. Given a decently large sample (say, your spoken performance) it is possible to generate a fairly convincing sample with different words in it; the rest is just work with a non-linear audio editor. Or, hey, ever play with soundtracker-style mod files? This is much like saying that transparent copies of paintings are not possible, because once committed to canvas they can't be modified. Technology has improved since then. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK
Re: LPPL and non-discrimination
Glenn Maynard [EMAIL PROTECTED] writes: A license that says modify and distribute all you want; keep my name; don't add additional restrictions to the license implicitly requires that you allow your modifications to be used proprietarily, since it prevents you from adding the GPL's safeguards against it. I'd find that license to be obnoxious (and it'd be incompatible with most other licenses), but it doesn't seem non-free. Yeah, a viral anti-copyleft license -- that would be odd. But probably not non-free, you're right. But that's not really the same as requiring that a particular group be able to relicense your code however they like. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: LPPL and non-discrimination
Anthony Towns aj@azure.humbug.org.au writes: On Wed, May 07, 2003 at 12:32:04PM -0400, Jeremy Hankins wrote: Why not? A license like the GPL, but with a clause requiring that Foo Inc. have the right to relicense any derivative works as they please is DFSG free? I'm not sure that's particularly like the GPL, but yes, it is. DFSG-free means that it can be included in Debian, maintained by our maintainers and used by our users. Now you're being silly. Surely you're not proposing that as an adequate reformulation of the DFSG? Are you saying restrictions on modification are OK so long as they don't narrow the scope of possible modifications? I.e., the license can make you jump whatever hoops it likes before modifying, and the bare fact that it allows modification is enough? So a license that requires payment before modification, or ritual sacrifice, or dancing a jig, or sending a postcard -- these are all DFSG free? Assuming that you agree that a license that requires payment before modifications can be made (i.e., no modifications are permitted, but if you pay $X you can have a license that permits modifications) isn't DFSG free, how is that different from requiring permission for a specific party to relicense your work however they see fit? -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: LPPL and non-discrimination
On Thu, May 08, 2003 at 11:35:07AM +0200, Henning Makholm wrote: Scripsit Richard Braakman [EMAIL PROTECTED] The NPL (Netscape Public License; parts of Mozilla still use it) has this feature. Check out part V of the Additional Terms: V.2. Other Products. Netscape may include Covered Code in products other than the Netscape's Branded Code which are released by Netscape during the two (2) years following the release date of the Original Code, without such additional products becoming subject to the terms of this License, and may license such additional products on different terms from those contained in this License. Uh... does Covered Code include modifications that third parties make? If so, then we have a problem. No moreso than we already have with the GPL; just like with the GPL, if you can't comply because you aren't in a position to grant the required permissions on the Covered Code, you have no right to distribute your modifications. -- Steve Langasek postmodern programmer pgpd6n7vrAAKc.pgp Description: PGP signature
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, May 07, 2003 at 09:39:25PM -0500, Branden Robinson wrote: On Wed, May 07, 2003 at 01:12:09PM -0400, Anthony DeRobertis wrote: On Wednesday, May 7, 2003, at 01:50 AM, Branden Robinson wrote: Or are you wanting to restrict the problem domain to cases where an interface innovated in a GPLed library hasn't been cloned yet? Given: 1) Library GPLLib is under the GPL 2) Perl module Iface provides an interface to various implementations of similar features, and the user selects which implementation to use 3) Perl modules PM uses GPLLib to implement Iface 4) Perl program P is under a GPL-incompatible license Question: Is is permissible for P to use PM through Iface? I would say yes, and I think that 2) is the critical issue. Edmund GRIMLEY EVANS raised a good point. GPL clause 0 says The act of running the Program is not restricted. Your question should be rephrased as: Question: Does the GPL permit people to distribute P with GPLLib? The answer probably depends on the circumstances, but distributing alternative implementations of Iface with P, not just the GPLLib implementation of Iface, makes the answer an almost certain yes. -- G. Branden Robinson| If you're handsome, it's flirting. Debian GNU/Linux | If you're a troll, it's sexual [EMAIL PROTECTED] | harassment. http://people.debian.org/~branden/ | -- George Carlin pgpz2Ctve4vR4.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, May 08, 2003 at 06:07:10AM +1000, Anthony Towns wrote: As far as I know, we're happy to accept non-free stuff in pristine .orig.tar.gz's as long as it's not used. If you don't have a pristine .orig.tar.gz anyway, then it's silly to include unused non-free stuff, but it's not cause for a REJECT. Well, that's weird, because back when we had the xc/util/patch problem with XFree86, I asked if it was okay if I just let the sleeping dog lie until the next upstream release, and nobody said yes. http://lists.debian.org/debian-ctte/2001/debian-ctte-200108/msg00034.html Maybe the answer depends on how angry one has made the FTP admins lately... :) -- G. Branden Robinson| The last Christian died on the Debian GNU/Linux | cross. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpCGwFI3uW6q.pgp Description: PGP signature
Re: LPPL and non-discrimination
On Tue, May 06, 2003 at 06:38:14PM +0100, Jonathan Fine wrote: Suppose ABC Software takes a DFL and from it creates a new license (call it ABC-DFL) by adding the clause: If the licensee is ABC Software Inc then the licensee may freely incorporate this work into its proprietary software. My question is this: Does this ABC-DFL license meet the Debian Free Software Guidelines? I'll dodge the question a little and say that I don't think a work of software licensed under such terms would be Free Software, and thus would not be distributable as part of a Debian OS. * If the work has been modified so trivially that no independent copyright can attach to the work, then, in the United States anyway, ABC Software Inc can do the above without needing to compel a license from the modifier. In the U.S., copyright does not attach to trivial modifications. * If the work has been substantially modified such that it is a derivative work under U.S. copyright law, then the above clause is effectively demanding consideration in exchange for rights granted under the license. In the U.S., copyrights are negotiable assets, and are presumably of some value. The clause might as well say: Substantial modifications are permitted, and may be distributed, at which point the modifier must either pay to ABC Software Inc the sum of USD 1,000 for each occurrence of distribution by the modifier, or grant to ABC Software Inc a permanent, non-exclusive, paid-up, royalty-free, irrevocable license to incorporate the modified work or any portion thereof into its own proprietary software. I feel sure that such a clause would immediately start alarm bells ringing in almost any Debian developer's head; why they do not so when other licenses confiscate things of value from modifers of free software is a mystery to me. I cannot express any informed opinions on this subject when it comes to the copyright laws of countries other then the U.S. -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpAOV4mvefX1.pgp Description: PGP signature
Re: PHP-Nuke License Conclusion?
On Thu, May 08, 2003 at 09:14:30AM +0200, Henning Makholm wrote: Scripsit Branden Robinson [EMAIL PROTECTED] On Wed, May 07, 2003 at 04:53:03PM +0200, Henning Makholm wrote: Scripsit Branden Robinson [EMAIL PROTECTED] Debian interprets this License and herein to mean the conditions of the GNU GPL expressed in its text; no more and no less. s/Debian/Branden Robinson/ I hadn't noticed any objections to my analysis, Well, good job then that you managed to reply to mine. (Don't have the archive link with me right now, but will dig). The message to which I am referring is: http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00294.html -- G. Branden Robinson|One man's theology is another man's Debian GNU/Linux |belly laugh. [EMAIL PROTECTED] |-- Robert Heinlein http://people.debian.org/~branden/ | pgpq1jXZjAY7L.pgp Description: PGP signature
Re: [OT] Droit d'auteur vs. free software? (Was: query from Georg Greve of GNU about Debian's opinion of the FDL
Henning Makholm [EMAIL PROTECTED] writes: sub 2. The work must not be changed or made available to the public in a way or in a context that violates the author's literary or artistic reputation or character. And this is the number one lose for this bogus sort of copyright regime. For example, Marcel Duchamp would have been prohibited.
Re: [OT] Droit d'auteur vs. free software?
Henning Makholm [EMAIL PROTECTED] writes: Of course they are. The fact that the author intends for his work to be free is made very explicit by applying the GPL to it. Since moral rights are about protecting the author's intentions with creating the work, there cannot, logically, be any conflict between moral rights and freedom. Moral rights protect things even when they are *not* the author's intention.
Re: [OT] Droit d'auteur vs. free software? (Was: query from Georg Greve of GNU about Debian's opinion of the FDL
Arnoud Galactus Engelfriet [EMAIL PROTECTED] writes: Note that the distortion or mutilation has to hurt the honor or reputation of the author. Here in the Netherlands this is the case if the owner of a house decides to put up new blinds in a color the architect does not like. Since people will know this wasn't the architect's design, how does it damage his honor or reputation?
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Wed, May 07, 2003 at 12:50:30AM -0500, Branden Robinson wrote: On Mon, Apr 28, 2003 at 05:58:15PM -0500, Steve Langasek wrote: Any chance you'd care to comment on the underlying question of whether Debian should or should not accede to the FSF's claim that GPL modules for interpreted languages demand GPL scripts? I believe Anthony and I are at an impasse; we simply disagree on the relative weight that should be given to various factors involved here, so no consensus is likely to be forthcoming between the two of us. I've been away from the list for a few days, but using Mutt to limit the message view to subjects including the string interp reveals no messages I haven't already read. I recall a message from you referring to the GPL FAQ which confusingly talks about whether people can run GPL-incompatible scripts with a GPLed interpreter, which only serves to cloud the issue since The act of running the Program is not restricted. Apparently, I haven't expressed myself very clearly. Yes, I'm not saying a user running such a script would be violating the GPL; the GPL doesn't speak to running the program, and the GPL is non-binding on users. I'm also not talking about any cases where a script is distributed separately from the interpreter, or where the bindings for the interpreted language are distributed separately from the GPL library that they make available to the script; these are gray areas, and not germane to the activities of Debian or its redistributors. I am specifically addressing the case where: - a library, libfoo, available under the GPL - an interpreter, pargle, available under a GPL-compatible license - a module that provides bindings for scripts written in pargle to use libfoo, also available under a GPL-compatible license from a different upstream - a script, fooadmin.prg, under a GPL-incompatible license are all distributed together in such a manner that running the script causes pargle to load libfoo for use by fooadmin.prg. The *act* of running fooadmin.prg is not a violation; but the facts of how this code is combined into a single runtime executable at the instant of running, without any conscious intent on the part of the user, show, I believe, that the distribution of such a combined work constitutes a violation on the part of the distributor. The GPL FAQ supports this interpretation, saying, If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them. Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. The FSF's statement is really much farther-reaching than I believe it has any grounds to be (see the gray areas above), but if it has any merit at all, the case is strongest when distributing all the components together in a single product (operating system or otherwise). So my questions for debian-legal are, Do you believe the GPL FAQ presents a legally valid interpretation of the GPL, as it pertains to the case of combined distribution described above? Do you believe this interpretation is *applicable* to GPL code that is copyright FSF, to code that is copyright MySQL AB, and to GPL code in general? Why or why not? If this interpretation is applicable in some or all cases, could Debian be in violation for using GPL commandline utilities from GPL-incompatible scripts? If not, how are commandline utilities different from language bindings for an interpreted language?
Re: [OT] Droit d'auteur vs. free software?
Scripsit Thomas Bushnell, BSG Henning Makholm [EMAIL PROTECTED] writes: Of course they are. The fact that the author intends for his work to be free is made very explicit by applying the GPL to it. Since moral rights are about protecting the author's intentions with creating the work, there cannot, logically, be any conflict between moral rights and freedom. Moral rights protect things even when they are *not* the author's intention. Did you read the exact wording I posted? It very specifically protects exactly the author's intention. Nothing more. -- Henning Makholm PROV EN FORFRISKNING FRISKLAIL DEM
Re: LPPL and non-discrimination
Branden Robinson [EMAIL PROTECTED]: Substantial modifications are permitted, and may be distributed, at which point the modifier must either pay to ABC Software Inc the sum of USD 1,000 for each occurrence of distribution by the modifier, or grant to ABC Software Inc a permanent, non-exclusive, paid-up, ~ royalty-free, irrevocable license to incorporate the modified work or any portion thereof into its own proprietary software. I feel sure that such a clause would immediately start alarm bells ringing in almost any Debian developer's head; why they do not so when other licenses confiscate things of value from modifers of free software is a mystery to me. It's a non-exclusive licence, so nothing is being confiscated. Obviously the modifier is losing the possibility of granting someone else an exclusive licence, but that's the case with the GPL, too. Edmund
Re: LPPL and non-discrimination
Scripsit Steve Langasek [EMAIL PROTECTED] On Thu, May 08, 2003 at 11:35:07AM +0200, Henning Makholm wrote: Uh... does Covered Code include modifications that third parties make? If so, then we have a problem. No moreso than we already have with the GPL; just like with the GPL, if you can't comply because you aren't in a position to grant the required permissions on the Covered Code, you have no right to distribute your modifications. I was speaking about the apparent If you make any modifications you have to pay Netscape by allowing them to take your modifications proprietary effect, which IMO would make the license non-free. If, as Richard says, the NPL-covered source that goes into Debian is actually dual-licensed with GPL, then of course there is no problem. -- Henning Makholm ... and that Greek, Thucydides
Questioning the Public Domain'ness of certain data
Hi Everyone, I have written a program that parses the data available here: http://www.fda.gov/cder/ndc/ and places it into a database. I am fairly confident that the data itself is public domain as: * one organization sells the same data re-packaged for MS Access. * another organization releases basically the same data in a different format. The second example, if I recall correctly, doesn't even cite the source although I went over the data personally and can say without hesitation that the data came from the FDA and is essentially the same as in the data available at the above URL. But, however, I have not had seen anything in writing specifically stating that the data is public domain and I received no reply when I asked them the license of the data via the email address on the above-cited webpage. My intention is to release a debian package containing Berkely DB databases that contain the same data as found in the above-cited URL. How do you suggest I proceed? Sincerely, Elizabeth
Re: Questioning the Public Domain'ness of certain data
On Thu, 08 May 2003, Elizabeth Barham wrote: I have written a program that parses the data available here: http://www.fda.gov/cder/ndc/ and places it into a database. Neat. My intention is to release a debian package containing Berkely DB databases that contain the same data as found in the above-cited URL. How do you suggest I proceed? As the information in that database changes rapidly [Data Files Updated through 3/31/2003], perhaps it would be better to include your program that downloads and parses the data on the site instead of including the data itself? I would presume that it is important to the end users of this dataset to have a relatively up to date set of data, and as the package of such data in stable could be out of date by more two years before the next stable release, they'd probably prefer a method of updating the dataset to an outdated one. Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, Chew more! Do more! The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpR7d0cJEFwk.pgp Description: PGP signature
Re: [OT] Droit d'auteur vs. free software?
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Thomas Bushnell, BSG Henning Makholm [EMAIL PROTECTED] writes: Of course they are. The fact that the author intends for his work to be free is made very explicit by applying the GPL to it. Since moral rights are about protecting the author's intentions with creating the work, there cannot, logically, be any conflict between moral rights and freedom. Moral rights protect things even when they are *not* the author's intention. Did you read the exact wording I posted? It very specifically protects exactly the author's intention. Nothing more. What if the author's intention is that anyone do whatever they want with the work, and explicitly says I hereby waive any of my so-called moral rights? In that case, his heirs can *still* come back and say no waiver is possible, and your modification of the work makes his artistic integrity look bad, and it will be their judgment and the court's that controls.
Re: GFDL Freeness and Cover Texts
Sam Hartman [EMAIL PROTECTED] writes: How is this any worse than an advertizing clause or a requirement to make a statement in supporting documentation? We consider both of those free. Advertising clauses only need to be there if you are advertising. They are also not enforceable in the US. A requirement to make a statement is problematic if the statement is extensive.
Re: motion to take action on the unhappy GNU FDL issue
Zack Weinberg [EMAIL PROTECTED] writes: (I suppose I could sue the FSF for violating its end of the copyright assignment contract, but that would be totally counterproductive). I think it might well be productive to point to the assignment contract, and insist that your content be removed.
Re: Knoppix and GPL
Sam Hartman [EMAIL PROTECTED] writes: 1) My interpretation of the GPL is correct, isn't it? I'm fairly certain on this one. Yes. 2) Am I being excessively unreasonable to complain to the authors about this GPL violation if it is actually getting in my way and making my life inconvenient? No. 3) Would anyone be willing to help with souch a complaint? In particular, I believe that someone who could point to convincing evdience that our interpretation of the GPL is correct would be useful. There may be a language issue and it is always nice to have something to say in response to No you are just reading that legal document incorrectly. In addition, if it becomes necessary is there anyone around who has contributed to GPLed software included in Knoppix who would be willing to formally complain as a copyright holder if it comes to that? Send it to the FSF's gpl enforcement team.
Re: various opinions on Debian vs the GFDL
On Thu, 2003-05-08 at 03:36, Anthony Towns wrote: We're not talking about music; we're talking about *sound recordings*. Actually, we're just talking about embedding sound in a GNU FDL document. Music, in case you hadn't noticed, is one form sound takes. That's right. You seem to keep wanting to discuss musical scores, which are a small subset of all sound. All the C code in the world won't let you recreate the last build I did either, unless I also give you the compiler I used. Big deal. Depending on the license. Well, no, it's not. The question is what changes do you want to make. If you want to change the location of two icons in a program, I don't think you're going to be able to do that if I give you a hexdump of an ELF executable. Why not? Personally, I've changed programs using hex dumps (though it was PEF, not ELF, but that's doubtfully relevant). OTOH, I don't think there are any revisions you can make to any sound file that you can't also make with a text editor to a suitable text dump of a WAV file. OK, try this one: Resample a hex-dumped WAV file from 48KHz to 44.1KHz using your text editor. Or mix several tracks down to one. Or do a phade out. Or, well, do just about anything. Sure, it's possible --- in the sense anything is possible. But it makes my job of moving that icon in an ELF executable look trivial. Same thing with most of the edits you want to do to a sound file. Some things are easy, some things aren't. Big deal. Yeah, and generally, when a license is the cause of the extreme uneasyness of modifying things, we don't call it free That's completely irrelevant too: the question that's answering is whether the formats specifically designed to thwart modifications. It's not. No. It is very relevant. The question is if making revisions is [straightforward] with generic text editors. That's wrong too: that would merely be an opaque copy which is entirely allowable, as long as you distribute a transparent copy as well. Of which, for sound, it appears there is no such thing as far as the FDL is concerned. signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
Just noticed another problem: A Transparent copy of the Document means a machine-readable copy, represented in a format ... that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. ... A copy that is not Transparent is called Opaque. Notice that a sound file, movie, etc., in any form, is not suitable for input to text formatters. It thus can't be a transparent format. I apparently can't make a training video from the EMACS manual; remember, my video is a modified version of the EMACS manual, and thus I am obliged to provide a transparent version which, under the definition above, I can't do. signature.asc Description: This is a digitally signed message part
Re: various opinions on Debian vs the GFDL
I'm going to try again... I think somehow, we got off on a tangent of sheet music which blurs the issue. Ignoring my previous message about not being able to have sound be a transparent copy at all: I hope we can agree that: 1) Transparent copies of a document are required for distributing printed copies in significant quantity 2) A transparent copy of a work must actually be a copy of it. Now, let's talk about a specific example: Let's say I want to make a music video with portions of the EMACS manual. Why? I'm crazy, that's why. Being crazy, I decide that the sound track will include the second part of Brahms' German Requiem, Denn Alles Fleisch. Why? Once again, I'm crazy. So, in order to get a recording under a an acceptable copyright license I hire an orchestra, a choir, etc. While listening to the singing Denn alles Fleisch es ist wie Gras und alle Herrlichkeit des Menschen wie des Grases Blumen... I start to wonder: What is a transparent copy of this work? At first, I think I'll just include the score. But upon closer reading of the GFDL, I notice that a transparent copy must be suitable for _automatic_ conversion. So, that rules out the score --- there is no automatic way to convert a musical score of Ein Deutsches Requiem, no matter how represented, to the audible form.[0] So that leaves me with my digital sampling. So I call the 96KHz, 48-bit[1] many-track full recording the transparent copy. Or at least I'd like to. I notice that a transparent format, unless a drawing or a painting, must be straightforwardly [editable] with generic text editors. So now I'm stuck. It's fairly easy to do all kinds of neat editing on sound, with programs designed to do so. But generic text editors sure aren't. Let's say that we allow that completely unmixed PCM data, as long as all editing is done through AJ's Special XML Format. That way, we can claim it's straightforward to modify with a text editor. So to mix the tracks (for example), I do: mix track id=firstViolin src=orch/violin1.wav channel id=1 volume=40 / channel id=2 vulume=60 / ... /track track ... /track ... /mix With 32 tracks[3], that 14:32 of transparent copy is a mere 15.3GB. Nothing major. So, the question is: Where have I erred? AFAICT, I can't use the score as the transparent copy. I can't use the PCM data as the transparent copy. Even if I could, it's too damn big to be of any use. Good thing I didn't even get to trying the do the video part, video is easy to edit with video editors; however, editing video with a text editor is once again, near impossible. [0] Just getting the instruments right is extremely hard even with very expensive synths; doing the singing is right out. [1] Not sure what rate/bit size is actually used today. [3] Google searches turn up studios using many more tracks, e.g., http://www.angelfire.com/id/dkstudios/, http://www.cavemanmusiconline.com/cl_about.html. I saw up to 128... signature.asc Description: This is a digitally signed message part
Re: GFDL Freeness and Cover Texts
On Thu, 2003-05-08 at 20:17, Thomas Bushnell, BSG wrote: They are also not enforceable in the US. Can you please provide a citation for this? I've never been able to come up with one. signature.asc Description: This is a digitally signed message part
Re: Bug#168554: Status of Sarge Release Issues (Updated for May)
On Thu, May 08, 2003 at 10:42:18AM -, MJ Ray wrote: Branden Robinson [EMAIL PROTECTED] wrote: Actually it does. GNU TLS's OpenSSL compatibility layer is licensed under the GPL, not the LGPL, last time I checked. This would cause problems for at least some works we distribute. Indeed it is. I was referring to MySQL in particular, not debian in general. It still has implications, but maybe less nasty. This of course assumes that the compatibility layer is used, as opposed to rewriting the relevant code to use GNUTLS natively... Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] If you can read this, you're too close.
Re: LPPL and non-discrimination
On Thu, May 08, 2003 at 09:09:03AM -0400, Jeremy Hankins wrote: Anthony Towns aj@azure.humbug.org.au writes: On Wed, May 07, 2003 at 12:32:04PM -0400, Jeremy Hankins wrote: Why not? A license like the GPL, but with a clause requiring that Foo Inc. have the right to relicense any derivative works as they please is DFSG free? DFSG-free means that it can be included in Debian, maintained by our maintainers and used by our users. Now you're being silly. Surely you're not proposing that as an adequate reformulation of the DFSG? It's the primary reason why the DFSG exists. Are you saying restrictions on modification are OK so long as they don't narrow the scope of possible modifications? I.e., the license can make you jump whatever hoops it likes before modifying, No, because that would mean we couldn't maintain it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpXkw4orWQzM.pgp Description: PGP signature
Re: motion to take action on the unhappy GNU FDL issue
Thomas Bushnell, BSG writes: I think it might well be productive to point to the assignment contract, and insist that your content be removed. I pulled it out of my files and reread it; the FSF's side of the agreement is a lot weaker than I remembered. The actual text is FSF agrees that all distribution of the Works, or of any work based on the Works, or the program as enhanced by the Works, that takes place under the control of FSF or its agents or successors, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to FSF or to anyone else for any permitted use of the work they apply to, or to communicate with FSF or its agents or assignees in any way either when redistribution is performed or on any other occasion. (That's clause 4 of the document normally referred to as assign.future.) Not one word about redistribution of modifications. I don't think I have a leg to stand on with regard to the manual I already wrote. You can be sure I won't be assigning any future copyright interests of mine to the FSF on those terms, though. On a more pragmatic note, if I really made a stink about this, what would happen is cpp.texi would get rolled back to its state before I revised it, and would continue to be distributed under the GFDL with invariant sections etc intact; thus it would not get any Freer, and would be much less useful to its intended readership. zw
