Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 12:33:21PM +1000, Matthew Palmer wrote: RFC authors do it all the time, by issuing updates to existing RFC documents. They say Do it like this, except for this, this, and this. This argument would suggest that any unmodifiable, freely-distributable document is free. You can reference *any* document in this way. It's certainly not similar to software patches. (And I believe many people on this list consider the patches exception to have been an error.) There's nothing free about being forced to do this. -- Glenn Maynard
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 10:49:26PM +0200, Thomas Uwe Gruettmueller wrote: There's lots of software in non-free that is freely distributable, but non-free for other reasons, such as limitations on commercial use. Non- free things should go in non-free, even if there's a lack of free equivalents. I agree that they should not stay in main, but I don't think that freely distributable documents should be mixed with stuff which is not allowed to be distributed commercially, or which according to its license, cannot be exported to Iraq. Why should Debian distinguish between different shades of non-freeness? Are you aware that there is much software already in non-free which is freely redistributable but non-modifiable? -- Steve Langasek postmodern programmer pgpMT57AVSXPO.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
What About Unmodifiable Software Licenses Like the GNU GPL? Strike that text! It's not true. Noting http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL, let me try: start new answer The Free Software Foundation clarifies what it means by ...but changing [the GPL] is not allowed in its GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL. In brief, this says that you may change the GPL provided that: 1) You remove the FSF's endorsement of the license which is the preamble. The Debian Project has no problem with this; it is certainly an author's right to refuse to endorse arbitrary changes. 2) You do not call the license GPL and make it clear that it isn't the GPL. We understand that certain types of software, require this, and thus our DFSG explicitly permits this, stating The license may require derived works to carry a different name or version number from the original software. So, the full terms that the GPL is distributed under, as explained on the FSF website, actually comply with the DFSG. end new answer signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Fri, 2003-04-25 at 11:26, Jeremy Hankins wrote: On one hand, the benefits to be gained from a free-software-like approach to purely artistic/aesthetic (i.e., non-functional) works aren't as obvious. A rather ironic statement in a Bazaar-type development of the wording of a position statement, methinks :-) Also, I must strongly disagree in general. Take artwork for example. Suppose you create a (digital) painting of a flower, and you make it red. I decide that orange would be better, so I change it. Maybe aj comes along and thinks the leaf would look better if it were a little rounder. Or, more pertinently to Debian, I think the icon for a program is ugly, so I change it. Or I dislike a theme author's choice of fonts, colors, etc. These are, as much as anything can be, purely aesthetic considerations, and yet, clearly benefit from being free. Art also often includes other art into itself. For example, I've got a neat desktop background which uses the Debian Swirl. Novels may not benefit much from word-for-word copying from each other, but copying things like characters, scenes, etc. could sure be useful. You don't see it much because it's against copyright law. The ones that are seen are parodies, and are only allowed due to fair use. And they have to fight it out in court half the time anyway (recent example: _The Wind Done Gone_) Many movies have been made from fairy tales, fables, and legends that are, free due to their public-domain status (go ask Disney about that hypocracy). Many pieces of music borrow themes, or even the entire tune, from other, now public-domain music. I'm not sure where the myth that the benefits of freedom are less for non-software comes from, but it sure isn't true. 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 Sun, Apr 20, 2003 at 08:02:45PM -0400, Anthony DeRobertis wrote: My question is, how is a package that depends on DBD::mysql materially different from a compiled program that links dynamically against libmysqlclient? 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) I can see how it can be argued that dynamic linking is creating a derivative work, because it actually involves copying _very small_ amounts of the library into the executable. I'm not sure if I agree with that; but let's assume it true for a moment. I am not arguing that dynamic linking creates a derivative work, and I'm not sure the FSF is, either. I *am* arguing that it is within the purview of the GPL to impose restrictions on redistribution of dependent works whether or not these are derivative works; and the FSF's GPL FAQ asserts that they are doing so. If you think that is a creation of a derivative work (and thus violates the GPL), then I have a much bigger GPL violation for you to worry about. It's with an interpreter known as bash. Many bash scripts rely on functionality provided by bash modules such as grep, gawk, and even tar. Why is this OK, if the DBI/DBD stuff isn't? The mechanisms are different; the effect is the same. Are you certain that a copyright holder who subscribed to this interpretation would *not* have legal standing to sue someone for bundling their GPLed 'mygrep' with a proprietary script that invokes it? There are two differences, however. First, we know of no copyright holders who assert such a requirement in the case of shell scripting interfaces; whereas in the case of GPL modules that are loaded into memory by interpreters, there is at least one prominent copyright holder who asserts this requirement. Second, in the case of shell utilities, it is the original authors who have exposed a certain interface (the exec() interface) for use by the system; whereas in the case of a Perl module, the wrapper that provides the interface used by Perl scripts may be written by a third party (as is the case with DBD::mysql), and its existence cannot be construed as an implicit endorsement on the part of the authors of the original library. The truth is that much of this is very fuzzy; but there are some reasons to believe we are acting in good faith when we use GPL shell utilities from GPL-incompatible scripts, and there are also some reasons (such as the statements in the GPL FAQ) to believe this argument would not hold up as well when the GPL lib is incorporated into an extension to an interpreted language. Regards, -- Steve Langasek postmodern programmer pgpcAGcoCVALx.pgp Description: PGP signature
Re: Is documentation different from software [Re: Proposed statement wrt GNU FDL]
On Fri, 2003-04-25 at 22:27, Matthew Palmer wrote: Except that it's typically a lot easier to work out where a program has been incompatibly modified (oops, compile error, damn, the API changed) than a standard has been modified. The use of 'diff' notwithstanding. Well, when you modify a program enough to cause a compile error, sure it's easy to spot. It's also easy to spot when someone modifies a standard by renaming all the sections and changing the terminology. If you really think that its a lot easier to note where a program has been incompatibly modified, please find all the places where NCSA Mosiac has been incompatibly (with the relevant standards) been modified to produce Internet Exploder. Or, if you content that source must be available, please confirm that GCC-3.2 - GCC-3.3 won't cause any regressions in compatibility with the C++ standard, the various microprocessor standards, etc. The FSF, I'm sure, will be most grateful for that work. It's not easy to find program modifications that don't show up as compile- or link-time errors, even with the use of diff. Programs can be quite long, and often changes don't change behavior (e.g., optimizations). An even larger subset of changes don't break compatibility. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Fri, 2003-04-25 at 22:33, Matthew Palmer wrote: RFC authors do it all the time, by issuing updates to existing RFC documents. They say Do it like this, except for this, this, and this. No, that's generally only done for tiny changes: Adding a bit here or there, etc. For large changes, the old document is obsoleted and the relevant portions included into the new one. Any other way would be insane! Consider that to understand the IPv6 Addressing Architecture, you'd have to read, in order: RFC 1884 (December 1995) RFC 2373 (July 1998) RFC 3515 (August 2003) An RFC can either obsolete another RFC (completely replace it) or update it. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Thu, 2003-04-24 at 12:34, Henning Makholm wrote: Of course both of these limits are judgement calls, and each particular Invariant-But-Removable section will have to be considered on a case-by-case basis. [Hmmm.. so I think at least, but I'm not sure that this is a clear d-l consensus. -HM] I don't think invariant-but-removable sections are OK; we'd certainly never accept things like that anywhere else, and I don't think that compromise would buy anyone much: If I am the author of a work, why would I want it? The only reason I'd have to make something invariant would be something like the manifesto, which contains my beliefs, arguments, etc. But would it not be a better solution to require that if its changed, it is clearly changed to show may not represent my views anymore? If I am the author, I could _possibly_ use one for an endorsement of the work, by e.g., making a statement in a removable invariant section that I endorse the work with a given MD5sum (calculated assuming the listed md5sum is all 0's, of course), but upon further reflection I don't need an invariant section for that: I could use gpg, or I could just include that statement anywhere in the document. Changing it to state I endorse a document I do not is already illegal. I don't need license conditions to make it so. If I am a distributor, sure, I can rip them all out, but not having them in the first place is better for me. I can see the motivation for non-removable invariant sections; they can be used for things like credits, dedications, odes to my pet anteater, etc. They just aren't free. 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 Sat, 2003-04-26 at 01:17, Steve Langasek wrote: I am not arguing that dynamic linking creates a derivative work, and I'm not sure the FSF is, either. I *am* arguing that it is within the purview of the GPL to impose restrictions on redistribution of dependent works whether or not these are derivative works; and the FSF's GPL FAQ asserts that they are doing so. Considering DFSG 1, I _sincerely_ hope they are not doing that! In addition, 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. a 'work based on the Program' means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. So, unless the program is a derivative work, it doesn't fall under the GPL's requirements. Any license that claimed otherwise would, I think, fail DFSG 1. Are you certain that a copyright holder who subscribed to this interpretation would *not* have legal standing to sue someone for bundling their GPLed 'mygrep' with a proprietary script that invokes it? A copyright holder has legal standing to sue anyone he damn well pleases. IANAL, but I think said suit would be lost. The point is, of course, that we have _hundreds_ of scripts like this, and we seem to (by inaction, at least) judge that OK. There are two differences, however. First, we know of no copyright holders who assert such a requirement in the case of shell scripting interfaces; whereas in the case of GPL modules that are loaded into memory by interpreters, there is at least one prominent copyright holder who asserts this requirement. Sure. This does lessen lawsuit risk, but the point is anyone could get ticked off and decide to suddenly try and enforce that. If it's illegal, we shouldn't be doing it --- whether someone currently complains or not. Second, in the case of shell utilities, it is the original authors who have exposed a certain interface (the exec() interface) for use by the system; whereas in the case of a Perl module, Hold on a sec. It's pretty clear that the authors of libmysqlclient have exposed a certain interface (the C API) for use by other programs on the system. The perl module is just using that documented, public interface. The truth is that much of this is very fuzzy; but there are some reasons to believe we are acting in good faith when we use GPL shell utilities from GPL-incompatible scripts, and there are also some reasons (such as the statements in the GPL FAQ) to believe this argument would not hold up as well when the GPL lib is incorporated into an extension to an interpreted language. What, actually, is the difference? That the kernel happens to load libraries into the same address space as programs, but separate programs have separate address space? Does that mean that using those shell scripts on Mac OS before 10 would be illegal because all processes share one address space? Or that shared memory is a problem? Would that be any different than shared disk space, in light of mmap? Why does bash's or dpkg's use of execve(2) for a shell script form a magic copyright barrier, while Perl's use of AutoLoader does not? signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 02:40:29AM -0400, Anthony DeRobertis wrote: It still contains an invariant section, though it's less severe than the GFDL type, as it can be removed. I don't believe there's consensus that invariant sections in general are okay as long as they can be removed, though. It's nothing special created by the copyright license. Its the general rule that you aren't allowed to misrepresent other's beliefs, which is what carrying the Preamble to your modified license (especially the first two paragraphs), without the FSF's permission, would be. I can change most of that text all I want, and as long as I don't claim the resulting text is the FSF's beliefs, I'm not misrepresenting anything. The only thing stopping me from doing that is the FSF's copyright. -- Glenn Maynard
LPPL and non-discrimination
As I am new to this discussion, first here are some words about myself and my understanding of the situation. I'm a longstanding user of TeX, and author of TeX macros. Some years ago I did a small amount of volunteer work for the LaTeX-3 project. My current interests include XML-front ends, and TeX as a callable function. Debian wish to ensure that users of open-source software can if they wish modify, develop and redistribute this software. A worthy aim. The LaTeX team wish to ensure that running a command such as tex \latex myfile.tex gives essentially identical results on all computers, provided myfile.tex is unchanged. Again, a worthy aim. This discussion is devoted to formulating a license that meets both the Debian and LaTeX aims. Now to the problem. Debian guideline 5 states The license must not discriminate against any person or group of persons. The proposed LaTeX license defines the Current Maintainer. The license grants these person(s) privileges that are not granted to other licensees. Although the motive is the worthy one of protecting the integrity of LaTeX, as above, this part of the proposed license is not in my opinion consistent with the non-discrimination guideline. I am confident that the LaTeX and Debian aims are consistent. I am also confident that this discussion has sufficient wisdom and good-will to find a solution to the problem. Jonathan Fine Cambridge, UK
Re: Legal questions about some GNU Emacs files
On Sat, Apr 26, 2003 at 08:08:01PM +0200, J?r?me Marant wrote: Hi, According to Dylan Thurston (see #154043), some files shipped with GNU Emacs could be considered as non-free. One of them is /usr/share/emacs/21.3/etc/LINUX-GNU. The problem seem to come from the footer which mentions: Copyright 1996 Richard Stallman Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved. Also in /usr/share/emacs/21.3/etc/WHY-FREE Copyright 1994 Richard Stallman Verbatim copying and redistribution is permitted without royalty as long as this notice is preserved; alteration is not permitted. What do you people think of this? Just one more comment: the versions of both of these two essays available on gnu.org (at http://www.gnu.org/gnu/linux-and-gnu.html and http://www.gnu.org/philosophy/why-free.html) have a slightly different license: Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Notably, without royalty is missing. Peace, Dylan pgpoUr5bNviFp.pgp Description: PGP signature
Re: LPPL and non-discrimination
Scripsit Jonathan Fine [EMAIL PROTECTED] Now to the problem. Debian guideline 5 states The license must not discriminate against any person or group of persons. The proposed LaTeX license defines the Current Maintainer. The license grants these person(s) privileges that are not granted to other licensees. We have a clear tradition on d-l that the non-discrimination guidline only means that there must be some free terms that apply to everyone. It is not a problem of specific groups receive *more* freedom than the norm, as long as everyone has the freedoms described by the DFSG. It would be absurd to consider one license less free than another solely because it gives more rights to a specific group. Now, if the license requires me, if I modify the software, to give those same extra rights to the specific group, we might have a problem. But as far as I understand, this is not the case for the LPPL draft - the last version I read in detail included explicit clauses that allow me to use a narrower license for my modified version. -- Henning MakholmWhat a hideous colour khaki is.
Re: Legal questions about some GNU Emacs files
Henning Makholm [EMAIL PROTECTED] writes: But you're right that none of the notices you quote describe DFSG-free licensing terms. Feel free to join the ongoing quasiflamewar in the LGPL thread about the degree to which we care about that in the case of Stallman's essays. If you think so, we're going to have a hard time dealing with this then. -- Jérôme Marant http://marant.org
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 11:50:45PM +0200, Thomas Uwe Gruettmueller wrote: Are you aware that there is much software already in non-free which is freely redistributable but non-modifiable? Then leave it there until someone starts complaining about it. (and then continue leaving it there) -- Glenn Maynard
