GPLv2+ and LGPLv3: Implications on project where OOP subclassing involved

Events happening in the community are now at Drupal community events on www.drupal.org.
Sohodojo Jim's picture

I understand from the GNU Licensing compatibility matrix (http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility) that what I need to do is permissible. But I want to take a quick dip here to avoid headaches and wasted time/effort in the event that I misunderstand.

There is a widely used PHP class for Google maps that implements the JavaScript API v3. (The primary Drupal Google mapping modules are 'legacy dependent' with code bases written to API v2.) This API v3 library/class I want to use is licensed under LGPLv3.

My wrapper/extension module needs to subclass this LGPLv3 class in order to make its functionality work within Drupal. The actual source files for this library/class will not be included in my module and I will point folks to the Google Code repository where this is freely available. However, it is essentially impossible to subclass and override something else without including bits and pieces of the parent class if only to map to the naming conventions, parameters, etc. necessary to have a functional subclass.

So my bottom line question is: Can my proposed module be included in the DO repository?

My assumption is that this module would, in effect, be interpreted as itself being licensed under the GPLv3 license when 'conveyed' (that is, downloaded and used by any recipients) while all of Drupal and its 'host' repository is and remains GLPv2+.

Thanks for clarifying,
--Sohodojo Jim--

Comments

Implications

acubed's picture

As long as you are copying significant "bits and pieces" of the parent code, I would suggest shipping the entire repository to make sure you distribute compatible code. Code on drupal.org is released under "GPLv2 or later" so the resulting project would be acceptable because it would simply be a GPLv3 project, by implication, even if the main LICENSE file says GPLv2 (you may want to note this in the main README, of course, if not a LICENSE file).

If the code you are copying is not significant enough to need updates if the parent code functionally changes, it may not qualify to be a derivative work, especially if that code is trivial and absolutely necessary to interoperate with Drupal. However I'm not sure exactly what the code in question is, it's a big "if" and that's quite a lot of worrying just to make sure you can distribute something as GPLv2, and may not likely even apply to non-US countries (if they wanted to use/redistribute the code - so far as I've seen foreign laws doesn't apply to drupal.org), plus distributing the external project wouldn't be an option - life's too short, get back to coding.

Thanks for your insights...

Sohodojo Jim's picture

Acubed,

Thanks for your thoughtful comments. I believe, as you imply in the your first paragraph, that my eventual released module would be okay via the "GPL2+" plus "LGPL3" 'parents' equals "GPL3" 'child' mechanic of how this all works.

As to your paragraph two insights, these are 'how much' and 'of what kind' details to consider when my module is closer to release.

At root, this is an itch I am scratching for my own specific use no matter what. If it turns out that what I've done can be released so others won't have to reinvent this wheel, that's simply a bonus.

Back to coding! :-)
Sohodojo Jim

--Sohodojo Jim--
http://sohodojo.com

That may not work ...

Aveu's picture

According to the Free Software Foundation's website you should not blend these two licenses (emphasis added):

GNU Lesser General Public License (LGPL) version 3

This is the latest version of the LGPL: a free software license, but not a strong copyleft license, because it permits linking with non-free modules. It is compatible with GPLv3. We recommend it for special circumstances only.

Please note that LGPLv3 is not compatible with GPLv2 by itself. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well. When this is the case, you can use the code under GPLv3 to make the desired combination. To learn more about compatibility between GNU licenses, please see our FAQ.

http://www.gnu.org/licenses/license-list.html

[EDIT] According to the FAQ mentioned above you can convert versions of LGPL to GPL but not the other way around. (see http://www.gnu.org/licenses/gpl-faq.html)

IANAL aside, I think it may work...

Sohodojo Jim's picture

Aveu,

The permutations of all this 'license soup' is what drove my to post this request for clarification in the first place... As I read the License Compatibility Matrix (link in OP), the relevant combination appears to be (and as noted in your subsequent edit):

'I want to release a project under' Column: GPLv2 or later

'I want to copy code under' Row: LGPLv3

Intersecting Cell: OK: Convey project and code under GPLv3 [8][3]

Where footnote [3] states: "If you have the ability to release the project under GPLv2 or any later version, you can choose to release it under GPLv3 or any later version—and once you do that, you'll be able to incorporate the code released under GPLv3."

And footnote [8] states: "LGPLv3 gives you permission to relicense the code under GPLv3. In these cases, you can combine the code if you convert the LGPLed code to GPLv3."

The 'loose bit' that I am wondering about is the interpretation of what the 'project' is in this case. My assumption is that contributed modules are each their own 'project' living (for 'conveyance access', as it were, under the overall umbrella of the Drupal contributed module repository. Since the Drupal codebase is GPL V2-plus, then my reading is that its various contributed modules may, depending on their individual heritage/components, be 'conveyed' as GLP V2-plus or higher. In this case, my proposed module would be conveyed as GPL V3 having applied the "LGPL V3 conversion to GPL V3" rule to allow incorporation of the LGPL V3 derived part.

If, however, by 'the project' this means the entire overarching Drupal code base would need to be conveyed/converted to GPLv3, then that is a BFD problem. If so, it would appear that there would at least be two options; 1) forget it and just not make my module available to others, or 2) simply 'self-publish' a stand-alone module -- such as on GitHub -- noting that this module is GPLv3 and can be used in an end-user's Drupal instance but that this module cannot be bundled with and distributed with Drupal proper, etc., etc.

Honestly, I am hoping that the correct interpretation is that Drupal contributed modules can simply be conveyed individually as GPLv3 while being released/maintained within the Drupal contributed module repository without impinging on the GPLv2-plus status of the overall project.

Thanks for your insights,
--Sohodojo Jim--

--Sohodojo Jim--
http://sohodojo.com

Anyone know what kind of

threading_signals's picture

Anyone know what kind of license terms the services module offer? +1 for that module if it provides more options.

Legal

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: