9
riaanvdb seemed pretty accurate in saying that if the addon doesn't include gnu/gpl code, then it doesn't have to be licensed as gnu/gpl
it may depend on the system, but as long as it's own code is separate and pure of gnu/gpl code, then from what i have seen, it can be re-licensed
i know many of the nuke developers that charge for their modules, and restricting the license, are also making sure that their scripts do not include gnu code. they often have to recreate the wheel on some functions, but it's their code straight-up
where i would think the line would get muddled, is in using the db abstraction layer provided with the CMS, i wonder if that is considered to be using gnu/gpl code and thus requiring that the module be gnu/gpl as well.
php itself is gnu/gpl, isn't it? many from-scratch restricted license applications are made using php, and using php functions, so following that model, i would think that using a function provided by the external shell doesn't require a gnu/gpl license, and as such, modules *can* be developed with a restricted license. they just can't copy/duplicate code from the XOOPS core, i guess.
dunno, i'm no authority, but looking at real-world examples, i don't see how a module would be required to be gnu/gpl, if it follows proper guidelines
what do you guys think?