Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epl-discuss] Status of generated code regarding "Derivative Works"

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 
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,

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

Back to the top