> - A file without any degree of creativity in either its literal elements or its structure is not protected by copyright law; therefore, such a file does not require a license header.
I guess this is the part that's open to interpretation. In my view I don't see how configuration files have any degree of creativity (which is the same view that was expressed in the references I posted earlier), they either work or they don't (i.e. if you apply any form of creativity a configuration file then it will just fail to parse/serialize in the main library or its completely mundane, i.e. the difference between changing a default value of some.timeout=50ms vs some.timeout=100ms can hardly be considered creative). The bigger point is whether this is a battle worth fighting or spending effort on, and I would suspect that the general answer would be no. On Tue, Feb 21, 2023 at 2:16 PM Claude Warren, Jr <[email protected]> wrote: > On further research: > > > - > > With few exceptions > <https://www.apache.org/legal/src-headers.html#faq-exceptions>, all > human-readable Apache-developed files that are included within a > distribution must include the header text > <https://www.apache.org/legal/src-headers.html#header-text>. > Documentation, including web site documentation distributed with the > release, may include the header text within some form of metadata (such > as > HTML comments) or as a header or footer appearing in the visible > documentation. > - A file without any degree of creativity in either its literal elements > or its structure is not protected by copyright law; therefore, such a > file > does not require a license header. If in doubt about the extent of the > file's creativity, add the license header to the file. PMCs should use > their judgement, err on having a source header and contact > legal-discuss@ > if unsure. It may make sense for some other files 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 included in a larger file, when the larger > file would have duplicate licensing headers. > > > So add headers to files that can take them and the headers should include > the text found on https://www.apache.org/legal/src-headers.html > > Claude > > On Tue, Feb 21, 2023 at 11:41 AM PJ Fanning <[email protected]> wrote: > > > The typesafe config library support comments and the sbt-header plugin > > that we use to automate header checks and autocreation also has > > built-in support for conf files. > > > > On Tue, 21 Feb 2023 at 12:38, Claude Warren, Jr > > <[email protected]> wrote: > > > > > > GPL is a much more restrictive license. I think by inclusion in the > > > package with the Apache license the configuration files are > transitively > > > under the Apache license, though a header would make that clear: either > > in > > > or out. I don't know of any issues with the Apache license and a quick > > > survey of the projects I work on show that Jena and Commons Collections > > do > > > include license statements, while Cassandra does not. > > > > > > Adding the license feels like a proactive defense in that it just > > prohibits > > > someone else from claiming copyright and prohibiting our use of it at > > some > > > later date. > > > > > > I would add the headers to the configs if the configs have a mechanism > to > > > add comments. Obviously, any format that does not support comments can > > not > > > have a license header. > > > > > > Claude > > > > > > Claude > > > > > > On Tue, Feb 21, 2023 at 11:14 AM Matthew Benedict de Detrich > > > <[email protected]> wrote: > > > > > > > > If someone wants to change the config in their apps (that use our > > > > libs), they modify their application.conf files. > > > > > > > > It's on this point that the Apache license is not ideal, even if you > > create > > > > the configuration files from scratch (which not everyone does) > > "proving" > > > > that you did it from scratch versus copying an existing > reference.conf > > is > > > > another thing which in specific circumstances can be problematic > > (that's > > > > exactly what > > https://mariadb.com/kb/en/mariadb-configuration-file-license/ > > > > is describing). > > > > > > > > I understand that other projects have added the Apache license to > their > > > > conf files (note that this is not universal), my impression is that > > this > > > > was done out of habit and hence them putting it there was a large > > oversight > > > > that was done without proper thought as to what it means. I imagine > > it's > > > > also a lot harder to remove the header once it's added. > > > > > > > > On Tue, Feb 21, 2023 at 11:42 AM PJ Fanning <[email protected]> > > wrote: > > > > > > > > > I'd prefer no license to a non Apache license - by a large margin. > > > > > > > > > > The reference.conf files are our files. They are static files that > we > > > > > can choose to modify in releases. > > > > > If someone wants to change the config in their apps (that use our > > > > > libs), they modify their application.conf files. > > > > > > > > > > > > > > > On Tue, 21 Feb 2023 at 11:34, Matthew Benedict de Detrich > > > > > <[email protected]> wrote: > > > > > > > > > > > > Also to add, I don't necessarily have a problem with adding a > > license > > > > to > > > > > > the conf files but if we do so in my view Apache 2 is not the > ideal > > > > > license > > > > > > for reasons stated earlier. If we want to go down this route then > > an > > > > > > artistic license such as CC-BY (or any of its variants) would be > > more > > > > > > appropriate. > > > > > > > > > > > > On Tue, Feb 21, 2023 at 10:54 AM PJ Fanning <[email protected] > > > > > > wrote: > > > > > > > > > > > > > Most Apache projects appear to put Apache license headers on > > > > virtually > > > > > > > every file in their source repositories, including: > > > > > > > * XML, YAML, etc. files that are used for runtime configuration > > > > > > > * Build scripts > > > > > > > * Shell scripts > > > > > > > * markdown files > > > > > > > > > > > > > > I have seen no evidence that HOCON conf files need to be > treated > > as > > > > an > > > > > > > exception, The Typesafe config lib seems to handle comments > fine. > > > > > > > > > > > > > > If the general consensus is to leave the headers off, then > > that's ok. > > > > > > > Until the Incubator PMC members have a look, we will not really > > know > > > > > > > one way or the other. The Apache RAT check will list these conf > > files > > > > > > > as not having headers and this could lead to -1s on our > releases. > > > > > > > > > > > > > > On Tue, 21 Feb 2023 at 10:12, Matthew Benedict de Detrich > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > DISCLAIMER: IANAL > > > > > > > > > > > > > > > > Recently some PR's/discussion has opened up on github > regarding > > > > > whether > > > > > > > we > > > > > > > > should be putting Apache Headers on configuration files (i.e. > > > > > > > > reference.conf files). As some people already know, we had to > > > > > undergo a > > > > > > > > process to add the headers to source files but in my view > > putting > > > > the > > > > > > > > Apache header on configuration files is at best completely > > > > > unnecessary > > > > > > > and > > > > > > > > in some cases can be harmful. For those not that familiar > with > > > > > typesafe > > > > > > > > reference.conf files, you can treat them the exact same way > as > > Java > > > > > > > > .properties files. > > > > > > > > > > > > > > > > My reasoning is that configuration files are treated > completely > > > > > > > > separately compared to source files, in this sense they are > > much > > > > more > > > > > > > akin > > > > > > > > to documentation rather than source of a project. The > > > > > > > > protections/stipulations provided by the Apache license > > definitely > > > > > makes > > > > > > > > sense for source contents, but they can be overly > > > > > excessive/restrictive > > > > > > > > when placed on a conf file and one example where this can > cause > > > > > problems > > > > > > > is > > > > > > > > cases like > > > > > https://mariadb.com/kb/en/mariadb-configuration-file-license/ > > > > > > > . > > > > > > > > > > > > > > > > In summary the content in configuration files have the > > expectation > > > > > to be > > > > > > > > copied and worked on (i.e. copying the base configuration > file > > and > > > > > > > changing > > > > > > > > the default values is typical for users) and there shouldn't > > be any > > > > > > > > restrictions on this. Furthermore this content is not > > expressive > > > > > enough > > > > > > > to > > > > > > > > be considered of value when it comes to things like copyright > > (I > > > > > believe > > > > > > > > this is one of the major reasons why there is no Lightbend > > > > copyright > > > > > > > header > > > > > > > > for conf files). If the Lightbend header happened to already > > exist > > > > > in the > > > > > > > > configuration files there would be sense in biting the bullet > > but > > > > > since > > > > > > > > this is not the case to me I see it as preferable if we just > > leave > > > > > the > > > > > > > conf > > > > > > > > files. > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
