> I don't quite follow the original argument that configuration files need to be treated differently than any other source file.
The argument is similar as to why wiki/documentation is nowadays typically licensed as CC-BY or one of its derivatives. The general premise is that configuration files in practice are treated quite differently from the main codebase. They are often separate from the main codebase (i.e. the files are not used to compile the main program) and more critically you don't want to restrict potential users from referencing/deriving the configuration file due to overly restrictive license and/or copyright. The response from Henri at https://issues.apache.org/jira/browse/LEGAL-633?focusedCommentId=17692908&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17692908 put it quite well > Configuration files are interesting. As you say, the configuration values themselves often lack the expression to have a copyright license apply, but the files are usually full of expressive comments. The 'simplest' configuration files have nothing in them but comments, with the defaults being literally defaults in the code and not just initial settings. At this point, a configuration file is documentation. > Largely I think configuration files, much like sample code, end up coming under a de-facto equivalent to https://spdx.org/licenses/MIT-0.html with no licensor caring about their licensing. The only philosophical line seems to be whether the configuration files/sample code may be used for any purpose or if (for more restrictive licensing) they may only be used with the product they configure or provide an example for. On Tue, Feb 28, 2023 at 10:13 AM Johannes Rudolph < johannes.rudo...@gmail.com> wrote: > I don't mind adding license headers, long or short. In any case, we > will have to use the APL2 license because they are part of an existing > code base licensed under APL2 and we should not judge on whether or > not they would actually be copyrightable or in which form or to which > extent. > > I don't quite follow the original argument that configuration files > need to be treated differently than any other source file. In fact, > they are way of refactoring and documenting certain values out of the > regular code base into a dedicated file. This is especially true for > HOCON files, which are usually treated unlike configuration files for > e.g. Linux services where it is expected that users copy the whole > template into their project and adopt to their needs. With HOCON files > you basically never do this but create your own configuration file > overriding the subset of variables that you care about. In that way, a > "use" of the configuration is not much different than a use of any API > that uses the names from the interface that a library defines. > > (Which incidentally might even also work for GPL because you don't > have to copy or redistribute from the original code but only "use" the > configuration using the identifiers defined by the library.) > > Regarding the length of the header maybe adding extra verbosity. I > think the same argument applies here, the reference configuration > files are already verbose and comprehensive, similarly to other source > code, it should be easy enough to skip to places you care about (e.g. > using Ctrl-Click in IDEs to identifiers in question). > > On Sun, Feb 26, 2023 at 6:00 PM Matthew Benedict de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > Do configuration files required headers? probably. Can we ask legal if > > they do? yes. Will that take time to get a response? Absolutely. Will > > that open a can of worms? probably. Do we have a bigger can to put the > > worms back into? No. Can we avoid this problem altogether? Yes. > > > > So unfortunately I ended up creating a legal ticket at > > https://issues.apache.org/jira/browse/LEGAL-633 right at the same time > you > > sent message but since we got a response the tl;dr is that it is > recommend > > we do add a header text but in the shortened SPDX-License-Identifier > format > > (which I believe in our case would be Apache-2.0) rather than the entire > > header typically used for source files. > > > > In more detail (and for those that are curious) as can be seen in the > > ticket there is some legitimacy to the concerns I raised earlier (which > is > > that license headers for config files end up de-facto being treated > > like MIT-0 regardless of what license they happen to have, or not have) > but > > because ASF doesn't have a policy for adding licenses that differ from > > Apache 2 it was recommended to add the shortened SPDX-License-Identifier > to > > the config files. > > > > On Wed, Feb 22, 2023 at 9:12 AM Claude Warren, Jr > > <claude.war...@aiven.io.invalid> wrote: > > > > > This is not a hill I want to die on. I suggest adding headers to all > > > configuration formats that have a comment line and be done with it as > we > > > have far more important issues to deal with. > > > > > > Do configuration files required headers? probably. Can we ask legal if > > > they do? yes. Will that take time to get a response? Absolutely. Will > > > that open a can of worms? probably. Do we have a bigger can to put the > > > worms back into? No. Can we avoid this problem altogether? Yes. > > > > > > I strongly recommend just adding the headers. > > > > > > > > > On Tue, Feb 21, 2023 at 2:58 PM Matthew Benedict de Detrich > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > - 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 > > > > <claude.war...@aiven.io.invalid> 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 <fannin...@gmail.com> > > > 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 > > > > > > <claude.war...@aiven.io.invalid> 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 > > > > > > > <matthew.dedetr...@aiven.io.invalid> 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 < > fannin...@gmail.com > > > > > > > > > > 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 > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> 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 < > > > > fannin...@gmail.com > > > > > > > > > > > > > > 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 > > > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> 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:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@pekko.apache.org > > > > > > > > > > > For additional commands, e-mail: > dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > 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:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > 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:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > 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:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > -- > > > > 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:* matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- 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:* matthew.dedetr...@aiven.io
