Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
In message [EMAIL PROTECTED], Kevin B. McCarty [EMAIL PROTECTED] writes 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 ;-) Bear in mind, in the case we are discussing, upstream appears to be the copyright owner. In that case, a Judge is *certain* to say you have no standing to sue. Case dismissed. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- 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
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
On Fri, 02 Feb 2007, Kevin B. McCarty wrote: 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 ;-) Yeah, in the case where there's a single copyright holder, it's a pretty useless tactic. The problem only really comes into play when there are multiple copyright holders. [Of course, that's the state of a lot of works in Debian, but possibly not the one that originally started this thread.] Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, Chew more! Do more! The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://rzlab.ucr.edu -- 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
On 01/30/07 11:54, Don Armstrong wrote: On Tue, 30 Jan 2007, Stephen Gran wrote: Just pointing out that it doesn't break our ability to redistribute under the GPL. 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: It can't be explained because your assumptions are wrong. You think that section 3 needs to be satisfied based on your interpretation but it only needs to be satisfactory to the author. The GPL is not a contract. Rights are granted by the creator. -- 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
On Wed, 31 Jan 2007, Jeff Carr wrote: On 01/30/07 11:54, Don Armstrong wrote: On Tue, 30 Jan 2007, Stephen Gran wrote: Just pointing out that it doesn't break our ability to redistribute under the GPL. 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: It can't be explained because your assumptions are wrong. You think that section 3 needs to be satisfied based on your interpretation but it only needs to be satisfactory to the author. This is the it's against the license, but the author doesn't care argument. It may be true in many cases, but it's not compelling, and not something that we should even account for in our licensing discussions, because the owners of copyrights can change, their attitude towards Debian can change, and even more importantly, their attitude towards our users and mirror operators can change. [And really, if that's their interpretation, then they can grant additional permissions to the GNU GPL.] Don Armstrong -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- 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
Don Armstrong wrote: Obviously we should try to figure out if the author was lying or making fun of -legal first, but if it was actually true and debhelper was GPLed, then we can't do anything else. Why? debhelper is also developed in vim[1], I don't have to ship vim with it, why would I need to ship its preprocessor with it? They are both simply tools that let me develop the software. The fact that I didn't type in every character of debhelper exactly as it appears in the code I distribute to you is irelivant. There is no bright line between a program like vim inserting useful syntatic whitespace as I type[2], and a preprocessor expanding keywords into blocks of code. Heck, _vim_ can be used to expand keywords into blocks of code. The important thing is the code I distribute. That in both of these cases it's trivial to actually modify the work merely obscures the real problem: the users of the software are second class citizens to the copyright holder. In closing, I'd like you to consider the plight of a machine intelligence who wrote GPLed code and was forced by the act of so licensing it to embed a copy of itself[4] with any code it distributed so that the fleshers weren't second class citisens. -- see shy jo, who generated this entire email, and all of dh_install*, with some polygen grammars[3]. [1] Or was that notepad.exe, I can't remember.. [2] Consider also a text editor that automatically calculates and displays whitespace, while not bothering to save it to the output files. That is a plausable explanation for the behavior of the upstream author in the head of this thread. [3] Enrico, this is your cue. I look forward to many more interesting dh_* programs. [4] All 40 terabytes, including Vista. signature.asc Description: Digital signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Yaroslav Halchenko wrote: I've asked the upstream to provide proper source code, but so far he effectively refused to do that, although it seems to be a very simple operation to perform. I'm repeating this since it was buried in a footnote in a probably pointless subthread. There's no particular reason why a development environment for java or a similar language would need to include whitespace in the source files it saves. The whitespace can be calculated and displayed on the fly in the editor, so why bother writing it to disk? I think this is not unheard of for some real scheme/lisp editors, and I'd not be suprised if it were true for some editor for java, used by coders in a culture quite different from ours. It explains what you've described of upsteam's behavior pretty well. And choice of editor is not a reason to consider a program non-free, or that whole editor flamewar is about to reach a new level. -- see shy jo signature.asc Description: Digital signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Yaroslav Halchenko [EMAIL PROTECTED] wrote: [...] If I understood GPL license correctly, upstream author simply can't release anything under GPL if he doesn't provide sources. Whenever I've asked on mozilla's addons IRC I've got reply as \afaik he codes himself, and so if he writes on his page / in the package that it is gpl, you can use it under the gpl license\ but I think that he/she is incorrect in his/her understanding of GPL. Could anyone correct/confirm me? You are wrong. Upstream author can do anything and you can use it under the gpl licence, but not redistribute it, because you can't give recipients the preferred form for making modifications. Nor can Mozilla's addons page, so you might like to tell them if they are distributing. Is there anything I could do to gently force upstream to either provide the sources or rerelease his probably-full-of-spyware software under some non-FOSS license, so I don't even bother thinking about packaging/using it? ;-) No, you cannot bomb the copyright holder into freedom. I think you may be able to fork it and make the fork free software by distributing a preferred form for modifications: the one which you use to maintain the software. This all gets a bit confusing and fuzzy with scripting languages IMO. P.S. Please CC me since I am not on debian-legal list Done. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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
Joey Hess [EMAIL PROTECTED] wrote: I'm repeating this since it was buried in a footnote in a probably pointless subthread. There's no particular reason why a development environment for java or a similar language would need to include whitespace in the source files it saves. The whitespace can be calculated and displayed on the fly in the editor, so why bother writing it to disk? However, the mozilla-foxyproxy author has clearly stated that the above is not the case. The preferred form for modification is kept in a subversion store which is not being distributed and we don't know how to reconstruct it from the source code. Hope that explains, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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
On Tue, 30 Jan 2007, Joey Hess wrote: Don Armstrong wrote: Obviously we should try to figure out if the author was lying or making fun of -legal first, but if it was actually true and debhelper was GPLed, then we can't do anything else. Why? Because it wouldn't be the prefered form for modification as the GPL requires. debhelper is also developed in vim[1], I don't have to ship vim with it, why would I need to ship its preprocessor with it? They are both simply tools that let me develop the software. The fact that I didn't type in every character of debhelper exactly as it appears in the code I distribute to you is irelivant. There is no bright line between a program like vim inserting useful syntatic whitespace as I type[2], and a preprocessor expanding keywords into blocks of code. The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? The answers to those questions tell you what needs to be distributed. The important thing is the code I distribute. The important thing is what you actually modify to distribute what you eventually distribute. The source code compliance in GNU GPL §3 says nothing about the code that was distributed, only about what is the prefered form of the work for making modifications to it. That in both of these cases it's trivial to actually modify the work merely obscures the real problem: the users of the software are second class citizens to the copyright holder. In closing, I'd like you to consider the plight of a machine intelligence who wrote GPLed code and was forced by the act of so licensing it to embed a copy of itself[4] with any code it distributed so that the fleshers weren't second class citisens. A far more practical example is the case of a GPLed movie where in you'd have to include all of the digital files etc. available to the author which aren't available to anyone else. Yes, this is a real problem, and is one reason why the GPL may not always be the most appropriate license. Ignoring the legal aspects though, distributing this information to the maximum extent possible is IMO the best thing to do, because it enables users of the work to exercise as many of the freedoms that the author of the work has and can convey. Don Armstrong -- Where I sleep at night, is this important compared to what I read during the day? What do you think defines me? Where I slept or what I did all day? -- Thomas Van Orden of Van Orden v. Perry http://www.donarmstrong.com http://rzlab.ucr.edu
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
In message [EMAIL PROTECTED], Yaroslav Halchenko [EMAIL PROTECTED] writes I've ran into a problem: given firefox extension released under GPL as shipped (.xpi files) has obscured .js files -- all formatting was removed. I've asked the upstream to provide proper source code, but so far he effectively refused to do that, although it seems to be a very simple operation to perform. For our discussion see http://z9.invisionfree.com/foxyproxy/index.php?showtopic=250 If I understood GPL license correctly, upstream author simply can't release anything under GPL if he doesn't provide sources. Whenever I've asked on mozilla's addons IRC I've got reply as afaik he codes himself, and so if he writes on his page / in the package that it is gpl, you can use it under the gpl license but I think that he/she is incorrect in his/her understanding of GPL. Standard blunders of copyright no 1 LICENCES DON'T APPLY TO AUTHORS (actually, that should read copyright holders, but often they're the same thing). If the upstream author owns the copyright, and he gives you obfuscated source, then there's NOTHING you can do about it. I'd say it's actually even dangerous to de-obfuscate the code! If you want to modify the code, de-obfuscate the bits you need, modify it, and then distribute as per GPL. IANAL, but you should be safe here, as you are distributing the original author's stuff as is, and you are distributing the modified stuff in a preferred form for modification, namely your preferred form because you're one of the people who modified it. It's been mentioned are you complying with the GPL if you distribute obfuscated source?. I'd say yes, because you're distributing it unmodified as per what the original author gave you (I think that's legit as per the GPL - I think it says you can distribute the unmodified source without any further obligation). Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- 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
On Tue, 2007-30-01 at 03:30 -0800, Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? That's not a very good line at all. I don't modify source LZ-compressed, yet that is how I distribute most of my code and how most of the source in Debian is distributed. We're talking about a case where a developer has used a lossy compression algorithm (which I think we all agree is foolish and useless) that can be more-or-less reversed with tools readily available in most programmers' toolset. It's not run through an obfuscator, nor is it object code or virtual machine code, nor is it code generated from a higher-level language. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Thanks everyone for help -- I've got the point now ;-) Well -- I postpone this ITP and will wait for source code release It's been mentioned are you complying with the GPL if you distribute obfuscated source?. I'd say yes, because you're distributing it unmodified as per what the original author gave you (I think that's legit as per the GPL - I think it says you can distribute the unmodified source without any further obligation). -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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
Joey Hess [EMAIL PROTECTED] writes: Consider also a text editor that automatically calculates and displays whitespace, while not bothering to save it to the output files. That is a plausable explanation for the behavior of the upstream author in the head of this thread. For the record, at least one editor really does work like this -- the listener built into the Factor system (http://factorcode.org). Programs are serialized into some sort of binary format that preserves comments, but not whitespace. A pretty-printer is responsible for re-inserting whitespace when rendering source code for human consumption. While the Factor code is itself maintained as conventional text files which are later read into the listener, it is conceivable that one could build and maintain an application entirely interactively (i.e. at the REPL) without ever using a plain-text format that preserved whitespace. You would distribute the application as a core dump, from which the full source code could be extracted programmatically (with whitespace automatically re-inserted by the pretty-printer). You can see output from the pretty printer here: http://factorcode.org/responder/browser/browse?vocab=sequencesword=find* -- Trent Buck, Student Errant -- 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
On Tue, 30 Jan 2007, Evan Prodromou wrote: On Tue, 2007-30-01 at 03:30 -0800, Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? That's not a very good line at all. I don't modify source LZ-compressed, yet that is how I distribute most of my code and how most of the source in Debian is distributed. Since you can transform between the two bidirectionally and the method to convert between LZ compressed forms is publicly available and well documented, they're effectively equivalent. We're talking about a case where a developer has used a lossy compression algorithm (which I think we all agree is foolish and useless) that can be more-or-less reversed with tools readily available in most programmers' toolset. It's not run through an obfuscator, nor is it object code or virtual machine code, nor is it code generated from a higher-level language. I've personally not looked at the code in question at all; I'm merely responding to Joey's message. However,evenremovingthewhitespacefromaprogramcanmakeitsignficantlymoredifficulttodebugandcomprehend,eventhoughitcanbereversedwithtoolsthatarereadilyavailable. Don Armstrong -- CNN/Reuters: News reports have filtered out early this morning that US forces have swooped on an Iraqi Primary School and detained 6th Grade teacher Mohammed Al-Hazar. Sources indicate that, when arrested, Al-Hazar was in possession of a ruler, a protractor, a set square and a calculator. US President George W Bush argued that this was clear and overwhelming evidence that Iraq indeed possessed weapons of maths instruction. http://www.donarmstrong.com http://rzlab.ucr.edu -- 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
This one time, at band camp, Don Armstrong said: However, even removing the white space from a program can make it signficantly more difficult to debug and comprehend, even though it can be reversed with tools that are readily available. I don't think anyone is arguing that this sort of thing should be encouraged. Just pointing out that it doesn't break our ability to redistribute under the GPL. I wouldn't package or maintain such a thing, and I'd prbably look sideways at someone who wants to. But as for license issues? I don't see a problem there. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 30 Jan 2007, Stephen Gran wrote: Just pointing out that it doesn't break our ability to redistribute under the GPL. 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: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, [...] The source code for a work means the preferred form of the work for making modifications to it. [...] If what you're arguing is that the source code with whitespace removed is the prefered form for modification that upstream actually uses, then our premises are different, so the conclusions can of course be different too. [I'm not in a position to argue one way or another which of the premises is correct, and frankly, I'm not sure that it's the right place for -legal to make that determination either. The maintainer and ftpmaster are the ones who need to make this determination IMO.] Don Armstrong -- Certainly the game is rigged. Don't let that stop you. If you don't bet, you can't win. -- Robert Heinlein _Time Enough For Love_ p240 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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
Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? Preferable by whom? That is a matter of personal preference and taste, where I as upstream might vary drastically from the recipients of the code -- or from my own preferences the next day. Personally, my current preferred form for modification of source code is a subversion repository containing the entire history of the code. Without the full history, the code can be hard to understand and work with. That doesn't mean that I get to demand access to the repository or claim that their code doesn't meet my preferences and is thus nonfree. It's very dangerous to take a stance that any code that someone claims has a different preferred form for modification is nondistributable under the GPL. This allows anyone slander upstream and get their code considered unusable. It allows upstreams to lie about their development practives and damage us by forcing us to drop their entrenched code. Far better is to consider the actual code, not statements made about how that code came to be. Is the code understandable? Can the code be modified by others? Is the code truely licensed under a DFSG free license? Then the code is suitable for inclusion in Debian, no matter what statements anyone may make about how the code came into being. -- see shy jo signature.asc Description: Digital signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 30 Jan 2007, Joey Hess wrote: Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? Preferable by whom? The upstream maintainer. Whatever form(s) of the work the upstream maintainer actually uses to modify the work is the prefered form for modification. It's very dangerous to take a stance that any code that someone claims has a different preferred form for modification is nondistributable under the GPL. This allows anyone slander upstream and get their code considered unusable. It doesn't matter what anyone thinks or claims is the prefered form for modification, all that maters is what _is_. I'm (conveniently) ignoring the issue of determining what is actually the prefered form for modification for upstream, becuase it's something that is necessarily heuristic, and not really the domain of -legal to determine. It allows upstreams to lie about their development practives and damage us by forcing us to drop their entrenched code. 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.] Don Armstrong -- We were at a chinese resturant. He was yelling at the waitress because there was a typo in his fortune cookie. -- hugh macleod http://www.gapingvoid.com/batch31.php http://www.donarmstrong.com http://rzlab.ucr.edu -- 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
On Tuesday 30 January 2007 12:48:15 pm Don Armstrong wrote: On Tue, 30 Jan 2007, Joey Hess wrote: Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? Preferable by whom? The upstream maintainer. Whatever form(s) of the work the upstream maintainer actually uses to modify the work is the prefered form for modification. I think that the GPL would have use much more specific language if the author's intent had been to require the form of modification in use by the original author. It doesn't take a law degree to write: The source code for a work means the form of the work used by the original author for making modifications. Since that language was not used, and instead the highly flexible term preferred was used, I suggest the GPL is far more accepting of modifications to the distributed source than is being granted in this conversation. I had always taken the clause to mean that between distributing a JPG or an XCF, that the XCF was preferred because it provided greater quantitative ability to modify the source. Whereas a javascript file with the whitespace striped out it's quantitatively different from a modification standpoint. (There are, of course, various qualitative differences.) -Sean -- Sean Kellogg e: [EMAIL PROTECTED] w: http://blog.probonogeek.org/ So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On 31/01/2007, at 9:48 AM, Don Armstrong wrote: On Tue, 30 Jan 2007, Joey Hess wrote: Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? Preferable by whom? The upstream maintainer. Whatever form(s) of the work the upstream maintainer actually uses to modify the work is the prefered form for modification. Perhaps you could add a wheee every time you mention this here -- it would help to convey the huge leap you're making there. Preferred is subjective, and the subject is *not* specified in the license, and certainly not to be the original author. As someone else mentioned, if they'd meant the form the author uses then surely they'd have said so. Fortunately, they were sufficiently with-it to see the problems that that would cause, and went with the preferred form of the work for making modifications to it. I don't think you're going to be able to come up with a clear answer here, for several reasons. I think the most important is probably going to be that intent matters. In the case of one piece of software, standing alone, it's less important, but when we're talking about interactions between works and license compatibility, it becomes much more interesting. Say A writes a library and releases it under the GPL. B later comes along and, as he's studying computer architecture, decides as a challenge to himself to write a program directly in machine code. It's not intended to be a useful program except as an example of this process. He then releases that under the GPL. C then sees B's program, decides that actually it could be really handy, hacks it around so it now links to A's library, and makes the result available under the GPL (including distributing the library). A sees the result, tells C that he's obviously not releasing source as specified in his license and to stop it. C points out that actually, he is. Do you think that this is acceptable? What about if B cheated at some point and reused some previously assembled code? What about if B had written it in C and then hand-compiled and assembled the code? The extreme is of course that B is $evil_company, had foreseen C's modifications, written the thing in C and not even pretended otherwise. Where's the line? I think you'll find you just have to be reasonable in each case, and hope that everyone else (particularly the court) is too. Cheers, Nick -- 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
Le mardi 30 janvier 2007 à 09:49 -0500, Yaroslav Halchenko a écrit : Thanks everyone for help -- I've got the point now ;-) Well -- I postpone this ITP and will wait for source code release This is your choice, but most people here agreed that you don't need to. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 30 Jan 2007, Sean Kellogg wrote: On Tuesday 30 January 2007 12:48:15 pm Don Armstrong wrote: On Tue, 30 Jan 2007, Joey Hess wrote: Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? Preferable by whom? The upstream maintainer. Whatever form(s) of the work the upstream maintainer actually uses to modify the work is the prefered form for modification. I think that the GPL would have use much more specific language if the author's intent had been to require the form of modification in use by the original author. It doesn't take a law degree to write: The source code for a work means the form of the work used by the original author for making modifications. This actually has other problems, and it's a great thing the license doesn't say this. I've been very careful not to use the words original author because it's quite possible that the prefered form for modification could change over time. Since that language was not used, and instead the highly flexible term preferred was used, I suggest the GPL is far more accepting of modifications to the distributed source than is being granted in this conversation. In retrospect, I can see what I wrote being interpreted like that, but it wasn't what I intended. I really mean upstream in the sense that it's used in Debian packaging, where it means whoever is modifying and distributing modifications that we use and distribute further. If upstream is holding back information from us that they actually use to make modifications, then we aren't distributing the prefered form for modification. I had always taken the clause to mean that between distributing a JPG or an XCF, that the XCF was preferred because it provided greater quantitative ability to modify the source. It's ideal, sure; but if the upstream author doesn't use XCF to modify the JPG, and a XCF never existed, then it isn'tthe prefered form even if editing a JPG is annoying. [I should note that I differ on this interpretation from Eben Moglen and (probably) RMS, as they have argued that commentless sourcecode, even if it is the form that upstream uses isn't the prefered form for modification... but their reasoning has never been satisfactory to me, and more to the point, the least they'd expect is the form that upstream actually uses.] Don Armstrong -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams _Mostly Harmless_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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
Le mardi 30 janvier 2007 à 09:49 -0500, Yaroslav Halchenko a écrit Thanks everyone for help -- I've got the point now ;-) Well -- I postpone this ITP and will wait for source code release This is your choice, but most people here agreed that you don't need to. I just don't want to release it due to unreasonable/worrying refusal to provide source code, which make it harder for anyone to inspect/modify it. And IMHO every tentative Debian package has to go through at least basic inspection by the maintainer for the subject of malware/obvious insecurities, before being shipped as part of Debian. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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
On Tuesday 30 January 2007 13:48, Don Armstrong wrote: The upstream maintainer. Whatever form(s) of the work the upstream maintainer actually uses to modify the work is the prefered form for modification. You keep saying this over and over, but it's just your opinion, not the way the license necessarily must be interpreted. The license doesn't say anything about the form that the *author* prefers. -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpwGMgwUj1MC.pgp Description: PGP signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Don Armstrong [EMAIL PROTECTED] writes: [If the argument is that figuring out whether or not the people is lying is difficult and requires judgement, then I agree. I've been trying to ignore that facet completely because it's not particularly interesting to me. Please play along and ignore it too! ;-)] More importantly, figuring out whether someone is lying isn't something to be solved by a legal interpretation of a software license. -- \ When I get real bored, I like to drive downtown and get a | `\ great parking spot, then sit in my car and count how many | _o__) people ask me if I'm leaving. -- Steven Wright | Ben Finney -- 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
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. I think we'd all be pretty comfortable with some other transforms, like \r\n - \n line ending conversion or character set changes. I think that, instead of hewing to the line that any transforms on the code are unacceptable -- clearly unsupportable -- we should probably deal with this particular case and whether this particular transform is acceptable. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Yaroslav Halchenko writes: I've ran into a problem: given firefox extension released under GPL as shipped (.xpi files) has obscured .js files -- all formatting was removed. I've asked the upstream to provide proper source code, but so far he effectively refused to do that, although it seems to be a very simple operation to perform. For our discussion see http://z9.invisionfree.com/foxyproxy/index.php?showtopic=250 If I understood GPL license correctly, upstream author simply can't release anything under GPL if he doesn't provide sources. Whenever I've asked on mozilla's addons IRC I've got reply as afaik he codes himself, and so if he writes on his page / in the package that it is gpl, you can use it under the gpl license but I think that he/she is incorrect in his/her understanding of GPL. Could anyone correct/confirm me? Is there anything I could do to gently force upstream to either provide the sources or rerelease his probably-full-of-spyware software under some non-FOSS license, so I don't even bother thinking about packaging/using it? ;-) A copyright owner can distribute his software under a license that is impossible to fulfill. The problem -- especially with copyleft -- is when anyone else wants to exercise the rights that the license is supposed to grant. Courts would have to interpret how the license should be construed when the copyright owners' terms are impossible to satisfy. The safe thing is to not distribute or modify any work like that. Michael Poole -- 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
On Mon, 2007-29-01 at 14:06 -0500, Yaroslav Halchenko wrote: I've ran into a problem: given firefox extension released under GPL as shipped (.xpi files) has obscured .js files -- all formatting was removed. So, if I read your comments correctly, the .js files aren't intentionally obfuscated. Whitespace has just been removed in order to speed up download. It may be misguided, but it's also pretty common among JavaScript programmers. I was able to run the JavaScript code through GNU indent (http://www.gnu.org/software/indent/ ) and get readable and modifiable output. I think there are some special-purpose JavaScript beautifiers out there that could give even better formatting. I don't think that this is a case where the user gets unmodifiable source. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Mon, Jan 29, 2007 at 04:25:56PM -0500, Evan Prodromou [EMAIL PROTECTED] wrote: On Mon, 2007-29-01 at 14:06 -0500, Yaroslav Halchenko wrote: I've ran into a problem: given firefox extension released under GPL as shipped (.xpi files) has obscured .js files -- all formatting was removed. So, if I read your comments correctly, the .js files aren't intentionally obfuscated. Whitespace has just been removed in order to speed up download. It may be misguided, but it's also pretty common among JavaScript programmers. Except the javascript file is zipped in a .xpi file, making the space removing argument moot. I was able to run the JavaScript code through GNU indent (http://www.gnu.org/software/indent/ ) and get readable and modifiable output. I think there are some special-purpose JavaScript beautifiers out there that could give even better formatting. I don't think that this is a case where the user gets unmodifiable source. However, the GPL requires the prefered form for modification to be provided. And what the author uses to modify is definitely not the whitespace-free version. Mike -- 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
This one time, at band camp, Mike Hommey said: I was able to run the JavaScript code through GNU indent (http://www.gnu.org/software/indent/ ) and get readable and modifiable output. I think there are some special-purpose JavaScript beautifiers out there that could give even better formatting. I don't think that this is a case where the user gets unmodifiable source. However, the GPL requires the prefered form for modification to be provided. And what the author uses to modify is definitely not the whitespace-free version. Given that the only difference between the version you see and the version the author modifies is whitespace, I don't think there's a real 'freedom' issue. It might be nice if the author built this into the build system so it was something you didn't have to worry about this, but I really don't see this as a violation of the preferred form for modification clause, sorry. I've always read that as being intended for people that want to ship only an .o or other intermediate, compiled version of the program. In this case, you have a pretty lossless converter. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
So, if I read your comments correctly, the .js files aren't intentionally obfuscated. Whitespace has just been removed in order to speed up download. It may be misguided, but it's also pretty common among JavaScript programmers. Except the javascript file is zipped in a .xpi file, making the space removing argument moot. That is exactly what I thought and stated in our discussion with the author on the support forum. .xpi is compressed, then chrome file is shipped within .jar which is also zip compressed. I don't think that spaces is of any concern for the size. They might contribute to few %s of the size. Also VC available from mozilla.org [1] got only space-stripped versions of the code -- no originals as well... I was able to run the JavaScript code through GNU indent (http://www.gnu.org/software/indent/ ) and get readable and modifiable I've done that (with astyle) but it still was really hard to comprehend the source. I don't think that this is a case where the user gets unmodifiable source. However, the GPL requires the prefered form for modification to be provided. And what the author uses to modify is definitely not the whitespace-free version. seconded. For now I just tagged ITP bug with wontfix and provided a description why not... [1] http://www.mozdev.org/source/browse/foxyproxy/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Mike Hommey said: However, the GPL requires the prefered form for modification to be provided. And what the author uses to modify is definitely not the whitespace-free version. Given that the only difference between the version you see and the version the author modifies is whitespace, I don't think there's a real 'freedom' issue. We know of *one* difference between what the author modifies and what is distributed as source. I don't necessarily believe that's the only difference. There could be additional differences, e.g. stripping comments, that are impossible to restore. The point is that the recipient isn't getting the preferred form of the work for making modifications to it and can't therefore fulfil the terms of the GPL when distributing the work. -- \ It's a good thing we have gravity or else when birds died | `\ they'd just stay right up there. Hunters would be all | _o__) confused. -- Steven Wright | Ben Finney -- 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
Mike Hommey wrote: However, the GPL requires the prefered form for modification to be provided. And what the author uses to modify is definitely not the whitespace-free version. The same could be true of any secret modifications to any program made by its upstream author. Perhaps the debhelper that I actually develop is written in a very high level language or templating system that compiles it down to the dh_* files that you get in the source package. They do all look somewhat similar, don't they? If I made such a claim, would you consider that debhelper needs to be removed from Debian now? -- see shy jo signature.asc Description: Digital signature
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 2007-30-01 at 08:59 +1100, Ben Finney wrote: The point is that the recipient isn't getting the preferred form of the work for making modifications to it and can't therefore fulfil the terms of the GPL when distributing the work. It's obvious that some transformations are acceptable for distributing source code. I assume that lossless compression like zip or gzip is OK, right? As well as conversion of character codes (ASCII - Unicode)? DOS line endings to Mac- or Unix-style line endings? I know that stripping whitespace from the source code is a step beyond this -- it _is_ lossy -- but it's not _too_ far off. The re-indented code isn't fun to edit, but it's definitely possible to do. I think if someone was being extra-careful, they'd avoid re-distributing, but if it were me I'd avoid loaded statements like no true source or accusations that upstream was distributing spyware. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Mon, 29 Jan 2007, Joey Hess wrote: The same could be true of any secret modifications to any program made by its upstream author. They'd have to be publicly knowable, though, so secret modifications don't really work. Perhaps the debhelper that I actually develop is written in a very high level language or templating system that compiles it down to the dh_* files that you get in the source package. They do all look somewhat similar, don't they? If I made such a claim, would you consider that debhelper needs to be removed from Debian now? Obviously we should try to figure out if the author was lying or making fun of -legal first, but if it was actually true and debhelper was GPLed, then we can't do anything else.[1] Debian should distribute the (digitally distributable) form of the work that the author actually uses to modify the work. We *must* do so in the case of GPLed works. That in both of these cases it's trivial to actually modify the work merely obscures the real problem: the users of the software are second class citizens to the copyright holder. Don Armstrong 1: I know it may be annoying, but it is what the letter of the GPL requires, and definetly what its spirit asks for. -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. -- Craig Dickson in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
