Up to and including version 2.12 of the binding crates and version 1.10 of the sys crates available in this repository, they have been licensed with LGPL v2.1+, with a possible alternative of dual MIT and Apache-2.0 licensing under certain circumstances (as previously discussed in the project readme).
As of v2.13 (bindings) and v1.11 (sys) respectively, I have changed the licensing, dropping LGPL and promoting dual MIT and Apache-2.0 to be the new licensing model.
Why?
LGPL is a variant of GPL intended for use with libraries; it relaxes the restriction that forces projects using GPL code to also be GPL licensed. The requirement of LGPL licensed code is that if it is compiled into a separate object, i.e. a dynamically-loaded library (like a system library - .dll/.so) then such a requirement does not apply. It thus only applies if compiled statically, i.e. combined directly into an application or library object, whereby that object must be GPL/LGPL licensed.
This meant that for complying with the license, to make use of these sys and binding crates, you would be forced to either license anything using them as GPL/LGPL, or to compile them into shared libraries that sit alongside your project, which is not really ideal for a thin binding layer.
The dual MIT and Apache-2.0 licensing imposes no such requirements.
Note that the default way Rust crates are consumed, through simply adding dependencies to a Cargo.toml file, is static compiling! All of your dependencies, unless you explicitly compile them as a shared library, are being compiled statically. There is thus risk that users may blindly depend on these crates and violate the licensing in doing so.
Furthermore, I, the project author, have absolutely no interest in imposing such a restriction on use of these crates.
Why was LGPL ever chosen?
PulseAudio itself is LGPL 2.1+ licensed, and I had to consider this when I created these crates. I was concerned about the possibility of these crates being considered derivative works of PulseAudio through for instance the fact that they largely copy the documentation from the PulseAudio C header files.
I thus simply went with licensing this project under the same LGPL 2.1+ licensing to avoid any potential for compliance issues.
What has changed?
Nothing has really changed, but I have re-evaluated the situation.
I have discussed the issue with the PulseAudio project (here). Their stance is that although the LGPL license makes certain common sense exceptions, there is no actual exception for copying documentation like I am doing. The only way to get their official approval would be to build a list of all individuals who have ever contributed to the PulseAudio documentation and get their explicit approval, which of course would be a pain.
My feeling is that perhaps the LGPL license authors had not considered a situation like this when they wrote it, and that what I am doing is not in the spirit of what their license was trying to
restrict. They have a contact address for asking such questions, and I emailed them requesting clarification on their position on this. I have not yet received a response.
Of interest of course is that documentation does not actually get compiled into any resulting library or application. It does however become part of documentation generated by cargo doc.
Another factor of interest is that there is a FAQ available for the GPL/LGPL licenses (here), and specifically there is an entry on "fair-use" (here) which explicitly makes clear that fair-use does apply...
Decisions
What I have decided is that the nature of my project and use of the PA documentation within it
should reasonably be considered fair-use, and that I should thus not feel bound to using LGPL for my crates.
My project is simply providing a free Rust interface to PA; I'm maintaining it myself independently
largely because they told me previously that it was too burdensome for them to merge into the
official project; and providing a copy of the documentation as I do is extremely valuable to users
of this Rust interface to PA. It would be very unreasonable for users to have to consult the C
header files. It is just a matter of making the documentation available in the location most useful
to Rust users, where they would expect to find it. That is the purpose in having copied it. Not
doing so would make use of PA for Rust programmers significantly unpleasant.
We also come back to that issue of combining LGPL code within compiled objects. This documentation, being documentation, is never compiled into libraries or applications (ignoring doc-tests, which is fair-use anyway as being examples), so there is actually the licensing restriction should not even apply to projects depending on these crates so long as they just depend upon them and not copy and paste stuff.
The only applicable "derivative-work" related use of the documentation where it gets combined into something, if this is even any concern of LGPL, is the HTML documentation generated by cargo doc. Here I feel that personal generation of this HTML documentation is also surely a clear fair-use
situation.
Furthermore I feel that the copy of the HTML documentation hosted on docs.rs is again a fair-use situation - it is just providing a helpful free resource for Rust users.
I have thus decided to move forward with changing the licensing of these crates.
How does this affect me (the reader)?
You can now freely depend upon the crates, allowing them to be compiled-in statically, as natural, without worry of being being in violation of the LGPL license. You should also of course be able to generate and make use of the HTML based documentation with cargo doc without concern.
That is, as long as you are simply making normal use of these crates. If you're considering
doing something unusual like copying the documentation into something else like your own code or into a book you wish to publish, then you should evaluate whether my fair-use of that documentation reasonably would carry over to your use of it, or whether you must comply with the original LGPL license.
Up to and including version 2.12 of the binding crates and version 1.10 of the sys crates available in this repository, they have been licensed with LGPL v2.1+, with a possible alternative of dual MIT and Apache-2.0 licensing under certain circumstances (as previously discussed in the project readme).
As of v2.13 (bindings) and v1.11 (sys) respectively, I have changed the licensing, dropping LGPL and promoting dual MIT and Apache-2.0 to be the new licensing model.
Why?
LGPL is a variant of GPL intended for use with libraries; it relaxes the restriction that forces projects using GPL code to also be GPL licensed. The requirement of LGPL licensed code is that if it is compiled into a separate object, i.e. a dynamically-loaded library (like a system library - .dll/.so) then such a requirement does not apply. It thus only applies if compiled statically, i.e. combined directly into an application or library object, whereby that object must be GPL/LGPL licensed.
This meant that for complying with the license, to make use of these sys and binding crates, you would be forced to either license anything using them as GPL/LGPL, or to compile them into shared libraries that sit alongside your project, which is not really ideal for a thin binding layer.
The dual MIT and Apache-2.0 licensing imposes no such requirements.
Note that the default way Rust crates are consumed, through simply adding dependencies to a Cargo.toml file, is static compiling! All of your dependencies, unless you explicitly compile them as a shared library, are being compiled statically. There is thus risk that users may blindly depend on these crates and violate the licensing in doing so.
Furthermore, I, the project author, have absolutely no interest in imposing such a restriction on use of these crates.
Why was LGPL ever chosen?
PulseAudio itself is LGPL 2.1+ licensed, and I had to consider this when I created these crates. I was concerned about the possibility of these crates being considered derivative works of PulseAudio through for instance the fact that they largely copy the documentation from the PulseAudio C header files.
I thus simply went with licensing this project under the same LGPL 2.1+ licensing to avoid any potential for compliance issues.
What has changed?
Nothing has really changed, but I have re-evaluated the situation.
I have discussed the issue with the PulseAudio project (here). Their stance is that although the LGPL license makes certain common sense exceptions, there is no actual exception for copying documentation like I am doing. The only way to get their official approval would be to build a list of all individuals who have ever contributed to the PulseAudio documentation and get their explicit approval, which of course would be a pain.
My feeling is that perhaps the LGPL license authors had not considered a situation like this when they wrote it, and that what I am doing is not in the spirit of what their license was trying to restrict. They have a contact address for asking such questions, and I emailed them requesting clarification on their position on this. I have not yet received a response.
Of interest of course is that documentation does not actually get compiled into any resulting library or application. It does however become part of documentation generated by
cargo doc.Another factor of interest is that there is a FAQ available for the GPL/LGPL licenses (here), and specifically there is an entry on "fair-use" (here) which explicitly makes clear that fair-use does apply...
Decisions
What I have decided is that the nature of my project and use of the PA documentation within it should reasonably be considered fair-use, and that I should thus not feel bound to using LGPL for my crates.
My project is simply providing a free Rust interface to PA; I'm maintaining it myself independently largely because they told me previously that it was too burdensome for them to merge into the official project; and providing a copy of the documentation as I do is extremely valuable to users of this Rust interface to PA. It would be very unreasonable for users to have to consult the C header files. It is just a matter of making the documentation available in the location most useful to Rust users, where they would expect to find it. That is the purpose in having copied it. Not doing so would make use of PA for Rust programmers significantly unpleasant.
We also come back to that issue of combining LGPL code within compiled objects. This documentation, being documentation, is never compiled into libraries or applications (ignoring doc-tests, which is fair-use anyway as being examples), so there is actually the licensing restriction should not even apply to projects depending on these crates so long as they just depend upon them and not copy and paste stuff.
The only applicable "derivative-work" related use of the documentation where it gets combined into something, if this is even any concern of LGPL, is the HTML documentation generated by
cargo doc. Here I feel that personal generation of this HTML documentation is also surely a clear fair-use situation.Furthermore I feel that the copy of the HTML documentation hosted on docs.rs is again a fair-use situation - it is just providing a helpful free resource for Rust users.
I have thus decided to move forward with changing the licensing of these crates.
How does this affect me (the reader)?
You can now freely depend upon the crates, allowing them to be compiled-in statically, as natural, without worry of being being in violation of the LGPL license. You should also of course be able to generate and make use of the HTML based documentation with
cargo docwithout concern.That is, as long as you are simply making normal use of these crates. If you're considering doing something unusual like copying the documentation into something else like your own code or into a book you wish to publish, then you should evaluate whether my fair-use of that documentation reasonably would carry over to your use of it, or whether you must comply with the original LGPL license.