Hallo, Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs? Cheers, -- -alex http://www.ventonegro.org/
On Mon, Mar 05, 2007 at 02:07:05PM -0300, Alex Queiroz wrote:
Hallo,
Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs?
This is not the FSF, and most of us don't buy into the FSF's theories on static linking. Of course, if you want any kind of assurances, you'll have to contact Duncan Coutts directly (for Gtk2Hs, I dunno who for HDBC). (And the FSF's control over Gtk+ itself is irrelevant since while GHC can only statically link haskell code, it CAN dynamically link FFI libraries.) Stefan
On Mon, 2007-03-05 at 14:07 -0300, Alex Queiroz wrote:
Hallo,
Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs?
Well let me put it this way: I'm not going to sue you and I doubt any of the other contributers are either. When we last cleaned up our license story (standardising on LGPL 2.1) we weren't particularly aware of the static linking issue so we didn't include a specific static linking exemption. We could do that now but honestly it's a bit of a hassle since there are several copyright holders. I'm hoping that the issue will be solved by ghc being able to do produce packages as dynamic libs. If you're really worried (but I wouldn't be) then do recall that the static linking thing only requires that the end user be able to relink with a different version that preserves the same ABI. So you don't have to provide source for your closed source app, you'd just need to provide all the .o / .a files you need to link together to produce your final program. So it's a bit of a hassle but it does meet the requirements of the LGPL and allows a closed source app. So, concretely you'd do something like: ghc --make to build all the .o files for your app, ld -r -x them all together into one .o file. Ship that .o file along with any other closed source ghc package .a files and then anyone will be able to use (the right version of) ghc to link them together along with a modified version of the Gtk2Hs .a lib. Of course GHC doesn't make this especially easy especially since it doesn't make preserving ABIs very easy, but fortunately that's not really your problem. Duncan
Hallo,
On 3/5/07, Duncan Coutts
If you're really worried (but I wouldn't be) then do recall that the static linking thing only requires that the end user be able to relink with a different version that preserves the same ABI. So you don't have to provide source for your closed source app, you'd just need to provide all the .o / .a files you need to link together to produce your final program. So it's a bit of a hassle but it does meet the requirements of the LGPL and allows a closed source app.
Yeah, was pĺanning to send an object file with the application to allow relinking. I was just curious about the LGPL because GHC always links everything statically. Thanks for the thorough answer! Cheers, -- -alex http://www.ventonegro.org/
Hi
Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs?
If you are concerned about static linking, Yhc may offer a solution, since it produces bytecode files, which don't statically link to anything. Of course, it doesn't support either of the above libraries, but if avoiding static links to your number one priority its the best compiler to use :) As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag. Thanks Neil
On 3/5/07, Neil Mitchell
As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag.
I am not a lawyer, but there are a couple of important points getting missed in this thread: (1) Few people have ever claimed that copyright law in the United States made any rational sense. Even so, Americans are subject to it, anybody who uses GPLed software may be subject to it, and given that the general trend is toward international treaties that subject their member nations to the copyright requirements of the nation with the most restrictive intellectual property laws, it may be safe to say that everyone is subject to it. "That's just silly" isn't a defense. (2) To paraphrase Eben Moglen, the legal basis for copyrighting software in the US is predicated on the notion that certain large numbers can be copyrighted. Thus, if you can infringe copyright by adding one to a large number, it suddenly doesn't seem so absurd that you can infringe copyright by setting a command line flag. (3) The GPL has never been tested in court, so debates about whether or not static linking can result in a GPL violation are ultimately academic, at least insofar as the real question is whether it's prudent for a company to use GPLed libraries in proprietary software (as the real question usually is). If someone is asking about GPL issues in the first place, it's probably because their boss told them "our lawyers say we're not allowed to use anything GPLed," and thus "trust me, we're not going to sue you" isn't the answer they're looking for, even if it's a completely accurate answer. Since there are people reading this list who release their software under various flavors of the GPL, and who thus presumably care that the free software they sweat over will remain free in perpetuity, hopefully this reply isn't entirely off-topic! Cheers, Kirsten -- Kirsten Chevalier* chevalier@alum.wellesley.edu *Often in error, never in doubt "I haven't got the slightest idea how to change people, but still I keep a long list of prospective candidates just in case I should ever figure it out." --David Sedaris
(3) The GPL has never been tested in court
http://www.fsf.org/news/wallace-vs-fsf note that during this thread there was a note from a contributor to promise to not sue a potentially infriging use. you should be careful of such promises, particularly considering that some fsf licenses include copyright assignment...in which case it will be the fsf enforcing the gpl, not the original authors (which is the specific purpose of the assignment). the fsf has a vested interest in showing that their licenses have teeth, although more in the case of the glp than in the lgpl. http://www.gnu.org/licenses/why-assign.html
brad clawsie on 2007-03-05 20:30:24 -0800:
(3) The GPL has never been tested in court
http://www.fsf.org/news/wallace-vs-fsf
note that during this thread there was a note from a contributor to promise to not sue a potentially infriging use. you should be careful of such promises, particularly considering that some fsf licenses include copyright assignment...
No FSF licenses include, demand, or require copyright assignment. The FSF encourages developers assign them the copyright to pieces of free software for the reasons enumerated in the link you mentioned, but this assignment is not a requirement for using the GPL or LGPL. Case in point: the Linux kernel.
Kirsten Chevalier wrote:
I am not a lawyer, but there are a couple of important points getting missed in this thread: [...] "That's just silly" isn't a defense.
and thus "trust me, we're not going to sue you" isn't the answer they're looking for, even if it's a completely accurate answer. I'm not a lawyer either, but I've discussed this a bit with one. Since
[...] the GPL is a voluntary licensing with no renumeration, the intent of the licensor will be given a lot more weight than in a negotiated agreement between two (more or less equal) parties. I think a clear statement from the author that linking statically is allowed in his interpretation of the license will be sufficient, even if it's not obvious from the licencing text. FSF or other third parties opinions should be irrelevant. So actually asking and getting the author's opinion is probably a good idea. This is according to Norwegian law, but I think such a statement will in any jurisdiction make it clear that you were acting in good faith. (Just make sure you have a contingency plan for when Duncan asks you to cease and desist :-) (And of course there's nothing to prevent you from being met at the airport the next time you travel to country with different copyright law enforcement. Also, there are other copyright holders to this particular code who may want to have their say in the matter.) -k
Neil Mitchell wrote:
As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag.
But you do infringe copyright by shipping a program including an LGPL'd library in such a way that the user cannot easily exchange said library for a newer version, thereby violating the LGPL in letter as well as in spirit. (Duncan should have chosen another license if he intended to allow Gtk2Hs being linked to proprietary software and then distributed.) -Udo -- The Turing test is turning out not to be a test of artificial intelligence, but of human stupidity. -- seen on slashdot.org
Hi folks I've noticed several messages to this list carrying attached files. I'm concerned about rogue data being propagated this way. Would the list moderator reconsider the policy regarding attachments? Thanks, Paul
P. R. Stanley wrote:
Hi folks I've noticed several messages to this list carrying attached files. I'm concerned about rogue data being propagated this way. Would the list moderator reconsider the policy regarding attachments?
If you mean udo's message, they're cryptographic signatures, which identify the sender of the message. If you mean (for example) alex queiroz' message, that was just a multipart (plain text/HTML) mail. Neither of these things are dangerous. In any case I strongly recommend you use an email client which you are confident will never execute code in an attachment without your express permission. Ultimately you need to be in control, otherwise a random junk mail author may catch you out. Jules Bean
On Tue, 2007-03-06 at 10:31 +0100, Udo Stenzel wrote:
Neil Mitchell wrote:
As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag.
But you do infringe copyright by shipping a program including an LGPL'd library in such a way that the user cannot easily exchange said library for a newer version, thereby violating the LGPL in letter as well as in spirit. (Duncan should have chosen another license if he intended to allow Gtk2Hs being linked to proprietary software and then distributed.)
Well actually LGPL is not to bad for that purpose, and since it's the licence of GTK+ itself it keeps things simple. As Neil pointed out, this is only a problem for current versions of GHC that do not support dynamic linking and as several people have pointed out it's still quite possible to abide by the licence and use static linking. Once GHC supports dynamic linking on linux & windows (as it does currently on OSX) I think people will stop worrying/complaining. Duncan
On Wed, 2007-07-03 at 11:11 +0000, Duncan Coutts wrote:
Once GHC supports dynamic linking on linux & windows (as it does currently on OSX) I think people will stop worrying/complaining.
About this issue. ;)
--
Michael T. Richter
On Tue, 2007-03-06 at 03:00 +0000, Neil Mitchell wrote:
The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag.
Just because it's easy to change between the two modes doesn't mean it's not different. There is a real difference for an end user between a single monolithic .exe file and a .exe with a whole bunch of standard open-source LGPL .dlls. In once case you really can make changes to the open parts of the system, in the other you cannot. That was exactly the point of the LGPL, to allow open components to be used in an otherwise closed system - but still let you play with those open components. Duncan
Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs?
Of course, just read the LGPL again. It doesn't prevent use of static-linking. It's a bit long and verbose with odd-sounding rationales, but all it really says is that you should make sure that the LGPL'd part of your application can be modified by the end user. Dynamic linking is the easiest way to get that result, but it's not the only one. Stefan
participants (13)
-
Alec Berryman -
Alex Queiroz -
brad clawsie -
Duncan Coutts -
Jules Bean -
Ketil Malde -
Kirsten Chevalier -
Michael T. Richter -
Neil Mitchell -
P. R. Stanley -
Stefan Monnier -
Stefan O'Rear -
Udo Stenzel