Re: FSF has published GNU FDL version 1.2
Walter Landry [EMAIL PROTECTED] writes: Let's say that the library has two things you can get, the texinfo source files and a pdf generated from them. People are unlikely to print out the texinfo files, so they would naturally try to print out the pdf. So the library sets the do not print flag on the pdf, making it unlikely that anyone will print out the Emacs manual. The library is not distributing copies of the manual, but they are using technical measures to obstruct or control the reading or further copying of the copies that they made. This is a completely reasonable _use_ that is not allowed by the GFDL. Your broad definition of technical measures to obstruct or control the reading or further copying of the copies would prevent me from keeping a GFDL-licensed work locked in my house: the doors and locks obstruct reading by random passerby. Clearly, this section is meant to refer to measures which obstruct or control reading or further copying by the owners of the existing copies. Since the library isn't distributing copies, only allowing browsing, there's no problem. If they do distribute PDF copies, of course, it has to be the unlocked PDF which is distributed, together with the texinfo source. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/ Available for security-related employment.
Re: EULAs and the DFSG
Andrew Suffield [EMAIL PROTECTED] writes: On Thu, Dec 05, 2002 at 04:56:10AM +0100, Sunnanvind Fenderson wrote: This is very different from EULAs because with them the end user gets *less* rights that normally given by copyright The rights normally given by copyright are virtually nil; you have the right to quote it for critical purposes and so on, but not the right to use it. A EULA generally grants you the right to use it. Are you saying that if I buy a book, I don't have the right to read it, sit on it, or otherwise use it without a license to do so from the copyright holder? If you aren't saying that, are you saying that if I purchase and download some commercial software, I don't have the right to use it without a license to do so from the copyright holder? Where's the difference? Jakob Bohm [EMAIL PROTECTED] writes: Click agree to accept this license and the lack of warranty. Click decline to not use, copy or distribute this software. The main problem is that that's simply not true - you _can_ use the software without accepting the license[1]. Ah. I see your confusion now. You really can't legally use the software without accepting the license, but the GPL imposes no conditions upon your acceptance of paragraph 0 which grants you usage rights. You could call this paragraph a EULA, if you really wanted to, but there's little point in doing so. That isn't the section 0 I'm looking at: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted That isn't a license to use the program, it's a note that copyright law already gives you that right without a license. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/ Available for security-related employment.
Re: PHPNuke license
John Goerzen [EMAIL PROTECTED] writes: On Mon, Mar 03, 2003 at 04:28:41PM -0500, [EMAIL PROTECTED] wrote: They are an object form. The page transmitted by PHP-nuke is not the preferred form for modification (which has the PHP code embedded within it), and so not source. It is produced by mechanical transformation fromt he source, and so quite reasonably an object page. I find it hard to believe that anything produced by mechanical transformation from a source is object form. Object form is machine code. I can not magically transform a text file into object form by running tr a-z A-Z on it. Sure you can. It's now full of shouting, and no longer in the preferred form for modification. No license can reasonably distinguish between tr and gnupg -- distinguishing indent is hard enough. -Brian -- Brian T. Sniffen G026 / Secure Technology Solutions [EMAIL PROTECTED]
Re: PHPNuke license
John Goerzen [EMAIL PROTECTED] writes: On Tue, Mar 04, 2003 at 10:45:43AM -0500, Brian T. Sniffen wrote: I find it hard to believe that anything produced by mechanical transformation from a source is object form. Object form is machine code. I can not magically transform a text file into object form by running tr a-z A-Z on it. Sure you can. It's now full of shouting, and no longer in the preferred form for modification. No license can reasonably distinguish between tr and gnupg -- distinguishing indent is hard enough. Nobody, including the FSF, defines object form as not the preferred form for modification. Just because the source code IS that format does not bean that everything that is not source code is object code. But the GNU GPL gives you a license to distribute source code and object or executable form, and nothing else... so if your obfuscated/munged/semicompiled form is neither source nor object, and you only have the right to distribute it under the GPL, my understanding is that you may not distribute it at all. The GPL wisely avoids a strict definition of object form, but I would think that the classic definition -- the product of a mechanical transformation from source or from other objects, and no longer source code -- would work. -Brian -- Brian T. Sniffen G026 / Secure Technology Solutions [EMAIL PROTECTED]
GPLv3 2(d) (was Re: PHPNuke license)
David Turner [EMAIL PROTECTED] writes: Can we please, please, please start another thread to discuss this?! done that's enough reason for me to stop releasing code under version 2 or later of the GNU GPL: the persistent spectre that future versions will prohibit certain sorts of functional modifications. That would be silly, since you could always fall back to v2. The only reason to fear v2 or later is that v3 could be too permissive, not too restrictive. No; if I release software under v2 or later, and a v3 with this clause is released, I have a problem: somebody can take my work, make modifications to it, and distribute it in such a way that I cannot use it. Even if he gives me the source code, I can't make use of his modifications without upgrading the licensing of my code to v3. If I'm going to give people the freedom to take my code and make it non-free[1], I might as well just put it under an MIT license. Wouldn't a requirement that if you make the software available for use to another party, you provide an offer of source to those users make much more sense, and avoid entanglements with the function of the software? That would be impossible under US copyright law, where use isn't one of the 17 usc 106 exclusive rights, while modification is. Public performance is restricted by copyright law; I'd certainly consider an Apache web server to be a public performance of Apache. In any case, there's another problem I allude to above but didn't mention clearly: the existing requirements for source distribution are very flexible. This proposed 2d imposes technical limitations on functionality. Every time a license tries to use exact technical definitions, it ends up breaking a few years later. I'm not nearly as worried about the HTTP requirement as I am about the definition of computer network. Is my USB keyboard/mouse a network? How about my Bluetooth keyboard? When I'm interacting through an anonymizing mix-net, there's a decent chance I'm not online when the other side is. Are we interacting through a network? What about a web client which responds to certain server requests for its source[2]: it may not have any way to hear a request from the server, and if it's used as the skeleton for an embedded control system, all that junk needs to go along with it. I'd far prefer to see a GPLv3 grant and guarantee more freedom, not less: * Remove technical requirements such as 2c, the object/executable langauge in 3, the header/Makefile and OS exceptions in the later section of 3. * Remove the strange definition that a work containing nothing both creative and derived from a GPL'd work be considered a derivative of the GPL'd work: that is, remove the definition that linking is modification. It's not in the license now, but clearly state that if you incorporate nothing creative from the GPL's work, you are not a derivative work. * Add public performance to the scope clause in 0, permitting (for example) me to give a lecture on the details of GNUtls, or to run a web server which presents an interface to Perl. -Brian Footnotes: [1] That is, modify and distribute it in non-free ways. [2] Admittedly, an odd case. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: transformations of source code
On Thu, Mar 06, 2003 at 11:23:47AM -0500, Jeremy Hankins wrote: This doesn't address proprietary or otherwise difficult but not impossible to reverse formats. I considered that but I'm not sure how much of a threat it really is. There's no way to keep the sourced locked into an obfuscated format under my proposal; the first person to crack it open is free to redistribute it in obfuscated form. This is directly analogous, I think, to the reason the GNU GPL doesn't have a clause forbidding selling a work so licensed for $1 million. Unfortunately, in the age of the DMCA that isn't quite enough. Since the GPL has few restrictions on functional modification, it's not much of an issue there. A document license has a broader problem: the first person to crack it open would be violating the DMCA to do so. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: OSD DFSG - different purposes - constructive suggestion!
Anthony Towns aj@azure.humbug.org.au writes: It certainly does force you to share your secrets. It forces you to share your secrets only with your customers, though. I don't believe this is the case: I have code which is a proprietary typesetting package based on GPL'd works. My customers give me paper and I give them paper back; sometimes i give them PDF files for proofing. These files contain *their* proprietary information. It closes a loophole; that is, it means companies can't maliciously take free GPLed software, make changes to it that they don't release, and then cause users to rely on that software. One of the advantages I've seen in the GPL is that it promotes the use-value of software over its sale-value. This sort of change -- requirements that an author distribute his changes more widely than he wishes -- seems to remove much of the use value as well. Convince me that in this imperfect world, as we try to make things more transparent, and give people more control and access over the software that affects them, that being able to get access to the sourcecode for www.wherever.com whether they want me to or not is a *bad* thing. * It makes certain kinds of crimes easier to commit, though much harder to conceal. * Identity theft, in particular, becomes much easier. * There's less incentive to develop new changes: unless you can afford a stable of developers large enough to deploy new features faster than your competitors can copy them, you gain no competitive advantage from innovation. Software gets developed only to scratch personal itches. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: OSD DFSG - different purposes - constructive suggestion!
Glenn Maynard [EMAIL PROTECTED] writes: On Mon, Mar 10, 2003 at 11:23:26AM -0500, Brian T. Sniffen wrote: * There's less incentive to develop new changes: unless you can afford a stable of developers large enough to deploy new features faster than your competitors can copy them, you gain no competitive advantage from innovation. Software gets developed only to scratch personal itches. This sure sounds like a (poor) argument against open source in general. Not at all. Open-source is great for infrastructure software -- Linux, Apache, Emacs. Many companies have private modifications to Linux or Apache which they use internally; some of these get released, some don't. Everybody benefits by contributing to the common good. For example, several network infrastructure companies use Linux on their embedded devices, release kernel changes and improvements, and keep their core technology in-house. It's not that it's under a proprietary license, just that it's not distributed at all. This model works wonderfully for the free software community and for those companies. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: PHPNuke license
David Turner [EMAIL PROTECTED] writes: On Fri, 2003-03-07 at 00:19, Anthony Towns wrote: On Thu, Mar 06, 2003 at 06:28:06PM -0500, David Turner wrote: On Thu, 2003-03-06 at 17:35, John Goerzen wrote: On Thu, Mar 06, 2003 at 05:07:13PM -0500, David Turner wrote: Distribution does not, and has never, mattered (see previous message in this thread). I think it's pretty clear that all three subsections of section 2 takes no effect unless distribution has occured. Please read it again -- if that's so, why does (2)(b) specifically mention distribution? (2)(a) and (2)(c) *do* apply even in the absence of distribution. Well, they try to anyway. If there's no copying taking place, I fail to see how it can apply, whether it tries to or not. Because the preparation of derivative works is one of the exclusive rights of copyright holders. Please read 17 USC 106 (2) again. Yes... but I can write in the margins of a book as much as I like, or tape over bits of a video recording. Given a legal unmodified copy on disk, can't I modify it as I wish under the first-sale doctrine? I own the drive it's on, after all, and copyright does not in any way infringe my right to dispose of my physical property. -Brian Still not a lawyer. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: OSD DFSG - different purposes - constructive suggestion!
Glenn Maynard [EMAIL PROTECTED] writes: On Mon, Mar 10, 2003 at 01:37:54PM -0500, Brian T. Sniffen wrote: * There's less incentive to develop new changes: unless you can afford a stable of developers large enough to deploy new features faster than your competitors can copy them, you gain no competitive advantage from innovation. Software gets developed only to scratch personal itches. This sure sounds like a (poor) argument against open source in general. Not at all. Open-source is great for infrastructure software -- Linux, Apache, Emacs. Many companies have private modifications to Linux or Apache which they use internally; some of these get released, some don't. Everybody benefits by contributing to the common good. For example, several network infrastructure companies use Linux on their embedded devices, release kernel changes and improvements, and keep their core technology in-house. It's not that it's under a proprietary license, just that it's not distributed at all. This model works wonderfully for the free software community and for those companies. I'm not disagreeing with this. I'm saying that your argument (top quote) can be applied to open source in general, and we all know it to be false in that case; so how are web apps so different? As I said: existing mechanisms of licensing Free Software (e.g. GNU GPL and MIT/X11) provide an impetus for improvement. A compulsory-sharing license, as might bring us closer to BrinWorld, removes much of the financial incentive for such improvement. In such a world, the changes made, used, and later released by IBM, Red Hat, Akamai, Apple... all wouldn't have been made, and our software technology would be that much more primitive. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Barriers to an ASP loophole closure
Jeremy Hankins [EMAIL PROTECTED] writes: Anthony Towns aj@azure.humbug.org.au writes: This detailed wrangling is really missing the point that I'm interested in, though. Is there a _fundamental_ difficulty with such licenses? Is it users of programs or owners of copies of programs that should have freedom? As far as I can see the answer is clearly users. Currently those two groups are roughly the same, and the second group is *much* easier to draw a line around. So we use ownership of a copy to pin freedoms to. The two groups are vastly different. As has been mentioned upthread, I use the power regulation software at Boston Edison, I use the 911 dispatch system (and indeed, the phone switching system) in my town, I use the typesetting software of my local paper when I e-mail them a letter and it's sent back to me. I don't see why I should have the right to Slashdot's source code -- or this mailing list servers, or the kernels of the routers inbetween, but not to that of the Boston Globe. Since I'm pretty sure that I *don't* have a right to the software of the Globe, given they wrote it in-house and have (for the sake of argument) not distributed it, I trace that back to say that even in an ideal world, I don't have a right to the software in a router I don't own, or to a web server I'm simply accessing. If they can find a way to tie the freedoms of the DFSG to users of software rather than possessors of copies of software, should that make their software non-DFSG-free? Maybe. I don't believe it's possible to delineate users in a way that doesn't discriminate strongly against fields of endeavor or against particular technologies. I think your three tests summarize what's needed pretty well... I just don't think they're mutually compatible. Moving on to your solutions: So we have three meta-options: * Decide that freedoms *should* attach to copies rather than users There's something to be said for that option. Here's a further extrapolation of the ASP nightmare for you: everybody who writes code makes it available only on their machine, in some .NET horror by which code is patched at runtime via RPC... so I want to set up a webserver. It uses Apache.NET, Zope.NET, ZWiki.NET, Perl.NET, and each of these (and each Perl module and Apache module) lives on its own separate server. To what are the users of my site entitled? My glue code? The kernels of each of these servers? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: OSD DFSG - different purposes - constructive suggestion!
Glenn Maynard [EMAIL PROTECTED] writes: On Mon, Mar 10, 2003 at 03:46:57PM -0500, Brian T. Sniffen wrote: As I said: existing mechanisms of licensing Free Software (e.g. GNU GPL and MIT/X11) provide an impetus for improvement. A compulsory-sharing license, as might bring us closer to BrinWorld, removes much of the financial incentive for such improvement. In such a world, the changes made, used, and later released by IBM, Red Hat, Akamai, Apple... all wouldn't have been made, and our software technology would be that much more primitive. The GPL removes much of the financial incentive for such improvement. After all, you have to provide source and you can't restrict people you sell copies to from giving it away for free, so the entire sales model of selling individual programs on the shelf, and licensing software per-seat, goes completely out the window. I disagree with this argument, of course (as everyone here probably does: it's true that the same sales model doesn't work, but it certainly hasn't stopped innovation), but your argument seems to be exactly the same. Why is this argument valid for web applications where it's clearly wrong for other software? Two reasons: First, because the argument about web applications is a reduction in the marginal use value of a software improvement, not in its sale value. Second, this can be taken out of the realm of theory: in practice, private companies make improvements to software they have under the GPL, keep some of those improvements secret, and release others. Those same companies pass up the opportunity to improve software where they do not have the option of keeping their improvements secret. (Admittedly, I've seen short-sighted companies scrambling for profitability start rewriting their code so they could sell licenses, excising all the GPL'd bits). (To be clear, I'm firmly against forced-sharing; the GPL goes far enough. I just don't think this particular argument is valid.) -- Glenn Maynard -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Barriers to an ASP loophole closure
Jeremy Hankins [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: The point is that the alleged user, even if he has the source to what's behind the web page, *can't* change it, because it's on a computer beyond his control, on the other side of that connection. Giving him the source does *NOT* make it possible for him to change it. Sure, but he may still want to know how the source works, or he may want to replicate the same functionality elsewhere. But even so, I'm not saying that everything that could possibly be construed as use should have access to source tied to it. If my dentist uses copylefted accounting software to send me bills I don't necessarily get access to source. That kind of use is outside the kind of use we want to pick out. And I acknowledge that picking out the right kind of use will be hard. But if the dentist were using copylefted accounting software via a web interface, it does seem reasonable to argue that he ought to have access to the source. But that's exactly the error we reprimand legislators and businesses for: believing that a different medium requires new laws to make it safe. That I receive the output of software over HTTP should change nothing from the cases where I received that output over a phone tree or on paper. But you still haven't answered my question: *IF* it could be done (and passed the other two tests I mentioned in my other message), would it be free? Yes... but I don't think I'm actually agreeing with you: I think the only way to properly define the set of users who should get a copy of the source is vanishingly small. David Turner says I secretly want to write proprietary software, but the truth is I don't see this as a loophole: I see it as a use of the software which wasn't expected by several authors, including the FSF, and to which they are reactively objecting. That, in itself, makes a good argument for why the author should have no ability to place an obligation on anybody under a Free Software license. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Barriers to an ASP loophole closure
Jeremy Hankins [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: Jeremy Hankins [EMAIL PROTECTED] writes: Is it users of programs or owners of copies of programs that should have freedom? As far as I can see the answer is clearly users. Currently those two groups are roughly the same, and the second group is *much* easier to draw a line around. So we use ownership of a copy to pin freedoms to. The two groups are vastly different. Only when you're playing the game of trying to push the definition of user as far as you can push it. And that's a perfectly legitimate and good thing to do when you're discussing a license text, but in doing so you shouldn't forget that there's also an ordinary, every-day definition that doesn't get pushed so far. When I say you're a user of router software, I'm not pushing the definition of user any further than you are when you say I'm a user of PHP-nuke or Apache. The ordinary, every-day use of the term is fuzzy, acknowledges inconsistencies, and works anyway. Ask the next guy you meet that uses computers but doesn't care about licensing whether they're using apache when they look at apache.org. Do you honestly think he'd say yes? Or the NYT's typesetting software when they read the paper? I think he'd say he doesn't use either. But then when I asked him what he used to read his mail, he'd either say Oh, I use Netscape or Oh, I use Yahoo! mail. I've observed a number of the nontechnical users I support failing to distinguish between their OS, browser, home page, and other web sites. I'm not sure we should be guided by such opinions, though: it would be nice to meet the expectations of the uninformed masses, but given the choice of their expectations, which are often internally inconsistent, and the expectations of those who will actually be modifying or distributing code, I'd rather satisfy the latter. In particular, it seems to me that drawing a technical distinction among users (i.e., to say that users at a console or over an IP network are users who get source, but users via sneakernet or over a voice telephone link are not) is unwise. Maybe. I don't believe it's possible to delineate users in a way that doesn't discriminate strongly against fields of endeavor or against particular technologies. I think your three tests summarize what's needed pretty well... I just don't think they're mutually compatible. Maybe not, I'm not sure. It's hard to prove a negative. So we have three meta-options: * Decide that freedoms *should* attach to copies rather than users There's something to be said for that option. Here's a further extrapolation of the ASP nightmare for you: everybody who writes code makes it available only on their machine, in some .NET horror by which code is patched at runtime via RPC... so I want to set up a webserver. It uses Apache.NET, Zope.NET, ZWiki.NET, Perl.NET, and each of these (and each Perl module and Apache module) lives on its own separate server. To what are the users of my site entitled? My glue code? The kernels of each of these servers? Yeeks, dunno. Probably your glue code, but once I install that myself and use the other sites I'm using them as well (i.e., if they're under ASP-loophole-closing licenses I get access to that code too). Oooh. Neat point. So if I access a site -- even just far enough to try to authenticate myself and be refused, then use that refusal in some computation -- I can demand access to the source. That's no good. This very quickly hits the case where If you make it available to anyone, you must make it available to everyone, which I think we all agree is not acceptable. Why not the code of the routers in between? Why not the code supplying power to the computers -- or does that count as a major component of the operating system? What happens twenty years from now, when Transmeta-style reconfiguring processors are everywhere, and I'm not so much running emacs as I am rebuilding my computer into a fixed machine which implements emacs? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: The ASP nightmare: a description
Jeremy Hankins [EMAIL PROTECTED] writes: Imagine a world with omnipresent connectivity, and a lot of copylefted software. Someone decides that they could make the browser into a platform (remember Netscape the MS antitrust trial). So they take commonly available Free software packages and stick them behind a web interface. Gcc, tetex, emacs, etc. They lock them down so that no one can access the filesystem of the server directly via these packages (and thus gain access to the binaries, say), and charge a monthly fee for access. Maybe they provide a sort of stripped down client computer with a browser (possibly all proprietary) that is set up to use their server for all your computing needs. OK, so they're running a time-sharing shell server. Got it. And they're distributing a client for this shell, right? It must be under the GPL, since it's distributed linked to GPL code. So in the absolutely worst case, you sue the ASP to force them to release the source to the entire platform, since they've advertised it widely as a single work. I really do think the existing GPL covers the Nightmare case quite well, without significantly bothering people who just want to set up a shell server for some friends. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Revised LaTeX Project Public License (LPPL)
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Walter Landry [EMAIL PROTECTED] That's good, but only if you're able to modify the Base Format. It is easy to imagine scenarios where you are able to modify individual files, but not the validation mechanism. Could you please imagine one? Remember to include in your imagined scenario that the unmodified Base Format will have a documented option to turn off validation. Sure: I take the Base Format and make a functional change to it, removing the option to turn off validation. Now I distribute this under your draft LPPL. The freeness of a license should be as divorced as possible from accidents of implementation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Revised LaTeX Project Public License (LPPL)
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Brian T. Sniffen Henning Makholm [EMAIL PROTECTED] writes: Scripsit Walter Landry [EMAIL PROTECTED] That's good, but only if you're able to modify the Base Format. It is easy to imagine scenarios where you are able to modify individual files, but not the validation mechanism. Could you please imagine one? Sure: I take the Base Format and make a functional change to it, removing the option to turn off validation. Now I distribute this under your draft LPPL. But does that possibility make the original software non-free? Your argument seems to be that it is possible to make a derived version that is not free - but that possiblity exists for, say, the BSD license as well. No, but it makes my software distributed under the LPPL non free. It is not possible to distribute non-free software under the MIT/X11 license, for example. The freeness of a license should be as divorced as possible from accidents of implementation. Remember that our actual business on debian-legal is not to decide whether *licenses* are free, but whether actual pieces of *software* are free. As I said, I agree that it is possible to apply the LPPL draft in such a way that it results in non-freedom. However, I also believe that it is possible to apply it in a free way. The situation is not basically that much different from that of the GFDL. It's greatly different: the document content has no effect with the GFDL, only the license options chosen. Given that you and Jeff are proposing this license in isolation, without providing the code implementing the feature which makes this free, or even a good specification for it, I find it strange that you're now arguing that it's wrong to insist that a license be clearly free in isolation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Revised LaTeX Project Public License (LPPL)
Barak Pearlmutter [EMAIL PROTECTED] writes:
Maybe instead of sinking further and further into little details of
how files are verified to be standard LaTeX and the distinction
between the LaTeX engine and the files it reads and all that good
stuff, we could back up a step? This all really an attempt to
procedurally implement an underlying concern. Maybe the concern
itself could be directly expressed in the license, abstracted away
from its implementation?
Something like this:
You must not cause files to misrepresent themselves as approved by
the official LaTeX maintenance group, or to misrepresent
themselves as perfectly compatible with such files (according to
compatibility criteria established by the official LaTeX
maintenance group).
Would this satisfy the LaTeX people? Because I think it would satisfy
the DFSG. It might (arguably, perhaps) even be GPL compatible, if the
authorship representation parts of the GPL are properly construed.
No. The problem is this: does this ban the following code snippet:
% This is not actually standard LaTeX, but we do this for ease of use:
\set{\latexversion}{standard}
The LaTeX people are explicitly unhappy with this -- they want a ban
on something which programmatically interfaces in certain ways with
Standard LaTeX. The DFSG will accept a ban on making false claims of
authorship to humans, but not a ban on making such false claims to a
program.
-Brian
Re: Revised LaTeX Project Public License (LPPL)
Barak Pearlmutter [EMAIL PROTECTED] writes:
Something like this:
You must not cause files to misrepresent themselves as approved by
the official LaTeX maintenance group, or to misrepresent
themselves as perfectly compatible with such files (according to
compatibility criteria established by the official LaTeX
maintenance group).
does this ban
% This is not actually standard LaTeX, but we do this for ease of use:
\set{\latexversion}{standard}
The LaTeX people [...] want a ban on something which
programmatically interfaces in certain ways with Standard LaTeX.
The DFSG will accept a ban on making false claims of authorship to
humans, but not a ban on making such false claims to a program.
Well, under the misrepresentation clause above, this would in fact
be banned ... if its effect were to misrepresent the file as standard
LaTeX, and the comment were just a subterfuge.
The comment is the truth; the code is purely functional.
Would it make it less of a misrepresentation if the comment produced
output to the screen that this wasn't Standard LaTeX?
Whether this is the case would depend on the context. But if
something like that ended up fooling people about whether it was
standard, then it certainly would be a misrepresentation!
The goal isn't to fool people, it's to fool the machine. Given what
Mittelbach and Carlisle have been writing, I think they understand and
are willing to give that permission... it's just a matter of phrasing
it properly.
On the other hand, my impression is that the LaTeX people would be
okay with such a file if (in context) there was care being taken to
not fool anyone (accidentally or deliberately) into thinking that what
was running was standard LaTeX, and the line of code were the just a
technical means to get something to run, eg with some modified
non-standard proprietary engine.
Yes. That's a great example of what the draft LPPL prohibits, but
which is necessary for the pieces of LaTeX to be free software.
In other words, I suspect that what is really going on is a question
of INTENT, and subsequent effect. In this light, maybe the reason the
LaTeX people are having such problems crafting a clear simple license
is that at root they want to ban something based on intent, but (being
computer programmers) they're trying to implement this by writing more
and more complicated rules related to mechanism, and getting more and
more specific to their particular implementation.
I've CC'ed this to a LaTeX person - any comments from the LaTeX crowd?
--
Brian T. Sniffen[EMAIL PROTECTED]
http://www.evenmere.org/~bts/
Re: Revised LaTeX Project Public License (LPPL)
Mark Rafn [EMAIL PROTECTED] writes: On Mon, 7 Apr 2003, Henning Makholm wrote: AFAIU, what the authors of the LPPL draft is trying to express is nothing more or less than 1. You must make your modified package output to the screen a message that it isn't Standard LaTeX. Would it be possible to use GPL wording for this? The ability NOT to do this when written for non-interactive use is important. I seem to recall a line of argument that this is OK when only a small number of things do it, but non-free in cases where hundreds of components must do so (say, system boot time, or LaTeX). Thousands of lines of this is non-Standard LateX flying by would prevent use in many circumstances; would a single, collected This is non-Standard Latex; see logfile for which components are non-Standard meet the LaTeX group's requirements? 2. If the environment where your modified package is intended to be used provides a documented standard way of emitting such messages to the screen, you must use that. I'll need more thought about this. A requirement to use a specified facility seems unfree to me at first sniff, but I could (yet again) be reading too much into it. But you also have the freedom to change that facility, or even disable it entirely, which makes it OK. Such changes impose additional requirements on you, but I think there is a free path through this license: to make totally free changes, disable the verifier, change the package name to GNU/LaTeX, and I think you're set. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
Georg C. F. Greve [EMAIL PROTECTED] writes: gg That was also discussed about the GPL. gg Many people were complaining that it wasn't free because they gg couldn't take parts of GPL'ed software and compile them into gg their proprietary software any way they liked. I just realized that it was probably not wise to use proprietary software in that example as people might get more upset about it. In case anyone felt personally insulted: I apologize, this was not my intention. So please allow me to change that paragraph to Many people were complaining that it wasn't free because they couldn't take random parts of GPL'ed software and compile them into their Free Software without taking the GPL into account. As legal proceedings are the same and this will hopefully increase my chances of being understood correctly. You've heard all this before, but I haven't seen you answer it. Why does the GFDL prohibit me from making an emacs reference card from the manual? Sure, I could make a one-sided card where the other side is the Manifesto, but that wastes half my space. There's an easy and wrong counterargument that I'd have to include the license, but I can put that on cheap onion paper; the Manifesto has to be included as part of the document, so it's got to go on the same expensive coffee-proof laminated stock as the reference card. In addition, how does the FSF expect anybody other than itself to distribute a GPL'd emacs with a GFDL manual? As far as I can see, they cannot be distributed together. Emacs links against the manual files, interpreting them programmatically -- this is how it takes me straight to the info page referring to particular variables or functions. It is, after all, a self-documenting editor. But the GFDL imposes additional requirements over the GPL, so they may not be distributed linked. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
Georg C. F. Greve [EMAIL PROTECTED] writes: || On Tue, 15 Apr 2003 10:37:57 -0400 || [EMAIL PROTECTED] (Brian T. Sniffen) wrote: bts You've heard all this before, but I haven't seen you answer it. bts Why does the GFDL prohibit me from making an emacs reference bts card from the manual? Sure, I could make a one-sided card where bts the other side is the Manifesto, but that wastes half my space. That is most likely a special case. Technical tables are not Copyrightable per se. Their special formatting or composition might be, but generally the table itself is not. This will probably also apply to such reference cards, which is a table mapping key presses to functions of a program. So it should be perfectly fine if you took the content of that reference card and printed it as long as you took care to not include things like special formatting or logos. I suspected you were trolling before, and am now essentially convinced of it. But what the heck, I'll feed you: You're horribly confused about copyright law, reference cards, or both. A reference card has a subset of commands, chosen for usefulness, elegance, or aesthetic appeal. It has succinct descriptions, which are a creative effort. It is definitely copyrightable on either of those points. But the issue here is not copying or modifying an existing card, but deriving a reference card from the Emacs manual. bts In addition, how does the FSF expect anybody other than itself bts to distribute a GPL'd emacs with a GFDL manual? As far as I can bts see, they cannot be distributed together. Why would that be? Documents and software are different domains by law. Just putting them together -- even if one links to the other -- does not constitute one assembled work. In fact it is probable that not even hard-linking them by compiling a document into a program would legally form one work. For a somewhat definitive answer to that we'd need to have a study performed; but it is the estimation of a lawyer specialized on Copyright that I have run this through. I'm not at all sure what to say to this. Are you talking about Berne Convention copyright law? Are you really asserting that the comments and strings in a source file labelled as being under the GPL might not be under the GPL? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: LPPL, take 2
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Branden Robinson [EMAIL PROTECTED] writes: c. In every file of the Derived Work you must ensure that any addresses for the reporting of errors do not refer to the Current Maintainer's addresses in any way. This is somewhat new ground for a DFSG-free license. Is it *really* that important? If so, I'd like to hear advocates of it explain why it's more free than, say, a prohibition against the creator of a Derived Work calling the Current Maintainer on the phone to ask for technical support. This is sufficiently awful as to be unacceptible. For example, suppose Debian takes the package, and modifies it. We prune all the previous bug reporting addresses, and mention only normal Debian addresses, including debian-devel. And then one of the Current Maintainers subscribes to debian-devel. It now becomes *Debian's* responsibility to deal. Eek! I think tb's problem is with the in any way phrasing. How's this for an alternative: c. The Current Maintainer may have included an offering of technical support for his work, labelled Support Information. You must remove any such offerings, though you may add your own. If there is other information regarding support from or contact information for the Current Maintainer, you may treat it under the other terms of this License. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: LPPL, take 2
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: c. The Current Maintainer may have included an offering of technical support for his work, labelled Support Information. You must remove any such offerings, though you may add your own. If there is other information regarding support from or contact information for the Current Maintainer, you may treat it under the other terms of this License. Sure, that's fine. But the LPPL people might not like it, given their weirdness. The following would be permitted: Create [EMAIL PROTECTED]; subscribe the original contact information to it, and then advertise this as the bug-reporting address. Sure, but that's somebody being intentionally perverse. I could advertise my address, and auto-forward to the CMs, or whatnot, as well. Or I could order a pizza to their address and giggle when they were surprised. The License isn't going to stop jerks from being jerks, so we don't need to invest *too* much effort in imagining how jerks might act. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
Glenn Maynard [EMAIL PROTECTED] writes: On Thu, Apr 17, 2003 at 03:05:48PM -0400, Brian T. Sniffen wrote: But the issue here is not copying or modifying an existing card, but deriving a reference card from the Emacs manual. If the documentation was licensed under the BSD license, wouldn't you still have to include the full license text on the card? If the GPL, a change list as well? No. I could include them on another piece of paper with the card. Those licenses merely require text be included *with* the document. The GFDL mandates that invariant sections be part of the document, which is much worse. For example, if I want to create some art with Richard Stallman's photograph over a backdrop of text from the emacs manual, I have to include the GNU manifesto as *part of the picture*. It's not enough to include it alongside the picture, it has to be part of the same document. In contrast, the free GPL or free BSD license lets me just include a copyright statement for the text, and a copy of the license, with the picture. If these are a problem as well, the argument against the GFDL here is less interesting; and if they're not, this GFDL argument probably isn't, either. There seem to be other, more convincing arguments against invariant sections. For example, if I want to perform a dramatic reading of a page from the Emacs Manual in some horribly expensive format, I have to read a bunch of invariant sections with it. I agree that there are more convincing philosophical arguments to avoid invariant sections, and to consider invariant sections non-free. But this is an example of a category of practical problems introduced by invariant sections, something which can be presented to those who say this is merely a philosophical issue. -Brian
Re: Suggestion to maintainers of GFDL docs
Stephane Bortzmeyer [EMAIL PROTECTED] writes: On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith [EMAIL PROTECTED] wrote a message of 25 lines which said: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. Can you actually write this section and post it here? Because I have a practical problem: finding a free licence for an important documentation I'm currently writing (and one which is not included in a specific software) and, after getting a headache from reading hundreds of previous postings in debian-legal, I still have difficulties to find a proper licence. Practical advices are welcome. I believe it is easier to bash the GFDL than to write a proper alternative. The MIT/X11 license and the GPL would both work, depending on whether you want a copyleft. The MIT license can probably be used just by itself. To use the GPL, though, you should probably put in a section which explains how your document can be viewed as software, along the lines of: This section is for clarification only. It is intended to expand on the wishes of the author, but should not be interpreted to change the license or copyright status of the work. The author intends that the LaTeX2e source for this document be treated as the preferred form for modification, which is to say the Source Code. All other formats -- even open, transparent formats such as plain text or HTML -- are hard for the author to use in integrating changes to his copy of the document, and so should be considered Object Code. Again, this isn't a binding statement, and any distribution in a preferred form for modification, such as plain text or clean HTML, is acceptable as Source Code under the license. Distribution in a closed, hard to modify format such as PDF, generated HTML or PostScript, or a Microsoft Word document should always be treated as Object Code. I hope that's useful to you. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
iain d broadfoot [EMAIL PROTECTED] writes: * Brian T. Sniffen ([EMAIL PROTECTED]) wrote: The MIT/X11 license and the GPL would both work, depending on whether you want a copyleft. The MIT license can probably be used just by itself. To use the GPL, though, you should probably put in a section which explains how your document can be viewed as software, along the lines of: This section is for clarification only. It is intended to expand on the wishes of the author, but should not be interpreted to change the license or copyright status of the work. The author intends that the LaTeX2e source for this document be treated as the preferred form for modification, which is to say the Source Code. All other formats -- even open, transparent formats such as plain text or HTML -- are hard for the author to use in integrating changes to his copy of the document, and so should be considered Object Code. Again, this isn't a binding statement, and any distribution in a preferred form for modification, such as plain text or clean HTML, is acceptable as Source Code under the license. Distribution in a closed, hard to modify format such as PDF, generated HTML or PostScript, or a Microsoft Word document should always be treated as Object Code. perhaps change 'clean HTML' to 'w3c valid HTML', with a link to w3c.org's validation site? It would be nice if that worked, but there's plenty of obfuscated HTML code which is valid. If you want to claim HTML as a preferred form of modification for any of my documents, I really want it to be hand-written. Others might prefer Dreamweaver-compatible HTML, though. and possibly avoid referring directly to MSWord as well - a reference to 'binary, closed file formats' would probably do the same job. Yes, that might be better. I'd avoid the words closed and binary, as MS is already trying to redefine both. Perhaps formats of proprietary word processing programs. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
iain d broadfoot [EMAIL PROTECTED] writes: and possibly avoid referring directly to MSWord as well - a reference to 'binary, closed file formats' would probably do the same job. Yes, that might be better. I'd avoid the words closed and binary, as MS is already trying to redefine both. Perhaps formats of proprietary word processing programs. hmmm, even that might not cover enough - we wouldn't want OOo Write format to be treated as Source Code presumably. Actually, if I can get free software which can read it and parse it into something useful to me, I'm content with that. I'd prefer more, but requiring that it's easily editable using free software is enough. perhaps it should be chopped back further, to say that the Source must always be directly editable as text rather than requiring to be parsed _before_ editing - that would cover plaintext, LaTeX, HTML etc and block PDF, PS MS, OOo, Abi, etc etc etc. 'Distribution in any format that requires parsing to be editable should be considered Object Code' or similar? maybe limit the allowed parsing to `cat $FILENAME`... :D But I actually do write documents in raw PostScript, by hand. It's quite readable, well-commented code, too. The requirement that source be plain text seems... short-sighted. A month after that goes into recommended text, someone *will* show up here with an illuminated manuscript they want to distribute, and the calligraphy's important... oh, there you go: ideally, this text should work for non-English text, and for documents which have embedded graphics. Plain text really doesn't satisfy either of those. Since this isn't actually license text, but merely accompanying clarification, it's probably OK to be sloppy and request plain text, or must be editable with free software. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Suggestion to maintainers of GFDL docs
iain d broadfoot [EMAIL PROTECTED] writes: plain text would simply mean that i can type `vim something`, and have the text appear in front of me. presumably, those strange foreign chaps already have their systems set up to handle those strange foreign chars. But *I* don't. So it's not a preferred form for modification to me. i'm never entirely convinced of the need for inline images, but i can certainly see that they _would_ be used if available. The argument doesn't need them to be inline, just graphics which need to fall under the same license as the text. .fig is very close to plain text, but really not parsable by humans above a very simple level. Since this isn't actually license text, but merely accompanying clarification, it's probably OK to be sloppy and request plain text, or must be editable with free software. but that allows MSWord docs, since i can edit them with Abiword, OOo etc... *Some* word docs might, then, be considered open. Certainly, I've been unable to open others in reasonably up-to-date Abiword or OpenOffice. maybe request a plain text version alongside any other formats? or must be editable with free software and must be saved in a Free format? Since these are just suggestions from the author, I see no harm in any of these. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
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
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
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
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/
Re: If Debian decides that the Gnu Free Doc License is not free...
As far as I am concerned, I have no desire to have ReiserFS distributed for free by anyone who removes the GNU manifesto or similar expressions from Stallman's work (or my own) and redistributes it. It is simply a matter of respect that is due the author. Respect is due; but it is up to Debian to decide how to show respect. To be clear, Debian isn't talking about removing the GNU Manifesto from even a single package. The only question is what permissions are granted to Debian and its users. That none of us have any intention of taking advantage of freedom to injure the original authors of this software does not prevent us from recognizing whether we have such freedom. -Brian
Re: LPPL and non-discrimination
Jonathan Fine said: The proposed new LPPL discriminates between person(s) who are the Current Maintainer, and those who are not. I have suggested that this is against Debian guideline 5 - non-discrimination. Two contributions have said, for various reasons, that the guideline does not apply in this situation. Suppose the proposed LPPL discrimination is allowed. How then can discrimination such as: If the licensee is ABC Software Inc then the licensee may freely incorporate this work into its proprietary software. be resisted? Let me propose a situation for you: I've written a program from scratch; I am the sole author. I distrubte it under the GNU GPL. You agree with me that it is unambiguously Free Software, correct? Now, in exchange for money, I license somebody else to modify and distribute my code in any way he pleases (that is, I use the MIT/X11 license). At some later point, I publish that I've done this. At some later point, I extend my work to link against OpenSSL, and so begin distributing it under the GPL, with an additional grant of permission to link against OpenSSL. In your model, at what point does my software become non-free? The real answer, of course, is that it never does: anybody can treat it as free software, so it is free software. That I have licensed shockingly similar code to someone else, who has done something with it in a non-free way, changes nothing. As another example, the BSD networking code has been incorporated into parts of MS Windows; this does not stop the original code from being Free Software. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: LPPL and non-discrimination
Mark Rafn [EMAIL PROTECTED] writes: On Mon, 5 May 2003, Jonathan Fine wrote: Two contributions have said, for various reasons, that the guideline does not apply in this situation. I will say it too. It's come up before, and been agreed that as long as it does not discriminate to the point that it is non-free for any person, group, or field of endeavor, then it is free. That isn't quite the consensus I've seen. For example, a license which claimed to be MIT/X11 for educators only, and GNU GPL for non-educators only, would, I argue, be unfree[1]. There needs to be a single free path through the license available to everybody; at that point, the license is effectively reduced to that set of conditions and is free. Dual-licensing has never been considered by Debian to be discriminatory, as long as there's a free license available to every person, group, and field of endeavor. I think this hints at something closer to what I've seen. -Brian Footnotes: [1] In addition, it would be internally inconsistent if it tried to prevent educators from distributing further under the MIT/X11 license, or non-educators from distributing further under the GPL. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: LPPL and non-discrimination
Jonathan Fine [EMAIL PROTECTED] writes: I think that there may have been a misunderstanding, caused by an ambiguity in the term free software. (Now there's a surprise.) Once it has been clarified, I think that there will be more agreement. So let's try. 1. Software is executables, source files, etc. You're going to get yourself into trouble if you go much further here: defining software both accurately and precisely is very, very hard. 2. The copyright holder can license the software to third parties. 3. Licensed software is free, according to the Debian Guidelines, if: a) the license meets the Debian Free Software Guidelines. b) the software is available as unobfuscated source, and not encumbered by patents or the like. (b) is reducible to (a). That is, anything which complies with the DFSG will be modifiable and redistributable, so it must exist in a clear, modifiable format without legal encumbrance. 4. The copyright holder can license software under both free and proprietary licenses, if he/she wishes to. So ABC Software can if they wish release the software they have written under a license that is Debian Free (call it DFL) and a proprietary license also (call it ABC-PL). Typically, the ABC-PL will cost money, and will allow creation of non-free derived works. Typically, the ABC-DFL will also allow creation of non-free derived works. For example, the BSD and MIT/X11 licenses both allow creation of non-free derived works by any party. The prohibition against creating non-free derived works is not a characteristic of free licenses, but of copyleft licenses. Most copyleft licenses happen to be free licenses as well. So far, I think we have agreement. With some exceptions and clarifications, yes. My concern is with the Debian Free License, and the non-dsicrimination guideline. I think you might understand more if you broadened your concern to look at Debian's process of accepting software (from ITP to upload) as a whole, and the role debian-legal and the DFSG play in that process. 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? Yes. Maybe. If this is the MIT/X11 license, for example, the addition of your candidate paragraph does not make it non-free. Indeed, for almost every non-copyleft license, this paragraph may be freely added: it imposes no restriction on anybody other than ABC Software. If DFL is a copyleft license, though, this is probably non-free. It imposes a cost to distribute modifications. This is very hard to talk about, because licenses aren't modular: each restriction or grant of permission ties into all the others. I don't think you can use an abstract DFL for this sort of conversation. This seems like a weighty proposition now, but for any particular example plugged in for DFL (CAL, GPL, MPL, BSD, etc), the question is either a very clear Free, a very clear Non-Free, for reasons other than discrimination or a very clear That's nonsense. This is a question, of course, about the working of the non-discrimination guideline. Partly... but when similar licenses have been proposed in the past, they've been rejected for failure to permit free distribution of modifications, not for unfair discrimination. I don't think you're going to be able to put together an example where bias towards the copyright holder involves the discrimination clause. The discrimination clause is more commonly used to prohibit software which is licensed as, for example, MIT/X11, but only if you do no work involving a nuclear power plant or Free for non-commercial use only. -Brian -- Brian T. Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [OT] Droit d'auteur vs. free software?
Henning Makholm [EMAIL PROTECTED] writes: Does this clear implication extend to documentation released under a Free licence? Does this clear implication extend to literary, visual arts, or audio works released under a Free license? I'd say yes, *if* the author *voluntarily* made the software free. Your emphasis is disturbing: does the exchange of licenses involved in distributing GPL'd software derivative of other GPL'd software count as voluntary throughout Europe? That is, is Freedom to Modify and Distribute an essential part of the artistic character of MySQL, XEmacs, and other works which the authors would rather have proprietary, but which they can't distribute except under the GPL? Thanks for taking the time to explain this system to the Common Law folks here. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [OT] Droit d'auteur vs. free software?
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Nathanael Nerode [EMAIL PROTECTED] RMS could use his 'moral rights' to prevent someone from distributing a version of Emacs which could read and write Microsoft Word files (file format being reverse-engineered). No he can't. His placing Emacs under a free license, aside from his numerous writings about software freedom, clearly imply that his works have no intrinsic artistic character that could possibly be violated by any third-party modification. But someone, I think you, said very early in this conversation that if an author is economically pressured to put his work under the GPL, that putting it under the GPL would not be regarded as proof of his intended artistic character. Doesn't that put the GPL'd work of groups like MySQL or the KDE group at risk under your system? -Brian
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Tue, 2003-05-20 at 05:15, Branden Robinson wrote: I am uncomfortable with some of the ramifications but I am also uncomfortable with totally declawing the GNU GPL by adopting and interpretation of it that would let people wrapper and language-bind their way out of the copyleft commons. At some point, we've got to draw a line where it's de-clawed. After all, I think we all agree that if a shell script calls GNU grep[0], it isn't required to be under the GPL. I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So, is encapsulating code in the kernel's execve interface always OK? The distinction really does come down to whether something is a derivative work: a shell script which coincidentally uses generic grep functions isn't a derivative work of grep. A shell script which wraps GNU grep to provide some of its peculiar functions to another program is a derivative work of GNU grep. There is a wide swath of gray down the middle; this is where we hope people are reasonable, and if not obey the wishes of the original authors. -Brian [0] Which, btw, has many extensions over POSIX or BSD grep, so there is not, AFAIK, an alternative implementation. Alternatively, put gcc or your favorite GPL program in its place. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote: I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So every script that Debian distributes that makes use of features only found in GPL tools must be under the GPL (since Debian can't use the normal part of OS exception). Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. The distinction really does come down to whether something is a derivative work: 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) It's hard to see how a shell script could be a derivative work of grep under that definition. I don't think the shell script is an transformation, recasting, or adaption of grep. Or a modification. It certainly can be. For example, consider the shell script greppager, which simply runs grep and pipes the output through $PAGER. That's a program constructed as a transformation and recasting of grep. That it includes grep by reference rather than by copying shouldn't matter -- this is the heart of the FSF's linking is modification argument. Greppager is a work based on a pre-existing work, consisting of elaborations and other modifications which, as a whole, represents an original work of authorship. I don't need to edit the source of a computer program to modify the program: I can create a derivative function by wrapping another function. The output of (lambda (f) (lambda (l) (map f (filter even? l may be a derivative work of f, for example. That a shell script is easily broken apart and read by a human shouldn't matter. For example, if I distribute a macro package which, given some text, loads MS Excel and uses that to perform some calculations, then closes Excel and uses the output of the calculations for some other purpose, that's clearly a derivative work of Excel. If my work couldn't have existed in the same form without another work, my work is derivative of that work. a shell script which coincidentally uses generic grep functions isn't a derivative work of grep. A shell script which wraps GNU grep to provide some of its peculiar functions to another program is a derivative work of GNU grep. Where do you see that in the definition above? To further clarify, given a copyrightable program P which implements an algorithm A(x), a program Q which implements B(A(x)) by nontrivial use of P is a derivative work of P. Put simply, if it's clear that you wrote Q intending it to wrap P, Q is a derivative work of P. If you wrote Q to work with a separate standard, or with a wide variety of programs P1, P2, etc. all presenting a similar interface to P, then Q isn't a derivative work of any of them (and it's most likely not derivative of the standard, because the procedures expressed in the standard are not copyrighted, only their expression there). -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Stephen Ryan [EMAIL PROTECTED] writes: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote: I don't. If it makes use of features specific to the GNU version, it should either use the normally part of your OS exception, or if distributed with GNU grep be itself available under the GNU GPL. So every script that Debian distributes that makes use of features only found in GPL tools must be under the GPL (since Debian can't use the normal part of OS exception). Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. I'm surprised no one else has jumped on this yet. No. The script in question is a derivative of both OpenSSL and of adduser, and the author of the script has no legal standing to relicense either of those. Thus, no script which uses both OpenSSL and adduser may be distributed by anyone under any terms, because it would link OpenSSL with adduser, and they are under incompatible terms. Even though the script itself may offer an exception for OpenSSL, adduser doesn't have that exception, and thus, the work as a whole is undistributable. Sounds reasonable. I'm not entirely clear on why adduser and update-rc.d are under the GPL and not the BSD license... but given their authors licensed them in ways that forbid linking with non-GPL-compatible software, such as OpenSSL, that sounds reasonable Wait. Isn't dpkg under the GPL? Now everything on the entire system has to be under the GPL, because you can't even get it installed without the use of dpkg. I don't see how a program which merely happened to be installed using dpkg can be said to be a derivative work of dpkg, any more than it being a derivative work of whatever tool was used to download the .deb file, or whatever router software runs in the middle. All of those -- TCP, HTTP, and DEB -- are generic formats. Implementing to a standard does not make your work a derivative work of a popular implementation of that standard. The other option, of course, is that the kernel exec() function *is* a barrier, I don't understand why you believe a technical definition is relevant. Why exec and not ld? Why not JMP? Why not #include? The barrier as you put it has nothing to do with bits. It is defined by thought: by the intent of an author of a potentially derivative work. If he, in his creation, is intentionally deriving creative ideas from the author of a previous work, his work is derivative. If he's creating independently of previous programs, or implementing to a specification, his program is not derivative of any other program. So if I write a shell script which makes calls to /usr/bin/openssl, my program is derivative of Eric Young's program, so we both have a copyright on the result. If my script also calls GNU grep, and I looked at the info page while writing it, consciously implementing it to use features particular to GNU grep, then it's also derivative of that program, and the FSF also owns a copyright on it. Doesn't this framework seem easier to work with than trying to find a technical definition of a barrier? Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Center for Educational Outcomes at Dartmouth College Ahem. I'm all for getting real work done: I just don't see a need to bend the law or the intent of an author to do it. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 01:45 PM, Stephen Ryan wrote: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: The other option, of course, is that the kernel exec() function *is* a barrier, Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Whoa! Those are not my words. I'm not quite sure whose they are. Well, I don't believe exec is a magic copyright barrier; instead, I think we need to generalize _why_ we generally consider it be one. But this leads me to believe that we may well be on common ground; what generalization do you see there? -Brian
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 03:30 PM, Brian T. Sniffen wrote: Wait. Isn't dpkg under the GPL? Now everything on the entire system has to be under the GPL, because you can't even get it installed without the use of dpkg. I don't see how a program which merely happened to be installed using dpkg can be said to be a derivative work of dpkg, Well, he is going a little far. But certainly the postinst, preinst, postrm, etc. files would have to be, as Debian distributes them in such a way to force dpkg to link them (by executing them). That would mean that everything used in those scripts has to be GPL-compatible. I didn't say *all* execution was derivation. Execution is a form of use, not covered by copyright. Creation with a certain target in mind is derivation, though. All of those -- TCP, HTTP, and DEB -- are generic formats. .deb isn't. There is, AFAIK, only one implementation. At the very least, alien and dpkg deal with it; I believe there are others. BTW: If the documentation in the policy manual makes it a standard, why doesn't the documentation in the GNU grep manpage, info page, etc. make it a standard, too? They do -- but really, you'd rather be writing a derivative of a GPL work than a GFDL work. If he, in his creation, is intentionally deriving creative ideas from the author of a previous work, his work is derivative. The only thing I'm deriving from in, e.g., grep is, if anything: 1) its command line interface 2) its functionality In Lotus Development Corp. v. Borland International, Inc.,[0] the court held that a menu structure is method of operation. Methods of operation are, by statute, not copyrightable. To quote the decision: We think that method of operation, as that term is used in 102(b), refers to the means by which a person operates something, whether it be a car, a food processor, or a computer. We hold that the Lotus menu command hierarchy is an uncopyrightable method of operation. The Lotus menu command hierarchy provides the means by which users control and operate Lotus 1-2-3. Users must use the command terms to tell the computer what to do. Without the menu command hierarchy, users would not be able to access and control, or indeed make use of, Lotus 1-2-3's functional capabilities. The Lotus menu command hierarchy does not merely explain and present Lotus 1-2-3's functional capabilities to the user; it also serves as the method by which the program is operated and controlled. gibber OK. Well, that settles that argument: if this hasn't been reversed, you're unambiguously correct. Thanks for pointing this out! I wonder how this relates to library interfaces... certainly, those are methods of operation as well. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 09:52 AM, Brian T. Sniffen wrote: Let's take a concrete example: apache-ssl. In particular, it's postint. It uses adduser, which is under the GPL. It also uses update-rc.d, also under the GPL. So, as above, we have to say the postinst is available under the GPL. However, it also uses /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the GPL and the OpenSSL license are not compatible. Is the above legal? If so, why? I'm not a lawyer -- but I think distribution of apache-ssl.postinst must be distributed under the terms of the GPL. As such, it can't be distributed by others without an OpenSSL exception or a license which grants a superset of the freedoms of the GPL. OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. Not quite -- I'd prefer to find a more reasonable solution first, and begin implementing it second. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Tuesday, May 27, 2003, at 15:20 US/Eastern, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: OK, then I take it you're in favor filing seriouss bug against ftp.debian.org asking for the removal of apache-ssl and *many* more packages like it. Not quite -- I'd prefer to find a more reasonable solution first, and begin implementing it second. Can we call Lotus v. Borland a reasonable solution? ;-) Heh. Given the chain of logic: A means of operation is not copyrightable; All user interfaces are means of operation; exec() is a programmatic user interface... I'm even willing to concede that exec() is always a boundary between works. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: The debate on Invariant sections (long)
Richard Stallman [EMAIL PROTECTED] writes: This problem is unfortunate, but no worse in the case of two ways of using the GFDL than with a pair of two different free software licenses. But no pair of licenses is claiming to create a shared commons. Heretofore, the FSF has been claiming to create a new commons within the GPL/LPGL universe. The GFDL not only does not contribute to that commons, nor can it draw from it, but does not even create a single commons itself. Questions of freeness aside, it is this which most disturbs me about the GFDL: I can't just know that some set of works are all under the GFDL and so assume that I have certain freedoms with respect to them: I need to consider the interactions of Invariant Sections and Cover Texts. Back to the issue at hand: individual documents licensed under the GFDL may be free, but derived works from them may not be useful to the original author: thus, it doesn't seem like a copyleft. Documents under the GFDL can't be freely adapted to my needs. I also don't have freedom to improve such a document and release my improvements alone. You say that the purpose of a political essay is to sway readers to the ideas of the author: I agree, but I assert it is the reader, and not the author, who decides on this purpose. The reader, not the author, corresponds to a person running a program. There are reasons to distribute political essays without license to modify them... but such essays are not Free. Your essays, for example, distributed under invariant-copy licenses, only serve the purpose of readers who wish to be informed as to your views. If distributed under a free license, say the GPL, they might serve those purposes, your purposes in the initial writing, and also enrich the community's political discourse. It's as fine and reasonable for you to be unwilling to contribute to that as it is for many people to be unwilling to contribute to the community's pool of useful software: but neither situation is free. You've probably heard the above arguments before; I know I have. Despite my searching through the FSF's web site, though, I couldn't find any answers to the following questions: 1. Does the FSF consider an invariant-copies-only political essay free? 2. What's the deal with the GPL-incompatible GFDL? What was so important that sacrificing this was worth it? 3. Where's a clear explanation of what I *can't* do with a GFDL'd document? What do I do when I find a badly inconsistent document (non-Secondary Invariant sections, for example)? What happens when a reasonable transformation of a document makes an Invariant Section non-Secondary? 4. Given that the FSF's screwed up use of the GFDL (the GDB manual, for a while), should I trust that this license is understandable by the general public? 5. Why should I make some sections of my document invariant? 6. Perhaps most importantly, what are my alternatives, and why should I prefer the GFDL to each of those for practical or moral reasons (comparing to at least the GPL, MIT license, invariant-copying licenses)? -Brian
Re: MySQL licensing and OpenSSL linking issues
Steve Langasek [EMAIL PROTECTED] writes: On Fri, Jun 06, 2003 at 11:25:51AM -0500, Branden Robinson wrote: On Fri, Jun 06, 2003 at 10:39:23AM +0200, Christian Hammers wrote: Attached and below you'll find the recent plans of MySQL regarding their licenses. I would think that this is sufficient for the Debian project. If not please scream loud now! :-) [...] Here is our initial plan to fix the problems that been created by the change in licensing. We are considering offering a blanket exception that will allow MySQL to be used in combined works where the combined work is licensed under one or more OSI approved licenses. [...] Can you see problems with this approach? Yes! What happens if OSI ever decides to yank their approval from a license, what happens then? I think MySQL is best advised to draft license terms that require as little reference to certifications and proclamations of third parties as possible. Would it be reasonable to ask them to snapshot the OSI license list with every release? This would ensure that the permission to link isn't retroactively revoked by a third party, while saving MySQL AB the work of coming up with their own definition of what they consider acceptable. As long as this is a list of *additional* linking permissions, and the contributors are ok with this sort of license, I don't see any reason why this couldn't work. The contributors would each need to assent to each change of the list, or assign copyright to MySQL, or assent to the schema of changes (and I'd assume that last to be shaky). That's a lot of paperwork for each release. Other than that issue, I think this would nicely address Debian's needs. I'm pleased to see MySQL AB taking this step to clarify the license of the client libraries. It seems at that point that it would be easier to just put it under the LGPL. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: MySQL licensing and OpenSSL linking issues
Steve Langasek [EMAIL PROTECTED] writes: On Fri, Jun 06, 2003 at 02:51:31PM -0400, Brian T. Sniffen wrote: Would it be reasonable to ask them to snapshot the OSI license list with every release? This would ensure that the permission to link isn't retroactively revoked by a third party, while saving MySQL AB the work of coming up with their own definition of what they consider acceptable. As long as this is a list of *additional* linking permissions, and the contributors are ok with this sort of license, I don't see any reason why this couldn't work. The contributors would each need to assent to each change of the list, or assign copyright to MySQL, or assent to the schema of changes (and I'd assume that last to be shaky). That's a lot of paperwork for each release. Why? If MySQL themselves can offer a license that references an external list (the OSI list), why can't the MySQL contributors do the same with regards to a list vetted by MySQL? I don't think Branden was objecting to the legal validity of this technique, only to the impracticality of depending on such a list that could change over time and result in de facto changes to the license of code already in use. That has other issues, in that the MySQL contributors would have to use a different license than MySQL AB uses -- practically difficult, and prone to forking. Really, the best license for Free and may only be linked with free things (which seems to be what they want) is the GPL itself. Encoding complex criteria for freeness into a license just seems like a very difficult proposition. Other than that issue, I think this would nicely address Debian's needs. I'm pleased to see MySQL AB taking this step to clarify the license of the client libraries. It seems at that point that it would be easier to just put it under the LGPL. Except that the LGPL permits use of the code in ways that MySQL does not want to allow. Nah, the LGPL is OSI-certified, isn't it? Oh, there's a distinction between You may link to anything under an OSI-certified license, such as the LPGL and this is under the LGPL. Hm. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [RFC] Modification history as a source code
Steve Langasek [EMAIL PROTECTED] writes: No, you should only provide the C source, because the binaries being distributed are those of the modified C program. Once I've started editing the C program, I've made it unambiguously clear that this is the preferred form for modifications; just because the Pascal source exists doesn't mean I should have to distribute it. So if I take a compiled C program -- say, something I got from Debian but for which I do not have the source -- and run 'strip' on it, is it the case that the unstripped binary is the source, and the stripped binary the object? The compiled binary is clearly the only possible form for the modification I've just performed. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Defining 'preferred form for making modifications'
Thomas Bushnell, BSG said: Anthony DeRobertis [EMAIL PROTECTED] writes: It's true that the GPL wording implies that there is a single preferred form, Yep. The GPL was designed for compiled programs, and it shows in several places. The relation between a xcf and a gif is precisely one of compilation. Nonsense. I edit multiple images into a single image all the time, but rarely save an XCF file: multiple layers live in the image-editor's memory, but never hit the disk. There is no persistent form which represents source any more than there is for a wood carving or a painting. The original images might be, but I'm usually using very small subsets of them. Now, in some cases of a GIF there may be a source file, where opening the XCF and essentially hitting save as GIF will produce the object form, but it's hardly the general case. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Defining 'preferred form for making modifications'
Thomas Bushnell, BSG said: Brian T. Sniffen [EMAIL PROTECTED] writes: Nonsense. I edit multiple images into a single image all the time, but rarely save an XCF file: multiple layers live in the image-editor's memory, but never hit the disk. There is no persistent form which represents source any more than there is for a wood carving or a painting. There is, but you delete them. This is exactly parallel to writing Scheme code in an online Scheme system, but never saving it, and then at the end, writing out a standalone executable, quitting, and destroying the source. The fact that it may be common practice to destroy the source in image editors is lamentable, but doesn't change the relationship of the parts. It certainly does: if there is no persistent form, it isn't the source. Otherwise, the elisp code which is generated (and used, but usually never seen) by programmers writing C in Emacs would have to be distributed as part of the build scripts -- I don't have to distribute C-mode, the current region stack, or ephemeral keyboard macros with my C programs, right? I'm not entirely convinced it *always* applies, but in general it seems that persistent storage is a good rule of thumb for identifying source. If I didn't save it to work on later, it isn't source, but a single act of creation. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: removing non-invaraint section from a GFDL doc
Nick Phillips [EMAIL PROTECTED] writes: On Sun, Jun 29, 2003 at 09:52:17PM -0400, Anthony DeRobertis wrote: Hello debian-legal, Suppose I remove all the non-invariant sections of a GFDL document that have some sections marked invariant. Are the invariant sections still secondary? I don't know. More directly, say that a invariant section suddenly becomes non-secondary because of a program's evolution. Then what? If you have a look at the GFDL, it appears that the intention is that any content for which that could be the case cannot be secondary anyway. That may be the intent, but it's hardly the effect. Imagine, for example, M-x generate-documentation-for-program, which automatically generates a manual page for a program. If called with C-u as a prefix, it generates free documentation, pulling from non-free sources. The Why Free Programs Need Free Documentation essay, which had been secondary, is no longer such. -Brian
Re: simple translation copyright issues
Steve Langasek [EMAIL PROTECTED] writes: It's my understanding that dictionaries, because they contain elements of originality in the selection and wording of definitions, constitute copyrightable works. At least in the US, to be copyrightable a work must be of a certain minimum length; I expect (though IANAL) that the examples listed above aren't enough to gain copyright protection, though a more extensive dictionary very well might be. While I agree with you about the copyrightability of dictionaries, I believe you're mistaken about the minimum-length requirement: several artists have copyrighted silent pieces of music, for example. There is also the emerging field of nanofiction, which is confined to 55 words or less. Many of Emily Dickinson's poems are shorter than that, and each would receive separate copyright protection. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: GFDL and man pages
Walter Landry [EMAIL PROTECTED] writes: Florian Weimer [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: You can make a manpage, but you must have to include inside the manpage Actually, it's sufficient to refer to this information in the SEE ALSO section of the manpage, so that elaborateness of the GFDL doesn't interfere with the intendend use of the manpage for quick reference. Note that this all has to be _in_ the manpage. The FSF has a different view on this matter. The FSF doesn't read its own license. Section 4 states: In addition, you must do these things in the Modified Version: ... # H. Include an unaltered copy of this License. That looks pretty clear to me. It would be clear, if this were the GNU Free Manpage License. The FSF makes a claim I know I've heard here before: that there is no one-to-one mapping from files to works. They'd presumably consider all the manpages in the csound package to be a single work, and have each refer to a central gfdl(8) page. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Implied vs. explicit copyright
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Drew Scott Daniels [EMAIL PROTECTED] writes: Is the an implied copyright notification (I.e. code added by person) sufficient in the debian/copyright or is it necessary to say explicitly say year copyright person? There is no such thing as implied copyright. But he didn't say there was. He said there was an (implied (copyright notification)), which there is. In the USA, setting down a form of art is sufficient to grant copyright. So writing Extra Foo added by Brian Sniffen is enough to make readers aware that I own the copyright on the Extra Foo bits. In some places, the incantation Copyright (c) 2003 Brian Sniffen has legal meaning. Even in the US, it's illegal to falsely place such a notice. Given all of that, I think it would be better if you *could* put such a statement into debian/copyright, but probably not a good idea for you to independently write one. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Implied vs. explicit copyright
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Andrew Suffield [EMAIL PROTECTED] writes: This is a plausible argument. You should know by now that plausible arguments do not form a basis in law; rather, it is merely the position put forth by the counsel for the defence. Kindly refrain from treating it as anything else. Oh, puhleez. There is no more reason for taking '(c)' to mean anything in copyright law than taking 'Flobotzink as meaning something. Or do you have case law for this? No, of course not. You have no official reference for anything suggesting that '(c)' has any meaning, and I have reference after reference giving an explicitly exhaustive list of what does have meaning, in which '(c)' is simply never listed. It certainly is. That's a c in a circle. It's not a flawlessly perfect circle, but I drew one as best I could. I can't draw a circle well freehand either, and neither can I generate one on a modern pixel-based printing device. So I guess that symbol is useless, unless approximations to it are permitted. It does not say this: - No alternate representations form an acceptable notice Yes, it does. Did you even to follow up the references I have from the United States Copyright office? I guess not. http://www.copyright.gov/circs/circ03.html says: Omission of notice is publishing without a notice. In addition, some errors are considered the same as omission of notice. These are: * A notice that does not contain the symbol [here they give the symbol] (the letter C in a circle), or the word Copyright or the abbreviation Copr. or, if the work is a sound recording, the symbol [the other symbol] (the letter P in a circle); * A notice dated more than 1 year later than the date of first publication; * A notice without a name or date that could reasonably be considered part of the notice; * A notice that lacks the statement required for works consisting proponderantly of U.S. Government material; and * A notice located so that it does not give reasonable notice of the claim of copright. If you are going to insist that I provide official references, the least you could do is read them when I provide them. Ah. So you were lying, or just didn't understand what you were reading. The following are all valid copyright notices: * Copyright 2003 Sample Author * echo Copyright \copyright 2003 Sample Author | tex * Copyright 2003 Sample Author. Baboons are pretty * This document was written in 2003 by S. Author. Baboons are pretty. He retains Copyright coverage on all of this document. And, despite what you've been arguing against, * Copyright (c) 2003 Sample Author That's all. There's no harm from putting a (c) in addition to the word Copyright, and it might even make things more clear. It gives a nice retro, typewriter feel to a document. I stipulate, again, that there is no legislated decision one way or the other. And I am aware of no precedent in this matter. There is a clear legislated decision. It says you must do this. Then it says if you don't do this, it's the same as no notice. And there is a common agreement among a bazillion people that if you don't do it in just those terms, it doesn't come up. Yup. And despite your repeated rants about references, there's still nothing that says and adding an extraneous symbol voids your copyright. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: translations under Creative Commons license?
Michael D. Crawford [EMAIL PROTECTED] writes: So, are you suggesting that freedom would be better served if the GNU manifesto provided for modification? Note the manifesto's license: Permission is granted to anyone to make or distribute verbatim copies of this document, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Modified versions may not be made. Suppose the Manifesto were a free document. That would allow Microsoft's PR flacks to update the Manifesto to exhort the user to protect corporate rights to intellectual property, and illustrate how respecting End User License Agreements stimulates not only the nation's, but the world's economy. You are incorrect. The Free Software Foundation has a monopoly on the trade mark GNU. As a result, no other organization may title a document GNU Manifesto without the FSF's permission. So yes, suppose the Manifesto were a free, copylefted document. That would allow Microsoft to use parts of the Manifesto to support their own ideas. It would also allow the FSF to use parts of Microsoft's Manifestos. Would that serve the cause of freedom? A free and open commons of ideas serves the cause of truth, through which we maintain freedom. A benevolent dictatorship of ideas, such as the FSF is attempting to create with the GFDL, is not Freedom -- merely a new set of masters. I'm aiming to do the same thing with music, and I don't want the record industry to put words in my mouth. Neither do I want to allow that of people who might be well meaning but incompetent. Fortunately, copyright licenses have nothing to do with who may put words in your mouth. That's covered by the laws against slander, libel, defamation, fraud, and the laws protecting trade and service marks. You could put your essays under the MIT/X11 license, and it would still not be lawful for me to claim you said other than what you did. The only protection you gain by keeping tight copyright control over your works, allowing only unmodified distribution, is confidence that nobody can use your arguments or rhetorical techniques to strengthen their own arguments. -Brian
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Steve Langasek [EMAIL PROTECTED] writes: On Wed, Jul 30, 2003 at 09:09:10AM -0700, Thomas Bushnell, BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. I believe this is not correct. In what regard? I believe that the circumvention in question, under the DMCA, is specifically only circumvention which is a copy protection mechanism. The CSS is not a copy protection mechanism, in any sense of the term. It is rather a mechanism designed to enforce region coding. It is not correct that CSS was developed by hardware player manufacturers in order to maintain their profits. All the players can always play an unencrypted DVD. It is the studios that choose to encrypt, and they do so to enforce region coding, and staged geographic releases and differential pricing. The distinction was between playing and copying of movies by means of decrypting CSS. You assert that viewing is a form of access (which indeed it is), but this misses the point that the DMCA covers only a copy-protection scheme, not an access protection scheme. DMCA 1201(a)(1)(A): No person shall circumvent a technological measure that effectively controls access to a work protected under this title. The prohibition contained in the preceding sentence shall take effect at the end of the 2-year period beginning on the date of the enactment of this chapter. DMCA 1201(a)(3)(A): As used in this subsection, to ''circumvent a technological measure'' means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner; and You've apparently only read 1201(b), which covers circumvention of mechanisms protecting other Title 17 rights. -Brian I do agree with your broader point that if we can ship libdvdcss, we can ship applications that use it. I also agree that, if it's feasible, a lawyer's advice would be useful here. Thomas -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: DMCA 1201(a)(1)(A): No person shall circumvent a technological measure that effectively controls access to a work protected under this title. The prohibition contained in the preceding sentence shall take effect at the end of the 2-year period beginning on the date of the enactment of this chapter. I'm thinking of the law in toto, including the provisions in the DMCA nothing in the DMCA is intended to contravene existing fair use. This is a pretty big stick to get to wave back at the MPAA and others of their ilk. Since existing fair use guarantees the right to watch my copy, provided it's legal, the provisions you quote must not apply to them. Why? Because the DMCA says, essentially, nothing here contradicts existing fair use principles. Your interpretation would make the access-circumvention provision almost useless: it would mean it only mattered when preventing access to illegally copied works. Which, hey, is a reasonable law. Neat. On the other hand, the text actually says that nothing in the DMCA affects fair use as a copyright-infringement defense. Distribution of an circumvention device isn't copyright infringement, so that doesn't help. The interoperability bits in 1201(f) seem fine to cover libdvdcss / libdvdread distribution, though. -Brian
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: Your interpretation would make the access-circumvention provision almost useless: it would mean it only mattered when preventing access to illegally copied works. Which, hey, is a reasonable law. Neat. No, it would also mean that you can't make an access-circumvention for a *copy protection* scheme. The point is that CSS isn't a copyprotection scheme, not at all. You keep snipping the relevant text: do you think your argument can't stand up next to evidence? Let my try this again: CSS is an access control mechanism. The fair use doctrine is a defense to copyright infringement. The DMCA makes circumvention of access control mechanisms illegal. That law also says nothing in the DMCA contravenes the fair use doctrine. The ban on use of circumvention devices for copy-prevention schemes is probably toothless, given the fair use doctrine. However, the following activities banned by the DMCA are not copyright infringement, and so fair use is not a defense for them: * Trafficking in access-control circumvention devices. * Accessing a protected work. Fair use would normally allow you to do either of these things. Neither of them is copyright infringement, though, so the DMCA effectively bans them. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Inconsistencies in our approach
John Goerzen [EMAIL PROTECTED] writes: Problem #2: Double Standards We have, and continue to, allow information to be distributed with software under even more strict terms than the FDL. Examples of these things include licenses. All of the arguments being made about freeness of documentation -- that somebody may want to develop a document based on the original -- would also apply to licenses (perhaps I wish to develop a license based on the GPL). Yet we are ignoring the problem with the licenses. I wish to address a very narrow part of this point: because copyright protects only creative expression of ideas, and because legal terminology is intended to be strictly denotative and carefully defined, contracts and similar legal texts (including licenses) receive very weak copyright protection; often none. The BSD license, for example, or the usual warranty disclaimer, are boilerplate: there's no other way to express exactly the same idea, so the expression receives no copyright protection. As a result, I suggest you abandon this point of your argument. Problem #3: Separability of Problems Concern has rightly been expressed about the ability to modify software documentation, especially since Free Software is out there to be modified. Concern has also been expressed about the ability to modify RFCs. While I share that concern, and agree in principle that they should be modifyable providing the modified version does not claim to be an RFC, we need to bear in mind that RFCs serve a quite different purpose than software documentation. RFCs are here to provide specifications, and their usefulness is directly derived from the fact that everyone can point to a single unified source for a spec. Aw, heck. While I'm here, I'll dice the rest too. While you're correct about a major use of RFCs, it's hardly the only one. My principal use of the RFCs, for example, has been extracting text for use in new documents. The new RFCs don't allow me to do that, and are clearly non-free. I, therefore, see the attempt to banish RFCs -- which are not software You really wouldn't want us to insist on shipping the non-software versions. Apt-get really bogs down when asked to process 20 lb A4. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: License evaluation sought
Tore Anderson [EMAIL PROTECTED] writes: Hi, I would like to have the list members' opinion on the following license, which is about to be applied to the data files of an old adventure game: It's non-free. There's no permission to create a derivative work, or to distribute such a derivative. -Brian Preamble: Basically, give this game away, share it with your friends. Don't remove this Readme, or pretend you wrote it. You can include it in a software collection, like a linux distribution or coverdisk (which may be sold), but using it in things like commercial adventure game collections without asking is just playing dirty. This preamble is not legally binding, but is to clarify the intent of the following license. License: 1) You may distribute this game for free on any medium, provided this readme and all associated copyright notices and disclaimers are left intact. 2) You may charge a reasonable copying fee for this archive, and may distribute it in aggregate as part of a larger possibly commercial software distribution (such as a Linux distribution or magazine coverdisk). You must provide proper attribution and ensure this readme and all associated copyright notices, and disclaimers are left intact. 3) You may not charge a fee for the game itself. This includes reselling the game as an individual item. 4) All game content is (C) Revolution Software Ltd. The ScummVM engine is (C) The ScummVM Team (www.scummvm.org) 5) THE GAMEDATA IN THIS ARCHIVE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING AND NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. ~~~ At first I had my doubts about paragraph 3, but after having read the Artistic license, whose paragraph 5 involves the same restriction while still being DFSG-free, I would assume this is acceptable for inclusion in main. But do comment, legalese is not one of my strong points. This software will be publically released soon, so swift replies would be much appreciated -- I might be able to talk upstream into adjusting the license before releasing, if it is necessary to satisfy the DFSG. Thanks in advance, -- Tore Anderson -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Should our documentation be free? (Was Re: Inconsistencies in
Joe Moore [EMAIL PROTECTED] writes: Joe Wreschnig said: If someone adds proprietary code to BSD-licensed code, however, you can later extract the free code (assuming you have access to the code of the now-proprietary program), and use it in something else. Once proprietary (invariant) sections are added to something under the GFDL, that version of the document is forever non-free, because they can't ever be removed. A nice example of a viral license. If proprietary (invariant) sections are added to something under the GFDL, you can still fork the (free) version from before those are added. Similar things have happened with software. But you have to go and find a copy from before the proprietary section was added. With a normal combined work, you can just remove the proprietary code and take the clearly marked (heh) BSD code. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: APSL 2.0
Matthew Palmer [EMAIL PROTECTED] writes: I don't think that such a licence term is particularly egregious. Look at the GPL requirement - if you get the binary, you can get the source. Now, who gets binaries? Users. So, users get the source to the programs they're using. Now move to a webapp. Who uses/views the webapp? Users. So, under the APSL 2.0, users get the source to the programs they're using. Handwaving it may be, but I think the intent is similar. If your premises were true, I'd agree with your conclusion. But I've never believed that renting someone an account on my system requires me to provide source to all the GNU tools installed there. This is a radical change. It affects not only the web, but encumbers every other service, currently existing or not yet imagined, running over a network. For example, if this clause were in the GPL, it would require me to provide full source to the Linux kernel, Emacs, gawk, Perl, etc. Yuck! What a burden on providing access to a computer. In addition, would this require source to mailing list software be distributed to subscribers? How about spammers; they're using it, right? If I set up a weather-monitoring device with an embedded Linux kernel, and it publishes temperature and air pressure data over SNMP, do I have to provide the source to those? If I send a message like this one, which quotes yours, do I need to send you the source for Emacs and Gnus? How about my MTA? If there are routers in between which use APSL code, are you entitled to the source for them too? The FSF chant is the users get the source. The GPL was written in a time when the web didn't exist, and it was impossible to foresee this way of distributing applications. I think this clause of the APSL 2.0 merely brings GPL concepts into the modern era. I think this era isn't very different from that of 15 years ago. RMS, and the FSF, are spooked by the success of web service providers. They didn't seem very upset by modems, remote terminals, and timesharing systems, though. I think they're just experiencing culture shock, and are overreacting to something which really isn't an important change. Worse, they're adding a sufficient encumbrance to networking computer systems to lock code available only under an APSL/Affero style license out of networked environments. If they succeed in promulgating these ideas, they'll hinder growth of networked systems. Perhaps a good way of summing up the problem is this: They're discriminating against a field of endeavor. Now, it's Free to discriminate against a business model, such as A monopoly on software in boxes on shelves. It's not Free to discriminate against a use model, such as running nuclear power plants. This is discrimination against both a business model (web services providers) and a use model (providing access to computers over a network). -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: {debian-legal} Re: APSL 2.0
M. Drew Streib [EMAIL PROTECTED] writes: On Thu, Aug 07, 2003 at 11:10:34AM -0400, Brian T. Sniffen wrote: out of networked environments. If they succeed in promulgating these ideas, they'll hinder growth of networked systems. Perhaps a good way I could agree with you, except that networked systems can't really be hindered too much now. They are pretty much a given. In that case, won't it hinder the use of APSL/Affero GPL licensed software in networked environments? Apple isn't so much discriminating against a use model, as discriminating against _all_ use, in either a networked or distribution model, without distributing source. Think of it as discriminating against the business model of 'service', rather than the use of networked software. They're simply cutting off the common GPL bypass these days, which basically lets ASPs, web services, etc basically use GPL'd software with no source releases (since no binaries are ever 'distributed' as such). Since most of the net seems to be moving towards service models and away from distribution models, this is merely a licence trying to catch up. So why hinder a typesetter who returns his work as PDF more than a typesetter who returns printed pages? Why favor an HTML file distributed on a floppy over one distributed via HTTP? This insistence that interacting with software over a network of electrons is somehow different from interacting with software via DHL is ridiculous. It's not a license catching up, or closing loopholes without impacting freedom: it's that license authors saw something which bothered them, and are prohibiting it in their licenses. They're allowed to do that, certainly, but that doesn't make it Free. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: APSL 2.0
Jeremy Hankins [EMAIL PROTECTED] writes: How about a web server, instead? Do you think that using a web server to make your content available to others qualifies as providing a service? Do you think Apple thinks so? In the list you referenced, the service goes electronic when Joe receives the document via email, munges it, and sends it back. So a hypothetical Amazon 1990, which receives a request over e-mail and responds by sending a package via physical mail, is not an electronic service? Neither is Gutenberg-USPS, which will e-mail me a document in response to a physical request, no SASE required? Even there, I think it's hard to claim that Joe is using the Covered Code, alone or as part of a Larger Work, in any way to provide a service. This confuses me. How can you not say, when Joe's using the covered code to perform typesetting for others, that he's not using it in any way to provide a service? Also true, but I think it's more about the fundamental problem that this is a non-free restriction than about abuse by licensors. I'm not convinced we can clearly get non-free out of the DFSG on this one. I don't buy the discrimination against fields of endeavor, and unlike the affero GPL this isn't a restriction on modification. It's a restriction, yes. And not one I particularly like, if the truth be known. But the analogy between this restriction and the source-redistribution restriction of the GPL is simply too strong for me to ignore it. If you assume that the definition of Externally Deploy (or more specifically, provide a service) is going to be reasonable I have trouble seeing where you can say it's not DFSG free. Copyright law does not grant any control over a third party's use, but only on modification and distribution. The GNU GPL's source-redistribution requirement only kicks in when attempting to do something normally forbidden by copyright law. That is, it lifts the barrier of copyright law, but only part way. This license, the APSL, imposes a barrier on things copyright law doesn't cover. What happens if I choose to refuse the license -- can I ignore the APSL then? For example, let's say I hire Modifiers, Inc. to take an APSL2-covered work and modify it. They comply with the APSL, and post it on their web site. They also hand me a hard drive with the software on it. I use that drive in a computer which provides a web service. I decline to accept Apple's license to modify or distribute their code. All I'm doing is using it, so they can't touch me. The above paragraph mostly says that the APSL is a bad idea and may be unenforceable; if you don't buy that, at least consider the original argument: that a restriction in addition to those imposed by copyright law is necessarily non-free. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Inconsistencies in our approach
John Goerzen [EMAIL PROTECTED] writes: On Fri, Aug 01, 2003 at 01:29:12PM -0400, Brian T. Sniffen wrote: I wish to address a very narrow part of this point: because copyright protects only creative expression of ideas, and because legal terminology is intended to be strictly denotative and carefully defined, contracts and similar legal texts (including licenses) receive very weak copyright protection; often none. But the GPL itself starts with: | GNU GENERAL PUBLIC LICENSE | Version 2, June 1991 | | Copyright (C) 1989, 1991 Free Software Foundation, Inc. | 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | Everyone is permitted to copy and distribute verbatim copies | of this license document, but changing it is not allowed. And while you may debate the enforcability of this in the US, it may be enforcable elsewhere, and our preference has always been to assume licenses are enforcable as written. Indeed. And elsewhere, the FSF grants a license to create derivative works of the GPL: http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL. It's also been Debian's preference to read all the applicable licenses. Particularly because it's a license, it's important to distinguish between changing an instance of it and creating a new license derivative of the GPL. Now, given that a huge portion of our software ships with this, and it is incorporated in our .debs by reference (and by mandate in the GPL itself), considering the text of the GPL to be non-free would force the removal of most of main directly or because of dependencies. Not quite. I *do* think Debian should remove the GPL's Invariant-but-removable Preamble, distributing only the legal text. The FSF says http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble, but since the requirement for future distribution is only under the terms of the GPL, Debian could distribute the Debian GPL containing only the legal terms, and without the invariant Preamble. If you then grant the GPL an exception, why do you not do that for RFCs? Why do you not do that for the Emacs manual? What is special about the GPL? This is what bothers me the most. We must not play favorites or say Well, this non-free file goes in main because it's too important to have in non-free. Either it is free or not, and popularity has nothing to do with that. Are you constructing straw men? I have seen nobody argue that the GPL is popular, and so should be retained. Indeed, I've seen proponents of non-modifiable-RFCs-in-main arguing that they're so popular that it would un-Social to remove them. Can you cite such a message? To put it more concretely: I have not seen any arguments that argue against the removal of RFCs on the grounds that they are non-free software that do not also argue against the removal of the GPL. Can someone devise one? Well, there's the easy approach, pointing to http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL. Look, the terms of the GPL are free. But if you'd like a more complicated answer, sure: we are distributing creative works. Many of them are copyrighted. The law says we must preserve those copyright notices. So you can't change the line in YEmacs which says Copyright 2003 S. Author. We wish to distribute Free software: we wish to give software to people, and to give them also legal permission to modify and distribute it. This means that we must give them a copyright license. We have this Free Software. We'd like to distribute it in a Free way... so we give the recipients the license to tell them how they can modify and distribute the software. It's not part of any program, just infrastructure put alongside the programs: not distributed for any useful purpose for anybody except for informing users of their legal rights. I'd like to point out also that if your goal is to preserve RFCs in Debian, you would probably do better to argue I cannot see any argument for preserving the GPL in Debian which does not also argue for preserving RFCs in Debian. boilerplate: there's no other way to express exactly the same idea, so the expression receives no copyright protection. As a result, I suggest you abandon this point of your argument. But you need only look at the first few lines of the GPL to see what I'm talking about; the FSF actually asserts copyright over it. It does. The copyright on the Preamble, and on the combination of the Preamble and the license text, is strong. The copyright on the license text itself is probably not defensible. It doesn't matter too much, given the license to create new documents derivative of the GPL. -Brian
Re: Inconsistencies in our approach
Sergey V. Spiridonov said: Branden Robinson wrote: After all, what utility would this distinction serve beyond providing one a means of routing around the DFSG's inconvenient restrictions? Program (code) is not of great value outside computer, except examples which usually belong to the documentation. This is not true: source code is intended for human consumption at least as much as for machines. I will not buy a book with printed source code of Linux kernel, even if it will be very cheap :) But you would buy a book like Linux Undercover, with printed man pages? Would you not buy a book with the source of PGP 2.6? Tens of thousands of people did so... Documentation and some other kinds of data can be used without computer. Documentation can be printed and sold as books. One does not need a computer to read a printed documentation. One does not need a computer to read printed source code either -- I do my best debugging that way, on a desk scattered with papers. And one does need a computer to read most PDF or MS Word files, no matter whether they are printed or not: lpr foo.pdf is not a pretty sight. There are kinds of files (documentation, images, sounds) which can be used outside the cramped computer scope. Indeed, I believe you are referring to the class Creative works, which includes computer programs. Go look at the DeCSS Gallery if you'd like a slightly stranger, but more artful argument on the same topic. There is a whole various world outside the computer! -- Best regards, Sergey Spiridonov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible approach in 'solving' the FDL problem
Said Wouter: I'm not saying we have to do that. I'm only saying we have to decide whether or not the rules for declaring documentation to be free should be the same as the rules for declaring computer programs to be free, and if not, what the rules for declaring documentation to be free have to be. OK. Where's your candidate DFDocumentationG? Nobody here will take you seriously until you have one. In fact, if the debian-legal group were to decide all by itself that software and documentation are essentially the same thing, I'm afraid a fork would be much more likely. It is not the same thing. The question is whether the definition of freedom should be the same for both. That's exactly the point I'm trying to get through. I feel that a lot of developers think it is not. As such, I'm suggesting we ask our developers, and work from there on. IANADD, but while there is clearly documentation which is not software, all documentation distributed by Debian -- possibly excepting CD cases -- is software. -Brian -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible approach in 'solving' the FDL problem
Wouter Verhelst [EMAIL PROTECTED] writes: On Thu, Aug 07, 2003 at 09:22:25PM -0400, Brian T. Sniffen wrote: Said Wouter: In fact, if the debian-legal group were to decide all by itself that software and documentation are essentially the same thing, I'm afraid a fork would be much more likely. It is not the same thing. The question is whether the definition of freedom should be the same for both. That's exactly the point I'm trying to get through. I feel that a lot of developers think it is not. As such, I'm suggesting we ask our developers, and work from there on. IANADD, but while there is clearly documentation which is not software, all documentation distributed by Debian -- possibly excepting CD cases -- is software. In the broader definition of software. Not everyone sees that definition as correct, including many people who accepted the DFSG with a definition of software that only includes 'computer programs', not this broad definition, in mind. OK. See, I thought you were arguing for keeping documentation in main under looser criteria than executable programs. If you're arguing that some of what Debian is distributing *isn't software at all*... gosh, what is it? I'd thought Debian distributed Free Software. But now you're telling me it distributes Software, Documentation... anything else in there? And incidentally, what does all of this do the LaTeX issue -- TeX is written using Literate Programming, remember, so the code and documentation are tightly interwoven. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Inconsistencies in our approach
John Goerzen [EMAIL PROTECTED] writes: On Sun, Aug 03, 2003 at 05:12:55PM -0400, Nathanael Nerode wrote: John Goerzen wrote: 1. Would removing the manual for Emacs, libc, or other important GNU software benefit our users? Yep. I'm very unhappy with having non-free software (and software means 0s and 1s -- so nearly everything Debian distributes except the physical CDs) in Debian; as a user, I chose Debian at least partly for the Social Contract, which this violates. That's an overly-expansive view of software. You would include anything that is digital in that description -- audio CDs, DVD movies, off-air TV signals, books on disk, etc. I find it very hard to quantify Beethoven's Ninth Symphony as software, even if it was recorded digitally, given that the invention of software postdated its composition by a LONG time -- and that the invention of software postdated early recordings by a long time as well. Nobody is claiming Beethoven's Ninth Symphony, or the King James Bible, to be software. Quite a few of us are claiming that this MP3 over here, beethovens_ninth.mp3, is software. So is this file bible.txt. I see it as fallacious reasoning to conclude that anything that is binary is software. If I use some sort of binary Morse code to send a message manually, why is it more of software than if I use the real Morse code? Oh, come on. He was clearly referring to the argument that computers are hardware which contain software. If you have the message, in ASCII, binary morse, morse, or Urdu, on a computer, it's either software or blocking the vents. I agree that this is good. But how does it promote Free Software to strip manuals from Free programs? Nobody's suggested stripping manuals: merely replacing them with Free versions, such as replacing the Emacs 21 manual with an edited Emacs 19 manual. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: APSL 2.0
Jeremy Hankins [EMAIL PROTECTED] writes: Even there, I think it's hard to claim that Joe is using the Covered Code, alone or as part of a Larger Work, in any way to provide a service. This confuses me. How can you not say, when Joe's using the covered code to perform typesetting for others, that he's not using it in any way to provide a service? As I see it, yes, there is a difference. In one case it's automatic, and the typesetting code is itself providing a service -- i.e., it's directly being used by the customer. In the other Joe is interacting with the typesetting code, not the customer, so Joe is providing the service. That's an interesting idea, but it is not what is written there: the APSL talks about using the software in any way to provide a service. So when considering the question Is Joe using the software in any way to provide a service?, is No an answer you find reasonable? Can you truly state Joe is not using the software in any way to provide a service? It's a restriction, yes. And not one I particularly like, if the truth be known. But the analogy between this restriction and the source-redistribution restriction of the GPL is simply too strong for me to ignore it. If you assume that the definition of Externally Deploy (or more specifically, provide a service) is going to be reasonable I have trouble seeing where you can say it's not DFSG free. Copyright law does not grant any control over a third party's use, but only on modification and distribution. The GNU GPL's source-redistribution requirement only kicks in when attempting to do something normally forbidden by copyright law. That is, it lifts the barrier of copyright law, but only part way. The APSL refers several times to performance, which suggests that they intend a public-performance argument to use that to back up this requirement. That's an interesting idea. It's not obvious to me how to interpret it; I'll have to think about it some more. The above paragraph mostly says that the APSL is a bad idea and may be unenforceable; if you don't buy that, at least consider the original argument: that a restriction in addition to those imposed by copyright law is necessarily non-free. Why? It's a convenient test, seems intuitively reasonable, and puts the GNU GPL2, BSD, Artistic, etc. licenses on one side, and all those which distribute against fields of endeavor on the other. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible approach in solving the FDL problem
[EMAIL PROTECTED] (Kai Henningsen) writes: [EMAIL PROTECTED] (Nathanael Nerode) wrote on 07.08.03 in [EMAIL PROTECTED]: Wouter Verhelst [EMAIL PROTECTED] wrote: Additionally, the FSF is not alone by claiming software isn't the same thing as documentation; international agreements and most countries worldwide make a distincion between how software and other copyrighted stuff is protected by law. You're muddling things. Software != computer programs. It is not? I certainly can't come up with an example that is one and not the other. The wiring of an ENIAC is a computer program, but not software. A DRM-encumbered video file is software, but not a computer program. If you believe that some pieces of that-which-is-on-a-computer-but-not-hardware are not software, you should present arguments and bright lines for distinguishing them. -Brian
Re: A possible approach in 'solving' the FDL problem
Wouter Verhelst [EMAIL PROTECTED] writes: Op di 12-08-2003, om 09:18 schreef Wouter Verhelst: It is not the case that Debian used to contain nothing but computer programs, but sometime after adopting the Social Contract, we let other materials into our Distribution. Of course; however, Darn, I did it again :-/ however, it could be said that in those days, there was no problem handling it this way, since documentation and 'software' (computer programs, if you prefer) were usually distributed under the same license. But if there'd been any reason to think that programs and documentation should meet different criteria of freeness, surely there would have been a debate over whether the BSD, GPL, and Artistic licenses were free for Documentation. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible approach in solving the FDL problem
within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled Acknowledgements, Dedications, or History, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License or any later version applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the with...Texts. line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible approach in solving the FDL problem
Jimmy Kaplowitz [EMAIL PROTECTED] writes: On Fri, Aug 15, 2003 at 12:25:26PM -0500, Branden Robinson wrote: On Fri, Aug 15, 2003 at 01:09:09PM +0200, Sergey Spiridonov wrote: Wouter Verhelst wrote: Can you buy a closed proprietary code and than realease it under GPL? Yes. It probably depends on the amount of money you spend, and on what exactly you buy, but it's very possible to do so... Thank you Wouter. That doesn't buy freedom, it buys a work. It can buy freedom, depending on what exactly you buy, as Wouter said. Imagine that you buy the right to relicense the work under a license of your choosing. That would probably [depend] on the amount of money you spend, [...] but it's very possible to do so, as Wouter said. Of course, the purchaser would also need to want to use the GPL for the new license That buys you a capability, not a freedom. For example, I have freedom with respect to this computer, which had a blank drive when I acquired it. I've since put all sorts of software on it without giving up any freedoms -- it's running Debian with no non-free software. I could pay money to Microsoft and gain the capability to install Windows; I already have the freedom to install Windows (by paying some money). I could put some non-free software distributed by Debian on here, giving me the capability to run that software... but I've already got the freedom to run that software. So no, buying closed proprietary code and releasing it under the GPL (e.g., Blender) does not give me any freedoms I didn't have before. It merely gives me technical capabilities I hadn't had before. You can't give me freedom. I've got it innately, unless I relinquish it or it is taken from me by force. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible approach in solving the FDL problem
Jimmy Kaplowitz [EMAIL PROTECTED] writes: On Sat, Aug 16, 2003 at 01:02:44AM -0500, Branden Robinson wrote: On Fri, Aug 15, 2003 at 01:30:48PM -0400, Jimmy Kaplowitz wrote: It can buy freedom, depending on what exactly you buy, as Wouter said. If you have bought it, what you have isn't freedom. I was talking about buying rights to a non-free software package and making it free for you and everyone else ... you have paid money to make there be a free software package where before there was only a non-free one ... that is buying freedom (for yourself, which you then share with others via a DFSG-free license), in a very real sense that pertains very much to copyright law. Blender is more free now than it was before the community paid $100K. But Blender has no freedom -- it's just a bunch of bits. And the community is no more free for having bought Blender than it was before -- certainly, I am no more free now than I was before other people paid money for Blender. -Brian
Re: Advice on DFSG status of this licence
Andrew Pollock [EMAIL PROTECTED] writes: Hi, I'm considering packaging up RIPE's whois server, and the closest thing I can find to a licence in the source tarball is the contents of the COPYING file, at the end of this message. The only bit I'm unsure of is the last sentence. Does it mean we can't refer to it as the RIPE whois server? This looks like a rewritten MIT/X11 license. Unfortunately, there's no grant of permission to distribute modified versions -- usually not necessary, but some copyright holders have decided to be silly and read permission to modify and distribute as different from permission to distribute modifications, most noticeably UW. The last sentence just means that Install Debian GNU/Hurd, with the RIPE Whois Server! shouldn't show up on our posters. It's verging on non-free, violating DFSG 9, but this minor effect has been tolerated for authors paranoid of exploitation before. -Brian Copyright (c) 1999RIPE NCC All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS; IN NO EVENT SHALL AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Re: SURVEY: Is the GNU FDL a DFSG-free license?
Branden Robinson [EMAIL PROTECTED] writes: Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. === CUT HERE ===
Re: Is the GNU FDL a DFSG-free license?
Joerg Wendland [EMAIL PROTECTED] writes: Matthew Garrett, on 2003-08-21, 16:13, you wrote: Oh, now, come on. The GFDL plainly /isn't/ compatible with the DFSG. Whether or not it /has/ to be compatible with the DFSG in order to be in Debian is an entirely separate issue, but the above is obviously not true. I was asked for my opinion, here it is. I feel the GFDL is free enough for my heart does not beat for the bureaucratic following of iron rules but for the sake of our users. And our users are not just the readers of GFDL-licensed documentation but also their authors, and they deserve freedom, too. This is why I made this very selection and this discussion Wouldn't it be better, then, to say that you don't think the GFDL meets the DFSG, but that you think it shouldn't have to? Certainly, you don't appear to believe that the GFDL both should have to meet the DFSG and does so. ends here. So it does. I greatly enjoy the freedom to derive a work from that which you sent. Just think -- if you'd licenses your message under the GFDL, not only would I have had to include a History section in this reply, but it would have been illegal for you to read it, thanks to the opportunistic encryption of SMTP/TLS! -Brian
Re: A possible GFDL compromise
That's an interesting compromise you propose, and it would solve the problems which affect only some GFDL documents. but I don't think it addresses the problems which affect all GFDL documents: the requirements for transparent formats, and the anti-DMCA clause (the ban on technical access control measures). It also doesn't well-address the problems with the difficulty of properly applying the license: what happens when someone says a non-secondary section is invariant, for example? A few weeks ago, on a Friday, you said that you'd take the weekend to think about it and try to propose a set of Debian Free Documentation Guidelines on Monday. I'd be interested to see the output of that thought process: since I haven't seed a Goerzen FDG, I'd like to know why you didn't come up with one, and what complexities made it hard -- or did you just come up with a rephrasing of the DFSG? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Is the GNU FDL a DFSG-free license?
Keith Dunwoody [EMAIL PROTECTED] writes: Brian T. Sniffen wrote: Joerg Wendland [EMAIL PROTECTED] writes: Matthew Garrett, on 2003-08-21, 16:13, you wrote: Oh, now, come on. The GFDL plainly /isn't/ compatible with the DFSG. Whether or not it /has/ to be compatible with the DFSG in order to be in Debian is an entirely separate issue, but the above is obviously not true. I was asked for my opinion, here it is. I feel the GFDL is free enough for my heart does not beat for the bureaucratic following of iron rules but for the sake of our users. And our users are not just the readers of GFDL-licensed documentation but also their authors, and they deserve freedom, too. This is why I made this very selection and this discussion Wouldn't it be better, then, to say that you don't think the GFDL meets the DFSG, but that you think it shouldn't have to? Certainly, you don't appear to believe that the GFDL both should have to meet the DFSG and does so. So why was option 2 included on the survey anyway, if all you're going to do is tell people who voted for option 2 that they're wrong? Neither Matthew nor I are in any way involved with running the survey. I'm not even a Debian Developer. Option 2 is, however, internally inconsistent. I've only seen one person -- Joerg Wendland -- select it so far, and after marking as his vote, The GFDL is DFSG-compliant, he has further explained that he didn't *actually* think the GFDL met the terms of the DFSG, but that he thought that: * The GFDL shouldn't have to meet the terms of the DFSG. * Authors should be able to license things as they please. * The GFDL is a good licence. * What? The moral quality of a license is not reflected in its DFSG status? I will hear no slur upon the beard of RMS, for my heart beats with revolutionary fervor for the sake of our users. Debian should distribute all good things. RFP: Bunnies[1]. In other words, he lied. It may not have been an intentional deception -- it's possible he just can't understand the difference between The GFDL is DFSG-free and I don't think the DFSG should apply to the GFDL. From his other posts, he appears to be a postmodernist, so this is quite possible: the claim that all opinions are equally valid, sacrosanct, and incontrovertible is not compatible with constructive rational debate[2]. -Brian [1] Bunnies are a registered trademark of the Microsoft Corporation, and are dual licensed under the MS Soul-Sucking EULA and the GFDL. [2] Neither are comments about the beard of RMS or speculations as to the ungulate heritage of postmodernists, I know. Sorry. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Is the GNU FDL a DFSG-free license?
Joerg Wendland [EMAIL PROTECTED] writes: Matthew Garrett, on 2003-08-22, 13:09, you wrote: As previously pointed out, the same is true of software. I could insert anti-semetic messages into pam-pgsql and NMU it now. Perhaps you should change your license? No, you didn't get it. What I wrote before was example for why invariant. sections _can_ be useful. Indeed, invariant sections can be useful. I have written several works which I do not give *any* permission to alter, and others which I do not even give permission to distribute. Neither set contains free software. If Emacs had an invarient section discussing fishing and how this had inspired the authoring of the manual, it would be awkward for me to use chunks in my document on an application for recording fishing statistics. And if you say But why would you want to do that then I'll scream because that's entirely not the point. But this _is_ the point. You cannot blame the author of the manual if it will be awkward for _you_ because this is entirely your problem. I do not blame the author, I merely categorize his output. If he gives me essentially all the rights he has, that output is free. If he requires me to eat three prawns and sing Oh Susanna for each copy I make, it is not free. If he requires me to only use his work in certain ways, but not for operating nuclear power plants, building encylopedias, storing on encrypted flash memory drives, building competing source control systems, publishing substantive reviews or criticisms of his work, or contradicting or omitting his political opinions... then it is also not free. This does not mean it is bad or worthless, or that the author is evil. Someone who writes a work and licenses it under the GFDL does a constructive and morally good thing. It is not as constructive or as good as if he put it under the GPL or the MIT/X11 license, but it is not evil. However, that work is not free, and Debian should not incorporate it. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
David B Harris [EMAIL PROTECTED] writes: Less likely, though I certainly wouldn't say it's impossible, is a judge ruling that without providing electricity, a working computer with a CD reader, and a technician to operate it and read the words aloud, distributing the documentation on a standard ISO9660 CD is in violation of the license. (Yes, the above is a deliberately silly example. It's obsurd. If a judge did maintain that position, we would all think the judge is nuts. But there are judges that are nuts when it comes to technology - a LOT of them. The example is meant to show a flaw in the GFDL.) Actually, isn't there a complicated set of trademark and patent claims preventing manufacture of a CD reader without paying money to Phillips and some trade organizations? This may not be that ridiculous. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
David B Harris [EMAIL PROTECTED] writes: On Fri, 22 Aug 2003 16:25:27 -0400 [EMAIL PROTECTED] (Brian T. Sniffen) wrote: David B Harris [EMAIL PROTECTED] writes: Less likely, though I certainly wouldn't say it's impossible, is a judge ruling that without providing electricity, a working computer with a CD reader, and a technician to operate it and read the words aloud, distributing the documentation on a standard ISO9660 CD is in violation of the license. (Yes, the above is a deliberately silly example. It's obsurd. If a judge did maintain that position, we would all think the judge is nuts. But there are judges that are nuts when it comes to technology - a LOT of them. The example is meant to show a flaw in the GFDL.) Actually, isn't there a complicated set of trademark and patent claims preventing manufacture of a CD reader without paying money to Phillips and some trade organizations? This may not be that ridiculous. (s/obsurd/absurd/, BTW :) You mean if Phillips is the distributor? That's certainly what the clause in the GFDL is supposed to prevent (people making proprietary formats, charging for access to them or their decoders, then releasing GFDL'd documentation under that format), so perhaps. I don't know the details about the CD market though :) No. There's a consortium of companies, led by Phillips, which hold the trademarks on CDDA, CD-ROM, CD-R, Compact Disc, and a pool of patents applicable to making compact discs and the devices to manipulate them. I can't just burn a disc and sell it with the CDDA logo on the side, nor can I make a machine which plays CDs and sell it as a CD player. Or rather, if I do, Phillips and the CD Consortium will sue me. -Brian
Re: A possible GFDL compromise
Jacobo Tarrio [EMAIL PROTECTED] writes: Third: if we were to enumerate each and every right in the license, it would be much longer and more complex (and imagine if we started combining the rights you must not limit the recipient's ability to make and distribute new copies of excerpted versions of this document). Thus, a single, simple clause I proposed: if the format or physical medium this work is distributed in limits the recipient's ability to exercise the rights given by this license, access to a copy of this work in a format or physical medium that allows for the exercise of the rights must be provided. That would mean -- if you want to modify it and cannot because you don't use Word, you have the right to obtain from your distributor a plain text copy. So if I distribute any text document in hard copy, I should be prepared to provide a Braille edition, as well as translations into a variety of obscure languages? I don't think that's Free either. I like the idea of what you're trying to do, but I think any phrasing of this requirement is either going to leave loopholes or cover too much: it will either be exploitable or non-free. This is a social problem, and best solved with social means, not with precise technical phrasing. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Is the Sun RPC License DFSG-free?
Branden Robinson [EMAIL PROTECTED] writes: On Fri, Aug 22, 2003 at 02:05:57PM -0400, Brian T. Sniffen wrote: Sun has repeatedly clarified elsewhere that the intent of this is essentially MIT/X11, except you may not distribute this product alone. Got any citations? The license certainly doesn't *read* like MIT/X11, except you may not distribute this product alone. Sadly, I have no citation. It came up in the context of proprietary software developed with Sun RPC code, and I no longer have access to the e-mail thread. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Alright, if none of the GNU Free Warez License folks are going to come up with freedoms for documentation, I'm going to. This is heavily derived from the FSF's Four Freedoms, before they went fundamentalist and proprietary: Free text is a matter of the reader's freedom to read, copy, distribute, study, change, and improve the text. More precisely, it refers to five kinds of freedom, for the readers of the text: * The freedom to read the text, for any purpose. (0) * The freedom to study how the text is written, and adapt it to your needs. Access to the text in the preferred form for modification is a precondition for this. (1) * The freedom to redistribute copies so you can help your neighbor. (2) * The freedom to improve the text, and release your improvements to the public, so that the whole community benefits. Access to the preferred form for modification is a precondition for this. (3) * The freedom to keep your modifications, or even your possession of a copy of the text, confidential. (4) The GFDL fails point 0, due to the any copies you make bit about technical restrictions: I cannot legally download a GFDL text onto a machine covered by HIPAA, for example, which requires technical restrictions on information distribution. The GFDL fails point 1 when Invariant Sections are used. I wish to use a paragraph from the GNU Manifesto in my own arguments about the liberation of antarctic waterfowl, but I am prevented by its license. I wish to use a paragraph from the GNU GPL2 Preamble in a screed I'm publishing on the nature of primitive bovine implements, but I am prevented by its license. I wish to make an Emacs reference card, but... The GFDL appears to meet point 2, but fails point 4 -- again due to the provision regarding technical restrictions on copies you make. It also fails point 3, as I can't close any of the holes in logic in Why Free Software needs Free Documentation and release them. So given all of that, let's take the rest of your message in hand: It is in the best interest of users to receive unstripped version of manual. It is also in the best interest of users to recieve a manual they can use, modify, and distribute, like they want, provided they prevent no one else from doing so. They can use, improve and distribute it by all useful means. Removing of secondary section from manual can't be count nor as improvement, nor as adaptation of manual. Of course it is. There's no reason for the GNU Manifesto to be published with a manual on BSD's awk, or for cover texts saying A GNU Manual to be there. Removing that misleading text would be an improvement. It is also in the best interest of authors. Except the GFDL takes freedom away from authors. What it *adds* is not freedom, but control - the original author of the document is exercising control over all subsequent authors and users. Removing a section from document does not create autiorship for derivative work, btw. Because, the copyright in a compilation or derivative work extends only to the material _contributed_ by the author of such work (USC T17 S103). If you not contribute anything, you is not an author, regardless of how much you removed. You're confused about copyright law. For example, if I publish an anthology composed of the first chapter of each of several famous books, I own the copyright on the compilation, despite having only removed text. The original authors, of course, retain their copyrights on both their whole books and on the chapters I used, and I'd better have their permission before I try this. As long as there is creative expression in which sections I choose, I retain copyright on that expression. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Sergey Spiridonov [EMAIL PROTECTED] writes: Bernhard R. Link wrote: As far as I know, there is no such restriction in usage. It only limits Yes, I agree. What I want to point out is: GPL have restrictions (limitations) on what you can do with the GPL code. So, it takes away *some* freedoms. You are incorrect. Copyright law limits how you may copy or distribute the code. The GPL lifts some, but not all, of these limits. The GPL itself takes away nothing. The same thing is with FDL. If Debian users and maintainers do not need the freedom to remove political statements in most cases (for example Manifesto from Emacs), they can agree with invariant sections in documenation. I believe in most cases we can agree with such a limitation. Your argument has false premises. Want to try again? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Sergey Spiridonov [EMAIL PROTECTED] writes: Brian T. Sniffen wrote: You are incorrect. Copyright law limits how you may copy or distribute the code. The GPL lifts some, but not all, of these limits. The GPL itself takes away nothing. According to your statement, any license do not put any restriction on user. It does a copyright law. GPL lifts some limits to restrict users. This section is sufficiently far from Standard Written English that I cannot reliably parse it. Perhaps this is what you mean: : According to your statement, no license puts any restrictions on : users. Copyright law does so. GPL lifts some limits which : otherwise restrict users. I'm going to proceed as if that's correct -- say so if it's not. Many licenses put restrictions on users. For example, some proprietary licenses forbid running the program for profit, or forbid publication of quantitative critical reviews. Copyright law, normally, does not forbid me from running a program in whatever way I like, or from publishing true factual information. Both of these example licenses offer me a trade: they will permit me to do certain things otherwise forbidden by copyright law (i.e., copy the program onto my computer) in exchange for not doing certain things otherwise allowed by copyright law (i.e., running the program for certain purposes, publishing reviews). So does FDL. The GNU FDL, like the proprietary licenses I mentioned as examples, offers a trade. Unlike the MIT/X11 license or the GNU GPL, the GNU FDL does not only grant permissions to the user: it offers to trade him some permissions in exchange for some freedoms. The particular trade it offers is non-free. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Richard Stallman [EMAIL PROTECTED] writes: This is a very important point. I have stated before that I would not have serious objections to the FSF issuing a small number of non-free manuals for a good reason, as it has been doing for 15 years. The FSF manuals are all free documentation by our criteria. We are the ones who first started to say that documentation should be free, and we are the ones who first wrote criteria for free documentation. I would swear Knuth predates you. I'm certain that Jefferson and Franklin, who argued against the Copyright Clause of the US Constitution, predate you. I find it implausible that you would not know that Thomas Jefferson and Benjamin Franklin opposed the Copyright Clause particularly because they believed documentation -- information of all sorts -- should be free. It may be convenient to forget about them, but it reflects badly on you to claim credit for yourself which rightly belongs to your betters. I hope that Debian developers will vote to follow our criteria for free documentation, but they have the right to choose differently. However, you cannot expect us to follow your choice if it differs from ours. Ultimately we and Debian may simply have to disagree. But the FSF is exploiting its monopoly position with regard to Emacs to do things which it does not permit further distributors to do. The Emacs manual claims to be part of Emacs, but only the FSF, as the copyright holder of both works, can distribute a combined work of Emacs and the Emacs Manual. I cannot distribute a package consisting of Emacs and Brian's GFDL'd Emacs Manual, because the GPL does not permit me to link my GFDL'd textcode with Emacs. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
Richard Stallman [EMAIL PROTECTED] writes: We need every method of informing them that we can get. Then why not go the Reiser[3] way and require that an advertisement for the Free Software movement be printed out at every interactive invocation of a GNU derived GPLed program? A long message at startup would be very inconvenient, simply for being long, regardless of its meaning. A section of the same length in a manual would not cause any such inconvenience. Nobody is heavily affected by a few extra pages in a large manual. But what about those who would use the large manual to derive a small manual? You've granted one important freedom with the GFDL -- the freedom to modify the existing work for its current purpose. You've held back the freedom to derive works of new and different purpose. That's the core argument behind most of what's been said on debian-legal: the controls on deriving new works are too onerous. The technical arguments, like that regarding the no technical measures to restrict copying, which bans marking a GFDL'd file anything other than world-readable, are probably surmountable with a new version of the GFDL. The ability of a vi-worshipping author to, say, add an invariant section in his math-in-lisp text on editor choice, thus forbidding use of anything from that text in any Elisp manual, is too much of a restriction to be Free. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: A possible GFDL compromise
MJ Ray [EMAIL PROTECTED] writes: On 2003-08-28 01:28:54 +0100 Branden Robinson [EMAIL PROTECTED] wrote: Enjoy is not a term I would use to describe the process of experiencing, say, Derrida's _Limited Inc._, but if that work were freely licensed, I would certainly be able to access, read, and otherwise use it. The trouble is to exclude use in the fair use sense of copying it for republication. Enjoy seemed a good word, as in right to quiet enjoyment that is a fairly unrelated legal phrase. Probably there's a better one. Indeed, I started with documentation and switched to text as more general; it's hard to keep the sentence structure so close using the word work. Content sounds good, so far. -Brian
Re: A possible GFDL compromise
Sergey V. Spiridonov [EMAIL PROTECTED] writes: The GNU FDL, like the proprietary licenses I mentioned as examples, offers a trade. Unlike the MIT/X11 license or the GNU GPL, the GNU FDL does not only grant permissions to the user: it offers to trade him some permissions in exchange for some freedoms. The particular trade it offers is non-free. Do I understand you correctly? I don't think so: Copyright law grants some permissions. GPL grants some additional permissions and does not put additional restrictions. Copyright law restricts some freedoms: copyright is not an inherent right, but a government-granted right of control. The GPL lifts some of those restrictions, imposing none of its own. Do you state that any license like FDL, which puts additional restrictions on user is non-free disregarding of additional permissions it grants? Certainly any additional permissions it grants don't make a difference. There may be some infinitesimal additional restriction which does not make an otherwise Free license non-Free... but I cannot think of any. I doubt they exist. Such point of view on freedom is dependent on the copyright law. No, any given work may have slightly different restrictions in different domains of copyright law, but from looking at a license to see whether it tries to restrict the user or free the user, it's still not to hard to classify it as Free or non-Free. -Brian
Re: A possible GFDL compromise
Sergey V. Spiridonov [EMAIL PROTECTED] writes: Brian T. Sniffen wrote: Such point of view on freedom is dependent on the copyright law. No, any given work may have slightly different restrictions in different domains of copyright law, but from looking at a license to see whether it tries to restrict the user or free the user, it's still not to hard to classify it as Free or non-Free. If the copyright law will be changed in the way that FDL will need just to grant permissions, you will say FDL is free, don't you? If the copyright law were such that the MIT/X11 license had the same effect as the GFDL 1.2, then I would accept a GFDL 1.3 identical in text to the MIT/X11 license as free. But this is not useful to your argument, is it? This is because you are wrong. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: SURVEY: Is the GNU FDL a DFSG-free license?
Andrew Suffield [EMAIL PROTECTED] writes: On Thu, Aug 28, 2003 at 06:08:47PM +0300, Richard Braakman wrote: On Thu, Aug 28, 2003 at 11:35:16AM +0100, MJ Ray wrote: Why have we another sudden influx of people who haven't read any of the history on this? (Rhetorical. I think we can guess.) I'll answer it anyway: it's because our conclusions are reaching a wider audience, which means we have more people to convince. I'll expand upon that: it's because our conclusions are reaching a wider audience, many of whom are stupid or insane. I'm fairly convinced that somewhere there is a mailing list or SlashRMS server which is featuring an article summarized by: Debian's going to force Emacs to be distributed without a manual. You need to all go and vote, to prevent Debian and ESR from censoring RMS. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Licence oddity in Securing Debian Manual
Branden Robinson [EMAIL PROTECTED] writes: [Rick, apologies for the CC if you are subscribed to this list.] On Thu, Aug 28, 2003 at 01:54:31AM -0700, Rick Moen wrote: This reminded me of something I noticed earlier today. The Securing Debian Manual at http://www.debian.org/doc/manuals/securing-debian-howto/ has in its front material the following: [...] Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Public License, Version 2 or any later version published by the Free Software Foundation. It is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. All well and good, so far. Appendix H of the Manual, in http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-apache-env.en.html , has: This document is copyright 2002 Alexandre Ratti. It has been released under the GNU-FDL 1.2 (GNU Free Documentation Licence) and is included in this manual with his explicit permission. Doesn't that create a licence conflict? Yes. No. Even RMS does not posit that the GNU GPL and the GNU FDL are compatible licenses. They are not miscible in a single work except by a party with copyright on the complete corpus. That's obviously not the case here. True. But I read the phrase This document... explicit permission as saying that Appendix H has a different copyright-owner, and has been separately distributed under the GFDL1.2. The whole work is under the GPL2, as said at the beginning. The only other explanation which makes sense with the explicit permission comment would be that it's under the GFDL, with a special linking with the Securing Debian Manual exception -- unlikely, but the only way to know is to ask Ratti. -Brian Please file a bug against www.debian.org, and feel free to quote this message. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Bug#156287: Advice on Drip (ITP #156287)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: The ban on use of circumvention devices for copy-prevention schemes is probably toothless, given the fair use doctrine. However, the following activities banned by the DMCA are not copyright infringement, and so fair use is not a defense for them: * Trafficking in access-control circumvention devices. * Accessing a protected work. Here we have a different question, with a very different answer. The first is easy. The access-control circumvention device is not actually a device, but a program; that is, a set of bits. Indeed, nobody is accused of trafficing in a *device*, but only the bits, given that in general not even a CD is being sent. Moreover, trafficking is not merely transmitting, but specifically commercially. Debian doesn't in fact traffic in anything. You haven't read the DMCA, have you? The actual text is No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that-- (1201(2)) Debian certainly manufactures, imports, and offers to the public technology. Anyhow, the point is that there is no existing first amendment category which allows such a restriction on speech. Telling someone how to circumvent access is manifestly speech; there are exceptions to the first amendment for copyright or trade secrets, but in the instant case, this is neither. Nor is it libel, or obscene. The speech-nature of computer programs may be protected; the functional nature of computer programs is likely to not be. The courts appear to be favoring, at best, a portmanteau approach to the question Is Code Speech? As for the second, it is not at all clear to me that the DMCA actually prohibits accessing a protected work, in the context in which I have actually purchased the copy. I have, in fact, purchased the right to access the information on my DVDs. When I play it using my home-unit Yamaha DVD player, I do not break the law, and when I do so using DeCSS, I do the same. Given the lack of explicit license or contract in the DVD packaging, your argument sounds reasonable -- an alternate explanation is that Yamaha and Best Buy are also violating the DMCA, but the MPAA declines to sue them. Now, if my copy were illegally obtained, it might well be illegal for me to access it. I don't know. But this doesn't affect us; the fact that there is a legitimate use for the software immunizes us against the fact that someone might also use it for nefarious purposes. I agree that, if the issue comes up, Debian should make clear that our intention in distributing DeCSS would only be for access to legal copies. I think that neither you nor I are lawyers, and Debian should keep its nose painfully clean until it has reliable legal advice on this subject. And probably let somebody else be the test case. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: SURVEY: Is the GNU FDL a DFSG-free license?
Andreas Barth [EMAIL PROTECTED] writes: * Joe Wreschnig ([EMAIL PROTECTED]) [030828 19:50]: On Thu, 2003-08-28 at 03:55, Andreas Barth wrote: So, as a ad-hoc statement it seems to me that the only way in the spirit of the Social Contract is to accept GFDL-docu if certain restrictions are not used (except for a license text, which we always did accept as invariant and which is invariant by law). However, don't expect me to back this up. There is nothing which can IMHO be used as basis, because the DFSG cannot really apply (see above). And opinion is not a good basis for a discussion. The documentation published by the Free Software Foundation uses invariant sections extensively. Since these are the manuals a few people are trying to keep in Debian regardless of their freeness, this ad hoc solution will be just as unpopular as removing all FDLd documentation from main. So we might as well do it right, and remove it all. We seem to have different views on what's right. IMHO the right thing is to make a DFDG, Great. Write one. Having proposed this, you will not be taken seriously until you have a candidate set of Free Documentation Guidelines for public review. in other views the right thing is to act on the DFSG[1]. This discussion is IMHO valuable, but: We seem to have the same conclusion about most actions what should be done now[2], so the difference in motivations should not stop this to happen. [1] as I said: IMHO the DFSG doesn't really apply, but only as a first aid as long as we don't have another guide.[3] [2] now could also be after sarge, that's a different discussion. [3] We definitly shouldn't make another guide while the argument about the GFDL is so hot. First solve this issue (IMHO removing or replacing the GFDL-docus with invariant sections) and then doing a guide _afterwards_. You are confused as to the nature of the issue. Invariant sections are not the only non-free feature of the GFDL: The restriction on technical measures which obstruct copying is also non-free. It is even harder to take you seriously because you were deceptive in your answer to Branden's survey: asked Is X in set Y, when X is software covered by the GFDL, and Y is the set of all software which is DFSG-free? you answered with nonsense -- though I don't remember off hand whether you were one of those who used the nonsense Yes, because documentation is not software! or None of these represent my opinion, because documentation is not software! Whether or not documentation can be software is irrelevant to that question, and you look like a mindless zealot when you respond in such a way. The question is Is software licensed only under the GFDL Free Software in the terms of the DFSG? Nothing else. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
