Re: [epl-discuss] Definition of Derivative Works

[Jim Wright <jim.wright@xxxxxxxxxx>]

Why make reference to a concept so vague and ambiguous and that requires a nontrivial knowledge of copyright law to understand to begin with (or, if you define it differently than the underlying copyright law, why define it in such broad & vague terms)?

The license should make clear to developers what is covered and what isn’t without needing to consult counsel and ideally with as little difference as possible between jurisdictions, which means being more specific IMHO - e.g., if you cut and paste our source, the module into which it’s pasted is subject to the reciprocal license obligation, if you subclass a class in a new source module, the new module is/is not covered (before we get to positions I’m trying to address the need to clarify them), if a piece of code can’t run without calling covered code then the caller is subject to the obligation (again, if that’s the position one wanted to take - not saying it’s the right one and would obviously conflict with not covering subclasses but just pointing out the axis for clarity on what the license means up front), etc.

It’s not without reason that people try to stay away from tying the license too closely to specific technologies, but on the other hand, if one goes so far trying to stay away from them that a developer doesn’t immediately know whether something is subject to a reciprocal license obligation, which is the direction many licenses seem to go, we end up with confused developers and a lot of legal time wasted across a lot of orgs trying to figure out what’s covered.  If we’re revising the license, can we make it clearer by more precisely and explicitly defining the scope of the reciprocal license obligation than using “derivative works” (or provide a definition which addresses the 99% case using current technology with less uncertainty and need for counsel)?

 — J