Re: swirl infringement by electrostore.se
I haven't been seeing my mail on debian-legal lately, maybe I have some email troubles.. hopefully the CC will get through, though. (Gerfried, if my email to debian-legal doesn't get there, would you kindly forward it there?) Gerfried Fuchs [EMAIL PROTECTED] writes: Any news on the case of the swirl they have in their logo? I can't see any trace about this at all, the last question on this topic still stands unanswered (from what I can see). It looks like noone seems to care about this rip off at all and I don't know where Sunnanvind Fenderson too the following from: ,- quote - | the company using the logo, elektrostore, said something to the effect | of for all we know, it could be some clipart or font image that Debian | just used, didn't invent `- quote - I got this from this comment: http://www.gnuheter.org/article.php?sid=1669typ=0mode=flatorder=1thold=-1#7830 where an anonymous gnuheter-reader quotes a mail from Elektrostore. Vi var dock inte medvetna om denna liknelse. Vi har inte själva gjort logotypen, vi ska ta kontakt med de som producerat sajten och fråga var de fått snurren ifrån. Sajten är dock gjord så tidigt som 1999 och företaget (Gula Interactive Trader AB) som gjort detta finns inte längre. Det är dock inte säkert att snurren är gjord av Debian heller, förmodligen är det en del i ett typsnitt eller liknande. Vi tackar för denna information! Translation: However, we were not aware of this similarity. We didn't do the logo ourself, we'll contact with those who produced the site and ask where they got the swirl. However, the site was made as early as 1999 and the firm (Gula Interactive Trader AB) that made it is defunct. However, the swirl isn't necessarily made by debian either, it could be a part of a font or similar. We thank you for this information! No news on this issue since then, and Elektrostore still uses the logo. Have you talked to Raul about the issue? I hope to see the issue resolved and, now that you remind me, I think it's weird that Elektrostore *still* haven't changed their logo. Sunnan
Re: motion to take action on the unhappy GNU FDL issue
Well, listening to Georg Greve it sounded like the FSF wanted an official statement from Debian regarding the problems with non-removability of invariant sections. In my very humble opinion, Debian should try giving them that before taking (what would appear to be) the more hostile actions suggested by you. Sunnan
Re: Fw: Stolen debian twirl at www.elektrostore.se
This issue has been brought up on debian lists before, iirc. I seem to remember that the ad agency that produced that logo has long since folded (and the company using the logo, elektrostore, said something to the effect of for all we know, it could be some clipart or font image that Debian just used, didn't invent). I don't remember what happened after that, anyone care to refresh my memory?
Re: EULAs and the DFSG
Glenn Maynard [EMAIL PROTECTED] writes: And if they put users through a click-wrap license, but don't require it on redistribution, there seems to be no point. I have trouble figuring out clause 2 in the APSL, specifically point 2.2.c. (I've seen some slightly confused Windows installers for GPL programs with a click-through containing the GPL. No real harm in that, I think, but it's unnecessary.) I personally think that that harms (if ever so slightly) the image of the GLP as being more free than copyright.
Re: EULAs and the DFSG
Andrew Suffield [EMAIL PROTECTED] writes: On Wed, Dec 04, 2002 at 03:11:25AM +0100, Sunnanvind Fenderson wrote: Anyone willing to clear things up? Sure. EULA is marketdrone speak for a license permitting actions involving a copyrighted work. It's the content of those licenses that matters. Any association you may have between the term EULA and non-free licenses stems from the absence of marketdrones in free software development. Because I've always read EULA as end user license agreement, as something the _end user_ has to agree with before using the program, as opposed to distribution licenses like the GPL.
Re: EULAs and the DFSG
Jakob Bohm [EMAIL PROTECTED] writes: Click agree to accept this license and the lack of warranty. Click decline to not use, copy or distribute this software. The main problem is that that's simply not true - you _can_ use the software without accepting the license[1]. If you want to copy or distribute software, copyright legislation won't let you, and that's when you need the license. This is very different from EULAs because with them the end user gets *less* rights that normally given by copyright, so they have to start entering contract law or the like. (And as been pointed out, click-wraps seems to be a very fuzzy area legally, currently. Are they void? Valid? Are certain clauses void?) [1]: I guess you'll have to acknowledge the lack of warranty (and in the case of future versions of the GPL, the patent situation).
EULAs and the DFSG
I started thinking on the Apple license again. Unlike the GPL, which is a copyright license, it appears to be an end user license agreement which you have to agree with prior to downloading the code or something like that. As far as I can see, this has the potiential for violating FSF freedom zero. The OSD doesn't seem to have a clause against this (and they even have the Apple license on their approved licenses list), and neither does the DFSG. However, the license has been considered a non-free license on this list in the past. While I agree with the sentiment against EULAs rather than copyright licenses, I'm concerned because I can't find the appropriate section in the DFSG against this. Anyone willing to clear things up? Sunnan
Re: Obnoxious ad-clause strikes again.
Steve Langasek [EMAIL PROTECTED] writes: On Mon, Jul 29, 2002 at 10:03:50PM +0200, Sunnanvind Fenderson wrote: I know some people who're thinking of moving their proprietary products to GPL instead, but they want to be able to link to some jakarta jar-files. (obnoxiously ad-clause-licensed, iirc) I suggested using the GPL with an exception clause (since the company is sole copyright holder of the software at the moment). b) Would they be allowed to link to real GPL stuff like the readline library? They wouldn't be able to include GPL-ed code in their GPL-ed (with exception) code, right? Only the copyright holders of libreadline can grant a license exception to link their code against GPL-incompatible code. This likewise applies to any other GPL code that they do not hold copyright for. Okay. But program X, licensed under GPL-with-exception can link to both jakarta and to GPL-ed stuff. Can it link to both at the same time? No? This being written in java complicates things even more. They link to Suns standard java libraries, also. Mmm, AFAIK the Java ABI is fairly well standardized; if the features they need are also available from a GPL-compatible jre implementation, then this should be technically indistinguishable from linking against Sun's Java classes. Okay. I think they'll look into this, then. If their code can't be built against the free Java class implementations, then it's definitely not possible for anyone to provide binaries referencing other GPL code. However, this is probably secondary to the use of the GPL-incompatible Jakarta code. Of course, they can allow others to do anything they want to allow with /their/ software (including things not normally permitted under the GPL if they grant a license exception). ISTR that someone was working on a BSD-licensed reimplementation of libreadline, btw. Yes, libeditline. But readline was only one of the examples. We'd really like this company to become a free software company, and one of the many selling points is that they would get access to a huge codebase of copylefted code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Obnoxious ad-clause strikes again.
Steve Langasek [EMAIL PROTECTED] writes (when he's not postmodernly making delirium-frogsies): But program X, licensed under GPL-with-exception can link to both jakarta and to GPL-ed stuff. Can it link to both at the same time? No? It cannot link to both at the same time, as this would violate the license of the other GPL code. I was afraid of that. If their code can't be built against the free Java class implementations, then it's definitely not possible for anyone to provide binaries referencing other GPL code. However, this is probably secondary to the use of the GPL-incompatible Jakarta code. Of course, they can allow others to do anything they want to allow with /their/ software (including things not normally permitted under the GPL if they grant a license exception). ISTR that someone was working on a BSD-licensed reimplementation of libreadline, btw. Yes, libeditline. But readline was only one of the examples. We'd really like this company to become a free software company, and one of the many selling points is that they would get access to a huge codebase of copylefted code. Only if their code can be made to not depend on GPL-incompatible code. This is one reason why the GPL has not been a big seller in the Java community. :) Any other suggested solutions? Thanks for all your help, anyway. I'm sure this will be resolved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [hpoj-devel] Bug#147430: hpoj: Linking against OpenSSL licensing modification (GPL)
Remember that hoopla a while ago about license texts themselves not being DFSG-free? Well, isn't it the case with this program? Did someone give -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [hpoj-devel] Bug#147430: hpoj: Linking against OpenSSL licensing modification (GPL)
Uh, I just posted an incomplete version of this mail to debian-legal. Sorry. I hit C-c by mistake. I tried to say huh, did someone give express permission to distribute modified versions of LICENSE.OpenSSL, because that's what's needed if anyone was going to change it. but then I realized that copyright can't stop people from distributing files under that name, so just ignore this entire mail, I'm going to eat something now, maybe that'll make me saner. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-US definition
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Matt Kraai wrote: * it contains cryptographic program code which needed to be stored on a non-US server because of United States export restrictions, or This is no longer true. So how should people in like, France, act with regard to crypto? (I guess the answer is check on a package-by-package basis.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New CUPS license violates DFSG 6?
Sam Hartman wrote: It means that Apple does not need to include source for anything with their primary OS CDs. Apple is trying to avoid anything GPLed or LGPLed in the parts of the OS they pre-install. There of course GPL and LGPL components in the developer tools. If I remember correctly, there was a version of GNU Emacs shipped with Mac OS X 10.1. --- --- My take on this is that; well, non-copyleft free licenses like the X license are usually GPL-compatible because anyone can make a GPL:ed fork. This licence, as written, would not be GPL-compatible (I think), and wouldn't we be happier with a dual licence situation? Like You may distribute this under the terms of the GPL, or, if you're an Apple developer... This license seems DFSG-free, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel's drivers license
Walter Landry wrote: This rather long paragraph means that I can't take out some code covered by patents and use it to extend my favorite text editor. That would count as an additional restriction, and thus GPL-incompatible. Well... Patents normally mean Hey, hands off this. This patent license grants an additional *permission*, to use the patents in certain software. This is different from the real-time Linux patents, which allow for any implementation as long as it is under the GPL. I agree, that would be better. This is a lot more restrictive. I'm still not sure that it's GPL-incompatible or DFSG-nonfree, though. It *is* an added permission rather than added restrictions, right? What does the GNU folk say? Sunnanvind (I don't like patents.)
Re: license requirements for a book to be in free section
Marcus wrote: On Fri, Feb 01, 2002 at 03:22:18PM +0100, Sunnanvind Fenderson wrote: Though the four freedoms of the FSF is a political statement. These are rights everyone should have when it comes to functional software - they're easily understandable and they're useful for advocacy and explaining free software. Well, Debian is a political mvovement, and I don't think there is much disagreement about those particular freedoms. Sure, but my point was that the four freedoms are fine for the advocacy/explaining part but (possibly, I'm not certain) too vague to be useful as the *only* guidelines for debian-legal. I.e, freedom to redistribute copies. A license that would only allow distribution of software non-commercially would be unusable for Debian, but using only the four freedoms, there's seemingly nothing wrong with such a license. Note that RMS in his explanation of the four freedoms at http://www.gnu.org/philosophy/free-sw.html does state that commercial redistribution has to be allowed. This helps make my point (err, I think) that the four freedoms, as written, are not complete legal guidelines that cover every case. They're still great and I agree with you, software that doesn't have the four freedoms are not free software. Still, the DFSG are a lot more detailed (or, tries to be). Also note that RMS has said (if I recall correctly) that he does not think that freedom 3 is necessary for non-functional works. (E.g. the GNU manifesto.) Actually, I don't believe it (although I am not sure, as I have no special insight into such matters). The guidelines are pretty clear, basically, and RMS had an amazing consistent stance upon these issues since a couple of years. In corner cases, the matter is discussed and it seems to me RMS makes a final decision. Huh? Don't they have like, an elected board or some kind of democracy? I think the four freedoms come closest to a definition of free software as you can get. Agreed. What I'm unsure of is whether that definition is detailed enough to work consistently as guidelines for debian-legal. Issues like patents and other funky stuff are in the process of being worked out (some of this work will go into the GPLv3, IIRC). So I hear. Here's to hoping that they deal with trademarks too - there's been some nasty stuff like the d20 STL coming up lately. You can say what you want about the FSF and RMS, snip stuff I knew Oh, I'm not interested in saying anything negative about them, I hope to make that clear. I am a very big fan. I agree with most everything RMS has written and I constantly refer people to Moglen's Anarchism Triumphant (it's one of my favourite essays). I certainly agree with the statement that all published software should be free. Sunnanvind.
Re: license requirements for a book to be in free section
Marcus wrote: Right, RMS changed his opinion on this license shortly before the debate happened here. So I noticed. That's how it goes, sometimes. Which is interesting, because I tend to disagree that it is free, but oh well ;) In my (previously stated, for those keeping count) opinion, it had the same problem as the Apple free license, which inconsequently enough is and was listed as non-free the whole time. I'm glad the issue seems resolved now, as I too disliked the sending-in-the-patches requirement. The old BSD (obnoxiuous ad clause) is and was listed as free (but GPL-incompatible), while it's been considered DFSG-nonfree. It is? I am surprised, because I think I remember that we used to distribute BSD licensed software in Debian before the ad clause was removed? Or do you mean that only afterwards it was considered nonfree? Actually, someone (I guess I'll have to do it) needs to check this up. I think it was brought up during the Zope discussion and during the discussion of that program that messed up spambots (name escapes me at the moment). Note: I am happy with software that has such obnoxious ad clauses being considered DFSG-nonfree, I just try to remember how it used to be. While I think that the required powered-by-button of zope is dreadful, I don't really have much of a problem with the old BSD-ad clause, and I don't really see how the DFSG is interpreted to make that non-free (that's why I think I might be in error when I seem to recall that it's been called non-free). It's very obnoxious, though, and we're all better of without it. Well, it is a fact that it tries to be more detailed and fails. However, I think the reason was the Debian left GNU and then probably felt the need to establish their own independent rules. Which is a pity because the differences are so small, and a lot of effort is put into discussing such issues, which could simply be saved by following the FSF's view on it, plus maybe documenting exceptions where they are truly wanted. Then we only would need to argue about the differences. This would have the additional effect of making the differences transparent. I agree with you about only arguing about the differences instead of seemingly different things that in reality is exactly the same. (NB: I also see Branden's point when he says that we should not just blindly accept everything the FSF says. I do disagree with some of his arguments against the FSF, though. Or something.) Though the four freedoms of the FSF is a political statement. These are rights everyone should have when it comes to functional software - they're easily understandable and they're useful for advocacy and explaining free software. Debian needs more detailed guidelines (that's why I was somewhat involved the recent attempts to clarify the DFSG wrt invariant sections) in order to make consistent, understandable judgement about what goes into non-free and what goes into main. I figure that the FSF have some long, opaque guidelines hidden in their vaults somewhere that their lawyer(s) use to decide what goes on the free-list and what doesn't. Needs is in quotation marks because sometimes I'm in an extra eristic mood and feel that all the politics is a waste of time and we should just distribute and package up all the software we want to without being subject to their (copyrighters) rules, which is arguably all make-believe anyway. Other days I find that it would be better to beat them on their terms and so those days I delve into politics and licensing issues and clarifying guidelines. I'm not very consequent. Sunnanvind (headache and hungry and mad at school. Hope it doesn't shine through.) Didn't notice until now. Food, sleep and hacking should help :) Yeah, it did for a while, but then I slipped on the icy roads in the port and hit my head in the asphalt, so I'm a bit shaken, and I've been involved in the nastiest polygonal relationship drama ever, meanwhile I have to learn all of the SMTP and pop3 protocols for school (sounds easy, but I've never read an RFC before). My life is a soap. I'm a whiner. I'll shut up now. Thanks and aehiilrs, Sunnanvind
Re: license requirements for a book to be in free section
Marcus wrote: No. There have been several cases in the past where we include and the FSF exclude, and none I am aware of where it is the other way round (although the GFDL might become such a case). The vim license was listed as a free license on gnu.org while debian-legal debated it. (A debate I personally thought was worthwhile and I agree with the arguments brought up by people here.) The old BSD (obnoxiuous ad clause) is and was listed as free (but GPL-incompatible), while it's been considered DFSG-nonfree. I think the reason that the DFSG differs from the FSF (four freedoms) is that the DFSG tries to be more detailed (and fails - there are places where it is too vague) about what goes and doesn't go. That's why I think interpretative guidelines to the guidelines is a seemingly absurd, but good (and possibly necessary) idea (even though I constantly keep changing my mind on how harsh or permissive these guideline guidelines should be). Sunnanvind (headache and hungry and mad at school. Hope it doesn't shine through.)
Re: license requirements for a book to be in free section
Zack wrote: Because debian is more liberal than FSF. The DFSG are possibly (though I'm not sure) even harsher than the FSF guidelines (the four freedoms). They need to be, to avoid legal trouble (e.g. really make sure you have explicit freedom to redistribute commercially.) Sunnanvind
Re: GDB manuals
On tisdag, januari 15, 2002, at 04:52 , Branden Robinson wrote: On Tue, Jan 15, 2002 at 09:10:04AM +0100, Denis Barbier wrote: Thanks Thomas, there is indeed no more invariant sections in gdbint and stabs manuals, and gdb manual has two called Free Software and Free Software Needs Free Documentation. It certainly does. I wonder why the Free Software Foundation isn't providing it. Free software doesn't need free essays about Free Software Needs Free Documentation. Free software can do with such essays being invariant, right? As long as the documentation is free. Now whether Debian can or should include such invariant essays is another issue...
Re: One unclear point in the Vim license
On Thursday, January 3, 2002, at 10:19 PM, Richard Stallman wrote: This appears to be a misunderstanding, because GNU is an operating system--no more, no less. It's also a funny animal, and some people also refer to the project that set out to create the GNU system as the GNU project. (Not that this is important, or changes your point.)
Vim license and apple license..
I just wanted to point out that the problem with the vim license is the same as the problem with Apple's licensing for Darwin. Not that that's important or significant in any way... or that this email is meaningful.. Sue
Re: Vim license and apple license..
On Thursday, January 3, 2002, at 01:26 AM, Henning Makholm wrote: Scripsit Sunnanvind Fenderson [EMAIL PROTECTED] I just wanted to point out that the problem with the vim license is the same as the problem with Apple's licensing for Darwin. Is Darwin in Debian main or contrib? If so, and if you're right (where can one find the license?), a bug report should be filed. It's not in any Debian archive that I know of. (I didn't mean to imply that, sorry.) A discussion of the license can be found here: http://www.gnu.org/philosophy/apsl.html
Re: Final Draft: Interpretive Guideline regarding DFSG clause 3
On Friday, December 28, 2001, at 03:23 PM, Michael Stutz wrote: The licensing terms and copyright statement for a work are not a part of the work itself. If that is true, then arguably, then the same might go for the text that the FSF says can be invariant in the GFDL. Invariant sections has to be secondary, and secondary sections are defined as follows: A Secondary Section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. end quote --- This means, if I interpret it correctly, that if I want to attach the Big Novella Manifesto of a Thousand Pages, it has to exclusively deal with my relationship to the documents subject or related matters. I can't attach just about any old invariant text.
Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
I don't see why. It is pretty obvious to me that the existing DFSG provides no exceptions to clause 3. Ah, so it wasn't a misunderstanding after all. I wasn't confused. I think it's pretty obvious that there is at least some confusion on this issue. I've seen at least three confused people post on this subject to debian-legal already. I wouldn't exactly call it a crisis. Yet. :)
Re: existing FDL documentation won't hurt
Again... this whole issue seems like it originated with me misunderstanding Branden. I somehow (don't ask me how) got under the impression that he thought that the Debian shall remain 100% free software-part of the social contract meant that every part of every piece of software should completely pass DFSG §3. This would mean that no invariant sections should ever be allowed. At all. And that would then lead to that no invariant license texts (like the GPL) would be allowed. (Branden's packages doesn't.) At first, I thought this absurd... but the more I thought about it, the more it made sense (okay, I have a twisted mind, bear with me) to me. After all - how can what's actually written be interpreted any other way? Sure, maybe people can read between the lines and see that Of *course* license texts and *some* invariant texts should be allowed, but I don't easily take things for granted. (I'm so open-minded that my mind sometimes gets cluttered...) Then I started to propose how the DFSG could be clarified to resolve this perceived issue. (Like explicitly stating what can be left invariant and how much, like license texts and philosophical statements of position.) Meanwhile... on the other side of the galaxy... Branden and RMS had a nice little flame war on a very similar topic, probably sparked by my beloved confusion: What's there to prevent that someone doesn't mark up a whole text as invariant?But... the FDL does clearly state what might be marked invariant. (As I can proudly say that I already knew! I did read the FDL... once... a long time ago.) (Oh, and by the way, RMS kept ignoring me. That's really creepy, am I in his killfile or something?) Meanwhile... I went on and on about the terrible issue that must be resolved and generally made a fool out of myself (it's all about kicking ass and taking names anyway) about DFSG §3 and Invariant parts. While Branden and his posse agreed to always be watchful of supposedly FDL:ed documents that marks up things as invariant that can't be invariant. (And I went on and on, at that point thinking that maybe it's Branden and Thomas that are the ones misunderstanding the issue.) Then. Bruce Perens stepped in and said something to the extent of: It's absurd! No one in their right mind could misunderstand DFSG §3 and think that it meant that everything had to be modifiable! And I thought Well, duh, of course it's absurd. Just because it's absurd doesn't make it less true. (But I didn't say anything, I guess I forgot or I was away or something, I don't remember.) And Branden said No, Bruce, read the thread, you fool, you foolish fool! Meanwhile, everything seems settled and I finally realize that the only one going on and on about DFSG §3 is me, so I shrug and go happily about my confused ways and keep sending fan-letters to Thomas, Branden, RMS and Bruce because I think they're cool generally and this scares them so they hire the Stalking Police but it's okay. So now I'm just basically sitting back to see what happens. My head hurts. And I think I have a rash. Maybe I should eat something now. Sunnanvind (queen of misunderstandings [but at least I can read license texts]) PS. Branden's right. People should read the actual threads. But Branden's also rude. Which is cool generally. But now you don't have to read the threads since I summed it up so nicely and clearly.
Re: existing FDL documentation won't hurt
On Monday, November 26, 2001, at 02:18 AM, Thomas Bushnell, BSG wrote: Did he get your messages? He doesn't subscribe to debian-legal, so if you over-zealously trimmed him from your messages, of course he wouldn't get them. I'm sure he got at least one (he has that auto-response thing going on) but I'm probably just paranoid, he's a buzy person. He's probably just annoyed because I'm always coming up with suggestions all the time. As indeed we *should* do for *every* package. Of course. But... we knew that, right? Let me just say that I found the conversation exceedingly useful in clarifying what we should do--and while your initial worries weren't necessarily so well founded, the fact that you brought it up was a good thing. I'm *still* worrying about that DFSG §3 thing... but we'll see what happens.
Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
I must confess, I'm very happy with Branden's proposal. The shorter and informal one that Thomas posted would probably suffice, but I feel we can't do totally without one - it should at least be stated somewhere, sometime that Debian *can* distribute license texts and invariant, auxiliary material. Hitherto, this has not been explicitly stated, so technically (to the point of absurdity) we'd have to put all GPL software in contrib and the GPL license text itself in non-free. That's silly, so we should actually say somewhere what's excepted from DFSG 3. Informal or formal, either would do. With regard to the 16K limit - that's regardless of encoding, right? One byte is one letter in iso-latin-1, but maybe different in other languages. 16K should be plenty, and if not, packages can be split (most of my suggestions are about splitting things. Split, split, split. Having fun), but to be sure we should check. Emacs has a lot of text files and jokes, for example. Sunnanvind Briling Fenderson No, my TLA isn't SBF. I have a 5LA, it's KSCBF. But that's weird, so I just go with Sunnan.
Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
Or, we could point out that it's the Debian Free *Software* Guidelines, not the Debian free-everything-in-the-world guidelines. I Isn't that exactly what this is? Besides, remember the Social Contract: Debian will remain 100% Free Software. It can be interpreted as All software in Debian will be 100% Free or Debian won't be anything other than software ever. No one knows which! Or so it seems. So we could either: - make some interpretive guidelines regarding DFSG 3 - make some interpretive guidelines regarding the social contract and draw up some Debian Free Other-things-than-software Guidelines - forget about it and just enjoy life Oh, and yeah, I think what's important is that we clarify *what* can be invariant, rather than *how much*, so I can see what you mean when you're concerned about the 5%/16K limits. I don't mind the limits, though, but these guidelines won't be written in stone (I hope. I don't like things that are written in stone, I like things to improve over time) so if something comes up, Branden (or whoever is Keeper of the Something or Other at the time) will make a new proposal, it'll pass, and everything will be coo. See, people are different. Some, like Branden I guess, feel better with things written out very specifically: what can't and what can be done. Some, like you, seem to think that too much written down is harmful rather than helpful. Some, like me, change with every mood swing... but generally I think that precedents are a bad idea. Anyone should be able to look at the rules and figure out what's okay and not okay, without looking at a lot of history and how did we do it in this case and how did we do it in that case. Rules should be hey, okay, now I see, this is okay. I.e, clear. I do think your informal guidelines are clear enough. But Branden's are cooler, they look more arcane... but then again, yours are more taoistically elegant. Oh, choices, choices. Sunnanvind
Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
I think Branden's (despite his plea at the end) will end up getting interpreted as narrow legal rules, and we will see people (perhaps with pseudonymous initials JG) saying noise like this meets the letter of the rule, why are you complaining. I think that the plea (and the fact that these are guidelines... though, the DFSG are supposedly guidelines too... that didn't last very long) goes a long way. The risk of someone following the letter but breaking the spirit is arguably not greater than your informal alternative; and Branden's version could well be seen as an attempt to put as much of the spirit as possible into letters. The danger with rules that attempt to cover every case is that they invariably will not, How very Gödel, but true. and you therefore end up tying your hands and doing the wrong thing in the corner case--or--you just go ahead and break the rule. That's why we've (okay, you've, this was before my time) set up a system where the rules can be changed, patched, fixed, improved. Non-static. So my proposed alternative is deliberately structured to convey to other developers the rough consensus that we have achieved here, without trying to go beyond that and give a rigid definition. That way, cooperative developers *will* be able to figure out what's allowed and what's not. ...and non-cooperative developers might find the letter of your informal alternative easier to follow without breaking the spirit. Or I don't know. I can't really think of a way. And, as a practical matter, they will ask debian-legal just like they always have. Is this an issue that has been asked a lot in the past? Or was it so absurd only the warped minds of debian-legal regulars could've thought of it? :) Still, you have good points. You and Branden can take it from here and duke it out. Sunnanvind (this particular discussion feels very Fudge vs Gurps. Which ruleset covers more situations?)
Alternatives, schmalternatives...
Either way, I thought of it first, I rule! Er... I mean, don't blame me! Unless it's good. Then yeah, I thought of it. Otherwise no. Sunnanvind (my noise-to-signal ratio will decrease, don't worry.)
