Hello Mattia, thank you for your very informative reply. I add my comments below.
On Thu, 17 Feb 2022 at 12:57, Mattia Rizzolo <mat...@mapreri.org> wrote: > Just as a data point, there is currently a lawsuit running in California > against Vizio, Inc. that includes their refusal (by staying silent) to > provide said object code linked against LGPL-2.1 libraries. > This basically confirms my concerns over use of LGPL licensed code in commercial software. Even corporate users that actually contribute back to the project may prefer to not advertise it too much openly that they use LGPL software because of fear of being coerced to release object code, which basically means having to pay more cloud storage and DevOps for maintaining such distribution. > > I suggest he should name the people that contributed most to PoDoFo > > and that should take part in this decision. > > I'll defer to who better knows Copyright laws and stuff, but from what I > concerned, the people that needs contacted are those who actually wrote > copyright claims, that for the LGPL parts of PoDoFo (src/* and some > tests/*, the rest is GPL-2+) it means: > > 2000-2016 Dominik Seichter > 2008 Craig Ringer > Sure. Also AUTHORS mentions about Leonard Rosenthol. My point is: we have to first ask the people that contributed something around 90% of the code. If they agree on a relicensing of sort, then we can look for the remaining 10% of the code. > > Well... since you seems to be taking some care on the licensing and > copyright matters, I hope that going forward some more care is put in > keeping those headers relevant. You mean better tracking the contributors? If so, yes, that was my intention as well. I asked for it in the pdfmm announcement (unfortunately no reply, so far). I think it should not be that hard to identify all contributors, PoDoFo is not that big project. > > > 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". > > Depending how small, such patches may very well not even be > copyrightable, so you can easily get away from those. Yes, I agree. Of course a review has to be done for all external patches commits. > > > 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. > > There is not much to think about. If somebody doesn't agree, that part > they own copyright own can't be relicensed, that simple. Yes, you're right. > [...] reimplement whatever was in it (paying attention to not > copy too much from the previous implementation otherwise it becomes a > derivative work). You're right. > > 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 > > I don't think it would. PoDoFo is LGPL-2.0+, if you merge LGPL-2.1 > stuff into it, the whole final work becomes LGPL-2.1 What I meant is that it's not possible to merge LGPL2.1 code into PoDoFo without introducing inconsistent/self contradicting license terms of PoDoFo. > > With one exception (libidn), all the dependencies have permissive (non > > coercitive) licenses > > Why is this not a blocker for going forward? > Wouldn't linking against libidn make the resulting library effectively > be under LGPL too? > You're right that the resulting library should comply with LGPL requirements (source and/or object code disclosed, and by definition PoDoFo source code is disclosed). By no way this means PoDoFo itself would be implicitly LGPL licensed. Until a replacement for libidn is found, we could workaround temporarily this issue by having libidn enabled only by voluntarily action, and not automatically enabled when found on the search paths, so the matter gets transferred to the PoDoFo end-users that can choose or not to enable libidn, being required to comply with LGPL requirements if they do. In my opinion it would not be a blocker for the overall relicensing of PoDoFo to another license. [1] https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/AUTHORS _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
