Closed iBelieve closed 1 year ago
Thanks for the interest, licensing was definitely something I grappled with when first writing. Ultimately, it comes down to the original source implementation (GPL) which may or may not have been referenced while porting. IANAL so I simply chose to stay on the safe side, though I have thought about reaching out to Dr. Madgwick for any sort of blessing that may be offered. FWIW this is the only crate I maintain which isn't MIT/Apache-2.0, so I totally agree with your point of view.
Could you reach out to Dr. Madgwick? I think it would be really great if it were licensed like the rest of the Rust ecosystem
Not sure what that process looks like for for him to grant permission in a way that is perpetually legal and free of license woes. Probably best way is for him to publish whatever code you referenced as a MIT / Apache 2.0 licensed project on github, or at least email you a version of it with the MIT license and Apache 2.0 inside it, filled out with his name and copyright date
Dumb question... but the link you have in README, points to this GitHub repo which is MIT licensed:
https://github.com/xioTechnologies/Fusion
Is it possible that the code you were originally referencing is now MIT licensed?
I wonder if @xioTechnologies could jump in, and offer any insight?
Fusion is the algorithm repository. All other repositories and code distributions are snapshots of the algorithm at different points in time. For example, the original source code accompanying the 2011 paper, the C# and MATLAB ports, and the copies bundled with specific applications such as the oscillatory motion and gait tracking examples.
Having so many versions of the code existing simultaneously is not ideal, but it is something I am slowly trying to rectify with all new occurrences being tracible back to the version controlled Fusion repository.
My preference is for code ports to be avoided in favour of wrapping of the C code. This is already demonstrated with the Python package, imufusion. Wrapping reduces the risk of errors, allows the behaviour of the algorithm to be replicated identically on each platform, and significantly simplifies maintenance of implementations in other languages.
I will discuss the addition of a Rust crate to Fusion with my team. We already use Rust FFI in another project so it should hopefully be straightforward. In the meantime, I can confirm that I have no problem with you porting and distributing the old "Mahony and Madgwick" code.
Seb Madgwick
That's awesome to hear, sounds they could indeed switch their license.
Was the fusion
library always MIT? I only see MIT in the code history.
When exactly did the license stop being GPL?
I cannot easily answer those questions. I can tell you that I consider the Fusion repository to supersede all past distributions, and represent how I wish the algorithm and library to exist in the public domain.
That's great news! I'll go ahead and cut a new release under MIT to match fusion
, thanks everyone.
@jmagnuson - Let me know if there's anything I can do to help with releasing a new MIT version. Happy to do a pull request if it makes your life easier?
@latenitefilms sorry, I should have some time later today (US time) to do it + cut a release. But if you beat me to it that would be great too.
Thanks for your work porting the Mahony and Madgwick AHRS algorithms to Rust! I'd like to use this crate for a (likely open-source) project I'm working on, but would like to avoid the GPL license. Would you consider licensing this under the Apache-2.0 and/or MIT licenses, since those seem to be the most common for Rust crates?