Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Don Armstrong wrote: Unfortunatly, there's not much that can be done to protect us from this latter case. If upstream wants to lie about which is the prefered form for modification, our choice is either to stop distributing or pony up when they sue us for violating their license and prove that they're lying. [But again, this is about determining which form is the prefered form for modification, not about what we do once we know what that is.] If upstream sued Debian for violating their license for this reason, wouldn't the onus of proof then be upon upstream to prove that they were lying about what was their preferred form of modification? Given that, I'm not sure a judge would be very sympathetic to upstream's case ;-) best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed software with no true source. Was: Bug#402650: ITP:mozilla-foxyproxy
Evan Prodromou wrote: On Tue, 2007-30-01 at 11:54 -0800, Don Armstrong wrote: This refrain keeps getting repeated, but still no one has explained how distributing a form of the work which is _not_ the prefered form for modification satisfies section 3 of the GPL: So, I think we all readily admit that _some_ transformations on the original source (like compression) are acceptable. The distributed source code does not need to be bitwise identical with the source edited by the developer to be the preferred form. s/compression/lossless compression/ I think we'd all be pretty comfortable with some other transforms, like \r\n - \n line ending conversion or character set changes. The commonality between these changes and lossless compression is that all are 100% reversible, assuming one knows what transformation operations have been performed. (Well, the character set changes I suppose depend on exactly what the original and final versions looked like; UTF-8 - ISO 8859-1 is obviously not reversible if the original was in Japanese.) Stripping whitespace on the other hand is not reversible. One may be able to add whitespace back (e.g. with indent) but there is no guarantee that the result is identical to the original version of the file before whitespace stripping. That said, personally (IANAL) I'd consider whitespace stripping to be a non-issue. After a change that is trivial for any downstream recipient of the code to make (running the afore-mentioned indent), the whitespace-stripped code is transformed into a Javascript file that is functionally identical to the original even if not bit-for-bit identical. For most people, probably including upstream, the result would be just as much a preferred form for modification as the true original was. On the other hand, transforming a UTF-8 Japanese document to ISO 8859-1 would obviously *not* result in something that upstream (or anyone else) would consider a preferred form for modification. My main concern in the particular case of mozilla-foxyproxy would be (as someone else mentioned) that comments in the code may have also been stripped to save space. I would consider redistribution of such comment-stripped code to be a violation of the GPL in spirit as well as in letter. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed software with no true source. Was: Bug#402650: ITP:mozilla-foxyproxy
Ben Finney wrote: Kevin B. McCarty [EMAIL PROTECTED] writes: personally (IANAL) I'd consider whitespace stripping to be a non-issue. After a change that is trivial for any downstream recipient of the code to make (running the afore-mentioned indent), the whitespace-stripped code is transformed into a Javascript file that is functionally identical to the original even if not bit-for-bit identical. Careful with this. functionally identical is not what is needed; we need the work *in the form that's preferred for modification*, including all comments and other human-to-human communication. The entire point of getting the source code is that it's what the *human* needs as a programmer, not that it's functionally identical to the original program. Yes, I should have been clearer. By functionally identical, I meant from the point of view of a person as well as of a machine. I completely agree with you that stripping comments is evil. Likewise for obfuscating variable names, removing whitespace that can't trivially be put back, etc. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
krb5 license export clause
Hi debian-legal, While helping with a license audit of the largely LGPL'ed project ROOT (message CC'ed to project contacts), I happened to notice that the license for source package krb5, from which the ROOT source uses some code, contains the following clauses: - Export of this software from the United States of America may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. WITHIN THAT CONSTRAINT, permission to [do standard MIT license things] is hereby granted, provided that [standard MIT license requirements are obeyed.] - (The full license is attached.) I know there have been numerous discussions about export restrictions as they relate to DFSG-freeness before, but I was surprisingly unable to find one about this particular license. The first paragraph excerpted above, if it were by itself, would seem harmless to me because it is a legal no-op: it is just an advisory notice, not a requirement of the license. What puzzles me are the words WITHIN THAT CONSTRAINT. Is that phrase sufficient to cause US export restrictions to be incorporated into the license? My understanding is that if so, it would not be DFSG-free, and also not GPL- or LGPL-compatible. If WITHIN THAT CONSTRAINT does *not* cause US export restrictions to be incorporated, then what (if anything) is the semantic content of those three words? Thanks in advance, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 Copyright Notice and Legal Administrivia Copyright (C) 1985-2006 by the Massachusetts Institute of Technology. All rights reserved. Export of this software from the United States of America may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Furthermore if you modify this software you must label your software as modified software and not distribute it in such a fashion that it might be confused with the original MIT software. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. Individual source code files are copyright MIT, Cygnus Support, OpenVision, Oracle, Sun Soft, FundsXpress, and others. Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira, and Zephyr are trademarks of the Massachusetts Institute of Technology (MIT). No commercial use of these trademarks may be made without prior written permission of MIT. Commercial use means use of a name in a product or other for-profit manner. It does NOT prevent a commercial firm from referring to the MIT trademarks in order to convey information (although in doing so, recognition of their trademark status should be given).
Re: Eterm license violation and non-free
bob marlet wrote: hi, Eterm was removed from debian testing because a problem of license : there is a cannot be sold for profit in some source file. is it possible to include Eterm in non-free? see http://lists.debian.org/debian-legal/2006/03/msg00572.html cannot be sold for profit is ok with non-free? we need to have Eterm in etch, please can you solve this problem thank you From the thread you cite (please note, I haven't done any investigation of the Eterm source code myself), it sounds as though the various source code files are licensed in ways that are incompatible with each other (4-clause BSD license, GPL, no-commercial-use license...) The licensing bug is at http://bugs.debian.org/359707 although it doesn't have any more info than what's in the debian-legal thread. This means that an Eterm binary, which is a derived work of all the source files, cannot be distributed at all, not even in non-free, because the license terms conflict. The Debian maintainer and/or upstream will need to solve this in order to get Eterm back into Etch. You may want to email them to ask about the status of the problem. Sorry this probably wasn't what you wanted to hear... -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Geant4 Software License, version 1.0
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 8. This license shall terminate with immediate effect and without notice if you fail to comply with any of the terms of this license, or if you institute litigation against any Member or Copyright Holder of the Geant4 Collaboration with regard to this software. [end of license] Thanks, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft
From GPL v3 draft 1: [13.[8] Geographical Limitations. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.] Nathanael Nerode wrote: *** Um, what's the brackets about? This clause should be deleted. Those countries are excluded implicitly by the previous clause anyway. The brackets apparently indicate that FSF _is_ planning to delete the clause unless it receives protests from people who want to keep it. See the rationale document, section 2.14: http://gplv3.fsf.org/rationale#SECTION00314 regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the FSF's GPLv3 launch conference [OT]
Alexander Terekhov wrote: The gang should better stop misstating the copyright act, to begin with. But actually it doesn't really matter given that Wallace is going to put the entire GPL'd code base into quasi public domain pretty soon anyway (antitrust violation - copyright misuse - quasi public domain/copyright impotence). http://www.ip-wars.net/public_docs/wallace_v_fsf_36.pdf (first, obligatory IANAL) I think this is unlikely, given that the plaintiff's claim there is based on a false assertion. Quoted from your cited document, page 4: [begin quote] The GPL term 2(b) also fixes the maximum price at no charge for the market value of a derivative or collective computer program thus created by the pooled code. All future third parties who accept the GPL copyright license must distribute their collaborative creations at no charge. [end quote] This is not true. 2(b) says that you must *license* work you derive from GPL'ed material and distribute for free, but section 1 specifically says You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. There is no limit specified on the fee that may be charged. Those interested in this case may note that this is the plaintiff's *fourth* amendment of his original complaint; the judge dismissed his third amended complaint without prejudice here: http://www.internetcases.com/library/cases/2005-11-28_wallace_v_fsf.pdf Some more references are available from Wikipedia: http://en.wikipedia.org/wiki/Daniel_Wallace_(plaintiff) -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox licensing issue
Arc wrote: While Firefox itself is licensed under a free license, there's an issue in the way the Mozilla foundation designed it to include their own package system for extensions and themes. Take Firefox 1.5 for example, I've had it for a few hours, downloaded a few extensions.. whoops. Looking at the readme in Foxytunes, for example, I find non-free terms (below). At no point did I see any notification of the license before installing this extension, and only by viewing a text file embedded in firefox's installation directory did I learn of this. Note that this is covered in a bug report, but no action has been taken yet to fix this problem: https://bugzilla.mozilla.org/show_bug.cgi?id=275743 I don't have any recommendation as to how to solve this problem in debian - I'm pointing this out, however, as an issue that the debian community may wish to do something further with. I don't quite see how Debian could help with this specific problem. Foxytunes (like any Firefox extension not packaged by Debian) is third-party software, and it seems to me that the onus of finding out its licensing terms is on the person who installs it. Neither Debian nor the Mozilla foundation can be reasonably expected to maintain a list of the licenses of every available extension. (Granted, perhaps Mozilla should at least audit licenses for extensions listed on mozdev.org...) Of course it would be very nice for Mozilla to have an API via which extension authors could state their licenses, and a GUI dialog box that would pop up the extension license for inspection before installing it. Ideally most extension authors would take advantage of the interface. But this sort of major feature needs to be added upstream. If such an interface were added to the Debian package of Firefox, hardly any extension developers would use it as long as it was Debian-specific. [Foxytunes license snipped] regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPlayer revisited
MJ Ray wrote: I'm not quite sure what sort of statement about patents will convince ftpmasters. Maybe knowing what patents held by who are definitely infringed by mplayer is good, especially if none of them are actively enforced, or maybe it is bad. ObligatoryIAmNotALawyerDisclosure / This seems like a potentially bad idea, actually. I certainly can't cite specific laws, but I seem to recall from similar discussions that if a patent holder can prove a patent was violated in full knowledge of the violation, he is entitled to triple damages. In the course of researching patents possibly violated by MPlayer, one would surely uncover the presence of the same patents in code already in Debian -- the already-mentioned Xine, Avifile, etc. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question about freeness of XyMTeX license
Hi debian-legal, I have ITP'ed xymtex ( http://bugs.debian.org/304714 ). This collection of LaTeX macros has the following license: %% Copying of this file is authorized only if either %% %% (1) you make absolutely no changes to your copy, including name and %% directory name %% (2) if you do make changes, %% (a) you name it something other than the names included in the %% ``chemist'' directory and %% (b) you acknowledge the original name. %% This restriction ensures that all standard styles are identical. %% %% === %% %% This file is a modification of latex.tex (LaTeX2.09) and of latex.ltx %% (a LaTeX2e), the reused parts of which is subject to %% Copyright 1994 the LaTeX3 project and the individual authors (For further %% copyright information see the file legal.txt of the LaTeX2e standard %% distribution, and any other copyright indicated in this file.) [end license] Assuming that by copying, upstream really means public redistribution (something which I have already emailed him to clarify), is this acceptable for main? Can Public redistribution is authorized if... be considered a grant of permission? If so, my understanding is that the restrictions in option (2) are permissible under the DFSG's Integrity of the author's source code, correct? Thanks, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Adding back compressed GIF code to cernlib after July 7 -- any objections?
Hi all, My understanding is that the last known patent on LZW compression held by Unisys, in Canada, expires tomorrow, July 7th 2004. I plan to ask my sponsor, Bas Zoetekouw, to upload a version of cernlib with compressed GIF creation support added back in soon afterwards. (This may be delayed several days from the expiry date due to some real-life obligations I have.) Any objections? N.B. I have always previously removed compressed GIF creation source code from the orig.tar.gz of the cernlib packages distributed by Debian. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: License of ROOT: acceptable for non-free?
Thanks to everyone who provided comments. I've sent a polite email detailing some of the licensing issues upstream. The person who does the Debian packaging for ROOT upstream (Christian Holm Christensen) has said to me by email that he would like to ITP ROOT for Debian, so I will not be filing an ITP myself. Regards, -- Kevin McCartyPhysics Department [EMAIL PROTECTED] Princeton University www.princeton.edu/~kmccarty Princeton, NJ 08544
