[Geoprisma-dev] Licensing was: MapFish-trunk in external

[Stephen Woodbridge]

Yves Moisan wrote:
>>> Not really.  The Modified BSD licence we are using is compatible with
>>> the GPL MapFish is using :
>>> http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
>> OK, Daniel, please look into this issue.
>>
>> I am be wrong, but I think your are not interpreting this correctly.
>>
>> What the above says is that these licenses do not contradict the GPL 
>> licenses.
>>
>> So if you mix GPL code and BSD code you get ............. GPL code.
>> That works great for them but not for the people that want BSD licenses.
> 
> Stephen,
> 
> It may be that the GPL is viral, but there is an issue to be reckoned
> with by all projects that use either MapFish (the PSC will have to take
> action on the MF licensing soon ...) or ExtJS (like GeoExt).  GeoPrisma
> uses ... both.
> 
> The ExtJS folks allow the use of their library under the GPL for all
> projects that have "open source" licences compatible with the GPL (or
> something like that; their exception clause is easily googled).  For all
> other uses, you have to buy an ExtJS license.  I don't know what to tell
> you at this point, but a license really is in the hands of the beholder.
> Those who "exercise" the MapFish license are well the MapFish project.
> they are the ones who can sue you if you don't use Mapfish properly.
> Odds are in this community of interrelated projects this won't happen.
> But you are right there is a potential for trouble.  

I think that this is the point that needs to be cleared up. If you say 
you are releasing a product under BSD, then you have some obligation to 
to insure that it has a clear license under those terms.

There are a few ways to do this.

1) do not bring any GPL or other code that has a license that is 
incompatible with BSD or whatever you choice to release it under.

2) if you want to incorporate code that is released under an 
incompatible license that you secure a relicensed copy for inclusion in 
the project and the this is appropriately documented in svn or with the 
releases so there is no future ambiguity about it.

3) if some parts of the product are separable from the main product that 
you might include them under a different license ... but this is getting 
muddy real fast. Now you probably have to release you product under a 
dual license so you have something like core == (BSD or GPL), and extra 
== (GPL only), but all this adds confusion to the users of the library 
in terms of what I can and can not use in this situation or that situation.

4) maybe something else I have not thought about.

If ever there was an area of a project that needs to follow the K.I.S.S. 
rule this is one of them.

>> GPL licenses are like a virus, any thing you mix with it becomes GPL.
>> There are some licenses that you can NOT mix with GPL because they 
>> require actions the are GPL incompatible.
>>
>> If I build an GeoPrisma application for a client and he mixes it with 
>> his code, he does not what all his code becoming GPL and then has to 
>> release his proprietary code as GPL. So GeoPrisma needs to be GPL clean!
> 
> IIRC, if he uses his code "for himself" he does not have to give his
> mods back to the community.  If your customer starts deploying or
> vending his solution, then there's an issue.

Right, but they want to build a software as a service site, so this 
would be problematic. And many clients look at software as a corporate 
asset that has value that increases the value of the company because it 
can be sold or relicensed, etc. It is because of these reason the 
companies want nothing to do with GPL, because it is designed to 
prevents people from doing that. Regardless of the reason, most coporate 
lawyer will prevent them for using GPL'd code. So not corporate clients 
really cuts down on the revenue stream for people like us.

>> You should not bring anything that is GPL into GeoPrisma which is under 
>> a BSD license or it will make GeoPrisma into a GPL license.
> 
> Saying that would be like saying "abandon MapFish and GeoExt" which
> makes no sense now at least in terms of our codebase.  The only thing we
> can do is work on the MF license : maybe add an exception for GPL
> compatible licenses ?  Remember : GeoExt has a modified BSD license, but
> it uses ExtJS behind under the GPL *with* the explicit exception clause
> provided by the ExtJS folks.  So if anyone were to turn a GeoExt
> application into some proprietary app, there would be a violation of
> ExtJS's exception clause, I believe.  We'll see with the MapFish PSC in
> January.

You have to get these guys to allow you to use it under a BSD or maybe a 
modified BSD if you if you want to relicense your code or (and I hope 
you don't) relicense to GPL.

Whatever you decide from a project point of view is fine, but just be 
clear in the communication and implementation of licensing. Then others 
can decide based on functionality, licensing, and whatever else floats 
their boats.

I'm +1 for BSD, -1 for GPL, willing to look at other choices.

This is not to start a licensing war, I just can't use GPL for most of 
my clients. If you can live with GPL it is great for some people.

Cheers,
   -Steve

> Cheers,
> 
> Yves
> 
> 
>> One of the OpenSource selection criteria that my clients put on me is NO 
>> GPL code.
>>
>> That means if someone has a cool GPL thingy that you would like to have 
>> in GeoPrisma then you need to recreate the functionality in clean code 
>> that does not use the GPL'd code.
>>
>> This unfortunately means that you can not use mapfish code.
>>
>> There is one possible angle to this that might let you get by that is it 
>> might be possible to convince people that the client JS code can be GPL 
>> as long as the service code is BSD. But it muddies the water and makes 
>> it harder to convince people to use the product. And you run the risk of 
>> something innocently polluting you server side code with something that 
>> is GPL and came along with some client-side piece. I am not a lawyer.
>>
>> If you need help or another opinion Frank W. is probably someone that 
>> understands this pretty well.
>>
>> My 2 cents,
>>    -Steve
>>
> 
>