Summary: Canadian law has a few interesting differences from US law, but I reach the same main conclusions -- the GPL is a valid offer of contract; technical distinctions like "linking" vs. "interpretation" are irrelevant to its legal force; and a judge is unlikely to permit the GPL to reach across a published functional interface irrespective of the FSF FAQ or of the GPL variants the FSF has created (LGPL, Classpath, gcc, etc.) in order to relax the, in my opinion, imaginary barrier to linking GPL code to code under other licences. IANAL in Canada, either.
On Sun, 16 Jan 2005 17:05:54 -0500, Etienne Gagnon <[EMAIL PROTECTED]> wrote: [snip] > (4) The owner of the copyright in any work may assign the right, either > wholly or partially, and either generally or subject to limitations > relating to territory, medium or sector of the market or other > limitations relating to the scope of the assignment, and either for the > whole term of the copyright or for any other part thereof, and may > grant any interest in the right by licence, but no assignment or grant > is valid unless it is in writing signed by the owner of the right in > respect of which the assignment or grant is made, or by the owner's > duly authorized agent. > > Personal comment > ---------------- > > This gives the copyright owner the right to license the work, or even > assign the "rights" on the work, to somebody else. Actually, the law > says that a license is not valid unless signed by the owner (or his agent). As in the US, licence in Canada is conveyed by contract (see, e. g., http://strategis.ic.gc.ca/sc_mrksv/cipo/cp/faq_cp-e.html ). From what you quote, I would expect a Canadian court to be more reluctant than a US court to find an implied licence in the absence of any written agreement, since the Canadian statute explicitly requires all licences to be in writing (as the US requires copyright assignment to be in writing). But a Canadian court can still use conduct to define the scope of an ambiguous licence. See, for instance, Bishop v. Stevens 1990 ( http://www.canlii.org/ca/cas/scc/1990/1990scc77.html ), which quotes Fox on Copyright: <quote> In order to constitute an infringement the act complained of must be done "without the consent of the owner of the copyright". Such a consent may be presumed from the circumstances. The inference of consent must be clear before it will operate as a defence and must come from the person holding the particular right alleged to be infringed. </quote> This quote seems to imply that evidence of consent, even in the absence of a written licence, can form an adequate defence against a charge of copyright infringement. I would presume (IANAL) that this would be a form of equitable estoppel, which is different from the theory US courts most often use but seems to have similar consequences. However, if Bishop v. Stevens is any indication, Canadian courts are not eager to find such consent, especially when there is an intermediary involved whose authority is strictly limited. (In the area of patent law, there is a very odd precedent, Signalisation de Montréal v. Services de Béton Universels 1993 ( http://www.canlii.org/ca/cas/fca/1992/1992fca10015.html ), which reads an implied license of patent into every purchase of a patented article, followed by a sublicense on every resale of that article. I haven't followed up on whether this conflicts with a statutory "authority to sublicense must be in writing" provision. However, Fox on Patent is cited as authority that a patent licence may be oral, so the law evidently differs between copyright and patent on this point.) > Note that Canadian courts have upheld in the past (as far as I can > remember) electronic documents as being valid. So, I am pretty > confident that a court would accept a license distributed along code as > valid. If you are not confident of this, then you might as well forget > about distributing any software for which you have no signed document > from its owner (or his agent), at least in Canada. :-) [I wouldn't be > surprised if the US law(s) had equivalent texts.] In the US, acceptance through conduct is originally a judicially created doctrine, although I think many legislatures have since written it into statute. I would expect to find it in Canadian contract law (code and/or case law) as well. Contract law is evidently part of provincial code in Canada, as it is state law in the US, and so the details may vary by jurisdiction. For an example in British Columbia, see Torfason v. 338058 B. C. 1994 ( http://www.canlii.org/bc/cas/bcca/1994/1994bcca10636.html ), which references an 1877 decision in the House of Lords as authority for acceptance through conduct. [snip] > [Side comment: This is one of the beauty of the GPL: for all those, such > as SCO, that claim that the GPL wouldn't hold up in court, it would mean > that actually they (SCO & all) have no right to do anything, let alone > distributing/licensing Linux. I know, this has been repeated over and > over, but it seems many people are still missing the point. :-(] Different people mean different things by "the GPL wouldn't hold up in court". Anyone who claims that GPL release puts code into the public domain (in the US), or isn't use in commerce, hasn't read and understood Planetary Motion v. Techplosion. If you ask me (IANAL), anyone who claims that it isn't a valid offer of contract hasn't read and understood MySQL v. Progress Software. However, there's quite a bit of room to argue (as I do) that some of its provisions overreach the bounds of what a court would be willing to enforce, and that the FSF's interpretation of the legal significance of the GPL may not be upheld in court. > All this means is that, to interpret the GPL, one has to interpret the > extent of the grants given in the GPL license text itself. If something > is not clear/explicit in there, then the "safe" assumption is to revert > to the strictness of copyright law that says: "no distribution is > allowed". In other word, the burden of the proof is not in the > direction of "The GPL does not say [something] may not be done, so I may > do it" (Wrong!). It is in the direction of: "The GPL grants me the > right to do [something], otherwise I wouldn't have had the right to do it". That's the "safe" assumption from the point of view of a licensee. It's even "safer" not to exercise the licence at all, by the simple expedient of not using or distributing GPL code. But when you compare, say, the "safety" of the GPL with that of the LGPL, you have to go to the trouble of matching them up against the applicable law, which may have the effect of overriding the GPL text in either party's "favor". [snip] > 1- By default, the Debian project may not distribute a Debian system > containing Kaffe, Eclipse, Linux, etc. > > 2- The GPL 2.b) for Kaffe says: You may publish the Debian system if > you "cause the Debian system (a work that contains Kaffe) to be licensed > as a whole at no charge to all third parties under the terms of the GNU > GPL". Note that it is entirely possible that a court would strike the GPL's attempt to reach compilations even without the "mere aggregation" clause, on the grounds that it is virtually universal practice in the modern software industry for software under different licenses to coexist on the same systems and distribution media. To allow a shrink-wrap software license, with no history of negotiations or evidence of licensee's intent, to ban the use of software under other licenses on the same (modern, multi-vendor, commodity) system, or to allow the license for electronically delivered software to dictate the boundaries of media on which it is incidentally stored, would be not merely far-fetched but stupid, and courts in most jurisdictions go to some lengths not to permit stupid readings of contracts. [snip] > Now, the question one should answer is the following: > > If, the Debian system includes a copy of Eclipse that is intended to run > on Kaffe, can we claim that both are "merely aggregated"? The answer is no. A major post-NAFTA decision, Tele-Direct v. American Business Information 1998 ( http://www.canlii.org/ca/cas/fca/1997/1997fca10177.html ), has clarified Canadian law on "compilations". This case states that "the Canadian Government ... must have expected the Court to follow the 'creativity' school of cases rather than the 'industrious collection' school." As such, Debian is a copyrightable compilation, and Eclipse+Kaffe is not. The former is certainly "mere aggregation" and the latter is unreachable on copyright grounds. Perhaps the Kaffe license could use more conventional license restrictions to disallow running Eclipse on Kaffe, but it doesn't. (For some general comments on the different standards of copyrightability in US and Canadian law, see CCH Canadian v. Law Society of Upper Canada 2002, http://www.canlii.org/ca/cas/fca/2002/2002fca187.html .) [snip conflation of engineering dependency with derivation under copyright] > One final point. One CANNOT claim that in the case of any Free JVM > using GNU Classpath, currently found in the Debian system, that a > virtual machine "merely" executes its class library. Actually, in many > of GNU Classpath's core classes, you will find "native" methods which > are implemented as C functions within the virtual machine itself. So, > if a virtual machine is licensed under the GNU GPL, without any > exception, then the GNU Classpath linking exception becomes void, and > the GNU GPL terms apply to the whole work. [Kaffe cannot run any > program, and consists of an incomplete work without its class library]. The technical niceties of "merely executing" versus "linking and then executing" are blessedly irrelevant under copyright law. For an indication that Canadian copyright law is applied similarly to US law in this respect, see Delrina v. Triolet Systems 2002 ( http://www.canlii.org/on/cas/onca/2002/2002onca10099.html ), which upheld a trial judge's analysis using methods similar to Computer Associates v. Altai 1992 (US 2nd Circuit). Delrina is, like most of the US precedents in this area, a "competitive" situation rather than an "interoperation" situation, so the fact that the trial judge used non-originality as well as functionality to reach uncopyrightability in the interface elements shouldn't be read to imply that use of a published API causes infringement if it meets an "expressive content" standard. US courts recognize that the manner of use can be as important in making the functional vs. expressive distinction as the nature of the content itself. I see no reason why a Canadian court wouldn't follow the logic, if not exactly the precedent, of Lexmark v. Static Control. In my view, the GNU Classpath linking exception is unnecessary and perhaps even disingenuous. Note that, prima facie, if SableVM + Classpath is a derivative work of both, then it can only be licensed under the GPL, because the LGPL contains a _different_ purported relaxation of the imaginary GPL linking constraint than the Classpath license contains, and thus a derivative work can't be licensed under either. See why I stick to GPL text and relevant law instead of trusting the FSF's special exemptions? Cheers, - Michael
