There is a lot of good advice here, but you really need to talk to your attorney, and if your company does not have an attorney who understands software and intellectual property, then you need to get one right away, especially if you may already be in license violation.

Basically for the two licenses you cited:

• GPL: If you use it in your application then you must release your application under the GPL. That doesn't mean you can't also sell it (like they sell Linux CD's) but you must also release the source code for free. That might work for you, but probably not.
• LGPL: If you use it in your application then you can still have a closed source proprietary licensed application. But if you modify the LGPL library then you must release your modifications under the LGPL, even though your application can remain closed source.

Keep in mind that the trigger point for the GPL license comes with distribution. This is why Google gets away with modifying Linux for their internal use - they never redistribute it. Since you are actually selling your software then you are distributing it, therefore if you use GPL code you must also license it as GPL.

I hope for your companies sake you haven't actually used any GPL code in your previously distributed application.

If you are bundling GPL licensed code with your application then that is a different story. You can just release the modified bundled applications under the GPL, and then keep your main application closed source. But if you have linked and distributed GPL Code into your application then your application is now GPL.

Again, talk to your attorney.

There seem to be some serious misconceptions here.

I work for a company that uses GPL code in their proprietary application... completely legally. How is this the case?

The GPL program is x264, which is used by the proprietary application AVCD. AVCD_x264 is a GPL wrapper that includes the x264 library. Frames to be encoded are passed via a pipe from the main AVCD app to AVCD_x264. By doing this, one never has to link proprietary to GPL code at all, yet one can make full use of the GPL software.

Of course, this isn't violating the spirit of the GPL either; since the wrapper is GPL, the customer can easily recompile AVCD_x264 himself and make whatever modifications he wants and have it still work with the main proprietary applications.

Of course, we distribute our product; if you don't distribute the app (its solely in-house), there are no restrictions whatsoever placed upon you by the GPL or LGPL.

GPL is classed as viral in this case, as if you have used or linked to it with any of your code, the licence requires you to release ALL of the source code (not just the GPL code) under the GPL licence, with certain exceptions (such as the classpath exception). LGPL is not parasitic in this case. As long as you have linked to the LGPL library dynamically then you can just release the code for the LGPL libraries.

Also check the FAQ ^[1] for the 2 licences.

There is only one correct answer to this question. Or, actually, there's about 210 answers to this question: ask (an) intellectual property lawyer(s) for the country/countries that you are going to distribute your software in.

You can distribute an app containing a GPL component without needing to release the entire app under the GPL if the distribution can be perceived as an aggregate.

The GPL is quite clear about this (see below), though as in everything GPLish the waters quickly get murky. In the end it seems to come down to a judgment about intimacy. Now where did I put that intimacy lawyer?

The excerpt below is from http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

What is the difference between an “aggregate” and other kinds of “modified versions”? An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

This is a tricky question to answer generally, since it really depends on many things. LGPL softens some requirements in the GPL specifically related to linking. GPL also exists in a classpath exception ^[1] variant where putting the library on the classpath of a proprietary application is not considered derived works.

I recommend that you read the GPL FAQ ^[2]. It tries to answer some of these questions.

One thing many people seem to forget is that the GPL mostly relates to distribution of software. Building a proprietary application and copying it internally in your corporation is not considered as distribution.

But to get a complete answer you need to seek legal counsel and / or contact the copyright holders to ascertain their opinion on the matter. Many open source projects are also dual licensed.

For Hibernate you should read http://www.hibernate.org/356.html -- it provides some insight and has this to say:

Using Hibernate (by importing Hibernate's public interfaces in your Java code), and extending Hibernate (by subclassing or implementation of an extension interface) is considered by the authors of Hibernate to be dynamic linking. Hence our interpretation of the LGPL is that the use of the unmodified Hibernate source does not affect the license of your application code.

Another thing you could do is to break up your applications into several modules that interact at arm's length. In this matter only the components that actually use GPL-licensed modules would have to be released under a GPL compatible license.

Everyone is missing the most important point here... your company surely has a policy towards GPL and LGPL and if you're working for your company you have to follow those policies. It's not about your opinion, its about the opinion of your legal/business departments.

Now as mentioned before, if you don't release a product, say you make an internal tool, then your Ok, GPL won't affect you. Probably 99% of the software companies in the world have internal tools based on GPL technology, so there is no issue with it (I learned this is safe from a software lawyer that works at my company).

If you build upon GPLed software, you must either license your application under the terms of the GPL to the people you distribute to, or you must negotiate with the copyright holders of that code for a non-GPL license. Anything else is copyright infringement.

You do not need to release your code to the entire world, only to the people you distribute to. But as you must license your application under the GPL, they are free to share your application with the entire world.

LGPLed software allows you to only provide the changes you make to the libraries themselves to the people you distribute to.

But above all else, you should be talking to a lawyer about this, rather than asking for legal advice on random Internet forums.

@ Thomas Vander Stichele ^[1]:

That couldn't be more wrong.

I'm not a lawyer but I AM a software engineer and I HAVE read the licenses and the FAQs.

Running in the same process has nothing to do with it. Running in a separate process is a sure way to indicate that the two binaries aren't linked or derivative, but a commercially-licensed runtime-loaded dynamic library (that is to say, a plugin) used by a GPL application (or vice versa) is also permissible under certain conditions. The plugin is only considered part of the application if they make function calls to each other and share data structures. If the application only invokes functions on the plugin (the plugin doesn't get to invoke functions on the application), and if the only data structures passed between the application and plugin are function parameters and return values (not global state, although both the application and plugin are permitted to maintain their own global state), it's not considered linking and the two components are not considered to form a single program.

This is derived from an article published by the Free Software Foundation; they ARE lawyers. :P

If your product incorporates any GPL code, you have to release all the code to your product under the GPL. The LGPL is more complicated. You have to make available the code of the LGPL component (including any modifications), and you also need to make it possible for someone to replace your modified version with their own (by dynamically linking the LGPL component, or by providing the object code, linker files, and instructions, or some similar route).

You can read the licenses online here: http://www.gnu.org/licenses

(or in the source of the components you're using)

Disclaimer: as everyone else here IANAL and this comment is only meant to make sure you ask your lawyer the right set of questions.

I read all the comments and nobody is pointing out a pretty important point: the fact that, if you don't actually link to the GPL code, it is fine to distribute your binary application and the GPL application.

Most people agree that 'linking' is to be interpreted as 'running in the same process'.

So, there are lots of ways in which a non-GPL program can use a GPL project: by spawning its command line tools (for example a closed GUI frontend on top of an open command line tool), or by building a GPL server on top of the GPL library and having the closed application communicate with that server.

I'm not saying this is morally the right thing to do - but 'running in the same process' is commonly agreed to be the border across which the GPL 'virus' spreads.

• with GPL you must distribute your app under GPL.
• with lGPL you must dynamicly link to the lGPL code, and you must provide the object files for your code so people can relink with a new (or modified) version of the lGPL libary.
• In both cases if you modify the libaries you must make the modified source freely avaible.

I think your company will be safe with the LGPL license, there is a simple an official explanation about the license and Java (I think this is a good example for the use of LGPL libraries in general):

... If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work. ...

http://www.gnu.org/licenses/lgpl-java.html

Best regards, Héctor.

I think that as long as you don't release the software you are ok. That is, if you run hosted solutions and never release any binaries, you are safe. If you ship binaries, you have to release your code. If you do ship binaries, I think with LGPL you are safe as long as you release source to the LGPL items, but you don't have to release the rest of your code. With GPL, you have to release all your code back under the GPL.

GPL: Your whole application becomes bound by the GPL. You can sell it, if you wish, but in any case you have to provide source code for the whole application, easily and for free.

LGPL: If you link to it only, you have no limitations. If you modify it then you have to provide source code for the modified version, easily and for free.

Caveat: IANAL (I am not a lawyer)

You can incorporate software with any license you want (at least in the open-source world) if you're never going to release a product.

If you're going to sell and distribute, though, that's the entire difference between the GPL and the LGPL. The former requires you to open-source your app, too, while the latter allows linking.

With the LGPL you should be safe. On the GPL side you have two options:

1. Provide a "service" without redistributing the product. This means you can have a hosted service (like Google does) but you can't distribute the final product to anybody.
2. Release your changes.

Keep in mind that the new version of GPL -- GPL3 -- has some changes for hosted applications as well (software as a service). From wikipedia on GPL ^[1]

The Affero General Public Licence (GNU AGPL) is a similar licence with a focus on networking server software. The GNU AGPL is similar to the GNU General Public Licence, except that it additionally covers the use of the software over a computer network, requiring that the complete source code be made available to any network user of the AGPLed work, for example a web application. The Free Software Foundation recommends that this licence is considered for any software that will commonly be run over the network.

Qt Software ^[1] has elaborated enough the differences between GPL and LGPL:

• A brief summary ^[2]

• Comprehensive FAQ ^[3]

You cannot use GPL code in a proprietary applications, you can, however, use LGPL code as long as any changes relevant to the LGPL code are made available to your users.

Some licenses like BSD licenses allow you to use the code in proprietary software without making changes available.

You really just need to look up each of the licenses individually for any others, but those are the main ones.

If the software is being developed for your (or your companies) personal use you can use any open source code you want (at least all the major licenses allow it), but if you ever distribute your software the license will become a problem

AGPLv3 is different from GPLv3.

While in some of the early drafts of v3, the AGPL clause was in the GPL -- it did not make the final cut and is a separate license.

Note: I realize this thread is old

My response is not based on legal reasoning but from a philosophical one.

The very idea of asking these types of questions violates the spirit of GPL and The Free Software Foundation. For anyone that has read their web site they are dead set against companies closed-source proprietary software.

They do make a valid point. Most commercial developers are looking for a free hand out from the FSF. This very question proves it. At the very core of their philosophy they do not want you using their software in any fashion unless you also make it free.

Here is a very simple rule. If you plan on selling software do not use GPL or LGPL. All these problems are solved by this simple creed.

There are so many conversations based on how to get around GPL and to a lesser extent LGPL. These conversations would never happen with a commercial companies License if they had the money to sue everyone using their software. Yet companies try their best to find ways around GPL. They do NOT want you using GPL software in your proprietary software. It's as simple as that. They are not out to promote the development of software, they are out to promote the development of FREE software. They despise proprietary software. It's written all over their FAQ's, license agreements, etc.

Quotes from GNU:

Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it. ( 1 ^[1])

Proprietary software development does not contribute to our community, but its developers often want handouts from us. Free software users can offer free software developers strokes for the ego—recognition and gratitude—but it can be very tempting when a business tells you, “Just let us put your package in our proprietary program, and your program will be used by many thousands of people!” The temptation can be powerful, but in the long run we are all better off if we resist it. ( 2 ^[2])

Here the GNU GPL comes to the rescue. The programmer shows the boss that this proprietary software product would be copyright infringement, and the boss realizes that he has only two choices: release the new code as free software, or not at all. Almost always he lets the programmer do as he intended all along, and the code goes into the next release. ( 2 ^[3])

The GNU GPL is designed to make an inducement from our existing software: “If you will make your software free, you can use this code.” ( 2 ^[4])

References:

• (1) ^[5]http://www.gnu.org/philosophy/why-not-lgpl.html
• (2) ^[6]http://www.gnu.org/philosophy/pragmatic.html