On 3/3/07, fabien <[EMAIL PROTECTED]> wrote:

You can develop a proprietary module for Tiny ERP. It's legal and we (Tiny) 
support that.
The restriction of the GPL about this is that you can not distribute Tiny ERP 
packaged with your module. But if you package it separetly, it's not a problem.


no, that's not the restriction.  take a look:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

"Mere aggregation of two programs means putting them side by side on
the same CD-ROM or hard disk. We use this term in the case where they
are separate programs, not parts of a single program. In this case, if
one of the programs is covered by the GPL, it has no effect on the
other program."

so mere aggregation would be ok... but is a module specifically
designed for tiny "mere aggregation"?

"By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs.
So when they are used for communication, the modules normally are
separate programs. But if the semantics of the communication are
intimate enough, exchanging complex internal data structures, that too
could be a basis to consider the two parts as combined into a larger
program."

so a module, specifically designed *for* tiny erp (a gpl work), using
/ sharing intimate data structures, would be easily considered a
derivative work.


the *key* question here is: does the module alone have any use or
function without tiny erp?  of course not, it can't be a "program" by
itself!  then it's clearly a derivative work, and the two form a
single program when combined with tiny erp.


oh and i had forgotten this very specific question!  " If I add a
module to a GPL-covered program, do I have to use the GPL as the
license for my module? "
http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense

... and its very specific answer "The GPL says that the whole combined
program has to be released under the GPL. So your module has to be
available for use under the GPL".


so a module designed for tiny erp is clearly a derivative working, and
making it non-gpl is clearly violating the gpl.  but as the (only?)
copyright holder, tiny belgium can choose not to enforce the gpl on
people who violate it.

you can do that by just promising you won't, or in the legally clear
way, by adding "linking exceptions" for specific modules (you formally
allow certain non-gpl piece of software to dinamically link with tiny
erp, without breaking the gpl).
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface

you could do this with certain modules only (your partners?  modules
you think are the most useful?), but if you plan to do it with all of
them, why not choose the lgpl?  you wouldn't have to grant linking
exceptions every other day.


but if you ask me (i know you didn't!), the gpl is the perfect license
for tiny: modules developed *specifically* for tiny erp (derivative
works) must remain free for all, which guarantees the whole ecosystem
will benefit.  and people can still link it with proprietary systems
that the company already had, because those are clearly not derivative
works.


--
Santiago Roza
[EMAIL PROTECTED]
_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users

Reply via email to