Re:
Michael K. Edwards [EMAIL PROTECTED] writes: Um, it is true that the rules for interpreting the meaning of licenses are more or less the same as the rules for interpreting contracts. It does not follow that licenses are therefore contracts. The words license and contract are indeed not synonymous under law. But the law applicable to offers of contract containing grants of license is contract law (or the equivalent codes in civil law systems). You're speaking too vaguely. The law applicable to offers of contract is of course contract law. It does not follow that the GPL is thus an offer of contract. Indeed, it explicitly disclaims any such intention itself. It would be a curious offer of contract indeed that labelled itself not an offer of contract. Huh? What about the license as just what it purports to be: a license? You're a little bit late to the party. Check the debian-legal archives for debate and case law out the yin-yang. There's no such thing as a copyright-based license. I didn't call it a copyright-based license. I said it's a license. There is a thing you are not considering: it is a unilateral grant of conditional permission. This is a perfectly well-traveled area of law. Also part of contract law; and not applicable to the GPL, which does not lack for acceptance or consideration. Thread at http://lists.debian.org/debian-legal/2004/12/msg00209.html . I don't care what is part of contract law. I care if the GPL has the legal status of a contract. You keep discussing *other* questions instead of that one. The GPL is a unilateral grant of permission, a concept which is independent of contract (whether you lump it together with contracts, in one thing called contract law is irrelevant to me). A unilateral grant of permission lacks the features of contract, but is still a perfectly real thing. Estoppel (which you have noted) indeed attaches upon such grants of permission: having granted me permission to enter your land, you cannot then sue me for (say) trespass. If your grant of permission to enter your land was simply a unilateral grant, it is not a contract, it is a grant of permission. It is also binding on you: having granted me permission, you cannot then sue me for trespass when I take you up on it. Now a grant of permission can be revoked, which is a different question. If the FSF turned nasty, could they revoke the permission? The question here is likely one of reliance. If I have relied on a future-tense permission (perhaps if you told me you may enter my land forever) then to the extent of my reliance, you can't sue me for trespass. The bindingness of such things is tricky, and nobody knows how far it goes if the FSF actually attempted to revoke the permissions given. Indeed, for this reason the FSF acquires copyright through a contract with authors such that the authors retain permanently the right to distribute their work under any terms they like, and in which the FSF is contractually bound to distribute only under free software licenses. In this way, the FSF can assure authors and the world that its hands are tied and one need not worry about such a revocation of permission. (This is relevant, because a legal judgment against the FSF could result in its assets being transferred to some nasty person.) But the point is really almost irrelevant. If the GPL is actually a contract and not a grant of permission, then what follows? If you have agreed to the contract, it's binding, and that's that. If you have not, then there is no arrangement under which you are permitted to distribute the software, and so you can be sued for copyright violation by the FSF. Since this is exactly the state of affairs which the grant-of-permission argument claims would obtain, what is the practical difference? Indeed, reduction to practice is the point. If the GPL successfully achieves its ends, then it works. And it does, in fact, achieve them. On numerous occasions the GPL has shown that it is a powerful instrument for insuring compliance with its provisions as they were intended, even upon reluctant or recalcitrant redistributors. And finally, for Debian's purposes, it's even more irrelevant. Our standing policy is that if there is doubt about the force or intention of a license, we err on the side of simply doing what the licensor demands. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re:
Michael K. Edwards [EMAIL PROTECTED] writes: At this point, there seem to be quite a few people who agree that the FSF's stance (copyright-based license) and the far-from-novel one that you advance (unilateral license / donee beneficiaries) are untenable in the jurisdictions with whose law they are to some degree familiar. You are choosing to post on three different forums. Having made that choice, it is your obligation to make your comments relevant to them all; you cannot post on debian-devel, and then insist that your interlocutors there read a different list. Please don't put words into my mouth. The quotes you give are not my words; I have not spoken of a unilateral license / donee beneficiaries, though you words suggest I have. You have not explained here (on debian-devel, that is) at all why we should disgregard the actual success of the license in convincing reluctant people to comply with its provisions. Indeed, to date there is nobody who is willing to risk a lawsuit due to noncompliance with the GPL when the FSF's compliance folks have come after them. This in itself suggests very strongly that those who have money to lose on the question think the GPL is binding And you haven't answered my question. Please explain how the difference in legal theory here affects the bindingness of the GPL on those who choose to distribute GPLd software. And finally, for Debian's purposes, it's even more irrelevant. Our standing policy is that if there is doubt about the force or intention of a license, we err on the side of simply doing what the licensor demands. Which is great, until you find yourself estopped from arguing otherwise in a courtroom. It matters both what you do and why you say you do it. Please be specific. Where are we hurting ourselves? (Or, if we are not, then why is this relevant?) Thomas P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re:
On Thu, May 19, 2005 at 11:39:21PM -0700, Michael K. Edwards wrote: On 5/19/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: [snip arguments that might have been worthy of rebuttal on debian-legal five months ago] I'm not trying to be snotty about this, but if you want to engage in the debate about the proper legal framework in which to understand the GPL, I think you would do best to at least dip into recent debian-legal archives and also look at some of the precedents cited back in December and January. At this point, there seem to be quite a few people who agree that the FSF's stance (copyright-based license) and the far-from-novel one that you advance (unilateral license / donee beneficiaries) are untenable in the jurisdictions with whose law they are to some degree familiar. So? Then they should take it up with their local legislative body and/or the FSF. Debian doesn't have a duty to account for every individual broken jurisdiction on the planet. The legal questions surrounding Waste are much more likely to center on whether the people acting at Nullsoft actually had the legal authority to offer people a license to the code at issue. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re:
On 5/19/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Michael K. Edwards [EMAIL PROTECTED] writes: At this point, there seem to be quite a few people who agree that the FSF's stance (copyright-based license) and the far-from-novel one that you advance (unilateral license / donee beneficiaries) are untenable in the jurisdictions with whose law they are to some degree familiar. You are choosing to post on three different forums. Having made that choice, it is your obligation to make your comments relevant to them all; you cannot post on debian-devel, and then insist that your interlocutors there read a different list. Oh, nuts. I didn't realize this thread was still copied to hell and gone. I'll try to summarize briefly, and would the next person please cut d-d and waste-public off if appropriate? Please don't put words into my mouth. The quotes you give are not my words; I have not spoken of a unilateral license / donee beneficiaries, though you words suggest I have. Sorry about that; I skipped a step or two. Your unilateral grant of permission is not in fact a recognized mechanism under law for the conveyance of a non-exclusive copyright license. In common law systems, the mechanism that does exist is called a contract. :-) This horse has been beaten to a pulp on debian-legal, and I think even my esteemed fencing parter Raul is approaching convinced; if you want one case law citation on the topic, try Effects Associates v. Cohen from the Ninth Circuit. Apparently quite firmly established in various civil law systems as well. (IANALIAJ.) There is such a thing as a unilateral contract, also sometimes called a defective contract, which can't be held to its full ostensible extent against the drafter by donee beneficiaries for lack of evidence of acceptance and/or return consideration. That doesn't apply in the case of the GPL; acceptance through conduct is quite sufficient, and the various obligations accepted by the licensee (especially the offer of source code) are in fact return consideration, not a limitation on the scope of license. Specht v. Netscape is sometimes cited as an obstacle to finding acceptance of a browse-wrap license. But it doesn't even contain the word copyright, and boils down to this analogy (quoted from the opinion): From the user's vantage point, SmartDownload could be analogized to a free neighborhood newspaper, readily obtained from a sidewalk box or supermarket counter without any exchange with a seller or vender. As I wrote in the thread I cited, picking up a free newspaper doesn't grant you copyright license on its contents. A better parallel may be found in Jacob Maxwell v. Veeck, in which the court used evidence of an oral exclusive license agreement to construe a non-exclusive copyright license and then applied contract law to establish whether and when it was terminated. Oral evidence of intent to offer an exclusive license -- something that by law must be in writing -- is hardly less valid an offer of contract than a document whose drafter professes to believe ought to be interpreted under some other legal theory. As for consideration, see Fosson v. Palace Waterland and the cases involving the GPL itself that have been discussed ad nauseam on d-l. These and other equines are nearing a blenderized condition on d-l, whether or not a consensus comes out of it. I am omitting the rest of the mountain of case law that has been cited there; persons who wish pointers to specific topics within that discussion are welcome to ask there, but let's spare d-d. You have not explained here (on debian-devel, that is) at all why we should disgregard the actual success of the license in convincing reluctant people to comply with its provisions. Indeed, to date there is nobody who is willing to risk a lawsuit due to noncompliance with the GPL when the FSF's compliance folks have come after them. This in itself suggests very strongly that those who have money to lose on the question think the GPL is binding And you haven't answered my question. Please explain how the difference in legal theory here affects the bindingness of the GPL on those who choose to distribute GPLd software. There's no question in my mind that the GPL is binding, i. e., a valid offer of contract that licenses various rights to a given work. There are some grounds to worry that Section 6 is hard to implement in at least some jurisdictions, for reasons having to do with the doctrine of agency and how strong a form of agreement is needed in order to construe agency to sub-license; but that's unlikely ever to be litigated, and if it is we can hope that an appeals court can find a way around it. There's also no question that the GPL is enforceable (and has been successfully enforced by Harald Welte in Deutschland) using a breach of contract theory against people who don't release source code to GPL works when they modify and distribute them. But applying
License question about regexplorer
I have been recently checking out packages up for adoption or already orphaned. In the process I came across regexplorer [0]. Here are the dependencies of regexplorer and their respective licenses (as I understand it): * libc6 (LGPL) * libgcc1 (GPL w/ exception) * libqt3c102-mt (QPL/GPL) * libstdc++5 (GPL) * libx11-6 (MIT/X) * libxext6 (MIT/X) My question is this. Is Debian accepting QT3 under the GPL or the QPL? According the FSF FAQ on licenses [1], the QPL says that modified sources must be distrubted as patches, and that linking to GPL code requires a license exception. However, it gets a bit more complex. I know that this has more or less been discussed before [2], but I think the circumstances have changed. Specifically: (1) is the exception for libgcc1 sufficient for regexplorer to link? (2) is QT3 in Debian via QPL or GPL? (3) is libstdc++5 actually GPL w/o exception? It seems that if any of those fails, then regexplorer can't link to them unless it is relicensed. Additionally, it seems like QPL licensed code can't be in main (which may or may not affect QT and any packages that depend on it, depending on how Debian chooses to make QT available), at least under the version used by regexplorer [3] [4]: QPL: 3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications: ME: Ok. This is not reall a problem, since we distribute source as a .orig.tar.gz and a .diff.gz. This is clearly seperate. QPL: a. Modifications must not alter or remove any copyright notices in the Software. ME: No problem here either. QPL: b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. ME: Does this mean that the Debian-specific packaging must be QPL licensed? It is a patch modification to the source. I presume that non-exclusive means Debian can continue to distribute the modifications themselves under other terms, e.g., the GPL. But, I think this implies the modifications must at least be dual/licensed. QPL: 4. You may distribute machine-executable forms of the Software or machine-executable forms of modified versions of the Software, provided that you meet these restrictions: ME: Ok. At least there is a chance to distribute the modified binaries. QPL: a. You must include this license document in the distribution. ME: No sweat. QPL: b. You must ensure that all recipients of the machine-executable forms are also able to receive the complete machine-readable source code to the distributed Software, including all modifications, without any charge beyond the costs of data transfer, and place prominent notices in the distribution explaining this. ME: Does this even comply with DFSG? This would imply that if make a CD which includes regexplorer (which is in main), then I can't charge money for it above the cost of duplication. QPL: c. You must ensure that all modifications included in the machine-executable forms are available under the terms of this license. ME: Not sure how that affects Debian's distribution of the package. Sorry if this has already been discussed, but I am trying to wrap my head around this. Also, please CC me on all replies, as I am not subcribed to -legal. -Roberto [0] http://pacakges.debian.org/regexplorer [1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses [2] http://lists.debian.org/debian-legal/2000/01/msg00203.html [3] http://cvs.sourceforge.net/viewcvs.py/*checkout*/regexplorer/regexplorer/QPL.html?rev=1.1.1.1 [4] http://packages.debian.org/changelogs/pool/main/r/regexplorer/regexplorer_0.1.6-12/regexplorer.copyright -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re:
Michael K. Edwards [EMAIL PROTECTED] writes: Sorry about that; I skipped a step or two. Your unilateral grant of permission is not in fact a recognized mechanism under law for the conveyance of a non-exclusive copyright license. I'm sorry, can you point me to the statute here? The US statute simply prohibits copying without permission. It says nothing about how permission is granted. Can you point me to a court case which said that grant of permission is not contractual, and therefore no permission has been granted? We aren't concerned with a browsewrap or shrinkwrap license; all the cases you point to are about that. Those are about licenses which attempt to take away rights that a person would have had if they had never agreed to the license. Since the GPL only gives you new rights, never taking away any, it's not clear how objections to those kinds of licenses would matter. There's also no question that the GPL is enforceable (and has been successfully enforced by Harald Welte in Deutschland) using a breach of contract theory against people who don't release source code to GPL works when they modify and distribute them. But applying contract law standards of construction against the offeror, notice and cure of breach, grounds for preliminary injunction, and all that -- together with a correct reading of phrases like derivative work under copyright law and mere aggregation -- results in a GPL whose utility as a club against the Wicked Linker is greatly weakened and possibly (IANALIAJ) zero. Which is, in my personal view, as it should be. I see, so this is what you're claiming. Since the proponents of the unilateral-grant-of-permission theory completely agree that contract law is the normal rule for the interpretation of such documents, there isn't any debate there. If you only reason for invoking contract law is to say the license must be interpreted in accord with the standards of contract construction, there is already broad agreement about that point. There's a world of difference between we can't link Quagga against an OpenSSL-enabled NetSNMP because it's illegal; whoops, we already did so (and a thousand similar things), which means we have to beg the FSF to un-automatically-terminate all of our GPL rights and as a matter of courtesy to the FSF, we usually make a reasonable effort to obtain OpenSSL 'exemption riders' where their FAQ recommends them, irrespective of whether the assertions in their FAQ and related statements are legally valid. Yes, and we can simply make neither statement, but ask for the rider, make no statements to the FSF about whether our past actions were right or wrong, and if the rider is not granted, stop distributing (which we would do anyway). So this is a tempest in a silly teapot. I'm happy to leave the thread here, since the upshot is a no-relevance-to-important-issues. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
* Arnoud Engelfriet [EMAIL PROTECTED] [050519 19:52]: Moral rights only allow you to act against mutilation of the work and lack of proper attribution. And you have the right to decide on _first_ publication. But once you publish, the work is on the market and your rights are exhausted. I don't see a basis for doing a recall. INAL, but German law also has some revocation paragraphs: The German copyright laws, called something line author rights law Urheberrechtsgesetz (e.g. http://www.netlaw.de/gesetze/urhg.htm) has paragraphs about revocation: §41 Rückrufsrecht wegen Nichtausübung which could be translated to revocation right because of non-use, which is quite uninteresting. It mainly allows to terminate rights when you give exclusive rights and the person makes no use of it. §42 Rückrufsrecht wegen gewandelter Überzeugung This could be translated as revocation right because of changed opinion/belief. For free software it is not very applicaple in my eyes, as the law mandates in that case: - the author has to compensate adaquately - the revocation is not active before compensation is payed. - the licensee has three months to name the amount of compensation - if the work is to be used again, the former licensee has to be offered equivalent rights under fair conditions. So this seems to be mainly for things like pictures or other art the artist wished he never made. Compensating every user, even if only the costs for downloading are compensated, would be far to expensive. Also note that as far as I was explained, the author is always the person who made it. Author's rights are not refereable. The nearest equivalent of copyright transference are exclusive licenses. And as these morale rights are considered part of human rights, they are not transferable and not bounding contracts about their use can be made. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Get latest version, cds and download under $99
OS-Adobe-Macromedia etc All under $15-$99 CDS http://phnmp.elithdwpb6w3bxw.quotajquot9.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re:
On 5/20/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Michael K. Edwards [EMAIL PROTECTED] writes: Sorry about that; I skipped a step or two. Your unilateral grant of permission is not in fact a recognized mechanism under law for the conveyance of a non-exclusive copyright license. I'm sorry, can you point me to the statute here? The US statute simply prohibits copying without permission. It says nothing about how permission is granted. Can you point me to a court case which said that grant of permission is not contractual, and therefore no permission has been granted? You might read the Jacob Maxwell v. Veeck case, in which the defendant argued exactly that (because by law an exclusive license must be a written contract). The court agreed that federal law didn't permit the finding of an exclusive license under the circumstances, discussed exactly what a non-exclusive license is, and proceeded to construe and interpret one under the applicable state contract law. Honest to Murgatroyd, copyright (and patent, etc.) licenses are [terms in] contracts is a principle that long predates modern copyright statutes and you're not going to find any counter-examples. We aren't concerned with a browsewrap or shrinkwrap license; all the cases you point to are about that. Those are about licenses which attempt to take away rights that a person would have had if they had never agreed to the license. Since the GPL only gives you new rights, never taking away any, it's not clear how objections to those kinds of licenses would matter. That argument simply doesn't hold water. Covenants to offer source code in this and such a way are not scope of license, they're return consideration. The GPL is a true offer of bilateral contract. And yes, I've read lots of unfounded assertions from the FSF and others on the subject, and this and other arguments have been made with a reasonable degree of skill on debian-legal, and I see no reason to repeat them on d-d. There's also no question that the GPL is enforceable (and has been successfully enforced by Harald Welte in Deutschland) using a breach of contract theory against people who don't release source code to GPL works when they modify and distribute them. But applying contract law standards of construction against the offeror, notice and cure of breach, grounds for preliminary injunction, and all that -- together with a correct reading of phrases like derivative work under copyright law and mere aggregation -- results in a GPL whose utility as a club against the Wicked Linker is greatly weakened and possibly (IANALIAJ) zero. Which is, in my personal view, as it should be. I see, so this is what you're claiming. Since the proponents of the unilateral-grant-of-permission theory completely agree that contract law is the normal rule for the interpretation of such documents, there isn't any debate there. If you only reason for invoking contract law is to say the license must be interpreted in accord with the standards of contract construction, there is already broad agreement about that point. Not from the copyright-based license crowd, who would have you believe that contract law standards don't apply and the GPL has a fast path to preliminary injunction under copyright infringement standards. It is, however, a blenderized equine on d-l, so there's no particular need to continue it here. There's a world of difference between we can't link Quagga against an OpenSSL-enabled NetSNMP because it's illegal; whoops, we already did so (and a thousand similar things), which means we have to beg the FSF to un-automatically-terminate all of our GPL rights and as a matter of courtesy to the FSF, we usually make a reasonable effort to obtain OpenSSL 'exemption riders' where their FAQ recommends them, irrespective of whether the assertions in their FAQ and related statements are legally valid. Yes, and we can simply make neither statement, but ask for the rider, make no statements to the FSF about whether our past actions were right or wrong, and if the rider is not granted, stop distributing (which we would do anyway). So this is a tempest in a silly teapot. I'm happy to leave the thread here, since the upshot is a no-relevance-to-important-issues. Fair enough; although you may find that not everyone agrees that stop distributing is the right answer when we are talking dynamic linking across one or more package boundaries. Especially when the FSF is not the sole copyright holder on the GPL'ed upstream, as in the case of Quagga (now under discussion on d-l). Cheers, - Michael
Re:
Michael K. Edwards [EMAIL PROTECTED] writes: [a lot of repetition that pretty much ignores what I said, and especially where I said:] So this is a tempest in a silly teapot. I'm happy to leave the thread here, since the upshot is a no-relevance-to-important-issues. So, since you ignored that last sentence, please re-read it. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
On 5/19/05, Adam McKenna [EMAIL PROTECTED] wrote: On Thu, May 19, 2005 at 07:38:18PM -0400, Raul Miller wrote: Which can occur if anyone redistributes any of the I_WANT_OPENSSL debian packages. According to you. If, for the sake of argument, we assume that such binaries are undistributable, Debian is still not affected, since we aren't contributing to their distribution, only their creation. In some senses you're right. The README.Debian clearly documents how to use this in conjunction with apt-get -b source -- and this probably does count as contributing towards their creation. But is the distinction between contributing to their creation and contributing towards their distribution a strong distinction? After all, we've provided a number of other rather strong contributions towards distribution in general -- it might be hard to argue that those contributions are irrelevant here. On the other hand, if the copyright holder supplied the I_WANT_OPENSSL option, then that copyright holder probably can't hold us in violation of the license. Only if code has been incorporated from other projects would this seem to be a serious problem. Basically, I think that the violation has to be downstream from someone who has significant copyright for it to be a serious issue. Thanks, -- Raul
Re: RES: What makes software copyrightable anyway?
Raul Miller wrote: But we're doing more than distributing the tarball. The tarballs we're distributing have been modified so that the user need only type a couple commands, and (using software we've provided) the binaries are reconstituted on their machine. So what? First off, the GPL gives us permission --- under section 2 --- to make and distribute that tarball. The user has permission to run those several commands under GPL 0. The only thing that the user doesn't have permission to do is distribute the resulting binary. The end result is that we have taken steps to make the binaries appear on the user's machine, so we have some responsibility for that result. While that may be the end result, we have not distributed that binary, which is the only relevant thing the GPL doesn't let us do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
On 5/20/05, Raul Miller [EMAIL PROTECTED] wrote: On 5/20/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 5/19/05, Raul Miller [EMAIL PROTECTED] wrote: But the ambiguities have to be valid ambiguities. That's where we seem to differ on this issue. I think there is little question that the work based on the Program definition + erroneous paraphrase in Section 0 is either: 1) a valid ambiguity (to be construed against the offeror on the licensee's request), or 2) unambiguously readable only as derivative work under copyright law, because the paraphrase is so weakly attached as to be an implausible candidate for a definition even if the licensee wanted it that way. Perhaps you would now agree to this either/or, without any implications for whether my reading of the phrase derivative work under copyright law is correct? I'm going to tackle this in two pieces. First I'm going to critique your presentation, then I'm going to try to tackle the issues I think you're raising. Be warned that I may have misunderstood you. The paragraph I wrote was somewhat cryptic, and I think you did misunderstand a little. Once more unto the breach: Stipulate, for the moment, that either the Program or any derivative work under copyright law (candidate E) and a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language (candidate C) are not obviously equivalent. Under contract law, it is necessary to construe a single definition for the clearly delimited phrase work based on the Program -- a phrase with no a priori legal meaning -- out of the text of section 0 as written, along with any other evidence that may be demonstrated to reflect a binding intention on the licensee's part. This construction must, as a matter of (common law) principle, be done against the offeror -- i. e., by choosing, from among the plausible readings of the text, the one least favorable to the offeror's position in the case at hand. Personally, I think that candidate C is so weakly attached grammatically as to be not plausible as a replacement for the definition given by candidate E. But suppose one were to call this a significant ambiguity in the text. At this point, and only at this point, do we need to bring in the actual meaning of derivative work under copyright law, as discussed elsewhere. As I read it, candidate E is still the correct construction. That's because it is less favorable to the offeror, as it draws narrower bounds on which works based on the Program have to be offered entirely on GPL terms. In this construction, the licensee does need to provide a theory under which the he is granted permission to create and distribute collections (with or without a selection criterion that raises them to the level of collective works) that contain a work based on the Program; this is addressed below. Is that better? Presentation: Logically, you seem to have assumed that the clause in question is erroneous, and you draw conclusions from this assumption. In other words, but your conclusions seem to be don't seem to add much to your initial assumption. I was attempting to use the phrase erroneous paraphrase just as a name for candidate C above. As stated more clearly above, the notion that it is erroneous doesn't enter into the logic until you try to resolve the ambiguity against the offeror. Issues: As near as I can tell, section 0 of the GPL establishes what is being licensed by the GPL. To my knowledge, no works which are not explicitly recognized in section 0 are being licensed. Section 0 also seems to establish the scope of the license -- which is something you've expressed strong interest in. Other sections which grant permissions explicitly do so under the terms of this license which includes section 0, or under the terms of section 1 (which refers to the Program of section 0), or of section 2 (which must be under the terms of section 1). The question being asked in scope of license analysis is, what rights reserved to the copyright holder, as defined in 17 USC, are being made available for exercise by the licensee, whatever the return consideration may be? In the case of the GPL, the licensed rights include copying and distributing the Program itself; modifying, adapting, translating or otherwise creating a work based on the Program, and copying and distributing the result; and aggregating a work based on the Program with other material and copying and distributing the result. In another license, the scope might be as narrow as translate alternate pages into French and German and publish the result on Post-It (TM) Notes; but as long as you pet a cat on alternate Tuesdays isn't part of the scope of license even if it's the first clause in the agreement text. As long as you [do anything] is contract law stuff, even if [do anything] logically requires exercise of the rights under copyright that are being
Re: RES: What makes software copyrightable anyway?
Raul Miller wrote: Which can occur if anyone redistributes any of the I_WANT_OPENSSL debian packages. No, most likely even that would be fine. Since Debian packages are intended to be used with Debian, and Debian ships OpenSSL, third parties get to use the GPL's exception for things distributed with the operating system. [Debian, of course, can't use this because it doesn't apply if the binary is distributed with those things]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
Michael K. Edwards wrote: But note that in principle the creation of derivative works can be infringement even if they are not distributed, and I haven't dug through case law to see exactly how far 17 USC 117 can be stretched from run-time use to local builds. Thankfully, you need not do so; GPL (2) give permission to make derivative works. As long as you don't distribute or publish the work (which is the case here), you need only (1) make notes on files you modified; (2) the thing with spewing the GPL notice for interactive programs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Keeping debate in its place so we can actually reach resolution [Was: Re: ]
On Fri, 20 May 2005, Michael K. Edwards wrote: On 5/19/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: You are choosing to post on three different forums. Having made that choice, it is your obligation to make your comments relevant to them all; you cannot post on debian-devel, and then insist that your interlocutors there read a different list. Oh, nuts. I didn't realize this thread was still copied to hell and gone. I'll try to summarize briefly, and would the next person please cut d-d and waste-public off if appropriate? Can we please try to hold most of these discussions primarily in -legal? Once we have actually figured out what the primary issue is, and understood the ramifications of it, only then should we present a cogent, clear analysis of what the actual issue is to upstream, so that they can actually deal with it appropriately. Otherwise, all we're doing is burying upstream (and frankly, -devel) under a deluge of material that they could care less about, and hurting our chances of eventually resolving the issue (whatever it is) appropriately. [Finally, as a major nitpick: Please, please, please, Set a useful Topic:. Otherwise it becomes quite impossible to return to these threads at any point in the future. Topicless threads are almost as bad as threads with a wrong topic.] Don Armstrong -- For those who understand, no explanation is necessary. For those who do not, none is possible. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
Raul Miller wrote: That works only if they don't distribute libssl with it. Sure. Same as for Debian. If you distributing software, open source or not, you need to read and follow the license. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
On 5/20/05, Anthony DeRobertis [EMAIL PROTECTED] wrote: GPL 1, 2, and 3 apply to distributions in object or executable form. GPL 1 and 2 apply to distributions in source code form. The GPL has *clearly* and *intentionally* placed additional restrictions (given in section 3) on binary distribution. Sure. But distribution and bits on the wire aren't equivalent. That is why whether we distribute in source or object for matters, because the FSF made it so when they drafted the GPL. This is not some trivial technical workaround trying to exploit a arcane loophole in the license; it is a difference that --- judging from the license, the preamble, and the position statements on fsf.org --- the FSF considers extremely important. BTW: Most piece of modern, open-source software I've seen comes with a few simple commands to build and install a binary; they typically are ./configure; make or just make. Are you arguing they are effectively distributing a binary, too? As a general rule, those commands don't go figuring out where to get the sources and download them for you. Nor are they specially documented in the distributor's notes on the package. Anyways, as long as the I_WANT_OPENSSL is something that's considered valid all the way upstream for all the GPLed code, I don't think this is a problem -- it's just yet another case of someone not licesning things the way they wanted to license them. -- Raul
Re: RES: What makes software copyrightable anyway?
On 5/20/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Stipulate, for the moment, that either the Program or any derivative work under copyright law (candidate E) and a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language (candidate C) are not obviously equivalent. Ok. Under contract law, it is necessary to construe a single definition for the clearly delimited phrase work based on the Program -- a phrase with no a priori legal meaning -- out of the text of section 0 as written, along with any other evidence that may be demonstrated to reflect a binding intention on the licensee's part. This construction must, as a matter of (common law) principle, be done against the offeror -- i. e., by choosing, from among the plausible readings of the text, the one least favorable to the offeror's position in the case at hand. Ok. Personally, I think that candidate C is so weakly attached grammatically as to be not plausible as a replacement for the definition given by candidate E. But suppose one were to call this a significant ambiguity in the text. Ok. At this point, and only at this point, do we need to bring in the actual meaning of derivative work under copyright law, as discussed elsewhere. As I read it, candidate E is still the correct construction. That's because it is less favorable to the offeror, as it draws narrower bounds on which works based on the Program have to be offered entirely on GPL terms. In this construction, the licensee does need to provide a theory under which the he is granted permission to create and distribute collections (with or without a selection criterion that raises them to the level of collective works) that contain a work based on the Program; this is addressed below. Is that better? Yes. I think it's important to note that narrower bounds on the license are not necessarily less favorable to the offeror. If you're willing to agree with me on that point, I'm happy. Presentation: Logically, you seem to have assumed that the clause in question is erroneous, and you draw conclusions from this assumption. In other words, but your conclusions seem to be don't seem to add much to your initial assumption. I was attempting to use the phrase erroneous paraphrase just as a name for candidate C above. As stated more clearly above, the notion that it is erroneous doesn't enter into the logic until you try to resolve the ambiguity against the offeror. And even there that erroneous character is contextual. I could imagine (for example in a dual-license contract) that the licensee might prefer the broader interpretation -- for that case, the narrower interpretation would be erroneous. Issues: As near as I can tell, section 0 of the GPL establishes what is being licensed by the GPL. To my knowledge, no works which are not explicitly recognized in section 0 are being licensed. Section 0 also seems to establish the scope of the license -- which is something you've expressed strong interest in. Other sections which grant permissions explicitly do so under the terms of this license which includes section 0, or under the terms of section 1 (which refers to the Program of section 0), or of section 2 (which must be under the terms of section 1). The question being asked in scope of license analysis is, what rights reserved to the copyright holder, as defined in 17 USC, are being made available for exercise by the licensee, whatever the return consideration may be? In the case of the GPL, the licensed rights include copying and distributing the Program itself; modifying, adapting, translating or otherwise creating a work based on the Program, and copying and distributing the result; and aggregating a work based on the Program with other material and copying and distributing the result. As near as I can tell, those rights are somewhat limited in the context of modification. You seem to be trying to imply that conditions are to be ignored when construing the scope of the license. But I don't think that's legally valid -- I've certainly not seen anything that would support that implication. And, I've seen legal language (for example the concept of narrow scope) which implies the opposite. In another license, the scope might be as narrow as translate alternate pages into French and German and publish the result on Post-It (TM) Notes; but as long as you pet a cat on alternate Tuesdays isn't part of the scope of license even if it's the first clause in the agreement text. As long as you [do anything] is contract law stuff, even if [do anything] logically requires exercise of the rights under copyright that are being offered to you. Except... I think you've left out a lot of the narrowness of the GPL. I think that there's really no question, no matter which path you take to construe aggregation, that it includes both the
Bro check out this awesome new product
Now, it's finally possible for you to enlarge your penis http://www.legahe.com/ss/ Wanna be more man? Check this dude -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping debate in its place so we can actually reach resolution [Was: Re: ]
On 5/20/05, Don Armstrong [EMAIL PROTECTED] wrote: On Fri, 20 May 2005, Michael K. Edwards wrote: On 5/19/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: You are choosing to post on three different forums. Having made that choice, it is your obligation to make your comments relevant to them all; you cannot post on debian-devel, and then insist that your interlocutors there read a different list. Oh, nuts. I didn't realize this thread was still copied to hell and gone. I'll try to summarize briefly, and would the next person please cut d-d and waste-public off if appropriate? Can we please try to hold most of these discussions primarily in -legal? I agree entirely. Please review the thread's history: apparently cross-posted from waste-public to d-d and d-l by one Mirco Bauer, attracting interest from people who seem not to be regular d-l readers; intervention from current d-l participants on the topic of GPL retraction (certainly relevant to WASTE), followed by a pointed but polite exchange about patently false (my phrase) assertions in the FSF FAQ; thread broken by Thomas Bushnell (trashing Subject; I stupidly assumed he had also narrowed the cross-posting) in order to dispute things I had written, in apparent ignorance of recent d-l goings-on; my attempt to refer Thomas to a specific thread from d-l archives, rebuffed with the above cross assertion that I owed all participants a summary; Thomas's and my subsequent conduct, which you may judge for yourself. Once we have actually figured out what the primary issue is, and understood the ramifications of it, only then should we present a cogent, clear analysis of what the actual issue is to upstream, so that they can actually deal with it appropriately. Otherwise, all we're doing is burying upstream (and frankly, -devel) under a deluge of material that they could care less about, and hurting our chances of eventually resolving the issue (whatever it is) appropriately. You may note that I've usually been the one to prune branches of threads that were spamming d-d when I noticed them; I don't believe I've added d-d to any d-l thread recently, and perhaps not ever. [Finally, as a major nitpick: Please, please, please, Set a useful Topic:. Otherwise it becomes quite impossible to return to these threads at any point in the future. Topicless threads are almost as bad as threads with a wrong topic.] Er, talk to TB, who doesn't seem to read d-l. ;-) But I'll try to fix such things when I notice them. GMail is the only resource I have handy that can handle the header-forged spam flood that a d-d subscription invites, and sometimes I miss things in its interface. Cheers, - Michael
Re: Keeping debate in its place so we can actually reach resolution [Was: Re: ]
On Fri, 20 May 2005, Michael K. Edwards wrote: On 5/20/05, Don Armstrong [EMAIL PROTECTED] wrote: Can we please try to hold most of these discussions primarily in -legal? I agree entirely. Please review the thread's history The thread's history just shows where the mistakes were introduced, but the perpetuation of them is primarily the fault of the author of every subsequent message.[1] Everyone who replies to a thread needs to be aware of who they're sending the message out to, and whether the content of the message really is going to serve the goal which we (hopefully all) share, resolving the issue(s) in a manner which allows the software to be included in Debian in compliance with the DFSG. [Please, please, please, Set a useful Topic:.] Er, talk to TB, who doesn't seem to read d-l. I'm just talking in general here.[2] Don Armstrong 1: And I've made more of my fair share of mistakes in perpetuating pointlessly crossposted threads that just end up confusing hapless upstreams... *cough* *cough* *mplayer*... 2: The recent influx of thread breaking messages[3] which have made it almost impossible to follow threads has made me even less tolerant of messages that break threads and lack subjects... if the discussion is made that difficult to follow, no one will follow it, and the participants may as well just be responding privately, because no one else but the participants in the thread will bother to read it. 3: Mozilla Thunderbird 1.0+ (Windows/20050224) and Internet Mail Service need to be taken out and shot. -- Three little words. (In decending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.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: RES: What makes software copyrightable anyway?
Another long one, because I'm trying to get to the bottom of this scope of license business. On 5/20/05, Raul Miller [EMAIL PROTECTED] wrote: [snip agreement, about which I am very happy] I think it's important to note that narrower bounds on the license are not necessarily less favorable to the offeror. If you're willing to agree with me on that point, I'm happy. Sure. But I'm not talking about narrower bounds on the set of rights offered with respect to the Program (which is the extant work on which there exist licensable rights). I'm talking about narrower bounds on the definition of work based on the Program, which leaves room to construe the appropriate permissions for anthologies / buckets-of-works based on the rest of the contract. I was attempting to use the phrase erroneous paraphrase just as a name for candidate C above. As stated more clearly above, the notion that it is erroneous doesn't enter into the logic until you try to resolve the ambiguity against the offeror. And even there that erroneous character is contextual. I could imagine (for example in a dual-license contract) that the licensee might prefer the broader interpretation -- for that case, the narrower interpretation would be erroneous. As a paraphrase of candidate E, it's erroneous. The grammar, as I read it, doesn't allow it to be anything else. But a licensee is certainly welcome to argue for the presence of an ambiguity there if they have some reason to prefer candidate C. The question being asked in scope of license analysis is, what rights reserved to the copyright holder, as defined in 17 USC, are being made available for exercise by the licensee, whatever the return consideration may be? In the case of the GPL, the licensed rights include copying and distributing the Program itself; modifying, adapting, translating or otherwise creating a work based on the Program, and copying and distributing the result; and aggregating a work based on the Program with other material and copying and distributing the result. As near as I can tell, those rights are somewhat limited in the context of modification. You seem to be trying to imply that conditions are to be ignored when construing the scope of the license. But I don't think that's legally valid -- I've certainly not seen anything that would support that implication. And, I've seen legal language (for example the concept of narrow scope) which implies the opposite. It's possible that you're right; however, the only evidence for this that I have found is internal to the district court's order denying Sun's copyright infringement claims on remand, and the outcome would have been the same either way, so it's not much of a precedent. Long version below. Note that the only consequence would be that some claims might be upgraded from breach of contract to copyright infringement (and thus an easier standard for preliminary injunction); all of the rules of construction still apply. My empirical understanding up until now from reading appellate case law (IANAL) is that limitations on how, when, where, and by whom copies (translations, etc.) may be made, and how many and in what form or medium, are all part of the scope of license. Ditto the nature and degree of adaptation, translation, aggregation, etc. Questions of form seem to be particularly subject to judicial construction as to the parties' intent: see Boosey Hawkes v. Walt Disney ( http://laws.findlaw.com/2nd/969205v2.html ) and op. cit. But the appellate record suggests that nothing other than the exercise of rights reserved to the copyright holder under 17 USC is relevant to this analysis, and obligations of return performance are to be ignored -- and the whole you must offer source code on demand bit is indisputably an obligation of return performance. Fail to satisfy it, and you may be in breach of contract, but you can't be successfully sued for copyright infringement unless the contract is first ruled to have been properly terminated. I'm now questioning part of this understanding, based on the Sun v. Microsoft district court's ruling on remand ( http://java.sun.com/lawsuit/012400motionfeds.html ) with regard to the scope of license contained in the TLDA. That opinion uses California law to justify reviewing the entire TLDA for evidence of scope of license. Its ruling against Sun relies on the absence of language in the TLDA about the license grants being subject to, conditional on, or limited by compliance with the compatibility obligations in the disputed section. The district court's approach to distinguishing between contractual covenants and restrictions on the license grants does not appear correct to me, given that all of the appellate judgments I have found that reference SOS v. Payday seem to implicitly use logic similar to mine above. It is worth noting that this is the same district court that was previously overruled for failing to
Re: RES: What makes software copyrightable anyway?
(Note, I might come back to some of this later -- I need to think about whether I want to bother raising some issues, among other things --, but a few of these I have immediate questions or comments about.) On 5/20/05, Michael K. Edwards [EMAIL PROTECTED] wrote: There is some question about whether Quagga+Net SNMP+libssl is uncopyrightable. No, there isn't. There's no selection and arrangement creative expression there. It's silly to say that some third party could obtain a copyright on combining those things and enforce it on the Quagga copyright holders themselves. Copyright doesn't protect ideas, it protects expression; and this is a doctrine of merger instance if I ever saw one. Are you saying I could just as well select, say, libperl, apache, and mysqld and expect them to be just as satisfactory' when combined with Quagga? Or are you saying that since the authors of Quagga already made that selection that no one else has to? 1. a. Official or legal permission to do or own a specified thing. Feeble. Get a real dictionary. Findlaw's legal dictionary says: 1 a: a right or permission granted by a competent authority (as of a government or a business) to engage in some business or occupation, do some act, or engage in some transaction which would be unlawful without such right or permission Better? The non-GPL license option to MySQL had no relevance to that case whatsoever. It was not claimed by Progress Software, it is not mentioned in the opinion or in Eben Moglen's affidavit, and as far as I can tell the judge may not even have known that existed. Unless you have some piece of the court record that I don't yet -- in which case, pony up -- this is a lame bit of misdirection. I'll quote the beginning of point 30 of that affidavit for you: MySQL AB engages in ``dual licensing.'' This means that it licenses a version of MySQL to be freely used, copied, modified and distributed by everyone under the GPL, and also makes versions of its program that are distributed to particular customers without the right of free distribution. I don't have at hand the claims of Progress Software, but Saris clearly was informed of this issue. -- Raul
Re: RES: What makes software copyrightable anyway?
On 5/20/05, Michael K. Edwards [EMAIL PROTECTED] wrote: As a paraphrase of candidate E, it's erroneous. The grammar, as I read it, doesn't allow it to be anything else. But a licensee is certainly welcome to argue for the presence of an ambiguity there if they have some reason to prefer candidate C. One other observation here: It's entirely possible that a court would not find this phrasing ambiguous. Here's the full text of the definition of derivative work from 17 USC 101: A derivative work is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a derivative work. I believe that we've established that for a work to be not a derivative work that it's not sufficient to show that it's a collective work. And, some of those possibilities -- elaborations, annotations, adapted, recast, etc. as well as the bit about based upon one or more preexisting works all seem to point at the idea that if a computer program as a whole is to be granted special copyright protection beyond that of its individual components that it is a derivative work of those components. And I think we can agree that, at least within the U.S., this definition is a part of copyright law. [On the flip side, if it can be shown in court that there's some criteria under which all programs are free of copyright law, that's probably a good thing for the free software community.] -- Raul
