A common question that I am asked in my seminar on license-compliant delivery of products that contain open source software is:
But what about a work-for-hire? We are a consulting company: As we work for our clients, and use open source software, do we have to create all those legal notices?
The answer, as so often is: It depends. With that, let’s tease the different situations apart.
The first common misunderstanding is to believe that you, the supplier (consulting firm) are responsible to the public for your use of open source software. You are not: Most open source licenses only structure the relationship between the supplier and the client, so whatever the problem, it can only come from your client, and hence you may be able to preempt it in your contracts or negotiate your way out.
Next, licenses in general only apply to a distributor of open source code and the recipient of that code, where distributor and recipient are different legal entities (companies). Then, the first question is: Are you actually distributing open source code? Usually you are not. Your code is your code and well-written code doesn’t copy and paste open source code but rather declares dependencies. Hence, in the most common situation, you only distribute your own code and all open source use in building and execution takes place on the client’s virtual premises. The client pulls in the open source code, not you.
But what if you actually have to give your client open source code as part of your work? Don’t you have to jump through all the hoops the licenses require of you? The answer: Maybe. However, before a client holds you over a fire for not providing license-compliant open source code, they are more likely to come after you for violating the terms of your contract with them. A competent client has policies in place that govern the use of open source, and if you don’t comply with them, you are first violating your specific contract with your client before you are violating a general obligation like an open source license. So, you may get into trouble, but not because you are not license-compliant.
Finally, lets assume the most outsourced situation of them all: You are just shipping binaries. Then, you have left the realm of traditional work-for-hire and entered product-land. If your client doesn’t want the source code, just binaries, you are indeed distributing open source code with your binaries, and you’ll have to distribute them in a license compliant way. If, as is now common, you ship container images, you will have to handle the obligations of all code in the full stack, if you want to be license-compliant. It may not be a problem, if your client doesn’t care, but since you are headed for a product, you may want to do it anyway.
In summary, if you sign over the copyright of your code to your client, and build and operate software on their behalf (as their agent) I don’t see how you have to create the full license compliance artifacts (i.e. the legal notices). Your client may want you to do it, but this then simply becomes more (laborious) contract work you will probably want to be paid for. If you are keeping the copyright to your code, for example, because you want to grow a product through project work, you still may not have to, but should do it anyway.
Some of these statements need to be modified depending on the license. Permissive licenses are generally fine, but Copyleft licenses, like the GPLv2, will throw a wrench to this, as they don’t allow restrictions on licensing when passing on code. However, in particular Copyleft-licensed code is almost always excluded from use anyway.
If you want to learn more about this, I recommend you participate in my license-compliant delivery (LCD) seminar (upcoming instances) and if you need to dig deep into how to be compliant with a particular open source license, I recommend you inquire about our license-compliant delivery handbook. The LCD handbook includes a detailed accounting of the obligations of the most common licenses, including step-by-step guidance of how to comply with them.