MapGuide fork of AGG

[Daniel Morissette]

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
--
Daniel Morissette
http://www.mapgears.com/

[Steve Lime]

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@...>, Daniel
Morissette <dmorissette@...> 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

[Daniel Morissette]

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.
>

Of course you and others more knowledgeable about the AGG situation than
myself are welcome to join the discussion on the mapguide-internals list.

Daniel
--
Daniel Morissette
http://www.mapgears.com/

[Paul Spencer-2]

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.

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.

Cheers

Paul

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@...>, Daniel
> Morissette <dmorissette@...> 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@...    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+

[thomas bonfort]

On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
> > Morissette <dmorissette@...> 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@...    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>

[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@...>, thomas
bonfort
<thomas.bonfort@...> wrote:
> On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
>> > Morissette <dmorissette@...> 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@...    |
>> +-----------------------------------------------------------------+
>> |Chief Technology Officer                                         |
>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>> +-----------------------------------------------------------------+
>>

[Dave McIlhagga]

So this means effectively we're looking at a relicensing of MapServer  
as GPL?

Dave



On 23-Oct-07, at 3:28 PM, Steve Lime wrote:

> 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@...>, thomas
> bonfort
> <thomas.bonfort@...> wrote:
>> On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
>>>> Morissette <dmorissette@...> 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@...    |
>>> +-----------------------------------------------------------------+
>>> |Chief Technology Officer                                         |
>>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>>> +-----------------------------------------------------------------+
>>>

[Steve Lime]

I don't think so, or only in a limited case, but I'm not a license guy.
As I understand
what Paul said way back that would be the case if one distributed
binaries linked with
AGG 2.5 (and one could always do 2.4). I'm not even sure what a GPL'd
binary means
since you wouldn't have the source, although I found some documents that
suggest
that you would have to distribute the source for a period of time (but
under what
license, GPL I guess)? As a user it wouldn't worry me, not sure about
companies selling
solutions.

I also thought Paul Spencer had talked to the AGG guy (Maxim) and there
was a
possibility of an exemption for MapServer (w/regards to GPL).

Steve

>>> Dave McIlhagga <dmcilhagga@...> 10/23/07 11:15 PM >>>
So this means effectively we're looking at a relicensing of MapServer  
as GPL?

Dave

On 23-Oct-07, at 3:28 PM, Steve Lime wrote:

> 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@...>, thomas
> bonfort
> <thomas.bonfort@...> wrote:
>> On 10/23/07, Paul Spencer <pspencer@...> 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>> 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@...>, Daniel
>>>> Morissette <dmorissette@...> 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@...    |
>>> +-----------------------------------------------------------------+
>>> |Chief Technology Officer                                         |
>>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>>> +-----------------------------------------------------------------+
>>>

[Stephen Woodbridge]

Dave McIlhagga wrote:
> So this means effectively we're looking at a relicensing of MapServer as
> GPL?

I would hope not!

I think that what this means is that the license of derivative works
will depend on what libraries the user builds them with. If the user
builds an executable with AGG 2.5 then that executable and all down
stream works from that would be GPL.

The Mapserver source will remain under its current license. If mapserver
ever decided to change the licensing to GPL, that would most like cause
a fork, just as AGG 2.4 and 2.5+ are going to be forked in the sense
that people that do not want GPL will stay on 2.4 and eventually if
anyone wants to add features or fixes to that it will probably need to
be forked and maintained out of a separate source tree unless other
arrangements can be made with the author/maintainer.

-Steve

> Dave
>
>
>
> On 23-Oct-07, at 3:28 PM, Steve Lime wrote:
>
>> 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@...>, thomas
>> bonfort
>> <thomas.bonfort@...> wrote:
>>> On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
>>>>> Morissette <dmorissette@...> 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@...    |
>>>> +-----------------------------------------------------------------+
>>>> |Chief Technology Officer                                         |
>>>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>>>> +-----------------------------------------------------------------+
>>>>

[Dave McIlhagga]

Ok - let me rephrase that. Does that mean when distributing MapServer  
with AGG 2.5, in that instance all of that code (including the  
MapServer source code) would have to be distributed via a GPL license.

Does that also then mean that any users who are bundling MapServer  
today in proprietary solutions could not do so with this build?

Does this mean that if other 3rd party proprietary components are  
included in a distributed build that they too would be subject to  
availability via GPL?

If the above are true - I can think of a few pretty significant  
instances where this decision could be pretty big problems.

Dave


On 24-Oct-07, at 1:09 AM, Stephen Woodbridge wrote:

> Dave McIlhagga wrote:
>> So this means effectively we're looking at a relicensing of  
>> MapServer as GPL?
>
> I would hope not!
>
> I think that what this means is that the license of derivative  
> works will depend on what libraries the user builds them with. If  
> the user builds an executable with AGG 2.5 then that executable and  
> all down stream works from that would be GPL.
>
> The Mapserver source will remain under its current license. If  
> mapserver ever decided to change the licensing to GPL, that would  
> most like cause a fork, just as AGG 2.4 and 2.5+ are going to be  
> forked in the sense that people that do not want GPL will stay on  
> 2.4 and eventually if anyone wants to add features or fixes to that  
> it will probably need to be forked and maintained out of a separate  
> source tree unless other arrangements can be made with the author/
> maintainer.
>
> -Steve
>
>> Dave
>> On 23-Oct-07, at 3:28 PM, Steve Lime wrote:
>>> 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@...>,  
>>> thomas
>>> bonfort
>>> <thomas.bonfort@...> wrote:
>>>> On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
>>>>>> Morissette <dmorissette@...> 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@...    |
>>>>> +-----------------------------------------------------------------
>>>>> +
>>>>> |Chief Technology  
>>>>> Officer                                         |
>>>>> |DM Solutions Group Inc                http://
>>>>> www.dmsolutions.ca/ |
>>>>> +-----------------------------------------------------------------
>>>>> +
>>>>>
>

[Stephen Woodbridge]

Dave,

I'm not a lawyer, but that would be my interpretation also. As soon as
you bundle a GPL product it will taint all down stream products with the
GPL. I think the comments that were made about AGG 2.5 "not being a
problem" were related to an end-user building a mapserver with that for
use on their server, which should not be a problem. It only becomes a
problem when and if you want to distribute it. In that case you want to
avoid adding in any GPL'd parts. I would think this would have an impact
on mapscript products like Chameleon and any products that rely on or
link with mapserver.

I think it is very important that we keep Mapserver under its current
licensing.

-Steve W.

Dave McIlhagga wrote:

> Ok - let me rephrase that. Does that mean when distributing MapServer
> with AGG 2.5, in that instance all of that code (including the MapServer
> source code) would have to be distributed via a GPL license.
>
> Does that also then mean that any users who are bundling MapServer today
> in proprietary solutions could not do so with this build?
>
> Does this mean that if other 3rd party proprietary components are
> included in a distributed build that they too would be subject to
> availability via GPL?
>
> If the above are true - I can think of a few pretty significant
> instances where this decision could be pretty big problems.
>
> Dave
>
>
> On 24-Oct-07, at 1:09 AM, Stephen Woodbridge wrote:
>
>> Dave McIlhagga wrote:
>>> So this means effectively we're looking at a relicensing of MapServer
>>> as GPL?
>>
>> I would hope not!
>>
>> I think that what this means is that the license of derivative works
>> will depend on what libraries the user builds them with. If the user
>> builds an executable with AGG 2.5 then that executable and all down
>> stream works from that would be GPL.
>>
>> The Mapserver source will remain under its current license. If
>> mapserver ever decided to change the licensing to GPL, that would most
>> like cause a fork, just as AGG 2.4 and 2.5+ are going to be forked in
>> the sense that people that do not want GPL will stay on 2.4 and
>> eventually if anyone wants to add features or fixes to that it will
>> probably need to be forked and maintained out of a separate source
>> tree unless other arrangements can be made with the author/maintainer.
>>
>> -Steve
>>
>>> Dave
>>> On 23-Oct-07, at 3:28 PM, Steve Lime wrote:
>>>> 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@...>, thomas
>>>> bonfort
>>>> <thomas.bonfort@...> wrote:
>>>>> On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
>>>>>>> Morissette <dmorissette@...> 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@...    |
>>>>>> +-----------------------------------------------------------------+
>>>>>> |Chief Technology Officer                                         |
>>>>>> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
>>>>>> +-----------------------------------------------------------------+
>>>>>>
>>

[Dave McIlhagga]

You've hit the nail on the head there Steve,

Anyone distributing MapServer with AGG 2.5 gets implicated in this.  
I'm not sure we fully understand the ripple effect here.

Dave



On 24-Oct-07, at 10:00 AM, Stephen Woodbridge wrote:

> Dave,
>
> I'm not a lawyer, but that would be my interpretation also. As soon  
> as you bundle a GPL product it will taint all down stream products  
> with the GPL. I think the comments that were made about AGG 2.5  
> "not being a problem" were related to an end-user building a  
> mapserver with that for use on their server, which should not be a  
> problem. It only becomes a problem when and if you want to  
> distribute it. In that case you want to avoid adding in any GPL'd  
> parts. I would think this would have an impact on mapscript  
> products like Chameleon and any products that rely on or link with  
> mapserver.
>
> I think it is very important that we keep Mapserver under its  
> current licensing.
>
> -Steve W.
>
> Dave McIlhagga wrote:
>> Ok - let me rephrase that. Does that mean when distributing  
>> MapServer with AGG 2.5, in that instance all of that code  
>> (including the MapServer source code) would have to be distributed  
>> via a GPL license.
>> Does that also then mean that any users who are bundling MapServer  
>> today in proprietary solutions could not do so with this build?
>> Does this mean that if other 3rd party proprietary components are  
>> included in a distributed build that they too would be subject to  
>> availability via GPL?
>> If the above are true - I can think of a few pretty significant  
>> instances where this decision could be pretty big problems.
>> Dave
>> On 24-Oct-07, at 1:09 AM, Stephen Woodbridge wrote:
>>> Dave McIlhagga wrote:
>>>> So this means effectively we're looking at a relicensing of  
>>>> MapServer as GPL?
>>>
>>> I would hope not!
>>>
>>> I think that what this means is that the license of derivative  
>>> works will depend on what libraries the user builds them with. If  
>>> the user builds an executable with AGG 2.5 then that executable  
>>> and all down stream works from that would be GPL.
>>>
>>> The Mapserver source will remain under its current license. If  
>>> mapserver ever decided to change the licensing to GPL, that would  
>>> most like cause a fork, just as AGG 2.4 and 2.5+ are going to be  
>>> forked in the sense that people that do not want GPL will stay on  
>>> 2.4 and eventually if anyone wants to add features or fixes to  
>>> that it will probably need to be forked and maintained out of a  
>>> separate source tree unless other arrangements can be made with  
>>> the author/maintainer.
>>>
>>> -Steve
>>>
>>>> Dave
>>>> On 23-Oct-07, at 3:28 PM, Steve Lime wrote:
>>>>> 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@...>,  
>>>>> thomas
>>>>> bonfort
>>>>> <thomas.bonfort@...> wrote:
>>>>>> On 10/23/07, Paul Spencer <pspencer@...> 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@...>, Daniel
>>>>>>>> Morissette <dmorissette@...> 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@...    |
>>>>>>> +---------------------------------------------------------------
>>>>>>> --+
>>>>>>> |Chief Technology  
>>>>>>> Officer                                         |
>>>>>>> |DM Solutions Group Inc                http://
>>>>>>> www.dmsolutions.ca/ |
>>>>>>> +---------------------------------------------------------------
>>>>>>> --+
>>>>>>>
>>>

[Doyon, Jean-Francois-2]

Is it feasable to distribute a given software package (i.e. mapserver)
under more than one license?

Could one say, here's the GPL'ed MapServer, or here's the BSD-ish
MapServer? They can be entirely identical, maybe just different download
files with different license files or something like that.  Or maybe
it's one distribution, and you can give the user a choice?

In the end, those concerned about all this but really wanting AGG
support will need to use 2.4 ... If supporting those customers that need
a BSD MapServer is key, supporting AGG 2.4 into the future will be
necessary :(

Forking AGG seems like an even worst solution to me ...

Might've been nice to have AGG as LGPL instead of GPL ...

J.F.

-----Original Message-----
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV@...]
On Behalf Of Frank Warmerdam
Sent: October 24, 2007 10:59
To: MAPSERVER-DEV@...
Subject: Re: [UMN_MAPSERVER-DEV] MapGuide fork of AGG

Dave McIlhagga wrote:
> Ok - let me rephrase that. Does that mean when distributing MapServer
> with AGG 2.5, in that instance all of that code (including the
> MapServer source code) would have to be distributed via a GPL license.

Dave,

If one distributes MapServer linked with a GPL AGG I *think* you are
required to provide MapServer under GPL terms.  Because there is no one
contributor who has rights to alter MapServer licensing terms I believe
the distributor would be in violation of the AGG GPL terms.

> Does that also then mean that any users who are bundling MapServer
> today in proprietary solutions could not do so with this build?

There is some ambiguity as you "move up the stack" as to whether the GPL
terms still apply.  For instance, a web front end that involved a GPL
AGG enabled MapServer via http/wms would likely be ok.  But arguable a
MapScript application would have to be distributed under GPL.

> Does this mean that if other 3rd party proprietary components are
> included in a distributed build that they too would be subject to
> availability via GPL?

If they are considered to be linked with AGG, and if they redistribute
them, then yes.

> If the above are true - I can think of a few pretty significant
> instances where this decision could be pretty big problems.

This is my conclusion.

While end users who don't redistribute their binaries (including those
providing proprietary web based services) should be ok, anyone who has
to distribute software needs to think very carefully before distributing
GPL AGG enabled binaries.

We could request some specific legal advice on this topic, but think it
is clear that MapServer needs a non-GPL AGG fork that can be dropped in
and used for distributors even if lags the mainstream AGG.

Best regards,
--
---------------------------------------+--------------------------------
---------------------------------------+------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org

[Dave McIlhagga]

Good summary Frank.


I realize this is a bit of a tangent from the original discussion --  
but does anyone have an idea of where the line is vis-a-vis PostGIS  
since it too is GPL? ie. if a proprietary solution built with  
MapScript is distributed built on MapServer today AND PostGIS --  
would that be in violation of the license?

Dave



On 24-Oct-07, at 10:58 AM, Frank Warmerdam wrote:

> Dave McIlhagga wrote:
>> Ok - let me rephrase that. Does that mean when distributing  
>> MapServer with AGG 2.5, in that instance all of that code  
>> (including the MapServer source code) would have to be distributed  
>> via a GPL license.
>
> Dave,
>
> If one distributes MapServer linked with a GPL AGG I *think* you are
> required to provide MapServer under GPL terms.  Because there is no
> one contributor who has rights to alter MapServer licensing terms I
> believe the distributor would be in violation of the AGG GPL terms.
>
>> Does that also then mean that any users who are bundling MapServer  
>> today in proprietary solutions could not do so with this build?
>
> There is some ambiguity as you "move up the stack" as to whether
> the GPL terms still apply.  For instance, a web front end that
> involved a GPL AGG enabled MapServer via http/wms would likely be
> ok.  But arguable a MapScript application would have to be
> distributed under GPL.
>
>> Does this mean that if other 3rd party proprietary components are  
>> included in a distributed build that they too would be subject to  
>> availability via GPL?
>
> If they are considered to be linked with AGG, and if they
> redistribute them, then yes.
>
>> If the above are true - I can think of a few pretty significant  
>> instances where this decision could be pretty big problems.
>
> This is my conclusion.
>
> While end users who don't redistribute their binaries (including
> those providing proprietary web based services) should be ok, anyone
> who has to distribute software needs to think very carefully before
> distributing GPL AGG enabled binaries.
>
> We could request some specific legal advice on this topic, but  
> think it
> is clear that MapServer needs a non-GPL AGG fork that can be dropped
> in and used for distributors even if lags the mainstream AGG.
>
> Best regards,
> --
> ---------------------------------------
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam@...
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http://
> osgeo.org

[Frank Warmerdam]

Dave McIlhagga wrote:
> Ok - let me rephrase that. Does that mean when distributing MapServer
> with AGG 2.5, in that instance all of that code (including the MapServer
> source code) would have to be distributed via a GPL license.

Dave,

If one distributes MapServer linked with a GPL AGG I *think* you are
required to provide MapServer under GPL terms.  Because there is no
one contributor who has rights to alter MapServer licensing terms I
believe the distributor would be in violation of the AGG GPL terms.

> Does that also then mean that any users who are bundling MapServer today
> in proprietary solutions could not do so with this build?

There is some ambiguity as you "move up the stack" as to whether
the GPL terms still apply.  For instance, a web front end that
involved a GPL AGG enabled MapServer via http/wms would likely be
ok.  But arguable a MapScript application would have to be
distributed under GPL.

> Does this mean that if other 3rd party proprietary components are
> included in a distributed build that they too would be subject to
> availability via GPL?

If they are considered to be linked with AGG, and if they
redistribute them, then yes.

> If the above are true - I can think of a few pretty significant
> instances where this decision could be pretty big problems.

This is my conclusion.

While end users who don't redistribute their binaries (including
those providing proprietary web based services) should be ok, anyone
who has to distribute software needs to think very carefully before
distributing GPL AGG enabled binaries.

We could request some specific legal advice on this topic, but think it
is clear that MapServer needs a non-GPL AGG fork that can be dropped
in and used for distributors even if lags the mainstream AGG.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

[Doyon, Jean-Francois-2]

PostgreSQL is released under a BSD license ... So you'd be safe, because
the binary components that you'd include with MapServer (as in MS4W for
example) would only inculde PostgreSQL stuff, and nothing PostGIS
specific.  PostGIS lives on the server only (AFAIK?).

If you were to distribute server-side components (a custom PostgreSQL +
PostGIS bundle?) then you might have some problems ...

J.F.

-----Original Message-----
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV@...]
On Behalf Of Dave McIlhagga
Sent: October 24, 2007 10:36
To: MAPSERVER-DEV@...
Subject: Re: [UMN_MAPSERVER-DEV] MapGuide fork of AGG

Good summary Frank.


I realize this is a bit of a tangent from the original discussion -- but
does anyone have an idea of where the line is vis-a-vis PostGIS since it
too is GPL? ie. if a proprietary solution built with MapScript is
distributed built on MapServer today AND PostGIS -- would that be in
violation of the license?

Dave



On 24-Oct-07, at 10:58 AM, Frank Warmerdam wrote:

> Dave McIlhagga wrote:
>> Ok - let me rephrase that. Does that mean when distributing MapServer

>> with AGG 2.5, in that instance all of that code (including the
>> MapServer source code) would have to be distributed via a GPL
>> license.
>
> Dave,
>
> If one distributes MapServer linked with a GPL AGG I *think* you are
> required to provide MapServer under GPL terms.  Because there is no
> one contributor who has rights to alter MapServer licensing terms I
> believe the distributor would be in violation of the AGG GPL terms.
>
>> Does that also then mean that any users who are bundling MapServer
>> today in proprietary solutions could not do so with this build?
>
> There is some ambiguity as you "move up the stack" as to whether the
> GPL terms still apply.  For instance, a web front end that involved a
> GPL AGG enabled MapServer via http/wms would likely be ok.  But
> arguable a MapScript application would have to be distributed under
> GPL.
>
>> Does this mean that if other 3rd party proprietary components are
>> included in a distributed build that they too would be subject to
>> availability via GPL?
>
> If they are considered to be linked with AGG, and if they redistribute

> them, then yes.
>
>> If the above are true - I can think of a few pretty significant
>> instances where this decision could be pretty big problems.
>
> This is my conclusion.
>
> While end users who don't redistribute their binaries (including those

> providing proprietary web based services) should be ok, anyone who has

> to distribute software needs to think very carefully before
> distributing GPL AGG enabled binaries.
>
> We could request some specific legal advice on this topic, but think
> it is clear that MapServer needs a non-GPL AGG fork that can be
> dropped in and used for distributors even if lags the mainstream AGG.
>
> Best regards,
> --
> ---------------------------------------
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam@...
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http://
> osgeo.org

[thomas bonfort]

On 10/24/07, Frank Warmerdam <warmerdam@...> wrote:

> If one distributes MapServer linked with a GPL AGG I *think* you are
> required to provide MapServer under GPL terms.  Because there is no
> one contributor who has rights to alter MapServer licensing terms I
> believe the distributor would be in violation of the AGG GPL terms.

would that also include distro packages that ship debs,rpms,insert
your package here, of agg enabled mapserver if their bundled version
of agg is 2.5 ?

tb

[Doyon, Jean-Francois-2]

Here's a FAQ, which answers this question among many:

http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL

So technically, yes, if you build an RPM of MapServer that links to AGG
2.5 (from say, another RPM), MapServer must be GPL.

J.F.

-----Original Message-----
From: UMN MapServer Developers List [mailto:MAPSERVER-DEV@...]
On Behalf Of thomas bonfort
Sent: October 25, 2007 05:39
To: MAPSERVER-DEV@...
Subject: Re: [UMN_MAPSERVER-DEV] MapGuide fork of AGG

On 10/24/07, Frank Warmerdam <warmerdam@...> wrote:

> If one distributes MapServer linked with a GPL AGG I *think* you are
> required to provide MapServer under GPL terms.  Because there is no
> one contributor who has rights to alter MapServer licensing terms I
> believe the distributor would be in violation of the AGG GPL terms.

would that also include distro packages that ship debs,rpms,insert your
package here, of agg enabled mapserver if their bundled version of agg
is 2.5 ?

tb

[Frank Warmerdam]

thomas bonfort wrote:
> On 10/24/07, Frank Warmerdam <warmerdam@...> wrote:
>
>> If one distributes MapServer linked with a GPL AGG I *think* you are
>> required to provide MapServer under GPL terms.  Because there is no
>> one contributor who has rights to alter MapServer licensing terms I
>> believe the distributor would be in violation of the AGG GPL terms.
 >
> would that also include distro packages that ship debs,rpms,insert
> your package here, of agg enabled mapserver if their bundled version
> of agg is 2.5 ?

Thomas,

Yes.  The Debian GIS team is currently looking at statically linking
AGG 2.4 into MapServer because the packaged version of AGG on Debian is
2.5 (ie. GPL licensed).

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

[Paul Spencer-2]

Clarification for those of you not following the mapguide internals  
list, Tom Fukushima announced yesterday that they are not actually  
forking AGG because Thomas found a way that MapGuide could use AGG  
without making any modifications (at this point).  They will be  
sucking in a copy of AGG as they do with all other 3rd party  
libraries but will not be maintaining local changes as a fork.

However, the general opinion now seems to be that the original  
maintainer, Maxim Shemanarev, essentially created a fork in the  
community at the time he relicensed AGG as GPL.  In practical terms,  
Maxim has been committing to the 2.4 code as recently as 2007/09/05.  
The 2.5 code was initially committed on 2006/10/09 and has had two  
commits since it was created which seem to be keeping the two code  
bases in sync only.  Personally, I think he was forced to create a  
relicensed version of his code base when he signed with Scaleform and  
has found a creative way to deal with it.  Unfortunately, he has  
received a lot of bashing from the community for it because he seems  
unable to speak about the change (NDA anyone?).

I think that as long as 2.4 meets our needs and there is no  
development going into 2.5, there is no problem.  The problems will  
start if 2.5 gets some development (that we need) or we (by which I  
mean the geo community) have improvements to make and no where to put  
them.

Cheers

Paul

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer@...    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+