Re: Hosting the original youtube-dl sources on salsa?
On Fri, Oct 30, 2020 at 09:16:21AM +0100, Philip Hands wrote: > Rogério Brito writes: > > > Dear people, > > > > As many of you may know, the RIAA issued a resquest for GitHub to take down > > the youtube-dl repository. > > IANAL so I may be confused, but AIUI that takedown is based on the > notion that there is no legitimate use for youtube-dl, which is > nonsense, as this comment clealy demonstrates: Actually not, it is based on the DMCA (which requires takedowns upon being given notice), and on the fact that youtube-dl includes some crypto bypassing code. [...] > b) if the RIAA feels the need to repeat their claims, that we should > then insist that they persuade a judge that their case has some > merit before doing anything about it. If salsa is hosted at a location that is under the jurisdiction of the DMCA, then we would *have* to do anything about it before going to a judge. That's how that (crappy) law works. I'd rather we wait until the youtube-dl developers resolve the situation, as it seems they are likely to do. The "nice" thing about youtube in this context is that it treats content differently based on the licenses that applies to the content; if youtube-dl is only able to download videos whose licenses explicitly allows downloading (and it is possible to do this), then youtube-dl can be reinstated with no issues. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Thu, May 24, 2007 at 10:54:36AM -0700, Don Armstrong wrote: On Tue, 22 May 2007, Sam Hocevar wrote: 3. Nexenta: Despite their incompatibility, Debian accepts both the CDDL and GPLv2 as valid free software licences and would welcome any solution to the distribution of a Debian system based on OpenSolaris. This is not the case, unfortunatly, and it really would be wise in the future to consult with people who are familiar with the arguments surrounding such licenses before expressing Debian's opinion to the FSF. The CDDL's clause 9 is very much not appropriate for works in main, and to the best of my knowledge, works licensed solely under the CDDL have never been accepted in main.[1] To underline, the following clauses in the CDDL are problematic: 9. MISCELLANEOUS [...] This License shall be governed by the law of the jurisdiction specified in a notice contained within the Original Software (except to the extent applicable law, if any, provides otherwise), excluding such jurisdiction's conflict-of-law provisions. Any litigation relating to this License shall be subject to the jurisdiction of the courts located in the jurisdiction and venue specified in a notice contained within the Original Software, with the losing party responsible for costs, including, without limitation, court costs and reasonable attorneys' fees and expenses. [...] You agree that You alone are responsible for compliance with the United States export administration regulations (and the export control laws and regulation of any other countries) when You use, distribute or otherwise make available any Covered Software. It's not appropriate for a Free Software license to require users of software to give up rights that they would normaly have in their own jurisdiction. I understand that argument, but I do think it requires a leap of logic (or at least some creative interpretation) to get from the DFSG to this position. While I can see why some people do not want CDDL-licensed software in main for the above reason, I do not think it is fair to call it the Debian position that this is the case; at least not yet. Counter-arguments: * The bit (except to the extent applicable law, if any, provides otherwise) means you don't necessarily have to give up all your rights. There are parts of copyright law in most jurisdictions that give unalienable rights to users; those fall under the above provision, by definition. The net result of your first clause therefore may be, depending on circumstances, that users actually get _more_ rights than what they started out with if that provision wasn't there, because their own copyright law doesn't give them nearly as much rights as the copyright law in the country where the software was written would. * Your second quote is a non-issue. The same is true for GPL-licensed software; if not, then why did we have to consult two lawyers back when we moved crypto to main? And why do we still have such insane procedures today when some crypto-using software gets through NEW? (you don't see them because ftp-masters handle them, but they're still there). Additionally, personally I don't think it's unreasonable for people to say if you use my software in a way that I didn't want you to, I'll sue you in a court that works by a set of rules that I'm actually comfortable with. You know, it makes fighting those who do not follow your license the way you intended them to quite a bit easier. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sat, Jun 02, 2007 at 09:29:08PM -0700, Don Armstrong wrote: [...] Choice of venue clauses can short circuit the normal determination of jurisdiction in civil cases in some jurisdictions in some cases. In [...] Since this is giving up a right normally enjoyed in exchange for the ability to use or modify a work, it appears be a fee, and as such fails DFSG 1. That's wishful thinking, at best. Common knowledge defines fee as something involving the transfer of money. If it isn't, then the GPL is also non-free, by the very same rationale: the fact that you are required to produce source when so asked if you do distribute binaries from source under the GPL means that you are giving up a right (the right not to distribute any source) which you might otherwise have, which could be considered to be a fee. Hey, if we're going to accept leaps of logic, I can do one too. Finally, by placing works under licenses with such clauses into non-free, we advise people that they should be examining the license more closely before deciding whether or not they should (or can) use the software. Everyone who really cares about anything should do that anyway. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 01:18:56AM +0200, Francesco Poli wrote: On Sun, 3 Jun 2007 21:46:30 +0200 Wouter Verhelst wrote: [...] If it isn't, then the GPL is also non-free, by the very same rationale: the fact that you are required to produce source when so asked if you do distribute binaries from source under the GPL means that you are giving up a right (the right not to distribute any source) which you might otherwise have, which could be considered to be a fee. This argument is flawed. It is not. You're *not* giving up the right not to distribute any source, because you can always refrain from distributing the corresponding binaries and have no obligation to provide source. You're *not* giving up the right to distribute binaries without distributing the corresponding source, because, without a license, you would not have the right to distribute binaries in the first place (with or without source). By accepting the GPL, you instead gain the right to distribute binaries with source, and you simply do *not* gain the right to distribute binaries without source. Similarly, by accepting the CDDL, you are not giving up the right to choose a venue in case you get sued over the software; instead, you are simply gaining the right to use, modify, and redistribute the software under a given set of rules (which simply does not include the right to choose a court in which to settle disagreements). That is what matters, and that is what makes the software free. Even if my argument would be flawed (which I don't think it is, but just in case), that wouldn't even matter. What matters is that DFSG#1 talks about a royalty or other fee--i.e. money--not giving up rights; and any interpretation of the text that says it does talk about giving up rights is incorrect to begin with. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sun, Jun 03, 2007 at 11:28:22AM -0400, Michael Poole wrote: Anthony Towns writes: I don't think that's meaningful; if I sue you in a court in Australia for not complying with debootstrap's license, and they find that you've infringed the license, it doesn't really matter if I'm doing that out of maliciousness or a genuine. And as far as the actual effects go, I'm not sure you're going to be any better off without that clause in your license: if you set foot in Australia, with an Australian judgement against you, there's a good chance of it being enforced; and if you don't, there seems to be a practical possibility of your extradition anyway, based on [0]. Extradition is for criminal cases, not civil cases. I cannot imagine how a choice of venue clause would significantly either help or hurt a criminal defendant. That makes it even better. If you get sued and convicted as a private person in a jurisdiction that is not yours, there are two possible outcomes: * You try to defend yourself, and might win or lose depending on the case. If you go to the jurisdiction where you are being sued, the end result might be that enforcement is likely. * You do nothing, and nothing happens You see, if a judge in the U.S. decides that I am guilty as charged based upon evidence brought before him, I couldn't care less. Belgium does not extradite its own citizens unless those have been convicted by Belgian judges and found guilty; so as long as I do not do anything which might be illegal by Belgian law, there's nothing to stop me from not following the license. Sure, that probably means I should be wary of going to the U.S. while convicted there, but perhaps I can live with that. And indeed, since extradition isn't for civil cases, they wouldn't even ask for extradition in the first place. On top of that, the licensor couldn't even sue me in Belgium, since then *I* could invoke the choice-of-venue clause to prevent that. Hadn't thought of that before, but I'm starting to like these clauses. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sun, Jun 03, 2007 at 05:09:57PM -0700, Don Armstrong wrote: On Mon, 04 Jun 2007, Wouter Verhelst wrote: If you get sued and convicted as a private person in a jurisdiction that is not yours, there are two possible outcomes: * You try to defend yourself, and might win or lose depending on the case. If you go to the jurisdiction where you are being sued, the end result might be that enforcement is likely. * You do nothing, and nothing happens I'm not sure what any of this has to do with choice of venue; By itself, nothing. But in a lawsuit in the context of a license with a choice-of-venue clause, either you live in the jurisdiction that is claimed in the license (in which case not much changes wrt what would be the case if there were no choice-of-venue clause in the first place), or you do not (in which case the above is appropriate). the only thing choice of venue alters is your ability to stop the case in the initial phases by advertising that venue is improper in that jursidiction, not your ability to decide that ignoring German law is the appropriate tactic. What I was trying to show is that the relevance of a copyright case brought against you in a jurisdiction outside of your immediate concern is zero, for all practical matters; that means you can simply ignore it, and nothing Bad will happen. Therefore, I don't think it makes it anything even remotely representing non-freeness. If you are a company or other organization which is large enough that choice-of-venue clauses do matter, then you probably do have contacts with a lawyer in the appropriate jurisdiction whom you can ask to represent you, anyway. [...] [Who has no idea if these sorts of clauses even work in Germany or Belgium] Seen how the Belgian Government wrote the first license in /usr/share/doc/libbeid2/copyright (in particular section 6.3 of that license), I guess they do. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Tue, Apr 24, 2007 at 08:44:30AM +1000, Ben Finney wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Personally, I don't see distributing non-modifiable license texts to be violating the social contract. I'm curious to know how you reconcile Social Contract §1 and DFSG §3, and the fact that we distribute non-modifiable texts in Debian. I don't. Why? It's pretty simple, really: Debian is about Free Software. Not about Free License Texts. To be able to distrubite this Free Software, we need to distribute the license texts with which they come, too. I mean, sure, those eight paragraphs that introduce the GPL are not modifiable. Big deal. -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Mon, Apr 23, 2007 at 12:37:16PM +1000, Ben Finney wrote: Josip Rodin [EMAIL PROTECTED] writes: Also, nobody cares for statements that can be normalized to 'you can do all this, except that, that, that, and that', and those should also be avoided if we want readers to take the spirit of the document seriously. I don't see how that's at all true. Contrariwise, I would hope you agree that a document that says we will always do this, and never do that, but which is routinely violated in practice, is one that readers will not take seriously. Personally, I don't see distributing non-modifiable license texts to be violating the social contract. I don't think anyone ever will consider that to be the case, either. Like people have said before: this is pointless nitpicking. I hope this never gets to vote; I don't want to be considered part of a bunch of crazy fanatics, which is exactly what we'll be if it does. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Wed, Apr 18, 2007 at 11:59:21AM +0100, Ian Jackson wrote: I disagree with this position. See Fabian Fagerholm's explanation. For a strong copyleft licence like the GPL it's particularly troublesome if people go around making minor edits: all of that code is licence-incompatible with all unedited-GPL code. So the FSF have worked to prevent that by using the copyright on their licence text and I don't think that's unreasonable. Actually, that's not what's going on. The FSF clearly state that you may make edits to the GPL, but that you must then * remove the preamble * rename the license to something else (it must not be GNU General Public License anymore, then) While I have no issue with either and agree with your conclusion anyway, it's not the same thing as using copyright on the license to prevent incompatible changes -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Sun, Apr 15, 2007 at 05:50:36PM -0400, Nathanael Nerode wrote: This is a proposed text for a GR. I can't actually propose a GR (not a DD), so I request that someone else who cares propose it or a similar proposal. ---begin proposed GR--- Resolved: That the DFSG shall be amended, by inserting at the end of clause 3, in italics: (There is a special exception for the license texts and similar legal documents associated with works in Debian; modifications and derived works of these legal texts do not need to be allowed. This is a compromise: the Debian group encourages authors of legal texts to allow derived works.) Rationale: Debian is not in the business of shipping license texts; Debian does so only because this is necessary in order to ship other material. Many of these license texts do not have licenses allowing the creation of derivative license texts; the GPL is a prominent example. Without this exception, if the DFSG were followed literally, most license texts could not be shipped in Debian and would have to be shipped alongside Debian instead, which would be very annoying. Historically, this exception has been an unwritten assumption; in most discussions, this exception has been agreed on by everyone involved. If that is the case, then why would it be necessary to write this down in the DFSG? Personally, I don't think we need to go through all this effort just so that nutcases can no longer use But look, we do this for license texts, too as an argument. They're nutcases, anyway. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Wed, Jul 19, 2006 at 07:51:30AM +1000, Matthew Palmer wrote: On Tue, Jul 18, 2006 at 05:04:02PM +0200, Wouter Verhelst wrote: If you distribute binary images with a magazine and have something in that magazine saying if you want the source write to address with a photocopy of this specific text, everything is okay. No more so than if you want the source write to address, enclosing a picture of you petting a cat. Unless, of course, you can show that a photocopy of this specific text is a necessary cost of providing the source. You're only required to provide the source to those who received a written promise from you or anyone who passed on the written promise. The GPL does not say that you may not require proof of them having received the written promise. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Wed, Jul 19, 2006 at 11:43:40PM +1000, Matthew Palmer wrote: On Wed, Jul 19, 2006 at 12:15:48PM +0200, Wouter Verhelst wrote: On Wed, Jul 19, 2006 at 07:51:30AM +1000, Matthew Palmer wrote: On Tue, Jul 18, 2006 at 05:04:02PM +0200, Wouter Verhelst wrote: If you distribute binary images with a magazine and have something in that magazine saying if you want the source write to address with a photocopy of this specific text, everything is okay. No more so than if you want the source write to address, enclosing a picture of you petting a cat. Unless, of course, you can show that a photocopy of this specific text is a necessary cost of providing the source. You're only required to provide the source to those who received a written promise from you or anyone who passed on the written promise. 3b) Accompany it with a written offer [...] to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code Sorry, I just don't see how your interpretation comes out of that. Can you elaborate further? Err, heh. No, I can't :-) (I had always (subconsciously) read it that way, but now that you point it out, seems my interpretation was wrong. Thanks :-) -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
On Tue, Jul 18, 2006 at 03:38:32AM -0400, Radu-Cristian FOTESCU wrote: --- Wouter Verhelst [EMAIL PROTECTED] a écrit : the claim that Debian can be downloaded is a simple statement of fact which just happens to be true as a byproduct of the way we create Debian, it is not a promise. If I can't trust what I can read on Debian.org, You can still download Debian for free from the Internet. The fact that there is a certain specific DVD release of Debian that you cannot download _in that specific form_ does not change this. Even if you can't download the DVD as an ISO image, you can still download everything it contains from ftp.debian.org and its mirrors. The website does not say you can download every conceivable version of Debian GNU/Linux for free from the Internet. It says You can download Debian GNU/Linux for free from the Internet, which should be read as There are versions of Debian GNU/Linux that can be downloaded for free from the Internet. There is a major difference, and it makes your claim (that everyone who makes a customized version of Debian must make it available for download) false. I'll even go one step further and point you to our DFSG: 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from different sources. The license may not require a royalty or other fee for such sale. It is not too far-fetched to interpret You must provide a downloadable version as a restriction. A requirement to provide Debian as a free download would be against the spirit, if not the letter, of the DFSG. then I'll stop using Debian GNU/Linux as soon as I'll find a convenient replacement. If you think you need to do that, then don't let me stop you. people should have the freedom to make a derivative version of Debian *without* providing downloads This is *not* a derivative. This is still labeled Debian Sarge. Because it is, for the most part, Debian Sarge. There is nothing wrong with that. Derivatives are: Ubuntu, MEPIS, Knoppix, dozens of others. Derivatives do *not* carry the name of Debian. It is *not* Debian MEPIS, it's MEPIS. Our policy wrt modified CD-ROM images allows you to do that, so long as it does not contain the word official. This DVD doesn't contain that word, so there's nothing wrong with that. Too bad that the moist important GNU/Linux project and the most important GNU/Linux community can't afford a good lawyer to explain you how to protect your mark. Actually, Greg Pomerantz is a pretty good lawyer. Are you? [...] For God's sake, it's labeled Debian Sarge, dammit! Yes, and? It *is* Debian Sarge. It's not the official image, and it contains some extras that can only be found in the 'backports' archive, but that doesn't make it less 'Debian Sarge'. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Re: RE : Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
On Mon, Jul 17, 2006 at 05:04:18PM -0700, Steve Langasek wrote: On Mon, Jul 17, 2006 at 11:48:05PM +0200, Henning Makholm wrote: If there WERE anything that said that modified versions of Debian must be avavilable for free download, it would mean that something is seriously, horribly, wrong. It would be a non-free requirement. You mean like the terms of the GPL? The GPL does not require you to make anything, at all, available for free download. Not the binaries, not even the source. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
On Tue, Jul 18, 2006 at 04:31:00PM +0200, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: On Tue, Jul 18, 2006 at 03:38:32AM -0400, Radu-Cristian FOTESCU wrote: --- Wouter Verhelst [EMAIL PROTECTED] a écrit : the claim that Debian can be downloaded is a simple statement of fact which just happens to be true as a byproduct of the way we create Debian, it is not a promise. If I can't trust what I can read on Debian.org, You can still download Debian for free from the Internet. The fact that there is a certain specific DVD release of Debian that you cannot download _in that specific form_ does not change this. Even if you can't download the DVD as an ISO image, you can still download everything it contains from ftp.debian.org and its mirrors. The website does not say you can download every conceivable version of Debian GNU/Linux for free from the Internet. It says You can download Debian GNU/Linux for free from the Internet, which should be read as There are versions of Debian GNU/Linux that can be downloaded for free from the Internet. There is a major difference, and it makes your claim (that everyone who makes a customized version of Debian must make it available for download) false. On the other hand the GPL, and most packages will be GPLed, requires that source be available in one of three ways: 3a) include source 3b) accompany it with a written offer good for 3 years 3c) pass through an offer received from upstream Since Debian gives no written offer for their packages but does 3a the option 3c can not be used for anyone building their own debian dvds. Correct. So if one does a custom dvd release of debian one must include source or make and keep it available for 3 years. By that reasoning anyone distributing only binary images is in breach of the GPL. Err, no. If you distribute binary images with a magazine and have something in that magazine saying if you want the source write to address with a photocopy of this specific text, everything is okay. My recommendation is to ALWAYS have the option of a source image. If people don't download/order/pickup the source image along with the binary one they have only themself to blame. Option 3a of the GPL should be satisfied by that. True. But that doesn't mean it's the only legal way according to the GPL. Moreover, all that is so completely and totally beside the point I was trying to make that it's funny. The point is that there is nothing wrong with the mere fact that you cannot download a specific DVD image. After all, there's nothing wrong with putting the source packages _on_ that image... -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Tue, Jul 18, 2006 at 12:32:43AM +0300, Radu-Cristian FOTESCU wrote: 2. Being it unofficial as it's said to be, as long as it holds Debian in the label, could you explain *WHY* the following wording from http://www.us.debian.org/distrib/ does *not* apply? Debian GNU/Linux is distributed freely over the Internet. You can download all of it from any of our mirrors That is still true. Everything which can be found on the DVD is available for download from various websites. The DVD is just an 'easy' version to get it all in one go without having to wait three days to download it all. That being said, the claim You can download Debian for free from the Internet does in no way imply a claim like You can download any random version of Debian for free from the Internet; i.e., the claim that Debian can be downloaded is a simple statement of fact which just happens to be true as a byproduct of the way we create Debian, it is not a promise. This is good; people should have the freedom to make a derivative version of Debian *without* providing downloads, should they want to do so. The only requirement we make is that they abide by the copyrights that are attached to the programs that make up Debian. In the case of the GPL and several other licenses, that means they have to hand over the source code to anyone who received the binary CD or DVD from them and asks for a source DVD -- or just to include the sources on the DVD itself. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 05:42:27PM +0100, MJ Ray wrote: Wouter Verhelst [EMAIL PROTECTED] Alternatively, I don't think it's hard for a judge to understand that there is this piece of software which we indeed do distribute, but which is used by many other people as well, and they all exhibit the same flaw; so even if we allowed the bug to slip in, it's not really our fault. Exactly! It's not our fault, so why should we indemnify Sun against it? If it's not our fault, it's not under our control, and we *don't* need to indemnify. That's what the FAQ says; and whether or not it has legal value, it *does* explain the interpretation Sun gives to its license. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 09:23:07AM +0100, MJ Ray wrote: Marco d'Itri [EMAIL PROTECTED] In linux.debian.legal MJ Ray [EMAIL PROTECTED] wrote: The package maintainer did not ask debian-legal (serious bug) and I'm They do not need to. No, there's no absolute *need* to do that, or to follow any of the other directions in debian policy, Please don't confuse things. The guideline to ask debian-legal is not enforced by policy, but suggested by the Developer's Reference. The latter document is a collection of good practices, not a list of things that must be done. The former document is a list of requirements that each and every package must comply to. Failing to follow a requirement set out in policy can result in a serious bug being filed against your package. Failing to follow a guideline from the developer's reference can, at worst, result in people being annoyed by your attitude. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 09:41:27AM +0100, MJ Ray wrote: Anthony Towns aj@azure.humbug.org.au Is there even any dispute that the DLJ indemnity seeks to overturn all the no warranty statements in debian and leave the licensee liable for the effects of everything in our operating system? If you're actually claiming that's what it does, then I guess there is. Cool. Where is this effect of sections 2(f)(i) and 14 disputed? I've seen repeated claims that we're not liable for Sun's changes and downstream changes, but not upstream changes of parts of the Operating System. Really, how is that any relevant? Can you come up with a real-life scenario (as in, something which actually occurred) where a change to, say, glibc or something similar made some other application break in such a way that it would no longer behave as documented? I could imagine a situation where compiler bugs would make an application misbehave, but that doesn't apply to a binary-only non-free piece of code. I could imagine a situation where library ABI changes break the application in such a way that it would no longer even _start_, but I can hardly imagine that people would want to sue anyone over that -- unless suddenly java would no longer start while they're running stable, but I don't foresee that ABI changes happening in stable (do you?) I could imagine a bug in glibc having an effect on every application which tries to make use of the particular buggy library call. What I cannot imagine is a case where an upstream change would result in only Sun's Java to break rather than a whole bunch of applications (so they would most likely be noticed before the release), and/or to do so on Debian only, rather than on every Linux distribution out there; and it would seem that for any case where the effects are much wider than just Debian, it can reasonably be argued that the problems are, not under our control, which would free us from the burden of having to idemnify Sun. If I'm misguided, I'd be happy to be enlightened. But I don't think I am. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 11:29:33AM +0100, MJ Ray wrote: Wouter Verhelst [EMAIL PROTECTED] The guideline to ask debian-legal is not enforced by policy, but suggested by the Developer's Reference. Please don't confuse things by introducing the DevRef to this. Right, so I was mistaken. An instruction to mail debian-legal about doubtful copyrights is in policy s2.3. No, it doesn't say that: it says If in doubt, send mail to -legal. It doesn't say if the license is doubtful, which is a different matter entirely. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 12:51:25PM +0300, George Danchev wrote: On Wednesday 07 June 2006 12:34, Wouter Verhelst wrote: What I cannot imagine is a case where an upstream change would result in only Sun's Java to break rather than a whole bunch of applications (so they would most likely be noticed before the release), and/or to do so on Debian only, rather than on every Linux distribution out there; and it would seem that for any case where the effects are much wider than just Debian, it can reasonably be argued that the problems are, not under our control, which would free us from the burden of having to idemnify Sun. If I'm misguided, I'd be happy to be enlightened. But I don't think I am. If you are not misguided, then why DLJ license creators put texts like: the use or distribution of your Operating System, or any part thereof, in any manner directly into the license? I dunno? It doesn't matter, because the text goes on to say You shall not be obligated under Section 2(f)(i) if such claim would not have occurred but for a modification made to your Operating System by someone not under your direction or control, and you were in compliance with all other terms of this Agreement. If it didn't, you had a point. As it is, you don't. And you are not to be liable for that only if the modifications made to the underlying systemm are not under your control. If a new upstream version of glibc or the kernel breaks Sun java to function properly or as documented then I believe (according to the license) someone should be be held liable for that break. Who's that? Upsteam? That's Not Our Problem(TM). We're only to indemnify Sun for the things we are directly responsible for. It doesn't mention /anything/ about the stuff for which we are not directly responsible. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 05:45:27AM -0700, Mike Bird wrote: On Wednesday 07 June 2006 04:30, Wouter Verhelst wrote: On Wed, Jun 07, 2006 at 12:51:25PM +0300, George Danchev wrote: On Wednesday 07 June 2006 12:34, Wouter Verhelst wrote: What I cannot imagine is a case where an upstream change would result in only Sun's Java to break rather than a whole bunch of applications (so they would most likely be noticed before the release), and/or to do so on Debian only, rather than on every Linux distribution out there; and it would seem that for any case where the effects are much wider than just Debian, it can reasonably be argued that the problems are, not under our control, which would free us from the burden of having to idemnify Sun. While some people cannot imagine that a contract will be enforced as written, judges can. I didn't say I could not imagine that a contract would enforced as written. I said that I consider the chance for something to actually occur to be small enough that it can be ignored. Remember that this is not about Freedom. If it were about Freedom, I would agree that there is a problem here. But that is not the case; it is about avoiding to get sued. I don't think the demands they are making are wrong per se, nor do I think that the examples of where they /would/ be wrong are realistic, or have any chance of actually occurring. [...] And you are not to be liable for that only if the modifications made to the underlying systemm are not under your control. If a new upstream version of glibc or the kernel breaks Sun java to function properly or as documented then I believe (according to the license) someone should be be held liable for that break. Who's that? Upsteam? That's Not Our Problem(TM). We're only to indemnify Sun for the things we are directly responsible for. It doesn't mention /anything/ about the stuff for which we are not directly responsible. Debian can argue that it is not responsible for software not in Debian archives. However, all software in Debian archives is signed in by a DD, a member of Debian's web of trust. A new upstream bug does not affect Debian until Debian is changed by the DD's incorporation of the upstream version containing the upstream bug. When that change is signed in to Debian, that is a change to Debian made by and authorised by a DD. At that point, Debian becomes responsible for incorporating the upstream bug into Debian, and Debian becomes responsible for indemnifying Sun. That's one way to look at it. Another way would be to say that if there would be a bug where glibc does not work as documented, which appears on _every_ glibc-based platform, then Sun did not do a proper job in testing their software (since it occurs everywhere, remember), so it's really their fault, not ours. Perhaps that depends on the time when the bug is actually introduced. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 05:08:40PM +0300, George Danchev wrote: On Wednesday 07 June 2006 14:30, Wouter Verhelst wrote: On Wed, Jun 07, 2006 at 12:51:25PM +0300, George Danchev wrote: If you are not misguided, then why DLJ license creators put texts like: the use or distribution of your Operating System, or any part thereof, in any manner directly into the license? I dunno? It doesn't matter, because the text goes on to say It does matter in the courts. No, not at all. The text clearly says that we are to idemnify Sun in for anything anyone could sue them over while doing something involving the use or distribution of (our) Operating System, except if something happened not under (our) direction or control. It doesn't matter that you can quote a part of that statement and say it's too broad! Oh, look!, because if you quote part of it, you're not quoting the entire statement, and your statement isn't complete nor does it reflect the intention of the person who wrote it. That's called basic grammar. [...] And you are not to be liable for that only if the modifications made to the underlying systemm are not under your control. If a new upstream version of glibc or the kernel breaks Sun java to function properly or as documented then I believe (according to the license) someone should be be held liable for that break. Who's that? Upsteam? That's Not Our Problem(TM). We're only to indemnify Sun for the things we are directly responsible for. It doesn't mention /anything/ about the stuff for which we are not directly responsible. It easily could became Our Problem(TM) if the break is caused by patch(es) applied to upstream versions by Debian Developer(s) ? Well, yeah, but then it really was Our Fault(TM). There's nothing wrong with standing up for the bad things you've done, is there? Of course, there _is_ something wrong with standing trial for an honest mistake you've made. But do you think a judge have anyone pay a fine if they made an honest mistake while creating something that shouts NO WARRANTY all over? Remember that both Debian and Java do so. Do you think many people will sue if they know that the product they've been using shouts NO WARRANTY all over the place? Of course, there'll always be loonies who will sue even if they have no case. And of course, there'll always be judges who will issue a verdict which is crazy and out of touch with everything else. And while we could theoretically try to ensure that never happens to us, I'd rather not go down that road. How can you ensure that a break will not happend or in a case of such indemnification wont be more than Sun's removal from the official Debian archives. I'm sorry, I can't parse that sentence. Could you please reword? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 02:38:55PM +0100, MJ Ray wrote: Wouter Verhelst [EMAIL PROTECTED] On Wed, Jun 07, 2006 at 09:41:27AM +0100, MJ Ray wrote: Cool. Where is this effect of sections 2(f)(i) and 14 disputed? I've seen repeated claims that we're not liable for Sun's changes and downstream changes, but not upstream changes of parts of the Operating System. Really, how is that any relevant? Can you come up with a real-life scenario (as in, something which actually occurred) where a change to, say, glibc or something similar made some other application break in such a way that it would no longer behave as documented? Why do I need a case where some other application breaks? The indemnification is for problems in the Operating System, not only for Sun Java. Right. And what's wrong with that? Why do you think it's sane to allow loonies to sue Sun over stuff they have nothing, but really _nothing_ to do with? Like, some loonie wants to sue us over his FTP server that went berzerk, finds out that Debian doesn't have a lot of money, and then sues Sun because, hey, there's this Java binary in the same Debian which just _happens_ to be owned by Sun? Sure, I'd prefer if loonies would avoid sueing at all. But if they are going to do that, whether or not there is an idemnification clause on some licence for a software package by Sun isn't going to help us any, because either the loonie is going to sue both us and Sun (so we'd be in court anyway), or the loonie is going to sue Sun first, who would presumably then manage to convince the judge that they're not at fault and that it's us the loonie has to get after (and then we'd be in court as well). [...] and it would seem that for any case where the effects are much wider than just Debian, it can reasonably be argued that the problems are, not under our control, which would free us from the burden of having to idemnify Sun. How does it do that? In general, upstreams are not allowed to change directly what is released as Debian. Ultimately, it's debian developers that decide what modifications are made to the Operating System and are controlled (heh!) and directed by the various project agreements and processes, so I don't see how those modifications are excluded. If it occurs everywhere, it could reasonably be argued that either the JDK is buggy, or not tested well enough. Alternatively, I don't think it's hard for a judge to understand that there is this piece of software which we indeed do distribute, but which is used by many other people as well, and they all exhibit the same flaw; so even if we allowed the bug to slip in, it's not really our fault. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
On Tue, Jun 06, 2006 at 01:33:46AM -0400, Travis Crump wrote: David Nusinow wrote: On Mon, Jun 05, 2006 at 08:04:56PM -0400, Jeremy Hankins wrote: I'm afraid I don't understand the fear here. What would it mean for d-l to become gnome.alioth.debian.org in your example? Non-developers, no matter how much they love Free Software and Debian, don't get to decide on the policies for the Debian project. They have a say, but they don't get to make a decision, or make any claims on behalf of the project. This applies to debian-legal contributors as well. - David Nusinow One would think that even developers that haven't been elected/appointed to certain positions don't get to do these things. Well, no, that's not actually true. Debian developers get a say in whatever they're responsible for. Whether that whatever is a bunch of packages on which they're listed as Maintainer, or a port they've been maintaining for a few years, or a programming language for which they maintain an extraordinary amount of packages and have been helping out in shaping a policy for, or some appointed position (as in this case) really isn't all that important. If somebody not involved with the m68k port comes and tells me that some decision I made for m68k is all wrong and that I should've done this or that instead, I'll have a good laugh. And go on with doing whatever I was doing. Which, I think, is what the ftp-masters should do to this thread. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Mon, May 22, 2006 at 10:25:35AM +0200, Josselin Mouette wrote: Le dimanche 21 mai 2006 à 17:03 -0700, Steve Langasek a écrit : No, I'm acknowledging that the ftpmasters have no obligation to do as *you* say. The ftp-masters aren't the ones trying to tell other people what to do in this thread. They are the ones to tell other people what to do in general. They are the ones rejecting new maintainers or new packages for frivolous reasons. They are the ones preventing me from working on GNOME 2.14 because packages are stuck in NEW. Oh, quit whining already. First, the FTP-masters is not the same group of people as the DAMs. There is some overlap, but it is not complete. Ignoring that, I've never seen the DAM reject new maintainers for frivolous reasons. More on topic, I've also never seen packages rejected because of frivolous reasons. What I have seen is a NEW FAQ which clearly explains the reasons for which a package might be rejected. None of them seem frivolous to me; in fact, if it were up to me, I'd be a bit more strict than what that FAQ seems to suggest. Second, the NEW queue is indeed a bit backlogged; AIUI, however, that's mainly because the ftp-masters were at debconf and the Internet connection there wasn't good enough for interactive traffic, which is required for ftp-mastery stuff. Debconf is over now, so I fully expect the NEW queue to be handled again as good as it used to be in a few weeks. Which would hopefully mean that emile, a package that I uploaded and which is stuck in NEW as well, will be accepted into the archive. They are generally considering the rest of developers like a boss with his employees. I've never seen any of them ordering me to do something, which is the essence of an employer/employee-relationship. You must be delusional. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Mon, May 22, 2006 at 10:50:22AM +0200, Michael Meskes wrote: On Sun, May 21, 2006 at 04:04:37PM -0500, Raphael Hertzog wrote: Fears are unfounded, we can at any time terminate the license by removing java! Again this logic doesn't seem to work for me. If I was offering warez on my server I couldn't become legal again by just removing it. Not even remotely relevant. The difference would be that while you would act against the original author's wishes if you were to put warez on your server, the same isn't true about Sun Java. In fact, Sun explicitely asked us to please distribute their software. I'd say that accounts to something, and that a Judge who feels different isn't worth his job. Consider Sun would turn nasty and would try to use their Java distributor's license against us. What do you think would happen? * Sun tells us remove Sun Java from your server, now! * We comply * End of story. What's the problem? They won't sue us for distributing Java. If they do, all we have to do is point the Judge to the press coverage of this change of license, and to the fact that Debian was mentioned as one of the distributors asked to please distribute Java. They won't have a case. Try as I might, and considering how lawyers and judges are human beings and not automatons, I can't see any realistic scenario in which we could be sued and lose a case in relation to this license. Do you? Sure, the license isn't Free Software. It would be nice if it were; and I'm sure that Sun Java won't be part of main until it is. But apart from that, I really don't understand what the big fuss is all about. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Mon, May 22, 2006 at 12:03:25PM +0200, Josselin Mouette wrote: Le lundi 22 mai 2006 à 10:46 +0200, Michael Meskes a écrit : And I'm pissed of that so much seems to happen behind the scenes and I as a normal developer who did not go to Mexico do not get the info even if I ask, but instead people are just told to shut up. Even people in Oaxtepec have learnt that Java thing by reading the mailing lists. Err, that's not actually true. It was announced at the end of one particular talk. Even I saw that through the webcast. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- 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 11:21:34AM +0200, Anton Zinoviev wrote: On Mon, Jan 23, 2006 at 11:49:04PM +0100, Wouter Verhelst wrote: The overall subject can be software freedom but not necesarily in all cases and certainly not in the case with the man-page. One can not use simple quantity calculations in order to determine what the overall subject of a book is. I think you'll find you'll have a hard time convincing anyone that a text that consists for 90% of a secondary section about free software and for 10% of technical documentation that the overall subject of that text is something technical. I gave two examples. I could also produce examples that have nothing to do with the matter at hand, that doesn't prove anything. I have a book with poetry but the total length of its prefaces is more than the total length of all poems. I have also a book containing relatively short medieval story and a very long preface. Can we stick to technical documentation? These examples show that my opinion about overall subject can be confirmed by a more authoritative source, namely the libraries. I submit that things like medieval texts and poetry are special cases; in the case of medieval text, a lot of research goes into this; in the case of any art form (including poetry), there are always people who think it is nice to give a whole lot of comments on the thing. For both your examples, it is normal that there is quite some accompanying text. It is not common for the accompanying text to be longer than the subject matter itself, but it indeed is not unheard of. The same cannot be said about technical documentation. I have never seen technical documentation accompanied by lots of text about different subject matters, except in the case of the FSF's documentation (and even then it never amounted to more than the technical documentation itself). [...] BTW, I chose these examples because these are books I realy have, not because I can not imagine technical book that proves the same. Well, I can't. If you can give me an actual example of a technical book that talks more about non-technical stuff than about the actual technical subject matter, I'll agree with you. Until that time, I think it's reasonable to say that the length of both texts is fairly important in deciding what the overall subject matter really is. Still isn't relevant. If you have three very short manpages, or six very short manpages, and then one copy of each of the invariant sections, and the cumulative length of the invariant sections ends up being larger than the cumulative length of the manpages, the question will arise what the overall subject is. Well, if you ask the people that use this man-page they will tell. Uh. You'll have to make a choice here: either the text is the entirety of _all_ manpages (in which case you can split off the invariant sections and the FDL text to different manpages, but you have to consider all of them together in order to decide what the overall subject matter is), or the text is one manpage specifically (in which case you cannot split off the invariant sections and the FDL text to different manpages, but you can consider each of them individually in order to decide what the overall subject matter is). You do not try to weasel out of admitting you're wrong by changing your definition of 'the whole document' when it suits your purpose better. but the question is why we shouldn't accept [the unmodifiable sections]? What basic freedoms of our users we will protect by doing so? The freedom to modify the text as they see fit. With respect to that freedom GPL is also non-free. It is not. See below. Note that you even have the freedom to take a license text and modify it, including any preamble such a license text might have. Not exactly. The BSD-alike licenses allow you do this but other licenses state that everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. You're referring to the GPL, right? Let me show you this, then: http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL In short: you are allowed to change it provided you do a few specific things; one of them is that you must rename your license. The full copyright statement to the copyright license is not included in the copyright license itself, probably for reasons of practicality; but that shouldn't matter. In fact, the GPL _has_ been modified in the past. See http://www.affero.org/oagpl.html If they think that something is a free license we have to agree acording to our social contract (we will be guided by the needs of our users and the free software community). To be guided by does not imply to blindly follow whatever they say, without having our own opinion. No, it doesn't but in that case there must exist more solid argumentation than just we don't agree becase we don't want
Re: GR Proposal: GFDL statement
On Thu, Jan 05, 2006 at 10:34:46AM +0100, Stephane Bortzmeyer wrote: It saves *so* much trouble. But not all documentation is attached to a software. For instance, if I write a book Software development on Debian, releasing it under the GFDL is still the reasonable thing to do. Not if you want it to be part of Debian. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Origins of debian swirl
On Sun, 19 Jun 2005 18:24:11 +1000, Simon Wright wrote: It's a simple, generic stroke of rough charcoal, a standard brush shape that ships with Adobe Illustrator. Actually, it's one of the five defaults that appear in the brushes pallete when you begin any new document I don't see any problem with this, but I thought it should be mentioned... Actually, one could wonder who was first. I'm not blatantly assuming Adobe just took the swirl without looking at our copyright, but then it's not entirely impossible either. The fact that this wave of other usages of the swirl is fairly recent (or is that a perception on my side?) could imply that this is indeed the case... -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
On Fri, Jul 01, 2005 at 04:34:54PM -0400, Glenn Maynard wrote: The fact that you're trying to coerce a maintainer to include a work instead of attempting to address his reasons for doing so, is enough for me to agree with Joey's decision. That doesn't actually seem to me to be what he's doing. Rather, the DIG maintainer saw his HOWTO, liked it, and incorporated it in the install guide. There's a major difference. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
On Fri, Jul 01, 2005 at 11:15:36PM -0400, David Nusinow wrote: Ok, change committed. You are now attributed in the administrivia section. Thanks for the great doc. You suck. You know you just ended a potentially great and entertaining flamewar by leaving one side without arguments? ;-) (jk, of course. Thanks for doing the reasonable thing) -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pine license
On Wed, May 11, 2005 at 12:28:29AM -0400, Raul Miller wrote: Also, if I recall correctly, there was a gnu project to write a pine replacement, but I don't know where that stands. Probably it's not complete because of a lack of development effort. Well, there's nano -- and if you want the pine UI, most people recommend mutt with a .muttrc that contains pine-style keybindings. At least that's what I used when switching from pine to mutt... -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: 4. Writing to debian-legal and asking for advice. Now that's a good idea. Why did you do that on debian-devel instead? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 08:25:48PM -0400, Raul Miller wrote: On Tue, Oct 19, 2004 at 01:47:34AM +0200, Wouter Verhelst wrote: The first section of the SC says that Debian will remain 100% Free Software. That is the title of that section. If you bother to read it, you'll see We will never make the system require the use of a non-free component. A binary which has been compiled using a non-free compiler does not require non-free software to run; nor does it require the same compiler to be built again. If it does, then it doesn't belong in main; that is not in dispute. Also, if the software compiled using a non-free compiler requires an additional license from the distributor, then it doesn't belong in main either; but AIUI, this is not the case (it only requires an additional license from the person using the compiler). It does not say that the binary bits of Debian can be restored to something which will produce the exact same MD5 sum using only Free Software[1]. This is a straw man argument. http://www.nizkor.org/features/fallacies/straw-man.html No, it is not. What you advocate is essentially that a later compilation must result in the exact same binary, disregarding the fact that our toolchain will change.. Since Wesley's software will be released under the GPL, it will clearly be Free Software, so there is no problem. There is a problem if building that component requires the use of a non-free compiler. Well, it does not /require/ the use of a non-free compiler. The fact that Wesley wanted to build his package using non-free software does not really matter -- as long as it does build using Free software. It doesn't matter if there is no difference in what is built. Problems arise if there are differences between what the two compilers build. For example, there might at some point be a bug which only shows up under gcc. That is a non-issue. We have 11 architectures; if there is a bug which only shows up under gcc, then the software will most likely exhibit that buggy behaviour on those 11 other architectures. If it does not (i.e., it is a bug which only shows up under gcc on i386), then this is a bug in gcc which will most likely be found by other applications as well (the strain we put on our compilers by compiling some 8GB worth of software is enormous) Heck, some developers might have installed icc and might be compiling their packages using that compiler instead of gcc; as long as their software does not use too many gcc-isms, you should not even notice so in the source. How would you tell that such a package is built using icc instead of gcc, other than by benchmarking? [1] I hope no one is doing that. I wouldn't care, as long as it would work correctly. [2] We probably wouldn't notice this issue until it creates problems. I don't think it would create problems. See below. If you still insist, consider this: If I would know i386 assembler (which I don't), I could theoretically hand-optimize software before I upload it. Since I did hand-optimization, the resulting binary would no longer be built using only Free Software; it would also incorporate the fruit of my labour. Is the resulting binary now suddenly non-free -- or, at least, should it go to contrib instead of main? If so, why? If not, what's the difference between this example, and the question of icc-built software? If you've hand optimized it, the hand optimized assembler becomes a part of the sources. Okay, what about this then? The m68k kernel maintainer at one point, if I'm not mistaken, used to compile m68k kernels with a cross-compiler he built. As a result, the compiler used to compile the kernel is not in main. Does that make the resulting kernel binary non-free? Or what about a developer who modified the gcc code to suit his own needs, but did not, as the GPL allows him to do, distribute either the source to his modifications or a binary built from his modified source? (where he only modified the optimizer code, not the parser code) [...] I don't see any reason why we should not consider the resulting builds to be part of main. If you can guarentee that when the package built with icc is tested that any bugs which would result from building using at least one free compiler will be evident, and if you can guarantee that systems which use icc-built software will continue to function if they use some free compiler to build that software then the problem is more philosophical than practical. That said, I don't see any viable way for you to provide any such guarantees. Easy. I can see three classes of problems that could result in the software not being usable when compiled by a different compiler than the one used when the software was distributed: * The software simply does not compile, due to a parser bug in one of the compilers; either the code compiles with the used compiler while it is syntactically invalid
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 09:13:24AM +0200, Andreas Barth wrote: * Wouter Verhelst ([EMAIL PROTECTED]) [041019 00:40]: Wesley's software can be built using software in main. It will not be as fast, but it will still do its job, flawlessly, without loss of features, with the ability to modify the software to better meet one's needs if so required. I disagree. A program is IMHO not only specified by the fact that it does certain transformations from input to output, but also by the speed it does this. There can be cases where compiling software using more recent toolchain versions will result in a binary not running as fast as before (because the newer libc is a bit more bloaty, or because some aggressive optimization which was enabled before but which was deemed buggy by design afterwards, was disabled again, or whatnot). Where is the difference with using a non-free compiler? If this specification can be matched by gcc, why consider using icc at all? And if not, it requires icc. (You can also consider what happens when we want to do a security update: Does the security team need to install icc, or do we want that the software runs significantly slower afterwards, and misses its specification?) If that is an issue, then it is also an issue for software currently in main but which is built using toolchain versions that are now no longer in main. If icc is required for that application, than it needs to go to contrib. Indeed. However, as long as the software does indeed compile correctly using gcc, one can say that icc is not required. If not, please compile it with gcc. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 05:47:26PM -0700, Steve Langasek wrote: On Tue, Oct 19, 2004 at 02:04:42AM +0200, Wouter Verhelst wrote: A difference in optimization is not relevant to a package's freedom. If compiling the program with a non-free compiler gains you users who would not find the package usable otherwise, distributing binaries built with such a compiler induces your users to be dependant (indirectly) on non-free software. That is a freedom issue. Okay, that is a fair point. I'll leave it at that. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 06:28:01PM -0700, John H. Robinson, IV wrote: [...] This package is buildable by tools in main. It meets the letter of the law. The spirit seems a bit ambiguous. Good case in point, the m68k cross-compiled stuff, where the cross-compiler used was non-free. (I have not verified the accuracy of the non-free claim of the cross- compiler. I didn't say that. The compiler was built from gcc sources, but the cross-compiler (as it was used) was not uploaded to the archive. Also, this discussion is academic as the maintainer is going to split the package into two: gcc build in main, and icc built in contrib. Given the circumstance, I felt that this action is the best. Agreed. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 07:51:00PM +0200, Josselin Mouette wrote: Le lundi 18 octobre 2004 à 19:22 +0200, Wesley W. Terpstra a écrit : So, when it comes time to release this and include it in a .deb, I ask myself: what would happen if I included (with the C source and ocaml compiler) some precompiled object files for i386? As long as the build target is i386, these object files could be linked in instead of using gcc to produce (slower) object files. This would mean a 2* speedup for users, which is vital in order to reach line-speed. Other platforms recompile as normal. On the other hand, is this still open source? Is this allowed by policy? Can this go into main? Main must be built with only packages from main. No, that's not true. In addition, the packages in _main_ * must not require a package outside of _main_ for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-_main_ package), There's a difference, which is crucial. ICC may not be Free Software, policy does not say you must only use Free Software to build a package; it says you must not /require/ a package outside main to build it. The difference is subtle, but crucial. Wesley's software can be built using software in main. It will not be as fast, but it will still do its job, flawlessly, without loss of features, with the ability to modify the software to better meet one's needs if so required. If you really want to distribute a package built with icc, you should make a separate package in the contrib section, and have it conflict with the package in main. That's also possible, of course, but not required IMO. The GPL doesn't restrict anything you are describing, as long as the source is available alongside. Nor does Policy. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 06:55:30PM -0400, Raul Miller wrote: On Mon, Oct 18, 2004 at 07:51:00PM +0200, Josselin Mouette wrote: Main must be built with only packages from main. On Tue, Oct 19, 2004 at 12:37:45AM +0200, Wouter Verhelst wrote: No, that's not true. It seems to me -- at least in the context of what Debian distributes and calls Main -- that this assertion conflicts with the first section of the social contract. No, I don't believe so. The first section of the SC says that Debian will remain 100% Free Software. It does not say that the binary bits of Debian can be restored to something which will produce the exact same MD5 sum using only Free Software[1]. Since Wesley's software will be released under the GPL, it will clearly be Free Software, so there is no problem. The fact that Wesley wanted to build his package using non-free software does not really matter -- as long as it does build using Free software. Heck, some developers might have installed icc and might be compiling their packages using that compiler instead of gcc; as long as their software does not use too many gcc-isms, you should not even notice so in the source. How would you tell that such a package is built using icc instead of gcc, other than by benchmarking? If you still insist, consider this: If I would know i386 assembler (which I don't), I could theoretically hand-optimize software before I upload it. Since I did hand-optimization, the resulting binary would no longer be built using only Free Software; it would also incorporate the fruit of my labour. Is the resulting binary now suddenly non-free -- or, at least, should it go to contrib instead of main? If so, why? If not, what's the difference between this example, and the question of icc-built software? As a side note, I think the comparison to Java-software someone made was a flawed one. There is a major difference between it can be compiled, but it won't be as fast and it can be ran by free software, but not compiled. Some java software is in the latter category; what we are discussing is in the former. [1] Which is the case even if there would be no icc-compiled software in Debian, simply because it's often impossible to determine what the exact used toolchain mix was to build a specific package. I'm interested in your reasons for making this assertion. If your point is that it's possible build software whose source is in main using compilers which are not in Main, I'd agree with you. However, I don't see any reason to consider the resulting builds to be a part of main. I don't see any reason why we should not consider the resulting builds to be part of main. I am fully aware that there are people who think that all non-free software should be banned from the face of the earth (Hi Richard!). However, the fact that some Free Software package is built using non-free Software, even though it could be built using only Free compilers, does not suddenly make the Free Software package non-free. What is 'Free Software' is defined differently by both Debian and the Free Software Foundation; however, GPL'ed source code which is built using a non-free compiler does not, in my view, fail any test of either of those definitions. Wesley's software can be built using software in main. It will not be as fast, but it will still do its job, flawlessly, without loss of features, with the ability to modify the software to better meet one's needs if so required. I have no disagreement with this statement. The GPL doesn't restrict anything you are describing, as long as the source is available alongside. Nor does Policy. Are you ignoring the social contract? Of course not. Policy and the Social Contract may not, and IMO do not, conflict. What's generally allowed in Debian is defined in the Social Contract. What 'Debian' exactly is, and the exact ugly bits of what is, and what is not, allowed in that, are defined in Policy. Hence, in some cases, including this one, Policy is an appropriate tool to determine whether something is appropriate (provided no conflicts between Policy and the SC can be found, which I don't think is the case). Or, when you talk about Main, are you talking about something other than the packages we distribute in the Main section of our archives? Of course not. On the contrary; the clearest definition of what packages we distribute in the 'main' section of our archives is in Policy (which is why I chose to quote that, instead of the SC). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 07:02:19PM -0400, Glenn Maynard wrote: You can't take the source, compile it with a proprietary compiler and upload the result to main, because in order to create that package, you need a non-free compiler. The fact that you can also compile the sources with a free compiler is irrelevant; non-free tools are still required to create the package actually in main. Policy doesn't say If that is important, then we must throw all packages which are built using an outdated glibc, binutils, or gcc out of the archive; because the tools used to build those packages are no longer in main (no, snapshot.debian.net doesn't count); and building something which was built, e.g., 4 months ago using the then-current unstable toolchain, will not produce the exact same package as it would today -- it would produce... you must be be able to build a package similar to the one in main using tools in main; ...a package similar to the one in main. Your point? Also, consider the fact that in the past (at least if I'm not mistaken), the m68k kernel maintainer used to provide m68k kernel packages built using a cross-compiler on his i386 system. Since the cross-compiler isn't in main, should those m68k kernels have been moved to the 'contrib' archive? it says the package in main must be buildable with tools in main. That is still the case. The fact that the package in main is built using non-free tools is irrelevant -- it can be rebuilt using software only in main; it can be ran using software only in main; and the difference is not noticeable except by comparing checksums, benchmarks, or to those with an intimate knowledge in compiler optimizers. A difference in optimization is not relevant to a package's freedom. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Keeping track of DSFG-free and non-free licenses
On Sat, Jul 24, 2004 at 11:15:58PM +1000, Parsons, Drew wrote: [MFT to d-legal, don't know what d-devel has to do with this] Keeping track of licences for prospective new packages is of interest to all developers. Correct. So is keeping track of how close we are to finishing debian-installer (-boot), what happens to policy (-policy), how our ports are doing, (too many lists to list them all), and so on. That doesn't mean we have to discuss all of that on this list. Even if I agree this is a worthy cause, please discuss this on -legal, where it belongs. If/when you create some web page, you can always announce it on -devel-announce, if appropriate. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: remove this package from another developer
On Thu, Jul 15, 2004 at 02:21:35AM -0500, Branden Robinson wrote: In any event, the Technical Committee and Project Secretary are not and cannot be delegates under the Constitution[1]. Additionally, most port- and CDD-maintainers are not delegates (and they certainly are not delegates in their capacity of port- or CDD-maintainer). So it is not clear to anyone viewing that page who is a delegate and who is not. Indeed, and I agree that such a list would be helpful. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Bug#247802: ITP: libfasttrack-gift -- giFT plugin for the fastrack network
On Mon, May 24, 2004 at 01:41:09AM +0200, Bartosz Fenski aka fEnIo wrote: On Mon, May 24, 2004 at 01:20:47AM +0200, Wouter Verhelst wrote: May I ask you in which country reverse-engineering for compatibility is forbidden? I'm just curious, because it is legal in Poland, but only for compatibility reasons, and I guess this situation fits this. That's because Poland is part of the EU now, where it is legal. No. It was legal also before access to EU. Of course it was; Poland wouldn't have been allowed in the EU if they didn't implement that in their laws first. Since when has this been legal in Poland? However... This is good, but it's not true anywhere else; so if the reverse engineering has been done outside the EU, there's a problem. ... I seem to have been wrong here. Can't say I don't like it, though :-) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Bug#247802: ITP: libfasttrack-gift -- giFT plugin for the fastrack network
On Sun, May 23, 2004 at 05:52:46PM +0200, Bartosz Fenski aka fEnIo wrote: On Sun, May 23, 2004 at 11:38:17AM -0400, Dan Weber wrote: The reason why libfasttrack-gift has never been placed into debian is because it doesn't even qualify non-free. Debian could be sued for this, and other reasons due to its reverse engineering. May I ask you in which country reverse-engineering for compatibility is forbidden? I'm just curious, because it is legal in Poland, but only for compatibility reasons, and I guess this situation fits this. That's because Poland is part of the EU now, where it is legal. This is good, but it's not true anywhere else; so if the reverse engineering has been done outside the EU, there's a problem. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: right of publicity, or why no-advertising clauses are not necessary
Branden Robinson wrote: A) Can folks in other countries help us find out if publicity rights are recognized there? IANAL, and the few areas about the law that I do have a more than average knowledge about do not include this part; however, ISTR having heard something about it not being legal over here for someone to take your picture and publish it without your permission. Also, if someone ever misrepresents you or your opinions, in Belgium you have what is called the Right to answer, which means that you can write up a reply to whatever was published, send it to the publisher and demand that they publish it. They then either have to publish it as is, or send you an edited version for approval and publish that if you agree; but they cannot refuse it. A good and recent example where this right was executed was in an article in a local newspaper about how the economy isn't going too well currently and that many small companies were having troubles, featuring a picture of some industrial area with some logos of some small companies. For obvious reasons, those companies weren't really happy to be associated with an article about bad economy and companies in trouble, so they executed their right to answer, and the newspaper published an explanation (that it was just a random picture, that the article didn't apply to the companies in question). All this is unconnected to copyright, though. Does any jurisdiction in the world automatically grant copyright licensees permission to use the copyright holder's name or likeness in advertising or publicity? Not that I know of; but again, IANAL. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Fri, Apr 02, 2004 at 02:20:52AM -0500, Branden Robinson wrote: On Thu, Apr 01, 2004 at 09:57:21AM +0200, Wouter Verhelst wrote: On Thu, Apr 01, 2004 at 12:27:09AM -0500, Branden Robinson wrote: IMO we should do a clean-room implementation anyway. 1) Past experiences with Apple have not been very fruitful, just ask the Linux Mac68K hackers. Well, actually, they have been. It is true that Apple has long refused to give out specifications for mac68k hardware, but after many requests, they have given out the requested information to the NetBSD folks, on the condition that they would share it with any interested party. The Linux/mac68k hackers have the information, and are slowly improving drivers with it. Whether history will repeat itself, I do not know... Ah, that's happy news. Does that mean floppy disk support for, say, the Quadra 840AV is just a matter of getting a good C programmer to type something up from the specs in NetBSD's possession? I should note that I have not personally seen those specs; but if they are complete enough (which I suspect they are), I don't see any reason why that would not be the case. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Thu, Apr 01, 2004 at 12:27:09AM -0500, Branden Robinson wrote: IMO we should do a clean-room implementation anyway. 1) Past experiences with Apple have not been very fruitful, just ask the Linux Mac68K hackers. Well, actually, they have been. It is true that Apple has long refused to give out specifications for mac68k hardware, but after many requests, they have given out the requested information to the NetBSD folks, on the condition that they would share it with any interested party. The Linux/mac68k hackers have the information, and are slowly improving drivers with it. Whether history will repeat itself, I do not know... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Debian-installer, older hardware, boot loaders, miboot amiboot ..
On Thu, Apr 01, 2004 at 12:14:50AM -0500, Branden Robinson wrote: On Wed, Mar 31, 2004 at 02:00:46PM +0200, Sven Luther wrote: Well, the US are mostly the most restrictive (unreasonable) juridiction on this kind of issues, so ... That's not my experience. The U.S. is very aggressive about extending the duration of copyrights, and deserves to be criticized for that, but it is far from the worst offender with respect to the *breadth* of copyright. In the U.S., we have consumer protections such as the right of first sale and fair use written into our laws and upheld in the courts. There are European agreements in effect that include those things, too. There is a right of first sale in the EU, which means that it's only valid if you bought your copyrighted product in the EU yourself; and the fair use clauses are in effect in every jurisdiction I know of (I think they're part of the Berne convention, but could be mistaken). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: copyleft licence compatible with apache licence
On Thu, Nov 27, 2003 at 07:42:23AM +0100, Pierre Gambarotto wrote: Some questions I have : _ is it possible to use the GPL with a modification, like : this code is distributed in GPL, but can be used with any apache licenced code. Yes, you can do that. You should add a paragraph to your copyright notice that says something like As a special exception, the author grants you the right to link the Program with any software licensed under full name and perhaps URL of the Apache License Obviously, you can only do this legally if you are, in fact, the author of that license. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: copyleft licence compatible with apache licence
On Thu, Nov 27, 2003 at 01:00:17PM +0100, Wouter Verhelst wrote: Obviously, you can only do this legally if you are, in fact, the author of that license. Uh. the author of the Program, not the license :) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: BSD Protection License
Op wo 22-10-2003, om 21:46 schreef Adam Majer: Hi, Could anyone tell me if the BSD Protection License can be used for main? It can be found at: http://people.debian.org/~adamm/LICENSE There have been numerous people explaining that this license seems non-DFSG-free, and I concur. However, even if the wording were changed to more clearly allow people to choose between 3 and 4, I don't think it serves its purpose (that of being GPL-incompatible): If there's an option to choose between either paragraph 3 and paragraph 4, this means you can effectively ignore paragraph 3 entirely if the Program is coupled with code under another license. So, to check whether or not the license is GPL-compatible, one would have to see whether any of the terms in the license _outside of paragraph 3_ impose 'further restrictions' as defined in the GPL. I don't think that is the case; AFAICS, the only GPL-incompatibility in this entire license is paragraph 3c. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: centericq and MSN support
On Thu, Oct 23, 2003 at 10:25:22AM -0400, Brian Ristuccia wrote: On Thu, Oct 23, 2003 at 03:33:24PM +0200, Julien LEMOINE wrote: Hello, I uploaded today a version of centericq with support for last msn protocol (MSN9). I received a question from upstream author, he do not want to include this patch in official release for the moment because he do not know if this is legal. Does someone know if this MSN9 support is legal ? A short resume of the problem is given on gaim page [1], microsoft now require a licence for connecting on a msn server. For the purposes of Debian, you need to concern yourself only with whether the software itself can be distributed without infringing on any copyright held on the software itself. As of version (4.9.2-5arc), centericq was distributable under the terms of the GNU GPL, which we generally consider to be acceptable. (The fact that end users might use the software for something illegal is irrelevant to whether or not it can be included in Debian. One can use mixmaster for industrial espionage, john to brute-force UNIX password files for the purpose of making unauthorized use of private computers, some half-dozen or more packet sniffers to run illegal wiretaps, GNU shred to destroy evidence, and xvidtune to commit arson[1]. We still distribute those). However, that does not mean the same is true for the upstream author; and if he requests that you wait until he's checked with a lawyer, I don't think it's unreasonable to do so. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Packaging Swiss Ephemeris Free Edition for Debian GNU/Linux
Op di 14-10-2003, om 07:17 schreef Branden Robinson: On Tue, Oct 14, 2003 at 08:34:24AM +1000, Matthew Palmer wrote: You missed the one big one, too: the apparent requirement to preferentially licence modifications you make to the copyright holders of the original SE copyright holders. Don't worry, I missed it too at first. grin Well, it turns out to be irrelevant as the upstream copyright holders seem disinclined to do anything at all about the licensing at present. If you can help us with setting up a license which fulfils our intention and at the same time has no unclear points, you are welcome to provide suggestions. Not that I think I'm experienced enough to provide suggestions, but can't we at least try? -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Swiss Ephemeris Public License
Op vr 10-10-2003, om 23:10 schreef Henning Makholm: This license file and the copyright notices in the source files are the only places where the author's names may legally appear without specific prior written permission. Hm - I wonder whether, if this is enforceable at all, it can be interpreted literally enough to allow the upstream author to be identified in the debian/copyright file, as required by policy. Is that an issue? The license text needs to be part of the debian/copyright file. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: MPlayer DFSG compatibility status
Op wo 08-10-2003, om 02:53 schreef Brian T. Sniffen: Gabucino [EMAIL PROTECTED] writes: Glenn Maynard wrote: One version of VirtualDub could read ASF files, and that was quickly removed. That was back in 2000, and I just checked: the news entries appear to have fallen off the site. There is a significant part to these patent enforcement stories: they all happen on Win32 platform. Microsoft has never enforced media patents on Linux market, as far as I know. That's irrelevant if they actually own the patent: the goal is not to avoid getting sued, it's to avoid breaking the law. In theory, yes. However, in practice, when dealing with patents, I suggest you do pursue just that 'not getting sued' goal; since literally everything computer-related is patented, there's no other way. If you've found a violation of the DFSG in xine, please file a serious bug against xine-ui or libxine1, as appropriate. The violation wouldn't be DFSG-related (the DFSG doesn't say anything about patents, only about licenses). -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*.
Re: [OT] Debian developers
Op vr 03-10-2003, om 03:31 schreef Manoj Srivastava: On Thu, 2 Oct 2003 00:54:29 +0200, Wouter Verhelst [EMAIL PROTECTED] said: (in case my English is worse than I thought: no, the fact that 'evil' and 'manojish' appear in the same... uh... tag doesn't mean I consider Manoj evil :-) Darn. I thought I had an evil twin. Oh, but I didn't say that wasn't the case :- -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: [OT] Debian developers (was Re: committee for FSF-Debian discussion)
On Wed, Oct 01, 2003 at 02:35:32PM -0500, John Goerzen wrote: evil manojish paranoia mode For the record, I do pledge to uphold the social contract, and my current key does have signatures from other developers on it :-) Unfortunately, that mail wasn't signed, so there was no way for us to check. Hence, you're a liar. /evil manojish paranoia mode (in case my English is worse than I thought: no, the fact that 'evil' and 'manojish' appear in the same... uh... tag doesn't mean I consider Manoj evil :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: solution to GFDL and DSFG problem (dadadodo at work?)
On Sun, Sep 28, 2003 at 08:37:07PM -0400, Anthony DeRobertis wrote: You don't even have to go through that much of a hassle. Old-Return-Path: [EMAIL PROTECTED] That could of been forged. Received: headers can be forged, too... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A possible GFDL compromise: a proposal
On Tue, Sep 30, 2003 at 03:23:06AM +0900, Fedor Zuev brabbled: On Sun, 28 Sep 2003, Wouter Verhelst wrote: 8)Is Debian logo written on [cover of] the same CD-ROM software or hardware? No. Is it in Debian? So, your definition of software is heavily Debian-specific. Even ftp.debian.org-specific, since you do not recognise covers of Debian CDs as subject of DFSG. Not quite so. There are no official CD covers, so any cover printed on a CD-ROM is unofficial. Even if it contains the logo, even if it is burned based on an official ISO image. As such, the logo is not 'in' Debian. Hency, my question. Did you even bother to read what I said? Are you genuinely interested in a constructive discussion, or are you just trying to waste everyone's time? I suspect the latter is the case; hence, welcome to my plonkfile. You're the first person, *ever*, to reach it (not counting USENET). -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A possible GFDL compromise: a proposal
Op vr 26-09-2003, om 09:04 schreef Fedor Zuev: On Mon, 22 Sep 2003, Roland Mas wrote: In the Debian Project, 'software' means anything that is not hardware. It does not mean just computer programs. Seconded. First, try to answer to several simply questions. If you do likewise. 0) Is printed Emacs Manual in bookstore a software or hardware? No. Is it in Debian? 1) Is Emacs Manual recorded on CD-Audio a software or hardware? No. Is it in Debian? 2) Is Debian/main printed as book a software or hardware? No. Is it (still) in Debian? 3) Why? What differs from 0,1? It doesn't. 4) Is Debian/main printed into punch-cards a software or hardware? The punch cards themselves are hardware; however, the information contained on the punch cards is still software. 5) Why? What differs from 0,1,2? A computer can make sense of it without stuff like OCR software. 6) Is Debian/main written on CD-ROM a software or hardware? The CD-ROM itself is hardware; however, the information contained on the CD-ROM is still software. 7) Why? What differs from 0, 1,2,4? No difference with 4, but differences with 0,1,2 as in 5. 8)Is Debian logo written on [cover of] the same CD-ROM software or hardware? No. Is it in Debian? 9) Why? What differs from 0, 1, 2, 4, 6? ... (hey, I'm not going to reiterate that every time!) 10) Is Debian installation, hardcoded into embedded system software or hardware? The chips containing the Debian installation are hardware; however, the installation itself is still software. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: solution to GFDL and DSFG problem (dadadodo at work?)
On Sun, Sep 28, 2003 at 05:46:30AM -0400, Anthony DeRobertis wrote: Branden, this level of email forging skills is completely unacceptable from someone as nefarious as yourself. I request --- no, demand --- that you take a few days to edumacate yourself on this matter. I mean, really, the only way you could of done worse would be to sign the damn thing. PS: Was that dadadodo? http://www.google.com/search?q=65.26.182.85+site%3Alists.debian.org You don't even have to go through that much of a hassle. Old-Return-Path: [EMAIL PROTECTED] Right. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: GFDL
On Tue, Sep 23, 2003 at 07:13:30PM -0400, Richard Stallman wrote: I would not release a reference card under either the GFDL or the GPL, because both of them are long enough that the requirement to distribute them along with the reference card is burdensome. But surely this doesn't imply they are non-free licenses. I've never seen any company print and distribute a single reference card. The costs for doing so highly outweigh the benefits. Usually, what people do is distribute a number of reference cards at once -- say, one for emacs, one for bison, one for gcc, and so on. Given all such manuals would be distributed under the terms of the GPL, one can get away with distributing a single version of the GPL. With the GFDL, you can also distribute a single version of the GFDL itself, but you must also distribute a copy of all of the invariant sections. With the GFDL'ed reference card, since the Invariant Section text is the majority of the text, I'd be doubtful that it could qualify as Secondary at all: it may be the main topic by sheer volume. So it may not even be distributable. The invariant sections don't define the main topic, because interpreting them as the main topic is inconsistent with the GFDL's requirement that they be secondary. That's putting the horse behind the wagon. A secondary section must not be a section about the main topic. However, if there are many secondary sections, in a reference card situation there may be more text in the secondary sections alone than in all other sections combined. One could wonder whether, at that time, they would still fulfill the definition of 'secondary'. You say 'they do not define the main topic, because they are secondary'. However, the statement being made was 'They are no longer secondary, because they define the main topic'. There's a world of difference there. Further Invariant Section problem: I can't use parts of the GCC manual in an essay on the funding of free software For the manual to be free, you must be able to publish a modified version of the manual. In other words, a modified manual. Being able to use some of the text for something of a different kind, such as an essay about the funding of free software, is something above and beyond the call of duty for a license. This is our main point of disagreement, I think. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Why documentation and programs should not be treated alike
On Tue, Sep 23, 2003 at 07:13:13PM -0400, Richard Stallman wrote: In the compiled form of a manual, as long as there is no DRM to stop you from reading it, everything that matters is plain to see. You see the contents, and you even see the fonts and indentation that were selected by the markup. The markup commands, which you don't see, and any comments in the markup, are far less important than what you do see. If you can read the published manual, what you see is everything that really matters. That is not always true. Some of the document formats you have defined as Transparent include conditionals, loops, and other programming constructs. As an example, have a look at /usr/share/doc/gs/examples/waterfal.ps ; but the same is true for (La)TeX. With such formats, a manual could be written that would exclude all non-relevant system-specific data based on the operating system or kernel it was converted on -- for instance, a manual written in LaTeX that explains installing, configuring, and running a specific program could only include the FreeBSD-specific parts when 'compiled' on a FreeBSD system. In that case, you don't just lose comments and markup constructs, but also content. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A possible GFDL compromise: a proposal
On Sun, Sep 21, 2003 at 09:29:54AM -0400, Richard Stallman wrote: The DFSG explicitly codifies my specific decision about TeX,=20 It does nothing of the sort; there is no mention of the word 'TeX' in the DFSG. Section 4 does precisely that, though without mentioning TeX by name. In other words: I can live with Donald Knuth issuing a license in the gray areay between free and non-free. I cannot live with the same thing coming from the FSF. The GFDL is free according to our standards. If you wish to view the matter otherwise, you're entitled to your opinion. Someone else criticized the idea (though no one had proposed it) of giving the FSF special consideration; now you seem to be saying just the opposite, that you believe in giving the FSF less cooperation that you would give to anyone else. No, that's not true. I'm saying that, when it comes to freedom, I expect a higher standard from the FSF than I do from D.E. Knuth. I'm not suggesting we should stop cooperating with the FSF. is that the Debian Project could end up being better friends with the Open Source Initiative than with the FSF; while most Debian Developers and users nowadays think the FSF is a good organization[1], this might change if the FSF insists on having those Invariant Sections.\ The FSF has lived with contant criticism for many years. Say what you wish; we will make no concession to threats like this. I'm not trying to be a 'threat' to you; I'm just suggesting a possible future, and am asking you whether you have considered it. If you have, good; if you haven't, please do. I for one will know what the FSF stands for, and will not easily be pursuaded to think of the FSF as an '3v1l' organization, but I'm not sure everyone thinks that way. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A possible GFDL compromise
On Sat, Sep 20, 2003 at 05:27:46PM -0400, Richard Stallman wrote: Remember the hypothetical emacs reference card, which must be accompanied by 12 pages of additional invariant material? Sounds like a big deal to me. If the GPL were used, it would have to be accompanied by 6 pages of additional invariant material. That is still bigger than the reference card. Do you object to the GPL on these grounds? The reference card would have to be accompanied by the GPL, yes, but it would not require the text of the GPL being printed on it. With the GFDL, this requirement is there. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: A WDL.
On Sat, Sep 20, 2003 at 05:41:09PM +0100, Andrew Suffield wrote: On Sat, Sep 20, 2003 at 04:42:51PM +0200, Wouter Verhelst wrote: I don't think the GFDL is a good place to start from when writing a documentation license, really. The WDL is a tangled mess. Start with the GPL instead, and try to answer this question: What do I want that this license does not already give me? There's nothing which is not in the GPL that I don't want. Wat I /do/ want, however, is a Free Emacs manual in Debian. Amongst others. I've been convinced that this won't happen with the GFDL, and I'm also quite convinced the FSF will not likely drop the GFDL unless an acceptable (to them) alternative is provided. Therefore, I took to crafting an alternative. Whether the alternative will be accepted by the FSF remains to be seen; but there's no harm in trying (other than that I risk wasting a lot of time in a project with no practical results). Well, the stated goal of the FSF is, as far as I can tell, inherently non-free. So I don't think this is actually possible. I don't have a lot of hope either, but that doesn't mean I shouldn't try. If you could get them to compromise on their goal to some extent, then it should be fairly easy to write a suitable license based on that. Again, that is an alternative (and viable) way to do it, but I find it easier to work in this way. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: Starting to talk
On Mon, Sep 22, 2003 at 04:14:45PM +0200, Mathieu Roy wrote: Mike Hommey [EMAIL PROTECTED] a tapoté : On Monday 22 September 2003 14:32, Mathieu Roy wrote: The point is whether every software needs to be free or just program and their documentation. The point is whether every software IN DEBIAN needs to be free. You are right, that's the question. Free, in think that everybody agree, but under which definition of freedom? Does the DFSG definition of freedom that applies to program (nobody question that) help us to draw the line at the correct place also for documentation? In other terms, do we consider the fact that we cannot modify a political essay in a documentation so harmful that we would prefer stopping delivering this documentation? Yes. That is indeed the question. I think personally that it is harmful to do so That is without question, but that does not mean we should not do so (because the alternative isn't much better) and harmless to let that essays where they are, Harmless, perhaps. The right thing to do, no. since they do not interfere with the program and documentation usability. What do you think? Saying it's not DFSG-compliant is not an answer. It is. Moreover, it's the only correct answer. Apart from MJ Ray, which think that any document should follow the Free Software rules, software or not, nobody against the GFDLed text inclusion clearly stated his point of view. Please. Read http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg01031.html and the thread that follows it. Or, if you don't have much time, that message and http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg01680.html -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A possible GFDL compromise: a proposal
Op za 20-09-2003, om 09:50 schreef Richard Stallman: At the start of the GNU Project, I was in a similar situation. When I wrestled with the question of whether TeX was free software, I did not owe Donald Knuth any special consideration, but I did want to use TeX in the GNU system. The most obvious place to draw the line would have rejected TeX's license, but that was not the only place to draw the line. I asked myself if it was really unacceptable to draw it in a place that would allow that license. I concluded that was acceptable, that TeX does provide the necessary freedom though in a somewhat inconvenient way, and that it would have been counterproductive to reject the license on account of that inconvenience. If you're suggesting that we should not reject the license on account of that inconvenience, I disagree. There's a difference between that situation, and the current issues with the GFDL. The difference is that Donald Knuth was not trying to create a Free operating system, while the FSF is. As a result, it can be understood that D.E. Knuth's license would not be completely and openly free, whereas that should not be the same for a license by the FSF. In other words: I can live with Donald Knuth issuing a license in the gray areay between free and non-free. I cannot live with the same thing coming from the FSF. Subsequently I generalized this to the idea that any sort of packaging requirement for publishing modified versions was acceptable in a free software license, as long as it was feasible to meet and did not substantially limit the substance of the changes. The DFSG explicitly codifies my specific decision about TeX, It does nothing of the sort; there is no mention of the word 'TeX' in the DFSG. What it /does/ do, however, is allow for the requirement of patch files for modification. Not because that is an inconvenient packaging requirement for publishing modified versions, but because it allows the modification of the /entire/ work. The packaging requirements are not of our interest when it comes to the freedom of a program (it is important in other areas of Debian, of course, but not in our principles); only the fact whether or not one is allowed to modify the software is. but doesn't explicitly say anything about the rest of the issue. I recommend interpreting it in a way that follows this principle. That's not the right way. The wording of the DFSG does not allow that. [...] On a side note: I think it's important you check your goals. If I read the general tone of your mails right, the reason you (personally, or the FSF) chose to use Invariant sections in your license is so that you can spread the word about free software without the risk of it being removed by someone who does not agree with your ideas. Propaganda, as some called it. Correct? You also say it's still required, because the Open Source Initiative, who disagrees with you in certain aspects, has more momentum than you have, and you want the Free Software movement to grow, not the Open Source Initiative, because you think the ideas behind the latter would not be good for Free Software in the long term. Still correct? If so, are you sure the Invariant Sections will do what you want them to do, i.e. make sure more people will submit to the ideas of the Free Software Foundation? A worst case scenario (from your point of view, at least) is that the Debian Project could end up being better friends with the Open Source Initiative than with the FSF; while most Debian Developers and users nowadays think the FSF is a good organization[1], this might change if the FSF insists on having those Invariant Sections. As a result, instead of having Invariant Sections spreading the word of Free Software, resulting in more people supporting and/or joining the FSF specifically, and the Free Software movement as a whole, the net effect of the Invariant Sections may be that there could be another split of the Free Software movement, as has happened with the Open Source people before. Are you sure that is what you want? [1] not that I believe in 'good' and 'bad' organizations, but you know what I mean. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: A WDL.
I didn't reply to this yet, but I should've; I thought I had. On Wed, Sep 17, 2003 at 02:22:11AM +0100, Andrew Suffield wrote: [WDL] I'm not yet convinced as to whether it's DFSG-free or not, but if I had to make a spot decision right now, I'd say not. That's why I requested feedback. As long as (at least) the consensus on this list is *not* that the WDL is DFSG-free, it is not finished. I don't think the GFDL is a good place to start from when writing a documentation license, really. The WDL is a tangled mess. Start with the GPL instead, and try to answer this question: What do I want that this license does not already give me? There's nothing which is not in the GPL that I don't want. Wat I /do/ want, however, is a Free Emacs manual in Debian. Amongst others. I've been convinced that this won't happen with the GFDL, and I'm also quite convinced the FSF will not likely drop the GFDL unless an acceptable (to them) alternative is provided. Therefore, I took to crafting an alternative. Whether the alternative will be accepted by the FSF remains to be seen; but there's no harm in trying (other than that I risk wasting a lot of time in a project with no practical results). Then, *without* attempting to write a license that meets these goals, just list them. We can probably deal with this more quickly based on evaluating whether and under what conditions those goals could be acceptable under the DFSG. That's a possible approach too, of course, but I think it's easier to debate over an actual text than over a hypothetical one. YMMV. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A WDL.
On Sat, Sep 20, 2003 at 04:42:51PM +0200, Wouter Verhelst wrote: There's nothing which is not in the GPL that I don't want. Uh. Obviously I meant there's nothing in the GPL that I would want -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: A WDL.
On Thu, Sep 18, 2003 at 12:33:46AM -0500, D. Starner wrote: *** Disclaimer The Unicode Character Database is provided as is by Unicode, Inc. No claims are made as to fitness for any particular purpose. No warranties of any kind are expressed or implied. The recipient agrees to determine applicability of information provided. If this file has been purchased on magnetic or optical media from Unicode, Inc., the sole remedy for any claim will be exchange of defective media within 90 days of receipt. This disclaimer is applicable for all other data files accompanying the Unicode Character Database, some of which have been compiled by the Unicode Consortium, and some of which have been supplied by other sources. Limitations on Rights to Redistribute This Data Recipient is granted the right to make copies in any form for internal distribution and to freely use the information supplied in the creation of products supporting the Unicode^TM Standard. The files in the Unicode Character Database can be redistributed to third parties or other organizations (whether for profit or not) as long as this notice and the disclaimer notice are retained. Information can be extracted from these files and used in documentation or programs, as long as there is an accompanying notice indicating the source. *** We can make copies _in any form_ _whether for profit or not_. Where's the problem? No grant to modification, perhaps? (although that probably wouldn't be extremely helpful, but anyway) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: A possible GFDL compromise: a proposal
Op di 16-09-2003, om 21:03 schreef Richard Stallman: Debian especially is concerned with the fact that we can't imagine all the future ways of publishing. How can we tell that it isn't a prohibitive requirement? We have to try. If we accept this, or any, reason to say that any requirement might perhaps be prohibitive, and reject any and all requirements, that leaves rather few acceptable licenses. Maybe none. There's a difference. 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.) The GFDL does not even allow patch files. This requirement is too prohibitive by Debian's standards. Simple. Your above statement falls in the FUD class. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: A WDL.
Op wo 17-09-2003, om 01:06 schreef Anthony DeRobertis:
On Thu, 2003-09-11 at 06:26, Wouter Verhelst wrote:
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.
I think you should address what happens if a document undergoes subject
creep such that what was formerly a secondary section no longer is.
Sounds reasonable, but not easy.
Will have to think that over.
The Opiniated Sections are certain Secondary Sections which are
I agree with others that Opinion or Editorial would be a better
term.
'kay, will call them 'editorial', then.
A Transparent copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public,
Some formats aren't well-specified, yet should still be usable. HTML _as
practiced_, for example.
Also, what does it mean for a specification to be available to the
general public? It must be freely downloadable? It must be under a
license no more restrictive than this one? It must be available for no
more than $200?
It should mean freely downloadable. As said, I'm not entirely happy with
the wording of that paragraph.
AFAIK, the PDF spec is only available for a price.
Ah? I wasn't aware of that.
Same with the ASCII
and Unicode specs.
That may have been the case, but try man ascii, or man utf-8 ('unicode'
as is is pretty useless, AIUI)
for which an editor can be implemented by anyone,
without requiring an implementer to have patent or other licenses to
that format.
Perhaps a better wording would be can be implemented without requiring
patent or other licenses
sounds good, indeed.
Though I think we might want to allow formats
where there are patents, but the patent holder makes the patent
available for royalty-free use by the public for any purpose (i.e.,
defensive patents)
You wouldn't require a patent license for defensive patents; if you
would, the format wouldn't be free (since you would have to ask for
permission to extend or modify the format). Hence, I don't think that's
an issue.
2. Verbatim copying
You may not put
the document on any medium intended for general redistribution whose
technical specifications make it impossible, or mostly so, to make
unlimited copies of the document to another medium.
I can't put the document in an embedded device? I suggest adding
something along the lines of unless you also provide a medium with the
same document in easily copyable form.
That's reasonable.
You must use the Cover Texts as stated in the license notice, putting
Front-Cover Texts on the front cover, and Back-Cover Texts on the back
cover.
I don't think invariant front-cover and back-cover texts are DFSG free.
I'm inclined to think along the same way too, now. At first, I thought
it could be allright to have invariant, short, front- and back-cover
texts, provided you can completely drop them under certain
circumstances. I was probably mistaken.
I *could* drop the front-cover and back-cover sections, but that will
probably make the FSF reject the license. For instance, the back-cover
section of the gcc manual contains wording that encourages people to buy
a version printed by the FSF itself, because selling CD-ROMs and printed
books is one way the FSF makes money.
That doesn't mean I don't want to see this changed; only that this gives
me a dilemma.
[...]
The front cover must present the full title
with all words of the title equally prominent and visible.
Why must all words of the title be equally prominent and visible? It
seems common practice in publishing to makes words like and smaller
and less prominent.
I took that text literally from the FDL; I didn't see any reason why not
to. But indeed, maybe that should become something along the lines of
'the front cover must clearly and visibly present the full title', or
so.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
I dare say this is a pretty good sign the license isn't free...
See above.
If you publish or distribute Opaque copies of the Document,
The GFDL only made a lot of this apply for 100 copies or more. I think
that may be a good idea, but I don't think it changes the freeness of
the license.
download using public-standard network protocols a complete
public-standard network protocols ?
Seems clear to me. any network protocol which is a public standard.
What am I missing?
G. Preserve in that license notice the full list of required Cover
Texts given in the Document's license notice.
Grrr
See above.
K. For any
Re: A WDL.
Op za 13-09-2003, om 09:10 schreef Brian C: I'm a little concerned about merely offering a link to things. FSF has always argued against this as regards offers of source, That's not really true anymore. In the very text of the FDL, the FSF allows people to have 'a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material,' as a sufficient alternative when distributing an Opaque version. in particular because there are parts of the world where 56k access speeds would be fast, and because some are charged per minute for such access. Perhaps documentation doesn't get so large, but in general, putting the burden on distributors might be better. I partially agree. Indeed, having distributors distribute the Transparent version along with the Opaque seems better, since you don't want people to have to pay much to be able to contribute. There are arguments for the opposite, however. For one thing, about 12 years ago when the GPLv2 was written, not many people knew that there was something called 'the Internet', and that you could have access to it at home; and if you had known that it existed, your access speed would not be above 14400bps, which is a fraction of 56k. For another, when distributing computer programs on a CD-ROM, it's easier to distribute the source code along with it than it is when publishing a book, which cannot be anything else than an Opaque version of the document. I'm not too emotional about this, though. If more people think like you, I'll change it. I'm also unaware of free software that modifies all .pdf documents, and even if there is such a thing, it seems likely to me that Adobe might pursue patent infringement claims on such software, so I'd prefer .pdf be cut from the list of acceptable transparent formats. Do you think the same about 'PDF designed for human modification', as well? Also, as I said before, I don't think that the unavailability of free software to modify a document format makes the format non-free. Next, I'm not aware of any patents on the PDF format. Do you have more information on that one? -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: A WDL.
Op zo 14-09-2003, om 16:07 schreef MJ Ray: On 2003-09-14 12:08:02 +0100 Wouter Verhelst [EMAIL PROTECTED] wrote: There's no markup or placing requirement; you could put them in small print somewhere in the document; at the first page, at their original place, or perhaps on the back cover. I specifically did not make any other requirement than that they have to be there. White text on a white background behind the text of another page? Well, that would defeat the purpose, of course, but I doubt any sensible judge would approve that as 'being there'. That sounds a lot like saying I didn't steal your car; I just made it invisible. It's right there! -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: A WDL.
Op zo 14-09-2003, om 17:48 schreef Etienne Gagnon: I don't understand... Why go through all the trouble of writing a WDL? Why not stick with using normal software licenses (GPL, LGPL, X11, BSD-3clauses,...) for documentation? There are parts of the FDL that actually make sense, such as the fact that the definition of 'source code' is not necessarily the same for documentation as for computer programs; or the 'Endorsement sections', which seem to be primarily intended for standards documents; one can modify a document with an endorsement section, but that section, which could say that the document describes some standard, has to be removed, so that it is clear that the document no longer describes any standard. That doesn't mean they wrote their license perfectly; only that I can agree that a GPL is not perfect for all sorts of documentation, and that there is a need for a license intended for works with documentation purposes. Anyway, the presence of invariant/opiniated/whatever non-free parts in the body of the *licensed-work* will hardly ever meet the requirement of the DFSG, unless the DFSG is amended. The DFSG doesn't forbid sections which require you to jump through a number of hoops to modify the work, as long as everybody has the same rights, and everything can be modified (safe the license or the license notice itself). I crafted my WDL with that in mind: make someone jump through hoops to be able to modify those particular sections, but *do* allow them to modify or remove those sections *in any case*. The alternative would have been to create a license which would not require anyone to jump through any hoops to amend or remove parts of the work, but it seems *very* unlikely that the FSF would accept that. And, after all, the whole idea was to give the FSF (or, perhaps, the community as a whole) a more or less acceptable alternative to the GFDL. I think creating an alternative is a better way to handle a situation like the current than constantly expressing your dislike with a certain license. Agreed, I wouldn't do that for each and every license out there, but I'd say the FSF is different in that they do, honestly, want to have free documentation. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Attribution-ShareAlike License
On Fri, Sep 12, 2003 at 07:40:43AM -0400, David B Harris wrote: If I develop a really spiffy document format for, say, a braille machine, document it thoroughly and publish it, and either don't take any patents out of it, or file one of those strictly-prior-art-to-stop-somebody-else-from-patenting-it patents, but my own implementation of the tools are non-Free, I don't want the file format itself to be considered non-Free. The ability to create a Free editor exists. No licensing fees, no patent battles, nothing. Agreed. Which is why my WDL defines Transparent formats in that way :-) Rg, Wouter (who wonders whether his mail about that subject has gone unnoticed on the otherwise so active -legal) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpUQXzkUzAo6.pgp Description: PGP signature
Re: Attribution-ShareAlike License
On Fri, Sep 12, 2003 at 05:22:46PM +0300, Richard Braakman wrote: On Fri, Sep 12, 2003 at 02:18:10PM +0200, Wouter Verhelst wrote: Wouter (who wonders whether his mail about that subject has gone unnoticed on the otherwise so active -legal) I just thought it was far too long. I think that about most new licenses :( I won't deny it's long. However, as it's based on the FDL (which I assume many people on this list know quite well already), I suspect an analysis should be shorter than the analysis of another license of approximately the same length. Even if you don't feel like reading everything, just skimming over it, and saying whether or not you think it's a good idea would be very much appreciated. To date, I've had 2 off-list replies for something which took me almost an entire day to write, and a few weeks to conceptually prepare. That's quite discouraging. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpv7fkQUuHFc.pgp Description: PGP signature
Re: Attribution-ShareAlike License
On Fri, Sep 12, 2003 at 08:08:11PM +0100, MJ Ray wrote: On 2003-09-12 19:18:18 +0100 Wouter Verhelst [EMAIL PROTECTED] wrote: took me almost an entire day to write, and a few weeks to conceptually prepare. That's quite discouraging. It was MIME'd, base64'd, marked as attachment instead of inline and in a charset that I don't use. Right. Got it. I didn't detach it yet. I have no idea why you made it so difficult for people to read it. Misbehaving email client? Sent it using evolution; yes, it was probably misbehaving. Seeing as you're so unhappy, I'll go back now, decode it and read it through, but I suspect that's why some didn't bother. Hm. I've put them up on http://www.grep.be/wdl/wdl.txt and http://www.grep.be/wdl/wdl-fdl-differences.txt Thanks. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpm450Ok9qBB.pgp Description: PGP signature
Re: A WDL.
On Fri, Sep 12, 2003 at 02:05:19PM -0500, Branden Robinson wrote: On Thu, Sep 11, 2003 at 12:26:07PM +0200, Wouter Verhelst wrote: As I tried to point out in the recent discussions about the GFDL (not sure whether that point has come through, but anyway), although the GFDL is crafted in a way which makes it not DFSG-free, IMHO there is nothing wrong with the spirit, the intention, of the GFDL. Well, I personally have had a lot of trouble eliciting information about what precisely the GNU FDL's intent *is*, at least when it comes to particular properties that distinguish it from other licenses. I think that in the course of crafting an alternative license, we should be able to come up with that. I think a more fruitful approach for developing a documentation license might be to enumerate our intentions before constructing the license. I have considered that alternative too, but dismissed it because I think it's easer to modify an existing text than it is to agree what you want to modify, followed by the actual modification. As such, I've taken the GFDL, and modified it in a way that retains the spirit of the GFDL, but results in a license which is, IMO, DFSG-free. I'm assuming the text of the GFDL is copyrighted in the same way as the GPL is, so I renamed it to the WDL, for Wouter's Documentation License -- that's just until I find a more suitable name for it. I do not have the strength of will to perform an analysis at this point, and commenting on parts that happen to be similar or identical to the GNU FDL would, in my opinion, run afoul of the self-censorship on the subject that Bruce Perens has asked me to practice.[1] Sure. No problem. I will make a couple of meta-observations, however: Wouter's Documentation License Version 1.0-DRAFT Copyright (C) 2003, Wouter Verhelst Since you frankly admit that this document is derived from the GNU FDL, surely they retain their copyright in it? Obviously. I started writing it with the intention of creating something that would be, in letter, completely different, but ended up copying large blocks of text for which I didn't see a need to change. I forgot to change that statement. Fixed now, thanks. If so, then it might be a good idea to ask the FSF for permission to make a derived license. Uh, right. Will do. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpTAV7XMfJXx.pgp Description: PGP signature
Re: A WDL.
On Fri, Sep 12, 2003 at 08:23:23PM +0100, MJ Ray wrote: Thoughts on WDL: Is opiniated really a word or a smelling pistake? There's probably some better name. Agreed, but opiniated was the best I could come up with. In any case, since it can be modified, invariant surely is a bad name. It's been brought to my attention, however, that 'opiniated' is a strange construct in the English language, and that 'opinionated' would be better. I'm not a native English speaker; I'll leave that to the experts. What's important is the definition, not the wording, so if someone comes up with a word that better defines what these sections do, I'll happily use that word. They also don't seem to meet FSF's requirements. I don't know. Perhaps. At least there's no harm in trying. The labelling requirements for removed sections seem nasty too, adding more unmodifiable parts to the document. They're just one line. That's a hell of a lot less than an entire GNU Manifesto, for shouting out loud. I agree that it is a restriction, but I could not *entirely* drop the Invariant sections from this license -- at least not if I would want a slight chance for the FSF to accept it. These 'opiniated' (or 'opinionated', if you want) sections allow for modification (which should make it DFSG-free), but (intentionally) require you to jump through a number of hoops, so that they cannot be dropped in a whim (so that it could still be used to distribute propaganda, if required). The idea is that you'd want to sent a message to someone interested in modifying the information, saying, You're allowed to modify this part of the text if you really want to, but you shouldn't do that unless you have a *very* good reason for it. RMS called the Invariant sections a practical inconvenience, which does not make the FDL non-free. I disagree, and I think a lot of people on this list do as well; but I'd like to hope that that description does apply to these 'opiniated' sections. I still don't like the labelling requirements (cover texts) but that's just a dislike. Embedding them in the unmodifiable licence notice feels sneaky. Are they legal notice or really part of the work? They're part of the work, but they have a special status in the license. Technically, I could require them to be marked the same way as the opiniated sections, but since they're so short, I think that's pretty silly. I don't understand substance and tone if it is modifiable. That's literally taken from the FDL. The idea is, AAUI, that you have to retain any acknowledgements and/or dedications, but that you can rephrase or translate them, if required. I think this is nearing the edge, but have kept it, to keep the discussion open. Replacement Opaque definition also seems a bit wooly and arguable. Yes, I've said that in my explanation. The problem is that this is a translation of a definition of 'Free Specification', as defined by the group behind openstandaarden.be -- a definition written in the Dutch language. This definition says that a file format or transport protocol should be freely (as in beer) available on the Internet, containing enough information to write a conforming application to be an 'open specification', and that it also should not be patent-encumbered, license-protected, or be protected under other legal restrictions to be a 'free specification'. Openstandaarden.be goes on to define the 'open standard', which is a free specification backed by a standards-body, but I wasn't sure whether that would be required for the purpose of a documentation license. I hope this explains what I tried to do there, but I couldn't find a clear enough wording to use in that paragraph. What an Opaque format is, should be easy: everything which is not Transparent, is Opaque. A few other errors a spellcheck should correct for you. hits himself Right. I *knew* I was forgetting something when I mailed it. I'll do that tomorrow, though. Way too tired to concentrate on that right now :) What copyright is the FDL under and is the WDL allowed to contain so much of it? Branden brought that up as well. I just sent a mail to the FSF, requesting permission. I do not anticipate any problem, but will remove both texts from my website should the FSF not give permission. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpChIBRwjmQJ.pgp Description: PGP signature
A WDL.
Hi, As I tried to point out in the recent discussions about the GFDL (not sure whether that point has come through, but anyway), although the GFDL is crafted in a way which makes it not DFSG-free, IMHO there is nothing wrong with the spirit, the intention, of the GFDL. As such, I've taken the GFDL, and modified it in a way that retains the spirit of the GFDL, but results in a license which is, IMO, DFSG-free. I'm assuming the text of the GFDL is copyrighted in the same way as the GPL is, so I renamed it to the WDL, for Wouter's Documentation License -- that's just until I find a more suitable name for it. As said, IMO this WDL is DFSG-free, but I'd like -legal's input on this. There might also be some parts which aren't perfect from a legal POV; IANAL, and I could've made a number of (slight|serious|) mistakes. Attached, the text of the WDL, as an ASCII text file, and another ASCII text file enumerating the differences between the FDL and the WDL, with a bit of explanation. Respectfully, -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. Wouter's Documentation License Version 1.0-DRAFT Copyright (C) 2003, Wouter Verhelst 1. Applicability and definitions This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The Document, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as you. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A Modified Version of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. 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. (Thus, 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. The Opiniated Sections are certain Secondary Sections which are clearly marked, at the start and the end of the Secondary Section, as being an Opiniated Section. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Opiniated. If the Document does not contain any sections marked as Opiniated Sections then there are none. The Cover Texts are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A Transparent copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, for which an editor can be implemented by anyone, without requiring an implementer to have patent or other licenses to that format. A format designed as an output format, rather than an editable format is not suitable for a Transparent copy. A copy made in an otherwise Transparent file format whose markup, or absense of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not Transparent is called Opaque. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include formats for which the specification is not widely available, such as those used by some proprietary word processors, SGML or XML for which the DTD is not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The Title Page means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, Title Page means the text near the most prominent appearance of the work's title
Re: free source code which requires non-free tools to build (dscaler modules for tvtime)
On Thu, Sep 11, 2003 at 02:36:13PM -0500, Branden Robinson wrote: Is Not an Emulator.) It may be worth asking the FSF. They have an email address for license questions, but I have forgotten what it is. [EMAIL PROTECTED] It's something along those lines, for sure. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: Bug#181493: SUN RPC code is DFSG-free
Op wo 10-09-2003, om 03:27 schreef Manoj Srivastava: On Mon, 08 Sep 2003 22:17:07 +0200, Wouter Verhelst [EMAIL PROTECTED] said: Op ma 08-09-2003, om 18:42 schreef Manoj Srivastava: Since our users and the DFSG are equally important, one should not try to solve one of those problems *at the cost* of the other, and *certainly* not if one is not willing to provide a solution. The DFSG is indeed in our users best interest -- unless you think that shipping non-free in main helps the users who use those bits, and thus users interest should render the DFSG irrelevant, since the users can benefit. This is a deeply flawed argument. So is saying that not shipping with an RFC implementation is in our users' best interest, or saying that holding up the release is in our users' best interest. Is it? Propreitary software can indeed provide value, and is often useful to people -- which is why the company is in business. And yet, we have coalesced a volunteer effort around the premise that libre software is better. Do you mean to say that the one and only property about Debian we should be proud of is the fact that it consist of 100% free software? Do you mean to say that the one and only goal we should pursue is to make, and keep, Debian 100% free software? You know, that would make my life a lot easier. I could stop caring about bugs. Shut up, you -- it's free software, you should be glad about that. If you think that this premise is flawed, then I wonder how you passed the philosophy section of the NM process. I passed the philosophy section of the NM process, because I agreed that our users and free software are equally important. Yes, delivering free software is in the best interest of our users. That doesn't mean it's the *only* thing which is in the best interest of our users. And since our Social Contract declares them to be equally important, at times they can be in conflict. I think this is one such occasion. Either way results in an action in conflict with the social contract. The question is: what's the least of the two evils? Or, who gets to decide what is the users best interest? That is another way to put it. That's a judgement call we have to make, and it may well be different if you make it, as compared to if I make it. Especially since it's not clearly defined anywhere what's actually 'in the best interest of our users'. As a consumer of food, my predilection as a child was overwhelmingly in favour of fast food -- tasty, convenient, and yet, according to my health care professional, inordinately bad for me. Non free software, despite its allure, is, in my opinion, bad for the users. I agree; however, this is about more than just whether the RPC code is free or not. If that weren't the case, I wouldn't be part of this thread. And you think our users are best served by non-free software? Our users are best served by useful, working software. Even when it is not free? That's not what I said. Oh, wait, I get it. You're saying that the *only* thing we should care about is whether our software is free. All the rest is secondary, not even worth considering. I thought our users and Free Software were *equal*. No, I'm not saying we should ignore the fact that the RPC code is non-free, if that is the case. Yes, I'm saying we should take care not to over-react, and to make sure whatever action we take is in the best interest of our users. If that means to ship with non-free code in a core part of our distribution, then so be it. No, I'm not saying we should ship sarge at the set date at all cost, even if that means shipping with non-free parts inside; I'm just saying we should consider all alternatives, and do what's best for our users. Someone has to make the judgement call. It happened to be aj. If you're not happy with his decision, you're free to use the powers given to you by our constitution. Or to fix the problem, as I suggested in my original post. Although, in hindsight, I could've been a bit more polite. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: A possible GFDL compromise
Op ma 08-09-2003, om 22:39 schreef Anthony DeRobertis: On Monday, Sep 8, 2003, at 15:44 US/Eastern, Wouter Verhelst wrote: Sure. You can offer/provide it alongside, or you can give the offer (good for three years) to provide it at cost. ITYM 'at a reasonable price for distributing the media' :-) No, for a charge no more than your cost of physically performing source distribution. (GPL 2(b)). So, 'at cost.' Ah. I assumed that phrase was grammatically incorrect, and that it required something like 'at a cost', or better yet, 'at a price'. Which would be blatantly incorrect. That'll teach me :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: GFDLed and preferred form
On Tue, Sep 09, 2003 at 09:46:41PM +0200, Mathieu Roy wrote: I _am_ providing the source. The preferred means for editing my thesis is with LyX. The problem is that the GFDL doesn't think that an open format easily modified with free software qualifies. I'm not especially familiar with LyX but I though it was similar or based on LaTeX. As LaTeX files are ok for the GFDL, shouldn't be the same? It is based in concept on LaTeX, you can make it export files that can be processed by LaTeX (and vaguely resemble it, too), and you can import some (not too exotic) LaTeX-files into LyX. That is not the recommended way to do it, however, and the LyX file format is completely different. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpYCimd5sP2q.pgp Description: PGP signature
Re: A possible GFDL compromise
ckOp ma 08-09-2003, om 18:40 schreef Anthony DeRobertis: On Sunday, Sep 7, 2003, at 14:10 US/Eastern, Andreas Barth wrote: Think of the DRM-version of the binary and the non-DRM-version as the source. It is certain legal to give away binaries (aka DRM-enabled versions) as long as you also provide access to the source. Sure. You can offer/provide it alongside, or you can give the offer (good for three years) to provide it at cost. ITYM 'at a reasonable price for distributing the media' :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Bug#181493: SUN RPC code is DFSG-free
Op ma 08-09-2003, om 18:42 schreef Manoj Srivastava: Since our users and the DFSG are equally important, one should not try to solve one of those problems *at the cost* of the other, and *certainly* not if one is not willing to provide a solution. The DFSG is indeed in our users best interest -- unless you think that shipping non-free in main helps the users who use those bits, and thus users interest should render the DFSG irrelevant, since the users can benefit. This is a deeply flawed argument. So is saying that not shipping with an RFC implementation is in our users' best interest, or saying that holding up the release is in our users' best interest. Either way results in an action in conflict with the social contract. The question is: what's the least of the two evils? That's a judgement call we have to make, and it may well be different if you make it, as compared to if I make it. Especially since it's not clearly defined anywhere what's actually 'in the best interest of our users'. In this particular case, with code being so important to a major part of our users, given that our users and the DFSG are, per the Social Contract, equally important, and given that the piece of code in dispute *is* already in stable, I'm saying we should not hold up the release to write a replacement. However, if *you* are willing to write a replacement, and are willing to hold up the release for that, I will support you, but then you should make sure the code is at least as good as the RPC code which *is* in glibc right now. Not doing so would be a disservice to our users, and not worth the effort. I see. Some non free software is too inconvenient to give up, so we should whore out our principles, I'm not suggesting that. But making sure our software is useful is part of our principles, too. [...] sarcastic It would probably hold up the release for yet another year or two, but who cares about such things anyway? /sarcastic I think I do care more for libre software than I do about releases and market share. Again, I couldn't care less about market share. However, I do care about what's in the best interest of our users. If our users go away to a different distribution because that one is not useless to them, surely some choice we made was not in their best interest. [...] Actually, pulling that code out would be a major disservice to our users. It's already in there. Our users expect it to be there, or at least, they expect a functionally equivalent part of code there. Our users also expect us to act with a degree of correctness, and who depend on our ethics. If the code is truly free, then sure, there is no problem. State your case. If the code is not free, then we do have a problem to resolve. I'm not saying we don't. The question is whether it really needs to happen *now*. and would lose Debian important market share, and we can't possibly let scruples stand in the way of market share, can we? I couldn't care less about market share. I do care about the social contract, though, which says 'Our priorities are our users and free software'. And you think our users are best served by non-free software? Our users are best served by useful, working software. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Bug#181493: SUN RPC code is DFSG-free
On Sat, Sep 06, 2003 at 05:49:36PM -0500, Manoj Srivastava wrote: On Sun, 7 Sep 2003 00:19:32 +0200, Wouter Verhelst [EMAIL PROTECTED] said: On Sat, Sep 06, 2003 at 10:39:33PM +0100, Andrew Suffield wrote: On Sat, Sep 06, 2003 at 11:10:19PM +0200, Wouter Verhelst wrote: Please, guys. He isn't saying he has final say in whether or not the Sun RPC code is DFSG-free; he's just saying it shouldn't hold up the release. When did we decide that release dates were more important than the DFSG? We didn't. At least not officially. But to 'some' of us, it does matter. /sarcastic In any case, the solution is easy (as I said in my mail, in the part you conveniently snipped away): stop the bickering, get your hands out of their sleeves, and write that RPC code. Free of bugs, and standards-compliant, mind you. In other words, it is OK to ship non-free code in main, as long as there is no free implementation. No, that's not what I'm saying. I'm not saying whether or not this is free; and I'm certainly not saying it's OK to ship non-free code in main. What I *am* saying is that we *are* already shipping this way, and that not removing the code would not intensify the problem. However, postponing the release any further would certainly intensify the other problem, namely, that we still don't have another release this long after the release of woody. Since our users and the DFSG are equally important, one should not try to solve one of those problems *at the cost* of the other, and *certainly* not if one is not willing to provide a solution. If you want Dewbian to stop shjipping non-free code, then you better write the free implementation -- not just any free implementation, mind you -- Free of bugs, and standards-compliant, too. That, also, is not what I'm saying. Well, almost. In this particular case, with code being so important to a major part of our users, given that our users and the DFSG are, per the Social Contract, equally important, and given that the piece of code in dispute *is* already in stable, I'm saying we should not hold up the release to write a replacement. However, if *you* are willing to write a replacement, and are willing to hold up the release for that, I will support you, but then you should make sure the code is at least as good as the RPC code which *is* in glibc right now. Not doing so would be a disservice to our users, and not worth the effort. sarcastic It would probably hold up the release for yet another year or two, but who cares about such things anyway? /sarcastic Do you really think this is the stance of the project? Not the way you put it, no. If you're not willing to do that, then I suggest you shut the fuck up. Right, how dare you imply that we care about shipping only free code in main. Again, that's not what I'm saying. For one thing, I'm not convinced the code is non-free, but perhaps that's just me; I won't make any argument about that. However, in this particular case, at this moment in time, pulling the code out would, again, be a disservice to our users. We are all about expedience, not about freedom. Actually, we are about both (if I understand 'expedience' correct from the context; don't have a dictionary nearby) [...] We can't ship without RPC in glibc (that would be a severe disservice to our users, as it would break NFS, parts of Gnome (FAM, for instance, on which parts of Gnome depend, uses RPC), and most likely some other major parts of our distribution as well; and per the Social Contract, our users and the DFSG are equally important), and the code is (at least) not GPL-incompatible (you should read the first paragraph after section 2c of the GPL if you disagree). Indeed. Some non free code is too important not to ship. That's not what I'm saying. Some code of which the freeness is being challenged, is already being shipped. Not shipping such non free code would be a major disservice to our users, Actually, pulling that code out would be a major disservice to our users. It's already in there. Our users expect it to be there, or at least, they expect a functionally equivalent part of code there. and would lose Debian important market share, and we can't possibly let scruples stand in the way of market share, can we? I couldn't care less about market share. I do care about the social contract, though, which says 'Our priorities are our users and free software'. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgp5gUOVIr5eg.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
On Sat, Sep 06, 2003 at 11:45:23PM +0100, Andrew Suffield wrote: On Sun, Sep 07, 2003 at 12:19:32AM +0200, Wouter Verhelst wrote: If you're not willing to do that, then I suggest you shut the fuck up. We can't ship without RPC in glibc Equally, we shouldn't ship with known issues this severe. We are already doing that. Continuing to do so will not intensify that problem (although if the consensus is that the code is non-free, that should be fixed; but if we do so, we should do it properly); however, replacing the code at this moment in time *will* intensify another problem for our users. One should not try to fix one problem at the cost of creating (or intensifying) another. There would be a difference if we would be *avoiding* one problem, but that's not what's happening here. our users and the DFSG are equally important), and the code is (at least) not GPL-incompatible (you should read the first paragraph after section 2c of the GPL if you disagree). You've tried to make that argument before; go dig in the archives for the reasons why it's wrong. Actually, I haven't done such a thing. You're probably mixing me up with someone else. Also, without a date, keyword, or thread subject, that's pretty hard to find. And even if I had enough information to find it, I'm not going to waste *my* time digging the archives to understand *your* point; so unless you come up with an URL to the specific post that explains your point, I'm just going to assume you've made this up, and will feel free to ignore it. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpaC9fcjQczT.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
On Sun, Sep 07, 2003 at 02:56:33PM +0100, Andrew Suffield wrote: On Sun, Sep 07, 2003 at 12:09:43PM +0200, Wouter Verhelst wrote: our users and the DFSG are equally important), and the code is (at least) not GPL-incompatible (you should read the first paragraph after section 2c of the GPL if you disagree). You've tried to make that argument before; go dig in the archives for the reasons why it's wrong. Actually, I haven't done such a thing. Oh, that was Steve Langasek. Anyway, the answer is in that same paragraph; it only applies unless that component itself accompanies the executable - clearly irrelevant to us. No, you're referring to section 3. I'm referring to section 2, specifically, These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Plus section 2 isn't the issue anyway, it's section 6 that makes it incompatible. I don't think section 6 can make it incompatible. For reference: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. The RPC code is not based on glibc; rather, glibc is based in part on the RPC code. Section 6 only applies to the Program, or any work based on the Program. The combined work of both the glibc and the RPC code is clearly affected by section 6 of the GPL, and since the RPC code is supposed to be MIT/X11 when part of a whole, it is not incompatible; however, the RPC code *by itself* is not, nor can it be. Of course, usual IANAL rules apply. In any case, it's clear that there is no consensus on this subject yet. My point -- that holding up the release for this problem, which it well may be, is not a good idea -- still stands. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpWCaKXQ8lkG.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
On Sat, Sep 06, 2003 at 04:34:50AM -0500, Branden Robinson wrote: On Fri, Sep 05, 2003 at 09:56:03PM +0100, Andrew Suffield wrote: On Fri, Sep 05, 2003 at 02:20:02AM -0500, Branden Robinson wrote: For the Release Manager: What standard do you set for the repudiation of the aforementioned hearsay? Why is he setting it at all? I don't think that giving the RM final say in questions of DFSG-freeness is a wise precedent to create. It doesn't appear to have been given; it appears to have been taken. Please, guys. He isn't saying he has final say in whether or not the Sun RPC code is DFSG-free; he's just saying it shouldn't hold up the release. If you think it should, then please, by all means, write a replacement for the Sun RPC code, release it under the GPL, and convince the glibc maintainers to use that (untested) of code. Which will likely hold up the release for another couple of months. I'm sure none of us wants that. If I'm wrong, and you do want that, then stop the bickering, and start hacking that RPC code. After all, this lit may be discussing licenses on a daily basis, that doesn't give you any authority either. Thanks. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpCkvZMOML9E.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
On Sat, Sep 06, 2003 at 10:39:33PM +0100, Andrew Suffield wrote: On Sat, Sep 06, 2003 at 11:10:19PM +0200, Wouter Verhelst wrote: Please, guys. He isn't saying he has final say in whether or not the Sun RPC code is DFSG-free; he's just saying it shouldn't hold up the release. When did we decide that release dates were more important than the DFSG? We didn't. At least not officially. But to 'some' of us, it does matter. /sarcastic In any case, the solution is easy (as I said in my mail, in the part you conveniently snipped away): stop the bickering, get your hands out of their sleeves, and write that RPC code. Free of bugs, and standards-compliant, mind you. If you're not willing to do that, then I suggest you shut the fuck up. We can't ship without RPC in glibc (that would be a severe disservice to our users, as it would break NFS, parts of Gnome (FAM, for instance, on which parts of Gnome depend, uses RPC), and most likely some other major parts of our distribution as well; and per the Social Contract, our users and the DFSG are equally important), and the code is (at least) not GPL-incompatible (you should read the first paragraph after section 2c of the GPL if you disagree). Thanks. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpOyf2mGGCaC.pgp Description: PGP signature
Re: UnrealIRCd License (Click-Through issue)
IANAL, TINLA On Mon, Sep 01, 2003 at 05:28:41PM +0200, Mika Fischer wrote: Hi, Edmund! * Edmund GRIMLEY EVANS [EMAIL PROTECTED] [2003-09-01 17:03]: Of course. You have the right to sue anyone for anything at any time! Oh well, I think you know what I meant. :) However, in their defence the FSF will probably use the following elements of the GPL as evidence that they were not negligent: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, ... However I decided not to accept the license and may not even have read it. That doesn't change anything. Quote from the GPL: 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. [...] 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. So, even if you do not accept the license but you do copy, modify, and/or distribute the Program, you're still bound by the License. If someone tries to sue you for distributing FSF software, you can point at the same parts of the GPL and also at the warning on your web site, if you have one. The whole point of my hypothetical example is that I don't accept the license and use the software nevertheless. Not accepting the GPL is not a way to avoid it. You would be using a copy of the program without the right to do so; it would be the Free Software-equivalent of software piracy. If you want to be 100% sure, I suggest you go to a solicitor with a copy of the GPL; but I don't think a click-through license is necessary. [...] -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgpuoIIMKM4mv.pgp Description: PGP signature
Re: UnrealIRCd License (Click-Through issue)
On Mon, Sep 01, 2003 at 09:01:35PM +0200, Mika Fischer wrote: Hi! * Wouter Verhelst [EMAIL PROTECTED] [2003-09-01 20:39]: So, even if you do not accept the license but you do copy, modify, and/or distribute the Program, you're still bound by the License. What about use? I think that's the most important one here. Section 0. Read it, for a change :-) (Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, [...]) Not accepting the GPL is not a way to avoid it. You would be using a copy of the program without the right to do so; it would be the Free Software-equivalent of software piracy. Could you then comment on the quoted comment on a ruling in my first email? ---snip--- In order to resolve the question of arbitration, the key issue the Second Circuit had to decide was whether plaintiffs, by downloading the free software, agreed to be bound to Netscape's license agreement, which included the arbitration clause. [...] The appellate court found that having selected to download the program, users were neither required to unambiguously manifest assent to the program's license agreement nor to view the license terms, or even become aware of their existence. After examining California case law and relevant law governing contract agreements, the appellate court held that the act of clicking a download button does not signify assent to a contract's terms if the consumer is not aware of the them. Therefore, users are not bound by the SmartDownload license agreement since a reasonably prudent consumer would not have been aware of its existence. ---snip--- That may be true; however, such a ruling should not imply that a user is free to do whatever he likes with the software. If the user does not choose to accept the license, he still is bound by copyright law. Copyright law does not give a user many options. Depending on his jurisdiction, he may have the right to use the program; he may have the right to install it. He probably does not have the right to copy or modify it. He most likely does not have the right to redistribute or sublicense it. These rights are in most jurisdictions by default only available to the author (you, in this case); only if you, as an author, explicitely give permission to copy, modify, redistribute or sublicense, only then can a user reasonably assume he has the right to perform these actions. Therefore, if he does not accept the license, he can do next to nothing with it. His only real option is to accept the license, and live by it. This also excludes ignorance about the license text, since if the user does not know about the license, he should assume his default rights, as specified by copyright law, apply, as opposed to anything he would want to, and technically could, do with the software. Of course, this does not protect you against the ruling of a braindead judge who should not have been a judge in the first place, but nothing can. Of course, IANAL, TINLA. Contact a solicitor if you want a certain level of competence. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. pgp5pqYDQi6qe.pgp Description: PGP signature
Re: Some licensing questions regarding celestia
On Mon, Sep 01, 2003 at 11:45:05PM +0100, Andrew Suffield wrote: On Mon, Sep 01, 2003 at 04:16:36PM -0500, Branden Robinson wrote: On Mon, Sep 01, 2003 at 08:24:57PM +0200, Mika Fischer wrote: How far does one have to go in regard to data? A few examples. - Data published on the web: http://www.obspm.fr/encycl/cat1.html lists stars with possible planets around them. Is one allowed to use this data in a program? Basically for me this is just information and it doesn't make sense to restrict that. In the U.S., mere facts are not subject to copyright protection, and there are no separate laws extending copyright-like protection to databases of facts. In many European jurisdictions, copyright-like protections to extend to databases of facts. I don't believe that database law applies here, due to the small size of the data set. It is not really the size of the data set that matters; the amount of work required to create the dataset is. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: documentation eq software ?
Op za 30-08-2003, om 17:08 schreef Mathieu Roy: Hum, I think you misunderstood my answer. I was not aware of this issue in coreutils and I wonder about which author of ls we are talking about. I think you misunderstood his example. To me, it looked like Matthew was only talking about the hypothetical scenario that someone _could_ put such a statement in ls, thereby misrepresenting the original author's opinion. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: SURVEY: Is the GNU FDL a DFSG-free license?
Op do 28-08-2003, om 20:02 schreef MJ Ray: Ye gods! Who knew that software was such a contentious word? Agreed. Perhaps we should... ... Oh, wait. I already suggested we'd do so. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
