Hi, On 2025/08/12 03:11:42 Sutou Kouhei wrote: > If we develop it as out of the Apache Software Foundation > (https://github.com/apache/), we need to donate it to the > Apache Software Foundation. See also > https://incubator.apache.org/ip-clearance/ and David's > reply. > > In the donation process, all copyright holders must > sign contributor license agreement. See also: > https://www.apache.org/licenses/contributor-agreements.html > > If we create a new repository such as > https://github.com/apache/arrow-erlang and develop in it > from scratch, we don't need the donation process.
If we create a new repository and "develop in it from scratch", I'll probably end up copying significant parts from the original project. I'm not very familiar with ip-clearance laws and procedures, but my understanding is that I (and other contributors) will have to sign the requisite paperwork even if code is just copied from the original repository and the repository is not donated itself. If it's necessary, getting signatures will not be too difficult since there are only 4 other contributors apart from myself. Secondly, this will be the first time I will be maintaining an Apache project, and I am not very familiar with the internal processes you use. I feel I might move faster with a repo under my own user because 1. I have full control to make any necessary changes and 2. I am not burdened with learning Apache's conventions. This is just an opinion, and I'm open to developing under an 'apache/arrow-erlang' repo. > If the Erlang Ecosystem Foundation is also a copyright > holder and we choose the donation process, the Erlang > Ecosystem Foundation also needs sign contributor license > agreement. The Erlang Ecosystem Foundations is not a copyright holder. > Could you upstream the FlatBuffers part to > https://github.com/google/flatbuffers instead of maintaining > it by us? See also the David's reply. There isn't a FlatBuffers implementation. The Rust code was bindings to the now defunct flatbuffers generate arrow-format crate that was used by arrow2: https://crates.io/crates/arrow-format > How about starting a new implementation as arrow-rs > bindings? nanoarrow provides only We weren't happy with Rust since it cannot be expected to be available in a system. Arrow is a dependency to OTel, which makes a dependency in a majority of Erlang projects. We need this to be as portable as possible, so I'm planning to go with regular C bindings. C++ bindings are also an option, but personally prefer C. > serialization/deserialization features but arrow-rs provides > more features such as computation features. This reminds me. What features will I have to support out of (de)serialization for an implementation to be considered complete? serde for Arrow Arrays is the only feature that mandatorily requires Erlang. I'm guessing if I can initialize an Arrow Array from C given a valid Array binary from Erlang, I can get Erlang to maintain a reference to the C Arrow Array and use that with the regular C API to implement everything else via bindings. > We need to add a tester to Archery. For example, > https://github.com/apache/arrow/blob/main/dev/archery/archery/integration/tester_go.py > is a tester for Go. > > FYI: There is a PR that adds a generic tester for > implementations not in apache/arrow: > https://github.com/apache/arrow/pull/46530 Cool. I'll patch Archery if we go ahead with this. If not, I'll use the generic test. Thank you for considering this! -- bp
