The company I work for develop and sell a proprietary, closed-source software application. Our application uses third party open-source projects licensed under open source licenses such as GPL and LGPL. For instance, we use Hibernate as an ORM.
Sometimes we modify and build upon these third party projects.
What is required of us to not be in violation of the GPL and LGPL licenses when it comes to selling and distributing our closed-source application?
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.
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
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 for the 2 licences.
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.
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:
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 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. 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.
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.
I'm very curious about that. Does anyone have a firm answer yes or no?
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)
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:
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 lawyer.
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).
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
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.
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.
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.
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.
@Thomas Vander Stichele:
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
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.
Hi Adam,
Thanks for the information, but as per the FAQ in GPL its written :-
"If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins."
So do you mean to say that in a single sided communication form GPL to Non GPL application doesnt violate the GPL license even thou i share its data structures?? Need a detailed explanation.
can you send me the link to the article published by the Free Software Foundation.
Thanks
Qt Software has elaborated enough the differences between GPL and LGPL:
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.
You can also refer to the below link that talks about LGPL !
http://www.keyongtech.com/5486103-static-linking-in-lgpl-upgrading
Karthik Balaguru