views:

60

answers:

4

We are developing a closed-source proprietary product that uses quite a few open source projects and we have not been methodically cataloging them, along with their licenses. Now we are trying to build a deployment package and we'd like to get into compliance. What's the easiest way to accomplish this?

Should we make one big text file with all the license information or should it be separate files for each open source project or each license? Do we have to include the actual file that came with the project? Does it have to be in the same directory as the project's files?

I was thinking of a simpler approach but I'm not sure if it complies. What if we just identified all the different licenses (not projects) and make up one big text file with all the license verbiage for each one, and at the top say something like "Product XYZ is proprietary software which incorporates open source software that is covered by the following licenses." (The individual open source projects would not be identified by name).

Or alternatively, the same as above, except identifying each project by name, along with their license, but all in 1 file?

+1  A: 

IANAL but each license typically tells you exactly what you have to do to be in compliance. Something like "this text must be included" or "this copyright line must be included". So read each one and do what it says. If they don't say that a specific file must be included then, yes you can combine them. Some even say you have to add it to your documentation as an attribution.

James Keesey
+4  A: 

Talk to a lawyer.

You can start by gathering license information for each package that you use and reading them. Many licenses (Boost license) are quite clear and permissive while others (GPLv3) are not so clear. Most of the time an attribution in your documentation will suffice. If you are distributing source, then you will likely need to distribute each license file along with either the source of each package or a reference to where it can be downloaded.

In any case, read the licenses and then talk to a lawyer.

D.Shawley
+1 for telling him the plain, unvarnished truth.
John R. Strohm
I've been through this a few times in a corporate context. Too many people think that redistributing OSS is simple.
D.Shawley
+1  A: 

You read the license for each component you're using, understand it, and do whatever it says is necessary to comply.

we have not been methodically cataloging them, along with their licenses.

You really should. The last thing you want to to find out right before you ship that one of the components you're using has an incompatible license, or onerous terms.

Andrew Medico
You should always be keeping track of licenses, no matter whether they're open source or not. Not all proprietary licenses are the equivalent of BSD that you paid money for, and the proprietary licensers are likely not as nice as the Gnu licensers.
David Thornley
A: 

The advice to talk to a lawyer is probably the best on here (and +1 for that, as well). Something to remember, though - if you are including multiple licenses within your source, you need to comply with all of them. So, if all the licenses are permissive except one, you may have to open source your software.

Just something to be aware of.

JasCav