Seeking advice on a licensing gray area: "Derivative work" or not?
2 comments
> For those who've built FFI wrappers in similar situations, how did you navigate this?
You talk to a lawyer who specializes in this topic. Anyone who is not a lawyer telling you anything is not to be trusted and can land you in legal trouble with no recourse.
There is literally no other discussion to be had you can trust.
I am not a lawyer and this is not legal advice.
You talk to a lawyer who specializes in this topic. Anyone who is not a lawyer telling you anything is not to be trusted and can land you in legal trouble with no recourse.
There is literally no other discussion to be had you can trust.
I am not a lawyer and this is not legal advice.
If you got a similar structure because you learnt, then I would not say it is a derivative work. But somebody else may say this is plagiarism.
I've hit a tricky licensing situation while developing a new open-source tool and would appreciate your guidance.
My project is a plugin for an ecosystem that typically uses static linking. It needs to communicate with a popular C library. Initially, I tried using an existing, well-regarded Rust wrapper for this C library, but it's licensed under LGPL. This would force the LGPL terms onto any app that uses my plugin, which is a major issue in our ecosystem.
To solve this, I decided to write my own FFI wrapper from the ground up, aiming for a more permissive license like MIT. It's important to note that when I was first trying to use the existing LGPL library, I had of course looked at parts of its code to understand how to integrate and use it properly.
As I built my own independent implementation, I found that the structure of my code (how I handled events, properties, contexts, etc.) became very similar to the LGPL library. This happened organically, not by copying, but because the underlying C library's API heavily constrains how any safe, ergonomic wrapper can be designed. The "best practices" for wrapping this specific C API seem to lead down a single path.
This similarity made me uncomfortable. Even though it's an independent implementation, it feels heavily inspired by the original work. Out of respect for the original author, we decided the most ethical path was to also license our plugin as LGPL.
But this brings me back to square one with the licensing problem for my users.
In a situation where the C API itself dictates the wrapper's structure, where do you draw the line between an independent work and a derivative one?
Was choosing LGPL the correct and only ethical option? Or could we have used MIT/Apache while giving prominent credit to the original project for its foundational design?
For those who've built FFI wrappers in similar situations, how did you navigate this?
Thanks for any insights you can share. This is a real gray area, and I'd love to learn from the community's experience.