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 Fri, 03 Oct 2014 14:32:41 GMT
Hi all,

See for updating 
the rat exclusions, as discussed.


On 02/10/2014 14:04, Richard Downer wrote:
> Aled,
> Our main "deliverable" as a release is the source code .tar.gz, and
> every file in this archive needs either correctly licensed or an
> exemption applied.
> Many projects also have a second deliverable of a binary .tar.gz -
> brooklyn-dist-N.N.N.tar.gz in our case. Again, every file in this
> archive also needs correctly licensed or an exemption applied. This is
> an interesting case as the binary bundle will contain files that ARE
> NOT in the source bundle! Specifically, all our dependencies are
> downloaded from Maven and bundled into the distribution. Therefore,
> the binary distribution will almost certainly require DIFFERENT
> LICENSE and NOTICE files to the source distribution.
> The Maven artifacts are, I suppose, a third deliverable. I have not
> investigated this so I don't know what the issues are - I would assume
> that these would also require that the contents comply with the rules,
> although how those rules are applied to binary .jar files, I am not
> sure.
> Richard.
> On 2 October 2014 12:54, Aled Sage <> wrote:
>> +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.
>> Aled
>> [1]
>> 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 HEADERS.

View raw message