CLWG: Common License Working Group
I was browsing the O'Reilly open-source page today and finally noticed the link to the Common License Working Group. The link is at http://opensource.oreilly.com/ The information on the Common License Working Group is here: http://protected.speech.cs.cmu.edu/clwg/ I'm not sure how this relates to the OSI, except that the OSD is used as an example of a metalicense and there are a number of other interesting licenses offered as specimens. Also, ESR seems to be participating at some level. Maybe this will be revitalized at this summer's open-source conference. -- Dennis
RE: Wired Article on the GPL - Signed Licenses?
Although we are getting far afield from the structure of open-source licenses, there seem to be some procedural and technical steps someone could take to ensure that a license is perpetuated, especially for digitally-conveyed works and licenses to those works. There are moves afoot to establish the legal acceptability of digital signatures and their non-repudiation qualities. I don't want to substitute technology for common sense, but this does seem to promise a way to be clear what (1) the licensed work is, and (2) the authenticity of the license (or even notice). It might even provide a mechanism for "affixing" a license to a copy of the work even though the elements are physically separated. A. USING DIGITAL SIGNATURES TO CONVEY LICENSES It is interesting that employing digital signatures to establish the authenticity of open-source distributions is already on the rise. Here is what I noticed: 1. If I provide a license statement in digital form, which is digitally signed, a recipient can confirm whether the license has indeed been signed according to an accompanying certificate, and whether the document is unaltered. That establishes signature and that the license is a true copy of the signed material. Then the "usual" mechanisms come into play with regard to determining whether (a) the signature is authentic and can be trusted and is indeed non-repudiatable and (b) whether I have the right to convey such a license, signed or not. [That is, we are in the same place that we are with conventional written instruments.] 2. I can, as part of the signed license document, provide certificate information that is usable to confirm signatures on the digital copies of the covered works themselves. These can be incorporated in the signed material of (1), and be an intrinsic part of the signed material. I see some weaknesses in this step, but no more so than with the EULA I have in front of me pertaining to a massive amount of software that I just installed on my development computer. 3. Various secure repository (certificate authority) mechanisms are used to establish the provenance of a digital certificate of particular quality. Along with this, there can be deposit mechanisms for licenses (just as there is or at least was a way to record copyright assignments for registered copyrights). It would be valuable to have a repository where licenses could be recorded/deposited so that someone researching the status of a copyright and its assignments/licenses could find them. I don't know that the U.S. Copyright Office would be particularly happy to provide that, but who knows. It would certainly depend on having registered the copyright, though. 4. Digital signature techniques are being used to provide more confidence in the authenticity and provenance of digital material, permitting trust against substitution of altered or counterfeit works that may be dangerous to users of the work. They also provide a level of commitment by an authentic signer that the work (including the license) is not repudiatable. None of these provisions prevent someone from forging a work or making fraudulent exclusive transfers. It is just harder to do it without incriminating oneself. It also depends on due diligence on the part of recipients of such materials. B. EARTH TO DENNIS, EARTH TO DENNIS ... I notice that the EULA I am looking at right now is not "signed" although I have every reason to believe that it is authentic. The box within which the software was packed even had an affixed "certificate of authenticity," and I guess I should retain that with my EULA, the CD-ROMS, the CD-ROM "key," and the proof-of-purchase. I purchased the software over the Internet. I have registered myself as the purchaser using the on-line mechanism provided as part of the software installation process. I suspect that's quite enough for me and the software vendor, either one, to establish the likelihood that I have purchased their software and that I am a party to the accompanying EULA, which I also recall "clicking-through" as part of the software installation process. I can't imagine what either of us might do that would have this be in dispute. I will hold onto the materials anyhow. I also notice that there are a number of digital certificates included in the software collection. Although a number of them have expired (that is a problem with these things), I have strong reason to believe that they are authentic. -- Dennis -- Dennis E. Hamilton InfoNuovo mailto:[EMAIL PROTECTED] tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -Original Message- From: W. Yip [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 30, 2000 04:43 To: [EMAIL PROTECTED] Subject: Re: Wired Article on the GPL [ ... ] --- USC 17 205 E (e) Priority Between Conflicting Transfer of Ownership and Nonexclusive License. - A
RE: Wired Article -- Nullifying a GPL?
I looked at what I could find on Wired, thanks to the Slashdot discussion and its links. 1. UNRESOLVED QUESTIONS? One problem I notice is that we don't have a finding with regard to the validity of the copyright by the original distributors of cphack. Part of the Mattel claim was that this work was the product of an infringement. I gather that the parties have settled, but I don't know what has been stipulated concerning the validity of the cphack copyright and therefore any purported licensing of it. The cited property transfer is prudently noncommittal on that score. I would say that leaves much of the "fiasco" in place, depending on what the judge makes of all of this. I have neither information nor further opinion about the actual case. 2. HEY BUDDY, WANNA BUY A WATCH? GENUINE ROLEX! I do see an interesting question over what happens when any published work is tainted by a problem over the ownership of the intellectual property embodied therein. I've never heard of anything that will insulate a recipient of software from the consequences of that material not being the property of the supplier/license-writer. I've seen contracts that held a purchaser harmless from any intellectual property issue, but they were written by suppliers who could be reasonably counted on to perform, and the monetary considerations were considerable (e.g., purchase of large mainframe computer systems). I don't notice anything about that in the 7-page software EULA I happen to have in front of me. I do notice that section 7 of the GPL (Version 2, June 1991) does have language which may be pertinent and which may have bearing in the Mattel-cphack case too. The outcomes tend to be limited to what is practical. But willful redistribution of a tainted work (e.g., copies of a believed-to-be-pirated audio recording or electronic novel) is not smart behavior, any more than is quickly reselling an automobile that you purchased with the strong suspicion that it was stolen. Or hastily spending that $20 bill you were given that you are pretty sure is counterfeit. So, "do you feel lucky, ...?" I have no basis for determining or assuming that the GPL-ing of cphack has been nullified or made void. I do think we are seeing an area where trustworthy sources become important. In particular, the presence (or in this case, simple mention) of the GPL in material, as for any license, depends for its authority on the legitimacy of the claim of property right on which the license is founded. Of course, we will trust these things. But I think it is important to understand that it is all about trust relationships. Sometimes, these don't work out, and we are left with a challenge to behave responsibly and diligently. -- Dennis -Original Message- From: Chip Salzenberg [mailto:[EMAIL PROTECTED]]On Behalf Of Chip Salzenberg Sent: Thursday, March 30, 2000 10:16 To: W . Yip Cc: [EMAIL PROTECTED] Subject: Re: Wired Article on the GPL According to W . Yip: On Wed, 29 Mar 2000 15:49:49 -0800, Chip Salzenberg [EMAIL PROTECTED] wrote: By releasing under the GPL, the original authors surrendered their right to control GPL-compatible copying. Having surrendered that right, the original authors are not able to transfer it. Mattel's lawyers would certainly disagree with you on this one. They probably would stand by their contract and claim that copyright has been assigned to them. Oh, I won't argue that point. Mattel certainly owns the copyright. But I would consider it obvious that, once I have been granted me a license to copy, neither the original copyright holder nor his assigns have the authority to stop me. In other words, the license adheres to the code, not the author. Frankly, I'm stunned that Mattel is even bringing this argument. They (or the department in question) must be in a full-blown panic. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
RE: How To Break The GPL - Copyright versus Contract
Hmm, I am still not being clear. 1. I agree with you completely about EULAs. I think we agree that the purpose of EULAs is to establish that a copy of a work is being licensed, and not sold, and is being provided under different conditions than simple trading in a copyrighted work. Are you suggesting that the GPL is an EULA? That never occurred to me. 2. I was under the impression that use of the GPL involved affixing a copyright notice naming the Free Software Foundation. I must have dreamed that somewhere. It's not accurate. However, if I affixed such a notice (as some people seem to) and included the GPL, I would think I am making assignment to the FSF under the proviso that the GPL be applicable. That's the case I had in mind. Sorry to have introduced such a red herring. 3. Is it necessary to discuss contracts and EULAs when dealing with a strict granting of license to perform certain conditional acts on a copyrighted work? I mean for the current GPL, not some hypothetical different license. This would seem to keep things under copyright law and the extensions of that outside/into the U.S. by various treaty provisions. (Does the preemption of the States with regard to copyright still holds in anything that has happened since the 1976 revision?) -- Dennis -Original Message- From: Rod Dixon, J.D., LL.M. [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 09, 2000 19:32 To: [EMAIL PROTECTED] Cc: Open-Source License Discussion Subject: RE: How To Break The GPL - Copyright versus Contract -Original Message- From: Dennis E. Hamilton [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 09, 2000 6:45 PM To: [EMAIL PROTECTED] Cc: Open-Source License Discussion Subject: RE: How To Break The GPL - Copyright versus Contract My apologies for not being clear. That is all I meant by speaking of EULAs. They are for purposes other than what is (thought to be) dealt with solely by copyright. The case that I posted, The Pro CD case, is a federal appeals court case that is viewed by almost all lawyers practicing in this area of law as clearly establishing a court's willingness to view EULAs AS ENFORCEABLE CONTRACTS EVEN WHEN THE ARE NO MORE THAN SHRINKWRAP LICENSES. This case energized the movement (UCITA) to declare ALL software licenses as enforceable contracts under certain conditions (including clickwrap licenses). Virginia is the first state to pass UCITA and many more are currently considering the legislation (this is not to say that there are not dissenting states. New Jersey is one and I believe Iowa is another). Nonetheless, once a few states join Virginia, UCITA will become a valuable tool for the Open Source movement as well as e-commerce in general. You might say that to some extent copyright will be displaced and contracts will become the real legal tool to enforce conditions on how one uses your software after it is downloaded. Controversial? You bet! Implausible? Not anymore. However, my sense of the GPL is that the Free Software Foundation is relying only on Copyright for the GPL, and that there is nothing but a conditional (non-exclusive and royalty free) license of copyright conveyed in the GPL (apart from the "no warranty" aspects). It is, after all, touted as the "copyleft" agreement. You are correct. Of course, most software is sold this way today. Or, to be more precise, software "is not sold, it is licensed." This distinction is made to "protect" the interests of the copyright holder. I guess here it is a matter of asking the FSF whether they see themselves as having accomplished anything else, since when we employ the GPL we appear to be assigning copyright to the FSF. Hmm... Not sure what you mean here. It sounds like you are pointing out one of the arguments in the debates going on concerning the legal status of the GPL's copyleft provision. If so, the FSF position would be that they own the copyright interest and THEY are assigning YOU a non-excusive copyright interest to make derivative works under the terms and conditions of the GPL. This is a critical distinction because the GPL would have a dubious legal status, if the argument were reversed or put in the terms you raised. (I think there are instances that may fit your version of the facts.) How do you see state contract law(s) applying to the GPL? See above. The GPL IS a contract. Calling it a license simply describes the type of contract it is. some people get confused and believe licenses are always required when copyright interests are at stake. This is not true. Copyright and contracts are not necessarily intertwined. The software industry loves licenses (in part, this may be due to the fact that bits are easily copied). The publishing industry, by contrast, seems to prefer to do business on a handshake, no license. The interesting thing is that both industries produce income by selling copyright interests. (Unfortunat
RE: How To Break The GPL - Direct Functionality versus Copyrighted Expression
I am concerned that moving this discussion toward "direct functionality" is completely leaving the domain of Copyright, at least as it has been dealt with in the United States. So long as the GPL is solely a license of some or all of the exclusive rights that are possessed by an owner of a copyright, we should confine ourselves to copyrightable subject matter. My sense of this is that it is important to recognize that copyright applies to *expressions* fixed in tangible forms. (e.g., an actual source code, this e-mail note as rendered by a computer, etc.) Generally, the idea, procedure, or "function" expressed in a work protected by copyright is not protected by copyright. It may be protected by other means, but not copyright. In the U.S. copyright history there has also been a principle of utilitarian necessity. That is, if the ways of expressing a particular idea or concept are severely limited, then a court is likely to rule that such expression is not protected by copyright. This seems to be so one cannot copyright language and one cannot use copyright to obtain the power of a patent by round-about means. Note that this principle did *not* protect Borland in the Lotus suit over replication of the Lotus 1-2-3 look-and-feel as a "skin" for Quattro Pro. At the same time, it is generally agreed (and tested in courts a little) that APIs are not protected works from the standpoint of copyright. Now, software presents some novel conditions around expression, mention, usage, and performance. We run into that in discussions of derivative works. It is important to remember that whatever the FSF claims about this regarding the GPL, this has not, as far as I know, ever been upheld in a court of law. Yes, there is a cloud around this because of the lack of a definitive precedent (as far as I know). This means that users of GPL's works in conjunction with non-GPL'd works are appropriately wary. On the other hand, relying on this to obtain constraints on the use of a work that may not be ones right to restrict is not particularly useful either, since this supposed exclusive right around usage or "co-operation" can vanish in the twinkling of an eye. So long as the GPL is solely a copyright license, it cannot assert an exclusive right that the distributor of the work doesn't possess as a matter of copyright. (This is why there *are* EULAs and licenses for the *use* of commercial software. Copyright alone is insufficient to prevent re-engineering and a host of other things that EULA-bound licensees agree not to perform.) I just want to suggest being mindful that we are talking about copyrighted subject matter here and not other things. When we are discussing a thin-ice area (e.g., derivative works that don't involve alteration of the original in any way but depend on the function expressed), it is not prudent to head farther into the center of the lake for resolution. -- Dennis -- Dennis E. Hamilton InfoNuovo mailto:[EMAIL PROTECTED] tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -Original Message- From: Ken Arromdee [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 04, 2000 23:12 To: [EMAIL PROTECTED] Subject: Re: How To Break The GPL On Sat, 4 Mar 2000, David Johnson wrote: But what does "direct functionality" mean in terms of licensing? I can see functionality being added to a GPL application in ways that both would and would not violate the GPL. If I wrote a new plugin for Gimp, it would add functionality, but would only have runtime linkage. But putting the exact some code within the body of the Gimp source code cause it to come under the purview of the GPL. According to RMS, plugins are *also* derivative works, so both your examples would come under the GPL. (Which produces the odd result that it is legal to write a GPL plugin for Internet Explorer but not for Netscape 4, since Internet Explorer comes under the system component exception.)
RE: BSD / GPL compatibility - Infection by Libraries
You've asked a key question. 1. THE "LIBRARY" QUESTION - WHEN IS AN USING WORK A DERIVATIVE WORK? Welcome to the world of behaving literature 1.1 Based on my readings of discussions on the question of infection by binding, no one knows for sure. It is all speculation about libraries, linking, binding, run-time coordinated use, etc., etc. There has been no test in court. So, what is one to do? 1.2 In the case of GPL (and specifically, what I understand to be the RMS view of it), one can take a simple principled view that if everything is GPL'd, then there is never an issue. That is a perfectly straightforward approach. And it is sufficient for the world that RMS is creating to live in, consistent with what I assess to be a key matter of personal integrity for RMS. 1.3 There is another view that I favor. I want to create software that is widely used and shared. I don't want users of that software to be concerned that their dependence on my contribution may place them in a position where copyright infringement could be claimed because of some weird technicality around dependence (static or dynamic) of one software element on another. That is how I have come to favor the MIT-style licenses that go no farther about derivative works than the OSD requires. I want people to know they can safely use the software/code and I want them to feel welcome and valued in contributing back, but not compelled to do so. This way, I don't have to worry about what a library or component (or even service) is and whether there is an open-source condition on their work as a consequence. 2. FINESSING THE LIBRARY QUESTION 2.1 By not constraining the form or license on derivative works, and placing simple conditions on provenance and distinguishability (the artistics, non-confusion stuff), even if a library use or a binding use is found to be a case of derivation, there is no infringement because adopters already have a license that permits what they have done. 2.2 If their work is found not to be a derivative, the license is moot. Either way, the users and adopters are on pretty safe ground and can operate with some confidence. 2.3 (The SDM license draft I am working on, a "simple" open-work license, is specific about that whereas the MIT-styles are often more implicit about it than I'm comfortable with.) 2.4 I looked at the LGPL and realized I simply did not want to go down that road. There is way too much technical specificity about how libraries are tied to software that uses them, and I couldn't figure out a way to abstract that to some easily specified and readily-applied principles. For example, I think using the compiler to do linking is also all right, and I don't want to go into the hairsplitting that seems to come up here in any case. 3. THAT SINKING FEELING For now, I am pretty comfortable with this approach. I also like the Open-Source Writers Group approach and how the MIT-like approach fits with open publication licenses. When I did that little analysis about the Angels, Borg, Inc., and Cavaliers last night, I did make myself a little queasy over the appearance of infringement when extending/maintaining my work makes changes that someone else has also arrived at in a GPL's derivative. (I am safer with regard to the closed-source Borg case so long as I had no way to see their source.) I am resolved, right now, to simply not fear something that hasn't actually happened. I am sure I can deal with if there is ever a concern or dispute about something like that. It's not as clear-cut as I would like, but I still prefer that situation to having people avoid using my work, whether commercially or otherwise because they are not clear on where they may be in a grey area over determination of derivative works. Since I do middleware, this is not a trivial concern for me. -- orcmid ------ Dennis E. Hamilton InfoNuovo mailto:[EMAIL PROTECTED] tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -Original Message- From: David Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 15, 2000 23:36 To: [EMAIL PROTECTED]; Dennis E. Hamilton; Ian Grigg; [EMAIL PROTECTED] Subject: RE: BSD / GPL compatibility - Derived vs. Fair Use On Tue, 15 Feb 2000, Dennis E. Hamilton wrote: 2.To focus on discussion of derivative works. Making derivative works is a right reserved to the original copyright holder, and so a license is indeed required to make one. And this is all provided for under copyright law. In particular, there is no implied right to make a derivative work by someone who is not the copyright holder, so what a copyright license says about it is highly pertinent. In terms of copyright law (and not in terms of programming usage), is an application that links to a library considered derivative? I would say that static linking is derivation and runtime linking is not. But I'm not sure about dynamic linking. RMS bring
RE: Derived vs. Fair Use
I don't think so. I am not sure how you see it having any influence. Here's my understanding of the GPL'd library case. If I GPL a library, I am not distinguishing among arguable cases of "derivative" is all, and I am specifying conditions on all exclusive rights that I have for making a derivative that I can give you a non-exclusive copyright license to also perform. Fair use, by definition, is not something that I have any say about as a copyright holder, whether I give you a license or not. I saw one article that suggested that is precisely the point of the fair-use doctrine, and it applies only where there is an over-riding public interest, such as permitting review and criticism not being stifled by creators hiding behind protection of copyright. (Taking code extracts for a textbook could easily fail that test, by the way, and commercial publishers have elaborate rights and permissions rituals to safeguard each other in precisely these situations.) If there is a fair-use doctrine (and that would be established in court or in the legislature) applicable to uses of software libraries that would otherwise appear to be infringing acts, electing to employ the GPL would make no difference. If, on the other hand, *you* want to make sure people are able to perform certain acts that might be found to be creation of derivative works, and you are willing to give a quit-claim for those cases without waiting for legal clarification, you use something fashioned like the LGPL, with a narrow escape condition, or something with a broad escape condition (e.g., no back-license) such as the MIT or the adless-BSD. The recipient of your openware might not actually need the protection of the quit-claim and your license may offer to give away something you don't actually possess, but it certainly clears the air, since your license prevents you from doing anything about it. As I keep exploring open-software licenses, fair use simply doesn't come up. For one thing, it is not something *I* have any say in at all. (And for me to *claim* fair use of someone's copyrighted work is something that I do at my peril and is not relevant to my crafting and using a license of a copyright that is my exclusive possession.) I think you and I have alignment. I just find it useful to point out that the right of fair use is not something you can assign, and that claiming it is not relevant to the language of copyright licenses. -- Dennis -Original Message- From: Scott Johnston [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 16, 2000 09:48 To: [EMAIL PROTECTED] Subject: Re: Derived vs. Fair Use From: "Dennis E. Hamilton" [EMAIL PROTECTED] In the context of these discussions, I suggest that it is valuable 1. To omit consideration of fair use. Making a derivative work of software doesn't qualify. The conditions under which fair use might arise with software are simply not useful for this discussion. Fair use could apply to the discussion of whether it makes sense to GPL a library, could it not? Other than that, I agree. Scott Johnston
RE: BSD / GPL compatibility - Derived vs. Fair Use
I want to clear up something that seems to be clouding this discussion. Here is my personal assessment: (IANAL, I just sound like one.) 1. Fair use is an application of a copyrighted work that does not require any permission or license to perform. In the past, the U.S. Copyright Act has given legal definition to fair use and stipulated what those usages are. There is, in effect, a statutory automatic permission regardless of the copyright status of a literary work. (There are other parts of the Copyright Act that establish mandatory licenses for certain acts, and also charter payment mechanisms for those acts.) Fair use is very limited and does not include creation of derivative works. In addition, the recent tendency has been to limit fair use even more. (For example, it can be a copyright infringement to exhibit a copy of a protected work that you own but have defaced in some way, even though it could still be found by a court that freedom of speech takes precedence in a specific disputed case.) 2. The making of a derivative work is one of the subdividable rights that come with copyright. The copyright holder has the exclusive and complete say in creation of derivative works. Period. If that weren't the case, it would be meaningless to say anything about it in creating a free, non-exclusive, royalty free copyright license such as the GPL. 3. Although much software is licensed and not simply sold as publication of a copyrighted work, the GPL and other open-source licenses are copyright licenses. Most software publishers are careful to place copyright notices and also to assert their copyright. The use of a "licensed not sold stipulation" is above and beyond the protection of copyright and is, I suppose, a matter of a contract between the purchaser of the license and the software publisher. (Which is why you have to declare you have read and understood that you are entering into such an agreement on various click-through arrangements.) As far as I can tell, that simply doesn't apply to the GPL (though people who deal in GPL'd distributions can certainly engage in additional licenses -- e.g., for maintenance and support and even warranty protection -- but those licenses can't alter or circumvent the GPL of the copyrighted subject matter in any way). In the context of these discussions, I suggest that it is valuable 1. To omit consideration of fair use. Making a derivative work of software doesn't qualify. The conditions under which fair use might arise with software are simply not useful for this discussion. 2. To focus on discussion of derivative works. Making derivative works is a right reserved to the original copyright holder, and so a license is indeed required to make one. And this is all provided for under copyright law. In particular, there is no implied right to make a derivative work by someone who is not the copyright holder, so what a copyright license says about it is highly pertinent. 3. To ignore other kinds of licenses as relevant to open-source licensing. OSD-satisfying licenses seem pretty clearly oriented to the licensing of acts that are specifically protected by copyright. Nothing else seems to be required. -- Dennis -Original Message- From: Ian Grigg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 15, 2000 13:46 To: [EMAIL PROTECTED] Subject: BSD / GPL compatibility OK, so does the same apply in reverse? I guess it does, so I can take any part of a GPLed work and shove it into my code and distrubute it as BSD. No, this is not possible. While programs distributed under the GPL may use BSD (minux advertising clause) code the reverse does not apply. The GPL is viral in this situation. I'm sorry if I didn't make myself clear, here's a rehash. Derived works are a concept of law of copyright. They are fairly broad, and applicable to all published works. AFAIK, IANAL. They are designed to protect the property rights of the author, whilst giving access to portions for fair use. If the feature of derived works applies to BSD covered code, then it probably equally well applies to GPL code. If, indeed, copyright law is applicable and provides access and protections, then it would normally apply equally to all publishers. It's not really a concept that a publisher can restrict the offering when publishing. Of course the big IF is whether copyright law has anything to do with it. I believe it doesn't, in which case the concept of derived works do not apply to any licence-covered code. iang
RE: License Approval Process
I think I understand how this works. Let me check it with your thinking: A. The Angels group produces a software work, X, distributing it under an OSD-consistent copyright license that permits derivative works and does not require that they be distributed under the same license or even be licensed at all. There is no back-licensing requirement in the license that accompanies copies of X. B. Borg, Inc., makes a derived work Y:X as a closed-source commercial product. They distribute the commercial product. Distribution of Y satisfies any other conditions that might govern the use of X and the Angels license is satisfied. C. The Cavaliers create Z:X as an open-source derivative and Z is distributed under the GPL. Again, all conditions of the Angels license on X are satisfied. AB. The Angels have nothing to say about Y. Furthermore, absent a specific separate agreement, the Angels have no right in Y different than anyone else who legitimately possesses a copy of work Y. In particular, they cannot do anything with aspects of Y not in X that conflicts with the terms of any copyright and licensing of Y. AC. The Angels also have nothing to say about Z. Furthermore, absent a specific separate agreement, the Angels have no right in Z different than anyone else who possesses a copy of work Z. In particular, they cannot do anything with aspects of Z not in X that conflicts with the GPL. AA. The Angels right to make their own derivative works of X is diminished to the extent that the Angels do not have an automatic license to take additions and modifications from the derivative works produced by others. The Angels can certainly make new, original derivative works of X, under cover of the original license form. In doing so, there needs to be care to avoid infringing the intellectual property rights of Borg, Inc. and the Cavaliers. Such care to avoid infringement is always warranted, but it would now seem somewhat easier for there to be an appearance of infringement considering that all are building derivatives of X. (AD. When the Dogmatics make a derivative work U:X, and license it in a way that is consistent with the Angel license, there is no such problem. The Angels and the Dogmatics can mutually derive from each others stuff and it all works.) Interesting, huh? Let's have "M admits-derivative N" represent that license N is automatically admissible on derivatives of works for which license M is automatically available. Then MIT admits-derivative GPL MIT admits-derivative MIT MIT admits-derivative closed GPL admits-derivative x if-and-only-if x = GPL where closed is an exit state [the chain is ended], and GPL is clearly a steady state [the chain is trapped]. I suppose this illustrates what is meant by the viral nature of GPL. For me, it also illustrates the cooperative nature of the MIT license and all of those, x, for which MIT admits-derivative x is a symmetrical relationship. Relation admits-derivative is transitive; it is neither reflexive nor symmetrical. -- Dennis ------ Dennis E. Hamilton InfoNuovo mailto:[EMAIL PROTECTED] tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Cowan Sent: Tuesday, February 15, 2000 13:06 To: [EMAIL PROTECTED] Subject: Re: License Approval Process "Matthew C. Weigel" wrote: On Tue, 15 Feb 2000, John Cowan wrote: The "new BSD" and the equivalent MIT license are compatible with the GPL; the "old BSD" license with the advertising requirement is not. In general, a license is compatible with the GPL if it imposes the same, or fewer, restrictions than the GPL. Ummm... I don't think so. For one, Nothing is commutatively compatible with the GPL -- software can't be redistributed under different terms[1]. Also, if another license is as restrictive as the GPL, you probably can't license it under different terms either, and thus you can't redistribute under the GPL. Oh, you are talking about relicensing. I was using "compatibility" in the sense of distributing a derived work parts of which are under two different licenses. Thus, no derived work can be partly under the GPL and partly under the MPL (or at least you can make such a thing, but not distribute it): thus GPL and MPL are incompatible. Not so GPL and MIT/new BSD. -- Schlingt dreifach einen Kreis vom dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
