Open-source library proxying to a closed-source library (ITP #679504)

July 07th, 2012 - 10:20 am ET by Christophe-Marie Duquesne | Report spam
Hi,

I am the author of an open-source library that proxy calls to a
closed-source library.

The library is meant to be used as a drop-in replacement, for
compiling, linking and runtime. The targeted closed-source library is
the one of a Linear Programming solver. The purpose is to provide
entry points for Osi [1], a library that lets you write solver
agnostic code. Osi links to my library, and at runtime, it takes care
of finding, dlopening and forwarding calls to the closed source
library. This way, you don't actually need the solver whenever you
compile Osi, and your build can use the targeted solver whenever it is
found on the system.

For now, what I do: I take the header of the closed-source library,
wipe out the comments and elaborated macros, and then implement all
the declared functions as proxy functions of the exposed API in a .c
file. As a consequence, there is very little actual difference between
my header and the one of the closed-source library.

I have asked about the potential copyright issues about this library
in various places (wine, fsf, debian-mentors). The average answers I
get are:
- "We are not lawyers, but it looks ok - see Oracle vs Google trials"
- "If you have the same header it's derived work, it's not ok".

I also had some clever suggestions, like rewriting the headers from
scratch, starting from the publicly available APIs. Even though I am
willing to do that if that solves copyright problems, I think there
still would be very little difference between my header and the one
from the closed-source library, so I want to be sure about this.

The question I have for you is very simple: What would it take for
debian to accept my package (if it can ever be distributed)?

PS: If you are interested, my project is hosted here [2].

Cheers,
Christophe-Marie

[1]: https://projects.coin-or.org/Osi
[2]: http://code.google.com/p/lazylpsolverlibs/


To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAHLp1YknmW...JR-0TyxkPA@mail.gmail.com
email Follow the discussionReplies 7 repliesReplies Make a reply

Similar topics

Replies

#1 Francesco Poli
July 07th, 2012 - 11:10 am ET | Report spam

On Sat, 7 Jul 2012 16:12:32 +0200 Christophe-Marie Duquesne wrote:

Hi,



Hello Christophe-Marie,


I am the author of an open-source library that proxy calls to a
closed-source library.



I am sorry to say this, but I think that the time of a competent
developer would be far better spent in writing Free Software, rather
than in building "proxies" having the sole purpose of making it easier
to use proprietary software... :-(

[...]
I have asked about the potential copyright issues about this library
in various places (wine, fsf, debian-mentors). The average answers I
get are:
- "We are not lawyers, but it looks ok - see Oracle vs Google trials"
- "If you have the same header it's derived work, it's not ok".



I am not sure which of the two is the correct answer, since, well, I am
not a lawyer!
I think you should really seek legal advice from a hired lawyer, in
order to obtain (hopefully) less vague answers...

[...]
The question I have for you is very simple: What would it take for
debian to accept my package (if it can ever be distributed)?



Accept your package where?

I don't think it could ever qualify for Debian main, since your proxy
library is useless in the absence of the proprietary library and the
Debian Policy mandates that packages in main cannot require or
recommend packages outside of main for compilation or execution [1].

[1] http://www.debian.org/doc/debian-po...tml#s-main

It could *maybe* qualify for the contrib archive [2], as long as it is
determined to be (legally redistributable and) compliant with the DFSG
(even though I see that it is licensed under the terms of the EPL, a
license that I personally dislike...).

[2] http://www.debian.org/doc/debian-po...#s-contrib



http://www.inventati.org/frx/frx-gp...n-2010.txt
New GnuPG key, see the transition document!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE





To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/
Replies Reply to this message
#2 Christophe-Marie Duquesne
July 07th, 2012 - 12:50 pm ET | Report spam
Hello Francesco,

On Sat, Jul 7, 2012 at 5:03 PM, Francesco Poli
wrote:
I am sorry to say this, but I think that the time of a competent
developer would be far better spent in writing Free Software, rather
than in building "proxies" having the sole purpose of making it easier
to use proprietary software... :-(



I understand your point. Let me elaborate about this:

In my field, people don't use much free solvers, because they don't
perform as good as the proprietary ones. They will usually point you
at the following resource [1] to explain to you that their code
performs performs 4x to 20x better with a proprietary solver. Because
of this, people rarely bother to even try free alternatives.

IMHO, the lack of users is one of the reasons why free alternatives
cannot compete with proprietary solutions. But who would blame the
users? They are just being pragmatic and use the best solution
available. They are also trying to avoid making a professional
mistake, targetting a solver that is notoriously slower than another
one that their compagny could buy. Everyone, including academics, use
these proprietary solvers, so why wouldn't they?

Osi is an interface that lets you abstract your code from the solver.
You can write your code once, and make it target different solvers,
including a lot of free software libraries. Osi can target 11
different libraries, 7 of them being open-source. This approach makes
it easier to try different solutions and find the solver that fits
your problem best. Whenever people use it, we can hope that they are
going to try the opensource alternatives. We can hope that we are
bringing users to the free software.

Osi is very neat, but debian delivers a version that does not let
users target their proprietary solvers. As a consequence, when they
discover they can't use their proprietary solver with the package
provided by debian, users go away. This proxy library is my attempt to
fix that. I am not only trying to make easier for a developer to
target proprietary solver: I am trying to bring more users to Osi, a
free framework that will let them experiment with various solvers.

It could *maybe* qualify for the contrib archive [2], as long as it is
determined to be (legally redistributable and)



Who would determine whether it is legally redistributable?

(even though I see that it is licensed under the terms of the EPL, a
license that I personally dislike...).



The EPL is the license recommended by coin-or [2] where I intend to
submit my project. I would be happy to relicense my work differently
as long as the new license is approved by the open source initiative
(coin-or requirement) and as it makes it possible to link Osi with it.

[1]: http://scip.zib.de/
[2]: http://www.coin-or.org/contributions.html


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/CAHLp1Yk6V1...kP+gsRA18=
Replies Reply to this message
#3 Francesco Poli
July 07th, 2012 - 01:20 pm ET | Report spam

On Sat, 7 Jul 2012 18:48:47 +0200 Christophe-Marie Duquesne wrote:

[...]
On Sat, Jul 7, 2012 at 5:03 PM, Francesco Poli
wrote:
> I am sorry to say this, but I think that the time of a competent
> developer would be far better spent in writing Free Software, rather
> than in building "proxies" having the sole purpose of making it easier
> to use proprietary software... :-(

I understand your point. Let me elaborate about this:


[...]

Point taken, thanks for the explanation, I now understand your goal
better (even though I must admit that I am not 100 % sure that it's the
best possible strategy...).


> It could *maybe* qualify for the contrib archive [2], as long as it is
> determined to be (legally redistributable and)

Who would determine whether it is legally redistributable?



The ultimate decision on what will or will not be distributed by Debian
is up to the FTP Masters (possibly after consultation with other
bodies, including the Debian-legal mailing list).


> (even though I see that it is licensed under the terms of the EPL, a
> license that I personally dislike...).

The EPL is the license recommended by coin-or [2] where I intend to
submit my project. I would be happy to relicense my work differently
as long as the new license is approved by the open source initiative
(coin-or requirement) and as it makes it possible to link Osi with it.

[1]: http://scip.zib.de/
[2]: http://www.coin-or.org/contributions.html



I would personally recommend a simpler license, such as the Expat license:
http://www.jclark.com/xml/copying.txt
also known as the MIT license:
http://www.opensource.org/licenses/MIT



http://www.inventati.org/frx/frx-gp...n-2010.txt
New GnuPG key, see the transition document!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE





To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/
Replies Reply to this message
#4 Jonathan Nieder
July 08th, 2012 - 01:30 am ET | Report spam
Hi,

Christophe-Marie Duquesne wrote:

The purpose is to provide
entry points for Osi [1], a library that lets you write solver
agnostic code. Osi links to my library, and at runtime, it takes care
of finding, dlopening and forwarding calls to the closed source
library. This way, you don't actually need the solver whenever you
compile Osi, and your build can use the targeted solver whenever it is
found on the system.



Thanks for asking.

Others' answers about how to get a free header seemed sensible to me.
Best to use as little creative content from the proprietary header as
possible remove parameter names, alphabetize by function name,
etc. Make sure you document how the header is produced so it can be
easily updated and so others can easily verify it has no nonfunctional
content. Best of all if you can write the header from scratch based
on a specification someone else has written.

But that is beside the point when answering the main question:

[...]
The question I have for you is very simple: What would it take for
debian to accept my package (if it can ever be distributed)?



This package would not be eligible for inclusion in Debian until there
is a free implementation of the solver interface you are linking to.

If you find a way to make a free version of the header, it would
presumably be a candidate for contrib.

Hope that helps,
Jonathan


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/
Replies Reply to this message
#5 Christophe-Marie Duquesne
July 08th, 2012 - 03:10 am ET | Report spam
On Sun, Jul 8, 2012 at 7:26 AM, Jonathan Nieder wrote:
Others' answers about how to get a free header seemed sensible to me.
Best to use as little creative content from the proprietary header as
possible remove parameter names, alphabetize by function name,
etc. Make sure you document how the header is produced so it can be
easily updated and so others can easily verify it has no nonfunctional
content. Best of all if you can write the header from scratch based
on a specification someone else has written.



Ok, I'll try to craft something from scratch. New versions should be
updated at small cost.

This package would not be eligible for inclusion in Debian until there
is a free implementation of the solver interface you are linking to.

If you find a way to make a free version of the header, it would
presumably be a candidate for contrib.



Thank you for the clear answer.


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search