Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
John Cowan wrote: > But in any case my point is that there is no bright line between > a derivative and a collective work. If you are looking for a bright line in copyright law, I'll agree that that isn't it. Here again is what you hypothesized: "Bob interweaves his code into Alice's code (as in this hypo), Bob adds code to the end of Alice's procedure, Bob adds new procedures to the end of Alice's module, Bob adds a new module to Alice's module." Consider that all the Bob v. Alice examples you described would be undertaken either for expressive or functional reasons. If for functional reasons, then copyright has nothing to do with it. Bob and Alice can *use* software that they lawfully acquire, and *interoperate* it for functional purposes with other software that they lawfully acquire, to their heart's content. It is my impression that the law in the US and Europe strongly favors such freedom to use and interoperate legally acquired computer software without copyright restraints. But if there is an expressive component to what Bob and Alice have done, that expressive aspect alone is protectable by copyright, and they can prevent the making of copies, derivative works, collective works, or compilations of their own expressions -- again to their heart's content. And they can choose to license those things. That is true regardless of whether what Bob and Alice create is a derivative or a collective work. Copyright law is the same for both. What is different is that some FOSS licenses (such as GPLv2) actually obfuscate even further by their sloppy language that fuzzy-line between derivative and collective works, and leave people confused about what they can and can't do with their legally-acquired software. There isn't a bright line between expressive and functional components either, as my lawyer friends will remind us. They will refer you to the confusing "abstraction-filtration-comparison" tests that are used in the U.S. courts to distinguish functional from expressive content. But at least, when talking about the principles of copyright law, your hypothesized examples ought to focus on the things that Bob and Alice do for *expressive* purposes rather than the things they do merely to allow their software to function together through some technical (or bizarre) form of linking. I'll apply copyright law only when Bob or Alice make their software prettier. /Larry -Original Message- From: John Cowan [mailto:co...@mercury.ccil.org] Sent: Wednesday, September 11, 2013 6:20 PM To: lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Lawrence Rosen scripsit: > I would guess that Bob's adding "a bunch of calls to syslog()" into > Alice's work might create a derivative work of Alice's work, but that > wouldn't convert "syslog()" itself a derivative work owned by either > Alice or Bob, even if Bob statically linked it with Alice's program. The GPL provides an exception for things like syslog() anyway; you can link to it without triggering even disputable obligations. > Why are you putting the burden on an over-clever source code compiler > to detect derivative works? Not what I meant. If Alice's code contains the string "foobar" and so does Bob's, a compiler might coalesce the two strings into one, in such a way that the 0x62 in the object file's initialized-data segment could not be unilaterally attributed to either Alice or Bob. But in any case my point is that there is no bright line between a derivative and a collective work. If Bob's work is a derivative of Alice's, then we can construct a sequence of alternate hypos by Bob that lead right up to two separate modules of code, such as this: Bob interweaves his code into Alice's code (as in this hypo), Bob adds code to the end of Alice's procedure, Bob adds new procedures to the end of Alice's module, Bob adds a new module to Alice's module. In all cases, Bob's contributions can be separated from Alice's mechanically, even at the object level (absent coalescence as described above). Yet that fact is not determinative of collective work vs. derivative work. -- I Hope, Sir, that we are notJohn Cowan mutually Un-friended by thisco...@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Lawrence Rosen scripsit: > I would guess that Bob's adding "a bunch of calls to syslog()" into > Alice's work might create a derivative work of Alice's work, but that > wouldn't convert "syslog()" itself a derivative work owned by either > Alice or Bob, even if Bob statically linked it with Alice's program. The GPL provides an exception for things like syslog() anyway; you can link to it without triggering even disputable obligations. > Why are you putting the burden on an over-clever source code compiler > to detect derivative works? Not what I meant. If Alice's code contains the string "foobar" and so does Bob's, a compiler might coalesce the two strings into one, in such a way that the 0x62 in the object file's initialized-data segment could not be unilaterally attributed to either Alice or Bob. But in any case my point is that there is no bright line between a derivative and a collective work. If Bob's work is a derivative of Alice's, then we can construct a sequence of alternate hypos by Bob that lead right up to two separate modules of code, such as this: Bob interweaves his code into Alice's code (as in this hypo), Bob adds code to the end of Alice's procedure, Bob adds new procedures to the end of Alice's module, Bob adds a new module to Alice's module. In all cases, Bob's contributions can be separated from Alice's mechanically, even at the object level (absent coalescence as described above). Yet that fact is not determinative of collective work vs. derivative work. -- I Hope, Sir, that we are notJohn Cowan mutually Un-friended by thisco...@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
John Cowan asked: > But suppose Bob takes Alice's program under the GPL and and > adds a bunch of calls to syslog() so that it logs what it is doing > (and suppose further that this is not a de minimis or merely > mechanical change). Hypotheticals are so easy to answer without committing malpractice. :-) And so useless as authority for real cases! I would guess that Bob's adding "a bunch of calls to syslog()" into Alice's work might create a derivative work of Alice's work, but that wouldn't convert "syslog()" itself a derivative work owned by either Alice or Bob, even if Bob statically linked it with Alice's program. Why are you putting the burden on an over-clever source code compiler to detect derivative works? Alice better be able to prove that Bob created a derivative work by some reasonable legal standard relating to the expressive content of her work or she may be sanctioned by the court for filing a frivolous lawsuit. /Larry -Original Message- From: John Cowan [mailto:co...@mercury.ccil.org] Sent: Wednesday, September 11, 2013 2:05 PM To: lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Lawrence Rosen scripsit: > Does the distribution of a GPL-licensed work along with those > "separate works" convert them into something "not separate" in the > copyright sense? Does a staple or a paper clip or a book binding > convert separate works to something not separate in the copyright sense? Plainly not. But suppose Bob takes Alice's program under the GPL and and adds a bunch of calls to syslog() so that it logs what it is doing (and suppose further that this is not a de minimis or merely mechanical change). Do you then hold that this is not a derivative work either, and therefore need not be licensed by Bob under the GPL? After all, it is not as if you can't trace every single bit in the source code or resulting object code to Alice or Bob respectively, at least assuming the compiler is not over-clever. -- "Well, I'm back." --SamJohn Cowan ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright & RHEL contract
Lawrence Rosen scripsit: > I do so because my clients expect to profit (either financially or > in reputation credits) for delivering comprehensive solutions that > include FOSS components. It's kind of hard to see how this could be the case for releasing a compilation under the GPL. There's no money in it, and people don't get a good reputation when they do things others find incomprehensible: quite the reverse. That is not to say it is not a Good Thing in itself. -- Normally I can handle panic attacks on my own; John Cowan but panic is, at the moment, a way of life. http://www.ccil.org/~cowan --Joseph Zitt ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Lawrence Rosen scripsit: > Does the distribution of a GPL-licensed work along with those "separate > works" convert them into something "not separate" in the copyright > sense? Does a staple or a paper clip or a book binding convert separate > works to something not separate in the copyright sense? Plainly not. But suppose Bob takes Alice's program under the GPL and and adds a bunch of calls to syslog() so that it logs what it is doing (and suppose further that this is not a de minimis or merely mechanical change). Do you then hold that this is not a derivative work either, and therefore need not be licensed by Bob under the GPL? After all, it is not as if you can't trace every single bit in the source code or resulting object code to Alice or Bob respectively, at least assuming the compiler is not over-clever. -- "Well, I'm back." --SamJohn Cowan ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
On Tue, Sep 10, 2013 at 10:41 AM, Bradley M. Kuhn wrote: > > As I mentioned in a private thread, I didn't really see the need to > burn Till's time posting here, since the discussion was a side-issue > on the main thread about license compatibility, and an OSI director > had already said "oh no, not again" on the derivative works subthread. To be clear, I'm very glad for the high quality of response since then! As you speculated, Bradley, we have seen much of the same, tired analysis before, which is why I was unhappy; but since then, the thread has seen much new, useful writing that I think will be valuable for anyone thinking about this issue in the future, so I'm glad people have thoughtfully responded and continued the discussion. Luis ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright & RHEL contract
This is indeed depending on the case: people (developers) always declare (often after the work has been done, and not before as it should be) that they "used" products X,Y, Z. But what do they mean by "use"? Aggregating? Linking? Copying only some APIs or data formats in order to ensure that software is interoperable? Or really merging their code with the existing one? Depending on the case, solution will differ, but the need for simplifying (or just making legally possible) distribution is there. Cases are indeed multiple, and these developers want to license under FOSS conditions (not proprietary). Incompatibilities between copyleft FOSS licences (including between GPLv2 only and GPLv3 only) produce a lot of FUD in such cases... Patrice-Emmanuel Schmitz On 11 sept. 2013, at 16:00, "Bradley M. Kuhn" wrote: > Patrice-Emmanuel Schmitz wrote at 04:31 (EDT): >> Frequent cases are submitted when developers (in particular European >> administrations and Member states) have build applications from >> multiple components, plus adding their own code, and want to use a >> single license for distributing the whole compilation. > > While the description you give there is a bit too vague to analyze > against the USA copyright statue (i.e., the example lacks any real world > facts), I'd suspect that the default case of that situation, at least in > the USA, is the creation of a new single work that derives from those > components, plus their own code. > > The compilation copyright situation, at least in the USA, comes up more > with putting a bunch of unrelated works on the same medium, like a CD > ISO image. Making a single work of software that includes many > components is very different from mere compilation. > -- > -- bkuhn > ___ > License-discuss mailing list > License-discuss@opensource.org > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright & RHEL contract
Nick Yeates asked: > Larry did not state *why* he advises use of this licensing strategy > from a business, social or other standpoint. I do so because my clients expect to profit (either financially or in reputation credits) for delivering comprehensive solutions that include FOSS components. That's a business and social good. They are entitled to choose their own license for their collective works or compilations. I don't care a fig for the claims of GPL licensors that everything that touches their code must be under the GPL, although please don't accuse me of trying to infringe their works. I insist that my clients honor the demands of GPL licensors that THEIR components be under an enforceable GPL. That is why I want to see software companies fully disclose the FOSS components (and licenses) in their software, even as they distribute the overall programs (including perhaps its proprietary parts) under licenses of their choice. /Larry Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Rd., Ukiah, CA 95482 Office: 707-485-1242 Linkedin profile: http://linkd.in/XXpHyu -Original Message- From: Nick Yeates [mailto:nyeat...@umbc.edu] Sent: Tuesday, September 10, 2013 12:35 PM To: license-discuss@opensource.org Subject: Re: [License-discuss] Red Hat compilation copyright & RHEL contract >From http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf > At the same time, the combined body of work that constitutes Red HatR > Enterprise LinuxR is a collective work which has been organized by Red > Hat, and Red Hat holds the copyright in that collective work. Bradley Kuhn wrote at 15:46 on Monday: > . It's admittedly a strange behavior, > and I've been asking Red Hat Legal for many years now to explain > better why they're doing this and what they believe it's accomplishing. Larry Rosen wrote at 23:28 on Thursday: > I often recommend that licensing method to those of my clients who > combine various FOSS works into a single software package. It isn't > odd at all. Even if GPL applies to one or more of those internal > components, there is no need to license the entire collective work > under the GPL. We've even distributed GPL software as part of collective works under the OSL. I too am curious what this "compilation license"ing is and what its benefits are. Mr Kuhn asked, and Larry responded saying basically 'its not so odd - I use it often' and Larry did not state *why* he advises use of this licensing strategy from a business, social or other standpoint. 1) Why larry? 2) What is the "standard" way of doing this? How do most other org's license many works together? Full disclosure: I work for Red Hat, though am writing this from my personal account and perspective. I am a beginner on my knowledge into OSS license details, so please realize that I am attempting to learn. I could go and ask around in my company about this, yet I would rather engage with the community on this for now. -Nick Yeates ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Thanks Till, this was a very useful summary of the situation in Europe! I believe you've begged the question, however, by saying this: > Apparently, a computer program which is _not_ derived from > GPL code has nonetheless to be licensed under the GPLv2 when > the original GPL code and the program are not distributed > "as separate works". I'll take as your premise that we're talking about distributing "a computer program which is _not_ derived from GPL code." That simplifies our analysis. Certainly in most of the collective works or compilations distributed by software companies under a variety of copyleft and non-copyleft licenses, the most interesting and useful parts of those applications software are NOT derived from GPL code. Those larger applications, comprised of many FOSS and non-FOSS components, evidence a great deal of independent creativity and development effort. Although we know that creativity and effort alone does not determine the copyright status of those applications, we can say that the reward system in software development is tied to such independent creative development efforts. It will take more than wishful thinking and static linking to subject those independent creative works to the GPL and thereby to reduce the rewards available to their authors. Does the distribution of a GPL-licensed work along with those "separate works" convert them into something "not separate" in the copyright sense? Does a staple or a paper clip or a book binding convert separate works to something not separate in the copyright sense? You refer to a "binary blob." That is an interesting phrase which has no analogue in copyright law. How would a European lawyer define such a thing in a FOSS license so that, as long as even one blob-ette within it is GPL, binary blobs as a whole subject are to the GPL? You concluded that "the situation is far from being clear." Maybe I'm being naive, but it is clear to me that the law in the US and Europe favors the free interoperability of legitimately acquired software and disfavors claims of infringement by mere linking. Best regards, and thanks again for stepping into this minefield. I'd much rather hear your thoughtful views and those of our colleagues than ambiguous threats of infringement from GPL enforcers without any legal analysis behind them. /Larry -Original Message- From: Till Jaeger [mailto:jae...@jbb.de] Sent: Tuesday, September 10, 2013 10:25 AM To: license-discuss@opensource.org Cc: Bradley M. Kuhn; Lawrence Rosen Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Dear list, Bradley and Larry have asked me to share my view as a European lawyer on the question if linking of software components (necessarily) results in a "derivative work" as understood by the GPL. In a nutshell, my thoughts are the following (a more comprehensive overview can be found at http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German only): ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright & RHEL contract
Patrice-Emmanuel Schmitz wrote at 04:31 (EDT): > Frequent cases are submitted when developers (in particular European > administrations and Member states) have build applications from > multiple components, plus adding their own code, and want to use a > single license for distributing the whole compilation. While the description you give there is a bit too vague to analyze against the USA copyright statue (i.e., the example lacks any real world facts), I'd suspect that the default case of that situation, at least in the USA, is the creation of a new single work that derives from those components, plus their own code. The compilation copyright situation, at least in the USA, comes up more with putting a bunch of unrelated works on the same medium, like a CD ISO image. Making a single work of software that includes many components is very different from mere compilation. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] Disclaimers
I find it particularly objectionable that by providing my software free I open myself to the possibility of financial attack. I use something similar to the open source disclaimer for software I have published but have added the following to it "IF THIS DISCLAIMER CONTRADICTS LOCALLY APPLICABLE LAW THEN USE OF THIS SOFTWARE IS PROHIBITED." in an additional attempt to protect myself from litigation lunacy. Not sure if you may want to add something like it to your own disclaimer. Anyway keep up the good fight. Regards Tim A ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Dear Till
Thank you for this - excellent - analysis.
You wrote:
The only hint you may find is Article 6 which says that decompilation is
allowed under certain circumstances to "achieve the interoperability of an
independently created computer program with other programs".
Written in 1991, the Directive considered decompilation only, based on the
assumption that source code was not communicated to the licensee. The case
of free/open source software looks different because the licensee has
legitimately an access to the source code (no decompilation is needed).
However, this is indeed without importance in my understanding: the idea is
that the legitimate licensee of a software program (received as object code
only or as object + source in the case of FOSS) has the right to inspect
and reuse this code with the purpose “to achieve interoperability”
There is a definition of interoperability in recital 10: 'The parts of the
program
which provide for such interconnection and interaction between elements of
software and hardware are generally known as "interfaces". This functional
interconnection and interaction is generally known as "interoperability";
such interoperability can be defined as the ability to exchange information
and mutually to use the information which has been exchanged. '
Therefore, my understanding of the directive is that software, that is
independently created and exchanges information with other software through
an interface, is independent software and not a derivative work.
This is also my own understanding. But it means that linking software for
interoperability (= for exchanging information) makes no derivatives and
that the way of linking (statically producing a single binary or dynamic at
runtime) is just a technical modality without substantial importance
regarding copyright.
There is another hint in section 3 of Article 6: “the provisions of this
Article may not be interpreted in such a way as to allow its application to
be used in a manner which unreasonably prejudices the rightholder's
legitimate interests”.
If some litigation comes (hypothetically) to the Court (note: the right
name is now “Court of Justice of the European Union”) and if I was - by
impossible chance - involved as a lawyer, I guess that I would argue that
protecting free software is a legitimate interest and that statically
linking with proprietary software unreasonably prejudices this interest. At
the contrary, linking with FOSS software covered by another “similar”
copyleft licence would not prejudice this interest. Just my own
understanding of course...
Interesting debate...
Patrice-Emmanuel
2013/9/10 Till Jaeger
> Dear list,
>
> Bradley and Larry have asked me to share my view as a European lawyer on
> the
> question if linking of software components (necessarily) results in a
> "derivative work" as understood by the GPL. In a nutshell, my thoughts are
> the following (a more comprehensive overview can be found at
> http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German
> only):
>
> 1.
> As far as I know there is no relevant case law on the question of what may
> be considered a "derivative work" under European copyright law for
> software.
>
> European software copyright law has been harmonized
> (
> http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:111:0016:01:EN:HTML
> )
> since 1991.
>
> In my opinion "derivative work" in software law should have a different
> meaning than in other fields of copyright law.
>
> Software is typically interacting with other software, and dependencies
> (e.g. an application running on an operating system) do not necessarily
> mean
> that two components form a derivative work.
>
> 2.
> GPLv3 refers to copyright law ('To “modify” a work means to copy from or
> adapt all or part of the work in a fashion requiring copyright permission,
> other than the making of an exact copy') whereas GPLv2 might be interpreted
> in a way that the understanding of "derivative work" is broader. In this
> regard the GPLv2 seems to be a bit contradictory to me. On the one hand it
> defines 'a "work based on the Program"'as “either the Program or any
> derivative work under copyright law", on the other hand sec. 2 contains a
> more detailed explanation of what the term "derivative work" is supposed to
> mean within the scope of the GPLv2 ("If identifiable sections of that work
> are not derived from the Program, and can be reasonably considered
> independent and separate works in themselves, then this License, and its
> terms, do not apply to those sections when you distribute them as separate
> works."). Apparently, a computer program which is _not_ derived from GPL
> code has nonetheless to be licensed under the GPLv2 when the original GPL
> code and the program are not distributed "as separate works".
>
> If you do not want to ignore that language you have to find a meaningful
> interpretation for this sentence in sec. 2 of the GPLv2. To me, it ma
Re: [License-discuss] Red Hat compilation copyright & RHEL contract
Nick Yeates wrote:>I too am curious what this "compilation license"ing is and what its benefits are. Mr Kuhn >asked, and Larry responded saying basically 'its not so odd - I use it often' and Larry did >not state *why* he advises use of this licensing strategy from a business, social or other >standpoint. > >1) Why? >2) What is the "standard" way of doing this? Frequent cases are submitted when developers (in particular European administrations and Member states) have build applications from multiple components, plus adding their own code, and want to use a single license for distributing the whole compilation. In many cases their policy is to use the European Union Public Licence (EUPL) for administrative or linguistic reasons (using a license with working value in multiple languages). Therefore I published a matrix on Joinup ( https://joinup.ec.europa.eu/software/page/eupl/eupl-compatible-open-source-licences ). (the matrix should be updated due to new license versions, i.e. the recent OSI-approved CeCILL 2.1 which is now fully EUPL and GPL compatible) 2013/9/10 Nick Yeates > From http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf > > At the same time, the combined body of work that constitutes Red Hat® > > Enterprise Linux® is a collective work which has been organized by Red > > Hat, and Red Hat holds the copyright in that collective work. > > Bradley Kuhn wrote at 15:46 on Monday: > > … It's admittedly a strange behavior, > > and I've been asking Red Hat Legal for many years now to explain better > > why they're doing this and what they believe it's accomplishing. > > Larry Rosen wrote at 23:28 on Thursday: > > I often recommend that licensing method to those of my clients who > combine > > various FOSS works into a single software package. It isn't odd at all. > Even > > if GPL applies to one or more of those internal components, there is no > need > > to license the entire collective work under the GPL. We've even > distributed > > GPL software as part of collective works under the OSL. > > I too am curious what this "compilation license"ing is and what its > benefits are. Mr Kuhn asked, and Larry responded saying basically 'its not > so odd - I use it often' and Larry did not state *why* he advises use of > this licensing strategy from a business, social or other standpoint. > > 1) Why larry? > 2) What is the "standard" way of doing this? How do most other org's > license many works together? > > Full disclosure: I work for Red Hat, though am writing this from my > personal account and perspective. I am a beginner on my knowledge into OSS > license details, so please realize that I am attempting to learn. I could > go and ask around in my company about this, yet I would rather engage with > the community on this for now. > > -Nick Yeates > ___ > License-discuss mailing list > License-discuss@opensource.org > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss > -- Patrice-Emmanuel Schmitz pe.schm...@googlemail.com tel. + 32 478 50 40 65 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
