« Return to Thread: Fwd: escada and jgcs
Re: escada and jgcs
by Jose Orlando Pereira
::
Rate this Message:
On Friday 21 September 2007, buzz lightyear wrote:
> Thanks for the reference to the paper - when using jxta I'm having to take
> into account node failure and clients are generally aware of which nodes
> have the database - jxta is pretty good at discovery. This idea is to
> ensure that clients connect to the 'best' connection at the time an
> operation is invoked. The 'load balancing' is effectively taking place on
> the client side.
I understand. You should definitely take a look at the paper and think about
the best solution for you: Enforcing some client affinity or using ESCADA in
the proposed safe mode, which does however have an impact in read only
transactions.
> The license is an issue do to the fact that customers may construct
> standalone applications using my libraries, your libraries and all the
> other libraries which they might pass onto their clients. Some customers
> may not not want to make public the source of their application. Other
> customers may be overlook the gpl issue, distribute an application without
> source and be unaware that they are contravening escadas license terms, and
> as a consequence be liable. All of the libraries I'm using, including my
> own (once they are ready), hibernate, jboss, jxta, derby etc have at worst
> the lgpl license, and at best the apache license.
>
> I dearly hope we can resolve this licensing issue.IANAL, but the client application cannot be considered a derived work from
ESCADA and thus is exempt from any licensing restrictions imposed by ESCADA.
Let me try to explain this.
Actually, this is a _major_advantage_ of the GORDA approach: replication is
implemented by intercepting requests within the DBMS and not within the
client application. This allows the client application (ditto JBoss,
hibernate) to link to the original unmodified JDBC driver. No linking to
ESCADA code is done. Besides technically interesting this should also solve
any licensing issues.
Licensing issues might arise only when linking ESCADA to the DBMS, since the
resulting replicated DBMS is a derived work from both ESCADA and the DBMS.
This is why we chose GPLv3, which unlike GPLv2 is compatible with Apache 2.0
license, hence with Derby or Sequoia. There are also no problems when linking
GPLv3 with modified-BSD licenses, hence with PostgreSQL.
Moreover, like Apache License 2.0, GPLv3 should also be safer when
redistributing code for money regarding possible patent claims.
I hope this clears the licensing issue,
--
Jose Orlando Pereira
> Thanks for the reference to the paper - when using jxta I'm having to take
> into account node failure and clients are generally aware of which nodes
> have the database - jxta is pretty good at discovery. This idea is to
> ensure that clients connect to the 'best' connection at the time an
> operation is invoked. The 'load balancing' is effectively taking place on
> the client side.
I understand. You should definitely take a look at the paper and think about
the best solution for you: Enforcing some client affinity or using ESCADA in
the proposed safe mode, which does however have an impact in read only
transactions.
> The license is an issue do to the fact that customers may construct
> standalone applications using my libraries, your libraries and all the
> other libraries which they might pass onto their clients. Some customers
> may not not want to make public the source of their application. Other
> customers may be overlook the gpl issue, distribute an application without
> source and be unaware that they are contravening escadas license terms, and
> as a consequence be liable. All of the libraries I'm using, including my
> own (once they are ready), hibernate, jboss, jxta, derby etc have at worst
> the lgpl license, and at best the apache license.
>
> I dearly hope we can resolve this licensing issue.
ESCADA and thus is exempt from any licensing restrictions imposed by ESCADA.
Let me try to explain this.
Actually, this is a _major_advantage_ of the GORDA approach: replication is
implemented by intercepting requests within the DBMS and not within the
client application. This allows the client application (ditto JBoss,
hibernate) to link to the original unmodified JDBC driver. No linking to
ESCADA code is done. Besides technically interesting this should also solve
any licensing issues.
Licensing issues might arise only when linking ESCADA to the DBMS, since the
resulting replicated DBMS is a derived work from both ESCADA and the DBMS.
This is why we chose GPLv3, which unlike GPLv2 is compatible with Apache 2.0
license, hence with Derby or Sequoia. There are also no problems when linking
GPLv3 with modified-BSD licenses, hence with PostgreSQL.
Moreover, like Apache License 2.0, GPLv3 should also be safer when
redistributing code for money regarding possible patent claims.
I hope this clears the licensing issue,
--
Jose Orlando Pereira
smime.p7s (2K) « Return to Thread: Fwd: escada and jgcs
| Free embeddable forum powered by Nabble | Forum Help |
