Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the licensing policy #1206

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

ForNeVeR
Copy link

@ForNeVeR ForNeVeR commented Aug 12, 2024

Today I've been asked by an acquaintance of mine to help with figuring out the licensing policy for OpenPDF. Their words were exact "hey, please help me to figure out what to do with a library that uses two contradictory licenses at once" — which is, of course, not correct w.r.t. OpenPDF, but this was the user's impression. I made sure to let them know of the real situation, after reading the license headers in the files, but for now I propose to state the requirements more clearly in the documentation, so nobody else is forced to deduce this from the sources again.

So, this PR clarifies the licensing. The fact that OpenPDF uses dual licensing, in particular OR in terms of SPDX, isn't well and formally documented by either the README file or the LICENSE files (or at least I was unable to find, if it is documented somewhere then please let me know), so I propose to update the wording in the documentation to include this information.

The particular wording I used in this PR I deduced from the license headers in the library source files.

Also, for now I decided that better (legally) safe that sorry, so I copy-pasted the same statement in every README or LICENSE file I was able to find; in my opinion, it makes sense.

Please note that, while I have some experience in open-source licensing, I am not a lawyer, and this PR is just a friendly suggestion/proposal, hopefully helping people to figure out the licensing policy better, and not is a legal requirement or something.

Your real name

Please specify your full name here, so that we can verify your identity.
If you have a conflict of interest describe this here also.

Friedrich von Never

Testing details

Hopefully no :)

Copy link

sonarcloud bot commented Aug 12, 2024

@Lonzak
Copy link
Contributor

Lonzak commented Aug 13, 2024

You have a valid point. The current license files do not mention "dual licensing" or the word "or" (even though the linked article explains this in detail) so your change makes it more clear to the ignorant user...

OpenPDF uses dual licensing: when using the library, you may choose either Mozilla Public License Version 2.0 or GNU Lesser General Public License 2.1.

So I would say that this is helpful. Thank you for not only complaining but helping out by adding a PR as well!

@ForNeVeR
Copy link
Author

ForNeVeR commented Aug 13, 2024

Oh, I never noticed that wiki link anywhere.

After reading the article at https://github.com/LibrePDF/OpenPDF/wiki/OpenPDF---License-MPL---LGPL-background-info, I have to be honest, to me it is still not 100% clear what exact licensing model the library uses (it is, like, 75% clear, though: the mention of "dual licensing" clarifies things quite a lot).

It is 100% clear after I read the license headers, but the article seems to address a different concern (and I totally understand what it is trying to tell).

Especially the latest statement from the article:

OpenPDF is open source software, relased under the Mozilla Public License Version 2.0 and GNU LIBRARY GENERAL PUBLIC LICENSE.

(Emphasis mine; also there's a typo in word relased I see now; sorry, I'm not nitpicking here so let's move ahead :)

In the modern OSS licensing where the most prominent way of formalizing the common licenses is SPDX, the word "and" has a very different meaning: it means that terms of both licenses would apply, the user is not allowed to choose.

The license header and the very concept of dual licensing make it clear that this is not what we have in OpenPDF, in SPDX terms: it is clearly MPL-2.0 OR LGPL-2.1+ (and I believe this is what the most of the library users are ok with).

So, my points would be:

  1. The current project licensing history is quite clear if you dig into it. It is clearly MPL-2.0 OR LGPL-2.1+ in SPDX terms.
  2. To figure that out, you need to read the license headers, and you cannot readily extract this information from README or LICENSE file, or even from the aforementioned wiki article.
  3. It is very common to mention complex licenses in SPDX terms in modern OSS projects; for particular examples let's see how Qt does that (they use dual license as well — note the use of the OR word as well).

So, I believe that it would make the project's licensing system clearer if we mention the SPDX identifier and human-readable description somewhere. Not necessarily in the README file (or in the source files' headers: this is a separate topic that I'd not touch here), but at least the LICENSE.md files look to me like an appropriate place to give such information.

@ForNeVeR
Copy link
Author

ForNeVeR commented Aug 13, 2024

Just to clarify, folks: I am not complaining that there's anything wrong with OpenPDF's licensing or its use of iText source code. From what I see, everything is perfectly alright. I genuinely sincerely sorry if my PR caused such an impression. I understand that the licensing matters might cause some bit of pressure; I mean no such thing.

I just want to make the licensing more clear and transparent for the users who read the project documentation.

@Lonzak
Copy link
Contributor

Lonzak commented Aug 14, 2024

Just to clarify, folks: I am not complaining that there's anything wrong with OpenPDF's licensing or its use of iText source code. From what I see, everything is perfectly alright. I genuinely sincerely sorry if my PR caused such an impression. I understand that the licensing matters might cause some bit of pressure; I mean no such thing.

I just want to make the licensing more clear and transparent for the users who read the project documentation.

Not at all - no need to apologize. You saw some room for improvement and got involved. I see your points too and appreciate the PR. Thank you for your contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants