brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: license headers and config section
Date Sat, 20 Sep 2014 02:35:16 GMT
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.

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

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

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

> Interesting they also don't include it in the test configuration file, which
> presumably no user should be modifying.
> https://github.com/apache/cassandra/blob/trunk/test/conf/cassandra.yaml
>
> Aled
>
> p.s. double-checking what some other apache projects do, surprised to see
> wording like "WSO2 Inc. licenses this file to you under the Apache License"
> [3]!

So that's a third-party dependency. The ASF has no claim to that file
itself, and WSO2 holds the copyright and deals with the license
header. We aren't authorized to change that, and it would be a mistake
to do so. That doesn't mean that Stratos or any other project is
perfect - as a matter of fact, that's worth creating a patch for the
missing notice in the NOTICE file.

>
> [1]
> https://github.com/apache/incubator-brooklyn/blob/master/docs/use/guide/defining-applications/example_yaml/simple-vm.yaml
> [2]
> https://github.com/apache/incubator-brooklyn/blob/master/software/nosql/src/main/resources/brooklyn/entity/nosql/cassandra/cassandra-2.0.yaml
> [3]
> https://github.com/apache/stratos/blob/master/dependencies/org.wso2.carbon.ui/src/main/resources/web/docs/about.html
>
>
> On 19/09/2014 09:03, Alex Heneveld wrote:
>>
>>
>> David-  Thanks.
>>
>> Chip, mentors-  Appreciate your thoughts.
>>
>>
>> The issue is that many of the HTML files are templates.  Many are just
>> one-line.  They'll be included hundreds of times, or thousands if it's a big
>> (in-memory) table when pages are rendered.  So it has significant
>> performance and memory impact.
>>
>> It is only those templates which have had the header removed.  All the
>> base HTML files include the header.
>>
>> I don't know if it makes a difference but these template files are not in
>> the distributables directly (wrt the condition that "human readable files in
>> the distribution); they are only inside the WAR inside the distributable and
>> there is already a LICENSE inside the WAR.
>>
>> Given the above would this be alright?  Or if not can you suggest how
>> other projects resolve this?
>>
>> Cheers
>> Alex
>>
>>
>> On 19/09/2014 07:06, David Nalley wrote:
>>>
>>> Hi Alex,
>>>
>>> So expect this to be challenged when your first release hits the IPMC
>>> (or even when mentors are reviewing code)
>>> Specifically, saving space or bandwidth isn't a good justification for
>>> not having a license header; from a policy perspective. There have
>>> been discussions in the past about using a shorter license header -
>>> but I'd argue that it's probably not in the best interest of folks
>>> trying to get a podlings first release out to engage on that issue.
>>>
>>> Chip; or other mentors - anyone feel I am off base here?
>>>
>>> --David
>>>
>>> On Wed, Sep 17, 2014 at 5:17 AM, Alex Heneveld
>>> <alex.heneveld@cloudsoftcorp.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've prepared a PR #169 which removes the license headers from the YAML
>>>> blueprints, as discussed.  The reason was that these are used as
>>>> examples,
>>>> often cutting and pasting, and having the license really gets in the way
>>>> at
>>>> runtime.  (You can't see the blueprint when you paste the YAML into the
>>>> GUI,
>>>> all you see are the headers!)
>>>>
>>>> I've also remove it from most of the HTML source pages:  I don't think
>>>> we
>>>> realized the implication of putting them there -- since most of the HTML
>>>> pages are templates, the license header ends up included in the
>>>> resulting
>>>> HTML hundreds of times!  This bloats the pages and slows down
>>>> processing.
>>>>
>>>> The header is still included in the root index.html which is used for
>>>> every
>>>> page -- so it appears in every page at runtime.  It is also in every CSS
>>>> and
>>>> JS, where the optimizer can remove it so there is no runtime impact.
>>>>
>>>> I think this is the best compromise but of course if there is guidance
>>>> to
>>>> the contrary we can reconsider.
>>>>
>>>> I have also moved the config section to the summary tab, to try that
>>>> out.
>>>> [#168]
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> [#169]  https://github.com/apache/incubator-brooklyn/pull/169
>>>> [#168]  https://github.com/apache/incubator-brooklyn/pull/168
>>
>>
>

Mime
View raw message