4

We (small team in large organisation, in Germany/EU) have the following situation:

  • we use OSS libraries within our commercial products, licenses are checked and we are sure that we're complying (LGPL, BSD, MIT etc.., no copyleft)
  • these libraries do contain/link other OSS libraries, sometimes using other licenses

Now, our legal department has a very elaborate/expensive/time consuming process to check new libraries that we want to use. Part of the process manually checks every single file, including those of transitive dependencies in source form.

My question is: Are we really liable for license problems posed by transitive dependencies of our dependencies? My feeling is that the legal department (which is external) designed the process to take as many billable hours as possible...

Improve this question
3
  • 1
    I understand the situation as follows: You include source code A in your product, and source code A is licensed under license LA, but to use source code A requires that you also include source code B in your product, and source code B is licensed under license LB. Is your question whether you must comply with licenses LA and LB in order to include A and B in your product? Do you think you can ignore license LB for some reason? – Brandin Aug 16 '18 at 7:11
  • 1
    Not exactly, since I only ever "include" library A (not even in source form). Library A happens to also use library B internally, so maybe the term "transitive" is not the correct one. My question is whether I need to even consider license B when I only use A – Milan Aug 16 '18 at 16:13
  • 1
    If you include library A and then ship the product, then library A is also copied into your product. If library A uses library B and is copied into your product as well, then it means that in the end your product has copies of libraries A and B. In this case you need to review the license for each library that you "use," where "use" means copying in source or binary form into your product and shipping it to a customer. – Brandin Aug 17 '18 at 6:57
6

You should practice due diligence also for transitive dependencies. Open-source licensing is frequently shoddy, inaccurate, or slightly misleading. There's no malice involved, but especially smaller libraries treat licensing as an afterthought. So it is unwise to blindly trust your immediate dependencies' authors.

You have to comply with the licenses of all components in your system. Transitive dependencies can hide surprises:

  • A transitive dependency might be published under the GPL, which can require your application to be made available under the GPL. This tends to be undesirable for your company.

  • As a variant of the above, consider an LGPL dependency that can be used without such restrictions, but only under certain conditions such as that the dependency is dynamically linked and can be replaced by users. You have to be aware that these conditions exist so that you can choose an appropriate architecture for your code.

  • A transitive dependency may only be available under a license that includes a restrictive patent grant, and could potentially prevent you from suing a competitor (e.g. older React licenses).

So what your legal department doing is not per se wrong. It is a legitimate risk mitigation strategy. The question is whether the effort is proportional to the risk – a business decision.

Improve this answer
4
  • 1
    Thank you for this answer! "You have to comply with the licenses of all components in your system" is really the crux. I have a feeling that most larger OSS libraries may actually have hidden license problems. Are you aware of something like a database of "proven" libraries, where others have checked for license problems? Something like a crowd-legal-department :) – Milan Aug 16 '18 at 16:15
  • 2
    @Milan The Debian project is very careful about proper licensing. If they include packages for a software they've probably looked over the code – and any dependencies would also have to be available as a Debian package, which was subject to similar checks. If a project is part of a foundation, they probably have to follow that foundation's licensing procedures (e.g. Apache, GNU, …). Large, old libraries should be fine – projects tend to get their licensing in order as they mature, also because of users like your company. – amon Aug 16 '18 at 16:50
  • I've wondered if I could make an application that used a GNU GPL library and release my specific work under public domain, with the thought process of "I personally don't want to restrict users of my specific IP in any way, and hypothetically if you edited out the components that require the GNU library you can use this for any purpose you like" and it would then essentially be only GNU GPL when linked against the GPL library. I'm not sure what license I would put as the "official" one, though. – jrh Sep 30 '20 at 17:03
  • 1
    @jrh Yes you can do something like that. The GPL just requires that the resulting work as a whole (incl the library) must be available under the GPL, not that your parts would have to be GPL – they just need a compatible license. You could dedicate your parts into the public domain. The most effective tool for that is CC0, but that's arguably not an open source license because it doesn't fully protect the ability of recipients to use the software (it lacks a patent grant). You could also consider licenses like Boost. Avoid the Unlicense because it's written confusingly. – amon Sep 30 '20 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.