Re: Linux Magazin Germany, affecting Debian's image?!
On Thu, Jul 20, 2006 at 12:24:20PM +0200, Goswin von Brederlow wrote: PS: Is it true that Ubuntu things about supplying a 3 year offer for source under 3b so derivates of ubuntu can go sourcelss? A nice idea, to be sure, but it doesn't seem particularly helpful, unless the derivative isn't modifying anything GPL-covered (possible, I suppose, but unlikely), since the moment you modify something you don't have a written offer from someone for that source code, and can't use 3c any more. More likely, Ubuntu is going to let people who use the Soyuz (I think that's the one) part of Launchpad to define their own custom distros provide the source alongside the binaries, thus letting everyone go the 3a route (as long as you sign your sanity away by agreeing to use Launchpad for ever more). - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Wed, Jul 19, 2006 at 12:15:48PM +0200, Wouter Verhelst wrote: On Wed, Jul 19, 2006 at 07:51:30AM +1000, Matthew Palmer wrote: On Tue, Jul 18, 2006 at 05:04:02PM +0200, Wouter Verhelst wrote: If you distribute binary images with a magazine and have something in that magazine saying if you want the source write to address with a photocopy of this specific text, everything is okay. No more so than if you want the source write to address, enclosing a picture of you petting a cat. Unless, of course, you can show that a photocopy of this specific text is a necessary cost of providing the source. You're only required to provide the source to those who received a written promise from you or anyone who passed on the written promise. 3b) Accompany it with a written offer [...] to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code Sorry, I just don't see how your interpretation comes out of that. Can you elaborate further? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Tue, Jul 18, 2006 at 05:04:02PM +0200, Wouter Verhelst wrote: If you distribute binary images with a magazine and have something in that magazine saying if you want the source write to address with a photocopy of this specific text, everything is okay. No more so than if you want the source write to address, enclosing a picture of you petting a cat. Unless, of course, you can show that a photocopy of this specific text is a necessary cost of providing the source. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Mon, Jul 17, 2006 at 12:13:54PM +1000, Andrew Donnellan wrote: The GPL only states that there has to be a written offer for at least 3yrs to send the *source code* by post for cost price, to anyone *who you distribute it to.* This means the magazine only has to send the source code to *people who buy it.* You were perfectly right until that last sentence. If I buy a copy of the magazine, with the DVD, and it contains a written offer to provide source code for the GPL material on the DVD (thus satisfying section 3 via 3b) I can redistribute that DVD non-commercially to other parties, giving them the written offer provided by the magazine (thus satisfying section 3 via 3c). The magazine is allowed to charge at-cost for the source distribution, so as not to leave themselves out of pocket. So a person doesn't have to have actually purchased a copy of the magazine in order to be entitled to the source code. In fact, I can't see anything that says that a person requesting the source has to have a copy of the DVD at all. This is, of course, why satisfying section 3 via 3a -- Accompany with complete source -- is the clever way to go. If we're talking about a stripped-down Sarge on a DVD, I'd guess there'd probably be enough space left over to put the source on the DVD as well, so this whole e-mail might be unnecessary. grin - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Magazin Germany, affecting Debian's image?!
On Mon, Jul 17, 2006 at 02:54:53PM +1000, Andrew Donnellan wrote: On 7/17/06, Matthew Palmer [EMAIL PROTECTED] wrote: You were perfectly right until that last sentence. If I buy a copy of the magazine, with the DVD, and it contains a written offer to provide source code for the GPL material on the DVD (thus satisfying section 3 via 3b) I can redistribute that DVD non-commercially to other parties, giving them the written offer provided by the magazine (thus satisfying section 3 via 3c). The magazine is allowed to charge at-cost for the source distribution, so as not to leave themselves out of pocket. Correct, I forgot about 3c. Still, the point is that only purchasers or people who the purchasers have given it to non-commercially have the right to get the source at cost price. The GPL does not require anyone to give anything away for free, except the source at cost price. Full ACK, for it equal to the written offer for source code. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun clarifies intent of the DLJ
On Wed, Jun 07, 2006 at 09:42:01AM -0700, Ken Arromdee wrote: On Tue, 6 Jun 2006, Matthew Palmer wrote: Although I'm not sure about the absolute validity of the argument that licences have to be written incomprehensibly, I certainly think that this revised FAQ preamble allows people to rely on the statements in the FAQ sufficiently. I don't get it. Half of the problem was that the FAQ said it doesn't count, but the other half of the problem was that the license said that the FAQ doesn't count. It seems that fixing the preamble fixes the first half of the problem but not the second. That would then fall under the part in the FAQ which says that if there are conflicts between the FAQ and the licence, please let Sun know and they'll fix them. So now you know what to do. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun clarifies intent of the DLJ
On Mon, Jun 05, 2006 at 11:58:44PM -0500, Tom Marble wrote: We have made an updated revision to the DLJ FAQ (now version 1.2) which is publicly available at [5]. The preamble to the FAQ has been specifically re-written to clarify the relationship between the FAQ and the license itself. Although I'm not sure about the absolute validity of the argument that licences have to be written incomprehensibly, I certainly think that this revised FAQ preamble allows people to rely on the statements in the FAQ sufficiently. - Matt signature.asc Description: Digital signature
Re: Bacula license (was Re: Help Selecting License for Bacula Documentation
On Thu, May 18, 2006 at 01:27:55PM -0500, John Goerzen wrote: On Thu, May 18, 2006 at 01:54:46PM -0400, Nathanael Nerode wrote: This is an additional restriction beyond those in the GPL. Therefore this renders the license GPL-incompatible. Which is a major problem since other parts of Bacula are licensed under pure GPL. :-P Does the permission to link with OpenSSL also make it GPL-incompatible? No, because it's an additional permission, not an additional restriction. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: infos about alien licenses
On Thu, Apr 13, 2006 at 07:45:46AM +0200, Wolfgang Lonien wrote: I don't think that the clause is necessarily a problem, though -- it reads to me more like a slightly more emphatic no-warranty clause, rather than a prohibition against use in any particular field. So what should I do in this case? Contact the upstream and ask him/her to change that license? Or do we accept this? I'll leave that open to discussion here for the moment. Since there hasn't been any dissenting opinion expressed, I'd say that there's no massive objection to the clause as it stands. My advice would be to put in a quiet query to upstream asking if they really think that the extra bit is really needed, since there's a perfectly good warranty disclaimer already, and whether they meant for the clause to be binding or merely advisory. In the meantime, get the packaging sorted out (both the app itself and the dependencies). My guess is that upstream probably boilerplated the template from somewhere, or thought it was a good idea at the time(tm), and will be happy to clarify their intent. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: infos about alien licenses
On Wed, Apr 12, 2006 at 02:35:28PM +0200, Wolfgang Lonien wrote: | |-- DCOracle2-cvs.tar.gz- +(ask) | |-- TwistedSNMP-0.3.13.tar.gz - +(ask) | `-- sybase-0.36.tar.gz - +(ask) The DCOracle2/LICENSE.txt reads: Copyright (c) 2000, Digital Creations, Fredericksburg, VA, USA. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions, and the disclaimer that follows. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Digital Creations nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. MIT-like. No problems. The TwistedSNMP-0.3.13/license.txt reads: TwistedSNMP, SNMP Protocol for the Twisted Networking Framework Copyright (c) 2003-2005, Michael C. Fletcher, Patrick K. O'Brien All rights reserved. THIS SOFTWARE IS NOT FAULT TOLERANT AND SHOULD NOT BE USED IN ANY SITUATION ENDANGERING HUMAN LIFE OR PROPERTY. This is possibly problematic, depending on how you define should. I'd take it as just being a restatement of the whole no warranty, if it breaks you get to keep both pieces thing, but it could be read as forbidding use in the mentioned areas. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. The name of the authors may not be used to endorse or promote products derived from this software without specific prior written permission. Again, MIT-like. All good, with the possible exception of the No danger clause, which I think is harmless. while the sybase-0.36/LICENCE reads: Copyright (C) 2002, Object Craft P/L, Melbourne, Australia. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Object Craft nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. MIT-like. All good. As an aside, I've got packages of python-sybase floating around here somewhere. I never uploaded them to Debian because I have no interest in maintaining them long-term, I just whipped them up for a client one day. I can send them to you if you'd like (and possibly sponsor them into Debian if you want to maintain it yourself). - matt signature.asc Description: Digital signature
Re: infos about alien licenses
On Thu, Apr 13, 2006 at 06:12:59AM +0200, Wolfgang Lonien wrote: The TwistedSNMP-0.3.13/license.txt reads: THIS SOFTWARE IS NOT FAULT TOLERANT AND SHOULD NOT BE USED IN ANY SITUATION ENDANGERING HUMAN LIFE OR PROPERTY. This is possibly problematic, depending on how you define should. I'd take it as just being a restatement of the whole no warranty, if it breaks you get to keep both pieces thing, Yeah. Interestingly (as a side-note), I have read something like this before. It's in the Windows License concerning the use of Sun's Java. I think it means something like: If you use this to steer an airplane and that crashes, don't blame us - we warned you. Not very reassuring IMHO. Practically, though, that's no less than you get with every other piece of software -- free or otherwise. but it could be read as forbidding use in the mentioned areas. ... which would be against the policy, right? Yes, it would discriminate against fields of endeavour, and hence fail DFSG #mumble. Hmmm. I wonder if that still could be packaged, and where to - contrib? non-free? The latter, I suppose? If it doesn't pass the DFSG (but we can legally distribute it), then it goes in non-free. If it depends on non-free stuff, but is itself free, then it goes in contrib. So twisted-snmp would go in non-free, and the dependent application would go in contrib. I don't think that the clause is necessarily a problem, though -- it reads to me more like a slightly more emphatic no-warranty clause, rather than a prohibition against use in any particular field. As an aside, I've got packages of python-sybase floating around here somewhere. I never uploaded them to Debian because I have no interest in maintaining them long-term, I just whipped them up for a client one day. I can send them to you if you'd like (and possibly sponsor them into Debian if you want to maintain it yourself). That would be cool. Thanks for your kind offer. http://www.hezmatt.org/~mpalmer/tmp/python-sybase_0.37* I don't guarantee a stellar packaging job -- it was a quick whipup for a client. It's not egregiously defective, though. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPL and Source Code
On Tue, Apr 04, 2006 at 12:23:09PM +1000, Craig Southeren wrote: On Mon, 03 Apr 2006 22:13:24 -0400 Anthony DeRobertis [EMAIL PROTECTED] wrote: Craig Southeren wrote: I'm not sure what an NMU is, but why are these not put into the SVN archive? A NMU (non-maintainer upload) is an upload by a person who is not the maintainer of the package. Reasons for this happening are numerous; trivial example is an urgent fix when the maintainer is on vacation, is missing, is too busy, etc. An NMU would often not be put in the revision control archive because the person doing the NMU does not have commit access to said repository. Does the NMU end up in the repository eventually? If so, then I don't see this as a problem. 1) Not necessarily. 2) It's not appropriate for us to be violating the licence until someone gets around to importing the NMU into the repository (assuming it ever does go in). Because if it is Debian policy to distribute binaries where the source code is not guaranteed to be publically available, then yes, I think that could be a problem regardless of whether the license is MPL or GPL. The source code is guaranteed to be publicly available for as long as the binary is, but no longer. This is in violation of most Open Source licenses. For example, the GPL requires source to be available on demand for up to three years after distribution of the binary by electronic means. No. It. Doesn't. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPL and Source Code
On Tue, Apr 04, 2006 at 01:51:05PM +1000, Craig Southeren wrote: This means theoretically that the lifetime of a source release under the GPL is the same as a binary release. Once the binary is no longer distributed, then the source no longer has to be distributed either. As a user, the seems more than a little unreasonable, but if that's what the license says.. If you think you might want the source later, then download it when you download the binary. The MPL requirement for 12 months seems quite reasonable, and I can't see that any packager (Debian included) would have a problem with meeting it. Perhaps not philosophically, but practially we really can't do it. First up, it'd take a non-trivial amount of modification to the archive scripts. Next, archiving every release for some period of time would almost certainly chew a whole hell of a lot more disk space, and I don't think we could differentiate between MPL and non-MPL easily enough to only archive the MPL stuff. I'm up in the air about whether the MPL would require every mirror operator to carry all previous releases, or if they could be somewhere off-to-the-side (mpl-compliance.debian.org, anyone?) -- if all mirror operators need to carry all previous versions, then that's an even bigger problem. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPL and Source Code
On Tue, Apr 04, 2006 at 01:22:50PM +1000, Craig Southeren wrote: On Mon, 3 Apr 2006 20:03:37 -0700 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Apr 04, 2006 at 12:23:09PM +1000, Craig Southeren wrote: Because if it is Debian policy to distribute binaries where the source code is not guaranteed to be publically available, then yes, I think that could be a problem regardless of whether the license is MPL or GPL. The source code is guaranteed to be publicly available for as long as the binary is, but no longer. This is in violation of most Open Source licenses. For example, the GPL requires source to be available on demand for up to three years after distribution of the binary by electronic means. False. The GPL requirements are satisfied by making the source code available together with the binaries. The FSF has clarified that distributing works together on an ftp site satisfies the intent of the GPL's requirement of a medium customarily used for software interchange. Sorry, I disagree. Section 3 of the GPL states that the source code for a binary-only distribution must be available on demand for three years. It's a good thing we're not doing binary-only distribution then. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPL and Source Code
On Tue, Apr 04, 2006 at 01:36:42PM +1000, Craig Southeren wrote: On Mon, 03 Apr 2006 23:15:05 -0400 Anthony DeRobertis [EMAIL PROTECTED] wrote: Craig Southeren wrote: Does the NMU end up in the repository eventually? If so, then I don't see this as a problem. Merging the NMU into the repository is up to the maintainer (he is, after all, the one with commit access). Given Debian's persistent problems with MIA maintainers, it â unfortunately â does not always happen. Multiple NMU's often go completely unacknowledged by the maintainer. I guess I'm confused, probably because I'm not knowledgable about Debian release procedures. Where does the source for the NMU reside? Is it just part of the source code release, but not in the repository? If so, then I don't see any problem - as long as the source code is available somewhere, then that's all that is needed to conform the the license. The source code is stored adjacent to the binary packages, on the archive servers and mirrors. When the binary packages are removed, the associated source package is removed along with it. - Matt
Re: FYI: Savannah forces new projects to use GFDL for documentation
On Thu, Feb 09, 2006 at 12:04:22PM -0500, Felix Kühling wrote: I was trying to get my project DRIconf hosted at Savannah (Non-GNU) and found out that as of recently Savannah requires all new projects to license their documentation under the GFDL, which we all know, Debian considers non-free. Dual-licensing under GFDL and GPL is apparently still ok. See also http://savannah.gnu.org/task/?func=detailitemitem_id=5214. While it's their servers, their rules, I think the rule is a bit weird -- the GPL is a perfectly valid licence for documentation, and it's an FSF licence. What really got me saying whoa! though is the blog post linked from the ticket comments -- the fourth paragraph seems to say that Savannah changed it's policy because Debian doesn't think the GFDL is DFSG-free. Worrying, if true. - Matt
Re: FYI: Savannah forces new projects to use GFDL for documentation
On Thu, Feb 09, 2006 at 09:43:42PM +, Sune Vuorela wrote: On 2006-02-09, Matthew Palmer [EMAIL PROTECTED] wrote: What really got me saying whoa! though is the blog post linked from the ticket comments -- the fourth paragraph seems to say that Savannah changed it's policy because Debian doesn't think the GFDL is DFSG-free. Worrying, if true. The blog entry is now gone. Any one got a copy ? Unfortunately, I closed the tab, and there's no Google-cache copy of it I can find. In the absence of an actual copy of the post for people to make their own opinion on, all I can assert is that what is currently in the blog post: Savannah didn't changed its policy about the license requirements, there exists only plans to do so. Currently we discuss how usefull it is to use the GNU GPL for your documentations. However you can even use any other GNU FDL compatible licenses to release your documentations - so we don't limit anybody there. contradicts my recollection of what was in that post this morning -- that the new Savannah policy on documentation licencing *had* changed. It also quoted a message on the sv-hackers list to that effect. I'll note the thorough pointlessness of allowing GFDL-compatible licences. The GFDL isn't even compatible with itself amongst it's many variants; what is the hope that anything *else* will be compatible with it? My opinion of FSF people is descending rapidly here. Revising history is never a good sign. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
On Thu, Jan 19, 2006 at 02:46:52PM +0100, Yorick Cool wrote: What is it you need to get rid of trolls? Fire? A billy goat gruff, if I remember my mythology correctly. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clause 7d (was Re: Ironies abound (was Re: GPL v3 draft)
On Wed, Jan 18, 2006 at 11:52:39AM -0500, Nathanael Nerode wrote: Well, I did devise a potentially Free alternative for the infamous clause 7d after an hour or two's thought. The key point here was that the clause suffered from specifying means rather than ends, which we have diagnosed as a major source of license drafting errors. By restricting the functionality of the program and all derivative works, it causes endless trouble. Instead, I attempted to rewrite this as a restriction which could be imposed on the recipients of the license. So here it is: 7d. They may require that propagation of a covered work which causes it to have users other than You, must enable all users of the work to make and receive copies of the work. This leverages the careful definition of propagate up top, so that it avoids restricting any acitivities which do not require a copyright license. Neat, although a little hard to understand at first without the context of what it's referring to (Affero-like clauses). I certainly like it a lot more than the original, though, for all of the reasons you cited. What do other people think of this? It's sort of a forced distribution clause, but it only forces distribution to the people you're already allowing to use the program. If it's considered acceptable, we could push to have this replace the proposed (7d). I like it, and I think it should be definitely be submitted to the FSF for consideration. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
On Fri, Nov 25, 2005 at 10:39:05PM +0100, Alexander Terekhov wrote: On 11/25/05, Glenn Maynard [EMAIL PROTECTED] wrote: [...] PHP scripts are derivative works of PHP sounds like someone misinterpreted the FSF's claims, and ended up believing that the source of a program is a derivative work of its libraries. (That, unlike the FSF's claims, seems ^^^ Unlike? http://web.novalis.org/talks/compliance-for-developers/slide-49.html Still a derivative work: * Distributing the source code of software which links to a library -- Copyright (c) 2004, Free Software Foundation. I can't find anything in those slides which provides a basis for that claim, and the technical issues surrounding such a claim are very complex. I'd be interested to see a video or something of a talk associated with these slides, to see if there's any additional context which the speaker provides to back up this claim. As it stands, this looks like a line the author pickup around the office koolaid-cooler. - Matt signature.asc Description: Digital signature
Re: Clarification regarding PHP License and DFSG status
On Fri, Nov 25, 2005 at 02:56:02PM -0500, Glenn Maynard wrote: On Fri, Nov 25, 2005 at 07:23:24PM +, Måns Rullgård wrote: Do you think that this licence does not require a developer of a modified package (other than PHP) to lie by saying This product includes PHP software? Perhaps the PHP folks subscribe to the view that PHP scripts are derivative works of PHP. Ye ghods, I'd hope not. That would be similar to believing that this message is a derivative of the English Grammar manual I read in school. Or that all non-trivial Emacs Lisp code must be licensed under the GPL. This position is not *that* unusual... Not being unusual doesn't make it sensible or correct. Just to take a guess at where this strange claim might have originated: The FSF (from what I understand) claims that binaries linked against GPL libraries are derivative works of the library, because the resulting binary has pieces of the GPL software in it. This isn't obviously true with C libraries, which has led to a lot of debate around the topic, but the claim isn't entirely unreasonable. Assuming that linked in your paragraph above means dynamically linked (as your second sentence suggests), can you provide a cite from the FSF which makes this claim, with rationale? I looked around, as research for my blog post Linking does not create a derivative work (http://www.hezmatt.org/~mpalmer/blog/general/linking_does_not_create_a_derivative.html) and couldn't find anything that really actually made the claim in those terms. - Matt signature.asc Description: Digital signature
Re: Clarification regarding PHP License and DFSG status
On Wed, Nov 23, 2005 at 03:08:24PM +0100, Florian Weimer wrote: * MJ Ray: Do you think that this licence does not require a developer of a modified package (other than PHP) to lie by saying This product includes PHP software? Perhaps the PHP folks subscribe to the view that PHP scripts are derivative works of PHP. Ye ghods, I'd hope not. That would be similar to believing that this message is a derivative of the English Grammar manual I read in school. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Tue, Aug 23, 2005 at 05:46:58PM -0700, Joe Stump wrote: odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. Depends: php-mail-mime - Matt signature.asc Description: Digital signature
Re: Linux and GPLv2
On Wed, Mar 23, 2005 at 04:19:31PM -0300, Humberto Massa wrote: Henning Makholm wrote: Snip explanation that does not do anything the idea that bits are treated differently by copyright just becuase they are in a file called .h. Repeating: bits that are in files called .h are not copied in your work, I think you need to stop referring to .h files. There's no general rule that can be applied to files based purely on their extension. I think what you meant to say is something like files referenced by a .c file by means of #include are only mechanically copied into your work, no creative transformation takes place and therefore no derivation takes place. Would that be accurate? That having been said, your example earlier of errno.h and the internal __err_msgs array could be an interesting example. If I reference that __err_msgs array in my own code, does that then pull in errno.h in a deeper fashion, such that I have then created a derived work of errno.h? Concluding: when you write a .c file, it is or not a derivative work on another original work independently of what the compiler and linker will do in the future. I repeat: No, but the resulting .o file may be derived from another work that the compiler also read while producing it. Not derived. Never. To derive you need inteligence (in Brazilian letter-of-law, spirit). A compiler does not have it. Neither does a linker. Only a person does. So whether or not a source file is derived from a file it includes by reference is determined before you ever wave a compiler near it? Seems sensible enough, if a little tricky to determine (I guess that's why we have courts for this, to stuff it up *properly*). I do not see how that has anything to do with the supposed magical copyright-evading capabilities of filenames that end in .h. This is an artifact of your imagination... I said only that, in general, the *usual* .h does not contain copyrightable bits. And I suspect you What you actually said initially was Basically, .h bits are *not* copyrightable. Nothing in there about in general or *usual*, except what might be implied by Basically. I'm happy to believe that you merely misexpressed yourself, but on the face of it, what you wrote implies that if you put your novel in a file called foo.h, it's not copyrightable. Remember, all we have here is written word. Cultural or linguistic shorthand rarely works well on a mailing list. Something like the common contents of a .h file, being prototypes, symbol definitions, and trivial macros, are not copyrightable would have probably had the same meaning (for you) as what you did write, and would have saved all of this subsequent confusion for the rest of us. - Matt signature.asc Description: Digital signature
Re: Linux and GPLv2
On Wed, Mar 23, 2005 at 11:45:45PM +0100, Måns Rullgård wrote: Glenn Maynard [EMAIL PROTECTED] writes: extern char **__err_msgs; #define perror(s) (fprintf(stderr,%d:%s:%s\n,errno,__err_msgs[errno])) Is myfile.c a derivative work on errno.h? The answer is NO. Of course. But myfile.o might have been if perror() were complex enough to leave any room for expressive choice. Again, irrelevant. If your implementation puts things in macros, that's your problem. Uh, what? If my implementation puts things in macros, and you distribute my implementation as part of your binaries as a result, that's *your* problem. I don't even know what you're trying to say here--you put your copyrighted code in a header and I copied it into my object file--that's your problem, not mine! doesn't make any sense at all. The only reasonable way to use your library (which for this discussion shall be assumed to have been legally obtained), is to compile programs using its header files, and link these programs against it. That's fine if you're building the program for your own use -- absent a EULA prohibiting certain uses of the work, you've got no problems (since copyright law doesn't dictate use). However, if you attempt to distribute your compiled work, with my implementation bits in them, you do need to comply with the licence of my implementation in regards to your redistribution of my copyrighted work. The issue at hand is whether the compilation phase creates an anthology work (AKA mere aggregation, I believe), or a derivative work. Are you taking the position that not even aggregation takes place during compilation? - Matt signature.asc Description: Digital signature
Re: Question regarding QPLed plugins for a GPLed app
On Thu, Mar 17, 2005 at 03:49:22PM +1100, Ben Burton wrote: I received the following response, claiming that dlopened plugins do not need to be GPL-compatible: Given that the QPL is GPL-incompatible, this raises issues for GPLed programs that wish to use this kpart. I believe this at least includes quanta and kdevelop (unless I'm mistaken). kparts are loaded at runtime. It has always been understood in the Just like dynamic libraries. Funny that. community that the license restrictions based on copyright law do not Which community? The KDE community? Perhaps. The wider free software community appears to be somewhat divided on the matter. The FSF certainly seems to lean toward the opposite interpretation in a lot of cases. apply to runtime components. The implications of reinterpreting USC 17 this way are profound. The effects on Java development alone would be catastrophic. This sounds like unfounded assertion to me, quite deeply in the FUD category. It is somewhat understood that a deliberate misuse of runtime components to circumvent copyrights is not allowed, but this is certainly NOT the I don't recall having seen much related to intent in copyright law, nor in free software licences. You can do this if you don't mean to seems a bit silly to put in a licence. case for quanta and kdevelop (you also forgot konqueror). These applications are designed to load available runtime components solely on the basis of the services made available. Follow the derivatives is my advice. Look at which works exist in the form they do due to the influence of another copyrightable work. If the API between a kpart and the applications that use them, then it is entirely possible that no derivation exists, and so no licence compatibility need exist. Unfortunately, I don't have much experience with RPC mechanisms, or with how KDE does it's work, so I don't have much specific advice to offer. There is no copyright violation occuring when a user loads a plugin at runtime, particularly one with a generic interface like a kpart. They're right about that -- no violation occurs when the user loads a plugin. However, *distributing* a plugin which is a derivative of a GPL'd work without complying with the GPL is a problem. - Matt signature.asc Description: Digital signature
Re: Linux and GPLv2
On Mon, Mar 14, 2005 at 05:53:35PM +, Gervase Markham wrote: Kuno Woudt wrote: * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. Incidentally, this is pretty badly drafted, IMO. For example: Add another one -- must offer an [...] opportunity for all users [...] to request immediate transmission by HTTP -- doesn't mean that the request must be successfully honoured... grin - Matt signature.asc Description: Digital signature
Re: Linux and GPLv2
On Sun, Mar 13, 2005 at 02:09:10PM +0100, M?ns Rullg?rd wrote: Daniel Carrera [EMAIL PROTECTED] writes: Given the vast number of Linux contributors, this means that Linux won't be able to migrate to the GPLv3 when it comes out, correct? That would be the case. Is this a problem? Personally, I'd be very sceptical about releasing code under a license containing a blanket permission to use it under another yet to be written license. What if I don't at all agree with GPLv3? The theory goes, apparently, that if you don't like the GPLv3 you can simply remove the 'or later' from all copies you distribute, and you're effectively exercising your granted right under version 2 or, at your option, any later version. I'm a little skeptical about how well this is or isn't going to work. I fear a lot of unpleasant forking action when the GPLv3 comes out, if it contains significant language changes along the lines of the GFDL (which I believe it will, from statements I've read from RMS and Hasn Reiser, amongst others), between people who decide to go v2 only and those who like v3 and will go v2 or later or even v3 or later, which will effectively produce licence-incompatible forks. - Matt signature.asc Description: Digital signature
Re: Linux and GPLv2
On Sun, Mar 13, 2005 at 08:31:38AM -0500, Daniel Carrera wrote: Henning Makholm wrote: Yes, probably. (Which, if the signals we've been getting from FSF the last few years are to be trusted, does not strike me as a bad thing at all). This issue is new to me. What are those signals? What are you talking about? Do you have a URL that might help me get up to speed? I'm too tired to dig up the exact reference, but in a large heated discussion between Hans Reiser and many other people on d-devel last year (or maybe the year before) about removing or obscuring credits in mkreiserfs, Hans Reiser stated that he had information from RMS that there would be some sort of invariant section-like clause in GPLv3. Earlier than that, in a thread here on d-legal regarding the GFDL, RMS himself made a few sideways comments regarding the content of the GPLv3. More generally, the direction that the FSF appears to have been moving in the last few years has, in some peoples' eyes, been diverging somewhat from the Debianistic view of freedom. - Matt signature.asc Description: Digital signature
Re: Help: Copyright notice
On Fri, Mar 11, 2005 at 09:31:35PM -0500, Daniel Carrera wrote: Hi guys, It's me again :-) I asked my team aobut using a dual license, GPL / CC-BY. So far the response has been good. Several people have said yay and no one has said nay. We are currently drafting the copyright notice. Some people wanted to make the terms clearer. So this is what I came up with: This document is Copyright 2004 by its contributors as defined in the section titled Authors. You can distribute it and/or modify it under the terms of either the GNU General Public License, version 2 or later (http://www.gnu.org/licenses/gpl.html), or the Creative Commons Attribution License, version 2.0 or later (http://creativecommons.org/licenses/by/2.0/). I have now been asked to run this by you. To see if anyone here sees a problem with it. In particular, someone was wondering if we were required to add under the terms of before the Creative Commons I wouldn't think so. I would guess that someone's parser is putting the wrong precedence on things, like so: ((under the terms of either the GPL) or CC-BY) or (either (under the terms of the GPL) or (CC-BY)) instead of (under the terms of either (the GPL) or (CC-BY)). I don't think it's a major problem -- as you note, Perl has identical wording, and it reads pretty easily to me as-is. About the only possible problem I could envisage would be with tying the either to the 'or' in GPLv2 or later instead of the 'or' in or the CC-BY, but the comma should put paid to that. - Matt signature.asc Description: Digital signature
Re: Bug#296369: ITP: spin -- Powerfull model checking and software verification tool
On Tue, Feb 22, 2005 at 01:54:18PM +0100, Eike Dehling wrote: Spin is distributed in source form to encourage research in formal verification, and to help a support friendly and open exchange of algorithms, ideas, and tools. The software itself has a copyright from Lucent Technologies and Bell Laboratories, and is distributed for research and educational purposes only (i.e., no guarantee of any kind is implied by the distribution of the code, and all rights are reserved by the copyright holder). For this general use of Spin, no license is required. All rights are reserved by the copyright holder fails to give permission to redistribute, let alone modify. So unless someone uses it commercially no license applies. Debian itself No licence means no right to redistribute. Copyright defaults to thou shalt not, and then a copyright holder may grant further rights to the work as he/she sees fit, either unilaterally (in, for example, the case of a free software licence) or in return from some consideration by another party. isn't commercial, so it doesn't apply here. The first sentence even encourages redistribution/modification, i'd think? How much of a problem is the restriction on commercial use, when non-commercial use is free? Is what was quoted above the sum total of the permission text that comes with spin? I don't see anything in what you quoted above which gives the right to modify and/or redistribute spin. It says Spin is distributed in source form to encourage research in formal verification, and to help support a friendly and open exchange of algorithms, ideas, and tools. That sounds more to me like we're giving you source to this so you can see how we did it, which might help you in your endeavours. It says nothing about modifying the source code to produce an improved version. - Matt signature.asc Description: Digital signature
Re: Why is choice of venue non-free ?
On Fri, Feb 04, 2005 at 03:05:22PM +, Andrew Suffield wrote: And that is why it is *possible* for choice of law clauses to be non-free: selection of laws that are intrinsically non-free is no different to writing them into the license in the first place. Precisely which ones are a problem is a tricky puzzle. Certainly selecting for one of the middle-eastern despotisms would be a problem. As opposed to middle-north-american despotisms? grin It raises an interesting point, though -- could we end up looking unfavourably at existing licences applied to software where one or more of the copyright holders lives in a jurisdiction which says if you breach the copyright of one of our citizens when you're in another country you can be sued here? So what they can effectively do is the same thing as with a choice of law clause -- launch a suit in their own country against you, under that rather idiotic (though probably on the books somewhere) jurisdiction clause, and effectively exile you from ever entering that country? Considering where the home of idiotic IP laws is, it could make for some interesting times indeed... - Matt signature.asc Description: Digital signature
Re: Why is choice of venue non-free
On Sat, Feb 05, 2005 at 05:20:14AM +1100, Glenn L McGrath wrote: On Fri, 4 Feb 2005 15:09:01 + Andrew Suffield [EMAIL PROTECTED] wrote: On Fri, Feb 04, 2005 at 12:37:53AM -0800, Sean Kellogg wrote: The laws that are applied are the place where the alleged violation occurred. If I break U.S. Copyright Law in Europe, there is no case. U.S. laws have no force in Europe. If I break U.S. Copyright Law in the United States with a some European court in the Choice of Venue clause, the European court would apply U.S. Law. If you find that a little bit off, you are beginning to see why Choice of Venue clauses are regularilly thrown out in an international setting (court's really don't like to interpret the laws of other sovereigns). You may find it interesting to note that they reject choice of venue for several of the same reasons that we do. (As a rule of thumb, anything that a court would throw out for being overbearing is going to be non-free). It would be usefull to people like me if you related your judgments (or rules of thumb) back to the DFSG. Can we hang a sign on the door saying NOTICE: The DFSG is not the Final Frontier in freedom determination and then beat with sticks anyone who fails to read it? Seriously, Glenn, not everything in the world can be grounded in the DFSG. But if you'd like one, several onerous condition groundings have been proposed up-thread. - Matt signature.asc Description: Digital signature
Re: Why is choice of venue non-free ?
On Thu, Feb 03, 2005 at 11:11:15AM -0500, Michael Poole wrote: Glenn L McGrath writes: hmm, so if parts of the license arent enforcable in the licencees jurisdiction, then a choice of venue clause could be used to drag people into a jurisdiction that they are enforcable... Yes, choice of venue clauses could drag someone into a jurisdiction that he perceives as oppressive. European individuals often think US copyright and patent laws are overbearing. US corporations often think European copyright and patent laws are too weak. Non-Muslims could be very disadvantaged if a COV clause subjects them to shari'a law. I could continue; is that sufficient illustration? To be fair, though, the problems you've listed above are just as prevalent in Choice of Law clauses. You agree that this licence agreement shall be interpreted by the laws of the state of foo can subject a European to US patent law, or a US corp. to .eu patent law, and so on, without causing either party undue cost (beyond what any lawsuit is going to cost you) due to having to present arguments in a foreign court. - Matt signature.asc Description: Digital signature
Re: prozilla: Nonfree
On Wed, Jan 12, 2005 at 11:03:19PM -0800, Brian Nelson wrote: Please use X-Debbugs-CC to Cc bug reports. See http://www.debian.org/Bugs/Reporting. On Thu, Jan 13, 2005 at 01:44:13AM -0500, Justin Pryzby wrote: ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm? No. Why would commercial use matter? Anything licensed under the GPL doesn't allow commercial use at all. raises eyebrow How did you come to that conclusion? I know no shortage of people who are using GPL'd software for commercial purposes, and no sane GPL licence holder has ever challenged that use as far as I know. Of greater worry, anyway, is that if the section quoted above is the entirety of the licence for that source file, we're stuffed, because it doesn't provide any of the usual freedoms we need. - Matt signature.asc Description: Digital signature
Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 01:30:52AM -0800, Brian Nelson wrote: On Thu, Jan 13, 2005 at 12:54:29AM -0800, Steve Langasek wrote: On Thu, Jan 13, 2005 at 12:46:51AM -0800, Brian Nelson wrote: On Thu, Jan 13, 2005 at 12:16:21AM -0800, Josh Triplett wrote: Justin Pryzby wrote: ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm? Confirmed; requirements to notify the author are non-free. Bullshit. There's no requirement whatsoever that a source file may be used at all commercially, assuming the common definition of commercial == closed source. Such a definition is wrong, and will not appear in any dictionary entry for that word. Wrong? Well http://www.tldp.org/HOWTO/Commercial-HOWTO.html uses the term to mean exactly that. I can't see (from a quick sampling of the items in there) that any of the items in that list are free, lock-in software. Could you point them out to me? Certainly other meanings could be derived, but I think my definition is the most common in the context it was used. It hasn't been for several years, and it is confusing to refer to lock-in proprietary software as commercial, as the two terms are very close to orthogonal. - Matt signature.asc Description: Digital signature
Re: prozilla: Nonfree
On Thu, Jan 13, 2005 at 02:06:29AM -0800, Brian Nelson wrote: On Thu, Jan 13, 2005 at 08:39:30PM +1100, Matthew Palmer wrote: On Thu, Jan 13, 2005 at 01:30:52AM -0800, Brian Nelson wrote: Wrong? Well http://www.tldp.org/HOWTO/Commercial-HOWTO.html uses the term to mean exactly that. I can't see (from a quick sampling of the items in there) that any of the items in that list are free, lock-in software. Could you point them out to me? Er, not sure what you mean by that. Show me the software listed in the Commercial-HOWTO which is free-as-in-beer but not free-as-in-speech, which would support your contention that the Commercial-HOWTO means Commercial as in lock-in, not Commercial as in pertaining to commerce. I couldn't find any. Everything listed in that file that I had a look at had a price tag -- a pretty standard requirement for commerce. - Matt signature.asc Description: Digital signature
Re: prozilla: Nonfree
On Wed, Jan 12, 2005 at 11:03:19PM -0800, Brian Nelson wrote: Please use X-Debbugs-CC to Cc bug reports. See http://www.debian.org/Bugs/Reporting. On Thu, Jan 13, 2005 at 01:44:13AM -0500, Justin Pryzby wrote: ftpparse.c heading: Commercial use is fine, if you let me know what programs you're using this in. Which I believes fails the desert-island test? Legal, can you confirm? No. Why would commercial use matter? Anything licensed under the GPL doesn't allow commercial use at all. raises eyebrow How did you come to that conclusion? I know no shortage of people who are using GPL'd software for commercial purposes, and no sane GPL licence holder has ever challenged that use as far as I know. Of greater worry, anyway, is that if the section quoted above is the entirety of the licence for that source file, we're stuffed, because it doesn't provide any of the usual freedoms we need. - Matt signature.asc Description: Digital signature
Re: Manpages licensed under GFDL without the license text included
On Tue, Jan 11, 2005 at 11:45:21PM +1300, Nick Phillips wrote: On Mon, Jan 10, 2005 at 10:57:56PM +0100, Francesco Poli wrote: On Mon, 10 Jan 2005 14:25:37 +1300 Nick Phillips wrote: The fact that we have conveniently ignored this problem when dealing with the GPL and BSD licenses so far does not make it go away. It is my understanding that Debian packages refer to the GPL text in /usr/share/common-licenses/ because the GPL license requires us to *accompany* the compiled form with the license text, rather than going beyond and requiring that the license text be *included* in the compiled form (that is fairly more demanding). Right. And when the .deb gets distributed on its own? Then whoever does the distributing should ensure that they comply with the terms of the licence of the software they're distributing, just as they need to now (eg distributing source for GPL'd stuff). - Matt signature.asc Description: Digital signature
Re: Manpages licensed under GFDL without the license text included
On Tue, Jan 11, 2005 at 11:45:21PM +1300, Nick Phillips wrote: On Mon, Jan 10, 2005 at 10:57:56PM +0100, Francesco Poli wrote: On Mon, 10 Jan 2005 14:25:37 +1300 Nick Phillips wrote: The fact that we have conveniently ignored this problem when dealing with the GPL and BSD licenses so far does not make it go away. It is my understanding that Debian packages refer to the GPL text in /usr/share/common-licenses/ because the GPL license requires us to *accompany* the compiled form with the license text, rather than going beyond and requiring that the license text be *included* in the compiled form (that is fairly more demanding). Right. And when the .deb gets distributed on its own? Then whoever does the distributing should ensure that they comply with the terms of the licence of the software they're distributing, just as they need to now (eg distributing source for GPL'd stuff). - Matt signature.asc Description: Digital signature
Re: Bug#287090: kaquarium: copyright file does not mention apparently unlicensed image files
On Tue, Jan 11, 2005 at 01:32:32AM +, Helen Faulkner wrote: This problem has been resolved by discussion with the copyright owner of the image files in question. The website that the images were originally distributed from [1] now has a license statement for the windows screensaver that the images are part of It's good to see a positive result on issues like this. I wonder if there's a d-legal success stories page somewhere, to offset all of the bad press... Kudos to you, too, Helen, for working with upstream to sort out the problem instead of spending 2 weeks arguing about the problem. For anyone interested, the licence is a simple 2-clause BSD-like. - Matt signature.asc Description: Digital signature
Re: Bug#287090: kaquarium: copyright file does not mention apparently unlicensed image files
On Tue, Jan 11, 2005 at 01:32:32AM +, Helen Faulkner wrote: This problem has been resolved by discussion with the copyright owner of the image files in question. The website that the images were originally distributed from [1] now has a license statement for the windows screensaver that the images are part of It's good to see a positive result on issues like this. I wonder if there's a d-legal success stories page somewhere, to offset all of the bad press... Kudos to you, too, Helen, for working with upstream to sort out the problem instead of spending 2 weeks arguing about the problem. For anyone interested, the licence is a simple 2-clause BSD-like. - Matt signature.asc Description: Digital signature
Re: Hypothetical situation to chew on
On Thu, Jan 06, 2005 at 12:21:06PM +0100, Francesco Poli wrote: On Wed, 05 Jan 2005 18:43:02 -0800 Josh Triplett wrote: I'm not referring to those who sell proprietary licenses to a separate version of the software; I'm referring to those who use a copyleft license and sell exceptions for people who want to link their proprietary software against that copylefted software. So you were thinking about libraries and the like, as I suspected... In that case I can understand the rationale behing this business model. In other cases, I find it hard... You're selling a licence to your app so that the recipient can modify and resell, but they don't want to GPL their changes. I probably wouldn't do it myself, but I can certainly envisage it as a possibility. - Matt signature.asc Description: Digital signature
Re: Non-free files in source packages?
On Fri, Jan 07, 2005 at 12:10:18AM +0100, Florian Weimer wrote: * Lewis Jardine: In the case of data tables, in many jurisdictions, a mere collection of facts is not copyrightable; the classic example is a telephone directory (everything in it is an uncreative fact; that there are thousands of them, which may have taken a lot of effort to gather, is immaterial). Databases are already copyrighted in many jurisdictions. AFAIK, this is also on the agenda of U.S. lawmakers. As I understand it, Databases are protected by a separate EU directive, which provides different (although to some degree similar) protections to that afforded by copyright. Databases are *not* copyrightable in the same sense as a computer program or artistic work. - Matt signature.asc Description: Digital signature
Re: Hypothetical situation to chew on
On Tue, Jan 04, 2005 at 11:34:47PM -0800, Josh Triplett wrote: Andrew Suffield wrote: Frankly, I think we were better off in the days when copyright had to be explicitly claimed. Anybody who doesn't know enough to claim it obviously doesn't know enough to license the damn thing properly either. That would cut out a lot of the crap we see. I agree entirely. I also agree with the various proposals to revoke the copyright grant when the copyright holder ceases to care about it. Apply that to patents as well, and you've got my vote. If it's going to be Intellectual Property (hack, spit!) then it should be treated like property -- if you don't maintain it, then squatters can take it and you have no rights to it any more. - Matt signature.asc Description: Digital signature
Re: Is the xdebug's non-free license necessary?
On Tue, Dec 21, 2004 at 11:10:11AM +0100, M?ns Rullg?rd wrote: Derick Rethans [EMAIL PROTECTED] writes: On Mon, 20 Dec 2004, Josh Triplett wrote: This is much broader. For example, I cannot write a derivative called Brian's Xdebug or Xdebug manual or even A third-party manual for Xdebug. The manual is no problem, that's not a derived product. It could very well be a derivative; a manual might want to copy some of the code for illustrative purposes, or copy various comments. IMO just copying a tiny bit of code or copying various comments does not make something a derivate. I mean, com'on, other people can come up with those same comments or tiny bits of code. This seems to me to be no different from citing a paragraph from a book, which is perfectly legal under normal copyright law. There is no such thing as normal copyright law. Not all jurisdictions out there have any concept of what is known commonly as fair use, which is the only thing I can think of that would allow you to quote a paragraph from a copyrighted book without the copyright holder's permission. If a code fragment is used in another program, matters might be different, though. Why? - Matt signature.asc Description: Digital signature
Re: Is the xdebug's non-free license necessary?
On Mon, Dec 20, 2004 at 08:34:49PM -0500, Glenn Maynard wrote: Find something that allows me to exclude people from using Xdebug+ or RealXdebug for names of derived products. That is exactly what I mean with this clause. I don't see why this should render something non-free. The source is free as you can get, I just do not want any confusion that people might get if somebody makes a derived product and calls it Xdebug+, as I as original author, will get silly support questions about it. [snip] In the general case, I think this type of clause is sticky. It doesn't seem free that my (hypothetical) game, Apache Combat, couldn't reuse code from Apache[1]. Xdebug doesn't seem as bad, but it feels wrong to be determining freeness of the clause based on whether the word being prohibited is a dictionary word or not. What's worse, this licence can't stop me from writing my own (non-Xdebug-derived) project, even closely modelled on Xdebug, and calling it RealXDebug or XDebug++ or something that *is* confusingly similar. If you really want to avoid people jumping on your good name, use the proper means for doing so -- trademark it. Using the copyright licence to try and do trademark-like things has the following effects: 1) It stops people from doing things they really should be allowed to do in a Free licence, such as take over the project if you totally give up on it (or take the metaphorical bus betwixt the eyes); 2) It doesn't stop people from doing what you *really* want to stop them from doing -- creating a confusingly similar makr of trade; 3) Irritates people who think copyright is for controlling the rights to copy a work, and trademark is for protecting marks of trade. As long as there are no strange patches that removes or adds functionality (something that I feel distributions should NEVER do), there should not be a problem as you're only delivering a 'pure' Xdebug to users. I don't know what derived product means. Most packages are probably derived works, which has a very specific legal meaning, but I don't know if derived product means derived work. I read them as being the same. And I also believe (although this is probably less agreeable) that a package of a program is a derived work, and not the work itself, because there are added / modified elements in there, and (at the very least) creative input has been involved in those additional elements. And it's very common for the Debian maintainer to apply at least some form of patch to the package somewhere along the line. Some packages are patched to hell and beyond because upstream is either dead, non-responsive, very non-patching, or just wants to take the program somewhere other than where Debian users want it to be. Prohibition on doing so is prohibition to fork, something that Free Software / Open Source people really don't like. If it needs a name change, so be it. We'll change the name. - Matt signature.asc Description: Digital signature
Re: LCC and blobs
On Fri, Dec 17, 2004 at 09:53:51AM +0100, Peter Van Eynde wrote: I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? And you restrictions that any package that depends on non-DFSG software to work cannot be in main means that after releasing sarge we have to remove from main: [Several rather absurd overgeneralisations] Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. - Matt signature.asc Description: Digital signature
Re: LCC and blobs
On Fri, Dec 17, 2004 at 10:45:07AM +0100, Peter Van Eynde wrote: Matthew Palmer wrote: Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. Ok. I'm game. Why? Where is the error my in applying your rules? Primary purpose, for a start. Perl can't go in main because it's useless without some non-free, perl-using app is ridiculous. - Matt signature.asc Description: Digital signature
Re: GPL on rendered images
On Mon, Dec 13, 2004 at 05:51:48PM +0100, Ingo Ruhnke wrote: There is also the throuble with textures from texture-cd-collection or from the web that are only allowed to be redistributed in their rendered form, ie. redistributing the rendered image under any license I am free to do, redistributing the plain texture itself that was used in that image I am however not to do. What do to there? Not use the image at all or just leave out the texture or only include the final rendered image? This is equivalent to having source code or an intermediate binary object (say a .o file) which states that it cannot be distributed separately but must be distributed linked into an executable. Not GPL compatible (nor even particularly Free, IMO). Another throublesome point would be camera position and light, say I render a sprite for a 2d game from numerous different perspective, is it ok to just ship the 3d model or do I have to include the camera positions and the positions of the light? In some cases those might of course be in the 3d model file, in others however the artists might simply add them manually on each render, so they are nowhere to be found beside in the artists head. Is the artists require to at least document the basic steps of the render process when its not fully automated via scripts? If the renderer asks for these things at each run, and the values input are critical, I would expect any sane person to put that sort of thing into a script, which would then become part of the build system, and would be shipped with the rest of the system. Otherwise, I would expect that the exact light and camera positions aren't that critical, and therefore people can change those without major harm. In that case, I don't see a major problem with someone who's building the software just plugging in random numbers... And another question, is a .psd or a 3D Max file enough? Aren't I required to include a copy of Photoshop or 3DStudio then or is it considered a part of the operating system? No, and no. Photoshop and 3DStudio form no part (unless they embed bits of themselves into the generated images, which I doubt) of the generated work, and therefore are not required to be distributed under para 5, section 3 of the GPL. (Not to mention that the portion of the paragraph you appear to be referring to only applies to executable works, which the generated images are not). Last not least what if the artist wants to keep his model files private, ie. a 2d game would only need the rendered model files, but never the 3d ones in case the 2d images are fine. Is it possible to use such files at all or do I have to reject everything that comes from the artist? Last not least what if the programmer wants to keep his source code private. C'mon, that's a no-brainer. Overall I find the GPL quite throublesome and what to include isn't really clear at all, shiping the 3d models is of course a nice gesture and a usefull thing anyway, but I don't think its much more then that and if it really does fullfill the requirements of the GPL is kind of None of the examples you gave are particularly troublesome under the GPL. Do you have some troublesome examples we can examine? - Matt signature.asc Description: Digital signature
Re: copyright on binary packages
On Tue, Oct 12, 2004 at 06:40:38PM +0900, Olaf Meeuwissen wrote: I've been pestered by the people who pay for the development of several of our packages to add a blurb claiming copyright on the *binary* packages we build and distribute. Binary packages built and distributed by others are not to be covered by this copyright claim. Now this strikes my as pretty off-the-wall and impractical, but I am wondering whether anyone knows of prior art in this area. If I think it goes beyond impractical -- I believe it's not legally enforceable. The transformation from source to binary form does not contain any elements of creative input; the process itself is trivially reproducable, and with the same set of inputs you will produce identical output every time. I'd be interested in what purpose they're trying to serve by claiming copyright protection over the compiled form, especially when they're not trying to claim protection over builds produced by others. Could a trademark do what they're trying to achieve? you can come up with good reasons NOT to include such a copyright notice, by all means let me know because I would be much happier without yet another licence/copyright wart on our packages. Because it's bloody ridiculous? Unfortunately, that doesn't appear to be a persuasive argument in the corporate world these days. # I've got to convince proprietary software licence/copyright law # veterans that have not the foggiest idea about FLOSS, it seems. Of course. You don't have to convince the ones that *do* have the idea already... - Matt signature.asc Description: Digital signature
Re: copyright on binary packages
On Tue, Oct 12, 2004 at 01:05:29PM -0400, Brian Thomas Sniffen wrote: Matthew Palmer [EMAIL PROTECTED] writes: On Tue, Oct 12, 2004 at 06:40:38PM +0900, Olaf Meeuwissen wrote: I've been pestered by the people who pay for the development of several of our packages to add a blurb claiming copyright on the *binary* packages we build and distribute. Binary packages built and distributed by others are not to be covered by this copyright claim. Now this strikes my as pretty off-the-wall and impractical, but I am wondering whether anyone knows of prior art in this area. If I think it goes beyond impractical -- I believe it's not legally enforceable. The transformation from source to binary form does not contain any elements of creative input; the process itself is trivially reproducable, and with the same set of inputs you will produce identical output every time. But the copyright is still held by the author of the source. Indeed. But that's not the issue at hand. Additionally, a repository of packages, with particular selections of quality software, is copyrightable in the same way that an anthology or magazine is copyrightable. Again, not what is being discussed. The creation of an anthology or collection involves creative input; two people, faced with the same possibles set, and even the same criteria for selection, will quite possibly choose differently. The same does not apply to the compilation of a piece of software, unless the build process is horribly fucked up. - Matt signature.asc Description: Digital signature
Re: MTL license
On Tue, Sep 14, 2004 at 12:20:08AM -0400, Brian M Hunt wrote: On September 13, 2004 11:28 pm, Anthony DeRobertis wrote: You can sue Microsoft in any state in the Union, and probably most countries in the world, without this clause, too. That's because Microsoft no doubt does business in your state or country. This is probably tangential, but it may be noteworthy. It depends in part on why you are suing them, in some jurisdictions anyway, it seems. According to the interpretation of an MSN click-through (I Agree) EULA by Canadian courts in Rudder v. Microsoft Corp (1999), you are bound to the aggrement stating that disputes may only be settled in King County in the State of Washington. I believe in Caspi v. The Microsoft Network, L.L.C. (1999) upheld the same clause in New Jersy. These seem intrinsically tied to the licensing of some software with an appropriate EULA. They may prevent you from suing the licensor cost effectively or in a suitable court of law (think selecting countries who have This can only possibly hold if you have previously legally agreed to the EULA involved. If, for instance, MS were to snaffle some of my software and use it in a product of theirs, unless I've agreed to the EULA covering *that* software, they have no grounds to claim that I have agreed to sue them in Seattle or wherever they've specified. - Matt signature.asc Description: Digital signature
Re: Problem with licence of Portaudio
On Tue, Sep 07, 2004 at 01:45:25AM +0200, Mikael Magnusson wrote: Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version. This clause doesn't appear to cause any major problems -- it's a request, not a demand, and therefore I don't *have* to follow it. The original developer wouldn't necessarily even be willing to incorporate my changes, as they might be under a more restrictive licence than he'd want to deal with. Absent any evidence that the copyright holder is a frothing lunatic, with a differing interpretation than naturally follows, I don't think there's any problem with this clause. - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:30:13PM +0200, Sven Luther wrote: On Thu, Aug 19, 2004 at 08:19:19AM -0400, Joe Moore wrote: That certainly makes the QPL more attractive to me, as a non-original-author. But I'm afraid I don't understand why any original author would use it. Indeed, so by arguing that way, we could bring this clause to be modified by the upstream author, could we not ? You think that taking the concerns of debian-legal to OCaml upstream would cause you to lose credibility with them, but tricking them into changing the licence by saying the licence means something that it doesn't wouldn't lose you any credibility? - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: Brian Thomas Sniffen wrote: Josh Triplett [EMAIL PROTECTED] writes: Consider for a moment a license that said something like You must either distribute under this license with source, or under a proprietary license without source., (where the license is otherwise BSD/MIT/X11-like, and with a definition for proprietary given somewhere in the license). This would be a form of copyleft, that requires derived works to maintain the right for _everyone_ to make proprietary derived works. I think such a license would still be Free, albeit annoying. For someone who only cares about Free Software, the additional permission is useless, and only serves to allow others to take the work proprietary. Now consider a similar license with one change: only the original developer may release under a proprietary license. Such a change reduces the number of people who can take the software proprietary. It seems like if the case above is a Free license, then this one would be as well, and would actually be preferable. This is not Free. It gives these grants: 1) Distribute with source, passing this license along. 2) or, if you're Bob, under a proprietary license without source. Now I have only one grant of permission. I have to pass along 2, but I don't get to take advantage of it at all. I don't see how this makes it non-free. You are distributing under the same license you received the software under, so DFSG 3 is satisfied, and you are not being discriminated against, since everyone has a Free license, so DFSG 6 and 7 are satisfied. (Note that saying everyone doesn't have a Free license because of discrimination would be begging the question, so you still need a non-DFSG6/7 justification for non-freeness before you can argue DFSG6/7 on this basis). Is there some DFSG #5. Discrimination against a person or groups of persons. In this case, the group that contains !(initial developer). A common definition of discrimination in the sense of exclusion is that exclusion is discrimination when it makes the distinction based on an intrinsic quality, rather than based on a choice. To take a kroogerism, if we exclude because someone is a White Christian Male, that's discrimination, but if we exclude that same person because they're being an idiot, that's OK. In the QPL's case, the licence discriminates against a large class of people because they are not the initial developer, an intrinsic characteristic which the persons that are part of that group can do nothing to change. The GPL, in contrast, does not *discriminate*, because it does not grant or revoke based on intrinsic characteristics, but rather by the choices that individual licensees may make. - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: I don't see how this makes it non-free. You are distributing under the same license you received the software under, so DFSG 3 is satisfied, But you're not. The license permissions you received don't permit using the code under a completely difference license; for example, you can't link the code with GPL work, since the licenses are incompatible. However, you have to distribute your modifications under terms that *do* allow the original programmer to do so. The license terms you're forced to release modifications under are different from the ones you received. But if upstreqm incorporqtes your changes, thus creating a modification of your QPLed work, you have the same right as he has, don't you ? I really wish you'd stop pushing this barrel, because I have to keep swatting it down. The initial developer does not have to abide by the terms of the QPL with regard to your changes, because he received an all-permissive licence to them. - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: I don't see how this makes it non-free. You are distributing under the same license you received the software under, so DFSG 3 is satisfied, On Thu, Aug 19, 2004 at 04:54:03PM +1000, Matthew Palmer wrote: DFSG #5. Discrimination against a person or groups of persons. In this case, the group that contains !(initial developer). A common definition of discrimination in the sense of exclusion is that exclusion is discrimination when it makes the distinction based on an intrinsic quality, rather than based on a choice. To take a kroogerism, if we exclude because someone is a White Christian Male, that's discrimination, but if we exclude that same person because they're being an idiot, that's OK. The question here: is it free for a license to offer free terms to everyone, and extra permissions to another group of people (eg. the original author)? Yes. If not, for example, this would seem to imply that software under the GPL with a special exception releasing John Smith from the requirement to release source would fail. I think that's clearly silly, because the same effect can be achieved by giving that individual a separate license. Additional licenses being granted only to certain people, independently from the one Debian sees, never make software less free. So, it would seem silly to reject a single license that combines the effect of this licensing arrangement into one license, even if using two licenses would be cleaner. The effect is different. For a copyleft, incorporating group X gets extra rights into the licence under which the work is distributed means that any changes I make have to also be under that discriminatory licence -- that is, the licence that Debian uses is discriminatory. Having two separate licence grants to two separate groups is not a problem, because the licence that Debian receives is not discriminatory. What other people get with the work is not our concern. What the licence forces everyone to do is a problem. Similarly, an effect roughly like the QPL's could be achieved by dual- licensing: one license that says all modifications must be available under a permissive license, and another that says all modifications must be available to the original author under a permissive license. The first license doesn't fail DFSG#5[1]. Even if the second license does, we'd still allow the first, and the second would still be available. This one's even better, because we can *choose* which licence to use. One or the other. The licence we use (whichever one we want) isn't discriminatory. (The first license is a sort of subset of the QPL: you can release your changes to everyone and avoid the problem.) Releasing your changes to everyone doesn't help you avoid the fact that the original author gets carte blanche to my changes, when nobody else does. Rejecting a license because it does this in a single license would be strange, if it would be allowed in dual-licensing form. Not particularly. With only a slight modification to the QPL, you can get that effect. Remove the requirement for the initial developer to re-release your changes in the QPL version, and tell me that's a free licence. And yet everyone gets free rights to the software, some people just get more free rights. Because the QPL is a copyleft, that's a real problematic clause, because I can't licence my changes separately. - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: On Thu, Aug 19, 2004 at 04:56:02AM -0400, Glenn Maynard wrote: On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: But if upstreqm incorporqtes your changes, thus creating a modification of your QPLed work, you have the same right as he has, don't you ? I believe this extra permission violates DFSG#3. I can't release my changes under the terms I received; I have to make a special additional license grant, granting the original author permissions to my work that he explicitly denied me to his. I am not 100 % convinced of this being the case, but even if it where, sure, there is a disymetry here, but then there is a disymetry anyway, since upstream wrote most of the code, and you only provide a small patch, and use it. Now, you may claim that the patch may be more significant than the original code, or equaly so. But then, in this case, it would be argued which of those correspond to a derived work of the other. My position is that each one is a I think it'd be pretty clear which was which. Your work was developed as a result of what was already provided under the QPL. The work resulting from the combination of the original software and your patch is a derived work of both, but thankfully the initial developer isn't bound by the terms of the QPL because he got an all-permissions, so you've got bupkis. Similarly, any modifications that the original author does to your work don't fall under the modified versions rule, because the initial developer didn't need to accept the QPL to modify your work. derived work of the other, each being QPLed, and so each get the same licence and the same benefit, in particular your right to claim upstream's code is a derived work of your own stuff, and can thus be incorportated in your own code base, provided upstream incorporate your work. The QPL doesn't talk of derived works as such[1], merely modified versions of the original software. Your modification, though it may constitute 90% of the resulting codebase, is still a modified version of a QPL'd work. (In that case, you'd be nuts not to just rewrite the other 10% and freely licence it, but we'll leave that alone for now). All modifications of a QPL'd work have to follow the guidelines in 3b. - Matt [1] There is no matches on 'deriv' (hence catching derivative and derived) in the licence at http://www.trolltech.com/licenses/qpl.html, nor, before you bring it up, in the annotations linked from that page. signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 02:45:11PM +0200, Sven Luther wrote: On Thu, Aug 19, 2004 at 09:56:45PM +1000, Matthew Palmer wrote: On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: Now, you may claim that the patch may be more significant than the original code, or equaly so. But then, in this case, it would be argued which of those correspond to a derived work of the other. My position is that each one is a I think it'd be pretty clear which was which. Your work was developed as a result of what was already provided under the QPL. The work resulting from It is not always that clear, imagine two works, A and B, which can integrate well enough, but each one could be a patch of the other, or vice versa. Nope, I'm having a great deal of trouble imagining two independently developed works each of which could be a patch to the other. Note that libraries linking to each other don't apply, as they're not modifying each other. I really cannot think of how two works, each of which is a modification of the other, could ever come to be, short of time travel or some such. the combination of the original software and your patch is a derived work of both, but thankfully the initial developer isn't bound by the terms of the QPL because he got an all-permissions, so you've got bupkis. Similarly, any modifications that the original author does to your work don't fall under the modified versions rule, because the initial developer didn't need to accept the QPL to modify your work. So what ? It is just a patch, no interaction with the original software at all, unless it is compiled that is. Now, if you consider those patch as only small piece of modification from the original software, like, err, the patches they are, then it is only fair to notice that there is some disymetry of importance between the huge work having gone in the original software, and the smallish patch you have sent upstream, and thus it is no wonder that you find this same disymetry in the licence and attached rights too. You didn't do much, so you don't deserve freedom. You're only users, you don't deserve source. derived work of the other, each being QPLed, and so each get the same licence and the same benefit, in particular your right to claim upstream's code is a derived work of your own stuff, and can thus be incorportated in your own code base, provided upstream incorporate your work. The QPL doesn't talk of derived works as such[1], merely modified versions of the original software. Your modification, though it may constitute 90% of the resulting codebase, is still a modified version of a QPL'd work. (In Well, i have somehow the feeling that this would be something you could go to court and argue over. I wouldn't like to. We generally accept that there are two ways to create a derived work, linking and modification. Each is dealt with separately in the QPL. I doubt you'd have an easy time convincing a judge that the licence authors really had no idea what they were doing, and mistook modified as derived. that case, you'd be nuts not to just rewrite the other 10% and freely licence it, but we'll leave that alone for now). All modifications of a QPL'd work have to follow the guidelines in 3b. But still, the copyright of your patch or modification remains with you, altough upstream has the right to integrate it, and all persons further patching it are thus obliged to give you the same right you give upstream, so ... The upstream author still doesn't have to abide by the same terms I had to. All I can do is take modifications to my patch and do whatever I like to them. Whoop-dee-doo! I still have an asymmetric relationship with upstream. - Matt signature.asc Description: Digital signature
Re: Web application licenses
On Thu, Aug 12, 2004 at 10:34:27PM -0700, Josh Triplett wrote: However, you didn't respond to the fact that you are allowed to recoup your costs; does that affect your argument that a requirement to distribute source is excessively burdensome? There's a fair cost involved in just keeping the source around; if I made a quick mod to the software and rebuilt, I don't necessarily want to have the whole source distribution (think kernel or X) hanging around clogging up my hard drive. I can only recoup the cost if someone requests a copy, otherwise it's a sunk cost; but I have to keep the source around just in case. Unless the original licensors are willing to cover that cost for me? No? I didn't think so. In that case I'm out the money. Probably not a lot of money (unless I had to buy a new HDD or tape drive because all these copies of huge source tarballs filled up my available space). - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 12, 2004 at 02:50:25PM +0200, Sven Luther wrote: On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. As long as it's source-only distribution. That's OK. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. Binary distribution forces you to release your modifications under the QPL. By the terms of that licence, however, by virtue of the fact that your patch is a modification, the initial developer gets an all-permissive licence *in* *addition* to the permissions granted to him/her and the rest of the world by the QPL. While the wording is a bit roundabout, and you need to take different bits of the licence together to get the whole picture, the end result is that source-only distribution *can* be free of extended grants (or not, if you choose to licence your modification under the QPL), but binary distribution results in an extra permission grant to the initial developer. Which is clearly *not* the same licence as the initial developer has given you. - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 12, 2004 at 09:31:58AM -0400, Brian Thomas Sniffen wrote: Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. No, I'm not talking about the copyleft in QPL4. I'm talking about QPL 3b, and its compelled grant of a more permissive license to the initial developer than I received from him. I can't give him my modifications under the same license under which I received the work from him. No, you can place your (source-only) modifications under any licence you like. This isn't immediately obvious from the licence, but there is no notification that you must licence your (source) patch under the QPL in section 3 at all, but there is a note that *if* you do licence it under the QPL, the author gets carte-blanche. It would be hard to argue that the licence implies that the patch must be under the QPL, because (a) copyright law in the jurisdictions I'm aware of says nothing about reciprocity of terms of derived works, (b) section 4 explicitly states when you must licence your modifications under the QPL, so it's obvious they've thought about it, and (c) 3b says When modifications to the Software are released under this license, which strongly implies to me that you have a choice as to whether or not to place your modifications under the QPL (unless compelled by section 4). This does raise an interesting point, though -- if the Debian maintainer accepts a patch from someone for a QPL'd work, but does not seek licence clarification, that would make the patched version undistributable -- because the maintainer doesn't have the authority to relicence the patch, but is unable to provide the patch under the QPL, and binary distribution is taking place. Methinks a quick licence audit of QPL-only packages is called for. - Matt signature.asc Description: Digital signature
Re: Difficult open source question
[Sorry for the Cc if you're subscribed] On Fri, Aug 13, 2004 at 12:13:13AM +0100, Robert Gibson wrote: I have a difficult query about open source, which I hope someone here can help with. My friend Gordon was very close to having a working Flash 7 player called magnesium that runs under Linux, and wanted to release it as open source. He passed away last month, and his friends want to do something with this software in his memory. His computers were passed on to me, and I have the program at my house. I can't see any copyrights anywhere, so: is it okay if we release it as open source, and what should we do? The copyright that exists in the program that your friend wrote is a thing of value, to be apportioned in the same manner as the rest of his estate. It is certainly *not* OK just to release it as open source, because absent an explicit notice to the contrary, all software has copyright over it, with all the same restrictions as any other work (no unauthorized duplication, etc etc). The most prudent course of action would be to declare the held copyright to the executor of Gordon's estate and have it distributed according to Gordon's wishes (in the case of the existence of a valid will) or according to the laws of probate in your (Gordon's(?)) jurisdiction. Hopefully someone who was aware of (or could be made aware of) Gordon's interest in seeing the program released as open source will receive the copyrights; they can then release the work under a Free licence. All of the above presumes that you have a copyright term that includes a term in excess of the life of the author, such as the US' life+70 years. There are some jurisdictions where copyright is terminated when the author passes away. It may be worth investing in an hour or two of a landshark's time to make sure everything is hunky-dory in your corner of the world. (The above is not legal advice, I am not a lawyer nor do I play one on TV, and all of the rest of the usual disclaimers) - Matt signature.asc Description: Digital signature
Re: ocaml, QPL and the DFSG: New ocaml licence proposal.
On Tue, Aug 03, 2004 at 09:05:56AM +0200, Sven Luther wrote: On Mon, Aug 02, 2004 at 11:38:58PM +0200, Francesco Poli wrote: On Mon, 2 Aug 2004 09:23:11 +0200 Sven Luther wrote: Now, what would be your ground for the original author not respecting the QPL of the patch ? I think that the initial developer does not have to comply with the QPL of the patch, because he/she already has the rights he/she needs (the right to integrate the patch in future versions of the Original Software and the right to distribute them under any other license as long as they remain available under the QPL too). He is allowed to apply its proprietary licence, as long as he also adds the patch to the QPLed version, thus allowing you the same rigths under the QPL back ? Let's look at the QPL license under which my hypothetical patch is distributed. Who is the initial developer in this instance of the QPL license? Is it me? I don't think so: I'm not the initial developer of the Software, I'm just a contributor, because I created a derived work of the Software. Hence (if it's true that I'm *not* the initial developer, not even for the QPL applied to the patch), I don't get any special right from further modifiers that must comply with the QPL: the true initial developer gets it! I don't think you can go this way, since the QPL insists on patches that are separate from the original work, then these standalone patches can as well be applied to some other software (well, there are other kind of separate distribution than just patches), and thus the upstream author has to live by the same rules when he integrates your patches, Aaah, but he doesn't, because of the permission grant you have given in 3b as a result of accepting the QPL. Regardless of any licence under which your modification may be distributed, you have given the initial developer an all-permissive licence. There's a possible loophole I've just discovered in the licence which you might want to notify upstream about if it turns out right. See the bottom for my analysis. and thus create a derived work from your patches. So Patch P is a derived work of software S, and software S' is a derived work of P? In that case, would there be reason to presume that the author patch P is an Initial Developer of S', and hence has all of the same rights as the Initial Developers of S? That would result, after several iterations of patch application, in software S', which would have many Initial Developers, all of whom have an all-permissive licence to changes to software S'. Earlier you said that keeping track of which submitted changes have permission grants or copyright assignments would be a problem. Do you believe it would be any less onerous to keep track of who qualifies as an initial developer for the purposes of determining who has preferential rights to modifications to an arbitrary version of the software? This becomes a larger problem when considering that a patch will likely apply cleanly to several versions of the software. If a patch Q is developed against version S'' but applies cleanly to S''', it would likely be very difficult to determine whether I, as an initial developer of S''' but not of S'', have preferential rights to Q, without a lot of detail into the development process of Q. Trying to track all of these changes suddenly makes getting permission grants for contributions downright simple... But I'm not allowed to, because the QPL forces me to grant additional permissions to the initial developer. But by integrating the patch, he gives you the same kind of rights, so ... So there is now an ever-widening set of people who can create proprietary works. Cool. You've also effectively argued that the patch clause in the QPL is totally non-effectual as soon as I get upstream to include a patch of mine, because I have an all-permissive grant to the changes to my patch (which you appear to indicate is the entireity of the original software, once my change has been integrated) thus I can distribute however I like, with whatever other patches I like. Methinks you might not want to be pushing that argument. As to the loophole: 3b says When modifications to the Software *are released under this license*, a non-exclusive royalty-free right is granted to the initial developer (emphasis mine). So if the changes are released under a different licence, upstream is screwed -- especially if it's a QPL-incompatible licence (such as the GPL). The only circumstance I can find where a change must be released under the QPL is when binary distribution takes place. If I only distribute my patch, upstream has no special right to my code. Considering that you have said that upstream really, really wants to be able to sell my changes, I think this clause might want to be reviewed to see if it really does what upstream wants it to do, because as it stands, unless I distribute my changes
Re: ocaml, QPL and the DFSG: New ocaml licence proposal.
On Sat, Jul 31, 2004 at 11:17:47AM +0200, Sven Luther wrote: On Sat, Jul 31, 2004 at 10:01:42AM +1000, Matthew Palmer wrote: On Fri, Jul 30, 2004 at 02:31:27PM +0200, Sven Luther wrote: On Fri, Jul 30, 2004 at 07:53:42AM -0400, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: On Thu, Jul 29, 2004 at 05:53:14AM -0400, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: So this solves most of the issues, and we need to go through the QPL 3b again, but upstream feels it is a reasonable clause, and would like to keep it. I'm sure that anyone would love to have that kind of term in a license. It still feels non-free to me. Sure, but there is much less consensus about this one, so if a handfull of people feel it is non-free, i doubt it will come into play. I would consider it a fee. It is even enshrined in US copyright law [1] The term financial gain includes receipt, or expectation of receipt, of anything of value, including the receipt of other copyrighted works. Ok, well. But we need to consider non-US law also. Let's, then. What does French copyright law define as a fee or financial gain? Thanks for that great answer there, Sven. Since all copyrights flow to the originator, I can't help but see it as a fee for making modifications. Well, even if we see it as such, do we really want to declare this clause as non-free ? After all it will simplify the administrative tasks involved in havign upstream integrate changes back, and in general will be a win for free software. It's not exactly rocket science to add a some modifications (C) Foo Wombat to each file touched by a patch submitted by Foo Wombat. With a decent revision control system it's even straightforward to identify when those changes get written back out again so you can remove the (C) notice. What you're talking about, I believe, is simplifying the ability of upstream to release proprietary versions of the software, requiring no explicit copyright assignment or permission grant. That is a little more difficult to judge as a win for free software, except in the sense that upstream gets money to continue to develop free software. And yet there are no shortage of Free Software projects that have thrived without this clause. Well, no, you cannot remove the existing copyright statement. Still the clause 3 deals with patches, and you can add your own copyright statement. I understand there are the following issues at hand here : A) people need to be able to add themselves to the copyright of files they touch. B) people need to be able to translate copyright statement that appear in the about box of an interactive program. C) if a whole file is removed, then it should be ok to remove the copyright statement attached to it. And that's the extent of it. Since we cannot modify the QPL anyway, would it be enough to add an additional ecemption, or maybe simply an upstream annotation saying that those are explicitly allowed ? I failed to write some nice and concise wording eplaining the above. Along with the ability to remove copyright statements if they are no longer relevant (such as converting the above-mentioned About-box-enabled GUI program into a console-based program, or even better, a non-interactive program), and other such things. That's why a list of you can do these things rarely suffices -- it doesn't take into account anything that the licence author didn't think of. Keeping it general is much better for everyone. Notice that the non-freeness involved here, is about the freedom to not contribute back your changes, is this really something we want to defent ? Yes. Otherwise we end up with licence clauses requiring that all software you write must be freely licenced and publically distributed as a condition of some piece of software. Not contributing your changes upstream is And we would accept those as free. You're joking, right? You would be happy agreeing to a licence which forced you to place *everything* you write under a Free licence? something you want to protect just as much as your right to not distribute a work under a Free licence in the first place. That you want to protect, i have no such interest, and i believe many in the debian project would feel the same. I'm happy to put that one to a GR. It would completely screw anyone who ever writes anything they may not want to share with others. It also stuffs anyone who has to agree to a we own everything you do employment clause. Note that this statement shall not be construed in a way as to discourage copyleft. That is a notice from the original copyright holder saying if you want to distribute bits of my work, you have to do equivalent things to your work. Compelling even *submission
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
On Fri, Jul 30, 2004 at 04:28:41AM -0500, David Nusinow wrote: On Wed, Jul 28, 2004 at 09:57:53AM +0100, MJ Ray wrote: On 2004-07-28 03:35:31 +0100 David Nusinow [EMAIL PROTECTED] wrote: 1) MJ Ray has suggested doing more work with people in the NM queue. [...] As should be obvious, I don't understand the NM black box. How would we do this? One thing is to modify the standard templates used for questions. Include more licenses to critique, all of which are picked to display certain points. I don't know that many licenses so I can't suggest any in particular right now, but a more focused portion of Policy Procedures would be good. As it is, I see the Policy Procedures overlapping quite a bit with Tasks Skills as they currently stand, so some separation would provide the necessary room in the tests. Having just recently come into the world of AMship, I agree with your observation regarding the overlap of some portions of TS with PP -- some of the questions in TS should probably be in PP instead, but that won't free up space in TS for licence analysis -- that's in PP (to some degree) already. For that matter, I'm not quite sure we should necessarily be subjecting applicants to the joys of rigorous licence analysis. We have d-legal for this purpose just so maintainers don't have to be licence experts. The question about Pine licencing is a pretty good test of basic DFSG analytical ability. 2) Steve McIntyre has continually suggested codifying [...] I agree with others that this is dangerous and likely to weaken the guidelines in nearly all cases. This is going to sound really bad, and I'm not trying to stir up trouble in saying this, but perhaps the guidelines need weakening? As Matthew Garret pointed out in another email, current interpretation of freedom is more restrictive than that of the FSF, and I echo his point that this probably needs to be justified. An interesting point of view. Be prepared for some brutal attacks for such a suggestion. - Matt
Re: ocaml, QPL and the DFSG: New ocaml licence proposal.
On Fri, Jul 30, 2004 at 07:48:17PM +0200, Sven Luther wrote: Moreover, we need these licenses to be recognized as open-source by Debian and other authorities before even considering to use them. The problem you are going to end up with for this, though, is that there is no authoritative English version of the licences. The translation of the CECILL licence we've seen so far was non-authoritative, and hence no actual decision can be made about it's freeness. Most of the organisations you're going to want to get recognition from are primarily English-speaking organisations. You might be able to get FSF-Europe to give the OK for the FSF, if they've got good French-speaking licence analysers, and if OSI's licence vetting process is what I've heard it is (trusting the drafting lawyer's assertion that it's OK) you might be OK there, but I doubt debian-legal is going to be able to discuss a licence without an authoritative English version to work from. The other problem with only having a French licence is that anyone who can't fluently read French is going to have no idea what the terms are under which they can modify the software. That's going to mean that you'll either have a lot of potential contributors down the tubes, or a lot of people infringing your licence without knowing it. Relying on an unofficial translation of the licence isn't going to help much, either. Note that these problems do also exist for English language licences and non-English speakers, but in practical terms they are diminished because (for better or worse) most people have at least a basic knowledge of English. - Matt
Re: ocaml, QPL and the DFSG: New ocaml licence proposal.
On Fri, Jul 30, 2004 at 02:31:27PM +0200, Sven Luther wrote: On Fri, Jul 30, 2004 at 07:53:42AM -0400, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: On Thu, Jul 29, 2004 at 05:53:14AM -0400, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: So this solves most of the issues, and we need to go through the QPL 3b again, but upstream feels it is a reasonable clause, and would like to keep it. I'm sure that anyone would love to have that kind of term in a license. It still feels non-free to me. Sure, but there is much less consensus about this one, so if a handfull of people feel it is non-free, i doubt it will come into play. I would consider it a fee. It is even enshrined in US copyright law [1] The term financial gain includes receipt, or expectation of receipt, of anything of value, including the receipt of other copyrighted works. Ok, well. But we need to consider non-US law also. Let's, then. What does French copyright law define as a fee or financial gain? Since all copyrights flow to the originator, I can't help but see it as a fee for making modifications. Well, even if we see it as such, do we really want to declare this clause as non-free ? After all it will simplify the administrative tasks involved in havign upstream integrate changes back, and in general will be a win for free software. It's not exactly rocket science to add a some modifications (C) Foo Wombat to each file touched by a patch submitted by Foo Wombat. With a decent revision control system it's even straightforward to identify when those changes get written back out again so you can remove the (C) notice. What you're talking about, I believe, is simplifying the ability of upstream to release proprietary versions of the software, requiring no explicit copyright assignment or permission grant. That is a little more difficult to judge as a win for free software, except in the sense that upstream gets money to continue to develop free software. And yet there are no shortage of Free Software projects that have thrived without this clause. Notice that the non-freeness involved here, is about the freedom to not contribute back your changes, is this really something we want to defent ? Yes. Otherwise we end up with licence clauses requiring that all software you write must be freely licenced and publically distributed as a condition of some piece of software. Not contributing your changes upstream is something you want to protect just as much as your right to not distribute a work under a Free licence in the first place. Note that this statement shall not be construed in a way as to discourage copyleft. That is a notice from the original copyright holder saying if you want to distribute bits of my work, you have to do equivalent things to your work. Compelling even *submission* upstream goes further, and compelling an all-permissive licence to upstream is well beyond the simple share-alike provisions of copyleft. Also the first modification, well, i am not overly confident that it is really needed, and i am sure my wording of it are abysmal, and i ask for some help here in finding some nice and concise wording which doesn't divert to much from the original. The old wording was : a. Modifications must not alter or remove any copyright notices in the Software. And i changed it to : a. Modifications must not alter or remove any copyright notices in the Software except by adding new authors. If I'm converting an interactive program to be non-interactive, I still can't remove a hard-coded copyright string that pops up in an About box. Bah. I doubt this is what was meant here, and i doubt this is going to be a problem all over. If you don't think that is what is meant, then change the wording to say that (preferably, remove it). Otherwise it is just lawyerbait. Notice that i will have to add all this modification in a licence-patch why, saying : The software is under the QPL, except ..., so the less change is needed the less confusion it will be. I would much rather keep this one as is, and concentrate at a later time to the change to another licence altogether, maybe one of the upcoming CECILL family. Now, if you could propose a sane and not too involved wording for the above, i and upstream would consider this. It should not exceed a few (preferably two) lines though. Here's a nice short one: Copyright law has naty things to say about people who file off copyright notices. No need to go restating them, especially in a manner which restricts modifications unnecessarily. If you *really* *must* have the clause, how about: Modifications must retain the effect of existing notices of copyright interest in the software. That way copyright notices can be moved, translated, and whatever else
Re: RPSL and DFSG-compliance - choice of venue
On Tue, Jul 27, 2004 at 09:55:10PM -0500, David Nusinow wrote: On Wed, Jul 28, 2004 at 12:43:31PM +1000, Matthew Palmer wrote: On Tue, Jul 27, 2004 at 09:35:31PM -0500, David Nusinow wrote: DFSG. I fully agree with this. If you really truly believe that your interpretations are shared by the rest of the project, then you have nothing to fear from this, and you only stand to gain. We fear that as soon as we special-case something in the DFSG it will be used as a fulcrum for splitting hairs even finer. Our special case isn't banned by the DFSG, but these other ones are, so obviously the DFSG was intended to be proscriptive, therefore our special case is free and our gratuitously non-free licence should be permitted. AKA The DFSG Arms Race. We keep throwing GRs around every couple of months to say this sucks, and then someone who wants to play word games comes up with another truly non-free licence clause which isn't covered by one of the special cases in the DFSG. This is true, but when the same basic ideas come up repeatedly, such as the choice of venue clause, they're probably worth codifying, since they're no longer special case. They're still special case in that they're intended to disallow one specific thing -- in this instance, choice of venue clauses. If we write a DFSG clause which states choice of venue clauses are non-free, then we will likely have someone say arbitrary termination clauses are OK because there's no specific DFSG point to cover them, and you singled out choice of venue clauses, so therefore you must be in the habit of listing problematic clauses like that. If we write the amendment as something like A licence must not place undue cost or inconvenience on a licensee in order to comply with the licence it's much broader and covers choice of venue as one of it's effects. It also covers any other instance where the license can make it prohibitively expensive to actually take advantage of the freedoms granted. DFSG #1 is interpreted in such a way as to be our defence against that, but it's not intuitive. Unfortunately it has potential side-effects and doesn't necessarily make it clear enough that that's what's being prohibited. For instance, undue cost could be argued to not apply for choice of venue because the cost involved is not undue. On the other hand, compelled distribution of source (GPL) could be seen as an undue cost. It's a very difficult line to get right. Whatever we put in writing can be attacked by those who want to either (a) get their pet piece of non-free software in, or (b) discredit the DFSG and debian-legal by attempting to show that it/we are trying to get rid of every licence except public domain... It's these sorts of potential problems, IMO, which have stifled DFSG amendments. We don't want to fuck up the DFSG with a bad amendment. It's much easier to go with tests and interpretations of the DFSG which prohibit such things implicitly, rather than documenting what we mean and coming up with something that we have to be bound to. - Matt
Re: Termination clauses, was: Choice of venue
On Sun, Jul 25, 2004 at 10:46:32PM -0400, Brian Thomas Sniffen wrote: I don't think you mean derivative in the same way the USC 17 means derivative, and I *really* don't think you mean it in the same way Berne does. The idea that influence grants copyright is not common -- indeed, it's not in any legal system I know of. That would mean that everybody who decided to write a magic-school book after reading Harry Potter would be infringing Rowling's copyright. There are issues there with similarity rip-offs and so forth, but I can't recall if they get litigated as copyright infringement or something else (see the Barry Trotter books for examples, to continue the theme -- Barry Trotter and the Shameless Parody is supposedly very funny). What changes the playing field a bit, too, is that typically the only part of the copyrighted library that you see is the API and documentation, and (from memory) APIs aren't copyrightable. However, that may be irrelevant because you're not attempting to reproduce the library, but rather to extend it by building an application or other library on top of it. But if you stick to the published API, that's really use of the work in the manner it was intended to be used. It's all a very grey area of law, and unlike a lot of other things we debate, I can't think of any case that has been heard on the subject of libraries and derivative works. Most seriously, of course, your scheme is not time-invariant. It *was* a derivative, but it isn't now, is not something we should ever be hearing. Agreed. Or even the other way around. Imagine if you coded against OpenSSL, and you use that subset of functionality that is implemented by the GNUTLS compatibility layer. Suddenly your program is a derived work of GNUTLS... - Matt
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 09:11:05PM -0700, Josh Triplett wrote: Matthew Palmer wrote: On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: On Sat, Jul 24, 2004 at 03:27:26PM -0400, Michael Poole wrote: Sven Luther writes: Each time i make a new upload, a notice of the upload is sent to the US security agencies, at least this is how i understood it. This include my changelog entry, my name and email, my GPG key, and the time at which i make this upload. In other words, they are effectively subscribed to the debian-*-changes mailing lists? I still don't see how that is any kind of privacy concern like you claimed. I am against it in principle. Having them subscribe to the debian-*-changes mailing list is an active effort of their part, while we willingly push data to them. So you're now not OK with the QPL's requirement that we push data to the initial developer of a QPL'd work, I take it, since you're against Debian pushing data to the US government? Technically, the QPL just requires you to provide changes on request, not push them to the original developer. That doesn't make it any less non-free, but the two situations you mentioned are distinct. Well, the US government has requested that data. If the licence said you must push a copy of changes at the time of first distribution of those changes, it'd be exactly the same. As it is, it's equivalent to the upstream author saying I'll have those changes as soon as you distributed them to another party. In a way, it's better that we push at modification time, because we know we have no further obligations and can completely forget about needing to keep them after that. The QPL requires long-term storage. - Matt
Re: The Sv*n L*th*r drinking game
On Sun, Jul 25, 2004 at 09:35:55AM +0200, Sven Luther wrote: On Sat, Jul 24, 2004 at 06:34:24PM -0400, Glenn Maynard wrote: On Sat, Jul 24, 2004 at 02:57:54PM -0400, [EMAIL PROTECTED] wrote: Sven's messages are constantly and deliberately laced with derision and insults--in almost *every* message he posts. Perhaps returning it with So, please show me the derision and insults in the serious thread i started later ? Too late for some people. And do you not think that making half-backed assertion is not an insult to the inteligence of both the contributors here, and the upstream author whose licence you are discussing. You say that so often, but I'm having trouble coming up with instances in which you have shown how, precisely, the arguments raised are half-baked. There's no shortage of instances of you saying that arguments are bogus (or worse), but reasoned rebuttals aren't exactly universal. and less derisive and condescending than Sven's behavior towards all of us. Well, if your argumentation has been upto it, maybe i wouldn't have needed to be so condescending, but this was clearly not the case. Perhaps you could enlighten us with your obvious wisdom and show us how our argumentation could be improved, rather than simply calling us ignorant? You know, showing benevolence to the little people and all that. You know debian-legal has some extreme power in debian, power only matched by the RM and the ftp-masters, since concensus here will mean almost-automatic removal of a package from the archive without much way to change it. With this Bullshit. No debian-legal regular (AFAIK) has power to remove stuff from the archive, so we're down to making a summary and petitioning ftpmasters with that. If our arguments are thoroughly unconvincing, then the summary will be laughed at and discarded. And you don't think that my behavior was a direct consequence of the way debian-legal operate, and the sub-par decision process you have here ? Cool. Blaming us for being abused. Thanks. - Matt
Re: The Sv*n L*th*r drinking game
On Sun, Jul 25, 2004 at 09:52:43AM +0200, Sven Luther wrote: On Sun, Jul 25, 2004 at 12:23:35PM +1000, Matthew Palmer wrote: On Sat, Jul 24, 2004 at 02:57:54PM -0400, [EMAIL PROTECTED] wrote: Matthew Palmer [EMAIL PROTECTED] wrote: On Fri, Jul 23, 2004 at 04:37:49PM +0200, Sven Luther wrote: intention would clearly be to dealy the issue until everyone who opposes you has left in disgust, and you can claim consensus. *You've* driven three people out of this discussion with your personal abuse against them. Who is exactly is trying to berate the opposition into silence and then claim they hold the consensus opinion, exactly? Actually, the process Sven describes here seems to be happening. Some people on the list abuse the other participants until they leave, and then claim consensus afterwards. They may just as well procede to say that whoever left is an unclued idiot, because they are not around to defend themselvees anyway. Yeah, I reckon: Please don't bother writing to me again. Your previous posts have made it clear that you don't even bother reading here anything apart from the posts which interests you, and that you have no problem making half backed claims based on pure speculation. (Sven Luther, http://lists.debian.org/debian-legal/2004/07/msg01122.html) And ? how is that insulting ? you don't even both reading here anything apart from the posts which interests[sic] you, half-backed claims based on pure speculation. That's not insulting? you can basically fall over them in any post made over the last few days by Sven. Well, you are only unhappy with me because i didn't leave, and dared to put a finger into the misfunction of the debian-legal decision process. Prove it. Go on. Demonstrate, to at least a reasonable degree, where my comments have indicated that I personally am unhappy with you because you're still here. What I *am* unhappy with is making an argument with you and being told that my reasoning is bogus, and being told that I've never read the licence or any of the discussion surrounding it, without *ANY* *BACKING* *WHATSOEVER* to those claims. And what really toasts my muffin is having it happen over and over again. Sven's arguments seem clear and important to me, and it behooves us to pay attention and address them. I thought that, too, for about four days, but after the approximately eighth time Sven's arguments consisted of abuse, ridicule, and nothing even vaguely resembling reason, I gave up. So, i apologize for being upset and harsh, i clearly should have not. Still, after reading mail after mail of clueless non-sense, i could sense the anger build in me, and was not able to put a stop on it while replying. Again i You can write a message, then go for a walk to calm down before editing it and sending it. Don't post angry. *Especially* when your purpose here is, ostensibly, to persuade people to your point of view. Lighting up the ol' flamethrower and lightly char-grilling the other participants doesn't help that. Well, the thread was long enough before i started to post, and what actually happens is that the debian-legal mob bands together, and bashes on the DD for not accepting their half-backed arguments inconditionally. Because Matthew Garrett has gotten exactly the same treatment as you, hasn't he? He's arguing a similar stance to you, but has always made his arguments rationally and, as such, has been well accepted and is listened to. You've taken pot-shots at nearly everyone here, and you get ridiculed. Do you see the difference? If you think Sven and I are exagerating, let me toss out a few examples from just the last couple of weeks: And the beginning of this thread gave quite a number of examples of Sven, all by himself, insulting other members of debian-legal. Sure, but if you go over them, it was a gradual process. You've been here about a week. You've been abusive for at least half of that time, from recollection. 4 days (at most) is not a lot of time to go from reasoned participant to abusive twit. Nathanael Nerode [EMAIL PROTECTED] wrote: I have argued that it may well be *good* for a license to specify choice of venue. It is a nice thing to know which laws apply to the agreement, and that's what a choice of venue clause tells you (at least, to the point anything is certain in law). Wrong wrong wrong. Please pay attention. How is it wrong, much less wrong wrong wrong, to point out a new argument? When the argument is flawed? Choice of venue does not necessarily specify the laws which will be used. Choice of law does that. But you know that. Sure, and your arguments are never flawed, but your oponents always are ? No. If I present a flawed argument that has been presented several times before I would expect to get kicked. And I've
Re: The Sv*n L*th*r drinking game
On Sat, Jul 24, 2004 at 02:57:54PM -0400, [EMAIL PROTECTED] wrote: Matthew Palmer [EMAIL PROTECTED] wrote: On Fri, Jul 23, 2004 at 04:37:49PM +0200, Sven Luther wrote: intention would clearly be to dealy the issue until everyone who opposes you has left in disgust, and you can claim consensus. *You've* driven three people out of this discussion with your personal abuse against them. Who is exactly is trying to berate the opposition into silence and then claim they hold the consensus opinion, exactly? Actually, the process Sven describes here seems to be happening. Some people on the list abuse the other participants until they leave, and then claim consensus afterwards. They may just as well procede to say that whoever left is an unclued idiot, because they are not around to defend themselvees anyway. Yeah, I reckon: Please don't bother writing to me again. Your previous posts have made it clear that you don't even bother reading here anything apart from the posts which interests you, and that you have no problem making half backed claims based on pure speculation. (Sven Luther, http://lists.debian.org/debian-legal/2004/07/msg01122.html) Brian, i ask you to not [...] to participate in this thread [...]. I will consider any conclusion you have participated in as void and not binding, as you are obviously clueless [...] (Sven Luther, http://lists.debian.org/debian-legal/2004/07/msg01203.html) I've refrained from posting further directly on the QPL issue. (Brian Thomas Sniffen, http://lists.debian.org/debian-legal/2004/07/msg01375.html) If you'd like, I'll dig up a few instances where Brian has been ridiculed after having removed himself from the thread, to back up your They may just as well procede to say that whoever left is an unclued idiot, because they are not around to defend themselvees anyway, but there's so many of them you can basically fall over them in any post made over the last few days by Sven. Sven's arguments seem clear and important to me, and it behooves us to pay attention and address them. I thought that, too, for about four days, but after the approximately eighth time Sven's arguments consisted of abuse, ridicule, and nothing even vaguely resembling reason, I gave up. can avoid it. Most especially I do not want to reach the situation where a theorist on debian-legal has found a theoretical problem that the maintainer of the package disagrees with. That's the commencement of the discussion. The theorist and the maintainer then discuss the issue to a point of agreement. Or, at least, that's what happens when the maintainer doesn't have a 100-post hissy-fit, anyway. Of course, even aside from the process question, there is an issue of proper treatment of fellow Debian developers. We are all on the same side, but some people seem to be forgetting this. Indeed. If you think Sven and I are exagerating, let me toss out a few examples from just the last couple of weeks: And the beginning of this thread gave quite a number of examples of Sven, all by himself, insulting other members of debian-legal. Nathanael Nerode [EMAIL PROTECTED] wrote: I have argued that it may well be *good* for a license to specify choice of venue. It is a nice thing to know which laws apply to the agreement, and that's what a choice of venue clause tells you (at least, to the point anything is certain in law). Wrong wrong wrong. Please pay attention. How is it wrong, much less wrong wrong wrong, to point out a new argument? When the argument is flawed? Choice of venue does not necessarily specify the laws which will be used. Choice of law does that. But you know that. And why am I supposed to pay attention here, when clearly I am pointing out something that people are overlooking? This is not the kind of treatement a fresh idea should receive. I have yet to see It's not a fresh idea. It's been dealt with before. Several times. The same points get brought up regularly, and it gets frustrating. Sven sees it and goes apeshit, and you ignore it. Someone who disagrees with you gets frustrated, and you raise it up as an example of the brutality of debian-legal. But don't take my advise, however much logic it may be based on. Namely, none. This speaks for itself. Yep. Your sentence was basically an attempt to bully everyone else from dissecting your argument by prematurely concluding the logical purity of your argument. Nathanael simply called your bluff. G. Branden Robinson wrote: I'm afraid your response was far too scholarly and informed to be taken seriously by anyone who feels that choice-of-law or -venue clauses are just fine by the DFSG. This was the entire content of one post, aside from a rot-13'd comment that this is sarcastic. This post had no purpose other than to flame someone and to rabble rouse. Further, we see here again the implicit It was a bit of a flame, but at least
Re: RPSL and DFSG-compliance
You are not required to accept this License. However, nothing else grants You permission to use, copy, modify or distribute the software or its derivative works. These actions are prohibited by law if You do not accept this License. Would it be too much to instantiate a test which states that if the licence outright lies it's not DFSG-free? I'm not aware of any jurisdiction in which copyright law prohibits use. - Matt
Re: ocaml, QPL and the DFSG: Choice of venue argumentation.
On Sat, Jul 24, 2004 at 07:58:08PM +0200, Sven Luther wrote: On Sat, Jul 24, 2004 at 09:38:44AM -0400, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: On Fri, Jul 23, 2004 at 09:11:07PM -0400, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: The cost of hiring a lawyer in france local to the Court of Versailles is probably less or similar to the cost of hirinig a lawyer of similar competence and fluent in the Laws of France, in a country local to the defendent. If I don't speak or read French (or English), it is going to be rather difficult to find a lawyer in France. Bah, you know that some french people speak english, probably a lot more of US-ihabitant who speak french, so ... My example was if you don't understand French _or_ English. Well, the only trouble would be to find a lawyer which speaks english, which i believe is not such an impossible task as you want to make us believe. It is How is an English-speaking French lawyer going to help me if I don't speak English? - Matt
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: On Sat, Jul 24, 2004 at 03:27:26PM -0400, Michael Poole wrote: Sven Luther writes: Each time i make a new upload, a notice of the upload is sent to the US security agencies, at least this is how i understood it. This include my changelog entry, my name and email, my GPG key, and the time at which i make this upload. In other words, they are effectively subscribed to the debian-*-changes mailing lists? I still don't see how that is any kind of privacy concern like you claimed. I am against it in principle. Having them subscribe to the debian-*-changes mailing list is an active effort of their part, while we willingly push data to them. So you're now not OK with the QPL's requirement that we push data to the initial developer of a QPL'd work, I take it, since you're against Debian pushing data to the US government? - Matt
Re: RE-PROPOSED: The Dictator Test
On Sat, Jul 24, 2004 at 12:57:31AM -0400, [EMAIL PROTECTED] wrote: That said, I don't think we are obligated to ship something just because it is DFSG free. For example, I don't think we should distribute massive quantities of public domain poronography. I don't think we should ship a BSD-licensed program that, when run, emails the contents of a user's hard drive to USENET, wipes the hard drive, and then blows up any connected monitor, even if the software is perfectly free in every way. More on this below. The problem is that presumably the maintainer of the package of PD pr0n wants it in Debian, or else it wouldn't have been packaged. But without a clear DFSG basis (judging by your terms), we would have no actual reason whatsoever for removing the package. How do you suggest we enforce your not useful criteria against packages if we can't even instantiate fundamental freedoms as an argument? (1) You must never say or write anything negative about the authors. The way this is phrased, it means I cannot add a comment to the software that is negative about the authors, so it would violate DFSG. If you How would this violate the DFSG? Come along, be specific. You require the same standard of others. (2) You agree never to exercise your fair use, fair dealing, or other similar rights regarding this software. This one's against DFSG. It's actually about uses of the software. Where does the DFSG say we can't make rules against use? Come on, be specific. (3) You agree not to use this program at all, in any way, without agreeing to this license. That's perfectly fine. If the terms of the agreement pass the DFSG, then there is no problem in users actually having to agree with them before they can use the software. Well, except for the fact that it's not something that copyright can regulate. (3) You agree never to sue anyone over anything. (4) You agree to allow the authors to search your home and person without notice at any time. (5) You agree to waive your right to trial by jury in all criminal or civil cases brought against you. These are DFSG-free, but clearly not something we want to distribute. Why not? You're asking us to base every real decision we make on the guidelines in the DFSG, but you are willing to make independent judgement calls. That's okay, however, because DFSG is not our only line of defense. We are not forced to distribute software even when it is DFSG free. Most blatantly, SC #4 will rule out a lot of things we might possibly distribute, because they would harm our users. And even when #4 passes, rm can harm our users, too. Presumably the software to be packaged is useful to *someone* or else it wouldn't be packaged. we can still exercise our judgement. I hereby propose the Nobody Wants It Test. :) If no user would want it if they knew what they were getting, then we do not distribute it. The person who packaged it wanted it, and unless you want to accuse maintainers of being clueless, it's going to be a bit hard to presume that the maintainer didn't know what they were getting. Oh, and what's your DFSG justification for the Nobody Wants It test? - Matt
Re: RE-PROPOSED: The Dictator Test
On Sat, Jul 24, 2004 at 12:28:24AM -0400, [EMAIL PROTECTED] wrote: Matthew Palmer [EMAIL PROTECTED] wrote: If it makes you feel happier, consider the tests to be proposed amendments to the DFSG. Do you feel that the dictator test does not reasonably diagnose a non-free licence, or is your objection merely that it's not a straightforward restatement of the DFSG? Good question. I actually am not convinced the dictator test even describes non-freeness accurately. I would be okay, for example, if the license says you must smile when you upload a new version, but since this has nothing to do with copyright it would fail the Dictator Test. That's the perfect thing to talk about. Firstly, having no basis in copyright means that a purely copyright licence has no basis for compelling me to do it in and of itself. The only thing that compels me to do it is that otherwise I would lose the other permissions granted. That's basically blackmail -- do this or I'll sue you. Where does it end, though? If I say you must pet a cat when distributing modifications, is that OK? Probably, unless you don't own (or have access to) a cat, or happen to be alergic to them. What about if I require you to self-flagellate whilst distributing modifications? That's OK, too, if you're a masochist, I guess. Basically, the moment you introduce extra requirements beyond that which a copyright holder is allowed to withold, you're straight into this slippery slope of look what I can make them do, which is, sooner or later, going to rear up and bite you in the arse. As you may or may not have noticed, the properties of software I am interested in seeing Debian support are use, modification, and redistribution. It bothers me to even use the word free, because it tempts people to go overboard and start talking about freedom of speech and freedom of religion, etc. While I don't *like* the smiles clause, I don't want Debian to bother with this kind of thing. But only because it doesn't practically affect you. But there are other restrictions in a similar vein which *would* affect you. Are you happy to have those restrictions applied against you, as well? - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 05:04:30PM -0700, Josh Triplett wrote: I also recall licenses that prohibited use in various types of weapons. For that matter, there is also the Hacktivismo Enhanced-Source Software License Agreement (HESSLA), as described by the GNU project on http://www.gnu.org/licenses/hessla.html (although the original project seems to be defunct at the moment). It prohibits use in spyware and by governments that violate human rights. As ridiculous as it sounds, that is actually a form of discrimination and use restriction, which makes the license not DFSG-free. Why is that ridiculous? It *is* a usage restriction. We're doing Free Software here, not Free-For-People-Who-I-Like-What-They-Do Software. In the two cases mentioned, the definitions can be fairly broad, too -- there are plenty of different ideas about what spyware actually is (kind of like computer viruses in that respect), and there aren't too many governments who don't violate some human rights now and then (or at the very least are complicit in same). I don't like those things any more than you or the authors of the HESSLA appear to, but restricting freedom for some tends to end up as restrictions for all if not addressed. - Matt
Re: Summary : ocaml, QPL and the DFSG.
On Thu, Jul 22, 2004 at 05:26:52PM +0100, Matthew Garrett wrote: Matthew Palmer [EMAIL PROTECTED] wrote: On Wed, Jul 21, 2004 at 10:58:39AM +0100, Matthew Garrett wrote: I would argue against any assertion that there's strong consensus that distribute to upstream authors is a worse restriction than distribute source too. I'll certainly throw my hat in in favour of to upstream being worse than source if binaries. Firstly, there's an advancing freedom argument -- ensuring recipients have source code (if they want it) has a great practical advantage to freedom. I hope you agree with that (if not, we have more fundamental disagreements than this small matter). But being obliged to pass stuff upstream also has an advancing freedom argument. Hoarding of code does little for freedom. Requiring me to public-domain every line of code I ever write and leave all of my computers with no passwords so anyone can see and use any code I write also has an advancing freedom argument. Lots of things have advancing freedom arguments. A lot of them place unpleasant obligations on other people, which is why they aren't truly Free. However, it may not be a trivial cost to distribute changes back to the original author -- in cases previously hypothesised, it may even be illegal. It is also unlikely to be trivial to determine what cost I may incur in sending the changes back upstream at the time I decide to exercise my granted permissions. In the vast majority of cases, the cost of distributing changes to the original author is not going to be large. We can construct fringe cases in which it may be, but it's not clear that they're significantly more common than fringe cases that the GPL comes up against. What fringe cases does the GPL come up against? Pointers to previous discussions is fine if I missed them earlier. Finally, there is the matter of choice. I can choose who I distribute my modified version to, and hence who receives the source. I cannot choose to send my modifications upstream -- I am compelled to if I wish to exercise my granted permissions. You may argue that I can avoid sending changes upstream by not making changes, but that's a bollocks argument -- if I cannot exercise the rights guaranteed to be available by the DFSG for a free licence, then that licence is not free. But exercising your DFSG rights to distribute binaries gives you an obligation to provide the source in the case of the GPL. You can't choose to give your binaries to someone if you don't want to give them your source. You can avoid giving them the source by not giving them the binaries, but then that's preventing you from exercising DFSG rights. I have recently come to believe that the GPL's requirement for source distribution is fundamentally different, and is in fact not truly a compelled distribution in the fashion of the QPL. Please rip my thought process to shreds if it's bogus. The core of my argument is that the binary and source forms of a work are in fact different forms of the same copyrighted work (excluding, for the purposes of thought-experiment, the linking issue). Since both forms are the same copyrighted work, there is no real separation of entities to distribute -- the GPL is just making that nice and clear. Consider, as an analogous situation, that some books come with CDs of the text of the book and (sometimes) further examples and other material. The printed text and the book-on-CD are the same copyrighted work. If you sell the book to someone else, you're supposed to give them the CD as well. Certainly it's frowned upon to sell the book to one person and the CD to someone else. The GPL is just source+binary in the same way as book+CD. Some licences give you the option of distributing in one form or the other, but the GPL reserves this right to some degree -- it says that you at least have to give the recipient the option -- it's like asking the person you sell your book to if they want the CD, and if they decline, you throw it in the bin. The argument seems fairly OK to me. Any comments? - Matt
Re: More questions about the QPL for compilers and other things
On Thu, Jul 22, 2004 at 02:32:47PM -0400, Brian Thomas Sniffen wrote: I see compilers -- and not just LISP compilers -- all the time, which claim to control how their output may be used. The intel compiler, for example, has an expensive license if you wish to build products for commercial sale. Metrowerks Codewarrior used to be under a similar license; I assume it still is. I always thought those came from EULA terms, not by virtue of the output of the compiler being a work derived from the compiler; certainly, I don't recall seeing a permission to distribute compiled programs in a non-commercial fashion. It's been a while since I've had a look at a EULA for a proprietary development environment; GCC does the job for me. - Matt
Re: QPL clause 6 irrelevant?
On Thu, Jul 22, 2004 at 04:14:29PM -0400, Walter Landry wrote: regarding libcwd. At the time, I didn't see any dissents, and I haven't seen anyone else bring up that angle. If you look at the ocaml licensing page http://caml.inria.fr/ocaml/LICENSE.html you could argue that the ocaml authors agree with this interpretation. So, first of all, does anyone dissent now? If not, I think as long as the ocaml authors agree with that interpretation, clause 6 is not a problem. It is, because it is explicit in that page that portions of the software *are* covered by clause 6. The one exception is custom top-level interactive systems built with ocamlmktop: those are composed of user code linked with a library containing large parts of the OCaml bytecode compiler. Those custom top-levels must comply with the requirements of paragraph 6, but that's pretty easy to do: just distribute them under an Open Source license. Oddly, though, the OCaml authors don't mention the requirements of 6c, which are what we've had trouble with. I wonder if that just is disclaiming the ability of the initial developer to compel distribution of other works. However, the choice of venue is still a problem. And 3b, IMO. I find that a larger *practical* problem than 6c. - Matt
Re: Re: Summary : ocaml, QPL and the DFSG.
On Thu, Jul 22, 2004 at 09:13:35PM +0200, Sven Luther wrote: On Thu, Jul 22, 2004 at 10:09:49PM +1000, Matthew Palmer wrote: On Thu, Jul 22, 2004 at 01:24:40PM +0200, [EMAIL PROTECTED] wrote: of stuff back to upstream. Not only are you free to chose the licence, but furthermore, it clearly states : a. You must ensure that all recipients of machine-executable forms of these items are also able to receive and use the complete machine-readable source code to the items without any charge beyond the costs of data transfer. So if there is any non-negligible cost involved in answering that upstream request, you are free to charge it to upstream. I don't see how 6a relates to 6c in any real fashion. 6c is not a subclause of 6a, so there isn't any relationship there. 6a starts by talking about recipients of machine-executable forms, which presumably the upstream author wouldn't really be, since upstream is interested in the source and not the binary. Clause 6 covers what you have to do when you are distributing a work which links with QPLed libraries. 6a says you have to distribute it with source, and can charge for the data transfer, 6b says you have to give them modification and redistributioon right, in a way mostly similar to what we consider DFSG free. 6c says that if the work linking with the library is not generally available, you need to provide it to the author upon request. Since the act of providing your work to the upstream author is clearly an act of distribution, you have to do it conforming to clause 6 of the QPL, and in particular clause 6a and 6b. That doesn't follow from the licence. 6a only applies to binary distribution, to wit: 6a. You must ensure that all recipients of machine-executable forms of these items are also able to receive and use the complete machine-readable source code to the items without any charge beyond the costs of data transfer. That's a if (binary) then no_profit_source clause, not a source is always free clause. There's several issues that arise from considering costs and charges in concert with clause 6: 1) There's nothing in there about not being able to charge for binaries, thankfully (otherwise that would be a non-commercial use clause). 2) There's nothing that says that you can't charge upstream a million dollars for their copy of the source. I imagine that upstream might not be real happy about that, but the licence doesn't say *anything* about what charge or lack thereof applies to distribution upstream. This cuts both ways, of course. We can't exactly argue that distributing items upstream is a cost to the user if they can make a profit off it, but at the same time, I severely doubt that you support the interpretation that the user is able to charge the initial developer an unrealistic price, especially given the Trolltech annotations, which you appear so enamoured of, which state that the intent of 6c is that of trying to stop proprietary software being made which is based on QPL software. 3) If clause 6 was interpreted to mean source is always free, then the clause devolves into a non-commercial use clause, because in many cases there *is* no binary form. I'm thinking Perl, PHP, Python, or anything like that, where anything written in an interpreted / JITted language is linked to a QPL'd library, you cannot charge for the program, because then you would be charging for source, which is not allowed by your interpretation of the clause. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 07:23:42PM -0400, Glenn Maynard wrote: On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: The consensus on debian-legal seems to be strongly against the QPL. I suspect Sven thinks--or hopes we'll believe--that one person disagreeing with consensus two hundred times is roughly equivalent to the reverse. To be fair, there are two people arguing against the QPL being non-free. It doesn't change the core of your premise, of course, just the numbers. And note that, at least in Sven's case, most of the disagreement consists of abuse and assertion, not invalidating the arguments. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 07:59:30PM -0400, Glenn Maynard wrote: On Thu, Jul 22, 2004 at 04:34:33PM -0700, Josh Triplett wrote: Would you might clarifying what that grounding is (or pointing me at a particular message that does so)? I'm currently drafting the second draft of the QPL summary, and that's one of the few things I'm still working on: a well-grounded justification from the actual text of the DFSG. The fee angle seems nebulous, and hard to justify; I more-or-less agree with it, but I need a clear way to justify why it is only a royalty or other fee if it is paid to the upstream developer, and not if it is paid to someone you are already distributing the software to. The license of a Debian component may not restrict any party from selling or giving away the software ... I believe may not restrict is the operative phrase; this is a restriction. I think we need to include the rest of that sentence is important, though: as a component of an aggregate software distribution I would fully support an amendment which made it explicit that DFSG #1 applied to individual distribution also, but as written I think it is mostly a protection for commercial Debian distributors, and a restatement of DFSG #9. A rewrite to be something like ... selling or giving away the software, either individually or as a component of an aggregate software distribution ... would do the job, I think. Again, judgement is called for in the interpretation, but no more than currently. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 04:45:07PM -0700, Josh Triplett wrote: Sven Luther wrote: On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote: Sven Luther wrote: On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: [EMAIL PROTECTED] writes: Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam upstream with every change done should resolve all the issue. Or maybe giving him consultation access would be enough. Spamming upstream is not enough. You have to provide one on request, even if you just sent one. Additionally, now you're suggesting doing away with the ability to make private modifications. Bullshit, you have provided it before it was asked, so where is the problem ? Do you see anything in the QPL that says the original developer can only request your changes once? They can ask twelve times a day if they Well, whatever is the problem ? You provide it to them, and if they ask you again, you either say, sorry, i sent it to you already, and haven't got a backup copy, would you like the latest version perhaps ? If you already fullfilled the request before you are asked, where is the problem. From the QPL: c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. Where in there does it say that you may refuse to supply a copy if you have already provided one? The licence specifically says you must supply one, referring to a copy of the software. Technically, if you have previously provided a copy of the software, you have fulfilled the obligation to supply one [copy of the software]. That being said, there is the alternate interpretation that for every request received, you must supply one, and that is a perfectly valid interpretation of the licence. If the user took the former interpretation, and the licensor took the latter, it's off to the courthouse to get it all argued about. Again, it's a matter to be clarified with the licensor. I certainly wouldn't want to be bound by the terms of the licence with that ambiguity hanging over it. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 08:19:50PM -0400, Glenn Maynard wrote: On Thu, Jul 22, 2004 at 05:13:50PM +0100, Matthew Garrett wrote: Of course, this mostly just turns the argument into one about weightings. Since these are mostly determined by personal opinion, it suggests that there isn't a correct place to draw the line. The only real suggestion I have is wider discussion in an attempt to gain a better understanding of how different people view the issue. That's exactly the purpose of many of the discussions on d-legal. I'm not sure what you think should change. Do you think the QPL discussion would be more productive if crossposted to d-devel? (I think it would just annoy the people who have chosen not to participate.) Can anything be productive if cross-posted to d-devel? - Matt
Re: Termination clauses, was: Choice of venue
On Thu, Jul 22, 2004 at 04:27:25PM -0700, Josh Triplett wrote: Matthew Garrett wrote: Matthew Palmer [EMAIL PROTECTED] wrote: On Wed, Jul 21, 2004 at 11:05:55AM +0100, Matthew Garrett wrote: 2) In the case of a BSD-style license with a QPL-style forced distribution upstream clause, there would be no need for a QPL-style permissions grant. Upstream could subsume it into their closed product anyway. But I could do the same to their work under a BSD licence. I can't do that with a QPL-licenced work. It's all about equality. It's not necessarily a *good* outcome, but it's a *better* outcome. I don't think a license that allows people to produce closed products is a good license. I think a license that allows precisely one person to produce a closed product is better than one that allows many people to do so. I still don't think it's good, but I certainly don't think it's non-free. Why is equality so much of an issue? Very well put. That's exactly my reasoning behind saying the upstream gets an all-permissive license requirement is acceptable and just obnoxious. While being able to take your modifications to a piece of software proprietary might be considered bad (opinions differ), I'd much rather that everyone was able to do it than one party. That way nobody is in a preferential position -- why should someone be able to take my work proprietary, if I don't have the ability to do the same in return? You might argue because they've done a lot more work that you, but that's not what the licence says. If I rewrite 50% of a QPL'd program, the initial author still has the ability to sell that large body of code, but I can't sell my modified version. The inherent unfairness of it irritates me. On the one hand, I can see why some people don't think it's non-free -- If I can make the modifications guaranteed by the DFSG, what's the harm?, but one of the real benefits of Free Software is that no member of the community has an inherent advantage over anyone else -- a free market ideal. - Matt
Re: More questions about the QPL for compilers and other things
On Thu, Jul 22, 2004 at 02:28:07PM -0400, Brian Thomas Sniffen wrote: compiler to tell for sure what this means. But when I see INRIA handing out a license that specifically mentions items which link to the compiler, I have to assume that they mean *something*, and didn't just pick a license with a giant meaningless clause. Especially since we've already been told that INRIA took a lot of time deciding on the QPL. The only issue is whether INRIA's interpretation of the licence is a lot different to how we're interpreting it. - Matt
Re: ocaml QPL : Clause 3b in question now.
On Thu, Jul 22, 2004 at 09:56:06PM +0200, Sven Luther wrote: And yes, if i sound pissed, i am. It is now almost one week since this bullshit started, and we haven't advanced one bit, and you are all so imbued Do you think that we might have advanced more had you actually put up some reasonable logic as to why our interpretations of various clauses are incorrect, rather than ranting and frothing about how we're all wasting your time? I've changed my opinion on the licence several times in this thread, but interestingly, never because of anything you've said. That is odd, because you're the person who feels most strongly about the freeness of the QPL. Perhaps if you spent more time reasoning and less time flying off the handle, you might make a positive mark on me or other people on this list. with your righteouness that you don't even bother reading the licence you are criticing, nor the comment that don't agree with you. You keep saying this, but I believe you have no proof of what you claim. In fact, the number of rebuttals which have been written to points you've made would be quite strong evidence that people have read comments that they don't agree with. As to your claim that nobody has read the licence, well, it's been quoted and debated in this thread quite heavily, and I doubt that would be possible if the participants had never read the licence. What you might mean is haven't interpreted it the same way as Sven, but then again, you have a vested interest in interpreting the licence in a fashion which benefits you, so your interpretation might be considered suspect. Most other people have no such vested interest in the outcome of this discussion. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 10:07:55AM +0100, MJ Ray wrote: On 2004-07-23 08:47:42 +0100 Matthew Palmer [EMAIL PROTECTED] wrote: To be fair, there are two people arguing against the QPL being non-free. I think there are more than that, but not all are helping to move things forward. ;-) In any case, it doesn't matter at this point what the numbers are. If their argument explains why a QPL-covered work follows DFSG and that isn't affected by the discussed problems, I hope most of us are humble enough to correct ourselves. If I saw an argument which cleared up all of the concerns I had, I'd be more than happy to acquiesce. I've already had my mind changed several times by persuasive discussion in this thread, but there are still several problems to worry about. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 11:18:28AM +0200, Sven Luther wrote: On Thu, Jul 22, 2004 at 04:45:07PM -0700, Josh Triplett wrote: Sven Luther wrote: On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote: Sven Luther wrote: On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: [EMAIL PROTECTED] writes: Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam upstream with every change done should resolve all the issue. Or maybe giving him consultation access would be enough. Spamming upstream is not enough. You have to provide one on request, even if you just sent one. Additionally, now you're suggesting doing away with the ability to make private modifications. Bullshit, you have provided it before it was asked, so where is the problem ? Do you see anything in the QPL that says the original developer can only request your changes once? They can ask twelve times a day if they Well, whatever is the problem ? You provide it to them, and if they ask you again, you either say, sorry, i sent it to you already, and haven't got a backup copy, would you like the latest version perhaps ? If you already fullfilled the request before you are asked, where is the problem. From the QPL: c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. Where in there does it say that you may refuse to supply a copy if you have already provided one? Where in it says you have to ? Where in it says that you don't? For my part, I can't see how either interpretation is more plausible than the other. In this sort of situation we *can't* take the easy interpretation; if the least friendly plausible interpretation is non-free, we have to go down that path. Optimism is dangerous. Please let's not forget common sense. Common sense is being used. We're approaching this from a pessimistic, protection perspective. You're approaching this from a it has to stay free perspective. want, and you have to comply; there is nothing in the license that says otherwise. For that matter, do you see anything in the QPL that says the original developer has to compensate you for the costs of providing your changes (bandwidth charges for network distribution, or media costs for physical distribution)? Yes, since the distribution will happen accordying to 6a, which says you can charge for the cost of data transfer. From the QPL: c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. Where in there does it say that the copy you supply to the initial developer is covered by the terms of 6.a? 6.a only covers recipients Well, it is evident. The section 6 covers how you distribute these code linking with the library. IF you distribute such code, you have to cumply to all of a, b and c, is it not ? You don't see in the main header of 6 that you have to satisfy one or the other, or you could safely ignore 6c and the whole point would be moot. All three subclauses have to be satisfied or judged to not apply. 6a doesn't apply to source-only distribution (all recipients of machine-executable forms). 6b applies to all distribution. 6c only applies if the items are private *and* the initial developer asks for a copy of the item. In the instance of applying 6c, we recurse through the licence, go through 6 again, and *again* we don't apply 6a because the initial developer asks for a copy of the source. Of course, the obvious loophole there is that the initial developer asks for a copy of the binary instead, in which instance 6a is invoked, and all's good. But is charging for a binary instead? Presumably it is, as otherwise the licence is non-commercial-only, and non-free, but there's no exception for the initial developer on that point, so I can charge the initial developer an unrealistic amount of money for my binary. who have a binary and want the source. In this case, if you are distributing source (that is not available to the general public), then the source is one of the items in question, and it must be provided under 6.c, which does not indicate that you may charge for cost of distribution. Notice that 6c speaks about copy of the items. How do you interpret this. In the absence of clarification, I'd imagine it'd mean a copy of the source, because the binary is of very limited use to the initial developer. No binary means 6a doesn't apply. This has no meaning apart from the stuff described in the 6 header, that is : You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 05:08:05AM -0400, Glenn Maynard wrote: On Fri, Jul 23, 2004 at 05:54:29PM +1000, Matthew Palmer wrote: The license of a Debian component may not restrict any party from selling or giving away the software ... I believe may not restrict is the operative phrase; this is a restriction. I think we need to include the rest of that sentence is important, though: as a component of an aggregate software distribution I would fully support an amendment which made it explicit that DFSG #1 applied to individual distribution also, but as written I think it is mostly a protection for commercial Debian distributors, and a restatement of DFSG #9. The component of an aggregate ... phrase is usually read as a specific restriction which is allowed: restrictions like this may only be distributed along with other programs[1] are free. DFSG#1 certainly applies to non- aggregate distribution, as well. I'd challenge certainly. It's the most reasonable interpretation, considering that we want to allow people to use the software itself, too, but throwing certainly in there is a little strong. I think it's pretty much the same thing, anyway; most licenses apply restrictions on distribution--not caring whether it's aggregated or not. The QPL's restrictions on distribution still apply if aggregated with other works, so DFSG#1 applies even if we accept your argument. Well, reading the whole sentence as one entity, it could be interpreted that DFSG #1 ONLY disallows aggregate prohibition, since there is no mention of non-aggregate distribution at all. Also, reading the second sentence as a followup of the first, it only disallows upstream for charging a fee for distribution of the software as part of the aggregate. Note that I don't agree with this interpretation, because it causes too much trouble in too many cases, but I think it's an interpretation that can easily be argued for. It's one of the reasons that I'm in favour of a few enhancements to the DFSG -- think of them as editorial changes to the DFSG grin. They shouldn't change the meaning of the DFSG for the common interpretation, but it'll reduce the ambiguity so no doubt some people will think it's a major change. [1] Bundling with hello world to form a trivial aggregate is generally expected to satisfy this; anything stronger, such as must be bundled with at least 10 megs of other stuff would probably be non-free. Working around not by itself problems by trivial bundling is right up there with this licence clause isn't a problem because the law doesn't allow the licensor to do that in terms of arguments that shouldn't be made. It's acting in bad faith, in my opinion. We shouldn't be looking for workarounds, we should be evaluating licensor intent (as expressed by the chosen licence and any clarifications received) and judging that against the DFSG, without playing the how can we work around this to get it in game. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 11:59:53AM +0200, Sven Luther wrote: On Fri, Jul 23, 2004 at 07:41:55PM +1000, Matthew Palmer wrote: On Fri, Jul 23, 2004 at 11:18:28AM +0200, Sven Luther wrote: Well, it is evident. The section 6 covers how you distribute these code linking with the library. IF you distribute such code, you have to cumply to all of a, b and c, is it not ? You don't see in the main header of 6 that you have to satisfy one or the other, or you could safely ignore 6c and the whole point would be moot. All three subclauses have to be satisfied or judged to not apply. 6a doesn't apply to source-only distribution (all recipients of Ok. machine-executable forms). 6b applies to all distribution. 6c only applies if the items are private *and* the initial developer asks for a copy of the item. Notice that it doesn't apply to private stuff, but only to not openly distributed ones, please don't muddle the water. !Public == Private. In the instance of applying 6c, we recurse through the licence, go through 6 again, and *again* we don't apply 6a because the initial developer asks for a copy of the source. Of course, the obvious loophole there is that the initial developer asks for a copy of the binary instead, in which instance 6a is invoked, and all's good. But is charging for a binary instead? Presumably it is, as otherwise the licence is non-commercial-only, and non-free, but there's no exception for the initial developer on that point, so I can charge the initial developer an unrealistic amount of money for my binary. Ok, are you so sure of this that you would care to go before a judge with this interpretation ? No, because my French lawyer would do that for me. who have a binary and want the source. In this case, if you are distributing source (that is not available to the general public), then the source is one of the items in question, and it must be provided under 6.c, which does not indicate that you may charge for cost of distribution. Notice that 6c speaks about copy of the items. How do you interpret this. In the absence of clarification, I'd imagine it'd mean a copy of the source, because the binary is of very limited use to the initial developer. No binary means 6a doesn't apply. And is the second phrase of the 6 header not clear enough, please reread it. These items, when distributed, are subject to the following requirements:. That makes no mention of the form of the items, either during the initial distribution, nor of the copy demanded of me by the initial developer. This has no meaning apart from the stuff described in the 6 header, that is : You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements: These items clearly refer to application programs, reusable components and other software items that link with the original or modified versions of the Software, and this clearly states that you have to cumply with all of the following, 6a to 6c. Comply or show as non-applicable. In the same way that 6c doesn't apply to every act of distribution, 6a doesn't apply in all situations of distribution either. Would you go before a judge with this interpretation ? What does you lawyer say about this ? My imaginary lawyer says you're a tool. Yours laughs at you. I think there's a pattern here. (Are you using webmail through lynx?) I have no choice, since i was not originally CCed, i have to go to the web archive to read the discussion, get the url of emails i want to respon, launch lynx over ssh on the box which does mail processing, open the url, go to respond to or whatever link and send the mail. Does copy-and-paste not exist on your system? Thanks all the same, but the web url for replying don't seem to be accepted by mutt, so please inform yourself before making sarcastic claims such as those. rolls eyes - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 11:54:13AM +0200, Sven Luther wrote: On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: Sven Luther wrote: Well, so what. This only proves that there are licences which allow proprietary product, and i would never voluntary release code under such a licence, and they are other who don't. Neither would I. However, my issue with the QPL is not that I would want to take the software proprietary, but that I might want to But Brian's interest seem to be. distribute Free Software between a few people, giving those people all the freedoms expected for Free Software. And ? What is the problem with that ? You can do it, the only point is that you have, upon request to give the upstream author (probably anyone in the chain of upstream authors) a copy of it if they request it. This can only be a problem with the DFSG 1, if you consider such a thing a fee. But since the cost to you is nil, i wonder if we can consider it as a fee, and also i consider the fairness involved in refusing to give this to upstream that he requests, while you had no problem in taking his work for free. We're not taking his work for free, because he didn't offer it for free. That's the problem. If I take a GPLed program, modify it, and distribute the modified version among a few people, then as long as those people also have the source (or an offer for the source), then no one is being deprived of Freedom, and the software is not proprietary. So what, how does that change with the QPL ? Because someone else can come in and legally demand the changes I've made. That said, I personally think that under almost all circumstances, it is a good idea to provide your changes upstream. So, ... Good ideas in the general case are not necessarily good when compelled by licence terms. Anyway, notice that QPL 6 doesn't speak about modification, but work which link to a QPLed library. Not exactly the same thing. Which is even worse, because the QPL is then compelling distribution of essentially unrelated items. If dynamic linking doesn't produce a derivative work, the QPL is overstretching it's bounds by quite a bit. Also, i also doubt that this is a way debian is confortable goind, and that allowance of proprietary modifications over other considerations is the path we are conforable threading. You doubt that which is the way Debian is comfortable going? To make allowance to proprietary modification hoarder, like you seem to be. Again, modifications shared amonst a group, with everyone in that group having Freedom, are not proprietary. Well, sure, but what is your moral ground for refusing the same modifications to upstream ? What's your moral ground for asserting that upstream has a right to my modifications? offers lots of permission, and asks nothing. It's more generous than fair. The GPL is fair: it offers many permissions, but some of them can only be exercised if you pass the same permissions on to others. That is, it's a copyleft. But it's probably the most restrictive you can be and still be fair. Whatever. you want to modify ocaml, and not give back your changes to the community. You have no sympathy from me, neither probably from a waste majority of the debian project. Also you lying, claiming consensus, while there is no such thing, doesn't endear you to me. I don't think personal insults really help anything. What I see is a Well, you claimed there was a consensus, while there is clearly no such thing. Thus it is a lie intended to get the maintainer to take the course of action you want through FUD, or at best a misinformed claim you should apologize for. The consensus on debian-legal seems to be strongly against the QPL. Well, i see disenting voices in that conversation, and the consensus you mention seems to be one of assertion, as it is quite lacking in analysis and real arguments, don't you think. Yes, I do see that quite a bit on one side of the discussion. have. Feel free to rebut the arguments of others, but please do not call people ignorant or accuse them of not reading the license. I have, and you didn't respond to them when i first voiced them, and have to this date not yet done so. The question of whether the QPL is free appears to have firm consensus from everyone involved in the debate, instead of standing on the sidelines and screaming. A, a consensus is one where there is no discordant voice, right ? Consensus is stronger than a simple majority, but it does not necessarily unanimous consensus. Consensus: a general agreement about a matter of opinion. Mmm. Mmm indeed. You are aware that general agreement != unanimity? In general meaning usually, but not always? What much more ? And what do you loose if upstream is allowed to use your code in the main product, and
Re: Bug#227159: ocaml: Worse, the QPL is not DFSG-free
On Fri, Jul 23, 2004 at 12:02:21PM +0200, Sven Luther wrote: On Thu, Jul 22, 2004 at 06:37:29PM -0700, Josh Triplett wrote: [EMAIL PROTECTED] wrote: Still, in this matter we need to find a balance between the right of the developer (who don't wish people to use the software in disrespect of the licence) and the wish of users who want to do modifications, and as long as they respect the licence, should not be furthermore molested. The fear of harassment only comes for someone who is willingly breaking the licence, and seriously, do we want to encourage those ? Or anyone who can be accused of breaking the license. And in order to show you aren't, you would need to show up in the licensor's jurisdiction. Well, this may work in the US, where trigger happy legal action is comon place, as shown by the RIAA-sues-the world news we commonly get. What procedures do you have in place in France to ensure that ultimately unsuccessful lawsuits don't get started? And finally, i know the upstream authors personnally, and i also understand their situation enough to know that they won't engage in any such harrasment, even if it was possible. I can understand that. However, we cannot say the QPL is Free because the non-Free clauses will not be executed by one particular user of the QPL. Furthermore, if upstream has no intention of engaging in such harrassment, perhaps they could be persuaded to waive the clause that gives them the ability to do so. (Yes, I do understand that upstream does not like to deal with licensing issues.) And where exactly does the DFSG make this non-free ? DFSG #14: Just because the Debian maintainer doesn't think a non-free term will be exercised, doesn't make the non-free term magically disappear. Nor does wandering into debian-legal, sticking his fingers in his ears, and shouting laa laa laa! I can't hear you! Your arguments are bogus! make the non-free term go away, either. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 02:22:06PM +0200, Sven Luther wrote: On Fri, Jul 23, 2004 at 10:08:14PM +1000, Matthew Palmer wrote: On Fri, Jul 23, 2004 at 11:54:13AM +0200, Sven Luther wrote: On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: Sven Luther wrote: Anyway, notice that QPL 6 doesn't speak about modification, but work which link to a QPLed library. Not exactly the same thing. Which is even worse, because the QPL is then compelling distribution of essentially unrelated items. If dynamic linking doesn't produce a derivative work, the QPL is overstretching it's bounds by quite a bit. And you ignored me arguing repeteadly that a derived work and a modified work are not the same thing, right ? Again this speaks highly of your capacity to follow up here and make informed arguments. Go the ad hominem. Yeah. Not to mention the fact that I never argued that a modified work is not a derived work. Quote me saying that. Go on. Go nuts. Well, sure, but what is your moral ground for refusing the same modifications to upstream ? What's your moral ground for asserting that upstream has a right to my modifications? What is your moral ground that he has not ? Elemental courtesy and decency sure would fall into play here. They're not his modifications. What is your moral ground that he has? Well, i see disenting voices in that conversation, and the consensus you mention seems to be one of assertion, as it is quite lacking in analysis and real arguments, don't you think. Yes, I do see that quite a bit on one side of the discussion. Thanks, again you can only reject those accusation by counter attacking. Yes, I do see that quite a bit on one side of the discussion. You don't give a free blank check here, you only give the right for the code to be integrated back in the original software, and in the case of dual licencing of said software, like in both the ocaml and Qt case, you give the right to have the _SAME_ software also relicenced under the other licence, thus allowing upstream to not have to handle a split patch. In no way does Upstream doesn't have to handle a split tree, they just don't integrate anything they haven't got their permission grant or copyright assignment for. Ok. But they can't reuse the modification then, and all the free software community looses then. Why can't they reuse the modification? They either have the copyright (by assignment) and can therefore do whatever they want, or they have the same blanket permission they have with the QPL, but this time they haven't coerced it. Either way they can incorporate the change into anything they like, free, non-free, or otherwise. For someone who is very quick to accuse others of not reading the rest of the thread, you're *incredibly* good at forgetting what people have previously told you. Given the amount of bullshit i have been told, well, one little minor lapse can be acceptable, and at least i accept my error, while others just don't. One minor lapse. Does anyone else get the same benefit? - Matt
Re: The Sv*n L*th*r drinking game
On Fri, Jul 23, 2004 at 04:37:49PM +0200, Sven Luther wrote: intention would clearly be to dealy the issue until everyone who opposes you has left in disgust, and you can claim consensus. *You've* driven three people out of this discussion with your personal abuse against them. Who is exactly is trying to berate the opposition into silence and then claim they hold the consensus opinion, exactly? - Matt
