On Fri, 2007-02-23 at 10:23 +0530, Biju Chacko wrote: > One of the biggest problems, as I see it, is that there is no clear > definition of what constitutes a derived work.
exactly. i should point out that the GPL very carefully avoids specifying what a derivative work is, within the licence itself. the question of whether aggretation, linking in some way, dependence in different ways, etc, infringes on copyright (and is thus a derivative work) is something the GPL leaves to copyright law. this is deliberate, because it allows the GPL to be a licence (a permissive grant) based only on copyright law, rather than a contract (an agreement) based on contract law - at least in the US, where this distinction works. so the GPL itself doesn't say that linking leads to a derivative work, though the FSF does say this (but their opinion is irrelevant). in ams's case, as thaths put it clearly, the interface between the proprietary (dependent) module and the modified GPL software is key to whether the proprietary module, combined with the GPL software, is a "derivative work". some forms of interaction are probably not derivative, others (such as static linking) certainly are, and yet others (dynamic linking) are possibly derivative. the best way to ensure "non-derivative-ness" is to design the proprietary module in a way that allows it to work with _other_ software instead of the GPL POP3 server. if it can work with other software, then it is probably non-derivative. an example may be a software APP that uses an underlying database DB. if APP is GPL, and works with MySQL OR mypropDB, i don't have to release mypropDB as GPL. -rishab
