I am planning to publish Rust bindings for igraph and want to ensure that I do it in accord with the wishes of the igraph developers. My main question here concerns the naming and licensing of the library, but please do tell me if something occurs to you that I should probably be aware of. Below I’ll give a small amount of background info and the intended scope, then I’ll pose my questions.
I’ve been looking for a Rust pet project for a while. Recently, I needed some tools for working with graphs and found those tools missing in the Rust ecosystem, so I figured that providing those tools would be a good project for me. Thus, I went looking for existing libraries that I could interface with from Rust. I found graph-tool, networkit and igraph—since igraph is written in C, interfacing with Rust is pretty straightforward. And here I am.
My intention is to provide two crates, following the structure described in https://kornel.ski/rust-sys-crate. The first crate will be a low level interface to the igraph C library, consisting basically of a build script which
Builds igraph from bundled source code using the cc crate
auto-generates unsafe bindings to igraph using the bindgen crate
The second crate will provide users with a Rust-idiomatic interface to igraph, built on top of the first crate.
Developing the second crate is expected to require by far the most amount of work. Initially I will focus on supporting the basic interface along with features related to determining structural properties of graphs. There’s a definite risk (in fact I would say it is expected) that I will never support all features. I will be doing this on my own time, at my own pace.
And so we come to my questions:
Concerning licensing, it is my understanding that I need to verbatim include https://github.com/igraph/igraph/blob/master/COPYING somewhere visible in the source code, which amounts to licensing the two crates according to GPLv2 (or, at the user’s option, any later version). Could someone verify that I understood this correctly?
Concerning the naming of the crates, I imagine rust-igraph-sys for the low level crate and rust-igraph for the high level crate would be good names. However, if the igraph developers ever intend to support their own Rust bindings for igraph, I image you might want to use that name yourselves—hence I’d like a pointer as to whether or not rust-igraph is an agreeable name for a crate like what I have in mind.
Did I miss something? Anything I should be aware of?
First of all, welcome to the igraph forum! I think it’s really great that you are doing this. Should you run into any issues with igraph, feel free to post here.
For now I will only attempt to answer point 1, with the obligatory note that I am neither a lawyer, nor particularly experienced with licensing questions.
My understanding is that it is not sufficient to include the GPLv2 license text because igraph contains several components whose licenses require retaining copyright notices. We have recently collected these notices in the ACKNOWLEDGEMENTS.md file. These notices should also be included in any distribution of software that makes use of igraph.
Furthermore, igraph can optionally use GLPK, which is GPLv3 licensed. This would mean that any distribution that includes the GLPK component should use GPLv3 or later (and not GPLv2).
Thank you for your response! I had completely missed that file.
I actually intend to include https://github.com/igraph/igraph as a git submodule, in which case I guess that also covers me regarding the ACKNOWLEDGEMENTS.md file.
Now that I had a look at the acknowledgements, I can’t help but wonder what the situation is with plfit (which appears to be GPLv2 only) and PRPACK (which appears to not be covered by an open source license). Were those components contributed to the igraph codebase under some special conditions ensuring that they are covered by GPLv2 or later for the purpose of distributing and/or deriving from igraph?
Feel free to use rust-igraph-sys and rust-igraph; I’m totally okay with that, and honestly, I think none of us has much experience with Rust so it’s unlikely that we’ll ever create a Rust interface for igraph on our own. I find it more likely that if your interface becomes mature enough and there’s long-term commitment to the maintenance of the project, then we’ll simply embrace it just like we did with IGraph/M (courtesy of @szhorvat).
Did I miss something? Anything I should be aware of?
Nope; and just shout if you find something that we could improve in the C core to make your life easier with the higher level interface.