Writing PNG with pure Python

[Johann C. Rocholl]

Just in case anybody has the same problem, here's my first attempt at
implementing a subset of the PNG spec in pure Python. I license it to
you under the terms of the GNU GPL.

http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.py

It encodes RGB images with 24 bits per pixel into PNG, using only the
modules sys, zlib and struct. These are all included in the base
distribution of Python. You don't need gd or imlib.

I have done a little testing, and my implementation processes 8 megs of
RGB input in 0.6 seconds. With Adam7 interlacing enabled, it takes 10
times longer.

I would really appreciate any feedback and suggestions for improvement.

Cheers,
Johann

 

[Sybren Stuvel]

Johann C. Rocholl enlightened us with:

It encodes RGB images with 24 bits per pixel into PNG [...] I would
really appreciate any feedback and suggestions for improvement.

You should really also include the alpha channel. Without that, PNG is
crippled IMHO.

Sybren

 

[Johann C. Rocholl]

You should really also include the alpha channel. Without that, PNG is

crippled IMHO.

I have now added simple transparency (marking one color as transparent
with a tRNS chunk). If anybody wants full alpha channel support, ask
kindly or send me a patch. I would like to avoid duplicating all the
functions, so maybe we should introduce a parameter to switch between 3
and 4 bytes per pixel.

Cheers,
Johann

 

[Alan Isaac]

here's my first attempt at
implementing a subset of the PNG spec in pure Python. I license it to
you under the terms of the GNU GPL.
http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.py

It's your code, so you get to license it.
But if you wish to solicit patches,
a more Pythonic license is IMHO more likely
to prove fruitful.

Alan Isaac

 

[David Isaac]

Em Sex, 2006-06-09 às 12:30 -0400, Alan Isaac escreveu:

"Pythonic license"? That's new to me. I can figure out what a
"Python-like license" is, but I'm clueless about a "Pythonic license".

http://www.panikon.com/phurba/alteng/i.html
hth,
Alan Isaac

 

[Felipe Almeida Lessa]

Em Sex, 2006-06-09 às 12:30 -0400, Alan Isaac escreveu:

It's your code, so you get to license it.
But if you wish to solicit patches,
a more Pythonic license is IMHO more likely
to prove fruitful.

"Pythonic license"? That's new to me. I can figure out what a
"Python-like license" is, but I'm clueless about a "Pythonic license".

 

[Johann C. Rocholl]

It's your code, so you get to license it.
But if you wish to solicit patches,
a more Pythonic license is IMHO more likely
to prove fruitful.

What license would you suggest? After some reading at [1] and [2] and
[3], I found that the Academic Free License (version 2.1) and the
Apache License (version 2.0) are considered helpful for contributions
to the Python Software Foundation.

So far, I haven't used either of these licenses for my own code, and
after a little reading the AFL seems okay for me. I would perhaps
consider the LGPL [4] as an alternative because it is less restrictive
than the GPL.

Thoughts or links, anybody?

Cheers,
Johann

[1] http://www.python.org/moin/PythonSoftwareFoundationLicenseFaq
[2] http://www.python.org/psf/records/board/minutes/2004-11-09/
[3] http://www.python.org/psf/contrib/
[4] http://www.gnu.org/licenses/lgpl.html

 

[David Isaac]

What license would you suggest?

I recommend that you choose the license that will best achieve
your long run goals for the code. As I understand them, and
as I understand your application and software development,
this implies something like the MIT license:
http://www.opensource.org/licenses/mit-license.php
I believe that the MIT license maximizes the likelihood that
a small scale application will receive useful patches, as long
as you actively incorporate patches.

You may reach other conclusions for many reasons ...

Cheers,
Alan Isaac

 

[Johann C. Rocholl]

The MIT license is enticingly short and simple, thank you for the tip.

I have now decided to license my project (including the pure python PNG
library) under the Apache License 2.0 which is less restrictive than
the GPL in terms of sublicensing. The Apache License looks modern and
well-maintained to me. My project runs on Apache, so there is some
context there as well. Also, this change will simplify things if I ever
want to contribute some of the code to the Python Software Foundation.

Cheers,
Johann

 

[Johann C. Rocholl]

Just in case anybody has the same problem, here's my first attempt at

implementing a subset of the PNG spec in pure Python. I license it to
you under the terms of the GNU GPL.

Update: the code is now licensed under the Apache License 2.0.

http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.py

Update: the module has moved to its own package, with its own setup.py:

http://trac.browsershots.org/browser/trunk/pypng
http://svn.browsershots.org/trunk/pypng/

Cheers,
Johann

 

[Paul Boddie]

The MIT license is enticingly short and simple, thank you for the tip.

I have now decided to license my project (including the pure python PNG
library) under the Apache License 2.0 which is less restrictive than
the GPL in terms of sublicensing.

But it is also incompatible with the GPL:

http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses

It's obviously your decision about how you license your own code, but
I'd advise you to disregard the "Pythonic license" rhetoric, whatever
that means: Python's original licence was regarded as not being enough
of a licence by some lawyers (that's what some people refer to as the
original Python licence); subsequent licences aren't recommended for
application to any other works (like various licences of the Python
code over the years); despite advocacy for permissive licences by some
parties, there exist numerous successful GPL'd and LGPL'd Python
projects (meaning that projects licensed in such a way are not lesser
members of the community). Moreover, any licensing gymnastics
undertaken by the PSF did involve various extra somersaults to remain
GPL-compatible, meaning that even people who favour permissive licences
regard "licence interoperability" positively.

If you're convinced that a permissive licence suits your code best,
please consider something whose side-effects you understand. If the
additional patent grant or licence termination clauses (which the FSF
don't regard as a bad thing, just something incompatible with the
current GPL/LGPL) are specifically what you want, then the Apache
Licence may be what you're after; otherwise, you should choose
something less baroque and better understood, perhaps from this list:

http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

Yes, one of the best places to find out about non-FSF licences is
actually the FSF themselves, undermining various myths some people like
to put forward.

Paul

 

[Steve Holden]

But it is also incompatible with the GPL:

http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses

It's obviously your decision about how you license your own code, but
I'd advise you to disregard the "Pythonic license" rhetoric, whatever
that means: Python's original licence was regarded as not being enough
of a licence by some lawyers (that's what some people refer to as the
original Python licence); subsequent licences aren't recommended for
application to any other works (like various licences of the Python
code over the years); despite advocacy for permissive licences by some
parties, there exist numerous successful GPL'd and LGPL'd Python
projects (meaning that projects licensed in such a way are not lesser
members of the community). Moreover, any licensing gymnastics
undertaken by the PSF did involve various extra somersaults to remain
GPL-compatible, meaning that even people who favour permissive licences
regard "licence interoperability" positively.

If you're convinced that a permissive licence suits your code best,
please consider something whose side-effects you understand. If the
additional patent grant or licence termination clauses (which the FSF
don't regard as a bad thing, just something incompatible with the
current GPL/LGPL) are specifically what you want, then the Apache
Licence may be what you're after; otherwise, you should choose
something less baroque and better understood, perhaps from this list:

http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

Yes, one of the best places to find out about non-FSF licences is
actually the FSF themselves, undermining various myths some people like
to put forward.

Also remember that it's perfectly possible to release the same code
under several different licenses. This can happen, for example, with
contributions to Python. The PSF doesn't care how you license it to
anyone else, only that you license it to the PSF under the Free Academic
Licence or v2 of the Apache License. We then re-license it to Python
users (under the Python license, naturally).

If the contributor then wants to license the same code under the GPL to
other people there's no problem with that.

regards
Steve

 

[Johann C. Rocholl]

I have now decided to license my project (including the pure python PNG

But it is also incompatible with the GPL:

http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses

Thank you for enlightening me. I was under the wrong impression that
the Apache License was compatible with the GPL, perhaps because it is
OSI-approved, which means a different thing as I now understand.

If you're convinced that a permissive licence suits your code best,
please consider something whose side-effects you understand. If the
additional patent grant or licence termination clauses (which the FSF
don't regard as a bad thing, just something incompatible with the
current GPL/LGPL) are specifically what you want, then the Apache
Licence may be what you're after; otherwise, you should choose
something less baroque and better understood, perhaps from this list:

http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

I do believe that my code will be useful for more people if it's under
a permissive license, but obviously also if it's under a GPL-compatible
license. Therefore it's perhaps a good idea to change the license of my
software again.

Currently, I am considering the following options:
- LGPL
- Modified BSD License
- X11 License (aka MIT License)

I appreciate the simplicity of the BSD and MIT Licenses, except for the
names. "BSD License" can be confused with the original BSD License,
while "MIT License" according to the FSF "is misleading, since MIT has
used many licenses for software." But perhaps these drawbacks are just
mentioned on the FSF page to get more people to use the GPL or LGPL.


I don't want to start a holy war about the benefits of the GPL, but I
would like some more input about the choices of licensing. Perhaps I'll
put the larger part of my Project under the GPL and only some
standalone library parts (like the PNG encoder) under the LGPL.

If I ever want to contribute some of the code to the Python Software
Foundation, I can still license it to them under the Apache License,
right? But how about the parts of the code that others contribute to my
software while it's licensed under the LGPL?

Cheers, Johann

 

[Scott David Daniels]

I appreciate the simplicity of the BSD and MIT Licenses, except for the
names. "BSD License" can be confused with the original BSD License,
while "MIT License" according to the FSF "is misleading, since MIT has
used many licenses for software."

I had one lawyer tell me the MIT license was better at declaring your
non-liability than BSD. IANAL, your lawyer may vary, ....

 

[Ben Finney]

Currently, I am considering the following options:
- LGPL
- Modified BSD License
- X11 License (aka MIT License)

I appreciate the simplicity of the BSD and MIT Licenses, except for
the names. "BSD License" can be confused with the original BSD
License, while "MIT License" according to the FSF "is misleading,
since MIT has used many licenses for software." But perhaps these
drawbacks are just mentioned on the FSF page to get more people to
use the GPL or LGPL.

I think these are real concerns. Discussion of these licenses usually
needs to be couched in clarifications, such as "the three-clause
BSD-style license" or "the MIT X11 license"; but these clarifications
are also often dropped, leaving ambiguity as to exactly which license
terms are being discussed.

If you want a permissive, GPL-compatible, copyright-preserving
license, the Expat license is probably the simplest.

I don't want to start a holy war about the benefits of the GPL, but
I would like some more input about the choices of licensing.

The FSF licensing webpage offers assistance via email in choosing a
license:

If I ever want to contribute some of the code to the Python Software
Foundation, I can still license it to them under the Apache License,
right?

This would be a reason to choose something like the Expat license; it
isn't a copyleft, so others can take your code and redistribute it
under a *different* license, such as the Apache license, without
seeking extra permission from you.

But how about the parts of the code that others contribute to my
software while it's licensed under the LGPL?

You could require that all contributions be licensed by the author
under the Expat license, allowing you to take it into the whole
without needing to seek out that author in future, while still
preserving their copyright.

 

[Johann C. Rocholl]

How about this here construct?

#!/usr/bin/env python
# png.py - PNG encoder in pure Python
# Copyright (C) 2006 Johann C. Rocholl <[email protected]>
#
# This file is licensed alternatively under one of the following:
# 1. GNU Lesser General Public License (LGPL), Version 2.1 or newer
# 2. GNU General Public License (GPL), Version 2 or newer
# 3. Apache License, Version 2.0 or newer
# 4. The following license (aka MIT License)
#
# --------------------- start of license -----------------------------
# Copyright (C) 2006 Johann C. Rocholl <[email protected]>
#
# Permission is hereby granted, free of charge, to any person
# obtaining a copy of this software and associated documentation files
# (the "Software"), to deal in the Software without restriction,
# including without limitation the rights to use, copy, modify, merge,
# publish, distribute, sublicense, and/or sell copies of the Software,
# and to permit persons to whom the Software is furnished to do so,
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
# ----------------------- end of license -----------------------------
#
# You may not use this file except in compliance with at least one of
# the above four licenses.

 

[Ben Finney]

How about this here construct?

#!/usr/bin/env python
# png.py - PNG encoder in pure Python
# Copyright (C) 2006 Johann C. Rocholl <[email protected]>
#
# This file is licensed alternatively under one of the following:
# 1. GNU Lesser General Public License (LGPL), Version 2.1 or newer
# 2. GNU General Public License (GPL), Version 2 or newer
# 3. Apache License, Version 2.0 or newer
# 4. The following license (aka MIT License)

Pointless. Licensing it under the Expat license (what you're calling
"MIT License", but we've already discussed the ambiguities in that
term) allows all the rights granted in all the other license you name,
plus just about anything else.

Hence, there's no point listing the others if you are also happy for
people to have it under the Expat license. On the other hand, if you
want to be more restrictive than the terms of the Expat license, you
need to choose a different license.

Simplify. Please don't attempt to write yet another set of license
terms without expert legal assistance. You've already chosen the Expat
license as being acceptable; use that, and you grant all the rest
without even mentioning it.

 

[Johann C. Rocholl]

Simplify. Please don't attempt to write yet another set of license
terms without expert legal assistance. You've already chosen the Expat
license as being acceptable; use that, and you grant all the rest
without even mentioning it.

Sorry for my stubborn ignorance, and thank you for your patient
explanations.

I think I finally got it: I'll put the bulk of my browsershots project
under the GNU GPL again, and the independent library parts like png.py
under the Expat License.

Cheers,
Johann

 

[Ben Finney]

Sorry for my stubborn ignorance, and thank you for your patient
explanations.

No problems; if license proliferation can be reduced, it's worth
spending some time to do so.

I think I finally got it: I'll put the bulk of my browsershots
project under the GNU GPL again, and the independent library parts
like png.py under the Expat License.

Sounds quite workable. This has the effect that the work as a whole
can be redistributed under the GNU GPL (since the Expat license allows
this), and the library parts can be redistributed independently under
just about any license.