Adding the license

[PierreSmits]

This will bring the license header to various files

[ulises]

squash and you get my 👍

[PierreSmits]

Thank you.

But I don't understand what you mean.

[ulises]

I meant that all commits should be squashed into a single commit. Then you get my +1 :)

[PierreSmits]

Thank you. I'll regard that as a nice to have, and will (try to) work towards it for future actions.

[Humbedooh]

Please see http://ponymail.incubator.apache.org/contribute.html#gitworkflow for instructions on how to squash/rebase your PR

[Humbedooh]

I am inclined to -1 this. There is far too many unnecessary changes. The markdown files and configuration snippets do NOT need license headers. Documentation and examples do historically speaking never include the license.

[PierreSmits]

Better check with ASF Legal as documentation is also part of the works of a product. The assertion that 'documentation and examples historically speaking never include the license' is wrong. Check the works of others in libraries (the real ones), etc.

Which changes are unnecessary and which aren't?

[Humbedooh]

see httpd for instance - we have never put licenses in our documentation there.

[Humbedooh]

the LICENSE file technically covers everything else, FWIW. When not specified, the ALv2 applies to any file without an explicit license header. We put license headers in our code for two reasons: 1) we sometimes use external dependencies which may have different licenses, and we need to be able to discern which is which, and 2) code is more typically reworked or reused by external entities, so putting license headers there makes sense. Putting it in the config files is usually....useless :)

[PierreSmits]

Rethink that again. That is why they (the smarter ones) have invented licenses of the type of CC-BY, etc.

[Humbedooh]

If you can find any place that explicitly says documentation must be licensed, then fine - but I haven't found such a policy and I don't agree that we need this. I can reach out to VP Legal and get an answer if need be.

[PierreSmits]

I will put the question to Legal.

[PierreSmits]

Done. See posting here: https://lists.apache.org/api/atom.lua?mid=47c657edfccde57e6c286ba41bfd046a2c9a44eb79b3d73acdb3af2e@%3Clegal-discuss.apache.org%3E

[justinmclean]

you may want to read/consider this:
http://www.apache.org/legal/src-headers.html#faq-docs

[Humbedooh]

Thank you for providing a factual link, Justin. This gives us some real data to assess.
http://www.apache.org/legal/src-headers.html#faq-exceptions however states that:

Other files may make sense to have no license header. Three examples are:

    Short informational text files; for example README, INSTALL files. The expectation is that these files make it obvious which product they relate to.
    Test data for which the addition of a source header would cause the tests to fail.
    'Snippet' files that are combined as form a larger file where the larger file would have duplicate licensing headers.

I would argue that the vast majority of these files (which are readme/install text files) and the configuration snippets fall under these categories.

We're not talking API reference docs here, this is purely files relating to the installation of the program as well as configuration snippets meant to be added to a larger configuration.

[Humbedooh]

To clarify; I am not against putting license headers in a select files that may warrant it. I am against accepting this PR and putting license headers in ALL files, regardless of size and whether they need it.
The change-log surely does not need a license header for instance.

[PierreSmits]

I wonder how legally different (with respect to copyright and such) the content in a readme.md file in the repository of the project on Github is from the content in a readme.html file in the website repository.

To me they are both the same, both the work of the project, both IP of the ASF, both licensable... Yet, in the html page for the website we place a copyright statement, while in the readme.md file on Github we don't.

Weird....

Best regards,

Pierre