Hey Sendoro,

Unfortunately that's not good enough.  I agree with your
interpretation of LGPL, but the ASF is, as a foundation, taking a more
conservative stance.  Apache projects are not allowed to depend on
LGPL libraries.  The ASF choses to be cautious on this matter, because
many companies depend on code produced by the ASF.

This sequence of events would be bad:
1.) We include LGPL software in our release.
2.) Our code, including the LGPL dependency is included in proprietary
code of CompanyOmega
3.) Some judge somewhere decides that the "firewall" separating our
code from the LGPL isn't strong enough to call prevent the viral
aspects of LGPL from taking effect.
4.) CompanyOmega's proprietary code is now all open source and they go
out of business.

It's not a likely sequence, but because of the size of the negative
outcome, we avoid it by not including LGPL (or any other Category X
software) in our releases.

We will have to remove any dependencies to CatX software before we
release Fineract CN.

Best Regards,
Myrle

(By the way, the Hibernate Validator, unlike the Hibernate JPA
implementation, is released under the Apache V2 license
https://github.com/hibernate/hibernate-validator/blob/master/license.txt)


On Sun, Apr 15, 2018 at 2:55 PM, Sendoro Juma <sendoro@singo.africa> wrote:
> Dear All,
>
> I believe this can resolve the issue with MariaDB client
>
> -------------
> Licenses used by MariaDB
> MariaDB is distributed under the GPL license, version 2.
>
> The MariaDB client libraries for C, Java and ODBC are distributed under the 
> LGPL license, version 2.1 or later. The LGPL license allows you to distribute 
> these MariaDB client libraries freely with any application.
>
> The MariaDB client library included with the MariaDB server is also GPL 
> version 2, but has a FLOSS exception that allows you to combine it with most 
> other open source software, without conflicting with their license, even if 
> that license is incompatible with the GPL. We do however recommend you to use 
> the new client libraries for any non-GPL application.
>
> About FLOSS exception.... #Below Apache Software License 2.0 is included.
>
>
> FLOSS License List
>
> License name Version(s)/Copyright Date
> Academic Free License 2.0
> Apache Software License 1.0/1.1/2.0
> Apple Public Source License 2.0
> Artistic license From Perl 5.8.0
> BSD license "July 22 1999"
> Common Development and Distribution License (CDDL) 1.0
> Common Public License 1.0
> Eclipse Public License 1.0
> GNU Library or "Lesser" General Public License (LGPL) 2.0/2.1
> Jabber Open Source License 1.0
> MIT license (As listed in file MIT-License.txt) ---
> Mozilla Public License (MPL) 1.0/1.1
> Open Software License 2.0
> OpenSSL license (with original SSLeay license) "2003" ("1998")
> PHP License 3.0
> Python license (CNRI Python License) ---
> Python Software Foundation License 2.1.1
> Sleepycat License "1999"
> University of Illinois/NCSA Open Source License ---
> W3C License "2001"
> X11 License "2001"
> Zlib/libpng License ---
> Zope Public License 2.0
>
>     Due to the many variants of some of the above licenses, we
>     require that any version follow the 2003 version of the Free
>     Software Foundation's Free Software Definition
>     (http://www.gnu.org/philosophy/free-sw.html) or version 1.9 of
>     the Open Source Definition by the Open Source Initiative
>     (http://www.opensource.org/docs/definition.php).
>
>  3. Definitions
>
>       a. Terms used, but not defined, herein shall have the
>          meaning provided in the GPL.
>       b. Derivative Work means a derivative work under copyright
>          law.
>
>  4. Applicability: This FLOSS Exception applies to all Programs
>     that contain a notice placed by MySQL AB saying that the
>     Program may be distributed under the terms of this FLOSS
>     Exception. If you create or distribute a work which is a
>     Derivative Work of both the Program and any other work
>     licensed under the GPL, then this FLOSS Exception is not
>     available for that work; thus, you must remove the FLOSS
>     Exception notice from that work and comply with the GPL in all
>     respects, including by retaining all GPL notices. You may
>     choose to redistribute a copy of the Program exclusively under
>     the terms of the GPL by removing the FLOSS Exception notice
>     from that copy of the Program, provided that the copy has
>     never been modified by you or any third party.
> --------------------------
>
> ----- Original Message -----
> From: "Sendoro Juma" <sendoro@singo.africa>
> To: "dev" <dev@fineract.apache.org>
> Sent: Sunday, April 15, 2018 2:41:50 PM
> Subject: Re: Moving Towards Apache Compliance for Fineract CN: Hibernate to 
> OpenJPA Migration.
>
> There are these comments though....
>
> GNU GPL/GNU Affero GPL
> Discussion of Apache License v2.0 and GPL Compatibility merits a separate 
> page. http://www.apache.org/licenses/GPL-compatibility.html
>
> GNU LGPL
> The LGPL is ineligible primarily due to the restrictions it places on larger 
> works, violating the third license criterion.
> Special exceptions to the GNU GPL
> Some copyright holders have licensed their works under the GPL with special 
> exceptions. Although these exceptions may appear to be addressing the 
> restrictions disallowed by the ASF's first and second license criteria, the 
> exceptions may only apply to software not "derived from or based on" the 
> covered work. This references terms defined in the GPL that include works 
> that "use" or "contain" the work.
>
> ----- Original Message -----
> From: "Sendoro Juma" <sendoro@singo.africa>
> To: "dev" <dev@fineract.apache.org>
> Sent: Sunday, April 15, 2018 2:38:45 PM
> Subject: Re: Moving Towards Apache Compliance for Fineract CN: Hibernate to 
> OpenJPA Migration.
>
> LPGL 2.1 is categorically included as not compliant.
>
> WHICH LICENSES MAY NOT BE INCLUDED WITHIN APACHE PRODUCTS?
> Binary Code License (BCL)
> Special exceptions to the GNU GPL (e.g. GNU Classpath)
> GNU GPL 1, 2, 3
> GNU LGPL 2, 2.1, 3
> GNU Affero GPL 3
> ....
> ....
> ....
>
>
> ----- Original Message -----
> From: "Awasum Yannick" <awa...@apache.org>
> To: "dev" <dev@fineract.apache.org>
> Sent: Saturday, March 10, 2018 6:29:51 PM
> Subject: Moving Towards Apache Compliance for Fineract CN: Hibernate to 
> OpenJPA Migration.
>
> Hello Everyone,
>
> I am hoping we could take some time to discuss and come up with approaches
> for achieving full Apache compliance on the Fineract CN project.
> I think there are still dependencies on Fineract CN which need some
> attention in terms of checking the licenses and making sure they are
> compliant with the Apache license.
>
> To that end, I began looking at the Microservices and checking the license
> of each dependency in accordance with this list:
> https://www.apache.org/legal/resolved.html
>
> Within the mariadb component, i realized that the
> *mariadb-java-client* uses LGPL 2.1
>  (Is this compliant with the Apache license? ).
>
> I don't know if there are other dependencies which are not Apache
> compliant like the known case: Hibernate.
>
> To migrate Fineract CN from using Hibernate to using OpenJPA, we might do
> the following:
>
> * Replace the Hibernate Validator with something more Apache compliant like
> javax.validation.*
> or a corresponding OpenJPA library if such exists.
>
> * Configure and set the LocalContainerEntityManagerFactoryBean ( within
>
> MariaDBJavaConfiguratio
> n )
>
> to use the right JpaVendorAdapter ( OpenJPAs own equivalent of
> HibernateJpaVendorAdapter ) within mariadb component. And also the set the
> right properties for OpenJPA ( peristence unit etc ).
>
> I will like more experienced developers/architects in the community weigh
> in and provide additional details which will enable the gradual migration
> from Hibernate to OpenJPA and to get other non-compliant dependencies
> migrated too. From this point, volunteers can pick this up and make
> progress.
>
>
> Thanks.
> Awasum Yannick.

Reply via email to