Hello Dominik, PoDoFo mantainers and contributors, it follows shortly my announce about pdfmm 0.9.20 (with the proposal of merging back to PoDoFo) another request regarding the current license of PoDoFo. Let me try to recap the current situation with PoDoFo licensing terms, using a Q/A approach. I am not a legal but I evaluated open source licensing terms quite a lot in the past 15 years, and I believe my considerations should be accurate enough.
Short version: Mozilla Public License 2.0[1] is more business friendly than LGPL[2]. Long version: PoDoFo is currently licensed under the terms of LGPL 2.0 license (or later version) terms. Very roughly summarizing LGPL 2.0[3] allows to use, redistribute and modify the Library (see LGPL definition of "Library") code in both source and binary form, providing modifications to the library code are redistributed along the way, making it a "copyleft" license. The Library (either modified or unmodified) can be "linked" in closed source programs (or any "work that uses the Library", as in LGPL terms) making it a derivative work of the Library providing such "work" is redistributed together "**object** code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library". * What does this mean with regard to "linking" the Library, as per using it in a C++ project with a linker? This means that this "work" (programs/libraries) using PoDoFo Library should be redistributed together either source code or the ".o", ".a" or ".lib" binary code that were generated for the whole programs/libraries (closed source software components as well), or such files shall be provided "for a charge no more than the cost of performing this distribution". LGPL2.0 makes no distinction between "static" or shared/dynamic linking, possibly being more restrictive, nor it better specifies anything if the "work" using the Library is another shared library and not a "program", intended as an entry point executable, putting this situation in a limbo/gray area * Does this really mean I can use/link PoDoFo code in my closed source program without having to release the source code? Yes, and FSF confirm it as well for any LGPL version (v2, v2.1, v3) in its FAQ[4], proving the above mentioned clauses are met. Any other source in the internet that it says that the the closed source code should be always released with LGPL as well is not correct. * What's the difference between LGPL 2.0 and 2.1? LGPL 2.1 introduces these main changes: - It renames the "L" in LGPL from "Library" to "Lesser"; - It introduces a distinction between "static" and "shared" linking (aka "dynamic"), basically allowing the "work that uses the Library" to not being considered a derivative work if it just uses "a run time a copy of the library already present on the user's computer system" using a "shared" linking mechanism; - It makes more clear that anything that gets "linked" to the Library is a derivative, non only "programs" but (presumably) other libraries as well. * So, what's the problem with LGPL (any version)? In my opinion the LGPL is overall fair, but it introduces a coercitive clause (the requirement to release the "work" under source or relinkable object form) that is not business friendly. It's no mistery that many companies avoid using/depending on LGPL libraries: for this exact reason. I think we can agree that most of the times this coercitive clause, differently than GPL (no "L), has very little use in practice since the freedom to modify the Library and use this modified version in the original programs/libraries looks very hacky/amateurish. I make one example: let's suppose a Fortune 500 company is now using and redistributing PoDoFo in a program of theirs, or a shared library: we all have now the right to ask this company to release the object code that was generated and linked in the final executables or libraries. What is the value of having this right in the "real" world? I answer for my self only: for me the value is less than zero in the case of a Library such PoDoFo, and exercise this right would sounds more like a coercitive move attempting to damage/jeopardize the company business. * What do you suggest? I think LGPL had and still has a place in this world, but I also believe PoDoFo should be as much as possible business friendly. My proposal is to relicense PoDoFo to Mozilla Public License 2.0. * Why Mozilla Public License 2.0? MPL 2.0 is a copy left license, similar in intents to LGPL but with much more easier terms and no "source disclosure" clause for just using/linking the library. It's also LGPL/GPL compatible. * Why not MIT/BSD/Apache 2.0/? I think Dominik had in in mind copyleft when he chose LGPL 2.0 and I agree with this principle. MIT/BSD/Apache2.0 are not copy left so are not viable choices. MPL2.0 instead is a copy-left license. * What plan do you suggest? If Dominik overall agrees with the arguments in support of relicensing, I suggest he should name the people that contributed most to PoDoFo and that should take part in this decision. These people are contacted, and if they overall agree we could make a signed statement that they accept the re-license. We should think about what to do about people that contributed with small patches, that may not respond to requests about licensing changes. For what I know, PoDoFo never had copyright re-assignment policy, which it would make relicensing much easier now. I think in many of these cases we can take for granted that posting of small "trivial" patches into PoDoFo mailing list automatically makes these patches "public domain". I think this approach was used in some circumstances in several open source projects that later decided to change license. Also we should think what do if some people, but not the majority, disagree with the re-licensing, especially in case of non-trivial contributors. * What's the bargain with pdfmm? If the license change is accepted and pdfmm gets merged into PoDoFo, then all the pdfmm code will use the new licesing terms of PoDoFo. Currently the license of pdfmm is LGPL 2.1 fixed[5], which it would make it incompatible to merge new files from pdfmm into PoDoFo * What about the dependencies of PoDoFo/pdfmm? With one exception (libidn), all the dependencies have permissive (non coercitive) licenses: - zlib: custom permissive -> OK - libxml2: MIT -> OK - openssl:pre 3.0 custom permissive, apache2 in openssl 3.0 -> OK - fontconfig: MIT -> OK - freetype2: BSD like -> OK - libjpej: BSD like -> OK - libtiff: BSD like -> OK - libpng: custom permissive -> OK - libidn: LGPL -> FAIL I believe at some point we can just take a more permissive stringprep implementation written in another language/framework and port it to C++. I hope this request is clear and well argued. I welcome everybody to comment, especially in case your employer is using PoDoFo in its products. Cheers, Francesco [1] https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2) [2] https://tldrlegal.com/license/gnu-lesser-general-public-license-v2.1-(lgpl-2.1) [3] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html [4] https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic [5] https://github.com/pdfmm/pdfmm/blob/master/COPYING _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
