You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@pekko.apache.org by Matthew Benedict de Detrich <ma...@aiven.io.INVALID> on 2023/02/21 09:12:12 UTC

[DISCUSS] Do we need to put Apache headers on configuration files

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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.

My reading of all the information so far yields two conclusions:

   1. We should put a license statement into the configuration files where
   possible.
   2. We can not put a more permissive license statement than was in the
   file when we got it.

So unless the configuration file already has a more permissive license
statement in it we have to assume that it is Apache 2 licensed.

Claude


On Tue, Feb 28, 2023 at 11:22 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:

> > 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.
>
> Right, this was raised before but there are 2 points here (IANAL
> disclaimer)
>
> * Some people actually do copy the configuration (or more realistically
> copy it and remove the parts that they don't need). There are other use
> cases as well, i.e. think of software that integrates with some part of
> pekko and includes this file as a default config that is fed into Pekko
> (this is actually similar to the problem stated at
> https://mariadb.com/kb/en/mariadb-configuration-file-license/)
> * More critically from a legal perspective, if there is a legal issue you
> would have to **prove** that you wrote the file from scratch rather than
> being inspired from the original *.conf file, and not only that but you
> would also have to prove that you wrote that configuration file **without**
> reading/seeing the original configuration file. The thinking here is the
> same as a Pekko contributor not reading code that has been mainlined into
> Akka BSL if they are implementing an equivalent feature, or in the case of
> Scala.js when implementing certain parts of Java stdlib contributors were
> not allowed to read source code from the JVM (due to it being an
> incompatible GPL2 classpath exception license)
>
> Granted these kinds of cases are quite rare and such a situation occurring
> can be considered perverse, but on the assumption that you have some sought
> of legal discrepancy with a configuration file this is the issue at hand as
> far as I understand it. Ultimately if you want to be as "legally correct"
> as possible you should use the license that matches the use case and the
> expectations of copyright, and the primary point here is that it's not
> ideal for users of Pekko to, technically speaking, be unable to use a
> configuration file because they are for example integration it into an
> existing GPL/LGPL codebase which cannot (for legal reasons) include the
> Apache license (but wouldn't have issues with an MIT-0 license). This is
> essentially what the previously mentioned MariaDB problem was.
>
> Now this is definitely not a major issue because as noted everyone here
> turns a blind eye to this specific use case, but it's still a blind eye and
> apparently in some cases you cannot ignore this.
>
> On Tue, Feb 28, 2023 at 11:42 AM Johannes Rudolph <
> johannes.rudolph@gmail.com> wrote:
>
> > 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
> > <ma...@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.rudolph@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
> > > > <ma...@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
> > > > > <cl...@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
> > > > > > <ma...@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
> > > > > > > <cl...@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 <
> > fanningpj@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
> > > > > > > > > <cl...@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
> > > > > > > > > > <ma...@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 <
> > > > fanningpj@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
> > > > > > > > > > > > <ma...@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 <
> > > > > > > fanningpj@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
> > > > > > > > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > > > > For additional commands, e-mail:
> > > > dev-help@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.dedetrich@aiven.io
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > dev-help@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.dedetrich@aiven.io
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@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.dedetrich@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.

> 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.

Right, this was raised before but there are 2 points here (IANAL disclaimer)

* Some people actually do copy the configuration (or more realistically
copy it and remove the parts that they don't need). There are other use
cases as well, i.e. think of software that integrates with some part of
pekko and includes this file as a default config that is fed into Pekko
(this is actually similar to the problem stated at
https://mariadb.com/kb/en/mariadb-configuration-file-license/)
* More critically from a legal perspective, if there is a legal issue you
would have to **prove** that you wrote the file from scratch rather than
being inspired from the original *.conf file, and not only that but you
would also have to prove that you wrote that configuration file **without**
reading/seeing the original configuration file. The thinking here is the
same as a Pekko contributor not reading code that has been mainlined into
Akka BSL if they are implementing an equivalent feature, or in the case of
Scala.js when implementing certain parts of Java stdlib contributors were
not allowed to read source code from the JVM (due to it being an
incompatible GPL2 classpath exception license)

Granted these kinds of cases are quite rare and such a situation occurring
can be considered perverse, but on the assumption that you have some sought
of legal discrepancy with a configuration file this is the issue at hand as
far as I understand it. Ultimately if you want to be as "legally correct"
as possible you should use the license that matches the use case and the
expectations of copyright, and the primary point here is that it's not
ideal for users of Pekko to, technically speaking, be unable to use a
configuration file because they are for example integration it into an
existing GPL/LGPL codebase which cannot (for legal reasons) include the
Apache license (but wouldn't have issues with an MIT-0 license). This is
essentially what the previously mentioned MariaDB problem was.

Now this is definitely not a major issue because as noted everyone here
turns a blind eye to this specific use case, but it's still a blind eye and
apparently in some cases you cannot ignore this.

On Tue, Feb 28, 2023 at 11:42 AM Johannes Rudolph <
johannes.rudolph@gmail.com> wrote:

> 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
> <ma...@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.rudolph@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
> > > <ma...@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
> > > > <cl...@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
> > > > > <ma...@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
> > > > > > <cl...@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 <
> fanningpj@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
> > > > > > > > <cl...@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
> > > > > > > > > <ma...@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 <
> > > fanningpj@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
> > > > > > > > > > > <ma...@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 <
> > > > > > fanningpj@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
> > > > > > > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail:
> > > dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > > > For additional commands, e-mail:
> > > dev-help@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.dedetrich@aiven.io
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> dev-help@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.dedetrich@aiven.io
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@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.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Johannes Rudolph <jo...@gmail.com>.

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
<ma...@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.rudolph@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
> > <ma...@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
> > > <cl...@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
> > > > <ma...@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
> > > > > <cl...@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 <fa...@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
> > > > > > > <cl...@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
> > > > > > > > <ma...@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 <
> > fanningpj@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
> > > > > > > > > > <ma...@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 <
> > > > > fanningpj@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
> > > > > > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > dev-help@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.dedetrich@aiven.io
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > > > >
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.

> 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.rudolph@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
> <ma...@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
> > <cl...@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
> > > <ma...@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
> > > > <cl...@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 <fa...@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
> > > > > > <cl...@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
> > > > > > > <ma...@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 <
> fanningpj@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
> > > > > > > > > <ma...@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 <
> > > > fanningpj@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
> > > > > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> dev-help@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.dedetrich@aiven.io
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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.dedetrich@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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Johannes Rudolph <jo...@gmail.com>.

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
<ma...@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
> <cl...@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
> > <ma...@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
> > > <cl...@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 <fa...@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
> > > > > <cl...@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
> > > > > > <ma...@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 <fanningpj@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
> > > > > > > > <ma...@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 <
> > > fanningpj@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
> > > > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > > > >
> > > > > > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@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.dedetrich@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.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.

> 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
<cl...@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
> <ma...@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
> > <cl...@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 <fa...@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
> > > > <cl...@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
> > > > > <ma...@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 <fanningpj@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
> > > > > > > <ma...@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 <
> > fanningpj@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
> > > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > > >
> > > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.

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
<ma...@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
> <cl...@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 <fa...@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
> > > <cl...@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
> > > > <ma...@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 <fa...@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
> > > > > > <ma...@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 <
> fanningpj@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
> > > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.

>  - 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
<cl...@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 <fa...@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
> > <cl...@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
> > > <ma...@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 <fa...@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
> > > > > <ma...@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 <fanningpj@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
> > > > > > > <ma...@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.dedetrich@aiven.io
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.

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 <fa...@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
> <cl...@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
> > <ma...@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 <fa...@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
> > > > <ma...@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 <fa...@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
> > > > > > <ma...@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.dedetrich@aiven.io
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by PJ Fanning <fa...@gmail.com>.

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
<cl...@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
> <ma...@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 <fa...@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
> > > <ma...@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 <fa...@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
> > > > > <ma...@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.dedetrich@aiven.io
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.

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
<ma...@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 <fa...@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
> > <ma...@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 <fa...@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
> > > > <ma...@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.dedetrich@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.

> 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 <fa...@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
> <ma...@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 <fa...@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
> > > <ma...@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.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by PJ Fanning <fa...@gmail.com>.

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
<ma...@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 <fa...@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
> > <ma...@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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.

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 <fa...@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
> <ma...@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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io

Re: [DISCUSS] Do we need to put Apache headers on configuration files

Posted by PJ Fanning <fa...@gmail.com>.

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
<ma...@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.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org