|Re: [Hangout - NYLXS] [png-mng-implement] libpng license 2.0
|Matthias B. wrote:
> I think inventing a new license is an absolute disaster. If you want to
> change the license, switch to an existing OSI-approved one.
In this thread we've discussed at length the theoretical possibility
(as well as the practical impossibility) to just switch to some other
random license, popular or not, OSI-approved or not.
I want to release the next libpng version 1.6.36 with an OSI-approved
license, and I'm making the changes that I believe are necessary, in
order to have it approved. I explained the rationale extensively in my
Most importantly, the present-day libpng license is not reusable across
different libpng versions or different contributing authors. I need to
rectify that. I'm not inventing a new license, I'm fixing the existing
one in order to make it reusable.
That's why I'm naming it "libpng license version 2", not "yet another
invented license version 1.0".
Following this discussion, and in the light of Glenn's approval, I will
submit my proposed wording to OSI for review. I intend to listen to
their critique and follow their recommendations. I'll keep you posted.
Bob Friesenhahn wrote:
> This creates an interesting situation since Github and others
> encourage 'forking' and modifying software. Github shows 550 search
> hits for 'libpng' (not all of which are copies) and 8 direct forks of
> Glenn's master repository. Each 'fork' which results in some
> modification should immediately add a document which describes the
> modifications which were made since Github distributes source code via
> Git and tarball downloads.
Good point, but hey, you missed the forks on BitBucket and GitLab ;-)
This is a glossary issue.
Terse licenses like MIT, BSD, etc., don't have a glossary, and they
work under the assumption that the licensor and the licensee agree on
In more verbose licenses like Apache, CPL, EPL, EUPL, etc., there is
a glossary, and all have it in Section 1.
Neither the zlib license nor the libpng license define any term. What
constitutes "original software"? What is an "altered version"? Is there
a necessity to attach a document indicating an "alteration"? Is it
misrepresentation if such document isn't attached?
Thanks to the way in which Git works, I am not concerned in principle
about a Git fork, because in this day, it's common knowledge what a Git
fork is, and how it works. Look, commits! I don't see much of a danger
of confusion, if users know how to distinguish between a random fork
of a random project, and the original source code downloaded from a
location that's trusted to distribute the original.
Now, what if somebody would start distributing a flattened tarball
named libpng-1.6.35.tar.gz, containing their own alterations, but
without any indication of what's changed? Misrepresentation of the
original source, in my opinion.
And I give you that, John: it's trivial to force-push a Git tag to
one's own GitHub fork, then have GitHub make a release archive from
that. That *is* annoying.
Our own PNG Development Group is a centralized body that publishes
PNG-related documents, registered extensions, the png-mng-implement
mailing list, the libpng.org website, the PNG Reference Library
(i.e. libpng), etc.
Would it be possible for a random group of people, independent of, and
unrelated to our group, to start voting on PNG public chunks on their
own while still calling it "PNG"? Release libpng-2.0, then libpng-3.0,
then libpng-4.0, on their own, still calling it "libpng"? Publish, say,
https://png.net or https://png.info? All of that, while we still exist,
and in competition with us? Yes, it's possible. I hope it won't happen.
I would consider that an unacceptable form of misrepresentation.
I believe that the libpng license grants us more legal protection than
other licenses, and I want to keep it that way.
png-mng-implement mailing list
Hangout mailing list