43 lines
1.8 KiB
Raw Permalink Normal View History

2013-03-22 01:40:56 -07:00
EFL comes with several licences. Different shared libraries are
covered by different licenses, and are distributed here as an
aggregation with a single build system. Listed below are the library/project
names and the license file covering it. Note that this license would
cover all of the source invovled in each project (src/lib/PROJECT,
src/modules/PROJECT, src/bin/PROJECT data/PROJECT) unless specifically
noted otherwise (eg epp in edje or lz4, libunibreak etc.), so please
refer to these imported project sources for details (but be aware that
the licensing of such libraries is compatible with the libraries that
use them and is not more restrictive).
evil: licenses/COPYING.BSD
eina: licenses/COPYING.LGPL
emile: initial introduction of Emile. The intent of Emile is to be the common layer for serialisation, compression and ciphering. It will expose the library we currently use internally to an easier use from the outside (like gcrypt and lz4). It should improve portability. Instead of pushing JSON, XML and what's not to Eina, I do think that they will fit better in Emile. As for the naming of Emile, you will need to be French and say : "Un quoi ?" "Un serializer !" Regarding why it is put there in the stack. Right now there is two users of compression (eet and terminology), two users of cipher library (eet and ecore_con) and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...). So the choice was quite simple, it needed to be below Eet. Now it could have been on top of Eo or integrated into Eina. One of the use case I am thinking of, is to compress Eo object when a canvas get hidden/minized. For that it require Eo to use that library and it can't be a higher level object. And with current implementation of Eo it is perfectly possible to implement such idea. So not at Eo level. As for Eina, I am starting to think it is getting to much things in its namespace. I do believe that infact Eina_Simple_XML and Eina_File should after all have landed in their own library. That's why I am putting the current logic in a new library. It is going to expand, I want it to provide an few SAX like parser for JSON, Eet_Data and protobuf with also an API like Eet_Data to directly feed those value into a C structure without using a DOM at all. It would also be the right place to experiment and benchmark for a new Eet_Data format that could be more efficient to use. So at the end, and due to how I see things going and being used, I do think it is better of in its own library.
2015-03-17 00:49:57 -07:00
emile: licenses/COPYING.LGPL
eet: licenses/COPYING.BSD
eo: licenses/COPYING.BSD
2015-07-31 00:23:33 -07:00
ector: licenses/COPYING.FTL, licenses/COPYING.GPL (dual licenses)
evas: licenses/COPYING.BSD
embryo: licenses/COPYING.SMALL
ecore: licenses/COPYING.BSD
dns: licenses/COPYING.DNS
eio: licenses/COPYING.LGPL
eldbus: licenses/COPYING.LGPL
efreet: licenses/COPYING.BSD
eeze: licenses/COPYING.BSD
ephysics: licenses/COPYING.BSD
edje: licenses/COPYING.BSD
edje/epp: licenses/COPYING.GPL (separate binary/executable)
emotion: licenses/COPYING.BSD
ethumb: licenses/COPYING.LGPL
2015-07-30 02:55:29 -07:00
eolian: licenses/COPYING.BSD
elua: licenses/COPYING.BSD
elementary: licenses/COPYING.LGPL
generic/evas: licenses/COPYING.GPL (separate binary/executable)
efl: licenses/COPYING.LGPL
csharp bindings: licenses/COPYING.ASL
cxx bindings: licenses/COPYING.ASL
2013-03-22 01:40:56 -07:00
NOTE: If linked together, the result will be effectively be LGPL (or
GPL if escape is used) due to license characteristics.