incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Licence headers in template files
Date Mon, 06 Feb 2012 19:38:56 GMT
On Mon, Feb 6, 2012 at 13:18, Ross Gardler <> wrote:
> Sent from my mobile device, please forgive errors and brevity.
> On Feb 6, 2012 5:26 PM, "Greg Stein" <> wrote:
>> On Feb 6, 2012 11:41 AM, "sebb" <> wrote:
>> >...
>> > Perhaps the answer to "Why is a licensing header necessary?"
>> >
>> > is relevant here.
>> >
>> > The README file is generally not going to be modified - or seen in
>> > isolation - so it's not so necessary for the end user to know its
>> > license from the file itself.
>> >
>> > However, the template files are specifically designed for
>> > modification, and are likely to be seen without the LICENSE file, so
>> > IMO the enduser should see the AL header as part of the file.
>> That would be my thinking, too.
> Not in this specific case, I think.

You keep refining the description :-P

> The original template files are not modified directly, neither are the
> output files. Modifications are by token replacement in the simplest form
> or by creating a completely new template to override the original (at which
> point the user can define their own licence).

Personally, I call that a tool problem. Seems there ought to be some
kind of comment directive that won't get included into the output. Put
the ALv2 notice in that comment.

And you're saying "supply a new template", but who knows what people
will do? Is there anything that prevents a downstream user from
editing these templates before packaging? Probably not. Sure... you'd
*like* them to provide a new template as part of Best Practices, but I
doubt that is forced.

> If the user generates their widgets from these templates the files we are
> talking about will be included in larger files, which do contain license
> headers. Final outputs will therefore always have an Apache header, there
> may be user specified headers surrounding their own contributions.

Gotcha. Yeah, that would be ugly, and it gets back to having some kind
of a "don't place <this> into the output" block.

> The final outputs should never be edited, it's the widget definitions (the
> tokens referred to above) that get edited.


Elsethread, I think Craig's suggestion is effectively saying "if the
file is shorter than the text, then we will declaratively state there
is no creativity in it." I'm not sure that is proper, but can
certainly see the argument.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message