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" <a...@douma.nu> 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"<gst...@gmail.com> wrote: >> >>> >>> On Feb 6, 2012 11:41 AM, "sebb"<seb...@gmail.com> wrote: >>> >>>> ... >>>> Perhaps the answer to "Why is a licensing header necessary?" >>>> http://www.apache.org/legal/**src-headers.html#faq-whyheader<http://www.apache.org/legal/src-headers.html#faq-whyheader> >>>> 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.**apache.org<general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: > general-help@incubator.apache.**org<general-h...@incubator.apache.org> > >
