MapGuide fork of AGG

[Steve Lime]

I think this is a pretty good synopsis, thanks for providing it. I'd add
that I don't see
a big problem with AGG 2.5 and a GPL license and MapServer either. 

As Paul Ramsey pointed out back in November:

"For AGG, you'll be linking to a GPL library, which means you won't be
able to distribute BSD binaries anymore -- any binary linked against
AGG will have to go out under the GPL. Basically, if you only care
about Mapserver as an open source product, it's no problem, but if
you have any plans to distribute altered versions as closed source,
you cannot do it with the AGG dependency turned on."

I'd rather see the MapGuide and MapServer folks (along with the other
open source 
projects that use AGG) work with Maxim to fix build issues if
possible.

Steve

>>> On 10/23/2007 at 3:06 AM, in message
<d2b988930710230106m71bff5aboa4b6b1a1c9b77546 at mail.gmail.com>, thomas
bonfort
<thomas.bonfort at GMAIL.COM> wrote:
> On 10/23/07, Paul Spencer <pspencer at dmsolutions.ca> wrote:
>> Steve, Daniel, I encourage you to voice your opinions on the
mapguide
>> internals list ... the more the better.  I would love to see some
>> collaboration between mapguide and mapserver at this level.  It
seems
>> like easy common ground to get started talking together.
> 
> hi all,
> 
> I've been thinking about the pros and cons of having an osgeo fork
of
> AGG, from a mapserver point of view but I think most of it applies
to
> mapguide too.
> 
> pro:
> * the agg build process is a pain for the users, as the agg
makefiles
> need some modifications before some of the mapscript components can
> run. I see two issues that have to be fixed in this field:
> - the freetype font manager isn't included in the default built.
This
> is by design and not a bug, so any fixes on this end will never be
> backported to the official 2.4+ agg branches ( at least imho )
> - makefiles and configure logic should include the ability to build
> position independant code (-fPIC). I don't think fixes for this
would
> be included in the official agg releases, as I think the aim is to
> have agg build by just typing 'make' and not having to configure
> anything
> 
> this could push us to have an osgeo tarball of agg 2.4 , with these
> few glitches fixed. I don't know if we can call that a fork, but
this
> at least allows us to keep a bsd compatible version secure whatever
> happens on the agg side, and a place to point the endusers at
if/when
> they encounter build problems.
> 
> cons:
> * do any folks at osgeo have the incentive and/or knowledge to
> continue on agg development? backporting fixes should be easy to do
> (for the time being this is useless as maxim of agg is still
> maintaining 2.4 - this might not last for long though), but keeping
up
> with features of 2.5+ (when and if they come) seems unfeasible for
non
> specialist people (without resorting to blindly backporting agg
> trunk's changes which seems a rather lame thing to do given maxim's
> wish in change of license)
> * this is mapserver specific, and I may be completely wrong here,
but
> it seems to me that the agg license change isn't a deal breaker for
> us. folks can continue "using" an agg-gpl enabled mapserver, and the
> businesses who are reselling modified/bundled/etc versions of
> mapserver can either continue with the gd-only version, or pay up
for
> a commercial agg license. I didn't follow the discussions when pdf
> support was added, but pdflib is far more constraining than agg in
the
> sense you have to pay a license for /any/ commercial use.
> 
>> In particular, I think mapserver could benefit from Traian's
>> modifications for rendering into a different buffer to solve the
>> alpha problems and for the rendering on transparent background
thing.
>>
> after sorting this out off-list with Traian, it turns out that there
> is no bug in the agg blending functions, just a mixup in which
> blenders to use and what ouptut they are supposed to generate
> 
> just my .02€
> 
> thomas
> 
>>
>> On 22-Oct-07, at 2:12 PM, Steve Lime wrote:
>>
>> > This should be a nice mess, especially if there is a broader
>> > community fork of AGG 2.4. I'm curious
>> > why a fork is even necessary? The RFC doesn't go into any detail.
>> > The one piece of code mentioned
>> > in the thread certainly doesn't necessitate a fork.
>> >
>> > Steve
>> >
>> >>>> On 10/20/2007 at 12:11 PM, in message <471A36AC.
>> >>>> 8090403 at mapgears.com>, Daniel
>> > Morissette <dmorissette at MAPGEARS.COM> wrote:
>> >> MapServer Dev's
>> >>
>> >> This is just a heads up that MapGuide has a RFC open right now
about
>> >> adding support for AGG rendering, and as part of that they plan
to
>> >> fork
>> >> AGG 2.4 and make some improvements to it:
>> >>    http://trac.osgeo.org/mapguide/wiki/MapGuideRfc40 
>> >>
>> >> A few people have already suggested on the mapguide-internals
list
>> >> that
>> >> they do that in a way that other OSGeo projects such as MapServer
can
>> >> benefit from the improved version. Interested parties can review
the
>> >> thread in the archives at
>> >> http://lists.osgeo.org/pipermail/mapguide-internals/2007-October/

>> >> 001922.html
>> >>
>> >> Daniel
>>
>> +-----------------------------------------------------------------+
>> |Paul Spencer                          pspencer at dmsolutions.ca    |
>> +-----------------------------------------------------------------+
>> |Chief Technology Officer                                         |
>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>> +-----------------------------------------------------------------+
>>