License issue: GPL v2 vs. ASL 2.0 about mpdf

[danielhjames]

Hi Jan, having reviewed the licenses I think this is a genuine issue. Only Ian, the copyright holder of mPDF, could make that license change.

[JanSlabon]

Hi Daniel,
Ok, I just saw that you're active on the mPDF forum, too. Could you open a thread there which points to this issue? Time ago I tried to contact Ian by email without success...
Thanks!
Jan

[danielhjames]

Hi Jan, if I get to speak to Ian I will mention licensing, as in my opinion the GPL v2/Apache mix makes the code difficult to redistribute, and I doubt that was the intention.

[jakejackson1]

I put a post over in the mPDF forums asking Ian to chime in about the licensing issue (http://www.mpdf1.com/forum/discussion/2451/gpl-licensing-clarification). I also asked about open sourcing the documentation.

[skreutzer]

There's yet another problem, the “SaaS loophole”: the GNU GPL licenses are insufficient for code which runs on servers (see http://radar.oreilly.com/2007/07/the-gpl-and-software-as-a-serv.html), therefore the GNU AGPL 3 (+ or, at your option, any later version) would be much better. It might be that the ASL2 is incompatible with AGPL3 or later, but if existing mpdf code would be licensed under GPL3, new code modules could be incorporated under the AGPL3 (https://en.wikipedia.org/wiki/Affero_General_Public_License#Compatibility_with_the_GPL. Would an “or later” clause be possible, too?), effectively making a combined package seem to be AGPLed, as the GPL3 conditions would be fulfilled automatically where the AGPL3 gets fulfilled with its additional conditions.

However, the best way to solve this mess would be to convince the FPDI authors to license their classes under GNU AGPLv3 or any later version.

[jakejackson1]

I don't think the "SaaS loophole" is an issue at all in this case (and I personally don't have a problem with this either). Nor do I think it's appropriate to convince the FPDI authors to change their license because their code was integrated into a package that is incompatible with said license - whether done unknowingly or not.

There's two courses of action I see:

1. Ian Black to address these licensing issues and change mPDF to be "GPL2 or later" or "GPL3 or later"
2. Remove the FPDI package from mPDF.

I've made multiple attempts to contact Ian regarding this issue to no avail. Unless he comes to the table and makes a decision that option is out.

We really are getting to the stage where option 2 is our only way forward. To continue distributing mPDF and FPDI together when we know they have incompatible licenses is unethical.

[danielhjames]

Hi Stephan, the SaaS loophole only applies in the case where a SaaS provider is improving mPDF but not making the source code for those improvements available to its users. I'm not aware that this is actually happening. Since it is impossible to retroactively change mPDF to AGPL v3, there's nothing that can be done about that (theoretical) issue now. Even if the licence was changed, there is no obligation under AGPL to release mPDF improvements to the public in a place such as GitHub, since only direct users of that web service are entitled to request source.

Jake, I understand that FPDI is used in mPDF for reading PDFs, and making templates from them, as in http://mpdf1.com/manual/index.php?tid=349
Supposing all FPDI code was removed from mPDF, would it actually be more maintainable to have fewer features, and focus on best quality PDF output from pure HTML?

[JanSlabon]

I just did some further research and checked some projects Ian took code from: http://mpdf1.com/manual/index.php?page=credits ...Steven Wittens e.g. definitively released his code under the GPL (this was several years ago! -> https://web.archive.org/web/20060420115737/http://www.acko.net/node/56), so I don't think that it will be possible to get Ian to update the license at all... A change at our side to AGPL will also make not any difference. That way we would end in AGPL 3.0 vs. GPL 2.0.
Actually mPDF is the only project that collide with "our" license and we're simply not in the possition to use GPLed code at any time, so it will not make sense for us to change its license atm, sorry. Personally I'm not aware of any business case where we were able to use GPLed code at all...
Additionally we offer a commercial addon under a proprietary license for FPDI which would looks somewhat strange if it would be available in combination with GPLed code.

[danielhjames]

Hi Jan, thanks for your patience :-) I can see that re-licensing FPDI is not going to be practical for your company.

[skreutzer]

@danielhjames:
And who's a SaaS provider actually? Everyone who runs the code on a server which is accessible over the Internet. If the unmodified code gets run, the AGPL would require the service provider to point out that such code is involved, and to link to the source repository or provide a copy of it in order to enable users of the service to obtain the code if they want to. At the moment, no such notice nor providing the source online or on request is required. If a service provider makes changes to it, there's absolutely no way for you or me or any other user to obtain the extensions and bug fixes which were made, because the GPL doesn't require it. mpdf improvements don't need to be released into the official mpdf repository on GitHub, but you guys would at least be able to find out about them, to inspect, obtain and incorporate them as you see fit. Of course, this doesn't mean that there's the need to be aware of all mpdf installations and their potential improvements, especially considering the chaotic nature of the net, but if such improvements ever gain traction and are of general usefulness, you guys would at least have the chance to use it yourself and to include it into the official package to make the latter more valuable to the community. Otherwise, mpdf users who improve the code on their own would benefit from the community, but wouldn't contribute back to the community and deny their users some of the four essential freedoms which every user of digital technology deserves.

Why is it impossible to change the license to AGPL3? It might be impractical, if it got impossible to contact contributors or if they're against the AGPL, or if there's no time to organize such a license change, or a number of other reasons. On the other hand, having a project for online software being stuck with the GPL is quite an issue for future development in my opinion. It's not that I'm going to demand the AGPLization of mpdf, it's a suggestion in order to improve the current situation and avoid potential harm.

@JanSlabon:
If Steven Wittens code isn't licensed with the "or any later version" clause, there's basically no path to migrate to a better GNU license when it comes to changes to the GPL2ed code, therefore such new code would be vulnerable to the loopholes and problems the GPL3 fixes. Regarding your business models, it seems you're mixing your code together with restrictively licensed third party software, where the latter denies the freedoms the GPL would provide. Or you're bound by some special agreement outside of copyright law to not to dual-license your components. Could you describe one business case as example where the usage of GPLed code would be impossible, especially as free licensing doesn't prevent commercial use, but instead indeed change business models? You don't have to, I'm just curious and don't know much about your products (yet?).

[jakejackson1]

@danielhjames It's a given that the less features to maintain the easier it will be to clean up, but the existing PDF reader is such a great feature. Not only will it be a shame to remove, it will also mean an alternative solution will need to be created for those users who rely on that particular feature. I'll likely have to create a GPLv3-compatible-license add on / plugin that incorporates the FPDI features so they still work with mPDF - although even then the GPL distinction of what is classed as a derivative work would mean the legalities of that ere on the grey side.

Since @JanSlabon and his company is the copyright holder of FPDI I'd like to hear what he would like to happen.

[danielhjames]

Hi Stephan, I'm aware of the benefits of AGPLv3, we use it for our own products. mPDF is licensed GPLv2 only, and that is not likely to change.

Jake, given that the PDF import features only work when explicitly activated with SetImportUse(), would it make sense to have something like this in mPDF's config.php by default:

// PDF import
$this->UseFPDI = false;

// Path to FPDI classes
$this->pathtoFPDI = /var/www/fpdi/;

and update lines 32314 onwards of mpdf.php:

function SetImportUse() {
$this->enableImports = true;
ini_set('auto_detect_line_endings',1);
require_once(_MPDF_PATH."mpdfi/pdf_context.php");
require_once(_MPDF_PATH."mpdfi/pdf_parser.php");
require_once(_MPDF_PATH."mpdfi/fpdi_pdf_parser.php");

so that the user can obtain FPDI separately and install it on their server only if necessary? As long as the user does not distribute the combination, that may satisfy both licenses.

[jakejackson1]

@danielhjames I'm not sure it would satisfy both licenses. Along with distribution, the GPL explicitly discusses linking static or dynamic libraries with GPL software and I believe would class this behavior as a larger combined work.

@JanSlabon In reading up on the GPL it's become plainly obvious that as the copyright holder of FDPI you have absolute say in the usage of FDPI and how we should proceed to prevent a violation of your license. I would love to see FPDI stay integrated with mPDF and you seem open to finding a solution that doesn't involve ripping it out. With that in mind, there are some alternatives:

1. Release FPDI under the Modified BSD license instead of the Apache 2.0 license. This would be compatible with GPLv2 but still retain the lax permissive non-copyleft free software of the Apache 2.0 license.
2. Leave your current public-distribution of FPDI under Apache 2.0 but grant the mPDF package usage of the software under the Modified BSD license (or similar). As the copyright holder you can release FPDI under various licenses to various parties.

Note: None of what I've said is legal advise. I've just passed on the details written on the GPL FAQ page: http://www.gnu.org/licenses/gpl-faq.en.html

To reiterate, as we aren't the copyright owners of mPDF there's very little we can do on our end but remove the software causing the license conflict. Ian Black, the author of mPDF, could potentially modify the GPLv2 license to GPLv3 however he has yet to comment about the licensing problem. There's also the issue that Ian borrowed heavily from multiple projects that may not be GPLv3 compatible. As @JanSlabon is the license holder of FPDI he could give us permission to use FPDI in mPDF under a different license that is compatible with GPLv2, however he is under no obligation to do so.

The ball is in your court @JanSlabon. Please let us know your thoughts.

[JanSlabon]

@skreutzer I'm unable to use GPLed code in every contract written code. That's why I'd choosen ASL 2.0 for FPDI, too.

JM2C: I understand your thoughts in view to freedom and think that the GPL could be a great license if everybody would not only agree to it but also would live it.

But that's not the case. Because nearly everybody reaches the point were he/she needs/wants to make money from their (derivated) work. I mean how could it be possible that a module for a GPLed software which is definitely a GPL derivate is sold by limiting its usage on e.g. a single website or more features than the offically GPLed version? Also by speaking about a grey zone is somewhat strange, isn't it? There's no grey zone. For me the GPL is viral and if foreign code interacts with GPLed code it has to be licensed under the GPL or a compatible license. A limitation on the usage or features is simply impossible. And I'm wondering why this happens AND is tolerated at all?

The idea from @danielhjames or an external modul by @blueliquiddesigns will make all users validating the GPL.

The idea with another GPLv2 compatible license could be a solution. Actually I'm looking at the X11/MIT license. I have to sleep over this :-)

PS: I just noticed that there's a special cache path if mPDF is used in conjunction with JpGraph! JpGraph is released under the QPL (http://jpgraph.net/download/) or as a professional version. BOTH are incompatible to GPL. I'm wondering why there's a hint how to use both together? ;-) Should there be more issues like this?

[danielhjames]

Hi Jan, quite possibly there are other licensing issues in mPDF. You are right that it is difficult to limit the features of GPL software, which is part of its appeal to users, unless it is offered as part of a web service. I appreciate that you are considering a GPL compatible license for your software, thanks!

[jakejackson1]

@JanSlabon In reference to the "grey zone" I was talking about the option of an add on for mPDF that is licensed under GPLv3 and incorporates FPDI - GPLv3 and Apache 2.0 being perfectly valid licenses to use together. That would resolve the licensing problem with FPDI but potentially create one with the GPLv2 licensed mPDF and the GPLv3 licensed add on. The legitimacy of that type of licensing situation would need to be determined by experts in software licensing law, but since the conflict is GPLv2 over GPLv3 I doubt there would be serious concerns (again, no expert here).

However, if you are happy with the X11/MIT license it will be a win-win all around and FPDI can stay with the mPDF code. I look forward to hearing your decision.

[JanSlabon]

Just give me/us some days... :-) I'll get back as soon as I have any news.

[jakejackson1]

Hi @JanSlabon. I was wondering if you've had a chance to give this any further thought?

[JanSlabon]

I didn't forget you! :-) Next version will be dual licensed ASL 2.0/X11/MIT. We just hadn't the time for preparing this. I think this will get official in the next 2 weeks.

[jakejackson1]

Awesome! Any special conditions for using the MIT license?

[JanSlabon]

I'm not sure what you mean?

[jakejackson1]

I was just wondering if there was any restrictions for using the MIT licensed version - much like JPGraph does with its duel licensing.

[JanSlabon]

mmhh... I still don't understand. MIT/X11 -> https://en.wikipedia.org/wiki/MIT_License JPGraph is not released under such a license.

[jakejackson1]

No. But it is duel licensed and restricts commercial use - a special requirement. I was just checking if there were any special requirements placed on your duel licensing.

[ram4nd]

The project suffers more in the area of continuous development, rather than
licensing issue.

2015-10-05 9:42 GMT+03:00 Jake Jackson [email protected]:

No. But it is duel licensed and restricts commercial use - a special
requirement. I was just checking if there were any special requirements
placed on your duel licensing.

—
Reply to this email directly or view it on GitHub
#15 (comment).

Ra Mänd

[JanSlabon]

Wow! Such comments should let me re-think about solving this, or? Licenses? Who cares, it's "free"! :-/ Really annoying...

[ram4nd]

Easy, run it under GPL2.0. That means you can do it what ever you want with
it, but anybody who gets their hand on it can spread it for free.

2015-10-05 12:24 GMT+03:00 Jan Slabon [email protected]:

Wow! Such comments should let me re-think about solving this, or?
Licenses? Who cares, it's "free"! :-/ Really annoying...

—
Reply to this email directly or view it on GitHub
#15 (comment).

Ra Mänd

[jakejackson1]

@JanSlabon, how so? I was simply asking if, when you duel license, the MIT version would have any additional restrictions - which is doesn't sound like there will be. I'll be updating FDPI to the MIT licensed version on my personal distribution of mPDF ASAP.

[JanSlabon]

@blueliquiddesigns All well! We are not going to add any restrictions. I missed to comment your last post, sorry.
My last comment goes into the direction of @ram4nd. Such guys are the GPL users I'm afraid of...

[JanSlabon]

FPDI 1.6.0 is released under the MIT license now. So the license issue is solved :-) I already updated our fork appropriate in #47 by removing FPDI completely and adding a require entry to the composer.json.

[danielhjames]

Good work, thanks Jan!

[jakejackson1]

Great news, @JanSlabon. Thanks for coming to the table and helping us resolve this one – and nice work on the PR.

[JanSlabon]

Closing (solved with #63)