Re: EDICT, GPL
On Tue, Apr 23, 2002 at 07:55:11PM -0400, Glenn Maynard wrote: (CC to d-legal; it's related, at least due to edict-el, and they're a lot better at this topic than I am.) It's much easier if you provide some context when you CC like this. Does this prevent plain GPL software from using the EDICT? No. Look, for example, at Quake. It's GPL, but at least for a long period of time (and arguably still today) there is only one useable data set, and it was non-free. The license of the data could forbid use with a GPLed program, but could not prohibit the GPLed program, as that's a seperate entity. (I had trouble convincing RMS that non-software didn't really fit under the GPL.) The GPL isn't the greatest license for non-software. The principles of the GPL - right to modify and distribute, rejection of right to take proprietary - are very relevant to non-software, though, and the GPL is a decent lazy-man's way of applying them. What exactly was the question here? -- David Starner - [EMAIL PROTECTED] It's not a habit; it's cool; I feel alive. If you don't have it you're on the other side. - K's Choice (probably referring to the Internet) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EDICT, GPL
On Wed, Apr 24, 2002 at 01:20:28AM -0500, David Starner wrote: It's much easier if you provide some context when you CC like this. I forgot to link the license: http://www.csse.monash.edu.au/groups/edrdg/newlic.html (or in the non-free package edict, I assume.) No. Look, for example, at Quake. It's GPL, but at least for a long period of time (and arguably still today) there is only one useable data set, and it was non-free. The license of the data could forbid use with a GPLed program, but could not prohibit the GPLed program, as that's a seperate entity. Did it actually do this? It had distribution restrictions, of course (which could bump the game itself in contrib, lacking any free datasets), but are there also restrictions on what kinds of programs can use the data, as there are here? (I don't have the Q1 license handy.) It'd be rather odd for id to GPL the source to the game, but not allow their own dataset to be used with it, though I could see the publisher causing that kind of thing. What exactly was the question here? (c, i) Permission is granted: ... to use these files as part of software which is distributed free-of-charge ... What's necessary to allow a program to use the EDICT? If a GPL program can use the EDICT freely, that'd seem to indicate this clause is unenforcable, at least in this case; the program might end up being distributed commercially. (How do restrictions like this work? How could it be satisfied if I placed a program that uses the EDICT in the public domain?) edict-el appears to be a plain GPL program that uses it; there seems to be nothing stopping commercial distribution. There are examples of GPL programs that use the EDICT with and without this restriction added, though in the cases where it was, I don't know if this was the reason. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EDICT, GPL
[Glenn Maynard (EDICT, GPL) writes:] Jim Breen [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: [This was on the sci.lang.japan newsgroup, and concerned some shareware MacOSX software that used the EDICT/KANJDIC/etc. Japanese dictionary files I have compiled.] Originally you couldn't charge for packaging it. But people were free to write shareware or commercial software, e.g. Unidict, then say to use this you need to download EDICT which is free.. It was partly to regularize this that I changed the licence. Does this prevent plain GPL software from using the EDICT? Not at all. My own xjdic is GPLed. It's in /debian/pool/contrib/x/xjdic among other places. I've seen GPL software (ie. JFC) with an added no commercial use restriction. (I hope they know that if they do this, they're no longer GPL-compatible and so can't link against GPL libraries.) I've seen that comment which Glenn Rosenthal added on the JFC page after he quotes the GPL text. He actually says .. without the explicit permission of the respective copyright holder(s). That makes any software using the EDICT non-free, at least according to Debian. I have heard that Debian has problems with this approach. Of course xjdic doesn't *need* EDICT; it can use any Japanese/English file in the right format. As far as I am concerned the software and its data are decoupled in this case. Hmm. edict-el in Debian appears to be GPL'd without any exceptions, which would seem to put it in violation (since that means the program can be used and sold commercially.) It could end up being sold as part of contrib. (I'm somewhat curious on whether the EDICT license can prevent things like the distribution of edict-el. It uses it, but could potentially be used with similarly-formatted databases, and the distribution of edict-el seems to have nothing inherently related to EDICT.) Exactly. edict-el and xjdic are in the same boat. I see edict-el is in /contrib too. Aside, Permission for such usage will normally be granted in return for a fee based on a proportion of either the subscription charges. Of either the subscription charges or what? Sorry, that either is a left-over from a earlier version. (I had trouble convincing RMS that non-software didn't really fit under the GPL.) Of course, you'll have people everything from the GPL does apply to non-software to databases and documentation *are* software. Regardless of this, it seems obvious that the *principles* of the GPL can easily apply to documentation and databases. (Yet others will debate the value of doing that.) Up to a point. The problem with putting a data file under the GPL is that a dataset is probably far enough off from the program source of a program that accesses it that the you must release the source dictum may not be supportable. I'm curious why you'd have tried to convince RMS of this: it seems clear you don't want the EDICT to be freely used commercially, and the GPL would allow this. I suppose you could apply a license that allows commercial use in free software, and alternative, fee-based terms for proprietary software. (That is, alternative GPLish-or-no-commercial-use licensing.) That could probably get EDICT into Debian, which is currently in non-free. The issue came up years ago with RMS, and has been touched on a few times since. The problem is that a lot of contributors provided data which was their IP on the condition of no commercial exploitation. I have got agreement that that be extended to the sort of non-exclusive licence for commercial use. I have given Debian and other Linux distros full permission to include EDICT, etc. free-of-charge. If they doesn't want to take it up, it's not my problem. Cheers Jim -- Jim Breen [EMAIL PROTECTED] http://www.csse.monash.edu.au/~jwb/] Computer Science Software Engineering,Tel: +61 3 9905 3298 P.O Box 26, Monash University, Fax: +61 3 9905 5146 Clayton VIC 3800, Australia [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EDICT, GPL
[Glenn Maynard (Re: EDICT, GPL) writes:] On Wed, Apr 24, 2002 at 01:20:28AM -0500, David Starner wrote: What exactly was the question here? (c, i) Permission is granted: ... to use these files as part of software which is distributed free-of-charge ... This is quoting from the licence covering EDICT, etc. What's necessary to allow a program to use the EDICT? Basically the program either must not be sold, or if it is, it gets specific permission in return for a licence fee. If a GPL program can use the EDICT freely, that'd seem to indicate this clause is unenforcable, at least in this case; the program might end up being distributed commercially. At the stage such software begins commercial distribution, it ceases to be eligible to use the file(s) fre-of-charge. Enforcibility? I would have all sorts of jurisdictional problems in establishing a tort existed. My licence has been violated a couple of times in the past and for their pains the perpetrators attracted so much vitriolic email, once the violation became public, that they backed off in a hurry. (How do restrictions like this work? How could it be satisfied if I placed a program that uses the EDICT in the public domain?) edict-el appears to be a plain GPL program that uses it; there seems to be nothing stopping commercial distribution. There are examples of GPL programs that use the EDICT with and without this restriction added, though in the cases where it was, I don't know if this was the reason. You can sell edict-el as much as you like. But if you pop a copy of EDICT on the CD for the package to use, I'll make the violation public and call in my cheer squad. 8-)} Cheers Jim -- Jim Breen [EMAIL PROTECTED] http://www.csse.monash.edu.au/~jwb/] Computer Science Software Engineering,Tel: +61 3 9905 3298 P.O Box 26, Monash University, Fax: +61 3 9905 5146 Clayton VIC 3800, Australia [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mplayer again.
Hello, I was just about to send packages for uploading, when one more issue about mplayer's sources creeped up, one file seems to bee a bit controversial on licence side ( divx_vbr.c, included later in this mail). Since then, I've located way around it: Michael Niedermayer implemented a two-pass mode directly into libavcodec. What are my options now? - can I remove this file in debian-patch? i.e. it would be it .orig.tar.gz, and get removed in diff, or do I need fix upstream first? Also, how problematic is what we have here? /* * divx4_vbr.c * * Copyright (C) Thomas streich - June 2001 * * 2-pass code OpenDivX port: * Copyright (C) 2001 Christoph Lampert [EMAIL PROTECTED] * * This file is part of transcode, a linux video stream * processing tool * * transcode is free software; you can redistribute it and/or * modify * it under the terms of the GNU General Public License as * published by * the Free Software Foundation; either version 2, or (at * your option) * any later version. * * transcode 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. * See the * GNU General Public License for more details. * * You should have received a copy of the GNU * General Public License * along with GNU Make; see the file COPYING. If * not, write to * the Free Software Foundation, 675 Mass Ave, * Cambridge, MA 02139, USA. * */ /** *Two-pass-code from OpenDivX ** ** * Large parts of this code were taken from * VbrControl() * * from the OpenDivX project, (C) * divxnetworks, * * this code is published under DivX Open * license, which * * can be found... somewhere... oh, * whatever... * **/ -- Eyck, The Public Ambivalent Individual. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EDICT, GPL
Jim Breen wrote in two separate messages: What's necessary to allow a program to use the EDICT? Basically the program either must not be sold, or if it is, it gets specific permission in return for a licence fee. This indicates that edict should either be in non-free or not distributed at all by Debian. I have given Debian and other Linux distros full permission to include EDICT, etc. free-of-charge. If they doesn't want to take it up, it's not my problem. This indicates that we can distribute edict in non-free (which we are). I have heard that Debian has problems with this approach. Of course xjdic doesn't *need* EDICT; it can use any Japanese/English file in the right format. As far as I am concerned the software and its data are decoupled in this case. If edict-el is in the same boat, then this indicates that there's no ambiguity concerning its GPLed license status or its dependency on Emacs. As long as there is no free data set for edict-el or xjdic to use, then both should be in contrib (which they are). Both the letter and spirit of the GPL disclaim any requirements on data, so this concern from Glenn: If a GPL program can use the EDICT freely, that'd seem to indicate this clause is unenforcable, at least in this case; the program might end up being distributed commercially. isn't an issue. You can sell edict-el as much as you like. But if you pop a copy of EDICT on the CD for the package to use, I'll make the violation public and call in my cheer squad. 8-)} This further backs up the licensing status for both edict and edict-el. It would appear, therefore, that the status quo concerning the Debian packages is exactly correct. Of course, IANAL, standard disclaimers apply. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mplayer again.
Dariush Pietrzak [EMAIL PROTECTED] wrote: Hello, I was just about to send packages for uploading, when one more issue about mplayer's sources creeped up, one file seems to bee a bit controversial on licence side ( divx_vbr.c, included later in this mail). Since then, I've located way around it: Michael Niedermayer implemented a two-pass mode directly into libavcodec. What are my options now? - can I remove this file in debian-patch? i.e. it would be it .orig.tar.gz, and get removed in diff, or do I need fix upstream first? Also, how problematic is what we have here? I found a copy of a DivX Open License at http://www.videocoding.de/divx_license.html. It is incompatible with the GPL. In any case, the copyright notice is so vague, that we don't know what license it is really under. So you should take it out of the .orig.tar.gz. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EDICT, GPL
On Wed, Apr 24, 2002 at 04:05:01AM -0400, Glenn Maynard wrote: Did it [Quake] actually do this? It had distribution restrictions, of course (which could bump the game itself in contrib, lacking any free datasets), but are there also restrictions on what kinds of programs can use the data, as there are here? No. I was just using Quake as an example of a free program that had non-free data; as far as I know, ID didn't care what you used the data with, so long as you paid for it. What exactly was the question here? (c, i) Permission is granted: ... to use these files as part of software which is distributed free-of-charge ... It's a bitch of a requirement, and probably gets violated all the time with stuff like Debian contrib on CheapBytes disks. But that couldn't affect the license on the code, unless it compiled it in. (Yes, I realize it's a moot point in this case.) -- David Starner - [EMAIL PROTECTED] It's not a habit; it's cool; I feel alive. If you don't have it you're on the other side. - K's Choice (probably referring to the Internet) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [cfi-en] Printing restriction -- should move to non-free ?
Oops, I sent this directly to Mr. Hedin, posting to list now. On Mon, Apr 22, 2002 at 11:27:04PM +0200, Mikael Hedin wrote: Mail Delivery System writes: This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after RCPT TO:[EMAIL PROTECTED]: host mxpool01.netaddress.usa.net [165.212.8.32]: 550 [EMAIL PROTECTED]... User not known nirgendwo is German for nobody, this looks like one of those no-spam e-mail addresses, not the real address of the translator, try looking for his real e-mail address elsewhere. Hope this helps Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any. pgpezyHfeKHa4.pgp Description: PGP signature
Non-US definition
Howdy, The package information page[1] contains the following description of the Non-US section: Non-US/Main and Non-US/Non-Free These packages cannot be exported from the USA, they are mostly encryption software packages, or software that is encumbered by patent issues. Most of them are free, but some are non-free. The CD FAQ[2] contains the following description: There are two variants of the binary-1 CD, one with and one without software of the non-US category. Non-US software may be imported into the US without problems, but exporting it from the US is forbidden by law (it contains strong cryptographic code). I suppose both of these will need to be updated once the crypto-in-main transition is complete. I am primarily concerned with the status of patent-encumbered software, however. May it be distributed within the USA? How does this avoid the patent problems? Matt 1. http://www.debian.org/distrib/packages 2. http://www.debian.org/CD/faq/ pgpKlwEs8V0ZD.pgp Description: PGP signature
Re: EDICT, GPL
On Wed, Apr 24, 2002 at 06:39:05PM +1000, Jim Breen wrote: I've seen that comment which Glenn Rosenthal added on the JFC page after he quotes the GPL text. He actually says .. without the explicit permission of the respective copyright holder(s). That's implicit, anyway. (Copyright holders can always grant permission.) It's a kind of restriction that would make me think twice about contributing to it, unless it was done for some unavoidable reason, such as for using the EDICT, which isn't the case. (I prefer donating time to free software, which this isn't.) Up to a point. The problem with putting a data file under the GPL is that a dataset is probably far enough off from the program source of a program that accesses it that the you must release the source dictum may not be supportable. Well, it might be mostly irrelevant if the form it's normally used is the same as its source. When it's relevant, I'd think it's always supportable. It's moot here, anyway, if the licensing of some of the data is out of your hands. The issue came up years ago with RMS, and has been touched on a few times since. The problem is that a lot of contributors provided data which was their IP on the condition of no commercial exploitation. I have got agreement that that be extended to the sort of non-exclusive licence for commercial use. Well, that's unfortunate, but probably unavoidable if some of that contributed data is published elsewhere. A quick question about SKIP data in the kanjidic: The license page says both that you have permission to include it, and that SKIP data must be protected from illegal copying and distribution, using such measures encryption. The data must be encrypted if it is to be used in any kind of product, including commercial products, software and freeware. (in the SKIP license.) Is this requirement waived? I'd imagine that if he allowed the data to be included, he's no longer interested in preventing illegal distribution by encryption. (It's obviously not encrypted within kanjidic.) Seems like a fairly useless requirement, anyway. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EDICT, GPL
[Glenn Maynard (Re: EDICT, GPL) writes:] [Background: SKIP (System of Kanji Indexing by Patterns) is Jack Halpern's indexing system used in both his kanji dictionaries.] A quick question about SKIP data in the kanjidic: The license page says both that you have permission to include it, and that SKIP data must be protected from illegal copying and distribution, using such measures encryption. The data must be encrypted if it is to be used in any kind of product, including commercial products, software and freeware. (in the SKIP license.) Is this requirement waived? I'd imagine that if he allowed the data to be included, he's no longer interested in preventing illegal distribution by encryption. (It's obviously not encrypted within kanjidic.) Seems like a fairly useless requirement, anyway. I included those words because Jack wanted them. I think they are pretty meaningless. Jack is a friend of mine, and I know he has a well-honed dislike of IP piracy, having seen some of his writings simply appropriated by others. He's no IT guru though, pace the above, and I'm not convinced that his SKIP is that well protected. The 3000-odd codes published in his New Japanese-English Character Dictionary may well be copyright, but since AFAIK he did not patent the system, the SKIP codes for the remaining 9,000-odd kanji in my kanji databases, most of which I generated, are out of his control. I'm happy to go along with the notion that he controls their disposition. I can't really imagine anyone else charging in to publish a SKIP-oriented kanji dictionary. The market isn't big enough. Cheers Jim -- Jim Breen [EMAIL PROTECTED] http://www.csse.monash.edu.au/~jwb/] Computer Science Software Engineering,Tel: +61 3 9905 3298 P.O Box 26, Monash University, Fax: +61 3 9905 5146 Clayton VIC 3800, Australia [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
