question about proprietary libraries
Hello, This is a general question about linking to proprietary libraries. Specifically I am thinking about developing a library which will work normally in the general case, but in some cases the user might have a proprietary library installed on their system, in which case I'd like to dynamically load that library and call out to its functions. The proprietary library in this case would be for doing I/O with a particular hardware device, for which there is currently no open source alternative. Therefore the user owning such a device would have installed the software and expect my library to work with it. Conversely, he would not have the proprietary library unless he has the device in question.. so I sort of think of this library as being "part of" the device. 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. Would such a library have difficulty getting accepted by Debian? Are there other examples of libraries in Debian which optionally leverage proprietary code if it is available? thanks, Steve -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=k5pyo6j4843t_-giynsrboresbn4=xtqqj...@mail.gmail.com
Re: question about proprietary libraries
On 01/09/10 20:40, Stephen Sinclair wrote: > Hello, > > This is a general question about linking to proprietary libraries. > Specifically I am thinking about developing a library which will work > normally in the general case, but in some cases the user might have a > proprietary library installed on their system, in which case I'd like > to dynamically load that library and call out to its functions. > > The proprietary library in this case would be for doing I/O with a > particular hardware device, for which there is currently no open > source alternative. Therefore the user owning such a device would > have installed the software and expect my library to work with it. > Conversely, he would not have the proprietary library unless he has > the device in question.. so I sort of think of this library as being > "part of" the device. 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. > > Would such a library have difficulty getting accepted by Debian? > > Are there other examples of libraries in Debian which optionally > leverage proprietary code if it is available? > Not exactly a library, but the kernel will load proprietary firmware if it finds it available and the device in question exists. As long as your software is useful without said proprietary library, it can go in main. If not, it should go in contrib. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: question about proprietary libraries
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.
OTOH, if it needs the library, then the most that you would be able to
do with your program would be to go into contrib.
Does this answer your question?
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100902080340.ga7...@ime.usp.br
Re: question about proprietary libraries
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). > > OTOH, if it needs the library, then the most that you would be able to > do with your program would be to go into contrib. Of course if the proprietary library is necessary then his library goes to contrib as well as any program depending on it. Also I think I've read somewhere that no library really enter debian unless a program requires it. (which kind of makes sense). Tell me if I'm wrong, I'm currently learning debian practices. -- Julien Viard de Galbert http://silicone.homelinux.org/ GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: question about proprietary libraries
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. > > OTOH, if it needs the library, then the most that you would be able to > > do with your program would be to go into contrib. > > Of course if the proprietary library is necessary then his library goes > to contrib as well as any program depending on it. > > Also I think I've read somewhere that no library really enter debian > unless a program requires it. (which kind of makes sense). > > Tell me if I'm wrong, I'm currently learning debian practices. IMHO you're right :) G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? signature.asc Description: Digital signature
Re: question about proprietary libraries
In <20100902092854.gr4...@vdg.blogsite.org>, Julien Viard de Galbert wrote: >Also I think I've read somewhere that no library really enter debian >unless a program requires it. (which kind of makes sense). I mentioned this in another thread. I'm not sure if it is policy. I was imagining a C library, which has little end-user demand if there's no application that needs it. I can imagine a PHP library (e.g.) might be shipped because it is useful for users developing websites (e.g.). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: question about proprietary libraries
On Thu, Sep 2, 2010 at 5:48 AM, Peter Pentchev 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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikjdxjw5zvcwcdkpj9gd=rwnpeg2k-h24169...@mail.gmail.com
Re: question about proprietary libraries
On Thu, Sep 02, 2010 at 12:46:09PM -0400, Stephen Sinclair wrote:
[...]
> 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.
Do you have a (legally sound) reason to believe that the vendor even
cares whether people write open source software for this device? For
that matter, do you know that their header files aren't licensed to
them by some non-transferrable agreement which allows the vendor to
provide a copy to you but doesn't entitle you to pass them along to
anyone else?
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100902171057.gn2...@yuggoth.org
Re: question about proprietary libraries
On Thu, Sep 2, 2010 at 1:10 PM, The Fungi wrote: > On Thu, Sep 02, 2010 at 12:46:09PM -0400, Stephen Sinclair wrote: > [...] >> 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. > > Do you have a (legally sound) reason to believe that the vendor even > cares whether people write open source software for this device? For > that matter, do you know that their header files aren't licensed to > them by some non-transferrable agreement which allows the vendor to > provide a copy to you but doesn't entitle you to pass them along to > anyone else? Not as far as I know, but I'll have to read the license in more detail. I'm assuming for now that the headers are allowed to be distributed. (For example, they can be found in their freely available documentation.) There are currently some other open source projects (not in Debian) which are already dlopen'ing the library in question, so I think they are okay with it. Steve -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikgshooyb-rxmatcaeuv5hirdtzgwamqfmnc...@mail.gmail.com
Re: question about proprietary libraries
Boyd Stephen Smith Jr. wrote: > In <20100902092854.gr4...@vdg.blogsite.org>, Julien Viard de Galbert wrote: > >Also I think I've read somewhere that no library really enter debian > >unless a program requires it. (which kind of makes sense). > > I mentioned this in another thread. I'm not sure if it is policy. Definitely not a policy. Take a look at libgnupdf; this completely useless *snapshot* make it even in Lenny. And another useless snapshot is going to be in Squeeze, too, unless someone does something about it (like filing a RM bug). There are lots of other examples, I believe. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v9bhoos.gnus_not_unix!%ya...@gnu.org
