Re: Proposed statement wrt GNU FDL
On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: -- would you prefer that they hadn't seconded the proposal either? We could have had a nicely silent majority. I don't really see much value in me too posts. We build consensus by responding to criticism, and there hasn't been *any* internal criticism of this stand since last November, when Branden found the FSF's responses to the issues he and others had brought to the FSF's attention. Debian's stance on the GNU Free Documentation License ...OR NOT (completely unofficial, draft, blahblah) (Section I, 'Preserve the section entitled History', is also a candidate for this list.) Is it? I couldn't see how it was much different to the GPL's You must cause the modified files to carry prominent notices stating that you changed the files. I suppose having a History section like: 2003-05-01 Title: _GNU Manifesto_ Debian (Extracted the GNU Manifesto from the GDB docs) 2003-04-28 Title: _GDB Documentation_ FSF 2003-04-12 Title: _GDB Documentation_ Debian 2003-04-11 Title: _GDB Documentation_ FSF 2003-04-01 Title: _GDB Documentation_ Debian 2003-03-20 Title: _GDB Documentation_ FSF could get tiresome. Does that make it non-free, though? I can't see any reason why it should. There's been some question whether the front-cover texts are DFSG free. Considering we accept the obnoxious advertising clause, I can't see any reason for them not to be. I also have a list of other problems with the GFDL. They should probably all be listed together, though we may want to skip some as being too nitpicky. I'd rather list them all in a comprehensive FAQ, and keep the statement short and to the point -- if we're going to make statements on non-free licenses that're commonly called and thought of as free, fair enough; making statements about every seriously flawed license out there would seem like a lot of effort. I'm happy to be shouted down, though. [1] I remember two in the GDB manual and one in the Emacs manual. (Un)fortunately these mistakes have been corrected and I no longer have the old versions around. Does anyone have references? http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00225.html In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' A stronger argument can be made that not only is it easy to misapply, but that it's harmful even when correctly applied: the wikipedia example of the addition of invariant backlinks making the modifications unusable for the original author; and the hypothetical example of random people who don't have RMS's credibility attaching their own manifestos to free software documentation as some weird unerasable graffiti are both convincing to me. Are they convincing to anyone else? If so, would someone else who's convinced like to pen a FAQ paragraph about it? Are there any other examples? Updated statement draft, and a draft FAQ attached, that should cover all your comments that I didn't address in this mail. 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!'' Debian's stance on the GNU Free Documentation License (2) ...OR NOT (completely unofficial, draft, blahblah) 24th April, 2003 In November 2002, version 1.2 of the GNU Free Documentation License (GNU FDL) was released by the Free Software Foundation after a long period of consultation. Unfortunately, some concerns raised by members of the Debian Project were not addressed, and as such the GNU FDL can apply to works that do not pass the Debian Free Software Guidelines (DFSG), and may thus only be included in the non-free component of the Debian archive, not the Debian distribution itself. This document attempts to explain the reasoning behind this conclusion, and offers some suggestions on how authors of free documentation may avoid these problems. The Problem ~~~ The GNU FDL includes a number of conditions, which apply to all modified versions, that disallow modifications. In particular, these are: * K. For any section Entitled Acknowledgements or Dedications, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. * L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. However, modifiability is a fundamental requirement of the Debian Free
Re: Proposed statement wrt GNU FDL
On Tue, Apr 22, 2003 at 06:59:45PM +1000, Matthew Palmer wrote: One which isn't mentioned there is to amend the DFSG to allow the FDL and similar licences. Before someone schedules a MOAB test over my home, note that I am not advocating this course, merely that it should be mentioned and refuted. If we don't do this, someone, somewhere is going to make the jump, and proceed to pester the Project to death with questions about why we don't just modify that pesky ol' DFSG and solve the problem that way. I think Why are Unmodifiable Sections a Problem? in the proposed FAQ I just posted in reply to Richard's message covers this. Could you have a look at it to see if you agree? 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!'' pgpUJtGGLtzmF.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, 24 Apr 2003, Anthony Towns wrote: On Tue, Apr 22, 2003 at 06:59:45PM +1000, Matthew Palmer wrote: One which isn't mentioned there is to amend the DFSG to allow the FDL and similar licences. I think Why are Unmodifiable Sections a Problem? in the proposed FAQ I just posted in reply to Richard's message covers this. Could you have a look at it to see if you agree? I agree with what's expressed in the FAQ, but apart from the section on why we think software and documentation should be treated equally under the DFSG (quite a good argument there, BTW) there's nothing there about why we can't as a project, for instance, just relax the rules of the DFSG generally. After all, we bump up against non-freeisms regularly (hence non-free), people are going to ask why can't you make an exception in the DFSG for this. Even if it's just something as simple as: Why can't the DFSG be modified to accomodate the restrictions imposed by the FDL? After all, RMS endorses it, so why shouldn't you? The Debian Free Software Guidelines, combined with the Social Contract, are the basic tenets by which Debian is guided. The DFSG has stood well with both Debian Developers and the Free Software community for some time, and is widely regarded as the canonical statement of what makes free software Free (the Open Source Definition [I think] was based on the DFSG). As such, changing the DFSG would be widely seen as a major compromise of the principles the Debian project was founded on, and continues to be based on today, as well as a key definition of what it means for software to be Free. On a more practical note, changing the DFSG requires a General Resolution of Debian Developers, a large logistical task and not one which should be undertaken lightly. ---[END]--- OK, so maybe it wasn't quite so simple after all. I'm not putting that up as the canonical form of the QA, but it reinforces to me why the GFDL needs fixing, and not us. - Matt
Re: Proposed statement wrt GNU FDL
Matthew Palmer [EMAIL PROTECTED] writes: Why can't the DFSG be modified to accomodate the restrictions imposed by the FDL? After all, RMS endorses it, so why shouldn't you? The Debian Free Software Guidelines, combined with the Social Contract, are the basic tenets by which Debian is guided. The DFSG has stood well with both Debian Developers and the Free Software community for some time, and is widely regarded as the canonical statement of what makes free software Free (the Open Source Definition [I think] was based on the DFSG). As such, changing the DFSG would be widely seen as a major compromise of the principles the Debian project was founded on, and continues to be based on today, as well as a key definition of what it means for software to be Free. On a more practical note, changing the DFSG requires a General Resolution of Debian Developers, a large logistical task and not one which should be undertaken lightly. ---[END]--- OK, so maybe it wasn't quite so simple after all. I'm not putting that up as the canonical form of the QA, but it reinforces to me why the GFDL needs fixing, and not us. This says to me It's hard to change the DFSG, and the DFSG is respected. Neither of those seems like a good reason for the GFDL to change. I think your argument could be much stronger if it included a because we're right paragraph. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote: In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' While in general I must say that I agree with Branden on this issue, I'm not yet completely convinced, and one reason was brought home to me by the above: I large majority of our software ships with the file COPYING, which states changing it is not allowed. Combined with the requirement in section 1 that the GPL be given to any recipients of the program, this strikes me as similar to the invariant section. It leaves me wondering if we are being a bit hyopcritical about it. At the same time, I see no value in making cover sections, etc. of manuals invariant. Any thoughts on that?
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 08:27:19AM -0500, John Goerzen wrote: On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote: In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' While in general I must say that I agree with Branden on this issue, I'm not yet completely convinced, and one reason was brought home to me by the above: I large majority of our software ships with the file COPYING, which states changing it is not allowed. Combined with the requirement in section 1 that the GPL be given to any recipients of the program, this strikes me as similar to the invariant section. It leaves me wondering if we are being a bit hyopcritical about it. The FAQ says: ] What About Unmodifiable Software Licenses Like the GNU GPL? ] ]Many software licenses unfortunately disallow the creation ofderivative ]works. The FSF give everyone permission to distribute verbatim ]copies of the GPL, eg, but do not give you permission to take the ]text of the GPL and change section (2(c)) to something you prefer, ]and license your own works under this new GPL-based license. This, ]clearly, does not pass the DFSG. ] ]Debian does not generally apply the DFSG to the text of licenses ]themselves, but rather to the software (programs, documentation, ]artwork) they cover. In the past, Debian has similarly overlooked ]applying the DFSG to documentation, but with the increasing focus on ]providing good free documentation, this no longer seems appropriate. Which doesn't really answer the question. The real answer is that: (a) There's never any point making these things unmodifiable. Deriving a new license that uses some parts of the GPL doesn't change the license of old works, and isn't dangerous in any way -- it merely makes it easier to write new license. Likewise for programs, documentation, and anything else. (b) We can't require freely modifiable licenses -- too much useful free software is covered by unmodifiable licenses. But conversely, this isn't something that can or should be extended: licenses aren't relevant to most users -- software and documentation is, and it's the users we're trying to protect here. Likewise, the line between software licenses, and documentation in general is much clearer than the line between documentation and software. Additionally, we're only required to give people a copy of the license, which is a much weaker requirement than including the complete text of the license in every binary we distribute. As such, we're happy to make a special exemption for licenses, that we're not willing to make for documentation in general. That might make more sense. 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!'' pgp996Sh83bJ7.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
Anthony Towns aj@azure.humbug.org.au writes: On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: Debian's stance on the GNU Free Documentation License ...OR NOT (completely unofficial, draft, blahblah) (Section I, 'Preserve the section entitled History', is also a candidate for this list.) Is it? I couldn't see how it was much different to the GPL's You must cause the modified files to carry prominent notices stating that you changed the files. I suppose having a History section like: 2003-05-01 Title: _GNU Manifesto_ Debian (Extracted the GNU Manifesto from the GDB docs) 2003-04-28 Title: _GDB Documentation_ FSF 2003-04-12 Title: _GDB Documentation_ Debian 2003-04-11 Title: _GDB Documentation_ FSF 2003-04-01 Title: _GDB Documentation_ Debian 2003-03-20 Title: _GDB Documentation_ FSF could get tiresome. Does that make it non-free, though? I can't see any reason why it should. There's been some question whether the front-cover texts are DFSG free. Considering we accept the obnoxious advertising clause, I can't see any reason for them not to be. The differences between the GPL's requirements and the GFDL's requirements are in where the required sections must be placed: the GPL, as you've noted elsewhere, usually makes special requirements only of the source, and then requires that the source be available. The GFDL tends to make requirements of all forms of the document. More importantly, for both the front cover texts and the history section, the GPL does not require its changelog be in the source file itself; it is enough to accompany the work with a separate changelog file. The GFDL's requirement that the History section be part of the work itself makes it unusable for a wide class of documents and formats, including video, audio, and static images. In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' How can the sample GDB Session possibly be a Secondary Section? Or is this just a good example of how confusing the Invariant Section rules can be, even to the FSF? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 08:27:19AM -0500, John Goerzen wrote: On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote: In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' While in general I must say that I agree with Branden on this issue, I'm not yet completely convinced, and one reason was brought home to me by the above: I large majority of our software ships with the file COPYING, which states changing it is not allowed. Combined with the requirement in section 1 that the GPL be given to any recipients of the program, this strikes me as similar to the invariant section. It leaves me wondering if we are being a bit hyopcritical about it. At the same time, I see no value in making cover sections, etc. of manuals invariant. Any thoughts on that? It seems that we have an implicit exception that legal statements about a work about allowed to be non-free. That seems to be quite reasonable since tampering with copyright statements is not allowed in many countries, and also since many licenses are also non-free. I don't mind works where it is manditory to reproduce: Copyright (C) 2003 J. R. Hacker. This manual is free documentation; yada yada yada. You should have received a copy of the license along with this manual; if not, write to Fubar, Inc. 123 Sesame St, New York, NY 10023, USA. There is ample precedent for putting these little notices on all sorts of things, typically in fine print. Look, I even have a serviette on my desk that says (C) 2003 DOCTOR'S ASSOCIATES INC. All rights reserved. Simon
Re: Proposed statement wrt GNU FDL
Scripsit Anthony Towns aj@azure.humbug.org.au On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: -- would you prefer that they hadn't seconded the proposal either? We could have had a nicely silent majority. I don't really see much value in me too posts. We build consensus by responding to criticism, Me-too posts are a way of observing consensus. One rant (advocating a possibly controversial course of action leading straight into major flamewar territory) followed by complete silence does not establish a consensus. It merely eastablishes apathy. A rant followed by a handful of me-toos and still no criticism voiced allows consensus to be observed. Of course, a rant followed by constructive discussion about how to implement the proposal in practise is even better, and once that ball gets rolling, me-toos are superfluous. and there hasn't been *any* internal criticism of this stand since last November, True, we knew we had a consensus that we don't like the GFDL and find it lacking with respect to the DFSG if any of its options are exercised. But we didn't previously have a clear consensus on turning that feeling into action, and when the action is as momentous as that lurking in horizon, I think Branden was right in not assuming that consensus of assessment would automatically imply consensus on action. We seem now to have the latter, which is good. There's been some question whether the front-cover texts are DFSG free. Considering we accept the obnoxious advertising clause, I can't see any reason for them not to be. Perhaps the O.A.C. ought to be our next target, but let us fight one battle at a time. We do not accept the O.A.C. because we like it, but because of the logistic problems of tracking down the well-meaning but misguided authors who used it because it was in the template they were following. That situation is unstable and marginally acceptable only because there are probably none of those authors who actually care to enforce it. On the other hand, we have to assume that the FSF really mean what they write in a brand new license, the drafts of which whey have solicited and received extensive responses from the community. the hypothetical example of random people who don't have RMS's credibility attaching their own manifestos to free software documentation as some weird unerasable graffiti are both convincing to me. Are they convincing to anyone else? While we should definitely include the hijacking example, some care should be exercised in phrasing an explanation of what we think it proves. In particular it should be very clear that we do not claim that the possibility of hijacking in itself contributes to DFSG-nonfreedom. (For example, BSD-licensed software and documention can be hijacked too). On the other hand, the hijacking scenario does help explain why we're mystified to see the FSF backing the license as a copyleft. The Problem ~~~ The GNU FDL includes a number of conditions, which apply to all modified versions, that disallow modifications. In particular, these are: [K and] * L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, which state: I think it would be good to emphasize more in the central section that it is the stickyness rather than the rigidity of Invariant Sections that bugs us. How about something like this after the DFSG quote: In particular, the DFSG requires that it must be legal to derive a new work by the particular modification that consists of removing one or more Invariant Sections. But this is expressly disallowed by condition L of the GFDL. If the rule had, instead been, that Invariant Sections could not themselves be modified, but could freely be omitted entirely in derived works, Debian would be able to distribute GDFL'ed documentation. If necessary, the Debian maintainer could himself remove the Invariant Sections, but in most cases where the license were not obviously abused or misapplied, we would still be able to include the original unmodified documentation based on a case-by-case review of the relevance and technical importance of the Invariant Section. (See the attached FAQ, question XYZ for discussion). Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto be included in the Debian GNU/Linux Distribution anyway? I propose expanding this question to: Why does Debian want to remove (say) the GNU Manifesto from the manuals? Do you want to suppress Stallman's views and just benefit from the software he created? The question is one we often hear, but its phrasing betrays a misunderstanding. Debian does not want to remove the GNU Manifesto from the packaged GNU manuals that we distribute. On
Re: Proposed statement wrt GNU FDL
Anthony Towns aj@azure.humbug.org.au writes: The real answer is that: (a) There's never any point making these things unmodifiable. Deriving a new license that uses some parts of the GPL doesn't change the license of old works, and isn't dangerous in any way -- it merely makes it easier to write new license. Likewise for programs, documentation, and anything else. It is dangerous, as it leads to confusion: a document which looks much like the GPL, except for one small section, might not be noticed. However, the legal text of the GPL is reusable (allowing modification and distribution), as long as you don't include the name GPL, the Preamble, or the instructions for use. If Debian's going to eventually remove invariant sections, it's possible that the included copy of the GPL should have those sections removed as well. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 06:34:08PM +0200, Henning Makholm wrote: If the rule had, instead been, that Invariant Sections could not themselves be modified, but could freely be omitted entirely in derived works, Debian would be able to distribute GDFL'ed documentation. We can distribute GNU FDL'ed docs as is -- they simply have to not include any invariant sections. I don't think it makes sense to include invariant sections ever -- whether they can be removed by others or not. We wouldn't accept anything that is entirely invariant as being DFSG-free -- so it doesn't make sense to accept books with chapters that're invariant as DFSG-free. If we are willing to accept invariant chapters in DFSG-free documentation, I don't see how we could possibly claim the GNU FDL is not DFSG-free. Merely being able to delete something doesn't make it free -- I can delete MS Office easily enough, eg. In short, I don't think that's a justifiable position. What we do want is for our *users* to be allowed to remove the GNU Manifesto from the manual if they can think of a reason to do so. No -- we want our users to be able to take everything we give them, and be able to build on any part of it they might choose, with few exceptions. If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. That would mean that part of what we distribute (namely the Invariant Section itself) would not, strictly speaking, be modifyable, but exceptions can be made for things that are both sufficiently non-software-like not to need modifyability for technical reasons and sufficienly relevant not to just constitute a waste of space in the distribution. Didn't we just say we're not making exceptions for things that are sufficiently non-software-like? 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. And further, as a practical matter, it's not reasonable for us to be making judgement calls on every random piece of documentation that gets uploaded. Just analysing the random licenses people come up with is hard enough, trying to work out if some rant is valuable while another isn't isn't sensible. If we're going to make an exception for the GNU Manifesto -- and I think we should -- let's be clear and deliberate about how we do it. Let's note that it's completely non-free, and collect it, and any other defining documents we might want to make similar exceptions for, and put them in doc-debian with our own manifest and social contract, rather than scattered through various manuals. That also forms a good way of judging whether random rants are valuable enough: if they're important enough to go in doc-debian, they're important enough to waive the DFSG. 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!'' pgpHxlebuCBAZ.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 12:22:27PM -0400, Brian T. Sniffen wrote: However, the legal text of the GPL is reusable (allowing modification and distribution), as long as you don't include the name GPL, the Preamble, or the instructions for use. What makes you think this is the case? 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!'' pgp0baUyO0zbg.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 06:34:08PM +0200, Henning Makholm wrote: If the rule had, instead been, that Invariant Sections could not themselves be modified, but could freely be omitted entirely in derived works, Debian would be able to distribute GDFL'ed documentation. On Fri, 25 Apr 2003, Anthony Towns wrote: We can distribute GNU FDL'ed docs as is -- they simply have to not include any invariant sections. I don't think it makes sense to include invariant sections ever -- whether they can be removed by others or not. We wouldn't accept anything that is entirely invariant as being DFSG-free -- so it doesn't make sense to accept books with chapters that're invariant as DFSG-free. A GFDL document with no unmodifiable portions is free, but can be hijacked by someone later adding an invariant section. A GFDL document with non-removable non-modifiable sections is non-free. A document with non-modifiable removable sections (I don't think the GFDL has any provision for this, I'm including it just for completeness) is not free itself, but the portion of the document which is modifiable can be made free by removing the non-modifiable sections. The fourth case (modifiable non-removable sections) is irrelevant, as one possible modification is removal. If we are willing to accept invariant chapters in DFSG-free documentation, I don't see how we could possibly claim the GNU FDL is not DFSG-free. Merely being able to delete something doesn't make it free -- I can delete MS Office easily enough, eg. Right. The ability to remove it only preserves the freedom of the attached work, not the unmodifiable portion itself. If we're going to make an exception for the GNU Manifesto -- and I think we should -- let's be clear and deliberate about how we do it. Let's note that it's completely non-free, and collect it, and any other defining documents we might want to make similar exceptions for, and put them in doc-debian with our own manifest and social contract, rather than scattered through various manuals. Or better yet, put anything that's not freely modifiable (including the Social Contract and GNU Manifesto) in non-free, and work toward making them free. Claiming that documents which do not allow derived works can still be part of Debian is arrogant, hypocritical, and simply wrong. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
question about moral rights
A few people have brought up the topic of Moral Rights, with which I am not very familiar. They sound like some sort of meta-copyright which an author cannot assign, and may not be able to grant permission over. Does anyone have a pointer to some description of these rights that a layman like myself might understand? I'm particularly interested in how they relate to the GFDL and why they would apply to documentation and not to software. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Proposed statement wrt GNU FDL
Henning Makholm said: Perhaps the O.A.C. ought to be our next target, but let us fight one battle at a time. EXPN O.A.C.? (snip) While we should definitely include the hijacking example, some care should be exercised in phrasing an explanation of what we think it proves. In particular it should be very clear that we do not claim that the possibility of hijacking in itself contributes to DFSG-nonfreedom. (For example, BSD-licensed software and documention can be hijacked too). On the other hand, the hijacking scenario does help explain why we're mystified to see the FSF backing the license as a copyleft. Giving particular attention to the fact that the hijacking entity can use the Invariant sections to prevent returning thier improvements to the commons. Example: SomeCo writes a user-friendly GNUware manual based in part on the GNUware Manual (which is GFDL-licensed, so the SomeCo GNUware Manual must be GFDL also). The SomeCo GNUware Manual has lots of useful information in it, which the GNUware authors would like to incorporate. Unfortunately, SomeCo included an invariant section which describes the company and offers investment opportunities, and also the CEO's rant about how all software should be proprietary (and licensed from SomeCo). The original authors can not incorporate SomeCo's improvements without including the company's advertisement, or appearing to endorse the CEO's confused views. --Joe
Re: Proposed statement wrt GNU FDL
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Apr 24, 2003 at 12:22:27PM -0400, Brian T. Sniffen wrote: However, the legal text of the GPL is reusable (allowing modification and distribution), as long as you don't include the name GPL, the Preamble, or the instructions for use. What makes you think this is the case? http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL Can I modify the GPL and make a modified license? You can use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble, and provided you modify the instructions-for-use at the end enough to make it clearly different in wording and not mention GNU (though the actual procedure you describe may be similar). and more on why not to -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
VisualBoyAdvance license
I've been looking into packaging Visual Boy Advance, a gameboy advance emulator. The package request indicated that it was released under the gpl, but on closer inspection it looks like the license is much more restrictive (and possibly too restrictive for debian) because it has a clause against commercial use. I would like to know if it will be possible to package this for debian, or if the license is too restrictive. Thanks Andy Here is the text of COPYING.TXT VisualBoyAdvance (c) Copyright 2001-2002 by Forgotten Homepage: http://vboy.emuhq.com Permission to use, copy and distribute VisualBoyAdvance in binary form, for non-commercial purposes, is hereby granted without fee, providing that this license information and copyright notice appear with all copies. See the COPYING file for the GNU Public License that also affects this program. This software is provided 'as-is', without any express or implied warranty. In no event shall the author be held liable for any damages arising from the use of this software. VisualBoyAdvance is freeware for PERSONAL USE only. Commercial users should seek permission of the copyright holders first. Cheat search engine and filters adapted from Snes9x source code. /* * Snes9x - Portable Super Nintendo Entertainment System (TM) emulator. * * (c) Copyright 1996 - 2001 Gary Henderson ([EMAIL PROTECTED]) and * Jerremy Koot ([EMAIL PROTECTED]) * * Super FX C emulator code * (c) Copyright 1997 - 1999 Ivar ([EMAIL PROTECTED]) and * Gary Henderson. * Super FX assembler emulator code (c) Copyright 1998 zsKnight and _Demo_. * * DSP1 emulator code (c) Copyright 1998 Ivar, _Demo_ and Gary Henderson. * C4 asm and some C emulation code (c) Copyright 2000 zsKnight and _Demo_. * C4 C code (c) Copyright 2001 Gary Henderson ([EMAIL PROTECTED]). * * DOS port code contains the works of other authors. See headers in * individual files. * * Snes9x homepage: www.snes9x.com * * Permission to use, copy, modify and distribute Snes9x in both binary and * source form, for non-commercial purposes, is hereby granted without fee, * providing that this license information and copyright notice appear with * all copies and any derived work. * * This software is provided 'as-is', without any express or implied * warranty. In no event shall the authors be held liable for any damages * arising from the use of this software. * * Snes9x is freeware for PERSONAL USE only. Commercial users should * seek permission of the copyright holders first. Commercial use includes * charging money for Snes9x or software derived from Snes9x. * * The copyright holders request that bug fixes and improvements to the code * should be forwarded to them so everyone can benefit from the modifications * in future versions. * * Super NES and Super Nintendo Entertainment System are trademarks of * Nintendo Co., Limited and its subsidiary companies. */
Re: question about moral rights
Hi Mark,
On Thursday 24 April 2003 19:37, Mark Rafn wrote:
A few people have brought up the topic of Moral Rights, with
which I am not very familiar. They sound like some sort of
meta-copyright which an author cannot assign, and may not be
able to grant permission over.
Does anyone have a pointer to some description of these rights
that a layman like myself might understand? I'm particularly
interested in how they relate to the GFDL and why they would
apply to documentation and not to software.
* * * IANAL * * *
The German Authors Rights Law is available at
http://bundesrecht.juris.de/bundesrecht/urhg/index.html
For an English version, use the Google translation tools:
http://translate.google.com/translate?u=http%3A%2F%2Fbundesrecht.juris.de%2Fbundesrecht%2Furhg%2Findex.htmllangpair=de%7Cenhl=deie=ISO-8859-1prev=%2Flanguage_tools
(Although this translation seems to be quite readable, I'm a bit
confused about the translation of the headline, Copyright law
and used patent rights. Literally, it should translate to Law
About Authors Rights and Similar Protection Rights. What the
hell are used patents rights???)
Relevant passages might be:
| UrhG § 14 distortion of the work
|
| The author has the right to forbid distortion or another
| impairment of its work which is suitable, to endanger its
| entitled mental or personal interests in the work.
and
| UrhG § 42 recall right because of changed conviction
|
| (1) the author can recall a right to use opposite the owner,
| if the work does not correspond to its conviction any longer
| and cannot to it therefore the utilization of the work any
| longer be zugemutet. The legal successor of the author (§ 30)
| can explain the recall only if he prove that the author before
| its death would have been entitled to the recall and from the
| explanation of the recall was prevented or this ordered
| last-willingly.
|
| (2) without the recall right cannot be done in advance. Its
| practice cannot be excluded.
|
| (3) the author has to compensate the owner of the right to use
| appropriately.
This point is interesting. How can anyone ever compensate six
billion licensees approprietely? ;o)
| The remuneration must at least cover the
| expenditures, which the owner of the right to use up to the
| explanation of the recall made; however here expenditures,
| which are allotted to uses already pulled, remain out of
| consideration. The recall becomes only effective if the author
| replaced the expenditures or carried security out for it. The
| owner of the right to use has to communicate within one period
| from three months to explanation of the recall the
| expenditures to the author; if it does not follow this
| obligation, then the recall becomes already effective at the
| end of this term.
|
| (4) if the author wants to again use the work after recall,
| then he is obligated to offer to the former owner of the right
| to use an appropriate right to use for appropriate conditions.
|
| (5) the regulations in § 41 exp. 5 and 7 are to be used
| accordingly.
- - - - -
I can't find any hint why software should be different.
cu,
Thomas
}:o{#
Re: VisualBoyAdvance license
[EMAIL PROTECTED] wrote: I've been looking into packaging Visual Boy Advance, a gameboy advance emulator. The package request indicated that it was released under the gpl, but on closer inspection it looks like the license is much more restrictive (and possibly too restrictive for debian) because it has a clause against commercial use. I would like to know if it will be possible to package this for debian, or if the license is too restrictive. You should probably get a clarification from upstream of what license the whole thing is really distributed under. If different parts of the program really are distributed under this non-commercial use license and the GPL, any binaries are undistributable, even in non-free. Regards, Walter Landry [EMAIL PROTECTED]
Re: VisualBoyAdvance license
On Thu, Apr 24, 2003 at 09:29:14PM +, [EMAIL PROTECTED] wrote: From the license: Permission to use, copy and distribute VisualBoyAdvance in binary form, for non-commercial purposes, is hereby granted without fee, providing that this license information and copyright notice appear with all copies. See the COPYING file for the GNU Public License that also affects this program. These conditions directly contradict the GNU General Public License, which is presumably the one they mean. So the big question is, in what way does it affect the program? Do they mean that this program is dual-licensed, under both the GPL and this paragraph? In that case the program is free software and it can go into Debian. Or do they mean that *both* licenses must be satisfied? In that case the license statement is contradictory, because the GPL doesn't allow imposing a non-commercial purposes requirement. We can't distribute that software at all. I think this paragraph makes the dual-license possibility unlikely: VisualBoyAdvance is freeware for PERSONAL USE only. Commercial users should seek permission of the copyright holders first. I downloaded their source[1] and poked around in it looking for copyright statements. Most of the files have Copyrigh(c) 1999-2002 Forgotten ([EMAIL PROTECTED]) and a GPL license blurb. This makes it somewhat strange that there's a completely different license in COPYRIGHT.TXT with the same name on it. [1] http://belnet.dl.sourceforge.net/sourceforge/vba/VisualBoyAdvance-1.5-src.tar.gz My best guess of the situation is that this Forgotten person put his code under the GPL without realizing that this conflicted with the Snes9x license that was on the code he was adding to. Files like src/tvmode.cpp have both the Forgotten GPL blurb and the incompatible Snes9x license at the top. More disturbing is the file src/win32/wavwrite.cpp, which has the GPL blurb followed by this: //- // File: WavWrite.cpp // // Desc: Wave file support for loading and playing Wave files using DirectSound // buffers. // // Copyright (c) 1999 Microsoft Corp. All rights reserved. //- I think we shouldn't get anywhere NEAR this package until it's had a careful license review. Richard Braakman
Re: Proposed statement wrt GNU FDL
Anthony Towns wrote: As such, we cannot accept works that include Invariant Sections and similar unmodifiable components into our distribution, which unfortunately includes a number of current manuals for GNU software. It may be worth noting that GNU manuals are hardly the only thing effected by the emerging consensus on treatment of document licenses. The RFC's are moving to non-free already as they cannot be modified, emacs contains a number of documents in its etc directory (WHY-FREE, PROJECT, INTERVIEW, CENSORSHIP, etc, etc) that cannot be modified. There are probably quite a few more examples. 2) Use an alternative copyleft license for your document. The GNU General Public License is a good license for documentation as well as software. It requires anyone who would want to do a print run of your documentation to either include a CD of the text with the book so anyone can modify it, or to include an offer to send copies to anyone who asks at cost; and also requires the modifiable copy to be in whichever transparent form was used to create the book originally. 3) Use a non-copyleft free license for your document. Example licenses include the FreeBSD Documentation License, and common software licenses such as the X11 license, or the updated BSD license. 4) Convince the FSF to change the GNU FDL to allow the removal of unmodifiable sections. While this does not prevent documents covered by the GNU FDL being non-free by Debian's definition of the term, it allows us to remove the non-free components (that by definition are irrelevant to the document), leaving simply the DFSG-free manual itself. It might be good to point to another license written explicitly with non-code in mind. What about the license used on the Debian web site? What About Unmodifiable Software Licenses Like the GNU GPL? Many software licenses unfortunately disallow the creation ofderivative works. The FSF give everyone permission to distribute verbatim copies of the GPL, eg, but do not give you permission to take the text of the GPL and change section (2(c)) to something you prefer, and license your own works under this new GPL-based license. This, clearly, does not pass the DFSG. Apparently they do allow it, according to Brian T. Sniffen who points out http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL If the license portion of the GPL can indeed be reused and modified then it is a bad example to use here. Or at least the reference to section 2c is a bad example. Debian does not generally apply the DFSG to the text of licenses themselves, but rather to the software (programs, documentation, artwork) they cover. In the past, Debian has similarly overlooked applying the DFSG to documentation, but with the increasing focus on providing good free documentation, this no longer seems appropriate. It might be worth noting that Debian historically did not apply the DFSG to software either (well, there was no DFSG), and had a large amount of non-free software in the distribution, and that applying a strict standard to the software we ship has led to a lot of software becoming free, and has not hurt the distribution or our users in any way. We hope applying these standards to documentation will have similar positive effects. I think this is mostly implicit in your answer, but many people will not know the history. Beyond allowing invariant sections, why does the GNU FDL suck? A little peice of me wonders if why does the GNU FDL suck is politic even in a FAQ, but whatever. Obnoxious Accumulation of Cover Texts Every contributor can add up to 5 words of Front-Cover Text and up to 25 words of Back-Cover Text. It won't take long before there is no space for artwork on the front cover, just a dense list of short texts. ([Nit: The front cover must present the full title with all words of the title equally prominent and visible. So no artistic license allowed in title arrangement. Nethack: Journey through the MAZES of MENACE is right out, especially if MENACE has little goblins holding up the letters.]) Has anyone figured out what you have to do to print a FDL licensed work as part of a collection like a magazine? I'm thinking particularly of my Linux Journals which always seem to arrive with a giant honking mailing lable right over the title of the two articles I'm most interested in. It would be very amusing if the placement of a label could violate a copyright. Languages other than English are poorly supported The GNU FDL defines special roles for several kinds of sections (such as History and Dedications), but refers to these sections by their names in English. A document under the GNU FDL will have to include a section with the title History, regardless of the language it's written in. I think if I were an author and was worried about this, I would quickly
Re: Proposed statement wrt GNU FDL
Hi Matthew and all,
On Thursday 24 April 2003 13:21, Matthew Palmer wrote:
I agree with what's expressed in the FAQ, but apart from the
section on why we think software and documentation should be
treated equally under the DFSG (quite a good argument there,
BTW) there's nothing there about why we can't as a project,
for instance, just relax the rules of the DFSG generally.
As a Debian user, I am glad that there is this set of rules --
namely the DFSG -- that strictly followed, help keeping Debian
100 % free software. I hope that these rules will not be
softened, so that in the end, Debian becomes a second SuSE.
I am also glad that the Debian project treats all different
sorts of content the same way, as I am very enthusiastic about
the idea of a transition of the principles of free software
towards other areas. The FSF has quite disappointed me in this
regard, as they not only deny the leadership of a general
free-everything-movement, but also discourage people from being
consequent by giving them a bad example. For me, this is another
reason why Debian should keep its rules as they are, and
continue to apply them consequently.
On the other hand, the DFSGly non-free docs that are about to be
thrown out of main are at least as freely distributable as any
other package in main. This is a quality that many packages in
non-free do not share with them. As I don't have non-free in my
apt/sources.list, from my point of view, moving these docs to
the 'non-free' section would practically mean the same thing as
moving them to the trash dump. I guess this step would be far
too radical.
Also, it seems to be more difficult to write and test
documentation than software, as it works on human beings, not
machines. Further, there still is too few good documentation.
This makes me think that trashing freely distributable
documentation would not be wise.
So, now I'm repeating an idea that I alredy mentioned here,
after selfhtml had been kicked:
* Create a section 'distributable' that is between main and
non-free, for stuff that is not free WRT modification,
availability of the source code etc., but at least freely
distributable in any medium, by anybody, for any price.
* Therefore, create a subset of the GFDL (a 'relaxed' GFDL)
which regulates what can go in there and what not, but not as
a replacement of the current GFDL, but rather a different set
of rules for a different purpose.
I think this would be a good compromise for those people who
want non-free docs out of main, and those who don't want them
trown onto the 'non-free' trash dump, and those who want both.
cu,
Thomas
}:o{#
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 04:57:36AM +0200, Thomas Uwe Gruettmueller wrote: On the other hand, the DFSGly non-free docs that are about to be thrown out of main are at least as freely distributable as any other package in main. This is a quality that many packages in non-free do not share with them. 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. As I don't have non-free in my apt/sources.list, from my point of view, moving these docs to the 'non-free' section would practically mean the same thing as moving them to the trash dump. I guess this step would be far too radical. Requiring you to add a line or two to sources.list isn't trashing anything. If this is a radical move, I'd say the earlier one of moving non-free software to non-free was an order of magnitude more radical. So, now I'm repeating an idea that I alredy mentioned here, after selfhtml had been kicked: * Create a section 'distributable' that is between main and non-free, for stuff that is not free WRT modification, availability of the source code etc., but at least freely distributable in any medium, by anybody, for any price. Distributors can already do this. I don't think Debian should be expending time categorizing non-free into non-free and really non-free; let people who would actually use the distinction (distributors) spend the time. (It'd be a fair bit of time, requiring further analysis of clearly non-free licenses.) -- Glenn Maynard
