LGPL NuGet package best practices

Topics: General
Aug 21, 2013 at 2:54 PM
I've been dealing with creating a package from an LGPL library. I've seen two approaches to do this in NuGet:
  1. Treat it as a regular package and just include the assembly and a license URL pointing to the LGPL license.
  2. Include the license file in the package and add it to the project files so it is automatically included in build output.
While I understand number 2 in the sense that LGPL requires that binary redistributions be accompanied by a license file, there are a number of composition issues with doing things this way.

Namely, it may happen that two different packages try to add two license files with the same name. Also, it may not make sense to have the license file in the build output if I'm just making my own library that dynamically links to the LGPL one; LGPL does not require that code that uses the library is itself LGPL.

What do you guys think? Is licenseURL enough to satisfy the redistribution requirements of LGPL? If not, is it possible to include the license file in the package, but not as part of the project? How do you feel these kind of licenses should be dealt with?

Thanks!