brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: license headers and config section
Date Mon, 22 Sep 2014 08:30:50 GMT

David- Thanks for your continued guidance here and the explanations.

All-

Here is my understanding of the areas where we still need to resolve 
headers, and a proposed resolution for each:

(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.

Does this sound right?

Best
Alex




On 22/09/2014 05:45, David Nalley wrote:
> More inline responses.
>
> --David
>
> On Sat, Sep 20, 2014 at 6:09 AM, Aled Sage <aled.sage@cloudsoftcorp.com> wrote:
>> Thanks, very useful comments. Responses in-line.
>>
>>
>> On 20/09/2014 03:35, David Nalley wrote:
>>> On Fri, Sep 19, 2014 at 5:48 AM, Aled Sage <aled.sage@cloudsoftcorp.com>
>>> wrote:
>>>> Hi all,
>>>>
>>>> Some of these files are more controversial than others. Let's break it
>>>> down...
>>>>
>>> I think this is the right approach; this is essentially what you
>>> should be prepared to do when it gets to the IPMC.
>>>
>>>> For YAML files, there are a few categories:
>>>>
>>>> 1. Files inside docs (e.g. [1]). The contents of these files normally
>>>>      get embedded inside an html page as a code-block example. Including
>>>>      the header in every embedded example makes the resulting web-page
>>>>      harder to read.
>>> I don't think that harder to read is a good reason. However, my
>>> question to you would be; are the docs going to be part of your
>>> release, or just something that you publish to the website. Keep in
>>> mind that the entire repository might not be what is in a release.
>>>
>>> But; if you read the page for this policy there is an exception:
>>> http://www.apache.org/legal/src-headers.html#faq-exceptions
>>>
>>> Is there any creativity in this list of key-value constructs? I'd
>>> argue that example 1 has no creativity. It is merely a factual listing
>>> of keys and values. E.g. my personal opinion is that if [1] is
>>> representative of all of this class of file then I'd argue there is no
>>> creativity and no header is needed.
>> [ALED] The docs are just for the website (not included in the release), so I
>> believe that means we can safely delete the headers.
>>
>> By "harder to read", I meant for someone reading the generated documentation
>> - and thus directly affects the quality of the documentation.
>>
> The source header policy only applies to software that we release. It
> does not apply to websites or non-released (for very specific
> definitions of released, in an ASF context) artifacts.
>
>>>> 2. Files in the examples. We expect some people to copy-paste these as
>>>>      the basis for their own applications.
>>> This is almost certainly not a reason to remove the license header.
>>>
>>>> 3. Test files (in src/test/resources)
>>>>
>>> What is the impact on the test. In example, jclouds as a podling,
>>> discovered that the license header in test response files made tests
>>> fail.
>>>
>>>> For (1), I strongly believe it should not include the headers.
>>>>
>>>> For (2) and (3), I'll abstain.
>>>>
>>>> ---
>>>> There are also files inside the maven archetype. These are used to
>>>> generate
>>>> a maven project with starter classes + scripts.
>>>>
>>>> I expect the first thing almost all users of this archetype will do is to
>>>> delete the copyright header from every file they modify, because their
>>>> downstream may not be apache licensed.
>>>>
>>>> Can we exclude the headers there?
>>>>
>>> So I read what you wrote as what people will do (though removing our
>>> notice would violate the terms of the license). What I didn't see was
>>> how you plan to justify exclusion of the license headers in the scope
>>> of the policy. I'd guess the answer is no here.
>> [ALED] Do I understand you correctly that anyone creating a downstream
>> project using the maven archetype should *not* remove the headers, even
>> though we expect such users to substantially change the contents of the
>> files?
>>
>> Perhaps I didn't explain clearly: the maven archetype copies resources into
>> the structure for a new maven project. This gives someone a starting point
>> for them to write their own application blueprints. For example, it gives a
>> starting pom.xml file with a dependency on brooklyn - we expect users to
>> then add dependencies for everything else they need. Same for the Java code
>> - it just gives a basic template.
>>
> It sounds like what you are saying is that there is no creative
> content in the archetype. If that is the case, it would qualify for
> the exception to the license header policy.
>
>> I presume the code the user adds to these files would not be copyright of
>> apache, so I'd have expected the user to want to remove the headers. It
>> feels wrong to me to include the headers at all in these template files.
>>
>>>> ---
>>>> We have config files for the software installed by Brooklyn (e.g. [2]).
>>>> These are often the standard configuration file that comes with the given
>>>> software (e.g. with Cassandra), but templated (using freemarker) so we
>>>> can
>>>> easily substitute various configuration options. A user can copy this
>>>> file
>>>> to tweak the configuration for their own installs.
>>>>
>>> Where did you get the configuration file from? If it came from a third
>>> party, you can't add a license header - the license header policy only
>>> covers code developed at the ASF or granted to the ASF as part of a
>>> SGA or CCLA.
>> [ALED] Thanks, makes sense.
>>
>>>> Should we really claim apache license on that, by including the header?
>>>>
>>>> Also note that apache cassandra (where the file came from) does not have
>>>> the
>>>> header in this file, presumably because it is expected to be modified by
>>>> the
>>>> end user:
>>>> https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml
>>>>
>>> If it's third party (even if that third party is another ASF project)
>>> you should assume that you don't have the rights to change it.
>>>


Mime
View raw message