Hello:
We've developed a drupal module that uses 3rd party php libraries and a jQuery plugin. The module serves the purpose of stamping an uploaded
PDF documented for a drupal user.
The php libraries and iQuery plugin used are
FPDF 1.53 (http://www.fpdf.org) - This is a freeware license
FPDI 1.2 (http://www.setasign.de/products/pdf-php-solutions/fpdi) - Licensed under Apache License, Version 2.0
FPDF_TPL 1.1.1 (http://www.setasign.de/support/manuals/fpdf-tpl/introduction) - Licensed under Apache License, Version 2.0
imgAreaSelect 0.4.2 (http://odyniec.net/projects/imgareaselect) - Dual licensed under the MIT (MIT-LICENSE.txt) and GPL (GPL-LICENSE.txt) licenses.
(i've attached the README.txt file which contains details of the licenses of all the 4 external pieces of code).
I also checked the http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licenses for GPL compatibility of the other licenses and
it looks ok to me.
My question for help is
1 - Is my understanding correct that i can legally bundle the above 4 pieces of external code with my contributed module
2 - How does one specifiy in the README.txt file and in the pieces of code that parts of contributed module code makes function calls
to the classes and functions from the external libraries/plugin.
This has stemmed since my request for cvs-account was rejected and it needed more information on the licensing
'Message from the CVS maintainer:
The licenses of bundled libraries appear to be incompatible with GPL. You'll need to confirm in more detail in the motivation message and the code + README.txt'
I'd appreciate any help from this group cause i'm keen to push this module out.
Thanks.
Yashesh Bhatia.
p.s. if anyone's interested in getting the actual module please contact me and i'll email it (not sure if i can post the tarball of the module here).
Comments
"freeware" license
I've looked at FPDF before and was amazed
From the FAQ:
It's kind of a legal "no-mans-land." I think more appropriate would be for the author to say that the code is "public domain" since that sounds like what he means.
Without a more specific license that is likely a sticking point for this module.
If your module just says "download these other things to make it work" then I think you should be fine, though I'm not entirely sure about that. Definitely it would be inappropriate to commit the code from these 4 other projects to cvs.drupal.org
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation
Not public domain
Actually it is not more appropriate for the author to use public domain unless that's what he actually intends. Hyper-permissive licenses still retain and assert a copyright. That's distinct from the public domain, which is the absence of any copyright claim. Think of it as an empty string vs. NULL. :-)
ok
The intent of his license statement seems similar to me to Public Domain. Maybe in fact it is more similar to something else, but I think there's value to moving it from a no-mans-land into a known quantity.
The benefit in my mind for this to be relicensed as "public domain" or some other known license is that we have legal opinions which allow us to say "yeah, this is GPLv2+ compatible." What he has, which has no general definition, we can't say one way or another if it is GPLv2+ compatible or not.
I'd say it's more like "null" vs. "unknown to be null nor not null, requires lawyer/judge investigation to find out."
knaddison blog | Morris Animal Foundation
Not in CVS
The term "Freeware" is also misleading here. "Freeware" colloquially means "free as in beer". There are thousands of freeware closed source programs out there. In the mid to late 90s that sort of freeware, along with "shareware" (in its various forms) was extremely popular on Windows platforms. Just because something is "freeware" in that sense, however, does not make it GPL compatible.
From the description, it sounds like FPDF is GPL compatible, however. imgAreaSelect is under GPL2 if desired, which makes it GPL compatible kinda by definition. :-)
The two Apache 2 licensed components are a sticky point, however. Apache 2 is NOT compatible with GPLv2, but IS compatible with GPLv3. Drupal is also compatible with GPLv3. Thus, if you wanted to mix them all together and distribute them you could do so only using GPLv3.
While permissible to do, we do not allow GPLv3-only code in CVS. That's not because GPLv3 is bad, but because we do not want to put people in the situation of having some modules that are GPLv2-only (or bridge to GPLv2-only code) and others that are GPLv3-only (or bridge to GPLv3-only code), as then those could not be combined. Instead we require that everything in Drupal's CVS repository is under the exact same license: GPLv2-and-later.
It also creates a maintenance hassle to have 3rd party code in our repository as keeping in sync with the 3rd party becomes much more difficult. If the 3rd party code is not GPLv2+, like Drupal, then it also becomes impossible to send bug fixes "upstream", resulting in a fork.
Depending on your specific case, you could either host the module elsewhere than Drupal.org and distribute it along with the bundled 3rd party libraries under GPLv3 (with appropriate credits in the README file, to be polite), or strip it down to just your custom Drupal module code and commit that to Drupal CVS under GPLv2+ along with instructions on how to download and install the 3rd party libraries. Which makes more sense varies case by case.
skip the bundling..
crell- - thanks for the information. i'll skip the bundling of the 3 libraries and 1 jquery plugin (didn't realize there were many legal fine points i'd have to work on).
One question. when you say - 'or strip it down to just your custom Drupal module code and commit that to Drupal CVS under GPLv2+ along with instructions on how to download and install the 3rd party libraries'
can i add function calls to the 3rd party libraries with appropriate comments ? here's a sample of the module code which does it..
// in pdfstamper.module
/*
* The code below uses classes from the library FPDI 1.2 (http://www.setasign.de/products/pdf-php-solutions/fpdi) - Licensed under Apache License, Version 2.0
*/
_pdfstamper_change_include_path();
require_once('fpdi.php');
$pdf = new FPDI();
$pgcount = $pdf->setSourceFile($file['filepath']);
$tpl_idx = $pdf->importPage(1);
$size = $pdf->getTemplateSize($tpl_idx);
if ($node->type == 'pdfstamper_pdf_file') {
essentially the lines require_once('fpdi.php'); $pdf = new FPDI();
are making calls to the FPDI library
and the javascript file
// in pdfstamper.js//The below code uses imgAreaSelect 0.4.2 (http://odyniec.net/projects/imgareaselect) - Dual licensed under the MIT (MIT-LICENSE.txt)
//and GPL (GPL-LICENSE.txt) licenses.
$(window).load(function () {
$('.image_container #preview-image').imgAreaSelect({ selectionColor: 'blue', onSelectChange: selectChange });
});
can the above code (module and js files) be committed to Drupal CVS under GPLv2+ ?
thx.
yashesh
p.s. i've attached both the js and module file
Yep
Yes, that's exactly what I mean. Lots of bridge modules work that way. You'll probably want to include an installation check to confirm that the user has downloaded the 3rd party library to /yourmodule/fpdi (or whatever) before installation, and/or an admin screen to let the user configure where the library can be found. You should also include appropriate checks throughout the code so that if the library is not found your code fails gracefully rather than simply throwing a fatal error. Much nicer for the user. :-)
The README file should document in detail how to download the 3rd party library and any legal implications there are of using it (eg, everything must be distributed GPLv3 if distributed).
I should note that this holds true for 3rd party code that is under a GPL-compatible only. If the 3rd party code is not GPL-compatible (commercial license, PHP license, etc.) then such bridge modules are not permissible, period.
MIT
Having a look at the GPL Compatible Licenses, I see Expat License, which says "This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. It is sometimes ambiguously referred to as the MIT License." The actual MIT License details are available here. They say that MIT is compatible with the GPL. The license is very unrestrictive and encourages the code's use anywhere...
So, can we commit MIT licensed code to the Drupal contrib CVS? If not, can we re-license it under a dual licensed GPL/MIT and then commit it with the author's permission?
"Permissive licenses"
Looking at the license in question, it looks like a standard "permissive license". There are many many variants that all say essentially the same thing. They're also sometimes referred to as BSD-like, MIT-inspired, or various other terms.
Mixing code under such a license is fine from a legal perspective, as is relicensing it under the GPL. However, there is still the issue of 3rd party code in CVS, which is discouraged for technical reasons as much as legal ones. If you think your case is worth an exception, please open an issue in the Infrastructure queue to discuss it before committing the 3rd party code.
I'm working on a module using
I'm working on a module using https://github.com/zurb/joyride, a nifty little jquery library for creating site tours. It's under MIT Open Source License. I want to know a few legal-ly things: