I've read that, so the rest of my paragraph you quoted was basically a direct counter to that argument :)
With HOCON, the configuration files are usually not an example to copy from, so the concern of overly restrictive configuration is not a major one. But apart from that we won't have a choice in that question for the other reasons stated... On Tue, Feb 28, 2023 at 11:02 AM Matthew Benedict de Detrich <matthew.dedetr...@aiven.io.invalid> wrote: > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
