Dizkus

Hi -

Apologies if this is not the right place to discuss this.

A client of ours has asked us to build a bespoke application for them. Instead of starting from scratch, we are thinking of using PostNuke as an underlying base framework. We will still need months of work and several dedicated modules to build the application. I would thus be extremely grateful if someone [particularly from the PostNuke Foundation] could clarify few of my doubts with regards to licensing.

Our client would eventually offer the application as a paid service on the web in an Application Service Provider model. They have no desire to re-sell or distribute the code but are more interested in offering a web-based service (based on the modules) which facilitates a market sector requirement.

1. If we use PN as the base framework, due to it being GPL, are we obliged to release and/or give away the source code of the modules to everyone ?

2. What rights will our client have over the modules that we have written ?

3. Most importantly, will our client be legally allowed to charge subscribers a fee for application use ?

Note: All copyright notices in the PostNuke source code will ofcourse be retained untouched.

Would be extremely grateful if someone could clarify the above as open source licensing seems to be getting too complicated to understand. We obviously do not wish to invest months of time and money in development, if its going to cause a problem later.


Thanks
migs

No, in no way are you required to do this.



Well, full rights unless you release it, and if you ever release it how it has to be licensed depends on your take on the GPL. While some people will say that you have to license your code as GPL because PostNuke is GPL, others disagree. The PostNuke foundation took advice on this some time ago now, and PostNuke's stance is that non-GPL modules are fine, but this is just a suggestion and not to be taken as legally sound.



Yes.



This is pretty much the only requirement of the GPL in your usage.


Hope that helps a little bit :)

--
Regards,
Simon

itbegins.co.uk - Zikula Consulting

Please read the Support Guide

Thank you very much for your prompt and informative reply.

We will now get down to the job of building the application using PostNuke as the base framework. :)


Kind regards
migs

Great, please let us know how it goes...

--
Regards,
Simon

itbegins.co.uk - Zikula Consulting

Please read the Support Guide

I would strongly suggest pulling a copy of 0.8 from the cvs notice as it has lots of new OO technology. Also watch out at mods.postnuke.com as I will be running a tutorial soon on the new methods.

Awsome, OO is still a bit of a mystery to me and understanding the new library is hurting my head a little. Even though I can see the benefit, implementation is a bit harry on the novice.

--
Under Construction!

Possibly I'll say something sacreligious about OO programming here, but in order to use the OO libraries to write your modules, you really dont need to know muct other than the arguements to put in and what to expect out. There's far too much jargon and buzz words surrounding this topic. For the post part we're dealing with static objects which amount to nothing more than functions organized into groups. Anyhow, regardless of the rights and wrongs of what I have said (cos I dont really know), I intend to provide a set of tutorials in the form of modules that will be easy to understand and leave existing module authors wondering why they had to jump though so many hoops in the past.

Drak

I agree with Drak - and incase you have difficulty with the notion of static objects take a look at this PHP manual page: http://uk2.php.net/manual/en/language.oop5.paamayim-nekudotayim.php

--
Regards,
Simon

itbegins.co.uk - Zikula Consulting

Please read the Support Guide

Given that the object-library is my baby, allow to explain in a bit more detail:

1) Using the DBUtil stuff (or converting existing code to DBUtil): this is almost mechanic and reduces most your SQL down to a single line of code. It also supports auto-joins and other advanced functionality but the basic fact is that it's a more efficient (and easier and this less error-prone) way to write your SQL without having to worry about generating SQL queries manually. You can apply such changes to an existing module without changing the logic/flow. In our conversions of the core code, this resulted in code savings of about 1/3.

2) The other part is actually using the object model (and this is where the whole OO stuff such as inheritance, function overriding, etc comes in). This is a much greater change to your program logic but it can enable you to access/handle all your objects through a single consistent object interface which means that you can have 1 edit, view, etc function for all objects. Constructing a persistent object (ie: an object which knows how to load/save itself to/from the DB) can take as little as writing the constructor (about 5-10 lines of code) which translates to massive code savings (and thus increased productivity) when building modules this way. Since this part is significantly more complex than the basic DBUtil usage, I would expect adoption of the object layer to be slower process, used mainly for new module development. You should really understand the basics of OO programming in order to make efficient use of the techniqes the Object Model enables ...

If you have specific questions about this stuff you can ask them here but your chances of me seeing it are greatly improved if you post them on the Openstar forums (http://openstar.postnuke.com ...

Greetings
--> R