Re: Results for Debian's Position on the GFDL
On Fri, Mar 17, 2006 at 02:00:42PM -0500, Raul Miller wrote: On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote: Using a pseudonym to make it harder to identify you is in clear violation of the above-quoted requirement. You've indicated that it's difficult to do so, but the intent of this clause remains very clear. This requirement does not apply when making modified copies of GFDL'd documents for distribution by Debian. It would be extremely unfortunate for Debian to change its standards of freedom to merely distributable by Debian. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpretation of the GR
On Thu, Mar 16, 2006 at 04:58:06PM -0500, Jeremy Hankins wrote: Glenn Maynard [EMAIL PROTECTED] writes: If a GR says something is Free, then it must be saying that either 1: the work is distributable, or 2: distributability is not relevant to freeness. A GR that calls a work Free is not orthogonal to distributability; it's intrinsically tied to it. The issues aren't orthogonal, but the decisions are. One decision (the GR) is made by debian developers. The other is made by the courts. The courts don't care about the GR if they have to decide on whether a GFDL work is distributable via debian infrastructure. Consequently, there's no reason to take the GR into account when deciding whether GFDL works are distributable. It's irrelevant to that discussion. I'm sorry, I'm having trouble following your logic; this reads like a set of unrelated statements. (Not meaning to flame or anything, I just don't follow.) The determination of distributability and of freedom are directly tied: a work which can't be distributed reasonably violates DFSG#1 at its most basic level. I don't know how you can call distributability and freedom orthogonal decisions. What's more, your opinion (or mine) on whether the GFDL is distributable given debian infrastructure is also irrelevant, because it carries no weight. The GR isn't going to get changed because you or I believe GFDL works aren't distributable -- not unless we can convince enough other people of that to get another GR passed. This is like a GR that says: the GPL permits combining code with proprietary systems, and Debian will do so and encourage its users to do so. It's patently false, and is merely a declaration of intent to violate the license. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpreting the GFDL GR
On Thu, Mar 16, 2006 at 11:36:34AM +0100, Frank Küster wrote: For what it's worth, I voted for Amendment B over the original text because I am convinced that no court (at least in my legislation, I have not much knowledge of others) would rule that someone has violated the license because of chmod or similar - simply because it is the normal state in the computer world, even on Windows systems, that stuff is not-world readable. Or in other words because this restriction would make the whole license void, and that can't be what the licensor intended. Huh? File permissions are just one example. The clause also prohibits distributing the work on a passworded FTP, and via HTTPS. These technical measures are generally used specifically and deliberately to control the reading of the copies I make, so unintended people can't get the file by logging into my FTP or sniffing network traffic. They're designed largely for that very purpose. This is prohibited from a straightforward reading of the license. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: All rights reserved?
On Thu, Mar 16, 2006 at 12:09:57PM +0100, Francesco P. Lovergine wrote: And what if a script has that clause and not a license at all? Wouldn't be considered public domain, I think... This is a real case for a tiny script (published on a web site) whose author is not reachable. A script with no license is not (generally) public domain anyway; the presence of all right reserved doesn't change that one way or the other. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpretation of the GR
On Thu, Mar 16, 2006 at 08:17:25AM -0500, Jeremy Hankins wrote: But the issue of whether or not they're distributable at all is absolutely orthogonal to the GR. They have no bearing on each other whatsoever. A work can't possibly ever be free if it's not even distributable. This is plain from DFSG#1. If the GR is labelling undistributable works free, then it is in no way orthogonal to distributability. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpretation of the GR
On Thu, Mar 16, 2006 at 08:14:25AM -0500, Jeremy Hankins wrote: The GR says For the sake of the DFSG, we're going to behave as if our generous interpretation of the GFDL is the correct one. It's not a generous interpretation, it's a plainly false one. According to your reading, the GR says we're going to willfully violate the license. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpretation of the GR
On Thu, Mar 16, 2006 at 04:04:37PM -0500, Jeremy Hankins wrote: Glenn Maynard [EMAIL PROTECTED] writes: On Thu, Mar 16, 2006 at 08:17:25AM -0500, Jeremy Hankins wrote: But the issue of whether or not they're distributable at all is absolutely orthogonal to the GR. They have no bearing on each other whatsoever. A work can't possibly ever be free if it's not even distributable. This is plain from DFSG#1. If the GR is labelling undistributable works free, then it is in no way orthogonal to distributability. True. But when determining DFSG freedom debian developers (often in the guise of d-l) can decide on an interpretation -- the courts don't really care about that. When deciding on whether its legal to distribute at all what we or the GR say is beside the point because it's not up to us; it's up to the courts. We can have a GR claiming that the moon is made of green cheese, and that doesn't change anything unless it has a bearing on whether we decide a license belongs in main/contrib or in non-free. If a GR says something is Free, then it must be saying that either 1: the work is distributable, or 2: distributability is not relevant to freeness. A GR that calls a work Free is not orthogonal to distributability; it's intrinsically tied to it. (Limiting this response to the question or orthogonality, leaving the question of whether #1 is true or not to other subthreads.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpretation of the GR
On Thu, Mar 16, 2006 at 04:16:07PM -0500, Jeremy Hankins wrote: For the purposes of this discussion, I'm agnostic on that issue (even though I happen to agree), because it isn't really the point. The fact is, according to the GR, the official debian position is that you (and I) are wrong. Unless you're working on another GR to get that changed there isn't much point in discussing it in the context of the DFSG. So I call the interpretation mandated by the GR generous to distinguish it from literal, which it clearly isn't. The interpretation you say is mandated by the GR is not generous, it's false. If the only rational interpretation that can be found of the GR is that it demands a willfully false reading of the license, so be it. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpreting the GFDL GR
On Wed, Mar 15, 2006 at 06:28:37PM +0100, Henning Makholm wrote: we shall, for the purpose of the DFSG, assume that this requirement is implicitly qualified by If distribution of Opaque copies is made by offering access to copy from a designated place, then offering equivalent access to copy the Transparent copy from the same place counts as distribution of the Transparent copy, even though third parties are not compelled to copy the Transparent copy with the Opaque one. (I am not sure whether ftpmasters should apply this interpretation when deciding whether they dare put binary packages containing opaque copies of GFDL-licensed works on our ftp servers given the current pool infrastructure. I would suggest not. However, that is not directly a DFSG issue). I assert that this interpretation is most faithful to the arguments presented by proponents of Amendment A during the discussion. In particular, when confronted by arguments that a literal reading of the GFDL leads to nonfreedom, proponents of the winning text did not generally challenge the nonfreedom of the literal reading, but instead argued that we should not use the literal reading because that was obviously not what the FSF meant when drafting the license. This isn't a case of taking an *overly literal* reading of a license and ending up with something incorrect. Rather, the literal reading and the natural reading are in agreement, and there's no twisting involved. Read in English, naturally by a native speaker, the license clearly applies restrictions against chmod, etc, and the above interpretation does not come from the license. We happen to have a clarification from one copyright holder (the FSF), but I don't understand how that can be extended to everyone else. The FSF does not have the power to offer binding statements of intent on behalf of all of the users of its licenses. (I still wonder: the FSF has an upgrade mechanism for its licenses, has known about this problem for years, and has acknowledged it as a problem. Where the hell is the fixed license? The only reason Debian is expending so much time on this is because of the FSF's stonewalling. So much of this would be simpler if the FSF would fulfill their responsibility of fixing their license, which they assumed when they begin proliferating it.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 04:54:30PM -0800, Walter Landry wrote: The Word format specification is not available to the public. Here's something I'm confused about: the Gimp's native file format, XCF, has, as far as I can tell, no specification, being intended for use with the Gimp only. All I could find, on searching, was assertions that it wasn't specified, and what appears to be an aborted attempt at documenting it in xcf.txt. Yet, the GFDL actually lists XCF as a transparent format. Huh? Does that mean the GFDL has a special interpretation of the word specification, which includes reference implementations (which certainly are not specifications; anyone who's implemented a file parser knows that)? (At least this one's in the license itself, and not merely a statement of intent from the FSF that we're supposed to assume everyone shares.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: All rights reserved?
On Wed, Mar 15, 2006 at 10:45:10PM +, Alp Toker wrote: Is the term All rights reserved compatible with Open Source/Free Software licensing? If so, is it still considered bad form? I've taken up maintainership of some code with headers that go: /* Copyright (c) 2006 Joe Author. All rights reserved. * standard free license here */ Should the original authors be asked to change this, or is this a case of splitting hairs? For the sake of keeping on-topic: [EMAIL PROTECTED]:/usr/share/doc$ grep -ri all rights reserved * | wc -l 2204 See http://lists.debian.org/debian-legal/2005/10/msg00198.html for previous discussion (from Googling for 'all rights reserved debian-legal'). It's not a problem. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpreting the GFDL GR
On Thu, Mar 16, 2006 at 02:31:48AM +, MJ Ray wrote: We happen to have a clarification from one copyright holder (the FSF), Can you remind me where? I found RMS going to ask a lawyer in http://lists.debian.org/debian-legal/2003/09/msg00212.html but the not-for-debian comment wasn't very long after that. I can't. Others have asserted that the FSF has clarified that they don't mean the DRM clause to prohibit file permissions, sending files with HTTPS (or Tor? or posting GPG-encrypted documentation on a public FTP and only giving one person the password?), or putting passwords on FTP servers; but that's just the FSF, not the general case, so I havn't tried to confirm it. (Note that people's assertions havn't necessarily been for each of those examples above, just some of them. They all seem like equally reasonable ways that I should be able to distribute a free work, all serving similar reasonable goals.) It's delayed until after GPLv3. It seems that FSF won't run concurrent consultations. See message from Chancellor of FSF Europe Chapter Italy: http://mail.fsfeurope.org/pipermail/discussion/2006-January/005448.html FSF Europe seem very friendly, open and transparent, even when I disagree with them about a topic. Blow-offs like The development of GNU licenses is not a Debian issue and their long-term refusal to respond to issues has given me a very different impression. It's irresponsible and damaging for those in the FSF's position to propagate a buggy license--for years!--without fixing it. The rationale doesn't change that, or lessen the resulting damage. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpreting the GFDL GR
On Thu, Mar 16, 2006 at 01:33:30AM +0100, Henning Makholm wrote: Read in English, naturally by a native speaker, the license clearly applies restrictions against chmod, etc, and the above interpretation does not come from the license. I agree on both counts. Yet rather than taking the GR to mean that restrictions against chmod are OK in general, I think the GR says that the GFDL should not be taken to imply restrictions against chmod. If that leads to using an interpretaion that does not come from the license, then so be it - it's a lesser evil than deciding that free software does not need to be chmodable. I don't think pretend the license doesn't place the restrictions it does, tell people that it's free based on that, and encourage interpreting licenses to suit one's convenience is a lesser evil, just a different one. Both mean that I'd never refer someone to Debian for licensing help--in the former case, they'd be told that it's OK to prohibit chmod, and in the latter, they're encouraged to bad, potentially dangerous practices. (Not to say that I have any better idea of how to proceed from this GR. It just doesn't seem to leave any acceptable options--but that fact doesn't improve the bad options any.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interpretation of the GR
On Wed, Mar 15, 2006 at 09:31:04PM -0500, Nathanael Nerode wrote: So the GR promotes a do what I mean, not what I say approach to license interpretation for the GFDL -- it does *not* claim that the literal reading of the DRM restriction is free. But GRs don't get to say what licenses mean. Are you saying that the GR is saying: even though the license says we can't do this, we're going to pretend otherwise, deliberately violate the license and hope for the best? I still think such a philosophy is an invitation to get in legal trouble, but it seems to be the preferred choice of the developers. At least Debian still believes in removing stuff without free licenses from Debian if the licensors decide to actually enforce their licenses as written. ... but at that point, it's too late. Debian and/or its users may already be liable. Such a claim by a licensor would not be a guaranteed victory, of course, but it does feel like Debian would genuinely be in the wrong. Note that this is very unlike the Pine case. In that case, UW was the licensor, applying an unnatural interpretation to its license to retroactively retract permissions. Here, Debian is the licensee, applying an unnatural interpretation to try to give itself permissions it hasn't been granted. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 08:46:16AM +0100, Florian Weimer wrote: It requires preserving any section titled History, required adding it if it's not there, and requires adding stuff to it. I agree that this is quite annoying, but the GPL has similar requirements, although the community at large does not comply with them. The GPL does not require that the information be preserved in any way. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 10:28:06AM +, MJ Ray wrote: Not a stupid label in general, but a stupid label for licences. There's always a UW. Using the DFSG as some sort of licence certification scheme is a really bad idea and organisations that try to do so should die messily. Please let's concentrate on the software: it's worth looking at licences, but software is the thing of interest. I disagree. d-legal should concentrate on the licenses. The software it's applied to is very rarely relevant to the freeness question; it's the license that makes the software free or not. Copyright holders, can create the unusual situation of a work being free or not free in disagreement with the license on its own, due to statements of intent--but that's the rare exception, and rarely a good situation (say what you mean in the license to begin with). I'm not sure what you're suggesting. Maybe I'll understand if you relate this back to the original topic. I don't believe a document placed under the GFDL, with no invariant sections, is free. You can look at it from the license, or by taking document under the GFDL and looking at the resulting freedoms, and the conclusion doesn't change. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 03:06:58PM -0500, Raul Miller wrote: For the DRM issue to be significant, we'd have to have reason to believe that a judge would not be familiar with the legal meaning of the phrase technical measures in the context of copyright law. Other meanings of technical measures would lead to ludicrous conclusions (for example: once we've started giving someone a copy we must keep spamming copies, never being allowed to stop). Encrypting a document (whether via GPG or HTTPS) sure seems like a technical measure to obstruct the reading of copies. And the Opaque issue only applies when the transparent copies are not distributed. It's simple enough to include the transparent copies in any .deb, and it's simple enough to file an RC bug report against any package with GFDL'd content which doesn't include the transparent copies. Maybe I'm misunderstanding the issue you're referring to. My issue with the transparent copies bit is that it prohibits converting the document to, say, a Word document. The GPL allows it: I can convert it to Word, and make that my source form (using it for all future modifications, throwing away the original HTML and all that). The GFDL prohibits this. The Transparent copies definition is being used like source in the GPL, but narrowed to exclude source forms that the FSF doesn't like (even entirely open formats, if they can't be edited with generic text editors.) As for the other issues you call out, I don't think this GR really says much about them: Where these elements are invariant, the GR doesn't say anything about GFDL licensed documents which contain them. Where they're not invariant, the restrictions imposed are not any more obnoxious than practical restrictions on software for non-legal reasons, or practical restrictions on patch clause dfsg software. I think that, prior to this, the patch clause exception was the biggest blunder in the history of the DFSG: calling software which you're never allowed to reuse code from Free. Code reuse is one of the basic goals of free software. It's the biggest error not so much because of the software under these licenses (which are few), but because it's been used to argue as you have: patch clauses even prohibit putting code in version control; since we allow that, we should allow all kinds of other onerous restrictions, too. I had hoped that this might be fixed some day, but this GR moves things a couple miles in the other direction and I no longer retain any such hope. It's never been clear to me that the Dissident test is a accurate reflection of the DFSG. I can think of many ways for a dissident to If a dissident is placed in serious danger if his identity is revealed, I can't think of any way he could work around a license that requires revealing his identity. work around such problems (except for dissidents who more slavishly follow their government's suggestions than most non-dissidents -- but I don't think that's a serious issue). I'm not sure what you mean by follow their government's suggestions. If the license says identify yourself, and identifying myself working on cryptography software will get me thrown in a dark cell, what government suggestion am I slavishly following? Copyright law itself? The government isn't the operating force in the dissident test, anyhow. The dissident test is not simply about dissidents and governments; that's the case used as a test, and for explaining the problem, but the test is applicable much more generally. That's why it's a test. I might work for a company that feels threatened by Free Software, and doesn't want its employees contributing to it. (I don't, to be clear; we actively contribute to free software.) If I was to spread Free Software, and was discovered, I might find myself without a job, so I'd do so anonymously. The Dissident test deals with the many reasons one might need to remain anonymous in order to exercise DFSG freedoms. (If you're thinking about you've probably signed over your copyright already, then use future employers won't hire you. Free licenses shouldn't prohibit anonymity.) Maybe none of this is new, but aside from the Opaque and DRM issues, none of the proposals or supporting material on vote.debian.org indicate that any of these issues are to be taken seriously. That's the problem: license problems are not being taken seriously. The GR casually (and, without another GR, permanently) ignores all of these issues, saying from now on, every issue you find in the GFDL is to be ignored, preemptively labelled free, and probably also any freeness issues are automatically OK if you can find them in the GFDL. The DFSG must now be read to allow mandating identifying yourself, making random section headers invariant, prohibiting converting to formats the author doesn't like, and so on. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 07:15:21PM -0500, Raul Miller wrote: On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote: Encrypting a document (whether via GPG or HTTPS) sure seems like a technical measure to obstruct the reading of copies. In the general case, this is not a technical measure to enforce the copyright holder's legal rights on the recipient of the copy. It has many uses; that is one of them. The same is true of encryption. If the recipient is not allowed to decrypt the document, except under legally restrictive circumstances, that's a different story. For what it's worth, I fully agree with trying to disable the legal teeth of DRM. That is, I think people should be allowed to use technical measures to do whatever they want, but I should be legally allowed to circumvent it. Security-by-encryption is one thing; security-by-jail-time is quite another. (I don't think any special attempt to prevent the technical measures themselves are necessary, since the GPL's source requirements already did that: an encrypted, locked, unmodifiable copy is not source.) The GPL allows it: I can convert it to Word, and make that my source form (using it for all future modifications, throwing away the original HTML and all that). Not necessarily. As a counter example: A word document is not the preferred form for working with .c source code, in the general case. You're nitpicking my example, not what I was saying. The GPL allows it, for works where Word documents are a plausible preferred form for modification. This makes it a reasonable source requirement, ultimately give me the form which you actually use to make changes to the work. The transparent copies requirement smells like a source requirement, but it's more than that: it prohibits changing the source form to a Word document, even if it's a work where Word is suitable (eg. not general C source code), and even if it really is your preferred form for modification. The GPL doesn't prohibit doing so; it says any form can be source, if it really is source, but you can't lie and handwave and pretend an obscured bogus format is source if it's not. (That's why the GPL does allow Word as a source format for C code, if the C code is example code in a manual, while *not* allowing you to hide your changes to the Linux kernel by distributing the source as a Word document and calling it source when it's not.) (Defining source is one thing the GPL did amazingly well at.) Maybe I'm misunderstanding the issue you're referring to. My issue with the transparent copies bit is that it prohibits converting the document to, say, a Word document. That's allowed. ... Of course, in some specific cases a word document might be acceptable. Likewise, in some specific cases a word document might be transparent. A Transparent copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors You can't revise a Word document with a generic text editor. I doubt the format--which, I believe, changes incompatibly with each revision of Office--is public, either. The transparent copies definition seems to very deliberately exclude Word documents, so using Word as your source format seems to be prohibited. I think that, prior to this, the patch clause exception was the biggest blunder in the history of the DFSG: calling software which you're never allowed to reuse code from Free. I don't see any votes on this issue. Perhaps other people in Debian disagree with you? Code reuse is fundamental to Free Software. I'd find disagreeing with that to be akin to disagreeing that source availability or permission to make changes to the work are fundamental--so far from my understanding that I can't imagine how anyone could hold that view. That said, my confidence in Debian's concept of freedom has taken a dive just recently, and I'm much more inclined to agree that Debian Developers may not consider code reuse important. (But the same change in my perception of the opinions of Debian applies to the other core elements of Free Software.) I had hoped that this might be fixed some day, but this GR moves things a couple miles in the other direction and I no longer retain any such hope. Well, it wouldn't just happen by itself. First you'd need a solid core of acceptable software to build a distribution on. Once you have that it's reasonable to go about organizing the distribution in terms of how the code can be reused. Until then, this is a development issue, not a package management issue. I'm sorry, you lost me. Debian is already a solid core of software without patch clauses; only a tiny handful of software in Debian have them. All it would take to fix this would be to remove those (none of which are critical to Debian, though--like any software--no doubt some
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 09:29:40PM -0500, Raul Miller wrote: On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote: (I don't think any special attempt to prevent the technical measures themselves are necessary, since the GPL's source requirements already did that: an encrypted, locked, unmodifiable copy is not source.) Ok, but the legal right to modify a work does not mean that you have the practical ability. More to the point, the GFDL prohibits the use of technical measures to enforce any of the more obnoxious clauses of the GFDL. I can't think of any way that one could use technical measures to fulfill the GPL's requirements without providing usable source. That is, you can't DRM the the source, since--I'd imagine--nobody can actually edit the source in that form. (Or, if you could, then the encryption keys needed to do so would effectively become part of the source.) If technical measures are applied to the source to restrict it, it's probably not the source anymore, by the GPL's definition. (Speaking here only of the DRM subtopic. You could lack the practical abliity to use the source if it's in a weird language, but that's the transparent copy topic--let's keep these things separate for sanity ...) All you need is a broadly available shim -- for example, something to convert word format to xml and xml back to word, to make it straightforward to modify the word document in a generic editor. So you can use any format, all you have to do is reverse engineer it, find an open format that's a complete superset of it (if one exists), and write a two-way lossless converter? That seems tantamount to a prohibition--especially if, like many writers, you're not even a programmer. (I am, and that's still a daunting task.) No one (you included) has even cared to identify subsets of packages where this is true. And we have some fairly broad subsets where code is re-usable. I don't claim that everything must be compatible with everything else. (Though I think it's a good goal, which is why I stick to the MIT license, to maximize compatibility.) With ordinary licenses, at the very minimum, a work's license is compatible with the license itself (any others are a bonus). Patch clauses don't do that. They're compatible with nothing. I don't believe I've ever heard of anyone even suggesting that someone's right to modify software should be revoked because their changelog entries (or whatever) are legally ambiguous. The GFDL specifically says that it must clearly and legibly identify you. Ambiguity and clarity are opposites, and pseudonyms do not identify you. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 10:37:07PM -0500, Raul Miller wrote: On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote: The GFDL specifically says that it must clearly and legibly identify you. Ambiguity and clarity are opposites, and pseudonyms do not identify you. My dad's name is Ron Miller. Are you claiming that his name does not identify him? There's thousands of Ron Millers in the U.S. alone. Are you claiming that there's no ambiguity here? I don't see any requirement in the GFDL that a person's identity must be unambiguous, sworn to, attested, co-signed, pgp signed, unique, guaranteed, warranteed, trackable, reachable, emailable, etc. Using a pseudonym to make it harder to identify you is in clear violation of the above-quoted requirement. You've indicated that it's difficult to do so, but the intent of this clause remains very clear. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
Debian has labelled a license with serious, onerous practical problems free. The obvious consequence is that any license with similar practical problems will also be considered free, and--going one small step further--licenses with serious problems in general will be considered free. This GR has tainted the DFSG-free label, probably permanently. Striving to be DFSG-free has historically been a strong force in encouraging people to genuinely release software freely; it's been my primary motivation for participating here. From what I can see, Debian has thrown that away. On Sun, Mar 12, 2006 at 05:37:46PM -0500, Anthony DeRobertis wrote: This GR also did not say the GFDL is free, as long as this and that interpretation of the license are held; it makes no such qualification. The GR just says: At the same time, we also consider that works licensed under the GNU Free Documentation License that include no invariant sections do fully meet the requirements of the Debian Free Software Guidelines. It does not say whether the interpretation of the DFSG or the interpretation of the license is wrong; I suggest that means we are free to pick, on a problem-by-problem basis, which one is wrong. This is a major contrivance. The GR made no such qualification. It doesn't say under the FSF's interpretation of the license or if our interpretation holds. I'm a little confused, by the way. The thread start quoted: Option 2 GFDL-licensed works without unmodifiable sections are free not invariant sections. Invariant sections is a specific term in the GFDL; unmodifiable sections is different, and would include front- and back-cover texts as well. I can put a document under the GFDL, and say the 'technical measures' clause is, in fact, intended to prohibit encrypting the document. That's not bending or twisting the license; it's merely confirming a straightforward interpretation. Sure. And we could decide that if you do that, we'll treat you just like UW with respect to Pine. Not without another GR to override this one. The GR says the GFDL is free, and I'd be using the GFDL with a perfectly natural interpretation. UW did not use a natural reading of its license; it used a deliberately twisted one. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, Mar 14, 2006 at 01:09:43AM +, MJ Ray wrote: Glenn Maynard [EMAIL PROTECTED] Debian has labelled a license with serious, onerous practical problems free. Labelling licences 'free' means little, as the FSF demonstrated with the ironic name of the FDL. What matters is whether the software under that licence is free software. Labelling licenses free means a lot, if the labelling is accurate. The FSF's labelling of the GFDL as such was not, precisely *because* works licensed under the GFDL are not free software. Historically, Debian's labelling had been, in my view, accurate. The practical problems beyond the DFSG have always been something we commented in, but not a direct freedom problem themselves. The FSF used to do this too - see their criticism of obnoxious advertising clauses - instead of using advertising clauses like now. Free Software goals exist for real, practical reasons. Practical problems *are* freedom problems. If I can't distribute a piece of software over HTTPS, or put a password on my FTP server holding it, or chmod o-r it, the software isn't free because of these fatal practical problems. At a more elementary level, these problems prevent my effective, free exercise of the basic freedoms. (There are plenty of cases in between, of lesser problems that are worth noting and fixing but not rendering the software non-free. I don't see how many of the GFDL's problems can be put in that category, while maintaining any consistency and without diluting the DFSG to uselessness.) I think that's a pessmistic, melodramatic interpretation and I hope you're wrong. I acknowledge that it's pessimistic, but my experiences on this topic lately have strongly suggested that pessimism is much closer to reality than optimism. Of course, I hope I'm wrong, too. More pragmatically, DFSG-free was a stupid label for licences which helped add to the confusion over whether it was the licence or the liberty of the software and users that mattered to us. The license is--largely[1]--what *determines* the liberty of the software and its users. The liberty is the important end result, but it's the licenses that get us there; restrictions placed by licenses (or lack of licenses) is what obstructs that liberty. DFSG-free is not a stupid label; it was an effective, useful one. [1] plus other factors, of course, such as third-party patents and availability of source code -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Mon, Mar 13, 2006 at 10:34:16PM -0500, Raul Miller wrote: On 3/13/06, Glenn Maynard [EMAIL PROTECTED] wrote: Debian has labelled a license with serious, onerous practical problems free. Oh? I find myself quite uncertain as to what it is that you're talking about. I see two issues mentioned in other messages, the DRM issue (the technical measures clause), and the Opaque issue. Are those what you are talking about? Or are there other problems? Those are the big, simple ones. Some other problems that have come up in the past: It requires preserving any section titled History, required adding it if it's not there, and requires adding stuff to it. It doesn't seem clear what preserve means, however. If it means that History is an append-only-invariant-section, it seems like *all* GFDL documents contain an unmodifiable section. I'm not sure, though: it says preserve, but not preserve, unaltered in their text, as it does for Invariant Sections, and preserve alone is not defined. It prohibits modifying several section titles. It gives a prescribed method for translation that's likely to be inappropriate and awkward. It prevents labelling sections History or Endorsements if they're, say, talking about the history of the topic (and not the history of the work) and disucssing endorsements rather than giving them. It requires maintaining dedications, even when inappropriate; if I use a page from your work, I have to preserve Dedicated to Raul's dad. It requires adding an appropriate copyright notice for your modifications; I don't know what that means, if I've placed my modifications into the public domain, or if my modifications come from a third-party public domain source. The identify you as the publisher bit seems to fail the Dissident test; at least on a natural reading (perhaps not a legal one), that seems to prohibit using an alias. equally prominent and visible seems to prohibit stylization; preventing me from publishing a modified version with a cool stylized title page seems like a patent violation of DFSG#3 to me. (I have no idea what the *purpose* of that restriction is--it's not like the title can't be changed; on the contrary, 4a mandates changing it.) The degree of some of these problems is debatable (none of this is new), but in sum, I can't honestly call this free. What bothers me almost as much is that I havn't seen cohesive responses to these or other problems. I can deal with rational disagreement: this is why we don't think this restriction is a problem--but we don't seem to have that. Instead, we've been handed down the result, and we're expected to use IK or something to force-fit the DFSG to reach the desired outcome. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Sat, Mar 11, 2006 at 11:01:19PM -0500, Anthony DeRobertis wrote: However, Option 1 was the consensus of this list, and thus we've been overridden[0]. I feel that we now need to figure out why the project as a whole has rejected the draft position statement [2] and render our The GFDL has more serious problems than most licenses, and Debian has stuck its rubber stamp on them; we're stuck with them, probably for good. I'm sure any pretense from the FSF of trying to fix these problems will be dropped entirely now, since Debian has said they're OK. The project has asserted that onerous practical problems are acceptable. Message-Id: [EMAIL PROTECTED] lists some other problems found on a quick reading, not all mentioned in the old position statement. Also, any other problems found in the license can no longer be considered DFSG- unfree, no matter how bad they are; this GR forces any such problems to be contrived as free. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute has been mis-read. I don't think there is any way the Project would consider you must make all your files a+r, etc. a free license. I propose that the Project is telling us that something along the following is the true reading: You may not use technical measures to obstruct or control the reading or further copying [by the intended recipient] of [all] the copies you make or distribute [to him] The Project can't say what the true reading is. Only the license and the copyright holder can determine that. The Project has no power, by GR or otherwise, to define the interpretation of someone else's license. This GR also did not say the GFDL is free, as long as this and that interpretation of the license are held; it makes no such qualification. The Project is telling us that it's Free to prohibit encrypting a document, since that's what a straightforward reading of the GFDL does. Even if the FSF has clarified that it's not *their* intention, that's only partially waiving the clause for only the FSF's works. I can put a document under the GFDL, and say the 'technical measures' clause is, in fact, intended to prohibit encrypting the document. That's not bending or twisting the license; it's merely confirming a straightforward interpretation. This GR says that it's free to prohibit you from sending the document over https, or to attach it to a message GPG-encrypted. (The silly thing is just how worthless this clause really is. Merely requiring source be available--you know, the preferred form for modification--prevents any effective DRM. This ill-conceived clause didn't even need to be there, and now Debian has to consider it free.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better licence for fosdem, debconf, .., videos...
(Grr. d-legal has been silently dropping my mails for a while now, and I only just noticed.) On Wed, Mar 08, 2006 at 08:59:37PM -0500, Joe Smith wrote: The license must allow modifications and derived works, It does allow those. and must allow them to be distributed under the same terms as the license of the original software. It does allow that. There is nothing in #3 to prevent restrictions on modified works. This seems close to arguing: DFSG#3 can't reasonably be read to forbid all restrictions on modifications, therefore it must be read to allow them all. That conclusion is equally wrong, but at the opposite extreme. If DFSG#3 is read as not preventing restrictions on modified works, then it becomes an effective no-op. It's meaningless to say we require permission to make modified works, but you can place whatever heinous restrictions on doing so that you wish. The line is somewhere in between those two extremes, subject to the judgement of Debian. Being guidelines and not rules, the DFSG doesn't tell us exactly where that line lies. (The same applies to DFSG#1, and the rest.) This restiction only in the Scotland version only requires removal of attribution in the form found in the copyright message (or equivlent). Huh? Copyright notices are not attribution, they're statements of copyright. There may be contributors who deserve attribution but have no copyright claim; for example, they may have placed their contributions into the public domain. I typically put copyright notices at the bottom of source files, so they're available but unintrusive; attributions at the top. Is it even legal, even on request, to remove a person's name from a copyright notice if they havn't actually released the work into the public domain? They still have a copyright claim, so it seems like a misleading copyright notice. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Testing, one, two ...
My messages havn't been showing up here, but they have to d-project. Sending a mail from the address I'm subscribed to, to see if someone turned on subscriber-posts-only or something like that. (I'm not getting any bounces, though, and I've posted with a different address on this list for years.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Tue, Feb 21, 2006 at 01:12:28PM -0500, Raul Miller wrote: On 2/20/06, Glenn Maynard [EMAIL PROTECTED] wrote: I still don't understand how either of these (whether Qmail or TeX) could have been considered so critical that it justified sacrificing code reuse, allowing licenses to effectively prohibit it. People say trust me, we thought about this, but I have yet to hear the resulting rationale, if there ever really was any. Code re-use (in the sense of using the code outside the package in question) wasn't one of the priorities. If it had been, we'd have required everything be compatible with the GPL. Not any code can reuse any other code, but patch clauses mean code can't even be reused in code with the *same license*, prohibiting it entirely. I hope you're wrong and that code reuse is unimportant and can be prohibited wasn't really the rationale. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Mon, Feb 20, 2006 at 10:33:31AM -0500, Raul Miller wrote: On 2/16/06, Glenn Maynard [EMAIL PROTECTED] wrote: On Thu, Feb 16, 2006 at 08:13:01PM -0500, Raul Miller wrote: I think that it's safe to say that at the time the DFSG was drafted it was felt if the patch clause wasn't included in the DFSG that some software important to Debian would have been treated as non-free. I think it's also safe to say that we thought that allowing that software into Debian was a better idea than excluding it. According to Branden, it was an attempt to get Qmail into Debian, and that's treated as non-free anyway. I disagree: At the time the DFSG was being drafted, it wasn't clear how qmail would be distributed. That doesn't seem to contradict Branden's post. Feel free to discuss it with him, though; I wasn't around at the time. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Mon, Feb 20, 2006 at 07:14:47PM -0500, Raul Miller wrote: Eh... I think I remember that it was thrown in for Knuth's software, thoughI don't remember the specifics of those licenses and packages. I still don't understand how either of these (whether Qmail or TeX) could have been considered so critical that it justified sacrificing code reuse, allowing licenses to effectively prohibit it. People say trust me, we thought about this, but I have yet to hear the resulting rationale, if there ever really was any. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Thu, Feb 16, 2006 at 10:49:47AM +0400, olive wrote: You have? You elided the bulk of Don's response wholesale, and your arguments often seem to reduce to poorly-defended assertions of what you think the DFSG should mean. As I have already said in a previous message let's say we disagree. Any opinion in contradiction with yours will be poorly defended. Some of Nope. I've had lots of debates with others on this list where the other person's position was well-defended. This is not one of them. As a case in point, you still havn't responded to Don's message which, as noted above, you elided wholesale, and still havn't replied to. I was reading the page http://www.debian.org/intro/free;; it basically says that free software is about the same as open source software and free software is linked to the definition of free given by the GNU project! This page seems to says that the DFSG is a mean to precize the definition of Free given by the GNU project. I think this was probably the case at the beginning of Debian but now this page seems terribly misleading. In the case of documentation, sure: the FSF's notions of Free Documentation have diverged from Debian's. Debian feels that documentation should be held to the same standards of freedom as programs, and the FSF does not. Feel free to lobby to have that page changed, if you feel it necessary, but refrain from trying to use it as a stick to beat Debian with. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Thu, Feb 16, 2006 at 08:13:01PM -0500, Raul Miller wrote: I think that it's safe to say that at the time the DFSG was drafted it was felt if the patch clause wasn't included in the DFSG that some software important to Debian would have been treated as non-free. I think it's also safe to say that we thought that allowing that software into Debian was a better idea than excluding it. According to Branden, it was an attempt to get Qmail into Debian, and that's treated as non-free anyway. http://lists.debian.org/debian-legal/2002/07/msg00071.html The rationale for modifying the DFSG to include this list would probably be that we feel that allowing software with these (relatively minor) warts in them would be good for the free software community. In part this would be out of respect for the FSF and its contributions and decisions. I have trouble describing the complete prohibition of modifying a work as a relatively minor wart. It seems ironic to waive freedom requirements for the FSF out of respect for its contributions to free software. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Wed, Feb 15, 2006 at 10:30:16AM -0800, Adam McKenna wrote: On Tue, Feb 14, 2006 at 11:42:03PM -0500, Glenn Maynard wrote: I think convenience is something to be considered in determining whether something is free or not; a hint, nothing more, but not irrelevant either. It's something that can be sacrificed, to a certain degree: the GPL is pretty inconvenient at times, but its effects are acceptable. Yes, and so it will be with the GFDL. So what will be? The GFDL prohibits modification of a part of a work, and freedom to modify is not something that can be sacrificed. What really matter is whether _creators_ of free documentation decide that the GFDL is suitable for their works. This is what will make or break the GFDL, not whether Debian decides to distribute works licensed under it. A license is free if people making free works use the license? Stack overflow ... Yes, you're right. However, we need to distinguish between when something is actually impractical, and when someone is merely pretending it is impractical because they don't like it. We need to distinguish between things that are problems and things that are not, but the sincerity of the individual giving the argument has no bearing on that. (Though I've had the opposite impression from Craig, that he actually believes the opposite of what he says, and argues in reverse, in order to associate mindless flaming with the perspective he disagrees with ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP License for PHP Group packages
On Wed, Feb 15, 2006 at 05:16:54PM -0800, Steve Langasek wrote: | 3. The name PHP must not be used to endorse or promote products | derived from this software without prior written permission. For | written permission, please contact [EMAIL PROTECTED] The usual no-endorsement clause that we consider acceptable in BSD licenses and the like is different, because it talks about the name of the copyright holder or contributors, not about the name of the original work[1]. Why is that an important difference, in terms of freeness? Clause #3 of the PHP License v3.01 forbids promoting derivative works with sentences like This product is based on PHP or This product is a modified version of the famous PHP scripting language interpreter, which are true and do not harm the PHP Group, AFAICS. I'm not sure this is a correct reading of endorse or promote. This product is based on PHP is a factual statement, and implies no endorsement or promotion by the PHP Group. In contrast, saying supported by PHP or works with PHP implies an endorsement. Well, saying this product is based on PHP in an ad is using the name PHP to promote the product. The corresponding BSD clause: 3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. I think this prohibits saying powered by stuff written by Steve Langasek and the University of California in an advertisement without permission, but not ... powered by Subversion. The PHP license, and others, took this clause and changed the name of its contributors, etc. to the name of the product, creating something different. The Subversion says that if I fork Subversion, I can't say based on Subversion! in an advertisement[1]. It seems fine (though probably legally redundant) for a license to say don't claim I endorsed something I didn't, but don't mention the use of this software in your ads is less clear. If the PHP and Subversion licenses don't say that, then I'm not sure how I'm misreading them. (FWIW, I don't have a strong opinion on this; I just want to understand the licenses.) [1] 4. The hosted project names must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [EMAIL PROTECTED] (I find it curious that this license--the old Apache one--simultaneously requires an acknowledgement in the documentation, and prohibits mention in advertisement. They want credit, but not too much credit?) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Tue, Feb 14, 2006 at 08:29:59AM +0100, Yorick Cool wrote: Climbing a 4,000 foot mountain is certainly possible. Its just inconvenient [well, unless you do that kind of stuff for fun]. Personally, I do not find this license to be free, even though its just a convenience issue. Seeing as that is a void condition which is totally unenforceable[1], the license is just the same as if the condition were inexistent, so yeah, it's as good as free. Do you just want to nitpick and distract from what little conversation there is here? Do you have a response to his actual point (that convenience arguments are a weak attempt to ignore non-free restrictions, which can be applied to almost anything)? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Tue, Feb 14, 2006 at 01:02:27PM +0400, olive wrote: And this was my opinion: the idealogy of some people is in my opinion have become excessive to the point of being harmful to free software. I think that I have the right of saying that without being accused of insulting people. Zealot is derogatory and inflammatory. If you're not a native speaker and didn't know that, now you do. If you don't want to be accused of insulting people, it's your task to not do so; if you do, you do not have any such right not to be told so. (It's disappointing that you respond in this tone in response to Don's forbearance.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Tue, Feb 14, 2006 at 04:57:47PM +0100, Yorick Cool wrote: The and what about this absurd license argument crops up regurlarly to try to demonstrate that requirements having nothing to do with software freedom per se can impede it's freedom. The problem is that the particular absurd license argument fails miserably in that such licenses' absurd requirements would be unenforceable[1]. This statement does not resolve the convenience problem, because even if the absurd license argument is unvalid, one can still argue that inconvenient clauses are non-free (FWIW, I tend to believe the contrary regarding a certain number of specific unconvenient clauses). I believe that is far from being a nitpick, because the argument is thrown around quite often, and having to deal with it creates alot of unuseful noise which does not help resolve the specific question at hand either way. Hence why I pointed out the weakness of the argument. The argument is we wouldn't allow this restriction, so why should we allow this other restriction that looks very similar? The question of whether the extreme example is enforcable or not doesn't enter into it. It's a very useful approach to explaining an argument; it accentuates the variables, and helps people find common points of reference. When people agree with the extreme case, and still disagree with the argument, they've established outer boundaries to narrow in on where they believe the line lies, and why; and it's a useful step in determining when that line is blurry (where bright line tests don't exist). (Unfortunately, some people miss that point, and merely respond with that's silly[1].) Anyway, what do you think distracted most from the conversation, my initial remark, or your message and my reply? My response started out with a reply to your claim, which I then deleted to avoid the distraction. Instead, I offered my interpretation of Anthony's argument, which had multiple purposes: to summarize it in case it was missed; and to give Anthony an opportunity to correct me, if my interpretation was off. I don't consider that a distraction at all. Since you seem to insist (and we're already thoroughly distracted anyway), I'll offer that, too. Nonenforcable only means free if the author's wishes are considered discardable if they don't have legal teeth. The author wants to restrict you in a DFSG-unfree way, but we think you can get away with it, so don't worry is hardly something Debian should be saying. Additionally, enforcable depends on jurisdiction; Debian doesn't have the means to tell with any certainty that a clause is unenforcable in *all* jurisdictions. Even your post included an in civil law qualifier. For license evaluation purposes, we assume that every restriction is enforcable (unless it's directly relevant, eg. severability). [1] Examples are probably unnecessary, but for the hell of it, http://lists.debian.org/debian-devel/2006/02/msg00285.html [grep for fraud] -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Tue, Feb 14, 2006 at 04:13:59PM +0400, olive wrote: To answer, Patrick remark; a search in this list will show you that I have considerably discussed and defended my opinion even if I do not agree with most of the posters. You have? You elided the bulk of Don's response wholesale, and your arguments often seem to reduce to poorly-defended assertions of what you think the DFSG should mean. And to repeat myself from a response to a previous poster making your argument, This is just more wedging, trying to abuse the fact that Debian allows invariant license texts to squeeze in other invariant stuff. I would suggest anyone engaging in such wedging carefully reevaluate whether what they're doing is really in the best interests of Debian; or whether they're just trying to contrive a way to pound Debian into agreement with the FSF. [1] http://lists.debian.org/debian-legal/2006/01/msg00493.html -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Tue, Feb 14, 2006 at 07:52:26PM -0800, Adam McKenna wrote: On Tue, Feb 14, 2006 at 04:17:11PM -0500, Joe Smith wrote: dict is both free AND convenient! n 1: the state of being suitable or opportune; chairs arranged for his own convenience Why would one desire freedom for something except that it is more suitable or opportune than not being free? Yes, convenience is an *effect* of certain types of freedom. As a mental exercise, try to imagine a scenario where the existence of a particular piece of free software would be very *inconvenient* for you. I think convenience is something to be considered in determining whether something is free or not; a hint, nothing more, but not irrelevant either. It's something that can be sacrificed, to a certain degree: the GPL is pretty inconvenient at times, but its effects are acceptable. Practicality is more significant. If a license makes it *impractical* to exercise DFSG freedoms, it's non-free. That doesn't actually say much, except that merely making it possible to exercise freedoms isn't enough, if it's not practical; that there are limits to the hoops that can be placed in front of DFSG freedoms. Of course, that's also just a guideline--there are some cases which we accept being made impractical by a license, such as proprietary distribution (because that case is considered inherently incompatible with Free Software goals). I think it's a better one than convenience, though. No, it's desirable because it's free. Convenience is subjective. Freedom is absolute. Freedom is subjective, too; there are a lot of views on it, even within the bounds of the letter of the DFSG. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Sun, Feb 12, 2006 at 12:13:26PM -0500, Benj. Mako Hill wrote: quote who=Glenn Maynard date=Sat, Feb 11, 2006 at 05:10:14PM -0500 If you have one GPL-ish license designed for arcades, and another for toll booths, and another for web services, then you can't use code written for toll booths in a web service, and vice versa. That's a pratical problem, not a freedom issue. That doesn't mean it doesn't matter but the GPLv3 shows draft already shows that these sorts of pratical problems can more easily be worked around. Of course it's a freedom issue. A license that makes it impractical to exercise DFSG freedoms is just as non-free as one that prohibits it entirely, and that's true whether it was intentional or not. Lcenses that effectively say the software can only be used in contexts where it's possible to supply code to users do so. Free licenses don't get to say this code can not be used in toll booths--neither directly nor indirectly. You can't sidestep and ignore the DFSG by changing prohibitions into impractical conditions. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP License for PHP Group packages
On Sat, Feb 11, 2006 at 03:33:42AM -0800, Steve Langasek wrote: THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND is also wrong for anything which is not from the PHP Team. Agreed; this license is still not suitable for software that doesn't come from the PHP Group. Non-free unsuitable or just unsuitable? A lot of non-BSD software uses the BSD license's THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS disclaimer, even software with nothing provided by THE REGENTS. It's a mistake, claiming someone contributed to something when they didn't, though it's a mistake Debian encourages, given that any package using a common- licenses/BSD symlink has this problem ... (The disclaimers, incidentally, are otherwise identical, except for the odd change of EXPRESS to EXPRESSED.) Is it the lack of AND CONTRIBUTORS that's the problem? The only difference I might guess is that the PHP license's version may not disclaim warranty for some people, but they're free not to do that, right? (But probably didn't intend not to ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Sat, Feb 11, 2006 at 04:18:26PM -0500, Benj. Mako Hill wrote: There's the possibility that we solve this problems in different ways for different classes of license. The AGPL might not do that now but maybe we can make it do that or find another license that does that. Maybe we have a different GPL compatible license when it comes to software in arcade games or toll booths? If you have one GPL-ish license designed for arcades, and another for toll booths, and another for web services, then you can't use code written for toll booths in a web service, and vice versa. That's the crux of the problem: these licenses, targetting a specific use, tend to make it impractical or impossible to use the code for a very different purpose. Having several of them for different purposes doesn't solve that problem. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FYI: Savannah forces new projects to use GFDL for documentation
On Sat, Feb 11, 2006 at 11:26:17PM +0100, Sebastian Wieseler wrote: So you should respect me and don't post the caches of my sites anywhere. MY blog and I can post what I want to post. I don't care about your opinion. Very well, but respect me and I don't care what you think seem at odds. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Sat, Feb 11, 2006 at 04:12:39PM -0800, Josh Triplett wrote: Would it be an excessive requirement to provide an offer for source (at up to 10 times your cost of providing source)? The offer could easily be stuck in the fine print next to the copyright notices. I've generally been of the opinion that the provide an offer for N years option in the GPLv2 is not a free option. That is, software that requires it and didn't offer the GPL's easier alternatives (to place the source alongside the binary on the FTP) would be non-free. I don't think we've ever actually seen a license do that and it's only come up theoretically. (Who would ever mirror Debian if every mirror had to maintain a snapshots.d.o? An argument could easily be made on Dissident Test grounds, as well. The 10 times change makes some cases more reasonable for some people, but not free.) So I think my answer is yes; it's not reasonable to require that I commit myself, for years into the future, to the task of archiving, packaging and shipping source, and this is just a slight variation on that theme. This, by the way, isn't a flaw in the GPLv2: it's perfectly fine for a free license to offer non-free alternatives alongside the free ones. (You know that, of course.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Fri, Feb 10, 2006 at 11:07:08AM +, Gervase Markham wrote: Glenn Maynard wrote: But that's a special case; more generally, I don't see any way at all of satisfying this for the voicemail, toll booth, etc. cases. (Though the thought of someone corking up a toll booth lane on a busy interstate to plug in a USB pen drive and download its source is somewhat amusing ...) The difficulty here is that in the arcade machine/toll booth case, the person who (IMO) requires source access to exercise his freedoms is the machine _owner_ or toll booth operating company, not the player or tollee. An arcade owner isn't going to allow me to upload hacked firmware to his machines (sadly :-). That's the it doesn't help argument: the argument that the distribution of source to end users doesn't actually give them the freedoms that the person who made the modifications had. It's been argued for web services, too. For example, Google providing the source to its database engine would be cool, but it wouldn't let me customize Google--only my own little useless copy of it, since I can't install my changes onto Google. How do you distinguish between an arcade user and someone using a web application? Is it the presence of a network connecting the two? I think that's an unnatural distinction. Both web users and arcade players are equally users; there are examples in both cases where providing source helps and where it doesn't. (I actually do know of arcade operators who have let players mess around with their machines. :) Also, web services aren't the problem, they're just the most common (today) example of a class of problems. Narrowing the restriction to web services means it's going to break down sooner or later, when a different incarnation of the same problem shows up. I think Josh's offering is a step forward in generalizing this. It still seems to cause fatal practical problems, though, hence my examples of toll booths and arcade machines. But, given the choice, I'd much rather see his version in GPLv3 than what's currently there. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Fri, Feb 10, 2006 at 07:21:44PM -0500, Anthony DeRobertis wrote: If that is were actually what they wrote, I think a lot more people here would be willing to accept it. E.g, they could have said: Any dispute arising out of or related to this Agreement shall be brought in the courts of the jurisdiction in which the defendant resides. However, they did not say that. This still affects claims made by the licensor against a licensee. On its face, it doesn't seem as big a deal, since it ends up near the licensee. But as a user of the software, merely using or distributing the software should not subject me, if I become a defendant, to the licensor's notions of correct venue law. Compare to: 6.5 This Licence is governed by the law of Scotland and the parties accept the exclusive jurisdiction of the Courts of Scotland to decide any action or claim directed against the Licensor. which is clearly only for claims against the licensor. However, the explicit naming of venue seems like a problem if the program is forked[1]. So, how about (IANAL): Any dispute arising out of or related to this Agreement against the Licensor shall be brought in the courts of the jurisdiction in which the defendant resides. (I'm not sure, however, if resides is a legally meaningful term, when the defendant isn't an individual.) [1] Message-Id: [EMAIL PROTECTED] and followups. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DSFG] question: Custom hand written notice
On Thu, Feb 09, 2006 at 06:19:45PM +0900, JC Helary wrote: License: The snow source code and the algorithms contained within it are free for non-commercial use. Licences for commercial single-customer applications will usually be granted free of charge, but contact the author for confirmation. Notes: (*)As of 29 May 1999 the source code has changed from being public domain to being free for non-commercial use. However, commercial users are automatically granted a licence for any use of the snow code and algorithms deployed before this date. Is it possible to take something that had been put in the public domain (ie copyright-less) and put a copyright and a license on it controling its use ? I don't think so. However, after releasing the work into the public domain, he can refrain from releasing further modifications. So, if you can find a copy of the program from before this date, or if you can take code from today and remove any changes made after it, it's in the public domain. (The latter is, of course, very difficult.) It sounds like he's saying: if you deployed before this date, then you can still use today's version commercially. It sounds like an attempt to be fair to people who had already deployed and were depending on the software, so as not to bait and switch. Of course, a license that doesn't allow commercial use is non-free. (Algorithms are not subject to copyright, though.) IANAL. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Wed, Feb 08, 2006 at 11:51:45AM +, MJ Ray wrote: Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Well, the discussion in March 2003 on debian-legal included the input of an ftpmaster who disagrees, so this definitely isn't a case of a fringe minority on -legal holding sway. That doesn't mean Debian can't reconsider debian-legal in 2003 *was* a fringe minority in itself. A fringe minority just because it didn't include Marco d'Itri, voice of the let-borderline-in extreme fringe... Instead, you can look at the archives and see the whole range, including RMS, James Troup, Ean Schussler, John Goerzen, Edmund GRIMLEY EVANS and more. Please stop repeating the fringe lie. -legal is open to all. It's just not easy to assert this is free here when it looks like it's not. He even claims[1] that the reason GR2004-003 passed was due to deception by the drafter--as if the topic wasn't the subject of thousands of mails in some of the loudest threads in recent Debian history, and as if developers are so gullible as to pass, with supermajority, changes to the foundation documents after only reading the subject line. I'm glad that's not the case; it prevents fringe minorities like Marco from sneaking through a GR to abolish the DFSG. It's also why I'm confident that the latest attempt to force non-free GFDL works into Debian will fail. His claims that d-legal isn't representative of Debian is particularly thin, given that he's essentially claiming that even a GR isn't representative. I guess it makes perfect sense, though, if you work from the assumption that Marco's opinion can't possibly be in the minority. Anyway, sorry for the noise. I figured I'd get my grumping about Marco done with for a while, and do it where it'd be threaded away with someone else's. [1] Message-ID: [EMAIL PROTECTED] -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [DSFG] question: Custom hand written notice
On Thu, Feb 09, 2006 at 05:12:31PM +0530, Mahesh T. Pai wrote: Jari Aalto said on Thu, Feb 09, 2006 at 01:08:19PM +0200,: Btw, is DSFG close to OSI approved or are there list somewhere that describes the difference? DFSG applies to software, `OSI-approved' relates to licenses. A package under a OSI approved licence *may* not be DFSG free if, for example, it includes a procedure which implemnts an actively enforced patent; or depends on a non-free software (eg. for compliation). Er. DFSG applies to the restrictions in effect on a piece of software. Most of the time, that means the same thing: the license. In practice, there are many licenses that are OSI-approved but are not DFSG-free, because the OSD and the DFSG are interpreted by widely different groups of people, with different goals and principles. (The interpretation isn't even close. As I understand it, OSI uses the OSD as a literal set of rules--a definition, which is in stark contrast to Debian's use of the DFSG as a set of guidelines.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Thu, Feb 09, 2006 at 01:28:57PM +0100, Florian Weimer wrote: * Mark Rafn: Is a work free if some modifications are permitted, but would make the resulting work non-free? Consider a program which is licensed under the plain GPL. You incorporate parts of OpenSSL into the program, under the standard OpenSSL licenses. The licenses are not compatible, which means that the resulting work is not distributable at all (but you still can run the software for your own purposes). You could argue that this case is different because you could reimplement the same functionality under a compatible license, so this is slightly different. But the example still shows that some kinds of modification can be prevented in a DFSG-compliant manner. This is showing that placing *restrictions* on modifications can be prevented. It is not showing that some *kinds of modifications* can be prevented. The ways in which the DFSG allows licenses to prevent what kinds of modifications I can make (and distribute) to a work is extremely limited (Those that are allowed are mostly about credit and licensing.) It does not allow saying don't remove code to send source or (in a related case) don't turn it into spyware, no more than it allows saying don't port this code to Windows. These are very different cases, based in two orthogonal principles of free software: people may turn your software into anything they want (even stuff that you don't like), and that you're allowed to say give everyone else the same freedoms that you received. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Wed, Feb 08, 2006 at 12:31:16AM -0800, Josh Triplett wrote: Although the interface is such that bit feels a little awkward, this is a step forward. If I use a source file from eg. Apache in a tiny embedded device, allow me to supply the source (that won't even fit on the device, never mind that the device has no I/O suitable for sending source) on an included CD. I'm assuming here that this tiny embedded device is not a product being provided to users, right? That case is already covered by GPLv2 and GPLv3 without the need for any clause of this nature: distributing a product containing GPLed code is distributing the GPLed code, and thus you must provide the source code, which you may on an included CD or via a 3-year offer. So you're talking about a tiny embedded device which interacts with a user but isn't distributed to that user? I was explaining why your clause is a step forward compared to if the work has code to send the source to the user, keep it incarnations. With theirs, if I adapt code from a webserve to a toaster, it's either impossible to satisfy the license or I have to keep broken code around. With yours, I can delete the code, and satisfy the requirements by including source on a CD. It excludes from users (still ill-defined) people who don't interact, which is an improvement. I'm inclined to say that we can leave users undefined here, and rely on the common-sense definition (people who use the software), because we're defining a particular set of uses, namely interaction. Even with the broadest possible reading of users, you still take the subset of those who interact with the software. It sounds like your definition of user is people who interact with the software, then? If that's the set of people you mean, maybe try avoiding the word user entirely. Then you can focus on defining interact. (But first: my examples were meant to show that even applying the GPL's source requirements to interacting users is problematic.) Well, to start with, it sounds like you agree that there's a subset of interact which is free, namely interact over a computer network. If you mean where it's free to require sending source, I'm not sure yet. I'm more inclined to think so based on this clause, which doesn't do so by placing restrictions on modifying the program itself. This makes me wonder: the draft GPLv3's clause talks about software which has the ability to send source *built into* the work itself. How is that useful? Why would PHP or a search engine or anything else of that nature have code to send the source? That's the job of the webserver it's running under! That alone would cover many of the cases people care about when they want this type of clause, so going with that option is worth considering. Going slightly broader, in most cases it doesn't seem particularly problematic to provide a 3-year-offer or a CD; in many of the cases, the source distribution mechanims must already exist in order to provide source to those who originally put those fixtures in place. But let's look at some of the examples I gave: What about supermarket self-check-out, ATMs, self-service gas stations, toll booths, voicemail, arcade machines? Software interacts with users in every way imaginable ... In my opinion, a player in an arcade, playing on an arcade machine, is both a user of the machine, and is interacting with the software. (That's my common sense, intuitive answer.) According to your clause, I'd need to provide source to the players, as if I'd sent them object code. Is that what you intended? It doesn't seem practical to me. All of my examples were of this nature. It easy to argue that a driver tossing quarters at an automated toll booth is a user interacting with the software, and so on. If I used code from your webserver in my voicemail system, what reasonable (eg. free) options would I have to comply with the license? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Wed, Feb 08, 2006 at 09:06:39AM -0500, Jeremy Hankins wrote: The only possibility that I can think of is to use an idea like public performance. I.e., if the work is publicly performed, source distribution requirements would apply. Public performance would probably have to be defined in a way that takes into account the purpose for which people are using the software (i.e., their primary purpose is to use the software, as opposed to using the software only to facilitate access to something else). A real example (from my own field) where this would cause serious practical problems is arcade machines. It's clearly public performance, and players in arcades really are using (and interacting with) the software directly. We include sources to GPL stuff on the machine's drive itself (though nobody cares, since none of it is modified except for the kernel, and that particular code is available on our webpage too). That's for the arcade operator (the owner of the machine). I have no idea how one might satisfy a requirement that the *users* be given GPL-like access to the source. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Thu, Feb 09, 2006 at 04:03:52PM +1000, Anthony Towns wrote: One way would be to supply a compactflash card slot that will burn the sources to a 1GB compactflash card. That seems a lot less outrageous today than it did three years ago, to my mind. Actually, our arcade machines are somewhat unique, in that they have an exposed USB slot, designed for players to plug in pen drives. However, it's still not reasonable to be storing source over it. If we do the logical conclusion, extreme case thing, we can have tens or hundreds of megs of source to store. These things are USB1.1; we can only send data at about 400-800k/sec. But that's a special case; more generally, I don't see any way at all of satisfying this for the voicemail, toll booth, etc. cases. (Though the thought of someone corking up a toll booth lane on a busy interstate to plug in a USB pen drive and download its source is somewhat amusing ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDE application relicensing
On Tue, Feb 07, 2006 at 10:04:23AM -, Regis Boudin wrote: I maintan a KDE application, so I have the pleasure of dealing with some GFDL data. Fortunately, the upstream author decided to relicense his work under a dual GFDL/BSDDL license, so it can be included in Debian. However, he is not certain about the wording, so I come here to ask your opinion on the subject. I know of no common license by the abbreviation BSDDL (and neither does Google). Please attach the license you're referring to. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDE application relicensing
On Tue, Feb 07, 2006 at 11:24:04AM -, Regis Boudin wrote: Oops, soory for that. He is relicensing under FreeBSD Documentaion License. I heve no idea where the BSDDL abreviation comes from. I'd still never heard of it; Google was able to find it, and I recognize it as a license that came up recently. See http://lists.debian.org/debian-legal/2006/01/msg00649.html . It's not a great license. I concur with Walter's explanation of the problems and recommendation to use a standard license instead of this custom thing. It's disappointing that FreeBSD uses a different license for documentation than programs, even though the spirit of the terms are identical. Why make things so complicated? Use the same license. I also notice that the list of forms in the one I found differs from the ones in the one we reviewed recently. The nature of this license is that it's likely to be modified a little every time someone uses it. Like the BSD license, it also requires the disclaimer text be modified, which is why I recommend the MIT/X11 license, which can be used verbatim. *** The FreeBSD Documentation License Copyright 1994-2005 The FreeBSD Project. All rights reserved. Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, Feb 07, 2006 at 02:10:23PM -0800, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. Although the interface is such that bit feels a little awkward, this is a step forward. If I use a source file from eg. Apache in a tiny embedded device, allow me to supply the source (that won't even fit on the device, never mind that the device has no I/O suitable for sending source) on an included CD. It excludes from users (still ill-defined) people who don't interact, which is an improvement. What about supermarket self-check-out, ATMs, self-service gas stations, toll booths, voicemail, arcade machines? Software interacts with users in every way imaginable ... -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, Feb 07, 2006 at 03:55:41PM -0800, Mark Rafn wrote: Should a smaller list than d-l be used for brainstorming this? I'm happy to join (or not, at your request, depending on whether my critiques are helpful or harmful), but I hesitate to spam d-l too much with it while working out the basics. Working on this on d-legal is fine. Ignoring threads you don't want to participate in is a basic mailing list skill, and pulling things out into tiny separate lists is a big hassle for those who do. (Personally, I'll follow the discussion on d-legal, and participate when I have something to add, but if it's on another list I probably won't follow it at all.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Mon, Feb 06, 2006 at 11:53:22PM -0500, Benj. Mako Hill wrote: I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. The GPLv3 having such a clause has no relevance to its freeness. A non- free restriction doesn't become free because the FSF decided to use it. That said, the draft does not have such a clause; rather, it says something like Affero-like clauses are not incompatible. That's unfortunate, and encourages people to do probably non-free things, but it's not non-free itself. Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. I've seen it said that its *goal* is to protect against behavior that is against the spirit of copyleft. Worthy goals don't make non-free things free. This means that we might be willing to accept a restriction that does this, if they get rid of the collateral damage, but nobody has yet offered an approach to this that does so. Even if there was some sort of rough consensus on the AGPL in the past, I think that we need to *at least* discuss this a bit more and and a bit more widely before we risk writing off some large future subset of GPL works as being non-free. It was just re-discussed recently, around the GPLv3 draft, I believe. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libgsm: right to distribute
On Sat, Feb 04, 2006 at 07:19:28PM +0100, Moritz Muehlenhoff wrote: Simon Neininger wrote: Copyright 1992, 1993, 1994 by Jutta Degener and Carsten Bormann, Technische Universitaet Berlin Carsten is my thesis counsellor, I'll ask him for clarification. I have no reason to believe that distribution is not permitted, though. It's probably intended, but the license doesn't say that. It's a common problem with people rolling their own licenses. It appears that a permissive license is wanted, and I'd suggest recommending the use of the X11/MIT license, rather than using a custom license. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP License for PHP Group packages
(Why is this being CC'd to d-d?) On Fri, Feb 03, 2006 at 12:06:32PM -0800, Don Armstrong wrote: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] [...] For example, I should be able to call my derived software TELEGRAPHPOLE if I want to, which contains PHP, but does not use the words PHP in a manner that would likely fall afoul of any trademark of the term PHP, which presumably the PHP group already has. As this goes farther than what DFSG 4 allows by dissallowing an entire class of names, instead of merely requiring that the software changed names when it is a derived version, it's non-free. See http://lists.debian.org/debian-legal/2005/12/msg00156.html This clause has been examined carefully in the past and deemed ugly but not non-free (at least, with no serious objections)--at least in the Apache, etc. cases. However, I don't think that should be extended to the general case; nor may 'net' appear in their name is obviously not free. It's an impossible line to draw, between PHP and Apache being annoying and net being completely unreasonable, which suggests that it really shouldn't be considered free. I don't know if it's a battle worth fighting now. Like patch clauses, there are so few of them that it's probably not that big a battle, but if you do want to fight that fight, I don't think PHP is any worse than Apache, so the objection should be extended across the others and not single out PHP. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpl and hosted apps
On Fri, Feb 03, 2006 at 02:52:41PM -0800, David M.Besonen wrote: does the gpl (v2 or v3-draft) address the issue of hosted apps? specifically, does the gpl prevent someone from taking code, modifying it, and putting it on a server and charging people to use the app without making the source available? GPLv2 does not. The GPLv3 draft attempts to. In my opinion, it does not do so in a satisfactory way, causing various practical problems. You can find discussions on the list archives, eg. http://lists.debian.org/debian-legal/2006/01/msg00213.html -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpl and hosted apps
On Fri, Feb 03, 2006 at 04:49:31PM -0800, David M.Besonen wrote: in the meanwhile, how would *you* word language in the gplv3 that would cover this loophole (that's what i would call it)? I'm not sure it's possible to require people running webservers with hosted applications to release their source, without causing practical problems as a side-effect. I'm undecided on whether I'd go as far as Mark in saying that the goal itself is non-free, but I havn't seen an incarnation yet without secondary ill effects. is there a general sense in the debian-legal community that modifying gpl'd apps and then hosting them without releasing the modified source is undesirable? That's a question of the goals of copyleft, which is something d-legal usually stays out of. We don't encourage copyleft any more than permissive licenses; they're both just fine. Similarly, we're not likely to encourage a super-copyleft that does what you say, above the GPL. We look at restrictions, and try to make sure that their restrictions are acceptable, but lack of copyleft is not considered a flaw. (Due to the fact that Free Software has a substantial number of people both of the copyleft view and the permissive view, this is the only way we can all get along. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP License for PHP Group packages
On Sat, Feb 04, 2006 at 01:49:06AM +0100, Francesco Poli wrote: Wasn't this issue solved in Apache License Version 2.0? The license, yes, but a quick look at /usr/share/doc/apache2/copyright shows some pieces that still use the old one. I havn't looked to see how much. If this is case, the most 'critical' package that still has this kind of non-freeness seems to be php... That's a matter of perspective, of course--Subversion is more important to me. (By the way, though I don't think it's currently critical to the thread, Subversion has the restriction nor may Tigris appear in their names. Tigris != Subversion.) And yes, I think it's a battle worth fighting, 'cause a DFSG-free PHP would benefit Free Software and Debian users, but PHP is not DFSG-free, currently... You're saying this is onerous enough to make it non-free (aka it's a battle worth fighting) because it's non-free. That's not a very persuasive argument. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP License for PHP Group packages
On Sat, Feb 04, 2006 at 12:32:25PM +1100, Andrew Donnellan wrote: That's a matter of perspective, of course--Subversion is more important to me. Ever heard of G/LAMP? (GNU/Linux, Apache, MySQL, PHP/Python/Perl) PHP has many millions of installations around the world, and is used by admins and even users a lot. SVN is used by developers or people who want to live on the edge, which I think is less than the number of PHP users. Maybe that makes it more critical to you. As I said, it's a matter of perspective. Having SVN packaged is also far more important in practice for me. If I want to use PHP, if it's not packaged, I install it manually once. If I want to host a project with subversion, and it's not packaged, then every developer on the project has to do so, which increases the threshold for attracting developers significantly. (Subversion is certainly not on the edge, by the way; it's a stable, solid, production-quality, 98%-complete replacement for CVS.) None of which is terribly important. Unless we're compelled against our will by sheer volume of fundamentally critical works, none of this affects whether the restriction is non-free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpl and hosted apps
On Fri, Feb 03, 2006 at 05:34:01PM -0800, David M.Besonen wrote: what ill effects would come of saying that if you host a gpl'd app (modified or not) you have to make the source available? I explained this in the link I gave you: http://lists.debian.org/debian-legal/2006/01/msg00213.html See under immediately obtain copies. The response was brief, since it's a whole subject unto itself that had been discussed at extreme length, but should give you an idea of the class of problems it presents. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Thu, Feb 02, 2006 at 01:49:59PM +0400, olive wrote: You seem to say that if a given license has conditions that would best be removed to benefit free software then the license is by itself non-free. But Debian does not choose the license of a given software; it just choose if will include the software in main or not. The question becomes if it would benefit free software if the given software is included. With this point of view including GFDL manuals in Debian would benefit free software since rejecting it would make a lot of free software unusable. The GNU project have accepted non ideal free software license on the same basis (for example the TeX license). The choice of whether to include a work is based on whether its license is free. The definition of free is based, ultimately, on whether it benefits free software or not. You're trying to bypass the process that determines that, by handwaving wildly and saying but anyway, who cares, it would benefit free software to make an exception for this thing and that thing. Sorry, but you're just not presenting any arguments that I think are worth spending further time debating. If anyone else thinks this has substance worth discussion, they're free to jump in, of course. Anyway, Debian will most probably continues to include GFDL and other non-ideal free licenses; it will just put these softwares in non-free. This will encourage more and more people to adopt software in the non-free directory (since you are in discordance with both the FSF and the open source movement; these people will include people from both movements) and will make the distinction between main and non-free pointless. It's unfortunate that you place so little value on free documentation, but that's your choice. I hope the free software community at large ultimately disagrees with you. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Thu, Feb 02, 2006 at 03:40:11PM +0400, olive wrote: the open source movement and the FSF): it is astonishing that licenses that does not follow the DFSG does follow the law of the open source movement which are exactly the same ones! So now we're being inconsistent because our conclusions differ from OSI's. I'd argue against that, but it's an argument that's been made, in various forms, a hundred times, and indicates a complete lack of background in the topic. I just can't be bothered. I place value on free documentation but not on your definition of free. GFDL can be modified, with the inconvenience of being obliged to include invariant section (which are non-technical). Wow--you're actually arguing that invariant sections are free? (I thought we were talking about the less blindingly obvious cases, like anti-DRM restrictions or choice of venue--too many parallel threads, perhaps.) This isn't a debated topic anymore; Debian agrees with me unambiguously (see GR2004-003). It's just next to impossible make a case, with a straight face, that a political essay attached to a technical manual that can't be modified and can't be removed is Free, and I have serious doubts about the priorities of anyone who's still trying. Finally, both the FSF and the much bigger open source movement agree with me (more modestly, I should say that I agree with them), not with you. With these absurdly strict policies, Debian eventually does not agree with itself: it's own logos cannot be modified! which show that these policies were not what Debian want at its creation. Using the logos as an argument is an act of desperation; I guess your next argument will be unmodifiable license texts, just to complete the set. (I'll stop wasting bandwidth with descriptions of exasperation now. I'd have held to my last attempt and not replied, but my exasperation quota filled and it had to drain somewhere. Sorry. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark policy for packages?
On Thu, Feb 02, 2006 at 05:06:19PM +0100, Florian Weimer wrote: There are no established policies, AFAIK. As long as trademark issues do not prevent creation and distribution of derivative works, or prevent an interoperable reimplementation, trademarks are outside Debian's scope. If Debian's inclusion of a trademark is such that users of Debian find themselves in violation in the course of exercising their DFSG freedoms, then the trademark is within Debian's scope. Now, many trademarks are simply the names of products, and Debian does permit requirements to change the name when modifying a work. So saying don't call it Subversion if you modify it[1] is allowed; Debian users expect that they might have to rename a work if they change it. But others are used differently. A piece of software in Debian might have been certified by Microsoft to be allowed to use the Windows XP logo. It might then do so in the documentation. (That wouldn't be fundamentally inappropriate in Debian; there's a lot of cross-platform software, typically with one set of documentation.) If the work is modified, the logo probably has to be removed. In that case, it should be removed in advance. People modifying software in Debian can't be expected to scour documentation for logos that need to be removed as a consequence of making a modification. Similarly, if the Debian swirl-with-bottle logo is trademarked, and says forks of Debian can't use this logo, then it shouldn't be used in main, since having to remove it would place too heavy a burden on modification. In practice, these conditions are still rare, so I think it's fine to stick with doing things on a case by case basis for now--I don't think we have enough experience in this area to formulate a general policy yet. [1] Subversion's actual renaming clause is in copyright, not trademark. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Squiz.net Open Source License - is it free?
other user, any of Your Modifications, You represent to Us that these are Your original work and that, as far as You are aware, neither it or its assignment, This is unacceptable. It's perfectly normal to modify a work by adapting the work of some third party. For example, I can adapt a permissively-licensed bit of code to the Linux kernel. I can't represent that it's my original work, because it's not. licence or use under this Licence or another licence on these terms infringes the intellectual property rights of any other person other than a patent identified by a notation made in the source code you have made available. Hold up. This is saying you represent that, as far as you are aware, your modifications don't violate any patents. That includes patents that wouldn't hold up in court, but due to lack of trying, havn't been struck down officially. 2.7 If the assignment in clause 2.4 is ineffective or does not occur for any reason, You grant to Squiz.Net a royalty free, perpetual, worldwide licence to use all intellectual property rights You have in all Modifications to the Software, including the right to grant licences to others on the terms of this or another substantially similar Licence. This does two things: - You grant us a license to your modifications, even if we never receive them. - The license we get is wider than this license--they can waive permissions, if they think the result is substantially similar. This is a gray, undecided area. I'd consider it in more depth, but there's so much else wrong with this license that it's not necessary. 2.8 You must Notify Squiz.Net within 30 days of making any Modifications even if You do not intend to distribute those Modifications. Notify is defined in Clause 4.2 below. If Your This is unacceptable. Copyright holders don't get to be all-knowing monitors of everything beying done with their software, and this is in basic violation of the Dissident test and the Desert Island test. 2.10 You are obliged to promptly provide a copy of any Modifications You make to any other party that requests a copy of Your Modifications and in a format reasonably requested by them. You may not charge any This is unacceptable, for similar reasons. 4.14 Termination This Licence and the rights granted to You by Squiz.Net, in particular those rights granted by Clauses 1.1 and 1.2, will terminate automatically if: (a) You knowingly fail to comply with its terms and in particular the terms of Clause 3.1; (b) You initiate or threaten legal proceedings of any kind against Squiz.Net; This is unacceptable. If Squiz.Net engages in blackmail, extortion or slander against me, DoS's my machine, or drives a truck up to my house and makes off with my car, I may initiate perfectly legitimate legal proceedings against them. They are not free (in a free license) to use their software as a lever to discourage my doing so. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Wed, Feb 01, 2006 at 01:45:49PM +0100, Yorick Cool wrote: Without taking a stance on the GFDL issue, I agree with the fact that Debian should be cautious not to go to far in it's assessment of licenses. In my view, a license can be free and yet not ideal, the two are different. And I feel that Debian should focus on freeness, not perfection. To me, copylefted licenses are better than non copylefted ones because they do more to advance the cause of free software, but it would be ludicrous to consider non copylefted licenses as non-free. Olive has a good point. Olive's argument seems to boil down to that, in order to avoid annoying people, Debian should - allow consessions (new restrictions that do not benefit Free Software; that is, a one-way exchange), if they appear minor. This is a chipping- away at the standards of free software, allowing more and varied restrictions to be placed on users. The burden of proof needs to be placed squarely on the people wanting to restrict us: explain to us why we should accept the new limitation, and how it benefits Free Software. (Copyright holders are a part of Free Software, too, and for the protection of the copyright holders is a perfectly legitimate end--since that means our protection, as developers, too. But these things need to be analyzed critically, to be sure that they really do what they purport to do, and do so without unacceptable negative consequences.) - ignore the corner cases that license authors tend to neglect. It annoys people when we point out uncommon goals that a license accidentally prohibits; collateral damage. An example is SMS messaging, which affects both make source available to users clauses as well as display this two-line acknowledgement to users for some overly-wide definitions of users[1]. Some people don't like dealing with cases they don't think they'll personally need, and it's easy to say I don't care about that when you're not the one affected. [2] Free Software needs to maintain its standards, avoid both the slippery slopes and the slow chipping, and prevent collateral damage. As far as I can tell, Debian is one of the very few organizations making any effort at this; the FSF, in my opinion, is doing very poorly at this. It would be a grave blow to Free Software if Debian was to give up. [1] http://lists.debian.org/debian-legal/2003/03/msg00369.html [2] There are some uses that Free Software acknowledges as being acceptable collateral damage, but these are always ones which are inherently incompatible with Free Software. We allow restrictions that prevent use on proprietary, closed systems where users aren't allowed to change anything, because those systems are--by design--incompatible with Free Software, and the restrictions preventing it benefit Free Software. This is not the case with most other collateral damage, such as SMS, where there is no such underlying conflict (though, of course, there is probably coincidental overlap between these two examples). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark policy for packages?
On Wed, Feb 01, 2006 at 09:18:10PM -0500, Nathanael Nerode wrote: Henning Makholm [EMAIL PROTECTED] wrote: Does the use of a trademark word to refer unambiguously to a specific technical protocol in package descriptions and documentation (that is, not in marketing materials) even require a trademark license? I know that it certainly does not in Denmark, but of course that does not say anything about the rest of the world. It does not in the US either, last time I checked. The legitimate purpose of a trademark is to prevent confusion about the origin of the good (or service), and this sort of usage doesn't cause confusion. Many trademarked logos are used a bit differently: sometimes with a license fee, or to indicate having passed a test suite, or some other kind of approval, like ESRB ratings. It's also to prevent confusion, but not regarding the product's origin. Of course, the same principle applies; I don't think trademark prevents me from saying this is the ESRB logo indicating 'Teen': img. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
On Tue, Jan 31, 2006 at 01:15:06AM -0800, Mark Rafn wrote: A human can tell the difference if he bothers to look. System software does not change behavior based on this human identification. Well, it might: if the software uses the human identification to select which font to use when rendering a document, it's no longer merely human identification--it's functional, too. That raises an odd (tangental) question, though. What if third-party software scanned output intended for the user; for example, refusing to run or changing behavior if the name of the software it prints isn't foo? Now it's impossible to make a functional drop-in equivalent without identifying differently. Same problem with any number of things required under the assumption that they're not functional: you could scan strings output for (c) Glenn Maynard if you don't like my code, or refuse to run if the GPL blurb is detected if you want to hinder GPL software. In practice, the only reasonable approach is probably intent. It's pretty clear that font licensors actually do want to prohibit me from modifying a font, distributing it, and having it drop-in over the original. That's a non-free goal. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark policy for packages?
On Tue, Jan 31, 2006 at 11:28:54PM +0100, Simon Josefsson wrote: Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira, and Zephyr are trademarks of the Massachusetts Institute of Technology (MIT). No commercial use of these trademarks may be made without prior written permission of MIT. The trademark is registered with USPTO: http://tess2.uspto.gov/bin/showfield?f=docstate=case6n.2.2 I am familiar with the GNU policies on trademark, and I am trying to adhere to them when possible. My question is: What is Debian's policy on trademarks for terms used in documentation and package descriptions? Do Debian require that certain usages of a trademarked terms is permitted to be included in Debian? I'm not sure what Debian's policies are; since trademark only infrequently comes up, I have a feeling they're a still bit unformed. This is just my impression of where things are today. Past discussions have come to the conclusion, I think, that a trademark license can't grant what Debian would require of a copyright license. That's because a license to use a trademark freely, in any way, would be equivalent to abandoning it completely. If Coke says you can use Coke(tm) to refer to anything, even Pepsi or ice coffee, they'd essentially be relinquishing their trademark completely. But, unlike copyright licenses, you can always escape a trademark license by not using it, and doing so doesn't prevent you from using the actual work. Debian even allows licenses to require that (DFSG#4). I'm not sure exactly where Debian should draw the line between a trademark license that should be preemptively escaped (by renaming the work upon packaging), and one that can be left. A trademark license that says you must pass our test suite before you're allowed to distribute anything with our trademark would obviously be among the former: Debian would simply not use the trademark. On the other side, Debian uses lots of trademarks, such as Linux, which are enforced, but under more lenient terms. I'm not sure about no commercial use of these trademarks. People sell Debian CDs all the time, and I don't know if that qualifies. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Mon, Jan 30, 2006 at 04:39:33PM -0500, Nathanael Nerode wrote: If it's not a copyleft: * the Scotland-venue clause in the original license only applies to claims against the original licensor of the original software * the French forker uses a license without that clause for his own modifications (perhaps with a French court clause). Suits against him, as licensor of the modified version, go to his French court. The result of this taken to the extreme, where lots of contributors from lots of different countries did this, might not become less free as such, but would become an unbearable mess (think 50 countries, with 50 choice of venue clauses, one for each depending on who you want to sue). (The next thought, of course, is replacing French with something like the home-country-or-something of the copyright holder, but that's a whole new ugly bag of worms.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Tue, Jan 31, 2006 at 12:52:00PM +1100, Andrew Donnellan wrote: On 1/31/06, Nathanael Nerode [EMAIL PROTECTED] wrote: olive [EMAIL PROTECTED] wrote: I personnaly think that Debian would do better to defend free software if there were in accordance to the FSF. I personally think that the FSF would do much, much better at defending free software if they operated in accordance with Debian. Debian-legal has proved better at guaranteeing the FSF's 'four freedoms' in practice than RMS, what with the GFDL and all. Let's face it: the FSF didn't create a full free-software system. Debian did. The FSF didn't even create the majority of the GNU project tools. Volunteers did, and many of them *disagree* with the FSF leadership. Discussions of the merits of FSF policy are forbidden on FSF mailing lists, with the exception of a few which appear to go to /dev/null. The FSF is, bizarrely, a top-down autocratic organization, with all the flaws that implies. Debian isn't, with all the benefits and flaws that implies. Let's face it: Debian wouldn't exist without the FSF. Maybe not. Neither would a lot of other things. That's a strawman that doesn't change where things are today. The FSF deserves respect for their part in getting us here, but not so much that they're exempt from critical review. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
On Sun, Jan 29, 2006 at 04:04:44PM -0800, Mark Rafn wrote: It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. I'd take this just a little further, in that the user shouldn't have to change his behavior, either. Filenames are part of the interface to the user, when they're binaries in the path (or symlinks to them, eg. alternatives). I seem to recall some renaming clauses that said don't name the binary 'foo', which went too far. (It's always a danger sign when licenses start talking at so technical a level as to mention things like filenames at all.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Sat, Jan 28, 2006 at 04:01:30PM -0500, Raul Miller wrote: On 28 Jan 2006 11:32:08 -0500, Michael Poole [EMAIL PROTECTED] wrote: I submit that, under this logic, fees to execute software or create derivative works are free since they are not mentioned anyhere in the DFSG. The usual response to this is that Debian would be restricted in doing things like porting software, fixing bugs, and so forth. The SC and DFSG make no mention of those tasks, either. I think that people who use the software constitutes a relevant group of people for The license must not discriminate against any person or group of persons. On that line of reasoning, people who don't live in California are, too. But we both know how weak arguing on DFSG#5 tends to be. I think the traditional argument is that restrictions on *use* of the software indicate an EULA, since simple copyright can not, in theory, restrict the use of software obtained legally. This implies that any license that restricts use requires a click-through license. Their implementation requires strict restrictions on distribution, to ensure that all recipients agree to it, and that falls widely afoul of DFSG#1. I think people who don't use the software and people who violate the license terms do not constitute relevant groups of people. I think people the licensor alleges violate the license terms are, however. Furthermore, I don't think the problem with this license is a problem with the license at all. It's that some people have a problem with the licensor. I don't think anybody is claiming that choice of venue is only non-free for Adobe. I don't think Adobe would want to expose themselves to that kind of risk, so I think we can take this license at face value. Harrassing lawsuits are the extreme case. It's a similar problem with, for example, honest but incorrect claims. I don't see why the licensor should get to override the venue in *any* case where he's the one instigating the lawsuit. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
On Sat, Jan 28, 2006 at 09:35:33PM +0100, Nicolas Spalinger wrote: 3) No Modified Version of the Font Software may use the Reserved Font Name(s), in part or in whole, unless explicit written permission is granted by the Copyright Holder. This restriction applies to all references stored in the Font Software, such as the font menu name and other font description fields, which are used to differentiate the font from others. Limited naming restrictions are permitted by DFSG §4. However, the naming restriction above is significantly more broad than the naming restriction that DFSG §4 was written to allow. (Earlier versions of the LaTeX Project Public License required renaming the filenames of modified versions so that they wouldn't conflict; that restriction has since been removed.) As such, it's likely that this clause will restrict the inclusion of works which have Reserved Font Names in Debian. This restriction only concerns the name of the font as it appears in a font menu and not the actual names of the files like in the older LPPL requirement you are referring to. The goal of the OFL is to avoid naming conflicts so that documents actually render as expected That's impossible to accomplish in a copyright license. I can take a completely unrelated font, rename it to your font name, and release it. Your copyright license can do nothing, since the font I'm using is not under that license. It takes a trademark to do this; copyright is ill-suited for it. (But, copyright licenses are free to try--within reasonable limits.) Users who install derivatives (Modified Versions) on their systems should not see any of the original names (Reserved Font Names) in their font menus, font properties dialogs, PostScript streams, documents that refer to a particular font name, etc. Again, this is to ensure that Font metadata might list similar fonts, to show in a dialog Fonts that look similar to This license prohibits this, since it says I can't use the original name *at all* in the derived version. It might also have metadata that says if you need a glyph that isn't present here, try getting it from the font named The license also prohibits this. (This isn't contrived; I've implemented a simple bitmap font system that did this.) I believe restricting these things is beyond what DFSG#4 allows. The in part is really meant to cover the case when there are various words used in reserved font names. If Foo and Org are both are RFN for the font Foo Org, any designer can branch and create his derivative but calling it Bar Org or Foo Inc is not allowed. The unit to consider here is the word and not the letter. If a font name is Times Roman, I can't create a derivative named Glenn Roman; worse, if it's Times New Roman, I can't name it Glenn's New Font? Again, trademark handles this much more gracefully, since it already has well-established mechanisms in place for determining things like confusingly similar. Trying to replicate this in a copyright license really isn't going to work. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Sat, Jan 28, 2006 at 09:32:12PM -0500, Raul Miller wrote: On 1/28/06, Glenn Maynard [EMAIL PROTECTED] wrote: Harrassing lawsuits are the extreme case. It's a similar problem with, for example, honest but incorrect claims. I don't see why the licensor should get to override the venue in *any* case where he's the one instigating the lawsuit. So what honest but incorrect claims does this license allow that could be problematic? In the sense of alleging specifc misbehavior. I meant: not only does this give the advantage to the accuser in the case of deliberate, hostile legal action, but also in the case of reasonable legal action where the accused licensee wasn't actually at fault. I'm just not seeing it. I'm just not seeing the defensibility of any lawsuits we instigate will be tried on our home turf, regardless of motives or the eventual outcome. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Sun, Jan 29, 2006 at 03:18:32PM +1100, Andrew Donnellan wrote: On 1/29/06, Glenn Maynard [EMAIL PROTECTED] wrote: I think the traditional argument is that restrictions on *use* of the software indicate an EULA, since simple copyright can not, in theory, restrict the use of software obtained legally. This implies that any license that restricts use requires a click-through license. Their implementation requires strict restrictions on distribution, to ensure that all recipients agree to it, I think DFSG#5 was written not because of this, but because of licenses that exclude some uses of the software, e.g. nuclear weapons factories, animal torture and things that people dislike. and that falls widely afoul of DFSG#1. ^^ -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Fri, Jan 27, 2006 at 10:35:44AM -0500, Jeremy Hankins wrote: We could, but does the DFSG require it? This is backtracking the discussion: we've already been over this. Message-ID: [EMAIL PROTECTED] There are other, non-malicious reasons for choice-of-venue, as others have pointed out. There are non-malicious reasons for releasing software under completely proprietary licenses. Good intentions don't make a restriction more free. Ah. I assumed (perhaps erroneously) that the choice of venue impacted the choice of law. I take it that the two issues are unrelated? I believe choice of law is uncontroversially considered DFSG-free, as long as that choice of law doesn't actually cause the terms of the license to become non-free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Fri, Jan 27, 2006 at 06:56:20PM -0500, Raul Miller wrote: On 1/27/06, Glenn Maynard [EMAIL PROTECTED] wrote: There are non-malicious reasons for releasing software under completely proprietary licenses. Good intentions don't make a restriction more free. Nor do bad intentions make a restriction non-free. Indeed, which is why we don't base our arguments upon intent, and which the tentacles of evil test fundamentally explains. Adobe might go nuts and harrass people is independent of any license provision. There's also little or no evidence that changing this jurisdiction clause would make the software any more free, even if we hypothesize that someone crazy at Adobe is going to start harassing users of this software using specious court actions, starting next week. There have been plenty of arguments why the choice of venue clause makes it easier and cheaper for Adobe to go nuts and harrass people, and I havn't seen a single argument why choice of venue shouldn't be restricted to claims made against the copyright holder. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Fri, Jan 27, 2006 at 10:29:27PM -0500, Michael Poole wrote: Raul Miller writes: What makes a restriction non-free is that it prevents some free use of the software. There's little or no evidence that requiring creators of a derivative of some software to identify themselves would prevent a free use of the software. Does that mean the Dissident test is irrelevant? Well, it would prevent that. Free use implies not having to do unreasonable things, or agree to onerous terms. That's why both the dissident test and choice of venue are non-free. Raul's definition doesn't help one come to either conclusion, though. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 11:37:14AM +0400, olive wrote: If that is what you think, you must first have the DFSG changed *before* declaring the license non-free. As long as the DFSG is not changed the license remains DFSG-free. A lot of people in this list, declare free or non-free software licenses following the fact they like the license or not and then say that is obviously non-free by the DFSGL; while the DFSG does not in reality. Both the FSF and the open source movement (the later use the same rules as the DFSG) declare choice of venue free or open source. You seem unaware of the way the DFSG works. It is not a fixed set of rules, but a set of guidelines to determine freeness. The DFSG can easily be interpreted very narrowly or very broadly. You can read it as you can't do this set of things, but anything else is OK; or, you can read you can't restrict modification as a strict, hard-and-fast rule. Both of them fail badly. An overly narrow view would make it useless; it would allow you must slay a tiger bare-handed to use this software. An overly broad view would also make it useless; it would prohibit even permissive licenses (eg. the discrimination clauses in the DFSG can apply to just about anything). Debian takes neither extreme interpretation. Rather, it looks at a restriction and, employing human judgement, decides whether it's an acceptable one to Free Software. At a high level, the question is, with respect to the license, can I reasonably exercise the freedoms the DFSG requires? The answer for Steve is no; in order to exercise his freedoms, he has to agree to a condition that makes him feel legally threatened. The choice of venue clause is very clearly a restriction on modification, since accepting it is a condition to receiving permission to modify the software. The question isn't whether the DFSG covers that (it clearly does), but whether that condition is acceptable. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 11:23:53AM +0100, Yorick Cool wrote: Well I obviously agree. My point was that the proposed interpretation was drifting so far from the DFSG that it wasn't arguable that it wasn't an addition and not a mere interpretation. A license that says to modify this software, give me $50 is obviously non-free; it's an unacceptable restriction on modification. A license that says to do anything in this license, give me $50 is obviously no less so. Similarly, saying to get any of the permissions of this license, you must agree to the choice of venue is a restriction on modification (and distribution, and maybe use), just as much as if it had said to modify the software, you must agree to the terms the choice of venue. This isn't complicated or contrived; it just means you can't circumvent the DFSG by applying restrictions as conditions to the license as a whole instead of to specific activities. (This isn't an argument for choice of venue being non-free, just that it's clearly something covered by the DFSG.) Bas So, how, according to you, does such a clause _not_ violate DFSG #5? The main argument to which I adhere, is flatly that such clauses don't discriminate against people at all. Let's see, what does I don't like most arguments based in DFSG#5 and #6. It's easy to argue that a choice of venue for California discriminates against people not in California, but it's just as easy to argue that requiring credit discriminates against people who like to plagiarize. I think DFSG#5 and #6 are intended for eg. Americans may not use the software and the software may not be used for stem cell research. When a restriction is non-free, there are almost always better arguments to be found, unless the restriction actually is of the above forms and falls under the spirit of DFSG#5/6. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 01:45:33PM -0500, Michael Poole wrote: Michael Thus it is a form of discrimination. It imposes costs (conditional, Michael but still costs) on some people that it does not impose on Michael others. As does every single license on earth, because you could be sued in a foreign country or not depending on the law of the land. Again, this is not something imposed by the license. The fact that a license is mute as to human rights or being able to use cryptographic software does not mean that it is non-free in countries that neglect human rights or that outlaw cryptography. Quite simply, a free software license should not attempt to correct wrongs that exist outside of the software. Well, I don't mind when they try to do that, if the attempt doesn't have negative side-effects. For example, in principle, I don't mind the anti-DMCA clauses. In practice, of course, they need to be scrutinized to be sure they don't have unintended negative consequences. It's those negative consequences that can make the license non-free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 10:31:25PM +0100, Yorick Cool wrote: It should be obvious that the silence of a licence is an implicit acceptance of the legal effects of laws it could have rejected. Since it could have changed those effects, by not speaking, the licence is taking a positive stance. Just like the silence of non-copyleft licences on any conditions for redistribution are an important feature -- not a bug -- of those licences. What a licence does not say is as important as what it says, and should not be dismissed as something totally unconnected with the licence. This would mean that any license that doesn't correct droit d'auteur, the DMCA, correct human rights violations, overrule laws preventing the development of cryptography, and disabling patents, is non-free, since in not trying to fix them, they're taking a positive stance? That's ridiculous. Michael The critical point that you are missing is that when a license doesn't Michael state a rule on a particular point, the default rules of law are de Michael facto incorporated in it. Hence it is absurd to consider non-free a Michael license because of a clause which shall have an effect very much Michael comparable to what a license whith no such clause would Michael have. (Obviously, this only applies if we consider the silent Michael license as free.) Michael Michael I do not miss that point at all; I think that the default rules of law Michael are preferable to the imposition of a forum selected by the Michael licensor. And why is that, if the effects are the same? Is it just out of some kind of irrational hatred of licensors? Unless the law says that the venue will be the home turf of the copyright holder in all cases, the effects *are not the same*. If the law says the venue is where the defendant lives, as someone claimed, then the law is clearly making a much more fair selection of venue than the license. If I sue Adobe, it goes to California; if they sue me, they come here. I have no problem with that. The license says even if we sue you, you come to California. That's the least fair selection of venue possible, with the defendant having to pack his bags and fly a couple thousand miles to face his accuser. You have failed to show any negative effects that come from the licences taking a stance on forum instead of not saying anything. We've explained the above a hundred times. Michael The fact that a Michael license is mute as to human rights or being able to use cryptographic Michael software does not mean that it is non-free in countries that neglect Michael human rights or that outlaw cryptography. Quite simply, a free Michael software license should not attempt to correct wrongs that exist Michael outside of the software. I totally agree. That is why I consider the burden imposed by forum rules, be they contractual (deriving from a license) or legal (deriving from a law) to be outside of the scope of free software to fix. They are wrongs (if indeed they are wrongs) which exist outside of the software as you put it. Which is why I don't want to make that question one which free software should address, and I don't view forum clauses as non-free. You are the one trying to fix something in this by rejecting these clauses. Uh, what? So now you're saying that any restriction in a software license that is outside of the software is irrelevant to freedom? A license that says you must apprehend a criminal is free? Sorry, but your arguments are becoming so strange and incomprehensible that I don't know how to respond to them, beyond expressing my bewilderment ... (No restriction *in the license of the software* is outside the software; when you say to have the right to use, copy and modify this program, you must agree to this condition, the condition immediately and obviously becomes Free Software's concern.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Fri, Jan 27, 2006 at 12:34:13AM +0100, Yorick Cool wrote: Glenn Michael I do not miss that point at all; I think that the default rules of law Glenn Michael are preferable to the imposition of a forum selected by the Glenn Michael licensor. Glenn Glenn And why is that, if the effects are the same? Is it just out of some Glenn kind of irrational hatred of licensors? Glenn Glenn Unless the law says that the venue will be the home turf of the copyright Glenn holder in all cases, the effects *are not the same*. It is very much possible that such is the case in some venues. In fact, I have a feeling it is the case somewhere, but I can't remember off the top of my head where. The only way the effects could be the same is if they were the same in *all* jurisdictions. Otherwise, it's not the same. The thing you keep missing and refusing to answer is that in the real world, there are laws saying approximately everything that is possible. So by default, some licensees will have to fly to California, and some won't. That is not an optimal solution. The situation with a choice of venue is not optimal either. Hence, nothing really distinguishes them enough to consider one situation as free and the other as non-free. Choice of venue is replacing the not optimal situation with the worst possible case; rather than only some people being forced to deal with a far-away jurisdiction, now every defendant has to. I don't see how that's an improvement. If it is a condition to enjoy the use of the software, then no. But in case you didn't notice, you don't have to fly to California to enjoy the software with the choice of venue clause. Agreeing to the condition--the choice of venue--is a condition to receive the license to the software. If you don't agree to the choice of venue, then you don't get the license. Any condition to receiving the license is a restriction on the permissions granted by that license, making choice of venue very much encompassed by the DFSG and within the scope of Free Software's concern. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 11:42:22AM +1100, Andrew Donnellan wrote: On 1/26/06, Francesco Poli [EMAIL PROTECTED] wrote: In a nutshell, this choice of venue discriminates against people who live far away from Santa Clara County, California, USA and thus fail DFSG#5. Those people can be forced to travel around the planet in order to defend themselves in a dispute raised by the copyright holder. Personally I think choice of venue clauses are reasonable, because it only discriminates against those who have broken the license. No, it discriminates against those who Adobe claims have broken the license. That's completely different. Also I don't think Adobe is going to sue you for a minor violation. This is called the tentacles of evil test: the license must be free, even if the copyright holder becomes hostile. Even if the copyright holder has an upstanding legal reputation, the license can't depend on that; copyright and companies can change hands. They could, for example, interpret the license in an unexpected or contrived way (as, for example, UWash did with Pine), and sue users (which, for clarity, UW didn't do, AFAIK). In that case, choice of venue clauses may place an undue burden on licensees; even if the interpretation doesn't hold up in court, they have to travel to prove it. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 09:23:03AM +0400, olive wrote: In a nutshell, this choice of venue discriminates against people who live far away from Santa Clara County, California, USA and thus fail DFSG#5. Those people can be forced to travel around the planet in order to defend themselves in a dispute raised by the copyright holder. I am not at all convinced. First, I wonder if this choice of venue is legal. If it's not legal, or not enforcable, that doesn't make it any less non- Free. If it's really known to be unenforcable, then the copyright holder should be willing to remove it from the license, and prevent the confusion (and misleading claims). Personally--speaking for my own particular case--I don't care about flying around the world; flying from Massachusetts to California is quite too far. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 10:08:34AM +0400, olive wrote: If it's not legal, or not enforcable, that doesn't make it any less non- Free. If it's really known to be unenforcable, then the copyright holder should be willing to remove it from the license, and prevent the confusion (and misleading claims). The other argument is that even without this choice of venue; Adobe could sue you in a Californian tribunal (am I wrong?, what could prevent Adobe acting in this way); so I do not see what are more inconvinient with this choice of venue. There are laws in place for determining the *appropriate* venue. If California really is the appropriate venue for the suit, as determined by the law, then that's fine. If the appropriate venue is Massachusetts, or somewhere else, then that's where it should be. Choice of venue attempts to override this mechanism, to always favor the copyright holder. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Thu, Jan 26, 2006 at 01:18:55AM -0500, Nathanael Nerode wrote: To be more specific, we generally consider choice-of-venue non-free when it applies to suits brought by the copyright holder (/licensor) against other people. It's free when it only applies to suits brought by other people against the copyright holder (/licensor). I think I agree, but I don't know of a license brought here that actually does this--I don't think it's been discussed. Know of any examples, so we can wave it around for a while and maybe conclude this for certain? Being able to give an alternative to a general choice of venue clause that is uncontroversially free might go a long way towards fixing the problem. (I don't know enough about venue selection to know if countersuits are a problem; for example, if the result would be that when Company X sues me in my own venue, and I countersue, I have to take it up in an a completely different venue. I just don't know enough about venue selection to answer this case.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Tue, Jan 24, 2006 at 12:24:04PM +0400, olive wrote: If this causes problems, you can always elect to not mention the use of the software in advertising. That's annoying, but accepted. There's no such escape with front- and back-cover texts. It's also not at all obvious to me how accepting acknowledgements in advertising implies that this consession should be extended to everything else. Covers on a book? What next; is requiring that software pop up a dialog every fifteen minutes to say my name free? It's just this sort of wedging, saying we allow this, so we should allow this, too--and wait, now we should allow this other thing too, it's just a little more!, that will destroy Debian as a free system. (And cover texts would not be a small concession at all, but a very big one.) That is at least an elaborate argument. That's not elaborate, it's straightforward and obvious. (The argument was three sentences; the rest was simply exasperation at people's constant attempts to widen the scope of restrictions Debian will accept.) I personnaly think that Debian would do better to defend free software if there were in accordance to the FSF. Debian has made it clear that documentation must follow the DFSG, requiring the same standards of freedom as other software (GR2004-003). The FSF has made it clear that it does not believe documentation does not need the same freedoms as software, and has even agreed that the GFDL is not a Free Software license. This is a concluded debate: Debian and the FSF are in disagreement regarding standards of freedom for documentation. I'm glad that Debian stuck to its standards, and didn't allow them to plummet merely to follow the FSF's standards into the grave. It is not in Free Software's interests to be in accordance to the FSF without thought, and it is meaningless for Debian to have any standards at all if the FSF has veto power. Having DFSG-free and FSF-free software which are not the same just confuse the user and make the distinction between free / non-free less pertinent (a software won't be non-free anymore, it just will be non-XXX-free, where XXX is a small group of person). I still think that If that's what you believe, propose a GR to abolish the DFSG. demand even a little more. But I still think that Debian does more harm to the free software by purely rejecting the license. Debian have accepted as DFSG-free licenses which are, in my opinion, much more inconvenient that GFDL: I thing of the patch close of the DFSG4; I hope you're not saying Debian allows patch clauses, so it should allow other things too. It's one of the worst imaginable examples of what I just said: taking (in my opinion) the worst consession the DFSG has made, and using it as a wedge to try to get even more onerous restrictions allowed. (That means that not only are we suffering for the consession made, we're suffering people using it to try to push even further.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 12:17:24PM +0100, Wouter Verhelst wrote: With respect to that freedom GPL is also non-free. It is not. See below. Anyone arguing for invariant sections by pointing to license texts has missed all of the prior discussions on this topic, going back years. Given the quantity of discussions around the GFDL topics, it's not too surprising that people would miss parts, but as the topic has been done to death, I suggest merely referring people to those conversations. Mostly found googling for 'site:lists.debian.org debian-legal license texts unmodifiable' and variants: 2001: http://lists.debian.org/debian-legal/2001/11/msg9.html at [1] 2002: http://lists.debian.org/debian-legal/2002/12/msg00067.html 2003; http://lists.debian.org/debian-legal/2003/10/msg00033.html 2004: http://lists.debian.org/debian-devel/2004/05/msg00370.html 2005: http://lists.debian.org/debian-devel/2005/04/msg00625.html (removal or modification) This is just more wedging, trying to abuse the fact that Debian allows invariant license texts to squeeze in other invariant stuff. I would suggest anyone engaging in such wedging carefully reevaluate whether what they're doing is really in the best interests of Debian; or whether they're just trying to contrive a way to pound Debian into agreement with the FSF. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Tue, Jan 24, 2006 at 10:52:56AM +0400, olive wrote: Fabian Fagerholm wrote: Works licensed under the GNU Free Documentation License, version 1.2, as published by the Free Software Foundation (GNU FDL), are free in accordance with the Debian Free Software Guidelines (DFSG), if and only if the work is licensed using the following options of the license: Tell some Debian Developers that black is not white and that pi is not 3, and they demand a vote ... I still don't understand how Debian can consider free the advertising clause of the original BSD license and not accept something very similar for the GFDL? This has in the past make the object of long flame but I never had any answer. So I ask again. If something has been already said about this specific question (why the difference between the original advertising close of the original BSD licence and the GFDL), please give a reference The advertising clause is: All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. If this causes problems, you can always elect to not mention the use of the software in advertising. That's annoying, but accepted. There's no such escape with front- and back-cover texts. It's also not at all obvious to me how accepting acknowledgements in advertising implies that this consession should be extended to everything else. Covers on a book? What next; is requiring that software pop up a dialog every fifteen minutes to say my name free? It's just this sort of wedging, saying we allow this, so we should allow this, too--and wait, now we should allow this other thing too, it's just a little more!, that will destroy Debian as a free system. (And cover texts would not be a small concession at all, but a very big one.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anti-DMCA clause (was Re: GPL v3 Draft
On Fri, Jan 20, 2006 at 09:49:09AM -0800, Walter Landry wrote: I think that effective does not mean perfect. Having a police force is an effective way of combatting crime, but it is far from perfect. A security mechanism which has been defeated by a piece of software is not imperfect. If I post my root password to this list, it is not an imperfect but still effective security mechanism; it is useless and defeated. (It seems to me that the real goal of this law is so that once a security mechanism is defeated, and is no longer effective, the real security mechanism becomes the law itself: by pretending that the obsolete mechanism is still effective, the deterrent becomes the threat of prosecution, instead of actual security.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anti-DMCA clause (was Re: GPL v3 Draft
On Fri, Jan 20, 2006 at 10:30:29PM -0500, Jeremy Hankins wrote: If you want to be charitable, you might say that effective here is being used in the sense of effectively, it's a security mechanism. But whether you want to be charitable or not, it's clearly not being used in a way that requires the mechanism to be robust. I thought about effectively, but that just means in reality. If I post my password to the internet, it is no longer, in reality, a security mechanism. In any case, it's not my interpretation, or a rational interpretation, that counts, it's the court's--which was my original point. Evaluations of anti- DRM clauses need to bear in mind the reality of the laws, not just the literal word. Walter says, I think, that merely stating GPG isn't an effective encryption software doesn't make it true. That's so--but if it's not actually the effectiveness of the security mechanism that the law cares about, but something else (such as stated intent), then the apparent simple untruth of the statement may not indicate that it won't be effective (and taken in context of the interpretation of the law, may not be untrue). If the authors of the statement have done some research into this (which I would hope), it might be interesting to hear their rationale in more detail, even if it's we don't know if this will work, we're just throwing darts at the courts (which is fine with me, as long as the clause seems harmless). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft
On Thu, Jan 19, 2006 at 07:53:46AM +0100, Arnoud Engelfriet wrote: Nathanael Nerode wrote: Effective technological protection measure is supposed to mean Effective technological protection measure for preventing copying or distribution. I think the DMCA actually speaks about access to the work (17 U.S.C. 1201): (2) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that-- (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; This doesn't even make sense. If a measure effectively controls access to a work, it's not possible to create technology to bypass it; conversely, if it's possible to bypass a control measure, then it is, by definition, ineffective. GPG is effective because it can't be reasonably bypassed; if someone successfully wrote a program to decrypt its files, then it would obviously no longer be effective. (Of course, laws and courts have free reign to interpret words in any way that suits their agenda, so effectively probably really means pretends to ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anti-DMCA clause (was Re: GPL v3 Draft
On Thu, Jan 19, 2006 at 01:58:08PM -0800, Walter Landry wrote: Accordingly, no program licensed under this License is a technological measure which effectively controls access to any work. Again, writing this sentence into the license doesn't make it true. It is decided by external factors, such as whether the people implementing the scheme know how to do decent crypto. There seems to be some rift between the law and reality, though. If the law is taken literally, it's a no-op: it forbids writing software that can't be written (if you write software for an effective protection scheme, then, well, it's not effective). If the law is being enforced anyway (which it is, of course), then it's being interpreted to mean something a little different--where effective means something other than what it does in English. In that case, anti-DRM clauses, and evaluations of their potential effectiveness, need to be done while under the influence of the courts' private version of the language. (Unfortunately, I don't speak that language ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft
On Mon, Jan 16, 2006 at 11:52:43PM -0800, Don Armstrong wrote: Eben had a really humorous explanation, which I will attempt to paraphrase from my (impressively imperfect) memory: No lawyer knows exactly why we have been shouting at eachother for the past 50(?) years; but since everyone is shouting, everyone thought there must be some reason. I've decided to take take the initiative and return to mixed case, ending the endless shouting match. FWIW, I just noticed on http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dx8_vb/directx_vb/graphics_iface_vb_9202.asp a small warranty disclaimer that's not screaming: Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. However--and this may be significant--the text is colored red. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
On Tue, Jan 17, 2006 at 07:18:10PM -0800, Steve Langasek wrote: But in that case, you might find it more fruitful to discuss this clause with the FSF itself rather than with debian-legal. Well, I'm not discussing these things here to try to get the weight of this would make Debian call the GPLv3 non-free, since the GFDL showed just how much weight that holds with the FSF. I do want to know what others here think about these things, though, and to let anyone who agrees with these things to lend their voice to fixing them. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
