Re: openjdk-8 upstream limits source distribution?
On Mon, 1 Sep 2014, Walter Landry wrote: Due to limited intellectual property protection and enforcement in certain countries, the JDK source code may only be distributed to an authorized list of countries. You will not be able to access the source code if you are downloading from a country that is not on this list. We are continuously reviewing this list for addition of other countries. This is just Oracle saying that they will not offer downloads to people in embargoed countries (e.g. Cuba). Debian does a similar thing. This does not prevent anyone from taking that download and giving it to a Cuban. Oracle saying that they won't offer downloads to people in embargoed nations would be we will only distribute the source code to..., not the source code may only be distributed to... The way it's actually worded, that limit applies to everyone, not just Oracle. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.lrh.2.00.1409020935100.5...@oxygen.rahul.net
Re: Java3D license incompatible with DFSG?
On Mon, 17 Sep 2012, Steve Langasek wrote: In this specific case, you're suggesting that we should for some reason care that a user can't make a counterfactual claim in court that this software has been licensed by the DOE for use in nuclear facilities. Suppose someone puts this license on something that really is licensed for use in nuclear facilities. (Perhaps they missed some obscure law which licenses it.) Does the license become non-free (since the user can't acknowledge a false statement), but only for this particular piece of software? Suppose that tomorrow the government decides to license the software for use in nuclear facilities. Does that immediately halt all further distribution of the software, since it now requires a false acknowledgement? GPL3, for instance, includes two distinct restrictions on the recipient's right to sue: Suppose that you use the software in a nuclear facility and you get sued for negligence (either by a third party or by the copyright owner). Among the evidence offered in the negligence case is that you acknowledged that the software isn't licensed for use in nuclear facilities. Would that make it non-free? This is not a case of the recipient suing--it's a case of the recipient being sued. How can we expect the user to make this acknowledgement anyway? I'm not a lawyer. I don't know if the software has been licensed in nuclear facilities or not. How can I acknowledge a statement whose factual nature I am uncertain of? The statement isn't, after all, we're telling you that the software isn't licensed for use in nuclear facilities, it's *you acknowledge* that Besides, this is a more general objection of which being licensed for use in nuclear facilities is just a specific example. I can easily conceive of a situation where the license says you acknowledge X and it is to the user's benefit to not acknowledge X, even if that won't happen much in the nuclear facilities case. (What if X is ___ violates ___ patent and acknowledging it exposes him to liability for willful infringement?) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1209180711390.31...@oxygen.rahul.net
Re: Java3D license incompatible with DFSG?
On Sat, 15 Sep 2012, Steve Langasek wrote: * You acknowledge that this software is not designed, licensed or * intended for use in the design, construction, operation or * maintenance of any nuclear facility. This is a standard No warranty clause wrt nuclear facilities in the US. It is not a restriction placed on the use of the software in nuclear facilities by the copyright holder, it is a CYA statement that the software has not been approved *by the government regulatory agencies* for use in nuclear facilities in the US. Stuff like this has puzzled me. I would think that in order to use this software, you must do something which would have the effect of disadvantaging yourself in a lawsuit wouldn't be considered free. A statement you must acknowledge X means that any user who wants to claim not-X in court is forced to drop that claim in order to use the software. If this is a statement that the software hasn't been approved, shouldn't it say you acknowledge that we *claim* X (thus not depriving the user of the opportunity to challenge X in court), and not you acknowledge X? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1209161747470.17...@oxygen.rahul.net
Re: Channel logos in vdr-plugin-markad
Wouldn't using a derived bitmap of the logo to check for the existence of the logo be fair use? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1204301224100.5...@oxygen.rahul.net
Re: Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
On Wed, 28 Mar 2012, Stefano Zacchiroli wrote: Each one of us is free to *think* that a piece of software in the Debian archive is patent encumbered, whatever that means, and possibly thinking so due to the legitimate interests of patent owners that want *everybody* to think pieces of software are encumbered by their own patents (it is like asking the restaurant owner if the food is good, right?). But the policy refers to knowingly violating patents. Are you claiming that knowingly refers only to cases where lawyers have told us this? Most people wouldn't interpret it that way. And that then means anyone can post to the list saying by the way, MP3 is covered by patents and Debian is now knowingly violating the patent (after all, we were just told about it, so now we know it) and must delete everything that handles MP3. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1203280714120.5...@oxygen.rahul.net
Re: Using freetranslation.mobi to translate .po files
On Sun, 25 Mar 2012, Petter Reinholdtsen wrote: If I ask a random person on the street to translate a GPLed text fragment, and the person give me a translated text fragment back, will the resulting text fragment still be GPLed? Assuming the text fragment was copyrightable in the first place, I believe it will be, as otherwise the translator would be said to violate the GPL and I fail to see what action involved could possibly violate the GPL. The translator would be violating the GPL, but since this is fair use, violating the GPL this way would be legal. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1203260827350.3...@oxygen.rahul.net
Re: Using freetranslation.mobi to translate .po files
On Mon, 26 Mar 2012, Petter Reinholdtsen wrote: The translator would be violating the GPL, but since this is fair use, violating the GPL this way would be legal. What is the translator doing in the example we are discussing that is violating the GPL? Please explain more, as I failed to understand what you mean from your terse comment. Which action is violating the GPL? The translator is creating a derivative work (his translation) and distributing it. This is one of the rights of the copyright holder and the GPL only gives him permission to do this if he puts his derivative work under GPL. Since he did not put this derived work under GPL, the GPL grants him no permission to distribute it, and he would be in violation of copyright if it wasn't for fair use. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.120326540.10...@oxygen.rahul.net
Re: Using freetranslation.mobi to translate .po files
On Mon, 26 Mar 2012, Petter Reinholdtsen wrote: I on the other hand believe that the translator here implicitly put this derived work under GPL, because not doing it would be in violation of the GPL. I believe assuming people follow the law and the license is a better assumtion to make than to assume that they break the law and the license. If it's GPLV3, GPLV3 has a fair use clause. So the translator is following the law and the license--yet is not putting the translation under GPL, and the translation can't be distributed further (since that would *not* be fair use). GPLV2 has no fair use clause, so with GPLV2 the translator would indeed be violating the license, but he'd be violating the license *legally*--he wouldn't be breaking the law, since fair use is legal. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1203261412250.20...@oxygen.rahul.net
Re: Using freetranslation.mobi to translate .po files
On Mon, 26 Mar 2012, Mark Weyer wrote: I do not think your argument is sound. Assume I write a text, publish it under a license which basically says that everyone translating it ows me EUR 1000, and then ask a random person on the street to translate it (even without mentioning how it is licensed). Would you say that I am entitled to any money? My guess is that in all sane jurisdictions I am not. Translating it if you have a copy, or to give to someone else who you're translating it for, is fair use. Therefore they don't have to pay you any money, and the license is irrelevant, at least in the USA. With your reference to EUR 1000, I assume you're not in the USA, so you might not have fair use. But even then, if you give someone something of your own to translate, you gave them an implied license to do the translation. If you give him a work made by someone else, however, you can't grant an implied license. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1203261423000.20...@oxygen.rahul.net
Re: Bug#639916: spread: license wackiness
On Wed, 31 Aug 2011, Francesco Poli wrote: 3. All advertising materials (including web pages) mentioning features or use of this software, or software that uses this software, must display the following acknowledgment: This product uses software developed by Spread Concepts LLC for use in the Spread toolkit. For more information about Spread see http://www.spread.org; What you quoted looks like an Obnoxious Advertising Clause (OAC), a GPL-incompatible restriction, but one that has traditionally been accepted by the Debian Project as compliant with the DFSG (even though recommended against), AFAICT. Unlike the original BSD 4 clause license this adds or software that uses this software. If I interpret this broadly (all software that uses this software must display the sentence) it's non-free, since it imposes conditions on non-derived software that happens to use it. Even if I interpret it narrowly (all advertising materials mentioning software that uses this software, must display the sentence) it imposes conditions on advertising for non-derived software. If I interpret the addition as meaning derived works the license is free but the wording is redundant. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1108311102040.13...@oxygen.rahul.net
Re: XNAT license terms... any chance for main?
On Fri, 3 Jun 2011, PJ Weisberg wrote: I've seen plenty of software in Debian with a clause similar to #4, usually phrased something like $foo is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I don't see how it could make a difference that this license names one particular purpose that the authors don't guarantee that the software is fit for. The difference is that those basically say we don't provide... and this one says you acknowledge that... and you agree that In this one we are requiring the user to do something (acknowledge and agree to things) that he might not want to do and which may put him at a disadvantage at some point in the future. If your example said the user acknowledges that we provide no implied warranty it would have the same problem. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1106061405460.24...@oxygen.rahul.net
Re: XNAT license terms... any chance for main?
On Fri, 3 Jun 2011, Yaroslav Halchenko wrote: 4. The software has been designed for research purposes only and has not been approved for clinical use. It has not been reviewed or approved by the Food and Drug Administration or by any other agency. You acknowledge and agree that clinical applications are neither recommended nor advised. Since it seems to be just an advisory, I think it should be ok 5. You are responsible for purchasing any external software that may be required for the proper running of this software. You also agree that you are solely responsible for informing your sublicensees, including without limitation your end-users, of their obligations to secure any such required permissions. You further agree that you are solely responsible for determining and divulging the viral nature of any code included in the software. ok It seems like a lot of people disagree with me on this subject, but this type of clause looks funny to me. What if someone doesn't want to acknowledge #4 or agree with #5 but still wants to use the software? Wouldn't that prohibit him from doing so? This sounds like it's asking for payment to use the software with the payment being you must acknowledge and agree to things that would make it harder for you to sue us. Certainly a direct statement you can use the software as long as you never sue us wouldn't fit the DFSG; why would an indirect you can only sue us at a disadvantage fit them? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1106031539060.19...@oxygen.rahul.net
Re: Lawyer request stop from downloading Debian
On Tue, 26 Apr 2011, Jeff Epler wrote: I'm trying to figure out how transmitting a range of bytes in a torrent is different than transmitting a range of bytes in response to e.g., an FTP REST or an HTTP byte-range request. It's not. Imagine that instead of torrenting the file, you just downloaded it by FTP, then made it available for someone else to get by FTP. That would be illegal too, if you made it available without source (and didn't receive a written offer which you passed on). You can only distribute with source. The difference is that if you are using FTP, when you get around to distributing it, you can put the source up at the same time. If you're using torrents, you're automatically distributing it without any chance to distribute the source (unless the source is in the same torrent). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1104261132090.4...@oxygen.rahul.net
Re: Lawyer request stop from downloading Debian
On Mon, 25 Apr 2011, Michael Poole wrote: How do you reconcile your claim with these sections of the GPLv2 and v3, both referring to an executable or object-code form of the work? GPLv2, section 3: You may Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) ... Arguably the GPLv2 clause doesn't apply because Debian is typically distributed with the source code available on the same medium (server), rather than with a written offer to provide source code You just answered your own question. That section only applies if you got a written offer. People who use Bittorrent to download (and therefore to upload) Debian don't have a written offer, so they can't take advantage of that clause. (Debian itself is, as you point out, distributing source on the same medium, so may be okay, but the downloader isn't.) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1104251317010.11...@oxygen.rahul.net
Re: Providing source for .iso files downloaded using bittorrent
On Sun, 24 Apr 2011, Marcelo E. Magallon wrote: What do you think? Um, I think I said the same thing, down to the reference to the GPLV3 clause meant to prevent the problem? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1104251324430.11...@oxygen.rahul.net
Re: Lawyer request stop from downloading Debian
On Sun, 24 Apr 2011, Vincent Bernat wrote: The problem is that on Bittorrent, everyone who downloads also uploads. This makes it illegal to download just a binary, since if you do that you're also uploading just a binary, and uploading just a binary is a form of distribution the GPL doesn't allow. In the case of Debian distribution, the source code is available at http://www.debian.org which fullfils section a) since it is a medium customarily used for software interchange. Doesn't work. You have to *accompany* it with the source code. Pointing to an unconnected third party's site has never been considered to satisfy this clause. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1104240818100.22...@oxygen.rahul.net
Re: Lawyer request stop from downloading Debian
On Sun, 24 Apr 2011, Michael Wild wrote: The problem is that on Bittorrent, everyone who downloads also uploads. This makes it illegal to download just a binary, since if you do that you're also uploading just a binary, and uploading just a binary is a form of distribution the GPL doesn't allow. As absurd as this argumentation sounds to me (but then I'm a mere engineer and find matters of law often to be very confusing), following it makes the Debian project a direct accomplice in copyright violation, see http://www.debian.org/CD/torrent-cd. By providing these torrents, the Debian project makes everybody in Germany who uses them a copyright violator. It makes everyone who uses it everywhere a copyright violator, it's just that only in Germany can a third party demand money for the violation. The GPLV2 just wasn't written with torrents in mind (since it was created before torrents). This was a real enough problem that the FSF had to fix it for GPLV3. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. Realistically, of course, this German lawyer probably picked Debian at random, and has no idea that it's free to distribute. The fact that he picked an obscure case where, on a technicality, he's right is just a coincidence and he knows nothing about Debian, the GPL, or torrenting. So (despite what I may have suggested before) telling him not to do this may have some effect. Also, I don't know German law, so I don't know if there are any limits on German law that Debian might be able to point to (such as whether he can ask for damages for something that's free). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1104240821020.22...@oxygen.rahul.net
Re: Lawyer request stop from downloading Debian
On Sat, 23 Apr 2011, Stefan Hirschmann wrote: The lawyer wants the poster to pay 700 Euro and stop uploading of Debian. - My opion is that this behavior is not good for Debian's reputation and the project should take legal action against the lawyer and this company. It's my understanding that in Germany lawyers can do this to copyright violators even though they are not the copyright holder. And it's very likely he's a copyright violator, so there's not much Debian can do. No, really. The GPL V2 requires that if you distribute, you either a) accompany a binary with the source code b) accompany it with a written offer to give everyone a copy of the source code for three years, or c) accompany it with an offer to distribute source code, if it's noncommercial distribution and you received the program inder b). It's very unlikely that b or c applies, and most people who torrent Linux don't put a copy of the source code in the torrent, so a is unlikely. The problem is that on Bittorrent, everyone who downloads also uploads. This makes it illegal to download just a binary, since if you do that you're also uploading just a binary, and uploading just a binary is a form of distribution the GPL doesn't allow. Which means he's (probably) technically a copyright violator, just a copyright violator that everyone has agreed to ignore because the GPL V2 is unwieldy that way. But lawyers in Germany can go after copyright violators who the copyright holders ignore. The GPL V3 had to have a clause written in specifically allowing Bittorrent (see http://www.gnu.org/licenses/gpl-faq.html#BitTorrent) because of the problems legally using it with V2. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1104231442130.5...@oxygen.rahul.net
Re: Lost sources [was: Re: scientific paper in package only in postscript form non-free?]
On Fri, 18 Mar 2011, Don Armstrong wrote: Yes, but this isn't something that a sane upstream is ever going to do, so it's not worth discussing much. [And frankly, if it's something that upstream does do, one should strongly question whether Debian should actually be distributing the work in question anyway.] It can actually happen. Consider the case where someone edits an audiovisual work using uncompressed video and audio files, then deletes them when he's done because they take up too much space. Plenty of sane people will do this. (This situation also results in works which cannot be GPLed, if the original creator still has the uncompressed files and refuses to distribute them due to lack of bandwidth. GPL may not work too well when the source code is hundreds of times the size of the binary.) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1103210809001.16...@oxygen.rahul.net
Re: Lost sources [was: Re: scientific paper in package only in postscript form non-free?]
On Mon, 21 Mar 2011, Francesco Poli wrote: However, we also have to consider this: in some cases, when the uncompressed form is hundreds of times larger than the compressed form, the former may be really unpractical to handle. In those cases, maybe we prefer to use some compressed form to make further modifications, just for practical reasons. Well: in those cases, the preferred form for making further modifications is that *compressed* form, which is consequently the actual source! It's possible that the compressed form can be impractical for some purposes but not others. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1103211503530.2...@oxygen.rahul.net
Re: Bug#570621: Parsing output = derivative work?
The distinction between a derivative work and a separate work is not based on technology but on functionality. Parsing the output of a program doesn’t make a derivative work. However, if this parsing is vital for the operation of the application and makes it useless without that program, what is the difference with dynamic linking to a library? To a programmer, there might be one, but to a court, there wouldn’t be any. By this reasoning, if I write a program which converts another word processor's output to Microsoft Word format, then that program is a derivative of Microsoft Word, at least until Open Office gets a filter good enough to read it. Moreover, by this reasoning, if I write a program that runs only on Windows, or which interfaces with some proprietary Windows protocol, Microsoft can legitimately claim that I am violating their copyright by creating an unauthorized derivative of their work. This definition of derivative work is something which the FSF claims, but which many people outside the FSF are skeptical of precisely because of absurd consequences like these.
Re: Inappropriate use of Debian logo.
On Tue, 30 Nov 2010, Stefano Zacchiroli wrote: As far as I can tell (IANAL, and before contacting SPI lawyer) what we should ask Legend PC is then to come into compliance of the license, by mentioning copyright and permission notices. But copyright doesn't apply to independent invention, which he claims this is, and which seems fairly reasonable. If he independently invented it we only have a trademark claim; if we don't have a trademark claim we have none. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1011301445200.3...@oxygen.rahul.net
Re: PS documentation file, no sources, author died
On Sat, 30 May 2009, Rafael Laboissiere wrote: I would really like to distribute the documentation file but the upstream author died recently [6] and the chances are small that the sources can be found. Is there any rule that applies to this case, I mean, when an author dies? I'd think that if you lose the source file, then all modifications have to be done using whatever file still exists. That would make whatever file still exists be the preferred form for modification, and therefore source. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: legal questions regarding machine learning models
On Wed, 27 May 2009, Francesco Poli wrote: I instead think that FTP masters should change their minds about 2D images rendered from 3D models. I suggest you start your own distribution, in which you wonât ship: * xfonts-* (bitmap renderings of non-free vector fonts) Are you saying that xfonts-* are derived from non-free fonts? How can they be DFSG-free, then? In the US and some other places, bitmap fonts can't be copyrighted. You can make a free bitmap font by rendering a non-free font at a particular size. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Sat, 18 Apr 2009, Anthony W. Youngman wrote: I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. HOW? I hope the FSF doesn't think this, because imho it is so sloppy legal thinking as to be incompetent! http://sources.redhat.com/ml/guile/1999-02/msg00151.html This talks about static or dynamic linking. I don't actually see how it applies, because if it's statically linked it's a clear violation - the person distributing the program has to distribute the library as well. But if it's dynamically linked and the program - as distributed - merely EXPECTS to find the library on the target machine, I don't see any violation. You don't, but the FSF does. I'm well aware that their reasoning for this is somewhat fuzzy. But that's exactly what they think. It's been their position for over a decade, even though they don't make public pronouncements about it any more and just about everyone not from the FSF thinks that it isn't true. Eben Moglen: As when, for example, people tried to draw a line between static linking and dynamic linking under GPL version two, and we had to keep telling people that whatever the boundary of the work is under copyright law, it doesn't depend upon whether resolution occurs at link time or run time. This whole thing is a rather grey area, but I still stick by what I said. You may have noticed references to the system library exception. Is that there as a valid exception, or because they're not sure whether it'll stick in court? The GPL explicitly says that you're allowed to link with system libraries. At the end of the day, if the proprietary program does not contain any GPL code *as* *shipped*, I find it hard to see a copyright violation suit sticking. Who is violating the GPL? The FSF would like to say it's the proprietary vendor but ... (and it's certainly not the user, the GPL explicitly says they're in the clear). The FSF thinks that a work which is designed to link with GPL code is a derived work of that code and, therefore, would violate copyright when distributed even if no lines of the code have been copied into it. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Fri, 17 Apr 2009, MJ Ray wrote: http://trac.xapian.org/ticket/191 makes me think the combination only happens at compile time, so including unused source would be OK. I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. This is the same situation, and therefore would be a GPL violation. (And I was also under the impression that Debian follows the wishes of the copyright holder, so it doesn't matter if this argument has any legal merit, just that the FSF makes it.) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Fri, 17 Apr 2009, Anthony W. Youngman wrote: I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. HOW? I hope the FSF doesn't think this, because imho it is so sloppy legal thinking as to be incompetent! http://sources.redhat.com/ml/guile/1999-02/msg00151.html http://www.gnu.org/licenses/lgpl-java.html http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs Also http://www.fsfeurope.org/projects/gplv3/bangalore-rms-transcript : Eben Moglen: As when, for example, people tried to draw a line between static linking and dynamic linking under GPL version two, and we had to keep telling people that whatever the boundary of the work is under copyright law, it doesn't depend upon whether resolution occurs at link time or run time. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
First sale in the US only applies if the product was made in the US. Where on Earth did you hear or read that? I've never head such a thing. http://supreme.justia.com/us/523/135/case.html Read carefully the sections describing 602(a), particularly page 148. # copies that are not subject to the first sale doctrine-e. g., copies # that are lawfully made under the law of another country -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
As I pointed out, in the US, First Sale is in title 17, chapter 1, section 109. # Notwithstanding the provisions of section 106 (3), the owner of a # particular copy or phonorecord lawfully made under this title, or any # person authorized by such owner, is entitled, without the authority of # the copyright owner, to sell or otherwise dispose of the possession of # that copy or phonorecord. This would seem to cover it, as long as the work was copyrighted in the US. (US courts have not decided on First Sale applied to works copyrighted outside the US.) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
On Sat, 14 Mar 2009, Francesco Poli wrote: U.S. copyright law [1] states, in section 106: [...] | the owner of copyright under this title has the exclusive rights to do | and to authorize any of the following: [...] | (3) to distribute copies or phonorecords of the copyrighted work to | the public by sale or other transfer of ownership, or by rental, | lease, or lending; 109 has this: Notwithstanding the provisions of section 106 (3), the owner of a particular copy or phonorecord lawfully made under this title, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord. That's first sale (and notice it doesn't actually require the copy be sold for money). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
On Sat, 14 Mar 2009, Ken Arromdee wrote: 109 has this: Notwithstanding the provisions of section 106 (3), the owner of a particular copy or phonorecord lawfully made under this title, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord. That's first sale (and notice it doesn't actually require the copy be sold for money). Actually it turns out there's a little problem with using first sale here. First sale in the US only applies if the product was made in the US. Which means that if you copy Debian outside the US, then come into the US, you may not necessarily be allowed to give the copies to anyone. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License issue on tiny Javascript fragment
On Sat, 7 Feb 2009, Bernhard R. Link wrote: 1) The safe way: See what it does, describe someone else not knowing the code to write code doing this for you and use that code. Does that actually work? The description is a derivative work of the code; the new code is a derivative work of the description and therefore the old code. I know about reverse engineering a BIOS, but that's really just a defense against direct copying, as far as I know. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which license am I looking for?
On Sun, 25 Jan 2009, MJ Ray wrote: Bad example, but the same warning is on Sainsbury's Shelled Walnuts 300g, which I'm pretty sure are nuts and can be looked up on http://www.sainsburys.com/groceries/ Consider how hard it would be to have the law say products must contain warnings about nuts, unless the presence of nuts is sufficiently obvious anyway. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
(Here goes an email with actual content, since I messed up...) I suggest you Google up user does the link. [...] I suggest you just post the URL(s) you mean. Google results pages are highly volatile and vary by browser location: what you saw then may not be what I see now. You don't really need Google, you just need a tiny bit of knowledge about some very famous things the FSF had said in the past. It has turned up for NeXt and GNU Readline, for instance. Asking this is like asking for a reference that Abraham Lincoln was a US President--it's just too well known. If you really want a reference, try this: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLPluginsInNF # Can I release a program under the GPL which I developed using non-free tools? # # It depends on how the program invokes its plug-ins. For instance, if the # program uses only simple fork and exec to invoke and communicate with # plug-ins, then the plug-ins are separate programs, so the license of the # plug-in makes no requirements about the main program. # # If the program dynamically links plug-ins, and they make function calls to # each other and share data structures, we believe they form a single program, # which must be treated as an extension of both the main program and the # plug-ins. In order to use the GPL-covered plug-ins, the main program must # be released under the GPL or a GPL-compatible free software license, and # that the terms of the GPL must be followed when the main program is # distributed for use with these plug-ins. It also seems unkind to tell upstream developers to use non-free software like Google, instead of writing great free software like they usually do. You are being ridiculous. Google's search engine runs on their own machines. They're not distributing it. Which means that most free licenses wouldn't require Google to release any source code at all. (And the ones that do are highly controversial.) If you like, you can pretend that Google's search engine is under BSD. That would make no difference whatsoever as to your rights to get it (which are nonexistent in either case). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
On Tue, 6 Jan 2009, Kern Sibbald wrote: 1. Build it from source yourself (perfectly legal -- only distribution violates the GPL license). Isn't it the FSF's position that user does the link violates GPL? No. Please read the GPL. I suggest you Google up user does the link. Unless they changed their position recently, they *do* think that creating something designed to link against GPL coder, but not distributing the GPL code and letting the user get it and link it in, is a violation. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
1. Build it from source yourself (perfectly legal -- only distribution violates the GPL license). Isn't it the FSF's position that user does the link violates GPL? Of course, even then, that only applies to distribution--which means that the user can build it from source himself, but the fact that Debian distributes something the user *can* use to build it from source itself violates GPL. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL photographies, eg for backround
On Wed, 31 Dec 2008, Josselin Mouette wrote: More precisely: if you are the copyright owner, you can publish it in whatever format you like, and if under a free license (e.g. the GPL), it will be acceptable for Debian. Say what? If you GPL a program and don't provide source code Indeed, but we are not talking of a program but of pictures here. The same applies if you don't provide the source code for the picture. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL photographies, eg for backround
On Mon, 29 Dec 2008, Josselin Mouette wrote: More precisely: if you are the copyright owner, you can publish it in whatever format you like, and if under a free license (e.g. the GPL), it will be acceptable for Debian. Say what? If you GPL a program and don't provide source code, Debian doesn't even have the right to distribute it, since they have to distribute it with the source code and they don't have that. The fact that you are the copyright owner means that your sending it *to* Debian is legal, but that doesn't grant Debian permission to distribute it any further. Why would Debian accept something it's not allowed to distribute? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alternatives to Creative Commons
On Wed, 17 Sep 2008, Arc Riley wrote: There is absolutely no issue licensing game data under the (L/A)GPL. In fact, this is required for at least the GPLv3 in that the license applies to the whole of the work, and all it's parts, regardless of how they are packaged. Thus if the game code or any dependencies (ie, the engine) are licensed under the GPL, the data must be licensed under a GPL compatible license (which the CC licenses are not). One problem with licensing game data under the GPL and variations is that it's quite common for game data to be created from something much larger--for instance, using uncompressed audio or video to create an .ogg or .avi. In order to release it under the GPL (at least if you want people to be able to distribute it), you have to release the uncompressed audio or video, since that's the preferred form of modification. Some game creators may not want to do this simply because of the files' size. Moreover, you need to include scripts used to control compilation and installation of the executable. If the game and data are considered a single work, then that means you need to include scripts for creating the audio and video too. If you're editing the audio/video in some weird format that you don't have a free tool for, this may be a problem. (For programs, this is covered by the operating system exception, though I'm still mystified how a C compiler is considered to be normally distributed with Microsoft Windows.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
On Tue, 2 Sep 2008, Gervase Markham wrote: If it's a small embedded system, the source code is likely also to be small. Or is this a combination of the small embedded system objection and the gigabytes of modified source objection? This problem could actually arise for the GPL too. Consider a work which contains a video file encoded in some kind of lossy format like divx. The source code for that video file could easily be a hundred times the size of the file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: source code written by monkey
On Sun, 10 Aug 2008, [ISO-8859-15] Philipp Hübner wrote: The actual author of this file (Edgar Toernig) refused to put any copyrights / licenses on it and claims that his monkey has written it, because international copyright law does not apply to animals' works. This way he wants to make is code completely free. Let's apply the Tentacles of Evil test. The author gets bought out by Microsoft, who tells you you may no longer copy the work. You try to go to court with the defense that the work was created by the author's monkey and that therefore Microsoft has no claim to it. Will the court accept that defense and let you copy it? I doubt it. So it's not free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, 22 Jun 2008, Francesco Poli wrote: OK, that said, if you wanted to modify a public key (in order to obtain something else), what form would you use for making modifications? I think the preferred form would be the one in which the GPG public key is distributed by keyservers or some other equivalent form (which may be losslessly obtained from the distribution form). Wouldn't the preferred form for modification be the number that's used to generate both the private and public key? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desert island test
On Thu, 6 Mar 2008, MJ Ray wrote: It's pretty similar to the bloody lunatic test; the license says you can't distribute unless you follow some condition (distribute source/send changes off the island), but an external force having nothing to do with the author of the software forces you not to follow the condition. Why is it the fault of the external force in one case and the fault of the license in the other? One can spot whether it's the fault of the licence in 99% of problems by asking whether a change to the licence could remove the problem. A change to the licence could allow desert island hacking. No change to the licence could stop the bloody lunatic. No, that isn't true. A change to the license which says you don't need to include source would prevent the bloody murderer from being a problem, just like a change saying you don't need to send changes off the island would prevent the island from being a problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desert island test
On Thu, 6 Mar 2008, Adam Borowski wrote: Having a country non-free doesn't make a license non-free. In the chinese dissident test the user chooses to fight against the bloody murderer (who wears an uniform) -- he breaks unrelated laws, yet does not breach the license in any way. A license that fails the dissident test *is* non-free. You're right that it's even closer, but consider this: if the bloody murderer will kill you if you reveal your identity (dissident test) the license demanding you do so is nonfree. But if the bloody murderer will kill you if you distribute source, the license demanding you do so is fine. What principle can possibly be used to get that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desert island test
On Thu, 6 Mar 2008, MJ Ray wrote: No, that isn't true. A change to the license which says you don't need to include source would prevent the bloody murderer from being a problem, just like a change saying you don't need to send changes off the island would prevent the island from being a problem. How could changing the license prevent the bloody lunatic from carrying out his promise if you distribute any code licensed under the GPL with the corresponding source code, he will hunt you down and kill you in cold blood? If you change the license so it doesn't require you to include source, you could distribute without source. The lunatic only kills you if you distribute with source. Thus, he wouldn't kill you. The lunatic interfering with you distributing source is like the island interfering with you sending changes back to the author. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desert island test
On Fri, 7 Mar 2008, Ben Finney wrote: consider this: if the bloody murderer will kill you if you reveal your identity (dissident test) the license demanding you do so is nonfree. But if the bloody murderer will kill you if you distribute source, the license demanding you do so is fine. What principle can possibly be used to get that? The principle that there are certain freedoms essential in a software work for that work to be called free. The point of the desert island (and bloody murderer) examples is to analyze *whether* a restriction is free. If in order to do this you need a principle which already defines what restrictions cannot be called free, then the desert island test is completely useless. You have to decide whether the restriction is free before you can even try to apply it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desert island test
On Mon, 3 Mar 2008, MJ Ray wrote: Allow me to propose my own convenient test, which I refer to as the Bloody Murderer Test: In that case and if the lunatic is truthful, no software under the GPL is free for 'you'. However, that's the fault of the lunatic and not the software or its licence. IMO the correct bugfix is to cancel out the lunatic. I could equally use that reasoning for the mandatory redistribution case. No software under that license is free for you, but that's the fault of the situation and not the license. The bugfix is to get off the island. It's pretty similar to the bloody lunatic test; the license says you can't distribute unless you follow some condition (distribute source/send changes off the island), but an external force having nothing to do with the author of the software forces you not to follow the condition. Why is it the fault of the external force in one case and the fault of the license in the other? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desert island test
On Fri, 29 Feb 2008, Mike Hommey wrote: You're taking it in the wrong order. The GPL doesn't forbid you to distribute the code because of the bloody murderer. The dissident and the desert island tests are about restrictions *inside* the license, related to some situations. Here, you just expose a situation. The GPL prohibits you from distributing the program unless you do something (distributing code) that the bloody murderer keeps you from doing. The mandatory changes license prohibits you from distributing the program unless you do something (send the changes back) that being stuck on an island keeps you from doing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: web hosting providers' modified .debs
On Fri, 25 Jan 2008, John Halton wrote: Maybe I'm missing someone, but in this scenario, isn't it the user who logs in, not the administrator, making the copy? The administrator wouldn't be conveying anything since he's not copying. The user is distributing someone else's software to himself, which might be illegal, but would not obligate the administrator. The definition of propagate in GPL v.3 is quite broad, and includes not only copying but making available to the public and so on. So the administrator will almost certainly be propagating the work. I still don't think so. To propagate a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. Not all kinds of making available are propagation. It's only propagation if making it available would, without permission, make you liable for infringement. Merely leaving a readable file where someone can copy it doesn't make you liable for infringement. (Imagine the situation where the software isn't GPL. If I lend you my laptop, that doesn't make me liable for infringement just because the copy of Microsoft Windows on it is readable and could be copied.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueCrypt License 2.3
On Sun, 13 Jan 2008, Måns Rullgård wrote: 1. You may not use, modify, reproduce, derive from, (re)distribute, or sublicense This Product, or portion(s) thereof, except as expressly provided under this License. Any attempt (even if permitted by applicable law) otherwise to use, modify, reproduce, derive from, (re)distribute, or sublicense This Product, or portion(s) thereof, automatically and immediately terminates Your rights under this License. This paragraph explicitly denies rights available under fair use or fair dealing. Hopefully a non-op (?), but not good. If it were a contract, such a clause could be valid. Whether licenses like this are to be considered contracts is matter for debate. Of course, the clause doesn't keep you from performing fair use. It can't. What it does do, however, is say that if you attempt fair use, you lose the rights the license grants and can *only* do fair use and nothing else. I think this clause is self-evidently valid. Saying we will only let you distribute the program if you don't perform fair use can't possibly be any more invalid than we will only let you distribute the program if you agree not to pet any cats. It's making distribution of the program contingent on limiting your otherwise legal actions somewhere else. The fact that fair use is guaranteed by law doesn't make the clause invalid; your right to keep your money is also guaranteed by law, but a clause saying you have to give up some money to distribute the program is obviously legal. This should, however, make the program non-free. A payment of not exercising fair use rights is no more DFSG-free than a payment of cash. Disclaimer: IANAL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark scope (just for the record)
On Fri, 7 Sep 2007, Rick Moen wrote: Pepsico doesn't ask the Coca-Cola Company's permission to publish claims that its sugar-water is better tasting than is Coca-Cola. That ought to be a big, fat clue, but far too many people have been successfully conned and don't think about the implications. But on the other hand, Pepsi doesn't put out a soft drink which says on the label This is Coca-Cola, but it is not produced or endorsed by the Coca-Cola Corporation. I didn't say it is. Yes, you did. Substituting in for the names Bob and Earthbadger, you think that if Debian says This is Debian Firefox, it is not produced by the Mozilla Corporation, that's okay. How's that different from saying This is Pepsi's Coca-Cola, it isn't produced by the Coca-Cola corporation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark scope (just for the record)
On Thu, 6 Sep 2007, Rick Moen wrote: Pepsico doesn't ask the Coca-Cola Company's permission to publish claims that its sugar-water is better tasting than is Coca-Cola. That ought to be a big, fat clue, but far too many people have been successfully conned and don't think about the implications. But on the other hand, Pepsi doesn't put out a soft drink which says on the label This is Coca-Cola, but it is not produced or endorsed by the Coca-Cola Corporation. In the Mozilla example, Debian's using the word to refer to their own product. In the Pepsi example, Pepsi is using the word to refer to the competitor's product, even though they're comparing it against their own product. -- 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, 1 May 2007, Fabian Fagerholm wrote: First of all, the interpretation we wish to claim consistency under is all bits that are distributed by Debian must follow the DFSG. Copyright law is not distributed by Debian, and needs no exception. Neither do licenses, which are distributed because of necessity, Something that is distributed by necessity is still distributed. Copyright law is actually *not distributed* by Debian. We don't have a text file which says Current Copyright Law and which includes excerpts from legal codes and judges' decisions. -- 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 Fri, 27 Apr 2007, Fabian Fagerholm wrote: What I'm saying is that the DFSG can only be applied to a certain point. We can require that license terms applied to works are DFSG-free. We can require that license terms applied to those licenses-as-works are DFSG-free. We can require that the license terms applied to those licenses-as-works are DFSG-free and so on, moving up the chain, until we hit bare copyright law at the top of the chain (meaning that there are no specified additional terms to apply; the license-as-a-work at that point has no explicit license). We would then need to add an exception for copyright law, because what we originally set out to do was to claim consistency under a certain (flawed, IMO) interpretation, because the consistency would stop at that last link in the chain, and because there is no way we can affect the existence or nature of copyright law by simply changing words in the DFSG. I still don't see the problem. First of all, the interpretation we wish to claim consistency under is all bits that are distributed by Debian must follow the DFSG. Copyright law is not distributed by Debian, and needs no exception. Second, what will happen in practice is that there will be text that is so short and functional that it can't be copyrighted. Example: package is under the GPL. The FSF then says you can reuse the text of the GPL as long as you change the name. There's no infinite regress, because you can reuse the text of the GPL as long as you change the name isn't copyrightable. -- 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, 24 Apr 2007, Fabian Fagerholm wrote: The GPL as a work, however, is *not* free, since the license on that work does not grant the requisite freedoms. Surely there's no disagreement on this? It is irrelevant, because of several reasons that have already been pointed out in this discussion. Everyone has their favourite reason, and the most important in my own opinion is that the requirements of freedom in the SC and DFSG do not extend to the licenses of the licenses that works are licensed under. This follows necessarily from the legal composition of copyright, which readers are expected to be (at least vaguely) familiar with when considering these issues. There is no need to explain or define copyright in these documents. What are you talking about? If by legal composition of copyright you mean license texts are copyrighted, so they cannot be DFSG-free, that's false. We include plenty of copyrighted materials which are DFSG-free. If by legal composition of copyright you mean license texts are used to indicate how other things are copyrighted, and cannot do that if they are modified, that's wrong. You're assuming that modifying a license means trying to relicense the thing the license is attached to. That's incorrect. One might want to modify a license in order to reuse the license somewhere else. Modifying a license in this way has no bearing on the licensing of the work to which the license was originally attached, and the copyright of the work does not restrict modifying the license this way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Mon, 12 Mar 2007, Francesco Poli wrote: Anyway, whenever some form of a work is the preferred one for modifications (i.e.: source form), but, at the same time, is inconvenient to distribute, well, the work is inconvenient to distribute in a Free manner! This is an unfortunate technical obstacle to freeing works and should be removed by technology improvements: we should not surrender and lower our freeness standards in order to accept sourceless works as if they were Free. That's not a technical obstacle, that's a we're stupid to recommend that the author do something horribly inconvenient obstacle. If the work is inconvenient to distribute free, then we should be telling the author distributing it free is probably not what you want to do. Besides, the DFSG don't define source code as the preferred form for modification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Tue, 13 Mar 2007, Francesco Poli wrote: If the work is inconvenient to distribute free, then we should be telling the author distributing it free is probably not what you want to do. I don't think the Debian Project (or debian-legal contributors) should promote non-free software. On the other hand, I think even Debian should try to be truthful. If Free for audio and video is so awkward that an author who asks for a free license probably doesn't want one, then we should tell the author this is what it means; you probably don't want one. Not saying that when you know very well it's true be lying by omission. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Don Armstrong wrote: If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. This is the same problem that exists for any work under the GPL; there's nothing special about recordings here. The difference with recordings is that it's much more plausible that the author would do this. Video source is more awkward than program source, and video binaries are more useful than program binaries. This means that there are many content creators who don't want to release source, not because they want to restrict their users, but because they don't think the hassle is worth it--it's a much greater hassle for a much smaller benefit, than releasing the source of a program. Indeed, it's much more likely the author might not even realize that the GPL requires his raw video or audio files. So yes, the same problem *can* exist for any work, but the special circumstances of media files make it much more likely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Mon, 12 Mar 2007, Francesco Poli wrote: When the uncompressed form is really huge, maybe even the upstream maintainer thinks it's inconvenient to work with. In that case, he/she may prefer to modify the compressed form directly: hence, the source code is really the compressed form! That doesn't follow. The uncompressed form may be inconvenient because it's dozens of times the size of the video and he has limited bandwidth. Or because he's releasing 40 videos but he only edits them one at a time, and has enough disk space for an edit (since he edits them one at a time), but not for all 40 at once. Or because the uncompressed form fits on 15 DVDs and the compressed form fits on one and copying 15 extra DVDs is too much work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Ben Finney wrote: Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Actually, there's one big problem. The GPL's preferred form for modification clause. Unless the creators of the podcast directly edit the MP3--which is rather unlikely--the MP3 is not the preferred form for modification and putting the MP3 under GPL without releasing the raw audio files grants no rights at all. GPLing video has a similar problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Francesco Poli wrote: In order to release the audio/video recording in a DFSG-free manner, they should release the source as well, as defined in the GNU GPL v2. Wonderful! That is a feature of the GPL, not a bug! Recipients should not be in a position of disadvantage with respect to original authors, or otherwise it's not really Free Software. It's a bug. If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. So the result is that you can't demand source and can't distribute the work either. That doesn't give free software the least bit of benefit. The problem with source for audio or video files is that the source is much larger and much more awkward to distribute than the final result. It's plausible that the author doesn't care what you do with his work, but doesn't want to give you these files simply because it's a lot of trouble. If he then puts his work under GPL, he may not even realize that he's given you no permission to redistribute at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
1. Was GR 2006-01 an exception to the DFSG, or a clarification of our principles? Consider an analogy. An amusement park ride puts up a sign saying that kids must be 4 feet tall to enter. A little while later, it declares that kids must be allowed in if they're 47 inches, and furthermore that this isn't a change to the 4 foot rule. Is that a clarification or an exception? I'd say that someone who couldn't count obviously meant for it to be a clarification. But clarifying means choosing an interpretation of something ambiguous; 4 feet isn't ambiguous. They may have *meant* to clarify the rule, but they really didn't. The same applies to the GR. People had well-reasoned, detailed, arguments about why the GFDL doesn't meet the DFSG. A GR can tell you to ignore a valid argument, but it can't actually make the valid argument become invalid. It can't, in other words, clarify the rules into saying something they don't say; that isn't what a clarification is. It's an exception which pretends to be a clarification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BCFG Public License
On Sat, 29 Jul 2006, Matthew Garrett wrote: I think you're misunderstanding. You're not asked to agree with the law, merely its existence. Imagine a hypothetical where five years from now someone believes that the law is unconstitutional and is embroiled in a lawsuit about it against the government. This person does not, in fact, agree that the law restricts people in any way (since an unconstitutional law is not valid). However, the software license demands that he agree that he is restricted by law, so he is barred from using the software. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BCFG Public License
On 29 Jul 2006, Michael Poole wrote: The license demands that a licensor agree that the US government might criminally prosecute him for prohibited exports from the United States (the license says OF GOODS AND/OR TECHNICAL DATA). Good luck arguing against that broad statement; there are plenty of cases where goods -- such as military surplus missile launchers -- are export controlled with no viable constitutional question and some, probably smaller, number of cases where technical data are validly export controlled. So you're saying that the clause would be satisfied if the user agrees that goods other than the program are subject to export law, even if he believes the program itself isn't? I suppose that's a valid way to read it, but it does seem strange. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL violates DFSG point 3
On Thu, 1 Jun 2006, Ben Finney wrote: It occurs to me that the GPL itself violates section 3 of the DFSG, it cannot be freely modified. (See: A useful summary of the position of debian-legal on this point is here: URL:http://lists.debian.org/debian-legal/2004/02/msg00290.html That summary doesn't consider the possibility that someone might want to modify the license for some purpose other than licensing the software to which it's currently attached. For instance, they might want to use the modified license on their own work. Or they might want to use it in a book about licenses in some context where the whole book is a derivative work of the license. Or they might want to print it on a T-shirt but only have room for half of it. That summary can justify certain limitations on license texts, such as making it clear that the revised license isn't being applied to something you don't have permission to relicense. But it doesn't justify allowing complete unmodifiability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Tue, 28 Mar 2006, Walter Landry wrote: These examples give partial specifications, not full specifications. I see no reason to read the GFDL as requiring only partial specifications. What's the difference between full specification for A, which is a subset of B and partial specification of B, other than semantics? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Results for Debian's Position on the GFDL
On Fri, 17 Mar 2006, Adam McKenna wrote: I didn't mean give an example of such a jurisdiction, I meant give an example of infringing, non-distributional copying. Umm, copying that occurs in such a jurisdiction? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Distributing GPL software.
On Mon, 16 Jan 2006, olive wrote: I think his point is this: Person A can legally make and distribute a lot of copies to B without putting B under any obligation, as long as B doesn't make more copies himself. B, who now has a lot of copies, can dispose of them as he wishes by first sale, without having to obey the GPL. This is probably right. B will not break the law. However; the GPL give you permission to distribute the software only if you agree to it. If you don't agree to it you loose your permission and only the normal copyright law apply. So if B do that he loose forever the possibility of duplicating, redistributing the sofware that he have himself downloaded and modyfing the software since the GPL does not apply to him anymore. I don't think this is a price that is worth paying... But couldn't B say he accepts the license for some copies, but not for others? For the copies that A gave him, he can reject the license and distribute them by copyright law (first sale). For anything that he wants to copy or modify himself, he has to accept the GPL, but he can accept the GPL for just those particular items. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Distributing GPL software.
On Fri, 13 Jan 2006, Mahesh T. Pai wrote: And I'm still not in prison. How come? 1. You have some kind of understanding with the copyright holder of the program in question. 2. You have not been prosecuted != you have not broken the law. I think his point is this: Person A can legally make and distribute a lot of copies to B without putting B under any obligation, as long as B doesn't make more copies himself. B, who now has a lot of copies, can dispose of them as he wishes by first sale, without having to obey the GPL. The argument what if it was Windows XP instead of GPL software doesn't seem to work here. The first step would become Person A can legally make and distribute a lot of copies of Windows XP to B... This statement would be true for GPL software and false for Windows XP, so the argument wouldn't extend to Windows XP. Only licenses that contain the specific quirks of the GPL would have this loophole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
On Wed, 4 Jan 2006, Marco Franzen wrote: What if I don't want to link it? I may want to - just publish (parts of) the source code (or (of) a modified version) - modify it into something that isn't a library and publish the source - paste code fragments into an embedded/free-standing application (which does not link against anything, not even libc), maybe with some modifications to fit the new environment - copy code fragments into documentation Couldn't you just link it with something, putting it under the terms of the GPL, then unlink it, whereupon it's still under the terms of the GPL, then use it as above? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rules for submitting licenses for review
On Fri, 26 Aug 2005, Raul Miller wrote: That said, it looks to me like this license grants you the right to use those game mechanics, including making and distributiong modified versions of them. If you've spotted someplace in this license which prohibits that kind of thing, I'd appreciate it if you could point that out to me. Since game mechanics are not copyrightable, without a license at all you still have the right to use them. Although the license does grant you the right to use them, it grants you that with conditions. Granting you the right to use something under some conditions, when previously you could use it without conditions, is taking away rights, not granting them. I suggest doing a Google groups search for rec.games.frp.dnd, TSR, and game mechanics to see just what was going on at the time. The fact that they've used other licenses in the past, and might not offer all their material under this license does not constitute a flaw in this license. It helps show that your interpretation is rather strained. TSR claimed pretty close to the time of the OGL that game mechanics are copyrightable in ways contrary to copyright law. The OGL's claim to license you to use game mechanics needs to be seen in light of that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rules for submitting licenses for review
On Sat, 27 Aug 2005, Ricardo Gladwell wrote: AFAIK, there is no pre-existing case law that demonstrates that game mechanics are or are not copyrightable. There have been cases of people being brought to court for making compatible rules (Palladium I believe did this) but I think the case was settled out of court. I would also note that there is a long history in the RPG industry of publishing games with mechanics that are identical if not the same as Dungeons and Dragons. Some searching on the Copyright Office's website showed me this: http://www.copyright.gov/fls/fl108.html Once a game has been made public, nothing in the copyright law prevents others from developing another game based on similar principles. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rules for submitting licenses for review
On Thu, 25 Aug 2005, Raul Miller wrote: Game mechanics, methods, procedures, etc. are not copyrightable. To the degree that their concrete implementations are a creative work, their implementations are copyrightable. But that's not what TSR means. They're claiming that if you use their game mechanics in your own work, even without copying a concrete implementation, you're violating copyright. This started in the mid-1990s when TSR tried to shut down a lot of sites for using game mechanics (whether or not anything was copied). For instance, see http://groups.google.com/group/rec.games.frp.dnd/browse_thread/thread/ce23543781715cdf . TSR claimed that if you created material using TSR game mechanics and posted it elsewhere than on TSR's own site, you were violating copyright. Later, TSR changed hands, and they created the OGL, which seemed to take a more lenient stance, but which was still based around the idea that TSR can copyright game mechanics and that you need a license to create materials that use them. I suggest doing a Google groups search for rec.games.frp.dnd, TSR, and game mechanics to see just what was going on at the time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rules for submitting licenses for review
On Tue, 23 Aug 2005, Raul Miller wrote: The problem is that the GPL says if you obey this license, you can do these things that you otherwise can't do. The OGL says if you obey this license, you can do these things that are otherwise legal anyway, we just promise not to bankrupt you with baseless lawsuits that we know you can't afford to defend against. Game rules can't be copyrighted (though their specific text can), but the OGL is based around TSR's/WotC's attempt to assert copyright in its game rules and claim that nobody can use them without a license. I disagree. OGL says: 4. Grant and Consideration: In consideration for agreeing to use this License, the Contributors grant You a perpetual, worldwide, royalty-free, non-exclusive license with the exact terms of this License to Use, the Open Game Content. Yes--but it also defines open game content as follows: Open Game Content means the game mechanic and includes the methods, procedures, processes and routines to the extent such content does not embody the Product Identity and is an enhancement over the prior art and any additional content clearly identified as Open Game Content by the Contributor, and means any work covered by this License, including translations and derivative works under copyright law, but specifically excludes Product Identity. Game mechanics, methods, procedures, etc. are not copyrightable. This license is an attempt to license something that TSR (or its successors) don't own. A license which licenses something that can't be owned isn't a DFSG-free license. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rules for submitting licenses for review
On 22 Aug 2005, MJ Ray wrote: I was hoping to review the Open Game License[1]. Although not a software license, it has been used in the popular PCGen software application which could, hypothetically, be added to Debian at some point. [1] http://www.opengamingfoundation.org/ogl.html I think there's a small risk in the COPYRIGHT NOTICE wording if someone adds adverts in it and there's a half-implementation of trademark law in it, but I'm not sure it's enough to block a work under that licence. I don't understand why it needed a new licence for this. I've complained about the OGL from almost the moment it was introduced. The problem is that the GPL says if you obey this license, you can do these things that you otherwise can't do. The OGL says if you obey this license, you can do these things that are otherwise legal anyway, we just promise not to bankrupt you with baseless lawsuits that we know you can't afford to defend against. Game rules can't be copyrighted (though their specific text can), but the OGL is based around TSR's/WotC's attempt to assert copyright in its game rules and claim that nobody can use them without a license. Something which purports to license you to use game rules can't be DFSG-free. It's like a license to write critical articles, or a license to allow fair use, or a license to breathe air. Part 7 also seems to be unfree because it forbids you from using trademarks in legal ways, but that isn't the biggest problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BitTorrent Open Source License (Proposed Changes)
On Mon, 1 Aug 2005, Michael Poole wrote: It is not a fee: implicit warranty and similar liabilities are created by law. Where a warranty disclaimer applies, it is because the relevant law allows that warranty to be disclaimed. I'm not sure that's a distinction. After all, a fee applies when the relevant law allows a fee to be charged. I apparently did not express what I wanted to. For implicit warranties, the law creates the cost and (at least sometimes) allows that created cost to be disclaimed. For choice of venue, the license is what imposes the cost, and that is why it is forbidden by the DFSG. I wouldn't compare an implicit warranty to a choice of venue. I would compare a disclaimer of an implicit warranty to a choice of venue. The implicit warranty itself is imposed by law, but the disclaimer is imposed by the license. Think of it this way: Normally you could sue because of breach of an implicit warranty. However, because there is a disclaimer, you're not allowed to do this. Normally you could have a lawsuit in a more convenient venue to you. However, because there's a choice of venue clause, you're not allowed to do this. In both cases, if the clause was not in the license at all, you get to do something that you can't do with the clause present. They both seem to be costs, in a sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BitTorrent Open Source License (Proposed Changes)
On Sun, 31 Jul 2005, Michael Poole wrote: It is not a fee: implicit warranty and similar liabilities are created by law. Where a warranty disclaimer applies, it is because the relevant law allows that warranty to be disclaimed. I'm not sure that's a distinction. After all, a fee applies when the relevant law allows a fee to be charged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL module linked with a GPL lib
On Fri, 29 Jul 2005, Michael K. Edwards wrote: If the GPL lets the user do it, it isn't infringement at all. You can't have contributory infringement if there's no infringement. The GPL is not a new copyright statute with the power to override the meaning of infringement, nor do its drafting oddities render it null. ...you may perhaps say that the GPL explicitly allows the end user to link the software in private. But that is merely a basis for arguing that the copyright holder is estopped from suing end users who are simply using what they have received in good faith. That does not mean that a distributor could not be successfully sued for copyright infringement _if_ it were correct that the act of linking breached rights reserved to the copyright holder. By this reasoning, if linking is normally a breach of rights, I could give you some BSD licensed software and do exactly the same thing. I am estopped from suing you for linking with my BSD software, but I can still prevent other people from helping you link with it, since the linking is still infringement despte the license telling you you can do it. If I give you some software and say that you can link it in private, that's *permission*. The GPL doesn't need to override the meaning of infringement, because it already has a meaning, and that meaning already says that if you have permission to do it, it isn't infringement. If it isn't infringement, helping you do it can't be contributory infingement. Compare, for instance, Micro Star v. FormGen. You could argue that the unauthorized sequel didn't really exist until an end user loaded the MAP file into Duke Nukem, and Micro Star neither authored the MAP files nor distributed them together with Duke Nukem. Oh, come on. FormGen claimed that the MAP files themselves were infringements, because they used the game setting. It didn't matter that the user linked them, because they were unauthorized sequels all by themselves. This was one of the distinctions the court made between it and the Game Genie case, because in their view the Game Genie only lets consumers create derivatives, but the MAP files are derivatives. # More significantly, Nintendo alleged only contributory infringement-- # that Galoob was helping consumers create derivative works; FormGen here # alleges direct infringement by Micro Star, because the MAP files encompass # new Duke stories, which are themselves derivative works. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL module linked with a GPL lib
On Thu, 28 Jul 2005, Michael K. Edwards wrote: But that doesn't apply in the case of automatic systems for users to do the link. The GPL allows users to do what they want privately, so the users aren't performing infringing acts themselves. While Andrew's parallel to Grokster is IMHO inapposite, he is correct that a theory of contributory infringement (also available in other countries under the name vicarious liability) allows recovery from a party whose role is to facilitate and encourage infringement by others. The availability of some sort of personal-use safe harbor (as in European patent law, for instance; see thread on XMMS and MP3) does not necessarily protect a commercial entity whose product or service does not have (or is not actually marketed for the sake of) substantial non-infringing uses. While that's true, the right of users to link the software in private isn't a personal-use safe harbor--it's explicitly allowed by the GPL. If the GPL lets the user do it, it isn't infringement at all. You can't have contributory infringement if there's no infringement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL module linked with a GPL lib
On Thu, 28 Jul 2005, Andrew Suffield wrote: Anyway, the person who recombines the film and track, in the case of dynamic linking, is the *USER*, in the process of using the program, and copyrights protection do not apply at that moment, as per 17USC. You Are Wrong. Under US law, this is Contributory Infringement, which carries a full array of jail terms. SCOTUS just upheld it against Grokster a few weeks ago. Providing an automated system for users to perform infringing acts, with the sole intent of aiding them in performing those acts, is the same as doing them yourself. But that doesn't apply in the case of automatic systems for users to do the link. The GPL allows users to do what they want privately, so the users aren't performing infringing acts themselves. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
On Mon, 23 May 2005, Nathanael Nerode wrote: They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. Well, that's fine; we don't want to use their trademarks for things which aren't designed to work with their hardware, now do we? (At least, except in a historical context, which certainly wouldn't be a trademark violation.) What does trademarks stripped mean though? Does it mean they want the product not to be called trademark? Or do they want every single line of code that has the name in it removed, so, for instance, a help box or even code comments that say Based on the driver for trademark must be removed? And what if the trademark is used in a different context; would that be like the Apache license that prohibits you from using it in a program called Apache Helicpoter Simulation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
Isn't it always legal to use a trademark to refer to the product in question? If you have a driver for a piece of hardware that has the trademarked name X, it should be legal to name it driver for X. (Of course, what is legal and what keeps you from getting sued aren't nececssarily the same.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What makes software copyrightable anyway?
On Thu, 12 May 2005, Raul Miller wrote: And, I might add, this is another respect in which the FSF FAQ verges upon the dishonest. Since 17 USC 117 explicitly limits the scope of what can be considered infringement under section 106, it also nullifies any claims of contributory infringement when a distributor arranges for things to be combined at run-time. This doesn't do anything for the distributor of copyright infringing software. 17 USC 117 only protects users of that software. But doesn't contributory infringement require that you're contributing to someone's direct infringement? So protecting users (by making their actions not be direct infringement) has the effect of protecting distributors too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... Wouldn't this, if true, make the GPL non-free? Requiring someone to keep names of anything in the executabe affects compatibility; what if in 2010 the newest Microsoft Windows decides to check for EXPORT_SYMBOL_GPL on all your software and shut itself down if it detects any? Or suppose you have two programs that use the symbol in different ways and both are under GPL and you're not allowed to change the name used in either one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, 28 Feb 2005, Jeremy Hankins wrote: No, it doesn't. The lone JPEG is only non-free if the lossless version is what the original author would use to make a modification to the JPEG. If, for example, the original author threw out the lossless version immediately on making the JPEG, that's strong evidence it's not needed. Not necessarily. It might be that at the time the original author had no intention of any future modifications at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Fri, 14 Jan 2005, Brian Thomas Sniffen wrote: First, there's a separation exception: 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. This means that it's fine for Kaffe and Eclipse to be distributed separately. But it's not OK to throw them both on a CD and label it Debian OS, if running eclipse loads a program made out of copies of Kaffe and Eclipse. There's also the OS exception, which Debian can't use... There's a third exception. The implicit exception if you're not doing something which requires permission from us in the first place, then we can't prevent you from doing it. I think people are arguing that it falls under the third exception, not the other two.
Re: LCC and blobs
On Thu, 6 Jan 2005, Raul Miller wrote: And of course there's the absurd situation where a manufacturer decides to move firmware from a device from a ROM to a CD and Debian suddenly cannot provide a driver for it Most likely, Debian IS able to provide a driver for it. Well, unless we can't figure out how to pull the firmware off that cd and feed it to the hardware. I meant that Debian can't provide a driver that meets its standards of freedom. Current consensus seems to be that when the firmware was in ROM, Debian could provide a driver, and when the firmware is on CD, it can't (because it depends on the non-free software on the CD) even though in the second scenario the user has all the rights that he does in the first scenario (assuming the CD, like the ROM, can be transferred along with the device, used if you have the device it came with, etc.)
Re: LCC and blobs
On Thu, 6 Jan 2005, Josh Triplett wrote: If the firmware we have packaged in non-free comes standard on the device, then the driver does not need a copy of the firmware, so it does not have a dependency on it. Hm? The driver does need a copy of the firmware. It needs a copy that is present on the device. Otherwise, we end up in the absurd situation in which if the non-free item becomes distributable (slightly less non-free) and someone packages it in non-free, such that the driver can then properly express its dependencies, the driver suddenly needs to go to contrib. And of course there's the absurd situation where a manufacturer decides to move firmware from a device from a ROM to a CD and Debian suddenly cannot provide a driver for it
Re: LCC and blobs
On Tue, 28 Dec 2004, Brian Thomas Sniffen wrote: That said, or not, I do think there's a significant practical difference between firmware which ships as software, say on a CD accompanying the device, and firmware which ships on the device: * The firmware on the CD is typically not redistributable by the end user. Future users can't get it without somebody along the line breaking a EULA. That depends on the details of the particular firmware license. If the license says you can give this to someone if it accompanies a transfer of the device, then there's no practical difference between that and the firmware being inside the device itself. (Well, except if someone loses the CD, but all that really means is that the device is more fragile than normal.) * The firmware blob on CD, if free, can be easily modified by end users. It's just software. Even given the preferred form for modification, it's much more difficult to re-flash a firmware chip on hardware not designed for regular firmware uploads. But that's a strange reason to require that the firmware blob on CD be free. It's essentially saying if you can make it hard to modify the firmware, you don't need to allow modifications at all. Can a company release an encrypted CD, so that it's as difficult to modify the firmware on CD as it is in a chip, and then have it count as part of the hardware? And what about firmware which gets checksummed by the device in such a way that you can modify the firmware but can't upload it?
Re: LCC and blobs
On Tue, 28 Dec 2004, Brian Thomas Sniffen wrote: I probably can't. No good with that sort of thing. Software on disk is software. Also, I could pull the Pentium off my motherboard, scan its contents to disk, and open that in any editor I like -- right? So if a BIOS can be scanned by a program running on the system, the BIOS counts as software and has to be free?
Re: LCC and blobs
On Tue, 28 Dec 2004, Brian Thomas Sniffen wrote: But that's a strange reason to require that the firmware blob on CD be free. It's essentially saying if you can make it hard to modify the firmware, you don't need to allow modifications at all. As always, intent matters. But most people have several different things in mind when they do something. Intent is rarely a simple all or nothing question. I'm sure that while the manufacturer had lots of reasons to put firmware on a chip, the idea ... and it'll be harder for the users to get at it crossed people's minds a good many times, even if it wasn't the only reason for doing it. I think the scenario They moved the firmware from a chip to a CD, so we can't distribute a driver any more is ridiculous. Any attempt to modify the rules to handle firmware should either fix that situation or else *really* justify why that's desirable. The difference with a chip on a card is not that it's difficult to modify, but that it's not treatable as software! I can't open it in Emacs, so it isn't software. There are DRM scenarios where you can't open in Emacs something that's obviously software. There are also cases where you could open firmware chips in Emacs (for instance, a BIOS, or a device which has debug commands to dump its own firmware).
Re: GPL and command-line libraries
On Thu, 2 Dec 2004, Raul Miller wrote: If there is -- if Wontshare in some way tries to enforce the use of readline, then this non-distributable product is being distributed Why? Distributing X, which relies on Y, isn't the same as distributing the combination. Surely you don't think that if I distribute Word Perfect, which relies on Windows, I'm actually distributing a combination of WP and Windows and thus I'm violating Microsoft's copyright.
Re: GPL and command-line libraries
On Fri, 3 Dec 2004, Raul Miller wrote: If I ship some product in three parts, such that the combination of those three parts is consistently assembled and used, then I'm distributing that product. Says who? Shipping parts can be different from shipping a combination if for some reason you are given different rights to ship parts and ship combinations. It's just that outside free licenses that never happens.
Re: GPL compatible license?
On Tue, 16 Nov 2004, Martin Schulze wrote: or instead you may notify anyone requesting source that it is freely available from the Elm Development Group. Doesn't it say that it is sufficient to inform the users that they can fetch the entire source code of Elm from the Elm Development Group? Additionally, aren't the users informed about this properly by distributing this license, e.g. in /usr/share/doc/*/copyright? What happens if 10 years from now the Elm Development Group no longer exists? This clause can't be enough, since anyone might become unable to satisfy it.
Re: non-free firmware: driver in main or contrib
On Mon, 25 Oct 2004, Josh Triplett wrote: I would disqualify that driver from main not because it depended on a Windows driver, but because it depended on having Windows itself. I see; so some dependencies on non-free software are to be considered acceptable, while others are not? I meant dependency in the same sense that a driver might depend on there being something in an eprom or other replaceable part. If you agree that that's dependency, then yes some dependencies on non-free software are acceptable. hardware/eprom and hardware/CD combinations, hardware/Windows isn't sold together and the user would have to get Windows separately--not because he And in many cases, the user would need to get the firmware for a device separately. Not all drivers that require firmware images provide the means to extract it from a manufacturer's CD; some choose to extract it from updates provided on the manufacturer's website, or from Windows drivers obtained separately, or downloaded from the Linux driver author's site. Some firmware images have even been sniffed off of a bus during the reverse engineering used to create the Linux driver. I think that this is a good place to stick to the spirit of the rules. If anyone with the hardware can get the firmware under restrictions no worse than if it was physically part of the hardware, then treat it as if it was physically part of the hardware. And what of my second suggested case (which you omitted in your reply), where the Linux driver could load the necessary piece of the Windows driver without needing Windows? Would you permit that driver to go in main, since it would only require the Windows driver and not Windows itself? Your argument seems to suggest that you would. It would only suggest this if hardware+Windows driver gives the user the same rights as hardware+eprom would. I think this is unlikely to be the case. Many hardware devices are also general-purpose pieces of equipment, using general-purpose processors, whose firmware is just software compiled for that architecture. The point of firmware is generally to make a piece of hardware less hard-wired and more reparable, which is to some extent a step in the direction of general-purpose. In other words, whether or not the device is general-purpose enough that something uploaded to it should be treated as part of the device is a judgment call. Yes, that is true. On the other hand, the arguments for _not_ including such drivers in main are trivially explainable with one simple test: can someone with the necessary hardware, having only main in their sources.list, and without installing any non-Debian software, build, install, and successfully run the package? Those requirements are assuming the conclusion. The question is about how to treat software in comparison to hardware. That list of requirements specifies that hardware and software should be treated differently and thus assumes a particular answer to the question. Finally, I'm curious: what is it that makes people so adamant that these drivers should be in main, rather than contrib? You and others have mentioned various practical arguments, but none related to freedom. The argument it's as free as this other thing, which you consider free enough *is* about freedom.
Re: non-free firmware: driver in main or contrib?
On Mon, 25 Oct 2004, Brian Thomas Sniffen wrote: The person who has the device doesn't neceessarily have the firmware, because the firmware can be removed. The person doesn't have the device at that point -- only part of it. The same reasoning applies for both examples if you refer to the combination of hardware plus CD as a device. But that imagined device is broken: it needs another component to read the CD, load the firmware off of it into the computer's memory, process it there, then upload that to the device itself. Then by the same reasoning the all-hardware device is broken too. It needs another component (driver) to function. Neither the version with the CD nor the version with the eeprom will function by themselves. Of course, there are relatively few examples where you'd *want* to remove the eeprom from the device, but similarly there are few examples where you'd want to sell the device without accompanying it with a CD. Of course, those examples include this one: inadvertently losing track of the CD. That's a difference, but it ...just means I need to rephrase the question: So what's the difference between a device with firmware, and a device with a CD plus a non-free license letting you copy the CD? In that case, losing the CD doesn't matter because the user can get another copy. The user can't modify the software on the CD, but then he had no permission to modify it when it's in hardware either. I'm not sure this last is true, for the same reasons that I may saw any book I have purchased in half and sell the result to you. Modifying software stored in an eeprom involves some sort of copying that cutting a book in half doesn't, and therefore is prohibited under copyright law. There's no difference between the CD and the eeprom here.
Re: non-free firmware: driver in main or contrib?
On Mon, 25 Oct 2004, Glenn Maynard wrote: The driver is opening a block of data on disk, reading it and sending it to the hardware. If that data does not exist, the driver will be incapable of driving the hardware. For the driver to work, in addition to installing it and the hardware device, you have to find and install a copy of the firmware to where the driver expects to find it. Both the driver and the hardware require this block of data to be useful. This is a clear-cut Depends:. And if the device has an eprom, then for the driver to work, you have to find and install an eprom containing a copy of the code. (The eprom is harder to lose, of course, so it's *usually* already installed, but it's not clear that that difference is relevant.)
Re: non-free firmware: driver in main or contrib?
On Mon, 25 Oct 2004, Brian Thomas Sniffen wrote: And that is a functional difference: in one case the owner of the device who has downloaded some Debian software has to go get some other software and load it onto his machine; in the other case he doesn't. That's not a functional difference. In the other case the user has to go get an eprom and make sure it's plugged into the socket. You could counter by pointing out that the eprom is normally already there, but so is the CD.
Re: non-free firmware: driver in main or contrib?
On Mon, 25 Oct 2004, Josh Triplett wrote: However, suppose that your statement were true. Why stop there? Consider the case of a piece of hardware which could not be initialized correctly except by the Windows driver. In order for the device to work, a user would need to boot up Windows, allow the driver to initialize the device, and soft-boot into GNU/Linux, at which point the driver could control the device. Also suppose that the Windows driver was shipped on the manufacturer's CD, so the user already has it (which is almost always the case). Repeat after me: Drivers don't require initialization, hardware devices require initialization. :) So why can't this driver go in main too? I would disqualify that driver from main not because it depended on a Windows driver, but because it depended on having Windows itself. Unlike the hardware/eprom and hardware/CD combinations, hardware/Windows isn't sold together and the user would have to get Windows separately--not because he lost a CD that he once had, but because Windows really is a separate item in more ways than just physically being on a different disk. For another example, suppose there were a new, proprietary 3D graphics interface, ClosedGL, only implemented by ATI's and nVidia's proprietary driver. Suppose someone wanted to package a game that used ClosedGL. Repeat after me: Programs don't require drivers, hardware devices require drivers (to provide APIs). :) So by your arguments, why can't this game go in main? You may as well claim that a hard drive is a piece of hardware which does word processing, that a word processor is a driver for this piece of hardware, and that without this driver you lose some functionality because the hard drive won't process words. The flaw in this reasoning is that a hard drive or a graphics card is a general purpose piece of equipment. The driver isn't a driver.
