Re: [epl-discuss] Status of generated code regarding "Derivative Works"

["Berg, Paul W" <paul.berg@xxxxxxx>]

>  if you ever used a template that came with the office suite, did you bother reading through the EULA if it mentions how its licensed?

If the template was used to produce a critical asset in a valuable acquisition, you bet I have. Many, many times. I have also required clean-room re-implementations of such assets in many cases and blacklisted the use of development tools. It's a very expensive process fixing licensing issues because the user "expected" a default right that wasn't actually granted them. I much prefer and recommend the use of tools and templates that make clear what they intend in their licenses.

> Doing so, I fear that by getting rid of one issue we’d open a Pandora’s box of all other similar questions

Or we capture the entire class with a statement.

This class involves any tool which takes input from the user of the tool and generates output as a result of that input which may contain snippets of the tool itself embedded in the output. Examples include image and sound generators, code generators, code refactorers or linters, VLSI layout and logic synthesis engines, compilers, linkers, optimizers, scientific modeling platforms, encoders and codecs, level generators for games, document editors with stock graphics, fonts, etc., etc. etc....

It is a large and common class of software. In almost all cases the developer EXPECTS that the license of the generated object is solely affected by the license of the input description. The developer may not even be able to discern if the tool uses only a mathematical transform, in which case there can likely be no claim that the tool author has any copyright on the output object, or whether the tool injects crafted snippets for given patterns of input which may themselves be under copyright of the tool's author. For instance, a compiler may see a pattern in the input source code and directly inject a non-trivial template of executable code which is expressive, parameterized by input file. The tool author could conceivably make a claim that the output file is a derivative or combined work.

A statement in the EPL2 that requires the tool to notify the user when the tool author intends generated objects to be derivative works could stop future trolling by the tool author. This is not a new problem. See the Bison license and the license of GCC for examples.

I think most authors of tool input would agree that the expected behavior is that tools which process input and generate output objects do not claim copyright on the generated object and any other behavior is a relative oddity. So to be explicit I think the license should clearly state that this is the intent rather that wait for case law to establish the default later (and possibly go horribly wrong the other way forcing an emergency EPL2.1).

I am not confident that I can even come close to constructing any kind of legally solid statement that encapsulates this intent, not being a lawyer and all. I'm hoping someone more skilled than I in this area might have suggestions on what such a statement might look like.

On Mon, Apr 24, 2017 at 3:29 AM, Vincent Hemery <vincent.hemery@xxxxxx> wrote:

About the drawing program analogy :

As an analogy, I don’t expect my office suite’s or drawing programme’s license 
to affect my writing or drawing. If there are templates involved, those 
licenses *might* come into play. But if you ever used a template that came 
with the office suite, did you bother reading through the EULA if it mentions 
how its licensed? (This isn’t a perfect analogy, but then again that’s how 
analogies work.)

You don't expect the programme affecting your drawing license, but sometime it does. In case you use licensed additional filters or text font in Gimp, their license may affect your work whenever you use them.

So I think the analogy is rather a good one. You don't expect the generator's license to alter your generated code, but it may. (And yes, I do read the EULA of any advanced Gimp filter or font before using it...)

I really don't think we could get an all black or white solution on this issue. Since somme generators may take a very slight configuration and produce licensed code (like example wizards), whereas some (like EMF) are clearly intended to be used only as a mean.

We won't be able to draw the line. But at least, I think we could tell what the default behavior should be when no action is taken by developers.

Experience shows that generator's developers won't bother to tell what is the behavior of their generator. Generally, they develop it with an open mind. So maybe the solution here is just :

• stating that the developers can develop both kinds of generators, just like before
  
• telling what the default case is to eliminate any ambiguity when no explicit choice was taken (most probably no-impact for backward compatibility and convenience)
• explaining to developers (most probably in the faq) how they can make a generator of EPL-licensed code explicitely.
  

I have no idea which of these points should appear in the faq or in the license itself. But any solution which get us rid of ambiguous situations looks fine to me.

Doing so, I fear that by getting rid of one issue we’d open a Pandora’s box of 
all other similar questions, as the EPL is a license used for various tools, 
projects etc. in various settings. Then we’d either have to redraft the 
EPL-2.1 soon for adding new exceptions and reiterate that process regularly 
until we end up with a fairly long license.

[...]

… all that being said, if we can find a carefully-drafted generic solution in 
the wording of the license text itself, that doesn’t specifically mention code 
generators, but happens to also include them, I agree that would be a good 
solution.

And yes, I couldn't agree more, this point really might raise other questions about numerous similar use-cases (even advanced code-refactorers could be concerned).

I have absolutely no idea how to formulate it in a generic way that applies without doubt to code generators without mentioning it. But it really makes sense in the definition of "Derivative Works".

Best regards,

Vincent HEMERY Ingénieur d'études et développement Business Unit E-SPACE & Geo Information - Département Ground Systems Services CS Systèmes d'Information Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE +33 561 17 63 10 - vincent.hemery@xxxxxx

_______________________________________________
epl-discuss mailing list
epl-discuss@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_epl-2Ddiscuss&d=DwICAg&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=2I1PKj_HwqL2q7lA5JSs0qBxuXzD6vXeUQR3Jk6QBOs&m=pjVV6lasRy4BDg33g70-RDLsPsljKP3_J6SuNzErhbc&s=DNevvRgUwvE8HmCuCewDnY7A11ZfHPqZgzQDkjz0L6M&e=