Sys crates, licenseing, bindgen

#1

I'm building a sys crate for building pure data plugins (aka externals) and I have a few questions:

  1. How do people license sys crates? I generate with bindgen and my github repository includes the original source for the interface I'll link against (I'm actually implementing plugins so I'm not linking in the sys library itself). Should I copy the license for the project I'm binding to, attributing the bindings to the original author? Or?

  2. This project I'm building plugins for has a stable ABI. There shouldn't be any reason for others to use bindgen once I publish the crate. I haven't published any crates to crates.io yet so I'm not 100% how they work.. should I just add the bindgen generated output to my src/ and remove the build script in order to distribute this? What is the usual approach? It would be nice to make it easy to re-generate the bindings if there are updates or I find things that I forgot to include.

Thanks!

1 Like
#2

I wrote a guide for sys crates.

  1. I recommend using the same license as the original source you're wrapping. This way Rust tools for managing licenses will recognize it.

  2. For stable ABIs it's fine to generate bindings once "offline" and not use bindgen at build time.

2 Likes
#3

@kornel

Great, thanks a ton. I actually looked at your guide before posting this but wasn't 100% clear on all of this.

So, on point 1., do you mean, simply copying the license as is from the source? Like original src (c) Jane Doe BSD 3 clause.. then I make this sys crate (c) Jane Doe BSD 3 clause ?

On point 2., if I'm using bindgen, should simply target the src/ library for generated file(s) and then disable the build script?

As far as linking goes.. Is there a way to indicate, in the sys crate that, by default, the linker should allow undefined symbols and do dynamic lookup? I'm pretty sure this crate will always be used in the context of a plugin being loaded into a program that defines these symbols.

I have another question about feature gates for bindgen but I think that deserves its own topic.

#4

I don't mean copying license file literally, but using the same sort of license. If the original is BSD, make the sys crate BSD-licensed. If the original is GPL, make the sys crate GPL-licensed. This reduces risk of someone pulling an incompatible license, or accidentally violating a license because they've looked only at the sys crate's license.

For bindgen I commit something like generate.sh in the repo and make it produce src/ffi.rs. This way I can pub use ffi::* in lib.rs and add extra stuff if I want to (e.g. functions that replace function-like macros that bindgen can't translate).

1 Like
#5

One notable exception (IMO) to using the same license as the C library is if it's LGPL. You want to be able to dynamically link to the LGPL library to easily adhere to its requirements, but since you'll probably be statically linking to the -sys crate it's best if it has a more permissive license.

2 Likes