brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: license headers and config section
Date Thu, 02 Oct 2014 11:54:42 GMT
+1 for (2)-(5).

For the test/resources, these do not end up in the tar.gz but they will 
end up on maven central (e.g. like [1]). I presume that means it is part 
of the distribution, unless a mentor says otherwise.
Whether there is creativity in any of them, I won't judge just now so 
will play it safe.

I'll work on removing headers for (1b - docs), (3) and (4), and will 
make sure there are suitable comments next to the RAT exclusions.



On 22/09/2014 09:30, Alex Heneveld wrote:
> (1) Example Java and YAML in test/resources and docs - these are NOT 
> included in the releases (they are mainly in tests) and more to the 
> point they do NOT have creativity; they are just obvious 
> demonstrations of how the corresponding entities can be used and 
> configured.  REMOVE HEADERS on basis of the exemption.
> (2) Example Java and YAML in example projects - these probably DO need 
> headers as they are distributed; an argument could perhaps be made 
> about no creativity but I don't think it's worth it as headers here 
> seem least likely to cause problems.  KEEP HEADERS.
> (3) Java and YAML in the archetype used for new projects - these do 
> NOT show creativity, and including the license header is disruptive to 
> users.  REMOVE HEADERS here on basis of the exemption.
> (4) Third-party YAML and XML (eg config such as cassandra.yaml) - as I 
> understand it we do NOT have the right to add the license here; we DO 
> need to properly attribute them.  I think we should put a short 
> comment describing the origin of these files and a summary of 
> changes.  EDIT as appropriate.
> (5) Template HTML - these ARE included in the releases and DO have 
> creativity, much of them, so it sounds like they MUST have licenses.  
> This is the resolution I'm least pleased with due to the performance 
> hit but I guess we have to take that.  Maybe we could in time write a 
> variant of _.template which filters comments (since templates are 
> always being included in pages which already have a license).  KEEP 

View raw message