Re: question about proprietary libraries
On Thu, Sep 2, 2010 at 5:48 AM, Peter Pentchev <roam@ringlet.net> wrote:
> On Thu, Sep 02, 2010 at 11:28:54AM +0200, Julien Viard de Galbert wrote:
>> On Thu, Sep 02, 2010 at 05:03:40AM -0300, Rogério Brito wrote:
>> > Hi there.
>> >
>> > On Sep 01 2010, Stephen Sinclair wrote:
>> > > I don't have the ability to reverse engineer it and write my own
>> > > drivers, but I'd still like users of this device to be able to make
>> > > use of my software.
>> >
>> > Right. You can dlopen the library, depending on the case. Your program
>> > will still be Free, in the same sense that the Linux Kernel is Free.
>> > You may want to check the license that you will eventually use: I think
>> > that the GPL wouldn't cut it, but the LGPL might.
>> >
>> > > Would such a library have difficulty getting accepted by Debian?
>> >
>> > The library, yes. Your program? No, depending on how "dependent" the
>> > program would be on that library. If the use of said devices is just a
>> > minor part of the program's role, then it may be accepted into main,
>> > without any problems.
>> >
>> I find it a little confusing, he was first saying he wants to write a
>> _library_, than can uses a proprietary library.
>>
>> What I understand is that his library (the one he want to write) could
>> be accepted to main if it is useful without the proprietary library
>> (that can be considered as a hardware driver). Then any program using it
>> could also go to main (provided that no other dependency would require
>> it to be contrib or non-free).
>
> That's how I understand the situation, FWIW.
>
> The whole thing might become a bit clearer with a real example of
> a library that is already in Debian main, and that may optionally use
> another library that is not in Debian. Take a look at the libdvdread4
> package, and specifically at how /usr/share/doc/libdvdread4/README.Debian
> documents its relationship with the libdvdcss library which is not
> in Debian. The libdvdread4 library is useful even without libdvdcss,
> but its operation is enhanced by libdvdcss's presence on the system.
>
> So, basically, yes, this is acceptable, and that's exactly how it is done.
Okay thank you, this basically answers my question. By the way to
clarify, yes it is the development of a library which may optionally
use a vendor-provided library for accessing a particular device. I
would like to make it easier for open source developers to develop
software for this class of devices, some which have open source
drivers and some which don't. That is, it will eventually lead to
applications, but first is to develop a simple library.
Now that I know it's not entirely hopeless, I will work on this
project and then if specific issues arise at least I know there is
some precedence to refer to in this situation.
Final question on this topic: What about the fact that to use some
vendor library functions, (even if it is dlopen'ed), it is necessary
to include headers from the vendor library? (Or at least to port the
function prototypes, although likely some structs and enums are also
necessary.) Would this in any way affect future packaging issues? I
will assume for now that the vendor's policy is to allow people to
distribute their header files, since otherwise I can't think of any
legal way to write open source software that would use their device.
thanks,
Steve
Reply to: