ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | enhydra List | Febuary 1999 Index

<--  Date Index  --> <--  Thread Index    

Enhydra: Licensing policy


Hi,

The recent "Moving towards a common goal" thread pointed out a major
problem: how can we use software packages protected by different
licensing terms in order to build a large application server? This
problem has two main parts: the first one is related to legal issues and
the second one to strategic choices.

I may be wrong, but it seems that legal issues could be solved if each
part of the complete software framework keeps its original license. For
example, if the framework is based on Enhydra, the framework keeps the
BSD-like license but still can use external libraries having their own
respective licenses (LPGL, LPL, ...). Developers would just not have to
mix code coming from different software packages having different
licenses.

This would restrict the ability of the complete package to be
distributed under a very liberal license like the BSD license (allowing
binary-only distributions), but it would allow developers to quickly get
access to features not already available on the main framework. If a
binary-only distribution policy becomes necessary for someone, this one
would just have to rewrite by himself pieces of code provided as
external libraries protected by licenses not allowing such a
distribution policy.

This strategy would allow Enhydra developers to use GPLd and LGPLd
software (like GNU-JSP), classes from other application servers (the
org.locomotive.loco.perm permission management package provided by
Locomotive is very cleanly coded and well documented) or XML-related
software licensed by IBM under the alphaworks license (the most powerful
and most complete java-based XML parser currently available).

Nevertheless, such a move must respect strategic choices made by Lutris.
Developers could take currently available codes from
Enhydra/Hamilton/Locomotive and start a the_best_app_server.org, but I'm
sure it would be a bad move, for two reasons: it would not respect the
work done by these application servers developers and it would prevent
them from working in synergy with those developers, who can bring more
than raw code: experience...

Enhydra, Hamilton and Locomotive are initially based on very different
concepts, on the bottom as on the top. On the bottom, they do not handle
applications in the same way. On the top, they provide very different
schemes to handle presentation. Then these application servers can not
be mixed. A big choice will have to be made by developers between the
three (and may be more in a couple of weeks...) application servers.
Every server will have its own development team and they will compete on
the Open Source field. And it may not be a bad thing: Open Source is
gaining a strong acceptance and many highly skilled developers are
joining this movement. Ideas and implementations will be confronted and
only the best concepts will remain.

Do you at Lutris see things in that way and should developments at
enhydra.org be made using such a strategy?

Best regards

Ismaël Ghalimi

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
with the text "unsubscribe enhydra" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-enhydra@xxxxxxxxxxxx




<--  Date Index  --> <--  Thread Index    

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.