MapGuide fork of AGG

Dave McIlhagga dmcilhagga at DMSOLUTIONS.CA
Wed Oct 24 09:37:29 EDT 2007 

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 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/ |
>>>>> +----------------------------------------------------------------- 
>>>>> +
>>>>>
>

More information about the mapserver-dev mailing list