> 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.rudo...@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 > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > I don't quite follow the original argument that configuration files > > need to be treated differently than any other source file. > > > > The argument is similar as to why wiki/documentation is nowadays > typically > > licensed as CC-BY or one of its derivatives. The general premise is that > > configuration files in practice are treated quite differently from the > main > > codebase. They are often separate from the main codebase (i.e. the files > > are not used to compile the main program) and more critically you don't > > want to restrict potential users from referencing/deriving the > > configuration file due to overly restrictive license and/or copyright. > > > > The response from Henri at > > > https://issues.apache.org/jira/browse/LEGAL-633?focusedCommentId=17692908&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17692908 > > put it quite well > > > > > Configuration files are interesting. As you say, the configuration > values > > themselves often lack the expression to have a copyright license apply, > but > > the files are usually full of expressive comments. The 'simplest' > > configuration files have nothing in them but comments, with the defaults > > being literally defaults in the code and not just initial settings. At > this > > point, a configuration file is documentation. > > > > > Largely I think configuration files, much like sample code, end up > coming > > under a de-facto equivalent to https://spdx.org/licenses/MIT-0.html > with no > > licensor caring about their licensing. The only philosophical line seems > to > > be whether the configuration files/sample code may be used for any > purpose > > or if (for more restrictive licensing) they may only be used with the > > product they configure or provide an example for. > > > > On Tue, Feb 28, 2023 at 10:13 AM Johannes Rudolph < > > johannes.rudo...@gmail.com> wrote: > > > > > I don't mind adding license headers, long or short. In any case, we > > > will have to use the APL2 license because they are part of an existing > > > code base licensed under APL2 and we should not judge on whether or > > > not they would actually be copyrightable or in which form or to which > > > extent. > > > > > > I don't quite follow the original argument that configuration files > > > need to be treated differently than any other source file. In fact, > > > they are way of refactoring and documenting certain values out of the > > > regular code base into a dedicated file. This is especially true for > > > HOCON files, which are usually treated unlike configuration files for > > > e.g. Linux services where it is expected that users copy the whole > > > template into their project and adopt to their needs. With HOCON files > > > you basically never do this but create your own configuration file > > > overriding the subset of variables that you care about. In that way, a > > > "use" of the configuration is not much different than a use of any API > > > that uses the names from the interface that a library defines. > > > > > > (Which incidentally might even also work for GPL because you don't > > > have to copy or redistribute from the original code but only "use" the > > > configuration using the identifiers defined by the library.) > > > > > > Regarding the length of the header maybe adding extra verbosity. I > > > think the same argument applies here, the reference configuration > > > files are already verbose and comprehensive, similarly to other source > > > code, it should be easy enough to skip to places you care about (e.g. > > > using Ctrl-Click in IDEs to identifiers in question). > > > > > > On Sun, Feb 26, 2023 at 6:00 PM Matthew Benedict de Detrich > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > Do configuration files required headers? probably. Can we ask > legal if > > > > they do? yes. Will that take time to get a response? Absolutely. > Will > > > > that open a can of worms? probably. Do we have a bigger can to put > the > > > > worms back into? No. Can we avoid this problem altogether? Yes. > > > > > > > > So unfortunately I ended up creating a legal ticket at > > > > https://issues.apache.org/jira/browse/LEGAL-633 right at the same > time > > > you > > > > sent message but since we got a response the tl;dr is that it is > > > recommend > > > > we do add a header text but in the shortened SPDX-License-Identifier > > > format > > > > (which I believe in our case would be Apache-2.0) rather than the > entire > > > > header typically used for source files. > > > > > > > > In more detail (and for those that are curious) as can be seen in the > > > > ticket there is some legitimacy to the concerns I raised earlier > (which > > > is > > > > that license headers for config files end up de-facto being treated > > > > like MIT-0 regardless of what license they happen to have, or not > have) > > > but > > > > because ASF doesn't have a policy for adding licenses that differ > from > > > > Apache 2 it was recommended to add the shortened > SPDX-License-Identifier > > > to > > > > the config files. > > > > > > > > On Wed, Feb 22, 2023 at 9:12 AM Claude Warren, Jr > > > > <claude.war...@aiven.io.invalid> wrote: > > > > > > > > > This is not a hill I want to die on. I suggest adding headers to > all > > > > > configuration formats that have a comment line and be done with it > as > > > we > > > > > have far more important issues to deal with. > > > > > > > > > > Do configuration files required headers? probably. Can we ask > legal if > > > > > they do? yes. Will that take time to get a response? Absolutely. > Will > > > > > that open a can of worms? probably. Do we have a bigger can to > put the > > > > > worms back into? No. Can we avoid this problem altogether? Yes. > > > > > > > > > > I strongly recommend just adding the headers. > > > > > > > > > > > > > > > On Tue, Feb 21, 2023 at 2:58 PM Matthew Benedict de Detrich > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > - A file without any degree of creativity in either its > literal > > > > > elements > > > > > > or its structure is not protected by copyright law; therefore, > > > such a > > > > > > file > > > > > > does not require a license header. > > > > > > > > > > > > I guess this is the part that's open to interpretation. In my > view I > > > > > don't > > > > > > see how configuration files have any degree of creativity (which > is > > > the > > > > > > same view that was expressed in the references I posted earlier), > > > they > > > > > > either work or they don't (i.e. if you apply any form of > creativity a > > > > > > configuration file then it will just fail to parse/serialize in > the > > > main > > > > > > library or its completely mundane, i.e. the difference between > > > changing a > > > > > > default value of some.timeout=50ms vs some.timeout=100ms can > hardly > > > be > > > > > > considered creative). > > > > > > > > > > > > The bigger point is whether this is a battle worth fighting or > > > spending > > > > > > effort on, and I would suspect that the general answer would be > no. > > > > > > > > > > > > On Tue, Feb 21, 2023 at 2:16 PM Claude Warren, Jr > > > > > > <claude.war...@aiven.io.invalid> wrote: > > > > > > > > > > > > > On further research: > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > > > With few exceptions > > > > > > > < > https://www.apache.org/legal/src-headers.html#faq-exceptions>, > > > all > > > > > > > human-readable Apache-developed files that are included > within a > > > > > > > distribution must include the header text > > > > > > > <https://www.apache.org/legal/src-headers.html#header-text > >. > > > > > > > Documentation, including web site documentation distributed > > > with the > > > > > > > release, may include the header text within some form of > > > metadata > > > > > > (such > > > > > > > as > > > > > > > HTML comments) or as a header or footer appearing in the > visible > > > > > > > documentation. > > > > > > > - A file without any degree of creativity in either its > literal > > > > > > elements > > > > > > > or its structure is not protected by copyright law; > therefore, > > > such > > > > > a > > > > > > > file > > > > > > > does not require a license header. If in doubt about the > extent > > > of > > > > > the > > > > > > > file's creativity, add the license header to the file. PMCs > > > should > > > > > > use > > > > > > > their judgement, err on having a source header and contact > > > > > > > legal-discuss@ > > > > > > > if unsure. It may make sense for some other files to have > no > > > > > license > > > > > > > header. Three examples are: > > > > > > > > > > > > > > > > > > > > > - Short informational text files; for example README, > INSTALL > > > files. > > > > > > The > > > > > > > expectation is that these files make it obvious which > product > > > > > they > > > > > > > relate > > > > > > > to. > > > > > > > - Test data for which the addition of a source header > would > > > cause > > > > > > the > > > > > > > tests to fail. > > > > > > > - 'Snippet' files that are included in a larger file, > when > > > the > > > > > > larger > > > > > > > file would have duplicate licensing headers. > > > > > > > > > > > > > > > > > > > > > So add headers to files that can take them and the headers > should > > > > > include > > > > > > > the text found on > https://www.apache.org/legal/src-headers.html > > > > > > > > > > > > > > Claude > > > > > > > > > > > > > > On Tue, Feb 21, 2023 at 11:41 AM PJ Fanning < > fannin...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > The typesafe config library support comments and the > sbt-header > > > > > plugin > > > > > > > > that we use to automate header checks and autocreation also > has > > > > > > > > built-in support for conf files. > > > > > > > > > > > > > > > > On Tue, 21 Feb 2023 at 12:38, Claude Warren, Jr > > > > > > > > <claude.war...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > GPL is a much more restrictive license. I think by > inclusion > > > in > > > > > the > > > > > > > > > package with the Apache license the configuration files are > > > > > > > transitively > > > > > > > > > under the Apache license, though a header would make that > > > clear: > > > > > > either > > > > > > > > in > > > > > > > > > or out. I don't know of any issues with the Apache license > > > and a > > > > > > quick > > > > > > > > > survey of the projects I work on show that Jena and Commons > > > > > > Collections > > > > > > > > do > > > > > > > > > include license statements, while Cassandra does not. > > > > > > > > > > > > > > > > > > Adding the license feels like a proactive defense in that > it > > > just > > > > > > > > prohibits > > > > > > > > > someone else from claiming copyright and prohibiting our > use > > > of it > > > > > at > > > > > > > > some > > > > > > > > > later date. > > > > > > > > > > > > > > > > > > I would add the headers to the configs if the configs have > a > > > > > > mechanism > > > > > > > to > > > > > > > > > add comments. Obviously, any format that does not support > > > comments > > > > > > can > > > > > > > > not > > > > > > > > > have a license header. > > > > > > > > > > > > > > > > > > Claude > > > > > > > > > > > > > > > > > > Claude > > > > > > > > > > > > > > > > > > On Tue, Feb 21, 2023 at 11:14 AM Matthew Benedict de > Detrich > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > > > If someone wants to change the config in their apps > (that > > > use > > > > > our > > > > > > > > > > libs), they modify their application.conf files. > > > > > > > > > > > > > > > > > > > > It's on this point that the Apache license is not ideal, > > > even if > > > > > > you > > > > > > > > create > > > > > > > > > > the configuration files from scratch (which not everyone > > > does) > > > > > > > > "proving" > > > > > > > > > > that you did it from scratch versus copying an existing > > > > > > > reference.conf > > > > > > > > is > > > > > > > > > > another thing which in specific circumstances can be > > > problematic > > > > > > > > (that's > > > > > > > > > > exactly what > > > > > > > > > https://mariadb.com/kb/en/mariadb-configuration-file-license/ > > > > > > > > > > is describing). > > > > > > > > > > > > > > > > > > > > I understand that other projects have added the Apache > > > license to > > > > > > > their > > > > > > > > > > conf files (note that this is not universal), my > impression > > > is > > > > > that > > > > > > > > this > > > > > > > > > > was done out of habit and hence them putting it there > was a > > > large > > > > > > > > oversight > > > > > > > > > > that was done without proper thought as to what it > means. I > > > > > imagine > > > > > > > > it's > > > > > > > > > > also a lot harder to remove the header once it's added. > > > > > > > > > > > > > > > > > > > > On Tue, Feb 21, 2023 at 11:42 AM PJ Fanning < > > > fannin...@gmail.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > I'd prefer no license to a non Apache license - by a > large > > > > > > margin. > > > > > > > > > > > > > > > > > > > > > > The reference.conf files are our files. They are static > > > files > > > > > > that > > > > > > > we > > > > > > > > > > > can choose to modify in releases. > > > > > > > > > > > If someone wants to change the config in their apps > (that > > > use > > > > > our > > > > > > > > > > > libs), they modify their application.conf files. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 21 Feb 2023 at 11:34, Matthew Benedict de > Detrich > > > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Also to add, I don't necessarily have a problem with > > > adding a > > > > > > > > license > > > > > > > > > > to > > > > > > > > > > > > the conf files but if we do so in my view Apache 2 is > > > not the > > > > > > > ideal > > > > > > > > > > > license > > > > > > > > > > > > for reasons stated earlier. If we want to go down > this > > > route > > > > > > then > > > > > > > > an > > > > > > > > > > > > artistic license such as CC-BY (or any of its > variants) > > > would > > > > > > be > > > > > > > > more > > > > > > > > > > > > appropriate. > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 21, 2023 at 10:54 AM PJ Fanning < > > > > > > fannin...@gmail.com > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Most Apache projects appear to put Apache license > > > headers > > > > > on > > > > > > > > > > virtually > > > > > > > > > > > > > every file in their source repositories, including: > > > > > > > > > > > > > * XML, YAML, etc. files that are used for runtime > > > > > > configuration > > > > > > > > > > > > > * Build scripts > > > > > > > > > > > > > * Shell scripts > > > > > > > > > > > > > * markdown files > > > > > > > > > > > > > > > > > > > > > > > > > > I have seen no evidence that HOCON conf files need > to > > > be > > > > > > > treated > > > > > > > > as > > > > > > > > > > an > > > > > > > > > > > > > exception, The Typesafe config lib seems to handle > > > comments > > > > > > > fine. > > > > > > > > > > > > > > > > > > > > > > > > > > If the general consensus is to leave the headers > off, > > > then > > > > > > > > that's ok. > > > > > > > > > > > > > Until the Incubator PMC members have a look, we > will > > > not > > > > > > really > > > > > > > > know > > > > > > > > > > > > > one way or the other. The Apache RAT check will > list > > > these > > > > > > conf > > > > > > > > files > > > > > > > > > > > > > as not having headers and this could lead to -1s > on our > > > > > > > releases. > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 21 Feb 2023 at 10:12, Matthew Benedict de > > > Detrich > > > > > > > > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: IANAL > > > > > > > > > > > > > > > > > > > > > > > > > > > > Recently some PR's/discussion has opened up on > github > > > > > > > regarding > > > > > > > > > > > whether > > > > > > > > > > > > > we > > > > > > > > > > > > > > should be putting Apache Headers on configuration > > > files > > > > > > (i.e. > > > > > > > > > > > > > > reference.conf files). As some people already > know, > > > we > > > > > had > > > > > > to > > > > > > > > > > > undergo a > > > > > > > > > > > > > > process to add the headers to source files but > in my > > > view > > > > > > > > putting > > > > > > > > > > the > > > > > > > > > > > > > > Apache header on configuration files is at best > > > > > completely > > > > > > > > > > > unnecessary > > > > > > > > > > > > > and > > > > > > > > > > > > > > in some cases can be harmful. For those not that > > > familiar > > > > > > > with > > > > > > > > > > > typesafe > > > > > > > > > > > > > > reference.conf files, you can treat them the > exact > > > same > > > > > way > > > > > > > as > > > > > > > > Java > > > > > > > > > > > > > > .properties files. > > > > > > > > > > > > > > > > > > > > > > > > > > > > My reasoning is that configuration files are > treated > > > > > > > completely > > > > > > > > > > > > > > separately compared to source files, in this > sense > > > they > > > > > are > > > > > > > > much > > > > > > > > > > more > > > > > > > > > > > > > akin > > > > > > > > > > > > > > to documentation rather than source of a > project. The > > > > > > > > > > > > > > protections/stipulations provided by the Apache > > > license > > > > > > > > definitely > > > > > > > > > > > makes > > > > > > > > > > > > > > sense for source contents, but they can be overly > > > > > > > > > > > excessive/restrictive > > > > > > > > > > > > > > when placed on a conf file and one example where > > > this can > > > > > > > cause > > > > > > > > > > > problems > > > > > > > > > > > > > is > > > > > > > > > > > > > > cases like > > > > > > > > > > > > > > https://mariadb.com/kb/en/mariadb-configuration-file-license/ > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > > > > In summary the content in configuration files > have > > > the > > > > > > > > expectation > > > > > > > > > > > to be > > > > > > > > > > > > > > copied and worked on (i.e. copying the base > > > configuration > > > > > > > file > > > > > > > > and > > > > > > > > > > > > > changing > > > > > > > > > > > > > > the default values is typical for users) and > there > > > > > > shouldn't > > > > > > > > be any > > > > > > > > > > > > > > restrictions on this. Furthermore this content > is not > > > > > > > > expressive > > > > > > > > > > > enough > > > > > > > > > > > > > to > > > > > > > > > > > > > > be considered of value when it comes to things > like > > > > > > copyright > > > > > > > > (I > > > > > > > > > > > believe > > > > > > > > > > > > > > this is one of the major reasons why there is no > > > > > Lightbend > > > > > > > > > > copyright > > > > > > > > > > > > > header > > > > > > > > > > > > > > for conf files). If the Lightbend header > happened to > > > > > > already > > > > > > > > exist > > > > > > > > > > > in the > > > > > > > > > > > > > > configuration files there would be sense in > biting > > > the > > > > > > bullet > > > > > > > > but > > > > > > > > > > > since > > > > > > > > > > > > > > this is not the case to me I see it as > preferable if > > > we > > > > > > just > > > > > > > > leave > > > > > > > > > > > the > > > > > > > > > > > > > conf > > > > > > > > > > > > > > files. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu > Valtonen > > > > > > > > > > > > > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > To unsubscribe, e-mail: > > > dev-unsubscr...@pekko.apache.org > > > > > > > > > > > > > For additional commands, e-mail: > > > dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: > dev-unsubscr...@pekko.apache.org > > > > > > > > > > > For additional commands, e-mail: > dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- 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
