Re: rar support violates DFSG #4
On Fri, Nov 25, 2005 at 07:44:08PM -0800, Steve Langasek wrote: OTOH, if you think my interpretation of DFSG is inadequate, I could try to expose it better, and we could also move this to -legal (perhaps I should have started there in first place). Yes, I still disagree with this reasoning. People of conscience may disagree on whether *preventing* the creation of files that can't be read with free software is serving the goals of the DFSG. In the absence of agreement on this point, I don't think it's right to treat this as a release-critical bug unless the *maintainer* agrees with you. That suggests if the maintainer disagrees in, say, DFSG #1 (Debian will remain 100% free), then we don't have to treat as release-critical an inclussion of non-free in main. I think I'll try to expose better my point, and also move it to -legal. DFSG #4 states: We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. I think it's very clear that the free software community is harmed by promoting trap formats like RAR, so I won't extend on that. For what the needs of our users are concerned, we have basicaly two groups of users with opposed needs: 1- A group of users who want to use rar to produce archives. 2- A group of users who want to extract rar archives produced by the first one. Reasons why I think the latter group is much bigger than the first: - In case user in group #1 is using RAR for private backups/etc, the technical disadvantages of using RAR instead of a combination of tar (better integration with Un*x file metadata) and p7zip (better compression) indicate this is a minority of users. - In case user in group #1 is using RAR for distributing data across the internet, then for each user doing this, it's logical to expect more than one user in group #2 will recieve the file and want to extract it. - In popcon, unrar is roughly 5/4 times more popular than rar. Although this info should be taken with a grain of salt, because many users install rar with the sole purpose of extracting, or simply because it's in Suggests in the packages that are object of this discussion. Therefore I don't think we're serving the interests of our users or the free software community first in our priorities. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340705: rar support violates DFSG #4
Scripsit Robert Millan [EMAIL PROTECTED] I think I'll try to expose better my point, and also move it to -legal. I think -legal is the wrong list. Is the license status of the software in question? Not as far as I can see from the build log. Your complaint appears to be that you think the software is inappropriate for main not because of its legal status, but because it *can* do things that you think are inappropriate for software in main to be able to do. That is, however not a question for -legal. For the record, I have never seen anyone argue that a piece of software should be expelled from main simply because of the function it can perform. In a few cases, there have been calls for not distributing software _at all_, because its functionality was considered distasteful (cf hot-babe), but I don't remember ever seeing a claim that the _freedom status_ of software is affected by which problem it solves. If you want to institute such a notion, I'd say that the burden of proof must be on you. Feel free to go to -project and try to raise a consensus for treating unwanted functionality as a cause for moving a package to non-free. But I would think it is inappropriate to start filing bugs with severities that assume that your (so far) uncommon position has alreay won the day. DFSG #4 states: We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. No it does not. DFSG #4 states: 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.) What you are qouting is part of point 4 of the Social Contract. Its interpretation is not a matter for debian-legal. -- Henning Makholm First chapter, the plot advances, second chapter, Ayla makes a discovery that significantly enhances Palaeolithic technology, third chapter, Ayla has sex with someone, and repeat ad infinitum. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340705: rar support violates DFSG #4
Scripsit Henning Makholm [EMAIL PROTECTED] I think -legal is the wrong list. Is the license status of the software in question? Not as far as I can see from the build log. s/build/bug/, of course. -- Henning Makholm Need facts -- *first*. Then the dialysis -- the *analysis*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rar support violates DFSG #4
El sábado, 26 de noviembre de 2005 a las 11:11:32 +0100, Robert Millan escribía: That suggests if the maintainer disagrees in, say, DFSG #1 (Debian will remain 100% free), then we don't have to treat as release-critical an inclussion of DFSG #4 states: We will be guided by the needs of our users and the free software community. Please, don't confuse the Debian Free Software Guidelines and the Social Contract :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reimplementing mac boot block - reviewer needed
Hi, Sven Luther and myself stared a project to reimplement boot block for Apple Macintosh. Publicly available documentation of the boot block does not contain all the necessary details, so we decided to do clean room implementation. I reverse-engineered the Apple boot block and prepared the specification. Now we are looking for volunteer to review it, before implementation starts. The specification is quite detailed and we would like to make sure it doesn't infringe Apple copyrights. I'll send the draft (about 3 pages) off-list to anyone ready to review it. After the review succeeds, I will mail it on debian-powerpc. Thanks in advance, Piotr Krysiuk PS. Please respond to the list.
Re: Clarification regarding PHP License and DFSG status
* Alexander Terekhov: On 11/25/05, Glenn Maynard [EMAIL PROTECTED] wrote: [...] PHP scripts are derivative works of PHP sounds like someone misinterpreted the FSF's claims, and ended up believing that the source of a program is a derivative work of its libraries. (That, unlike the FSF's claims, seems ^^^ Unlike? http://web.novalis.org/talks/compliance-for-developers/slide-49.html Still a derivative work: * Distributing the source code of software which links to a library when that library is the only software to provide that interface Still a bit bizarre, and I would prefer if the FSF didn't enforce their copyright along these lines. Basically, this is an ex-cathedra position back from the old days when people thought that the most important piece of GNU software was GNU readline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
On Fri, Nov 25, 2005 at 10:39:05PM +0100, Alexander Terekhov wrote: On 11/25/05, Glenn Maynard [EMAIL PROTECTED] wrote: [...] PHP scripts are derivative works of PHP sounds like someone misinterpreted the FSF's claims, and ended up believing that the source of a program is a derivative work of its libraries. (That, unlike the FSF's claims, seems ^^^ Unlike? http://web.novalis.org/talks/compliance-for-developers/slide-49.html Still a derivative work: * Distributing the source code of software which links to a library -- Copyright (c) 2004, Free Software Foundation. I can't find anything in those slides which provides a basis for that claim, and the technical issues surrounding such a claim are very complex. I'd be interested to see a video or something of a talk associated with these slides, to see if there's any additional context which the speaker provides to back up this claim. As it stands, this looks like a line the author pickup around the office koolaid-cooler. - Matt signature.asc Description: Digital signature
Re: Clarification regarding PHP License and DFSG status
On Fri, Nov 25, 2005 at 02:56:02PM -0500, Glenn Maynard wrote: On Fri, Nov 25, 2005 at 07:23:24PM +, Måns Rullgård wrote: Do you think that this licence does not require a developer of a modified package (other than PHP) to lie by saying This product includes PHP software? Perhaps the PHP folks subscribe to the view that PHP scripts are derivative works of PHP. Ye ghods, I'd hope not. That would be similar to believing that this message is a derivative of the English Grammar manual I read in school. Or that all non-trivial Emacs Lisp code must be licensed under the GPL. This position is not *that* unusual... Not being unusual doesn't make it sensible or correct. Just to take a guess at where this strange claim might have originated: The FSF (from what I understand) claims that binaries linked against GPL libraries are derivative works of the library, because the resulting binary has pieces of the GPL software in it. This isn't obviously true with C libraries, which has led to a lot of debate around the topic, but the claim isn't entirely unreasonable. Assuming that linked in your paragraph above means dynamically linked (as your second sentence suggests), can you provide a cite from the FSF which makes this claim, with rationale? I looked around, as research for my blog post Linking does not create a derivative work (http://www.hezmatt.org/~mpalmer/blog/general/linking_does_not_create_a_derivative.html) and couldn't find anything that really actually made the claim in those terms. - Matt signature.asc Description: Digital signature
