short licensing question

newer
Windows Automation - COM package -...

Sebastian Fischer

11 Jan 2010 11 Jan '10

7:58 a.m.

Hello Café, when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

Show replies by date

Don Stewart

11 Jan 11 Jan

8:08 a.m.

sebf:

...

Hello Café,

when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL?

Libraries don't link in other things as such -- the .cabal file is the only thing that ties them together -- so you can use whatever license you like. Any resulting binaries might contain a mixture of such libraries, and the most restrictive license will usually be the license of the result. -- Don

Svein Ove Aas

8:15 a.m.

On Mon, Jan 11, 2010 at 2:08 PM, Don Stewart wrote:

...

sebf:

...
Hello Café,

when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL?

Libraries don't link in other things as such -- the .cabal file is the only thing that ties them together -- so you can use whatever license you like.

Any resulting binaries might contain a mixture of such libraries, and the most restrictive license will usually be the license of the result.

So, let's look at binaries then. In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked. Dynamic linking doesn't exist in GHC 6.10 and below. LGPL is thus restricted to open-source applications there. In 6.12.. well, dynamic linking exists, but in practice trying to replace a library implementation won't work. In fact, there's code in specifically to prevent it from working (well, crashing, really). So LGPL isn't very useful on that either. In practice, then, LGPL'd haskell libraries are probably useless for the stated purpose of supporting closed-source applications. You'd have to modify the license, or rather find something that fits better. I'm sure that exists, and chances are the author will be understanding if you ask. -- Svein Ove Aas

Ketil Malde

9:13 a.m.

Svein Ove Aas writes:

...

...
...
when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package?

...

...
Any resulting binaries might contain a mixture of such libraries, and the most restrictive license will usually be the license of the result.

...

In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked.

Isn't it possible to provide the proprietary bits as compiled object files (.o or .a) to be linked by the recipient? -k -- If I haven't seen further, it is by standing in the footprints of giants

Andrey Sisoyev

12:30 p.m.

Svein Ove Aas wrote:

...

In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked.

Don't understand that. Can't we just put a constraint: "our binary works only with versions x.x.x-y.y.y of this LGPL licensed library"? The Cabal provides a way to put such constraint in build-depends... Andrey -- View this message in context: http://old.nabble.com/short-licensing-question-tp27110059p27114282.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Duncan Coutts

12 Jan 12 Jan

4:03 a.m.

On Mon, 2010-01-11 at 09:30 -0800, Andrey Sisoyev wrote:

...

Svein Ove Aas wrote:

...
In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked.

Don't understand that. Can't we just put a constraint: "our binary works only with versions x.x.x-y.y.y of this LGPL licensed library"? The Cabal provides a way to put such constraint in build-depends...

It's not referring to totally new versions of a library with a different API/ABI. The LGPL requires that the user of the program is not prevented from making some small tweak to the LGPL library and relinking it against your program. Of course if the user makes it ABI incompatible then that's their fault. So the LGPL requires it be relinkable, which you can do by providing a copy of your application as a .o file which can then be linked against the LGPL lib to make a final program. Or if you're using shared/dynamic libs then its easier. If you want to do this in practise with Haskell, GHC and an LGPL Haskell package then here's what I recommend: ld -r -x -o main.o ${objects} Then make your actual executable as: ghc main.o -o main -package ${pkg1} -package ${pkg2} ... etc Then you distribute the executable "main" and also the relinkable form "main.o" to your users, along with a copy of the LGPL license. Any user can then perform the last step themselves and if they're really lucky they might get that to work with a slightly modified version of the LGPL'ed package. In practise of course this isn't that easy for the user because GHC does not make it easy to make ABI compatible packages. However it is my understanding that this procedure will comply with the LGPL. Duncan

minh thu

4:24 a.m.

2010/1/12 Duncan Coutts :

...

On Mon, 2010-01-11 at 09:30 -0800, Andrey Sisoyev wrote:

...
Svein Ove Aas wrote:

...
In this case, LGPL is a problem. It requires you to offer a way to re-link such binaries against new versions/implementations of the library, which in practice requires it to be either open source or dynamically linked.

Don't understand that. Can't we just put a constraint: "our binary works only with versions x.x.x-y.y.y of this LGPL licensed library"? The Cabal provides a way to put such constraint in build-depends...

It's not referring to totally new versions of a library with a different API/ABI. The LGPL requires that the user of the program is not prevented from making some small tweak to the LGPL library and relinking it against your program. Of course if the user makes it ABI incompatible then that's their fault.

So the LGPL requires it be relinkable, which you can do by providing a copy of your application as a .o file which can then be linked against the LGPL lib to make a final program. Or if you're using shared/dynamic libs then its easier.

If you want to do this in practise with Haskell, GHC and an LGPL Haskell package then here's what I recommend:

ld -r -x -o main.o ${objects}

Then make your actual executable as:

ghc main.o -o main -package ${pkg1} -package ${pkg2} ... etc

Then you distribute the executable "main" and also the relinkable form "main.o" to your users, along with a copy of the LGPL license.

Any user can then perform the last step themselves and if they're really lucky they might get that to work with a slightly modified version of the LGPL'ed package. In practise of course this isn't that easy for the user because GHC does not make it easy to make ABI compatible packages. However it is my understanding that this procedure will comply with the LGPL.

In short, if I understand you correctly, you would just have to provide your code in unlinked form regardless of the existence of some tool to create another ABI-compatible version of the LGPL library. This alongside of the last discussion (which also roughly said you can license the code as you want when it is the client responsability to link the final binary) makes the (L)GPL quite useless (as a "freedom" keeper) whenever the code is made for specific clients... Thu

Felipe Lessa

6:25 a.m.

On Tue, Jan 12, 2010 at 10:24:22AM +0100, minh thu wrote:

...

2010/1/12 Duncan Coutts :

...
Any user can then perform the last step themselves and if they're really lucky they might get that to work with a slightly modified version of the LGPL'ed package. In practise of course this isn't that easy for the user because GHC does not make it easy to make ABI compatible packages. However it is my understanding that this procedure will comply with the LGPL.

In short, if I understand you correctly, you would just have to provide your code in unlinked form regardless of the existence of some tool to create another ABI-compatible version of the LGPL library.

This alongside of the last discussion (which also roughly said you can license the code as you want when it is the client responsability to link the final binary) makes the (L)GPL quite useless (as a "freedom" keeper) whenever the code is made for specific clients...

I don't really follow. GHC inlines aggressively between modules. IMHO you would need to disable cross-module inlining. This means GHC would miss a lot of optimization oportunities. Oh, well. For example, if you use an LGPL concrete monad package and I want to CPS transform it, then all primitive operations would have to be changed. That means *any* inlined code from this module would change. Are you saying that this kind of change would count as "ABI incompatible change"? And so LGPL would say nothing about it? Am I missing something? :o) Cheers, -- Felipe.

Duncan Coutts

7:38 a.m.

On Tue, 2010-01-12 at 10:24 +0100, minh thu wrote:

...

In short, if I understand you correctly, you would just have to provide your code in unlinked form regardless of the existence of some tool to create another ABI-compatible version of the LGPL library.

Right. The procedure I mentioned is just to ensure that it is at least possible, so that you don't accidentally provide your code in unlinked form that's totally borked! :-) By making the single large .o form and then using that to make your final exe, then you guarantee that there were no missing symbols or whatever in the .o form that you will provide.

...

This alongside of the last discussion (which also roughly said you can license the code as you want when it is the client responsability to link the final binary) makes the (L)GPL quite useless (as a "freedom" keeper) whenever the code is made for specific clients...

It guarantees your client has the freedoms under the LGPL. If they choose never to redistribute then of course that's up to them and so any improvements you or they have made will not be available for upstream. But that is the intent of the LGPL, to protect the rights of the users *receiving* the code, not to guarantee that modifications are available to the entire world. Duncan

Sebastian Fischer

2:46 p.m.

On Jan 12, 2010, at 1:38 PM, Duncan Coutts wrote:

...

But that is the intent of the LGPL, to protect the rights of the users *receiving* the code, not to guarantee that modifications are available to the entire world.

I wonder whether the following statements are valid: When I write a program that uses an LGPL library, I am allowed to distribute the *sources* of my program under a permissive (non- copyleft) license like BSD3. I am not allowed to distribute my program in *binary* form under a permissive license (even if I release the sources too). Am I allowed to distribute the sources under BSD3 and the binary under LGPL? Would that make sense? Maybe not, because anyone who distributes a binary of my program or derivative work must license it under LGPL anyway. Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

Sebastian Fischer

3:21 p.m.

On Jan 12, 2010, at 8:46 PM, Sebastian Fischer wrote:

...

Am I allowed to distribute the sources under BSD3 and the binary under LGPL?

Would that make sense? Maybe not, because anyone who distributes a binary of my program or derivative work must license it under LGPL anyway.

Well it may make sense. People can write a replacement for the LGPL code, modify my code to use it, and distribute a binary without distributing the sources. They could not do this, if my sources were LGPL licensed. Sounds valid? -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

Ketil Malde

3:21 p.m.

Sebastian Fischer writes:

...

I wonder whether the following statements are valid:

You want my layman's opinion?

...

When I write a program that uses an LGPL library, I am allowed to distribute the *sources* of my program under a permissive (non- copyleft) license like BSD3.

Yes. I don't think using an API counts as deriving a work - the alternative would be to difficult and have too many dire consequences that would go against current practice (any program on, say, Linux, would be a derived work of the kernel - and probably vice versa).

...

I am not allowed to distribute my program in *binary* form under a permissive license (even if I release the sources too).

This would be a shame, since this is the whole raison d'être for LGPL. The point of LGPL is to ensure that any recipients of your program is able, should they so desire, to replace the LGPL library with a modified version.

...

Am I allowed to distribute the sources under BSD3 and the binary under LGPL?

I'm not sure this makes a lot of sense. But clearly, you can't redistribute somebodys LGPL library as BSD3, wether in binary or source form. You may of course distribute your bits as BSD3, which anybody could redistribute as LGPL or GPL. The point of LGPL is to be somewhat less "viral" than the GPL in that you may link LGPL code with otherwise licensed code and even proprietary, binary only code.¹ E.g. readline, which was explicitly GPL to "force" more software to adopt that license, while LGPL would "encourage" keeping different license. ¹ Whether the current license achieves this is a different matter, and LGPL is clearly either too strict or too lenient for most people. I like it, though. -k -- If I haven't seen further, it is by standing in the footprints of giants

Sebastian Fischer

11 Jan 11 Jan

2:43 p.m.

On Jan 11, 2010, at 2:08 PM, Don Stewart wrote:

...

Libraries don't link in other things as such -- the .cabal file is the only thing that ties them together -- so you can use whatever license you like.

On Jan 11, 2010, at 7:02 PM, Tom Tobin wrote:

...

I think in your case you can license the library you're writing any way you'd like, but distributing a statically linked binary might leave you with additional obligations under the LGPL.

Thank you all for your comments. It seems consensus that it is no problem to depend on LGPL libraries if no binary that links to LGPL'ed code is distributed. I understand that this consensus is no definite legal advice, though. What reasons do people have to use a BSD license over a Public Domain license, for example with the license text from: <http://www.lemur.com/pd-disclaimers.html

...

? Is the only difference that, with a BSD license, the copyright notice must be maintained?

Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

Jeremy Shaw

3:01 p.m.

...

What reasons do people have to use a BSD license over a Public Domain license, for example with the license text from: <http://www.lemur.com/pd-disclaimers.html

...
? Is the only difference that, with a BSD license, the copyright notice must be maintained?

I've heard rumors that you can't license your code as public domain in some countries. Not sure if the BSD3 helps with that though. But, one reason I license my Haskell code as BSD3 is that GHC and most(?) of the libraries on hackage are BSD3. And the BSD3 license is very widely known. As a result, I don't expect to have to deal with licensing issues. If I used a different license, then people would have to wonder... even if the license was more liberal. I figure people want to code, not think about licenses :p Also, I think it is kind of rude/conceited to license my code as GPL when it builds on so much BSD3 code. As if my code is some how so much better that the BSD3 isn't good enough for it :p - jeremy

wren ng thornton

3:08 p.m.

Sebastian Fischer wrote:

...

What reasons do people have to use a BSD license over a Public Domain license, for example with the license text from: http://www.lemur.com/pd-disclaimers.html ? Is the only difference that, with a BSD license, the copyright notice must be maintained?

One important reason is that "public domain" does not exist (or is not the same) in all countries, which can make international sharing a hassle. If you feel the BSD3 is too restrictive, another alternative is the WTFPL[1][2] which provides a formal contract of, essentially, public domain privileges (and is GPL-compatible). [1] http://sam.zoy.org/wtfpl/ [2] http://en.wikipedia.org/wiki/WTFPL -- Live well, ~wren

Tom Tobin

1:02 p.m.

On Mon, Jan 11, 2010 at 6:58 AM, Sebastian Fischer wrote:

...

when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL?

There was a long thread on licensing recently: http://www.mail-archive.com/haskell-cafe@haskell.org/msg68237.html I'm still waiting to hear back from the SFLC regarding the questions we came up with, and I'll post them as soon as I get them. I think in your case you can license the library you're writing any way you'd like, but distributing a statically linked binary might leave you with additional obligations under the LGPL. (Things get wonderfully more confusing when one of the libraries is the GPL, but hopefully we'll have more insight regarding that soon.) I'm not a lawyer, though, and I suggest that you take any advice from non-lawyers as hints rather than definitive answers. If you want an answer from a lawyer, the SFLC can be useful: http://www.softwarefreedom.org/

Matthias-Christian Ott

2:18 p.m.

On Mon, Jan 11, 2010 at 12:02:46PM -0600, Tom Tobin wrote:

...

On Mon, Jan 11, 2010 at 6:58 AM, Sebastian Fischer wrote:

...
when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL?

There was a long thread on licensing recently:

http://www.mail-archive.com/haskell-cafe@haskell.org/msg68237.html

I'm still waiting to hear back from the SFLC regarding the questions we came up with, and I'll post them as soon as I get them. I think in your case you can license the library you're writing any way you'd like, but distributing a statically linked binary might leave you with additional obligations under the LGPL. (Things get wonderfully more confusing when one of the libraries is the GPL, but hopefully we'll have more insight regarding that soon.) I'm not a lawyer, though, and I suggest that you take any advice from non-lawyers as hints rather than definitive answers. If you want an answer from a lawyer, the SFLC can be useful:

http://www.softwarefreedom.org/

You can also ask the Freedom Task Force of the FSFE: http://fsfe.org/projects/ftf/ftf.en.html They may offer better legal advice for Europe. Regards, Matthias-Christian

5612

Age (days ago)

5613

Last active (days ago)

List overview

Download

16 comments

12 participants

participants (12)

Andrey Sisoyev
Don Stewart
Duncan Coutts
Felipe Lessa
Jeremy Shaw
Ketil Malde
Matthias-Christian Ott
minh thu
Sebastian Fischer
Svein Ove Aas
Tom Tobin
wren ng thornton