I'm interested if monkey-patching is considered a modification by LGPL 3.0 and MPL 2.0 licenses.

Specifically, I'm interested in monkey-patching of ruby code. E.g. I require an LGPL library (e.g. sidekiq) and apply a patch in run-time. Here I have a couple of questions:

1) Is it considered a modification of the original work?

2) If so, what part of my software shall be copylefted by the same license now?

migrated from softwareengineering.stackexchange.com Apr 23 at 18:40

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 1
    What are you actually distributing? Just your "monkey patching code" or are you distributing the LGPL/MPL licensed code toeghether with your "monkey patching code" and then running the whole thing as one program? – Brandin Apr 24 at 4:36
  • @Brandin actually I think I do not distribute anything since I'm writing a backend REST API which runs on the servers of a single company. And even if I'd distribute this to more than 1 company, my app dependencies are installed via the package manager (rubygems.org, much like npm) which downloads and installs other libraries, so in that case, I guess it would be just my "monkey-patched" code. – Danny Ocean Apr 24 at 14:39

(mandatory disclaimer - I am no a lawyer)

As far as I understand the license, the fact that you're using monkey patching is inconsequential. The core issue here is that you're using an LGPLed library, modifying its behavior in some way, and then using it. Whether you're monkey patching it, wrapping it, inheriting from it or whatever probably isn't the point here. The main point probably is how tied to that library your code is. If you're providing a general monkey-patching mechanism (e.g., automatically logging every API call), that could be applied to any library, you're probably free to license it as you will. If it's deeply tied to that library (e.g., you're redistributing the LGPLed library and just slightly tweaking some functionality by monkey patching), chanced are it should be considered as a modification of the existing work.

  • 1
    Even so, you can probably isolate the monkey patching logic into its own little chunk, combine it with the existing library, and distribute the combination under the LGPL, then call into it normally from your proprietary code. This is really only a problem if your monkey patching is pervasive and tightly coupled to the original library... in which case you should take a hard look at your overall design, because that's just terrible. – Kevin Apr 27 at 5:51

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.