3

We are building a product with 100s of OSS dependencies. We want to fully comply with the OSS license terms.

Let's assume our product has a direct dependency "DDep_v1" under MPL-2.0 license, and "DDep_v1" itself has a direct dependency "TDep_v1.8" . Now TDep_v1.8 has a vulnerability, which is fixed in TDep_v1.9, and therefore I want to change DDep_v1 to point to TDep_v1.9 (instead of _v1.8). No other changes at all.

Here is the question: Is the mere change of the version of the dependency a modification of DDep_v1 that makes it a 'Derivative Work' with all its implications (notice of modification, etc)?

Are there any publications on this topic?

The question is not limited to the MPL-2.0 license, I just use it here as an example.

Improve this question
3
  • Are you going to distribute TDep_v1.8 and TDep_v1.9, or a compiled version of either of those, along with your software/product?
    – Brandin
    Sep 13, 2021 at 14:15
  • @Brandin: The plan would be to distribute DDep_v1 together with its new/changed dependency TDep_v1.9
    – Martin_in_AUT
    Sep 14, 2021 at 16:07
  • This is probably only definitively answerable with the license in mind. For example, MPL, as you mentioned, actually defines "Modifications" in the license, so you could say that since you are including TDep_v1.9, that inclusion counts as a "modification" even if you didn't actually 'author' the change from v1.8->v1.9. I checked a few other OSS licenses, and there is not such a definition, so it wouldn't be clear how to answer it for any other licenses.
    – Brandin
    Sep 14, 2021 at 16:26

2 Answers 2

Reset to default
2

Here is the question: Is the mere change of the version of the dependency a modification of DDep_v1 that makes it a 'Derivative Work' with all its implications (notice of modification, etc)?

I am not sure if you are creating a derivative work from a purely legal standpoint, but from a practical perspective, I would treat your modification as if it is.

From the viewpoint of good software engineering practices, if you make a change to any file of DDep that affects the build output (or what gets bundled), then you should give that modified DDep a new version number. And once you give your new build of DDep a separate version number, then for all practical purposes it should also be considered to be a Derivative Work.

The reason for giving the changed build a new version number is to make sure you can prove to the relevant stakeholders that the correct version of each (transitive) dependency will be picked when you re-build your product. But once you have created DDep_v1-mycompany, it is way easier to treat it as a Derivative Work than to argue that it is legally the same as DDep_v1 even though a change has been made that warrants a new version number.

Improve this answer
0

No, a change in your dependencies is not a modification of your product and not considered a derivative work. Your product has not changed in any way beyond a minor documentation change.

However, if the change in the dependency requires modifications to the source code of your product, that would constitute a patch update under semantic versioning, or a more substantial update depending on the scale of changes.

Even disregarding that, a change in the licensed software by the holder of the property (the "owner"). "A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work.'"

Improve this answer
4
  • 1
    If I'm not mistaken, the question doesn't ask whether the modification makes a derivative work of the OP's product, but whether it makes a derivative version of the DDep_V1 library.
    – MadHatter ♦
    Aug 14, 2021 at 7:44
  • In either case, the situation is the same. By simply changing which version of a dependency you reference in your work, you typically will not be making changes significant enough to be considered derivative. However, if you fork a copy of DDep_V1 and modify that, then you are making a derivative of that, but that doesn't seem to be the question here.
    – Chris
    Aug 23, 2021 at 15:19
  • Under what definition do you believe that a minor change is not "significant enough" to be a derivative? The law link you point to seems to say that any change would make it a derivative (I would consider even a small change to be at least an editorial revision, or an annotation). By the way, I do not get the impression that it's only a version number being changed in this example. The version number changed in order to signify that a security flaw was fixed. The actual fixes in the code are probably the interesting changes, and there's no telling how significant those changes were.
    – Brandin
    Sep 13, 2021 at 14:20
  • @Brandin The fix of the security flaw from TDep_v1.8 to TDep_v1.9 is likely significant enough to make it a derivative work, but that was done by someone else and is not my change (and not the question). The question relates to the change I am doing to DDep_v1, which is just an update to a pointer to the dependency version, without any creativity or inventive step. Does this "as a whole, represent an original work of authorship" (to take the quote from the legal link above)?
    – Martin_in_AUT
    Sep 14, 2021 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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