Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.

CTS 35 - LGPL version

  • 6 Replies
  • 184 Views
*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
CTS 35 - LGPL version
« November 03, 2020, 06:47:10 PM »
ppisar opened on 02 November 2020:

lib/PDF/Builder.pm reads:
Quote
    This is free software, licensed under:

    The GNU Lesser General Public License (LGPL) Version 2.1, February 1999

      (The master copy of this license lives on the GNU website.)

    Copyright (C) 1991, 1999 Free Software Foundation, Inc. 59 51 Franklin
    Street, Fifth Floor, Boston, MA 02110-1301 USA

    *Please see the* INFO/LICENSE *file in the distribution root for full
    details.*

    This program is free software; you can redistribute it and/or modify it
    under the terms of the GNU Lesser General Public License, as published
    by the Free Software Foundation, either version 2.1 of the License, or
    (at your option) any later version.

The second paragraph picks LGPL version 2.1. But the last paragraph allows version 2.1 or any later.

Which one of the two statements are correct?

If I look at INFO/LICENSE, there is stated 2.1 only. Thus I believe that the "or any later version" statements was left unintentionally. Could you please clarify this situation?

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
Re: CTS 35 - LGPL version
« Reply #1: November 03, 2020, 06:49:46 PM »
PhilterPaper replied:

This is the original license, as inherited from PDF::API2. I Am Not A Lawyer, but my reading has always been that this work is licensed under LGPL 2.1, and you are free to redistribute it (modified or not) under 2.1 or any later version. Whether this would hold up in a court of law depends on local (country) laws and legal precedent (earlier rulings), but that's the logical perspective on the matter.

I can see that the slightly different wording between INFO/LICENSE and PDF/Builder.pm could be confusing. INFO/LICENSE does say that later versions of the LGPL may be applied. Probably the best course of action would be to bring the brief statement in Builder.pm in line with the full statement in INFO/LICENSE, by stating that INFO/LICENSE would be the "controlling" document and Builder.pm is only a brief summary. Other than that, I really don't want to go changing the legal boilerplate. Legal documents (which the LICENSE is) written or modified by non-lawyers tend to be trouble.

Keep in mind that the whole point of GPL/LGPL is to be as unrestrictive as possible with regards to your choice of action in using this software. Thus, it allows one to redistribute under a later version of GPL/LGPL if desired.

Would this clear up the conflict for you?

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
Re: CTS 35 - LGPL version
« Reply #2: November 03, 2020, 06:51:58 PM »
ppisar replied:

Thanks for the details. If you inherited the files from PDF-API2, it would be best to ask the author of PDF-API2 what were his intentions. (Frankly PDF-API2-2.038 does not contain such a mess as lib/PDF/Builder.pm; My understanding of PDF-API2 is that lib/PDF/API2.pm is "2.1 or later" while all the other files are "2.1".)

If your intention is the "2.1 or later" path, I recommend you to follow advise appended to the original text of the license https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt. That is use the following wording in lib/PDF/Builder.pm (or anywhere where you find the best place):
Quote
    PDF::Builder is a Perl library which facilitates the creation and modification of PDF files.
    Copyright (C) 2017-2020 by Phil M. Perry.

    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 2.1 of the License, or (at your option) any later version.

    This library is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Lesser General Public License for more details.

    You should have received a copy of the GNU Lesser General Public
    License along with this library; if not, write to the Free Software
    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
Re: CTS 35 - LGPL version
« Reply #3: November 03, 2020, 06:53:02 PM »
PhilterPaper replied:

It appears that the LICENSE file and related material in API2.pm/Builder.pm goes back 15 years or more, through at least 2 or 3 layers of authors in other countries. I'm not sure I'll get satisfaction on that path!

The two products' LICENSE files have not changed, except for the copyright line. (I see I need to add "-2020" to the copyright year range!) It appears that a recent release of API2.pm cut out most of the stuff originally there (and still there in Builder.pm) under the "LICENSE" section (the "mess" you are referring to?). I will need to be careful that such editing doesn't alter the legal meaning!

Anyway, before the next release, I'll have to review the license-related text in PDF::Builder (especially in Builder.pm), compare it to PDF::API2's current text (especially API2.pm), mix in your suggestions, and see what changes I need to make. I want to be very careful that any edits don't break what the meaning is supposed to be (and if in doubt, leave well-enough alone).

Files mentioning license and version: lib/PDF/Builder.pm, README, INFO/LICENSE

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
Re: CTS 35 - LGPL version
« Reply #4: November 06, 2020, 10:52:14 AM »
PhilterPaper replied:

See also RT 133691. Matrix.pm has its own statement (Perl's license), and all of the Basic/PDF/ files (except Literal.pm and Filter/*) are Perl Artistic License. There might be still more cases lurking in PDF::Builder (and PDF::API2) under odd phrasings.

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
Re: CTS 35 - LGPL version
« Reply #5: December 05, 2020, 11:13:13 AM »
PhilterPaper replied:

I just pushed revised text in README, INFO/LICENSE, and PDF/Builder.pm to try to harmonize the various statements about the licenses in use, and address your concerns. Please let me know if you still have issues with it.
  • LGPL 2.1 is the master license
  • some files are under different licenses, and must be treated in accordance with those licenses
  • for files covered by LGPL 2.1, you may (at your option) redistribute (modified or not) at a higher revision of the LGPL.

ppisar replied:

Thanks. Now it's better.

PhilterPaper replied:

Thanks for reviewing it. I'll close this now.

*

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 781
    • View Profile
Re: CTS 35 - LGPL version
« Reply #6: February 01, 2021, 12:21:30 PM »
PhilterPaper replied on 16 December 2020:

Petr, are the PDF::Builder 3.020 release licensing statement(s) now satisfactory to Red Hat? Anything else you think needs clarification? I see the email exchanges that were taking place have been dead for a while now. Steve Simms removed the licensing text from one of the files (Matrix.pm) in PDF::API2 (as he says he rewrote it), but didn't do anything about the Basic/PDF/ files.

ppisar replied on 17 December 2020:

I spent last weeks on vacation and have not yet read all my e-mails. So it's
possible I missed some message.

The LGPL version is now understandable. That's fine.

The lib/PDF/Builder/Basic/PDF files are still Artistic only. That's not sufficient.

Matrix.pm is fine.

PhilterPaper replied on 17 December 2020:

Hmm. in the last month we're not getting any email response that I know of from the original author of the Basic/PDF/ files using PAL (Martin Hosken). He seemed to be amenable to a license change, preferring MIT, but I've heard nothing since. As it is the holiday season, perhaps he's busy (and we should wait until mid-January to press him further).

Since this is being driven by your requirements at Red Hat, would you consider taking the lead in working with Martin? He might not require any arm-twisting, and is currently just busy. He doesn't seem to be active on GitHub. There is a @MartinHosken, but he has no repositories and no activity in 3 years. There's also an MHOSKEN on CPAN, but he hasn't done anything in 12 years.

PhilterPaper replied on 22 January 2021:

Petr, what is the current status of licensing? Is the Artistic License some of the code is under still unsatisfactory? Has anyone picked up the baton trying to work with Martin to permit a change in license? With the holidays over, it's probably time to start pushing this thing again. Martin did indicate support for one or two alternatives to PAL... has anyone at your end seriously discussed going to MIT license (for Martin's code) instead?

If things are moving forward on your end, I'll just sit tight and let it play out. Otherwise, what should be done? I'd like for Red Hat to be happy with the license and distribute PDF::Builder, provided this doesn't result in an unacceptable amount of work for me.

Are there any standards for rewriting code that it can be considered "new" and could thus be under LGPL (with the rest of PDF::Builder)? I suspect that merely changing variable names and internal routine names won't be enough. I don't want to go through the effort of a rewrite only to be told that it is still too close to the original work to pass as new.

ppisar replied on 28 January 2021:

Quote
On Fri, Jan 22, 2021 at 07:34:33AM -0800, Phil Perry wrote:
 Petr, what is the current status of licensing?
I'm sorry, I was quite busy. I didn't sent any e-mail, neither got any
response. I've just sent detailed instructions to Martin Hosken how to amend
the licensing terms.

Once he sends us an affirmative message, anybody including PDF::API2 and
PDF::Builder maintainers will be able to use his code under the new license.
You will then append his quote to the copyright header in those files ("This
specific module is licensed under...") or copy his complete e-mail message
somewhere into the PDF::Builder distribution. This enables users of the future
PDF::Build releses to notice the license change.

Quote
Are there any standards for rewriting code that it can be considered "new"
 and could thus be under LGPL (with the rest of PDF::Builder)? I suspect that
 merely changing variable names and internal routine names won't be enough.
 I don't want to go through the effort of a rewrite only to be told that it
 is still too close to the original work to pass as new.

You are right, just copying the code and rewriting identifiers is not enough.
It has to be an independent work. I.e. starting with an empty file and writing
the code without copy-pasting from the original file. You can retain original
identifiers of public interface of the modules (e.g. routine names and
semantics of their arguments).

PhilterPaper replied on 28 January 2021:

Thank you for following up on this (I received your email, too). I will be happy to append the license change text (once it's settled upon) to Martin's routines in PDF::Builder. Will you need a formal release (3.022) to CPAN to get your own release out, or will it be sufficient to have the updated files in GitHub?

ppisar replied on 29 January 2021:

Martin Hosken sent me a grant for the MIT license. I hope you got a copy.
(I can forward it to you if you didn't.)

There is no immediate change needed from you. The grant is for everyone.
I will attach it to the Fedora package.

Just update the text in GitHub. Once you do a new release embedding the new
license text, I will remove the Fedora copy of the grant since it will become
redundant with the new licesne text from your new release.

PhilterPaper replied on 29 January 2021:

Quote
Martin Hosken sent me a grant for the MIT license. I hope you got a copy.

You mean the following?

Quote
I, Martin Hosken, grant anybody a permission to use my PDF::API2 code under the terms of MIT license.

I notice that it only mentions PDF::API2... can I assume it also applies to any derivative works, such as PDF::Builder?

Quote
Just update the text on GitHub.

I should mention the license change it in the global documents such as INFO/LICENSE and (perhaps) README.md. Should I also (for clarity) update the affected files so there will be no confusion? It's no big deal.

It could be 3 or 4 months until the next CPAN release. If that holds up getting PDF::Builder onto Fedora, I could make a special quickie release much sooner. Let me know what works for you.

Add: I have updated (but not yet pushed to GitHub) the affected files with the following modified header text:
Code: [Select]
#   This specific module is licensed under the Perl Artistic License.
#   Effective 28 January 2021, the original author and copyright holder,
#   Martin Hosken, has given permission to use and redistribute this module
#   under the MIT license.
Is this satisfactory?

ppisar replied on 1 February 2021:

Quote
V Fri, Jan 29, 2021 at 06:48:39AM -0800, Phil Perry napsal(a):
 > Martin Hosken sent me a grant for the MIT license. I hope you got a copy.

You mean the following?
 >     I, Martin Hosken, grant anybody a permission to use my PDF::API2 code
 >     under the terms of MIT license.
Yes.
Quote
I notice that it only mentions PDF::API2... can I assume it also applies to
 any derivative works, such as PDF::Builder?
The grant is retroactive. It means that any changes ever made by Martin Hosken
in PDF::API2 are now in addition licensed with MIT. E.g. a code in
PDF::API2::Basic::PDF::Array.pm has "Artistic or MIT" license now. That means
that the code copied to PDF::Builder::Basic::PDF::Array is also "Artistic or
MIT" now. At the end it's the same code.

A different situation is with indeed changed code. E.g. a line "package
PDF::API2::Basic::PDF::Array;" was changed by someone into "package
PDF::Builder::Basic::PDF::Array;". An author of the change had only Artistic
license available when he was doing the change, hence the new line is still
Artistic only. But the author of the change has now a posibility to also claim
that his change is covered with MIT.

I did not inspect all the changes in PDF-Bulder, but e.g.
PDF::Builder::Basic::PDF::Array seems to be editted only by you. And those
changes are usually very small (like rewriting API2 into Builder). So I assume
that it's not a problem for you. I think that once you insert Martin's grant
there, you don't need to add you own claim there since anybody reading the
file without a git history is unable to distinguish who changed which part of
the file and the new perception that the whole file is "Artistic or MIT" will
be correct.
Quote
Just update the text on GitHub.

 I should mention the license change it in the global documents such as
 INFO/LICENSE and (perhaps) README.md. Should I also (for clarity) update the
 affected files so there will be no confusion? It's no big deal.
I think updating the affected files would be better. E.g. somethine like:
Code: [Select]
#=======================================================================
#
#   THIS IS A REUSED PERL MODULE, FOR PROPER LICENCING TERMS SEE BELOW:
#
#   Copyright Martin Hosken <Martin_Hosken@sil.org>
#
#   No warranty or expression of effectiveness, least of all regarding
#   anyone's safety, is implied in this software or documentation.
#
#   This specific module is licensed under the Perl Artistic License.
#
#   IN ADDITION:
#
#   I, Martin Hosken, grant anybody a permission to use my PDF::API2 code
#   under the terms of MIT license.
#
#=======================================================================
Quote
It could be 3 or 4 months until the next CPAN release. If that holds up
 getting PDF::Builder onto Fedora, I could make a special quickie release
 much sooner. Let me know what works for you.
It does not hold Fedora. Take your time.

PhilterPaper replied on 1 February 2021:

PDF::Builder has been updated on GitHub. Thank you everyone for your input on this.