The relevant commit message:

commit 2a17839
Author: Michael Droettboom [email protected]
Date: Wed Oct 15 10:35:38 2014 -0400

Upgrade Agg to SVN r103

There is one additional patch that is currently awaiting acceptance. That
can be found at commit cf11aea

Cheers!
Ben Root

On Mon, Feb 29, 2016 at 1:33 PM, jelmd [email protected] wrote:

I'm currently trying to compile 1.5.1 using libagg2 2.5.0.1, but
unfortunately it fails with errors like "src/agg_workaround.h", line 12:
Error: conv_rgba_pre is not a member of agg. so it is obviously not
compatible to 2.5.0.1 anymore (but setupext.py says, it is sufficient).

Digging around a little bit, I saw, that matplotlib has also an
extern/agg24-svn/ but I couldn't find any information about which version
it is. Basic idea is to find out about matplotlib's modifications and port
it back to the system's libagg2 package, so that both are consistent and
matplotlib can continue to use the system's lib instead of duplicating most
of it ...

So can anyone say, on what exactly extern/agg24-svn/ is based on and what
matplotlib team's intention is wrt. its current/future state?

—
Reply to this email directly or view it on GitHub
#6077.

matplotlib has never been compatible with agg 2.5.0, as that version of agg is GPL'd. Linking against it would be a GPL violation, as matplotlib is not GPL'd. We have no plans to ever used the GPL licensed version.

Semantics here... linking against 2.5+ itself wouldn't be a GPL violation.
What that does it makes that particular instance of the packaged binary
GPL'ed. So long as that packager makes available matplotlib's source code,
then I think all is still kosher. We as the matplotlib developers do not
develop against that version of libagg2 because we have no intention of
making our distribution of matplotlib GPL'ed.

On Mon, Feb 29, 2016 at 2:25 PM, Michael Droettboom <
[email protected]> wrote:

matplotlib has never been compatible with agg 2.5.0, as that version of
agg is GPL'd. Linking against it would be a GPL violation, as matplotlib is
not GPL'd. We have no plans to ever used the GPL licensed version.

—
Reply to this email directly or view it on GitHub
#6077 (comment)
.

Ahh ok, thanx for the infos!

If there is no intention to be compatible to any official version of libagg2 (at least cf11aea suggests that IIUIC), shouldn't the corresponding pkgconfig check for libagg in setupext.py be removed or adjusted to say e.g. 200.5.0 instead of 2.5.0.1?

The latter is pretty misleading, however worked for 1.4 - and just checked: At least the published 2.4 and 2.5 versions on http://antigrain.com/ are almost identical (2.5. seems to have some minimal fixes, ~ 20 lines +-), so basically the only difference is the license used, yepp (I think, this confuses ppl as well).

The situation with Agg is confusing and unfortunate. I have tried building against plain old rev103 (and even the latest 112), but it appears that the version in matplotlib is still patched even more than just cf11aea. I have become busy and so have yet to track down the origin of these differences.

It seems unlikely there will ever be another upstream release of Agg. I think, as much as it bothers me, we should just consider our copy the only officially supported fork.

Would be ok for me, as long as one isn't forced to use python, i.e. libagg2 can still be used within plain C projects without loosing any functionality it has right now.

Sorry I wasn't clear -- I mean the only officially supported fork by matplotlib. The other forks in the wild would be completely unaffected.

Hmmm, yes, and I hoped, that the work done on it can be shared via an external lib and thus clients have the same behavior ... Anyway, if that's not possible, we've to live with it =8-(.

I am stilling holding out a little hope that the recently-active (relatively speaking) maintainer will accept my offer to help upstream a bunch of patches, but I haven't seen any response as yet.

As it's a C++ template library, there isn't much of a shared object file anyway...

Since #11984 we don't even try to use anything but the vendored version of Agg anymore, so I'm going to close this. This can be revisited if somehow, miraculously, upstream Agg becomes a thing again...