2

We have a Java project which uses a couple of libraries licensed by LGPL-2.1 and uses MongoDB which is licensed by AGPL-3.0 as its database. We don't modify any of them.

Our legal team claims we should provide source and build/install instructions for these Open Source Libraries/Software.

However I think only AGPL-3.0 requires build/install instructions according to the following links.

https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) https://tldrlegal.com/license/gnu-affero-general-public-license-v3-(agpl-3.0)

Am I right?

  • 3
    IMHO you should not rely on tldrlegal as the primary source for your conclusions. Use the source, aka. the original license texts. – Philippe Ombredanne Oct 21 '16 at 7:38
9

However I think only AGPL-3.0 requires build/install instructions according to the following links.[...] [and not the LGPL-2.1]

Am I right?

Nope.

These links are not the license proper. Just commentaries about it (and based on what I can see incomplete commentaries). You should rely on the license text instead.

Our legal team claims we should provide source and build/install instructions for these Open Source Libraries/Software.

They are correct.

The LGPL 2.1 text explains in Section 0 what is "Source Code":

"Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.

You must redistribute the source code of LGPL-licensed libraries to your users and therefore this includes build scripts.

The text explains further in Section 6 (emphasis is mine):

For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

The key is must include any data and utility programs needed for reproducing the executable from it. What this means is that you would need to provide the source code alright and either the build scripts and/or alternatively build instructions if there is no such script.

In the case of a Java library, the most likely case is that the upstream library source code already comes with a Maven POM of sorts or some gradle/ivy/ant/sbt script. So if you collect the original source code for that library from upstream as you should, chances are that these will contain everything that is needed to build both in terms of scripts and instructions.

Furthermore, in the case of a Java library, you would not include the Java compiler. The end of section 6 of the LGPL 2.1 explains why:

However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

So if you used a certain version of Java to compile, you could state this in your instructions and point to where this could be fetched but in general I would not include a JDK itself in my redistribution, nor would I include major build tools such as Maven or Gradle.

Thomas Owens furthered asked in a comment:

Do you have a citation to support this? I agree that the intent is to ensure that the source code can be rebuilt, but the use of "data and utility programs needed for reproducing the executable from it" can be ambiguous - some people may not interpret "data" as also including written build instructions, if the build process is not automated.

The key point is that the recipient should be able to rebuild from sources. Without the build instructions (as doc or as a script) the user will not be able to rebuild the sources and your re-distribution would not be compliant.

As explained above the LGPL 2.1 text explains in Section 0 what is "Source Code" very explicitly and it includes build scripts.

Here are some extra references if this is not enough to get you convinced:

On FFmpeg legal FAQ. Libav does the same:

  1. Explain how you compiled FFmpeg, for example the configure line, in a text file added to the root directory of the source code.

On the GPL2 FAQ DistributeExtendedBinary section :

No, you must supply the source code that corresponds to the binary. Corresponding source means the source from which users can rebuild the same binary.

I consider this FAQ entry to apply equally to the LGPL. Without build instructions you would likely be unable to rebuild the binaries.

Beyond, Cisco's Suppliers guidelines state in an SEC filing that they require the provision of build instructions for L/GPL (Section2 Publication Archive):

Along with the Publication Archive, you must provide a file named “README” at the root of the Publication Archive which contains instructions (such as an ordered list of Unix shell commands) for building the source code into installable object code

  • Do you have a citation to support this? I agree that the intent is to ensure that the source code can be rebuilt, but the use of "data and utility programs needed for reproducing the executable from it" can be ambiguous - some people may not interpret "data" as also including written build instructions, if the build process is not automated. – Thomas Owens Oct 21 '16 at 15:08
  • @ThomasOwens See the extra elements I added to my answer. Beyond this, I never saw any lawyer consider that build instructions should not be provided. Instead what I see is lawyers that insist that the code is buildable. Buildable means have scripts and instructions. – Philippe Ombredanne Oct 22 '16 at 19:03
  • 1
    It seems like with other aspects of open source licensing, there's never been any challenges or legal rulings that test aspects of this license. It looks like Cisco, FFmpeg, Libav, you, and I all agree that the intention is to require the source code be buildable and match the executable (required by the GPL and LGPL), but the instructions for actually building it are included. I'm surprised the GPL FAQ doesn't clarify this, and would be curious as to if a court would consider build instructions "data and utility programs needed for reproducing the executable" from the provided source files. – Thomas Owens Oct 22 '16 at 19:21
  • @ThomasOwens fair enough. I am not too concerned about the courts. I am more interested about doing what I think is the right thing. But to your point, this has surely not been tested. – Philippe Ombredanne Oct 22 '16 at 19:37
  • 1
    Fully agree there. I was hoping that what I considered to be vague terms was clarified somewhere, either in a FAQ I missed or by a court. Apparently not. Hope this answer gets the accept is deserves. – Thomas Owens Oct 22 '16 at 19:39

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.