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 <matthew.dedetr...@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.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 >
