On further research:

   -

   With few exceptions
   <https://www.apache.org/legal/src-headers.html#faq-exceptions>, all
   human-readable Apache-developed files that are included within a
   distribution must include the header text
   <https://www.apache.org/legal/src-headers.html#header-text>.
   Documentation, including web site documentation distributed with the
   release, may include the header text within some form of metadata (such as
   HTML comments) or as a header or footer appearing in the visible
   documentation.
   - A file without any degree of creativity in either its literal elements
   or its structure is not protected by copyright law; therefore, such a file
   does not require a license header. If in doubt about the extent of the
   file's creativity, add the license header to the file.  PMCs should use
   their judgement, err on having a source header and contact legal-discuss@
   if unsure.  It may make sense for some other files to have no license
   header. Three examples are:


   - Short informational text files; for example README, INSTALL files. The
      expectation is that these files make it obvious which product they relate
      to.
      - Test data for which the addition of a source header would cause the
      tests to fail.
      - 'Snippet' files that are included in a larger file, when the larger
      file would have duplicate licensing headers.


So add headers to files that can take them and the headers should include
the text found on https://www.apache.org/legal/src-headers.html

Claude

On Tue, Feb 21, 2023 at 11:41 AM PJ Fanning <fannin...@gmail.com> wrote:

> The typesafe config library support comments and the sbt-header plugin
> that we use to automate header checks and autocreation also has
> built-in support for conf files.
>
> On Tue, 21 Feb 2023 at 12:38, Claude Warren, Jr
> <claude.war...@aiven.io.invalid> wrote:
> >
> > GPL is a much more restrictive license.  I think by inclusion in the
> > package with the Apache license the configuration files are transitively
> > under the Apache license, though a header would make that clear: either
> in
> > or out.  I don't know of any issues with the Apache license and a quick
> > survey of the projects I work on show that Jena and Commons Collections
> do
> > include license statements, while Cassandra does not.
> >
> > Adding the license feels like a proactive defense in that it just
> prohibits
> > someone else from claiming copyright and prohibiting our use of it at
> some
> > later date.
> >
> > I would add the headers to the configs if the configs have a mechanism to
> > add comments.  Obviously, any format that does not support comments can
> not
> > have a license header.
> >
> > Claude
> >
> > Claude
> >
> > On Tue, Feb 21, 2023 at 11:14 AM Matthew Benedict de Detrich
> > <matthew.dedetr...@aiven.io.invalid> wrote:
> >
> > > > If someone wants to change the config in their apps (that use our
> > > libs), they modify their application.conf files.
> > >
> > > It's on this point that the Apache license is not ideal, even if you
> create
> > > the configuration files from scratch (which not everyone does)
> "proving"
> > > that you did it from scratch versus copying an existing reference.conf
> is
> > > another thing which in specific circumstances can be problematic
> (that's
> > > exactly what
> https://mariadb.com/kb/en/mariadb-configuration-file-license/
> > > is describing).
> > >
> > > I understand that other projects have added the Apache license to their
> > > conf files (note that this is not universal), my impression is that
> this
> > > was done out of habit and hence them putting it there was a large
> oversight
> > > that was done without proper thought as to what it means. I imagine
> it's
> > > also a lot harder to remove the header once it's added.
> > >
> > > On Tue, Feb 21, 2023 at 11:42 AM PJ Fanning <fannin...@gmail.com>
> wrote:
> > >
> > > > I'd prefer no license to a non Apache license - by a large margin.
> > > >
> > > > The reference.conf files are our files. They are static files that we
> > > > can choose to modify in releases.
> > > > If someone wants to change the config in their apps (that use our
> > > > libs), they modify their application.conf files.
> > > >
> > > >
> > > > On Tue, 21 Feb 2023 at 11:34, Matthew Benedict de Detrich
> > > > <matthew.dedetr...@aiven.io.invalid> wrote:
> > > > >
> > > > > Also to add, I don't necessarily have a problem with adding a
> license
> > > to
> > > > > the conf files but if we do so in my view Apache 2 is not the ideal
> > > > license
> > > > > for reasons stated earlier. If we want to go down this route then
> an
> > > > > artistic license such as CC-BY (or any of its variants) would be
> more
> > > > > appropriate.
> > > > >
> > > > > On Tue, Feb 21, 2023 at 10:54 AM PJ Fanning <fannin...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Most Apache projects appear to put Apache license headers on
> > > virtually
> > > > > > every file in their source repositories, including:
> > > > > > * XML, YAML, etc. files that are used for runtime configuration
> > > > > > * Build scripts
> > > > > > * Shell scripts
> > > > > > * markdown files
> > > > > >
> > > > > > I have seen no evidence that HOCON conf files need to be treated
> as
> > > an
> > > > > > exception, The Typesafe config lib seems to handle comments fine.
> > > > > >
> > > > > > If the general consensus is to leave the headers off, then
> that's ok.
> > > > > > Until the Incubator PMC members have a look, we will not really
> know
> > > > > > one way or the other. The Apache RAT check will list these conf
> files
> > > > > > as not having headers and this could lead to -1s on our releases.
> > > > > >
> > > > > > On Tue, 21 Feb 2023 at 10:12, Matthew Benedict de Detrich
> > > > > > <matthew.dedetr...@aiven.io.invalid> wrote:
> > > > > > >
> > > > > > > DISCLAIMER: IANAL
> > > > > > >
> > > > > > > Recently some PR's/discussion has opened up on github regarding
> > > > whether
> > > > > > we
> > > > > > > should be putting Apache Headers on configuration files (i.e.
> > > > > > > reference.conf files). As some people already know, we had to
> > > > undergo a
> > > > > > > process to add the headers to source files but in my view
> putting
> > > the
> > > > > > > Apache header on configuration files is at best completely
> > > > unnecessary
> > > > > > and
> > > > > > > in some cases can be harmful. For those not that familiar with
> > > > typesafe
> > > > > > > reference.conf files, you can treat them the exact same way as
> Java
> > > > > > > .properties files.
> > > > > > >
> > > > > > > My reasoning is that configuration files are treated completely
> > > > > > > separately compared to source files, in this sense they are
> much
> > > more
> > > > > > akin
> > > > > > > to documentation rather than source of a project. The
> > > > > > > protections/stipulations provided by the Apache license
> definitely
> > > > makes
> > > > > > > sense for source contents, but they can be overly
> > > > excessive/restrictive
> > > > > > > when placed on a conf file and one example where this can cause
> > > > problems
> > > > > > is
> > > > > > > cases like
> > > > https://mariadb.com/kb/en/mariadb-configuration-file-license/
> > > > > > .
> > > > > > >
> > > > > > > In summary the content in configuration files have the
> expectation
> > > > to be
> > > > > > > copied and worked on (i.e. copying the base configuration file
> and
> > > > > > changing
> > > > > > > the default values is typical for users) and there shouldn't
> be any
> > > > > > > restrictions on this. Furthermore this content is not
> expressive
> > > > enough
> > > > > > to
> > > > > > > be considered of value when it comes to things like copyright
> (I
> > > > believe
> > > > > > > this is one of the major reasons why there is no Lightbend
> > > copyright
> > > > > > header
> > > > > > > for conf files). If the Lightbend header happened to already
> exist
> > > > in the
> > > > > > > configuration files there would be sense in biting the bullet
> but
> > > > since
> > > > > > > this is not the case to me I see it as preferable if we just
> leave
> > > > the
> > > > > > conf
> > > > > > > files.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Matthew de Detrich
> > > > > > >
> > > > > > > *Aiven Deutschland GmbH*
> > > > > > >
> > > > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > > > >
> > > > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > > > >
> > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > > > >
> > > > > > > *m:* +491603708037
> > > > > > >
> > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Matthew de Detrich
> > > > >
> > > > > *Aiven Deutschland GmbH*
> > > > >
> > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > >
> > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > >
> > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > >
> > > > > *m:* +491603708037
> > > > >
> > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org
> > > > For additional commands, e-mail: dev-h...@pekko.apache.org
> > > >
> > > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org
> For additional commands, e-mail: dev-h...@pekko.apache.org
>
>

Reply via email to