Re: Rust binding licensing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2019-08-19 at 22:15 +0100, jnqnfe@xxxxxxxxx wrote:
> Hi,
> 
> I don't know if you remember me, but I'm the author of the Rust binding
> (https://github.com/jnqnfe/pulse-binding-rust) for PA.
> 
> I am a little uncertain about licensing with regards to my binding,
> specifically whether it in any way actually does fall under the concept
> of "derived work" and thus is subject to LGPL, or whether it is simply
> a copyright matter.
> 
> The things it all hinges upon I suppose is the fact that I've copied
> much of the documentation, and since licensing is primarily concerned
> with actual code and use of code in compiled form within
> binaries/shared-libs/firmwares, I'm just not certain where I stand with
> just the documentation aspect and got nowhere googling the topic.
> 
> I have outlined much of what needs to be said regarding licensing wrt.
> my Rust binding in the project's main readme (
> https://github.com/jnqnfe/pulse-binding-rust/blob/master/README.md).
> 
> The big issue I have with LGPL is that in the Rust world the default
> way "crates" (libraries) are consumed is static compiling (you just
> specify the name of a crate as a dependency in your project and it is
> just automatically downloaded and compiled in). Many Rust crates are
> MIT+Apache licensed, meaning little or no impact regarding the
> licensing of the end product they are built into. When it comes to LGPL
> crates however, for compliance you must either make the product
> GPL/LGPL or else compile the dependent crate (i.e. my binding here) as
> a dynamic shared lib.
> 
> Since the default with Rust crates is static compiling, there's great
> danger in people just plowing on ahead with using it in non-GPL/LGPL
> work, not even realising they're breaking LGPL licensing requirements
> (either directly, or indirectly as an inherited dependency from
> something else). If they do follow the requirements, building as a
> shared lib, then that becomes rather a pain to deal with and an
> inefficiency issue, just for a thin binding layer in this case.
> 
> As discussed in the project readme, I leave open the possibility of
> using my work under MIT+Apache under strict conditions, while
> officially marking it in the crates as LGPL. It would be great though
> to resolve the unanswered question.
> 
> If what I have done with copying the documentation *is* covered by the
> LGPL such that it *is* a derived work and thus I am forced by default
> to also use LGPL, then would you considered granting my project an
> exception, specifically just for the aspects that apply, i.e. copying
> the documentation? Such that my binding can freely be MIT+Apache
> licensed and statically compiled, while not affecting the use of PA
> libs themselves of course.

The documentation is copyrighted, and since there are no special
exceptions mentioned anywhere, it's covered by LGPL like everything
else. I now read what the license says, and I got the impression that
if you copy the documentation, you have created a derivative work, and
the whole work must be licensed under LGPL, and you can't change the
licensing terms by adding alternative licenses.

Granting an exception for your project probably isn't feasible. The
copyrights to PulseAudio code isn't held by any centralized entity.
Someone would have to inspect the history of everything you've copied
to find out who are the people who hold copyrights to the
documentation. Only those who hold the copyrights can grant exceptions.

One possibility might be that you split off the documentation to a
separate work (probably best to create a separate git repository) so
that only the documentation needs to be under LGPL and the bindings
themselves you can license however you wish.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux