Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

Can You LGPL an Application? 15

Posted by Cliff from the when-is-an-application-a-library dept.
Tim writes "Can you really use the LGPL for an application--that is, code that isn't part of a library? I've been reading over the LGPL again in preparation for licensing an application of my own, and I feel that the LGPL would best fit my needs/wants. However, section 2a of the LGPL makes it very clear that a work 'based on the Library' must 'itself be a software library.' Section 0 also makes it clear that a 'library' means 'a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.' So, given all this, why is it taken for granted that you can release an application/executable under the LGPL?" It must be stated that applications link to libraries and are not based on them. I may be splitting a few hairs here, however. What do you think?
This discussion has been archived. No new comments can be posted.

Can You LGPL an Application? More

Can You LGPL an Application?

Comments Filter:

  • Well, it's been done before (Score:1)

    by Anonymous Coward
    "Bochs", an x86 emulator, is LGPL, and it's not a library. As for the legality of this, I think some Linux company (was it Mandrake? don't remember) hired the app's copyright owner as part of the deal that bochs would become LGPL, so obviously it had some commercial support, and commercial support usually has laywers.

    IANAL, and hell, I haven't read the LGPL. I've read the GPL, but the LGPL seems a lot more confusing for some reason.

  • >In other words, section 2a says that a modified
    >version of the covered work must be a software
    >library--in the technical sense that we all know

    Maybe I'm missing something here, but why don't you just take the license, and change library to application? (Obviously you'd probably have to change some other sections.) If you like the core of the license, use it, and just adapt it as required.

    Is there reason you can't / don't want to do that...?
  • You mean their licenses don't fall under the [L]GPL terms, in that anyone can modify them as long as they make it clear?

    Wow, that bites.
  • Here are a few thoughts. Since I am not a lawyer, not only do i not know what a court would think, you shouldn't put too much stock in my opinion.

    If you're more concerned with the notion of "how do i communicate to others what I would like to let you do with this source code I've written", then perhaps this will make some sense.

    First, a program an a library are trivially convertible between each other, at least in C/C++.

    Consider a program, which has a function main(). Perform the following steps:

    1. rename the function main() to main2().
    2. link all of the .o files in the program into a library.
    3. create a function main(), which calls main2(), possibly passing argc/argv, and possibly returning the return value from main2() .

    Practically, this is a very different beast than a real library, which implements a hopefully thoughtful API. However, there is no obvious technical difference between all the .os of a program in an AR archive and a library, so it's not clear to me what a court would think.

    You could also try a dual license under GPL/MPL or LGPL/MPL. Both of these would allow users to do things like linking in non-GPL code, while allowing GPL code to be linked in, although this may still not be possible (since it is the third-party's GPL code that is causing the problem, code you have written).

    You could license under a BSD license. Again, you would not be able to link w/ third parties' GPL code and proprietary code at the same time, since that would violate the third parties' GPL (unless they explicitly allowed this).

    Finally, you could offer your code under a GPL w/ a "module exception". Linux is licesnsed this way (it explicitly indicates that it does not view third-party closed-source modules to be in violation of the GPL). Again, if someone didn't like this interpretation of the GPL, no one would be able to link in their GPL'ed code w/ a proprietary plugin or module.

    I hope that that makes sense.
  • Again, use the MPL 1.1, with the dual-licensing clause, and the GPL as the second license named in Exhibit A.
  • So I'd suggest the MPL 1.1, which does pretty much the same thing but doesn't have any "library" language.

    Anything about the MPL that bothers you?
  • On reading my own submission, I think perhaps that I need to clarify my own question a tad...

    The reason I even thought about this was due to the fact that licensed code is always referred to as a "Library" in the LGPL. Not surprising, given that LGPL originally meant Library GPL, but still confusing, if you're wanting to license an application under the LGPL, rather than just a plain old software library.

    When I read more into the text of the LGPL, I found what I noted above, and that really bothered me. If a modified version of the licensed code is required to be a "library" (which is defined in section 0 in the intuitive way), then how can you create an application, and license it under the LGPL in such a way that anyone can modify and redistribute it in application form without violating the license?

    In other words, section 2a says that a modified version of the covered work must be a software library--in the technical sense that we all know and love. This works great for software libraries licensed with the LGPL, but it doesn't seem so hot for applications that want to do the same. In fact, it seems like a pretty big discrepancy (unless I'm really missing something ;) )

    I hope this helps. I'm very interested to see if anyone else has thought about the same thing.

  • RMS's stance is that dynamic linking produces a derived work. Thus, you can only dynamically link GPLed code with GPLed code or LGPLed code.

    If you implement plugins with dynamic linking, you can't have closed-source plugins unless you use the LGPL (or something LGPL-like).

    So sometimes, it does make sense to want to LGPL an application. But I don't see how it can be done. And using some non-GPL license will pretty much make my code incompatible with the GPL, which is also bad.
  • The LGPL differs from the GPL in that programs can link to the library without themselves being covered under the GPL.

    It doesn't make any sense to LGPL an app. If it's an app, you won't be linking to it, and it's the same as if it were licensed under the GPL. You still need to distribute source, you still can call the app (as a whole) from non-free programs, etc.

    Am I missing something here?
  • If a modified version of the licensed code is required to be a "library" (which is defined in section 0 in the intuitive way), then how can you create an application, and license it under the LGPL in such a way that anyone can modify and redistribute it in application form without violating the license?

    As DeadSea wrote in response to another article [slashdot.org], it's generally better to implement libraries as libraries than nonmodular applications. Implement the functionality of your application as a library, or a set of libraries, and a stubby little main routine, and then you won't really need to care about whether the LGPL can be applied to things that aren't libraries.
  • I don't know about applying the verbatim LGPL, but if you can't, there's nothing stopping you from modifying it to your own license. Easiest thing would be to use it all the same except the part the conflicts (if it is determined to conflict).
  • IBM has also released their K42 OS kernel under the LGPL.
  • From:

    http://www.gnu.org/copyleft/lesser.html& lt;/a> [gnu.org]

    This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

    Why you shouldn't use the Library GPL for your next library

    http://www.gnu.org/philosophy/wh y-n ot-lgpl.html [gnu.org]

    Useful resources: http://www.gnu.org/philosophy/li cen se-list.html [gnu.org]

  • Three words: Not GPL Compatible [gnu.org]. I'd suggest MPL/GPL disjunction (like the Gecko engine, soon) or GPL with permission to link [gnu.org] (like libstdc++, Guile, and the GNU Ada libraries).
  • That's why I suggested the MPL 1.1, not the MPL 1.0. See [mozilla.org]
    http://www.mozilla.org/MPL/MPL-1.1.html, section "13. MULTIPLE-LICENSED CODE".

Slashdot Top Deals

The biggest difference between time and space is that you can't reuse time. -- Merrick Furst

Close