> 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
