incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Licence headers in template files
Date Mon, 06 Feb 2012 20:23:30 GMT
Yes, Ate is right. There is likely to gee a situation in the future when
some of these files might contain creative content. I think Craig's
clarification covers this and there will, in the future, need to enhance
the code to strip licences.

My question here is about the way forward for a release the project is
cutting now. I'm satisfied that there is no creative content in what we
have at present. But I will review fully before the release and insert
headers where necessary.

Thanks for the input

Sent from my mobile device, please forgive errors and brevity.
On Feb 6, 2012 7:42 PM, "Ate Douma" <> wrote:

> On 02/06/2012 07:18 PM, 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.
>> 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).
> Ross: maybe the analogy with the two ways you can define embedded comments
> on JSP files might make sense here.
> In JSP files, which also can be seen as a template solution, including the
> support for including (embedding) output from a JSP fragment in a larger
> JSP page, you can use two type of comments:
> a) standard XML type comments, e.g. <!-- a runtime visible comment --!>
> The comments are retained and will eventually show up in the rendered
> output. They are good for example for (visual) debugging purposes.
> b) JSP native comments, e.g. <%-- a build time only comment --%>
> These comments are automatically stripped out from the output produced by
> the JSP, so are purely needed and used for development purposes.
> Typically you'll see in most ASF (and other) projects using JSPs the
> latter type being use for the license header.
> I would suggest a similar solution for the Wookie templates: that way the
> developers do receive a proper notice of the license for use, modification,
> and copying, while not cluttering the generated output.
> And you make it easy for downstream users/developers to make the choice
> themselves if they want a include their own license or copyright statement
> visible in the generated output, or not.
> While the current templates might be relatively trivial and indeed not
> have much of creative content, it will also be very easy to create one
> which does. Which might happen sooner or later, and than you're back to
> this question anyway. And you'll constantly keep making this decision.
> Using an automatically stripped comment format the whole problem simply
> vanishes, you just always add the license header inside such a comment.
> Ate
>> 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.
>> The final outputs should never be edited, it's the widget definitions (the
>> tokens referred to above) that get edited.
>> Ross
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**<>
> For additional commands, e-mail: general-help@incubator.apache.**org<>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message