Re: [E-devel] E CVS: apps/e raster
Enlightenment CVS wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Dir : e17/apps/e
Modified Files:
configure.in enlightenment.pc.in
Log Message:
fix pc file to not inlcude dbus verbatim includes. just -D's for config
Well, you should have the -I flags as well, so that you don't need to
find the include paths for headers which e.h includes.
Sebastian
===
RCS file: /cvs/e/e17/apps/e/configure.in,v
retrieving revision 1.210
retrieving revision 1.211
diff -u -3 -r1.210 -r1.211
--- configure.in 5 Aug 2008 13:52:00 - 1.210
+++ configure.in 6 Aug 2008 05:42:53 - 1.211
@@ -231,8 +231,11 @@
e_libs=$E_LIBS $LIBINTL $fnmatch_libs
e_cflags=-DUSE_E_CONFIG_H $define_e_dbus $E_CFLAGS $E_DBUS_CFLAGS
+e_configflags=-DUSE_E_CONFIG_H $define_e_dbus
+
AC_SUBST(e_libs)
AC_SUBST(e_cflags)
+AC_SUBST(e_configflags)
profile=SLOW_PC
AC_ARG_WITH(profile,
===
RCS file: /cvs/e/e17/apps/e/enlightenment.pc.in,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -3 -r1.4 -r1.5
--- enlightenment.pc.in 5 Aug 2008 13:52:00 - 1.4
+++ enlightenment.pc.in 6 Aug 2008 05:42:53 - 1.5
@@ -8,4 +8,4 @@
Version: @VERSION@
Libs: -L${libdir}
Libs.private:
-Cflags: -I${includedir} @e_cflags@
+Cflags: -I${includedir} @e_configflags@
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Wed, 06 Aug 2008 08:32:31 +0200 Sebastian Dransfeld [EMAIL PROTECTED] babbled: Enlightenment CVS wrote: Enlightenment CVS committal Author : raster Project : e17 Module : apps/e Dir : e17/apps/e Modified Files: configure.in enlightenment.pc.in Log Message: fix pc file to not inlcude dbus verbatim includes. just -D's for config Well, you should have the -I flags as well, so that you don't need to find the include paths for headers which e.h includes. you really need to do that separately yourself - because the -I's include fully expanded paths and when doing os package builds - this breaks things as they expect to use env vars to fix this up, not have the build-system internal path in it :( so i was fixing an os build issue here... :/ -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_object_image rotation?
Here's some example code: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/branches/prototypes_0.7/ui/gauges/evasutil.c?root=carmanview=markup I used it once for testing and worked. Maybe I'm dead wrong but AFAIK evas doesn't support rotation yet, this is third party. 2008/8/6 Yong Ma [EMAIL PROTECTED] Hi all, I want to know if there are some ways to rotate an image object to a custom angle with C language API of EFL, here is some Python code I googled, but I could not find the corresponding function in Ecore_Evas/Evas C language API documents. I really appreciate if anyone can tell me how to or send me some example code. The Python code is as following: #!/usr/bin/env python import sys import ecore import evas import ecore.evas if 'x11' in sys.argv: ee = ecore.evas.SoftwareX11(w=800, h=480) else: ee = ecore.evas.SoftwareX11_16(w=800, h=480) bg = ee.evas.Rectangle(color=(255, 255, 255, 255)) bg.size = ee.evas.size bg.show() img = ee.evas.Image() img.file_set(icon.png) img.move(380, 200) w, h = img.image_size_get() img.resize(w, h) img.fill_set(0, 0, w, h) img.show() rotation = [evas.EVAS_IMAGE_ROTATE_90] def rotate_img(rotation): img.rotate(rotation[0]) rotation[0] += 1 return rotation[0] = evas.EVAS_IMAGE_ROTATE_270 ee.fullscreen = False ee.show() ecore.timer_add(2.0, rotate_img, rotation) ecore.main_loop_begin() # prevent segfault del ee Thank you very much! -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- André Dieb Martins Mail: dieb at embedded.ufcg.edu.br, andre.dieb at gmail.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_Evas_Engines API change in Python-EFL
Hi List, after the recent small API change in Ecore_Evas_Engines the python-bindings of python-efl have been updated, but the python-efl API itself stayed the same. In my opinion this should be changed, too, because it's not a good style to have different APIs in the bindings. The attached patch changes the python API, the same way the C-API has been changed recently. Of course this will break all apps that use the affected engines. I already fixed it in all the demo apps in the python-efl folder, so there should be nothing else to do. I didn't check the other apps in the whole CVS, don't know if there are any other python apps. If this patch comes in there would be one further step to do: python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas_gl_x11.pxi must be renamed, as must python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas_software_x11_16.pxi As a rename requires a cvs rm and cvs add this should be done by someone with cvs access. Also the includes in the examples and so on would have to be changed, I would send another patch if the files will be renamed. Greets, thomasg P.S. I hope the patch is not too much lines in one file, but as the changes are more or less trivial I think this is no big deal. Index: python-efl/python-ecore/ecore/evas/__init__.py === RCS file: /var/cvs/e/e17/proto/python-efl/python-ecore/ecore/evas/__init__.py,v retrieving revision 1.5 diff -u -r1.5 __init__.py --- python-efl/python-ecore/ecore/evas/__init__.py 1 Oct 2007 05:09:43 - 1.5 +++ python-efl/python-ecore/ecore/evas/__init__.py 6 Aug 2008 12:20:14 - @@ -4,6 +4,6 @@ from c_ecore_evas import shutdown, engine_type_supported_get, \ engine_type_from_name, engine_name_from_type, SoftwareX11, \ - GLX11, XRenderX11, FB, Buffer, SoftwareX11_16 + OpenGLX11, XRenderX11, FB, Buffer, Software16_X11 c_ecore_evas.init() Index: python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas.pyx === RCS file: /var/cvs/e/e17/proto/python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas.pyx,v retrieving revision 1.8 diff -u -r1.8 ecore.evas.c_ecore_evas.pyx --- python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas.pyx 25 Jul 2008 19:05:24 - 1.8 +++ python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas.pyx 6 Aug 2008 12:20:14 - @@ -16,18 +16,18 @@ engines[intECORE_EVAS_ENGINE_SOFTWARE_BUFFER] = software_buffer engines[intECORE_EVAS_ENGINE_SOFTWARE_X11] = software_x11 engines[intECORE_EVAS_ENGINE_XRENDER_X11] = xrender_x11 -engines[intECORE_EVAS_ENGINE_OPENGL_X11] = gl_x11 +engines[intECORE_EVAS_ENGINE_OPENGL_X11] = opengl_x11 engines[intECORE_EVAS_ENGINE_SOFTWARE_XCB] = software_xcb engines[intECORE_EVAS_ENGINE_XRENDER_XCB] = xrender_xcb engines[intECORE_EVAS_ENGINE_SOFTWARE_DDRAW] = software_ddraw engines[intECORE_EVAS_ENGINE_DIRECT3D] = direct3d -engines[intECORE_EVAS_ENGINE_OPENGL_GLEW] = gl_glew +engines[intECORE_EVAS_ENGINE_OPENGL_GLEW] = opengl_glew engines[intECORE_EVAS_ENGINE_SDL] = sdl engines[intECORE_EVAS_ENGINE_DIRECTFB] = directfb engines[intECORE_EVAS_ENGINE_SOFTWARE_FB] = software_fb -engines[intECORE_EVAS_ENGINE_SOFTWARE_16_X11] = software_x11_16 -engines[intECORE_EVAS_ENGINE_SOFTWARE_16_DDRAW] = software_ddraw_16 -engines[intECORE_EVAS_ENGINE_SOFTWARE_16_WINCE] = software_wince_16 +engines[intECORE_EVAS_ENGINE_SOFTWARE_16_X11] = software_16_x11 +engines[intECORE_EVAS_ENGINE_SOFTWARE_16_DDRAW] = software_16_ddraw +engines[intECORE_EVAS_ENGINE_SOFTWARE_16_WINCE] = software_16_wince cdef int engines_len engines_len = sizeof(engines)/sizeof(engines[0]) Index: python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas_gl_x11.pxi === RCS file: /var/cvs/e/e17/proto/python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas_gl_x11.pxi,v retrieving revision 1.3 diff -u -r1.3 ecore.evas.c_ecore_evas_gl_x11.pxi --- python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas_gl_x11.pxi 1 Oct 2007 05:09:43 - 1.3 +++ python-efl/python-ecore/ecore/evas/ecore.evas.c_ecore_evas_gl_x11.pxi 6 Aug 2008 12:20:14 - @@ -1,6 +1,6 @@ # This file is included verbatim by c_ecore_evas.pyx -cdef class GLX11(BaseX11): +cdef class OpenGLX11(BaseX11): X11 window using OpenGL render. @ivar window: X11 window id. @@ -12,7 +12,7 @@ cdef Ecore_Evas *obj if self.obj == NULL: -obj = ecore_evas_gl_x11_new(display, parent_xid, x, y, w, h) +obj = ecore_evas_opengl_x11_new(display, parent_xid, x, y, w, h) self._set_obj(obj) def window_get(self): @@ -20,7 +20,7 @@ @rtype: int -return ecore_evas_gl_x11_window_get(self.obj) +return ecore_evas_opengl_x11_window_get(self.obj) property window: def __get__(self):
[E-devel] Nightly build log for E17 on 2008-08-06 07:11:28 -0700
Build log for Enlightenment DR 0.17 on 2008-08-06 07:11:28 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Time-based releases
On Tue, Aug 5, 2008 at 7:13 PM, raoul [EMAIL PROTECTED] wrote: Le mercredi 6 août 2008, Gustavo Sverzut Barbieri a écrit : On Tue, Aug 5, 2008 at 5:36 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2008 13:38:54 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: As for this last remark, moving to SVN is one step further and integration with GIT is even easier. Those that wish can develop in GIT branches and when ready just merge to trunk, Those who don't know how to use GIT (ie: RASTER! ;-)) can keep polluting the trunk with regular commits as they do nowadays. bzzzt. wrong :) i do know how to use git - been using it now for a few months. i think svn is a better choice - for us. :) (i particularly have come to dislike git's mergetool handling.. and when it fucks up... man it fucks you up...) as I said... ;-) being using git as you use cvs is just driving a car like you drive a bicycle. But really, when you see something like that: http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png It scares me a lot about how easy git can be :-p Commands are not difficult, even the worse we can learn (ie: cvs up -dPA), but it's the work flow, the way you organize, work, ... that's what needs a bit of change and some people get lost. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Time-based releases
On Wed, Aug 6, 2008 at 11:30 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Tue, Aug 5, 2008 at 7:13 PM, raoul [EMAIL PROTECTED] wrote: Le mercredi 6 août 2008, Gustavo Sverzut Barbieri a écrit : On Tue, Aug 5, 2008 at 5:36 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2008 13:38:54 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: As for this last remark, moving to SVN is one step further and integration with GIT is even easier. Those that wish can develop in GIT branches and when ready just merge to trunk, Those who don't know how to use GIT (ie: RASTER! ;-)) can keep polluting the trunk with regular commits as they do nowadays. bzzzt. wrong :) i do know how to use git - been using it now for a few months. i think svn is a better choice - for us. :) (i particularly have come to dislike git's mergetool handling.. and when it fucks up... man it fucks you up...) as I said... ;-) being using git as you use cvs is just driving a car like you drive a bicycle. But really, when you see something like that: http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.pnghttp://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-large.png It scares me a lot about how easy git can be :-p Commands are not difficult, even the worse we can learn (ie: cvs up -dPA), but it's the work flow, the way you organize, work, ... that's what needs a bit of change and some people get lost. Git can also improve the patches quality, because you can work offline (i.e. reorder, redo, refactory, etc your commit) and when you think that everything is perfect, send the patchs. With CVS you will need something like quilt in order to do this. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that +there is no warranty for the free library. Also, if the library is +modified by someone else and passed on, the recipients should know +that what they have is not the original version, so that the original +author's reputation will not be affected by problems that might be +introduced by others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that +any patent license obtained for a version of the library must be +consistent with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and +is quite different from the ordinary General Public License. We use +this license for certain libraries in order to permit linking those +libraries into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the +entire combination fits its criteria of freedom. The Lesser
Re: [E-devel] E CVS: proto/eina turran
Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Enlightenment CVS wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE +Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link other code with the library, you must provide +complete object files to the recipients, so that they can relink them +with the library after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + We protect your rights with a two-step method: (1) we copyright the +library, and (2) we offer you this license, which gives you legal +permission to copy, distribute and/or modify the library. + + To protect each distributor, we want to make it very clear that +there is no warranty for the free library. Also, if the library is +modified by someone else and passed on, the recipients should know +that what they have is not the original version, so that the original +author's reputation will not be affected by problems that might be +introduced by others. + + Finally, software patents pose a constant threat to the existence of +any free program. We wish to make sure that a company cannot +effectively restrict the users of a free program by obtaining a +restrictive license from a patent holder. Therefore, we insist that +any patent license obtained for a version of the library must be +consistent with the full freedom of use specified in this license. + + Most GNU software, including some libraries, is covered by the +ordinary GNU General Public License. This license, the GNU Lesser +General Public License, applies to certain designated libraries, and +is quite different from the ordinary General Public License. We use +this license for certain libraries in order to permit linking those +libraries into non-free programs. + + When a program is linked with a library, whether statically or using +a shared library, the combination of the two is legally speaking a +combined work, a derivative of the original library. The ordinary +General Public License therefore permits such linking only if the +entire combination fits its criteria of freedom. The Lesser General +Public License permits more lax criteria for linking other code with +the library. + + We call
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
We don't want the ability to cross-pollinate code with those projects and they are SEPARATE PROJECTS. The goal of eina was to unify around one shared data lib, so why would we not be using eina? On Wed, Aug 6, 2008 at 3:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I hate to reiterate over whats already been said, but just in case you've forgotten, here you go: That library is not a big one, it's not the most powerful lib on earth. Just a data type lib. You do not want to help, well, if you don't like LGPL, why not. But not linking against it, it's completely crazy. I won't link against it because it's an internal E library that isn't BSD. The rest of the stack is BSD and anything from the E project (at least core stuff) could be taken by a company and worked on internally. Suddenly there are pieces which require separate licensing and contribution requirements. Feels wrong. Does that mean that you also don't link against any lgpl (or other licence that is not like BSD or MIT) lib that exist ? No, it doesn't. Those aren't EFL projects. We have them marked as a dependency and I don't code for them. I may submit bugs and such but they aren't a big part of my work. I want to be able to take my work at some point and make modifications that aren't open if it comes to that. Why should I have to give up my ability to take my code and do what I want with it? (And, I know I can just re-license my code but in general it's been worked on my many, many, people so I can't just take it that way) dan Also, there have been several emails about the need to keep the licensing consistent within the project (from Kim, Luchezar, Andreas, etc). - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina's ideas hasn't been around for short time, i started this topic two years ago, even did a poll and added edata into cvs, the truth is that i created efl-research (some kind of a fork) to elaboroate the ideas i had, and then, include them into e cvs. But the consensus your quoting has never existed on this project, never; i think most of us will agree on this, everybody is following their own needs and goals on what they want things to be. Every time i've tried to push some discussion on some ideas or development changes it has lead to /dev/null and nobody has been interested on anything other one was/is doing on e cvs. So this consensus is just an hypothetical consensus on a project which hasnt. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. Regards On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 5:21 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: We don't want the ability to cross-pollinate code with those projects and they are SEPARATE PROJECTS. The goal of eina was to unify around one shared data lib, so why would we not be using eina? Because you don't like its license? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors to deny you these rights or to ask you to surrender these +rights. These restrictions translate to certain responsibilities for +you if you distribute copies of the library or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. Nathan, E *is* an unhealthy community. To be honest, E is not even a community. We are nothing more than a group of people working on their own little projects in a shared CVS repository. Look at the state of any active EFL project. We rarely have more than a single or two developers contributing to a project at any one point, and most of the time, the count is zero. Granted we're a small group, why does no one spend time fixing E17's bugs so we can roll it out the door instead of working on random bits here and there? No interest, maybe... The point is though, we're never trying to help each other in developing anything. Everyone cares about their own sub-projects and we rarely have any E-wide planning or any focused development on a single part because it will benefit us as a single community. -- Hisham Mardam Bey http://hisham.cc/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 16:22 -0400, Jaime Thomas wrote: On Wed, Aug 6, 2008 at 4:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I hate to reiterate over whats already been said, but just in case you've forgotten, here you go: That library is not a big one, it's not the most powerful lib on earth. Just a data type lib. You do not want to help, well, if you don't like LGPL, why not. But not linking against it, it's completely crazy. I won't link against it because it's an internal E library that isn't BSD. The rest of the stack is BSD and anything from the E project (at least core stuff) could be taken by a company and worked on internally. Suddenly there are pieces which require separate licensing and contribution requirements. Feels wrong. Well that's quite close-minded. I don't agree to have different libraries for different libs within E (and I presume eina will take over from evas and ecore), but refusing to link to an LGPL library ... Well, if you want to make your life difficult, be my guest, but don't presume that everyone else does. Some of us just want to code, not go into the politics of code itself. Does that mean that you also don't link against any lgpl (or other licence that is not like BSD or MIT) lib that exist ? No, it doesn't. Those aren't EFL projects. We have them marked as a dependency and I don't code for them. I may submit bugs and such but they aren't a big part of my work. I want to be able to take my work at some point and make modifications that aren't open if it comes to that. Why should I have to give up my ability to take my code and do what I want with it? (And, I know I can just re-license my code but in general it's been worked on my many, many, people so I can't just take it that way) Are eina and etk your work? Take whatever you want from ewl and close it, it's your work, and you are certainly free to do so. Also, even LGPL can't force you to release your modifications, if the result is not public anyway (if you keep it in your basement, no one will care). Again, while it is bothersome that now we have to deal with multiple licenses, no one is forcing you to change to lgpl. dan Also, there have been several emails about the need to keep the licensing consistent within the project (from Kim, Luchezar, Andreas, etc). - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. Mike dancingeek - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish); that you receive source code or can get +it if you want it; that you can change the software and use pieces of +it in new free programs; and that you are informed that you can do +these things. + + To protect your rights, we need to make restrictions that forbid +distributors
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:45 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? Stop mis-characterizing statements. See my other reply about code interactions between parts of the project. On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based
Re: [E-devel] E CVS: proto/eina turran
Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Lesser General Public License, applies to some +specially designated software packages--typically libraries--of the +Free Software Foundation and other authors who decide to use it. You +can use it too, but we suggest you first think carefully about whether +this license or the ordinary General Public License is the better +strategy to use in any particular case, based on the explanations below. + + When we speak of free software, we are referring to freedom of use, +not price. Our General Public Licenses are designed to make sure that +you have the freedom to distribute copies of free software (and charge +for this service if you wish);
Re: [E-devel] E CVS: proto/eina turran
Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? A gun has been put to the head of EWL now that it could potentially have an LGPL lib underneath it and thus bounding companies to either make cumbersome workarounds or in general make our community look like it can't make up it's mind (which probably isn't far from the truth at this point). On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:41 PM, Hisham Mardam Bey [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 4:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. Nathan, E *is* an unhealthy community. To be honest, E is not even a community. We are nothing more than a group of people working on their own little projects in a shared CVS repository. Look at the state of any active EFL project. We rarely have more than a single or two developers contributing to a project at any one point, and most of the time, the count is zero. Duh? And how does this do anything but hurt that loose affiliation even more? We now have a component that set of components that have become code tarpits from the rest of the project. Code can go in, but never come back out. Granted we're a small group, why does no one spend time fixing E17's bugs so we can roll it out the door instead of working on random bits here and there? No interest, maybe... The point is though, we're never trying to help each other in developing anything. Everyone cares about their own sub-projects and we rarely have any E-wide planning or any focused development on a single part because it will benefit us as a single community. We're all scratching our own itches as they come up. This is off-topic from the discussion though. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
I'm a Summer of Code student this year (so, not a /real/ E developer), and I was planning on keeping my head entirely out of this conversation, but each email makes that more and more difficult. So I've decided to express my _opinion_ on the matter of the E community (I'm have no preference in the license wars, and I will *not* choose a side). I've come to realize that the E community might not be as healthy as it appears from the outside; it certainly isn't as /large/ as it appears, nor as large as it would need to be in order to sustain a codebase of this size and expand its user base (as I assume one of the goals of the project is). However, it is my opinion that this is, in fact, *not* a license issue, nor a quality issue, or anything of that matter - the simple fact is, you *are* losing potential developers with arguments like this (and the rest from weeks past). They notice the amount of time the 'community' spends on things like this (among other issues), and move on to other projects. I know this, because I know a handful of said developers, and the fact that they decided not to work on E saddens me, but I cannot find fault in their argument; I'm sorry. Anyway - here's to a speedy resolution of this, and millions more lines of working, usable, use*ful* code. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 15:48 -0500, Nick Hughart wrote: Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:41 -0500, Nathan Ingersoll wrote: Really? I have done my best to layout factual reasons and arguments but have not seen any rebuttals that have attempted to do the same. True, you have. And I didn't say otherwise. What I said was, more than half just don't care. And it seems that ewl is still under the bsd license. Am I to assume that no one has put a gun to your head, and forced you to switch licenses? A gun has been put to the head of EWL now that it could potentially have an LGPL lib underneath it and thus bounding companies to either make cumbersome workarounds or in general make our community look like it can't make up it's mind (which probably isn't far from the truth at this point). This isn't meant as an offense, and IANAL, BUT how is LGPL restricting for companies exactly? They can use the library, and they can still keep their proprietary code too. The company I work for uses LGPL libraries, and there were never 'cumbersome workarounds' involved. On 8/6/08, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:20 -0500, Nick Hughart wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 5:04 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:53 PM, Nick Hughart [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri wrote: On Wed, Aug 6, 2008 at 4:07 PM, Nick Hughart [EMAIL PROTECTED] wrote: Have fun getting any of the libs in CVS to use Eina now. Just more split effort... Since they're basically the only doing any code in CVS, it will be as hard as before. I guess I should stop working on EFM then and all those working on EWL should cease as well. Don't make stupid statements. There are plenty of people who have and continue to contribute when they can to all of E's CVS, by making such a statement you just look stupid. I realize you are trying to make a point with all this switching, but in all honesty all it's going to do is make things worse, so thank all of you for screwing up our community more then it already was. Ok, so let's reduce the scope of my statement to make it less stupid: Since they're basically the only doing any code in CVS [THAT WOULD USE EINA DIRECTLY], it will be as hard as before. I see ecore and evas as main users, possible provide some helpers to have eet descriptors with eina data types. Of course there are many places where it could be used, including EWL or ETK, but I saw no talk about moving them so far. EWL uses ecore data types, thus it will use eina indirectly and thus indirectly it will be bound by the terms of the LGPL as will anyone using ecore, evas, edje, etc. ah, fine... so you all use BSD's libC, do not use GNU LibC or any other LGPL library... There are plenty of libc's, if a company so chooses they could use a BSD licensed libc and build the EFL on top of it. This may require patches, but they can easily patch it themselves if they want to. The contents of libc are far more common between variations then Eina will be. Also, if we didn't support GNU libc at all, we probably wouldn't have anywhere near the exposure we do (note this is no argument for LGPL, people just happened to build Linux with the GNU tools and here we are today with that being the most popular combination). Either way, you completely ignored the fact that you are causing major headaches for the community and in the end this isn't going to make anything better, so once again, thank you for being short-sighted and trying to force your way upon others who have long ago decided how free they wanted their software to be. Now they are being forced to either waste effort or switch licenses, neither of which feels very good (one of which is impossible) and sure the hell isn't going to bring more developers (or even end users) as some like to claim. That's not exactly true. From the discussions here, more than half of us didn't even care whether the libraries would be lgpl or bsd. The rest either want to be only bsd, or only lgpl, and it seems that these edge cases are about equal in numbers. And could you elaborate on why exactly you would be forced to switch from bsd to lgpl. LGPL is not a viral license, so you don't have to do shit. You seem to insinuate that the LGPL camp is only spreading FUD, but to me, it seems that both camps are doing it. - This SF.Net email is
Re: [E-devel] E CVS: proto/eina turran
Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. I wouldn't be so quick to make that assumption, I can recall many cases over ideas being stolen, mainly patents. Proving to a 50 year old judge who's never touched a computer that the code is identical with different words is incredibly easy and experts are paid for their testimony, so... On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 16:54 -0400, Timothy P. Horton wrote: I'm a Summer of Code student this year (so, not a /real/ E developer), and I was planning on keeping my head entirely out of this conversation, but each email makes that more and more difficult. So I've decided to express my _opinion_ on the matter of the E community (I'm have no preference in the license wars, and I will *not* choose a side). I've come to realize that the E community might not be as healthy as it appears from the outside; it certainly isn't as /large/ as it appears, nor as large as it would need to be in order to sustain a codebase of this size and expand its user base (as I assume one of the goals of the project is). However, it is my opinion that this is, in fact, *not* a license issue, nor a quality issue, or anything of that matter - the simple fact is, you *are* losing potential developers with arguments like this (and the rest from weeks past). They notice the amount of time the 'community' spends on things like this (among other issues), and move on to other projects. I know this, because I know a handful of said developers, and the fact that they decided not to work on E saddens me, but I cannot find fault in their argument; I'm sorry. Anyway - here's to a speedy resolution of this, and millions more lines of working, usable, use*ful* code. Tim And that is really THE saddest part of all this commotion. E isn't a community as Hisham said, not many people use it or its libraries (are there even any isvs using ewl or etk?). And instead of people doing what they like (which is in this case, coding), suddenly the shit hit the political fan. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, 2008-08-06 at 16:00 -0500, Nick Hughart wrote: Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. I wouldn't be so quick to make that assumption, I can recall many cases over ideas being stolen, mainly patents. Proving to a 50 year old judge who's never touched a computer that the code is identical with different words is incredibly easy and experts are paid for their testimony, so... True, but patents != copyright. Totally different concept, totally different judges. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:55 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. You mean like EWD was? Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. Only if you are reimplementing it. You can't re-use any of the code from the original if you want to BSD license it. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the Lesser GPL. It also counts + as the successor of the GNU Library Public License, version 2, hence + the version number 2.1.] + +
Re: [E-devel] E CVS: proto/eina turran
Viktor Kojouharov wrote: On Wed, 2008-08-06 at 16:00 -0500, Nick Hughart wrote: Viktor Kojouharov wrote: On Wed, 2008-08-06 at 15:48 -0500, Nathan Ingersoll wrote: Look at the history of this project and any other complex projects. It is very common that components get moved from one layer of abstraction to another as it becomes apparent they fit better at another location. Speaking specifically for eina, I seriously doubt that the code would go anywhere (except maybe to another new library). The whole point of creating the library was to put all the different data type codes together. And besides the name (does eina even mean anything, is it related to data in any way?) it seems that all the code belongs together. Let's be realistic and say that the code is not going anywhere. Also, the license covers the verbatim code, not the idea behind it. Therefore, if the code will be moved, it will most likely change in the process. Therefore, you can license it to bsd, if you so desire. I wouldn't be so quick to make that assumption, I can recall many cases over ideas being stolen, mainly patents. Proving to a 50 year old judge who's never touched a computer that the code is identical with different words is incredibly easy and experts are paid for their testimony, so... True, but patents != copyright. Totally different concept, totally different judges. They're all old and oblivious, doesn't matter which court it is heh. And given the RIAA copyright cases, who knows how copyright will come into play. On Wed, Aug 6, 2008 at 3:46 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-08-06 at 15:33 -0500, Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most people I know of are interested because we can finally remove some redundant API's. Why don't you ask Peter since he's the other one you mention making some effort on it? The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. Correct me if I'm wrong, but isn't eina a library? Why do you need to take something out of it? What happened to good ol' linking? Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 -
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 3:54 PM, Timothy P. Horton [EMAIL PROTECTED] wrote: I'm a Summer of Code student this year (so, not a /real/ E developer), and I was planning on keeping my head entirely out of this conversation, but each email makes that more and more difficult. So I've decided to express my _opinion_ on the matter of the E community (I'm have no preference in the license wars, and I will *not* choose a side). I've come to realize that the E community might not be as healthy as it appears from the outside; it certainly isn't as /large/ as it appears, nor as large as it would need to be in order to sustain a codebase of this size and expand its user base (as I assume one of the goals of the project is). However, it is my opinion that this is, in fact, *not* a license issue, nor a quality issue, or anything of that matter - the simple fact is, you *are* losing potential developers with arguments like this (and the rest from weeks past). They notice the amount of time the 'community' spends on things like this (among other issues), and move on to other projects. I know this, because I know a handful of said developers, and the fact that they decided not to work on E saddens me, but I cannot find fault in their argument; I'm sorry. Anyway - here's to a speedy resolution of this, and millions more lines of working, usable, use*ful* code. Thanks Tim, well stated. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:46 PM, Mike Rutter [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Mike dancingeek - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:46 PM, Mike Rutter [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Given this information, why did you decide to even contribute to the EFL. Did you think that having multiple licenses would be fine with everyone? Mike dancingeek - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. You can't tell me that im wrong as i did eina and took the decisions about it. I have to explain this as this totally wrong. Eina's attempt was known, i already commented about it on irc and on ml, *with* intention to get developers contribute to it, contribute not only on the sense of coding it, but actually *using* it to have a common data library. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. people I know of are interested because we can finally remove some redundant API's. If so, why on the past two years, no interest on this library (concept) has been shown? i even received comments like: ecore already provides it and ecore means core so it should belong there and not in evas/eet. kind of absurd, imho. Why don't you ask Peter since he's the other one you mention making some effort on it? Peter already stated his POV on this, he said that he wont contribute, so his stringshare code was respected with the bsd license on top of the file. Did i do something wrong? what happens with edata when it was on cvs, why he didnt put up his effort there and instead made a new library? why he didnt contact me about eina on the beginning? I respect his decision, but looks like mine isnt respected. The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do whatever he wants because such thing as consensus doesnt exist, but not only at license level but on *any* level. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. True, so? i understand that having that flexibility is something you are interested on, and i respect that; but i have a different vision there, doing that is what e has exactly been doing with no real gain, just moving/renaming and code things on a monolithic way; and i dont like that approach. Consensus is how healthy communities operate, so your second point would be that E is an unhealthy community. Well, that's just a words game, you can call it unhealthy community, but for me a community is exactly that the community has the power to change how it operates, which in this case has been broken (with eina's license) because i dont think this is a community. On Wed, Aug 6, 2008 at 1:12 PM, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : turran Project : e17 Module : proto/eina Dir : e17/proto/eina Modified Files: COPYING Added Files: OLD-COPYING.PLAIN Log Message: License changes (BSD - LGPL) === RCS file: /cvs/e/e17/proto/eina/COPYING,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- COPYING 30 Jul 2008 12:46:54 - 1.1 +++ COPYING 6 Aug 2008 18:12:57 - 1.2 @@ -0,0 +1,504 @@ + GNU LESSER GENERAL PUBLIC LICENSE + Version 2.1, February 1999 + + Copyright (C) 1991, 1999 Free Software Foundation, Inc. + 51 Franklin Street, Fifth
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 11:37 PM, Nick Hughart [EMAIL PROTECTED] wrote: Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:46 PM, Mike Rutter [EMAIL PROTECTED] wrote: On Wed, Aug 06, 2008 at 10:25:52PM +0200, Jorge Luis Zapata Muga wrote: Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. I would just like to point out that you are making the arguments that: 1) Everyone does their own thing in E CVS, there is no leadership or guidance for the project. 2) Developers paying attention to a direction the project lead wants to go in makes them sheep. I don't know, but it seems a touch contradictory to me. Much like claiming the reason for a small community is because of a license, and then causing community fragmentation by pushing a license when the license argument has been shown to have serious holes. True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Given this information, why did you decide to even contribute to the EFL. Did you think that having multiple licenses would be fine with everyone? Looks like it isnt fine with everyone, but i (and the others devs that want to have the code licensed under lgpl) think that a change needs to be done, maybe the license is not the best thing for everyone, but is a push we are going forward, at least with *our* code. From my personal point of view, I could have kept the code under the google code project and continue there and never give back code into e cvs, but it would have been unfair for the whole project and because others devs wanted that code *in*, so do i. Why contributing to the EFL? do i have to answer that? Having a library lgpl and linking against it, doesnt affect you unless you want to move code around and dont want to license yours as lgpl, which i doubt that having a good design means moving the code around. Mike dancingeek - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. You can't tell me that im wrong as i did eina and took the decisions about it. I have to explain this as this totally wrong. Eina's attempt was known, i already commented about it on irc and on ml, *with* intention to get developers contribute to it, contribute not only on the sense of coding it, but actually *using* it to have a common data library. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. people I know of are interested because we can finally remove some redundant API's. If so, why on the past two years, no interest on this library (concept) has been shown? i even received comments like: ecore already provides it and ecore means core so it should belong there and not in evas/eet. kind of absurd, imho. Ecore is going to be split and thus ecore_data will be a separate library and was going to house all the datatypes, this shows how you've ignored or just don't understand the plans of the rest of the community. Ecore should not depend on Evas, Ecore_Evas should be split out now and this problem would be mostly moot as the circular dep would not exist and evas data types could be moved to ecore_data or merged to create new data types. Your effort is fine, your choice to make it LGPL may just make it useless in the end. If this is the route you want to go, then you'll have to deal with the consequences. On that same thread, can you honestly say that having a random LGPL lib that all these BSD libs depend on in a heavy way not concerning to anyone looking at the EFL? They may stay away just for fear of it all becoming LGPL and them being unable to update their forks. Why don't you ask Peter since he's the other one you mention making some effort on it? Peter already stated his POV on this, he said that he wont contribute, so his stringshare code was respected with the bsd license on top of the file. Did i do something wrong? what happens with edata when it was on cvs, why he didnt put up his effort there and instead made a new library? why he didnt contact me about eina on the beginning? I respect his decision, but looks like mine isnt respected. Well all of the people who are contributing to eina showed no interest before. Since eina hit cvs people have been contributing to it with the intent of making it LGPL the whole time. Saying otherwise seems like a big lie to me as there really wasn't any thought put into the ramifications. Just because the people who like the LGPL tend to have more time to contribute doesn't mean it makes eina any better then the other efforts. You're making assumptions that cannot be made with your limited insight into the project. And if he would have put his effort into eina all his code would now be LGPL or rewritten to make it so, so that argument is pointless. Plus he also has obligations elsewhere and eina was not in E's repo so it wasn't really a good target given everyone was unsure of it's success. The license issue is not really an issue, if the problem is because ewl/ecore might be lpgl, that statement is totally wrong, you already know that, you can keep the license you want and in fact you will, there's no need to make other projects use eina, but the ones i'll commit later will use it and also be lgpl. If the problem is because all e projects should be bsd, then again, that would make sense on a project where everything is shared among the developers and the development which again is not the case. Basically e cvs is a repository where anyone can do
Re: [E-devel] E CVS: proto/eina turran
Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Imagine our License page on our website: Well, some of our core libraries (evas, ecore...) are licensed under the BSD license, but some others are LGPL'd. This will only frustrate and confuse newcomers. Nobody cares if BSD is comfortable for your or anyone else's company, this is our current license and raster's 10 years arguments on GPL - BSD are still valid and good. Plus, again, we just can't relicense those libraries, you know the reasons. You guys are just doing mistakes and all this is a huge bullshit that frustrates both developers and users. See, Dan already left... A man with a huge contribution to the whole project. You want to make someone else leave? I think a lot of people will support me here. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Thu, Aug 7, 2008 at 12:06 AM, Nick Hughart [EMAIL PROTECTED] wrote: Jorge Luis Zapata Muga wrote: On Wed, Aug 6, 2008 at 10:33 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:25 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:01 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: You're going to completely ignore all of the feedback you received on this issue and just change the license without a consensus? Ok, let's begin on *how* i see this. Eina suddenly has gotten attention, not because of its technical features, but because i wanted it to be lpgl *and* raster has said that he wants to push eina's effort. That's the real thing, nobody cared about it on the past two years until cedric was interested and pushed it into proto and pfritz did the string thing. Nobody. Raster has expressed his will on that library, so what happens? everyone is going to love eina because of that? if that's the case this is not a community is a herd. Wrong, it got attention because you started working with people to get it into CVS and operate as part of the project. You can't tell me that im wrong as i did eina and took the decisions about it. I have to explain this as this totally wrong. Eina's attempt was known, i already commented about it on irc and on ml, *with* intention to get developers contribute to it, contribute not only on the sense of coding it, but actually *using* it to have a common data library. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. people I know of are interested because we can finally remove some redundant API's. If so, why on the past two years, no interest on this library (concept) has been shown? i even received comments like: ecore already provides it and ecore means core so it should belong there and not in evas/eet. kind of absurd, imho. Ecore is going to be split and thus ecore_data will be a separate library and was going to house all the datatypes, this shows how you've ignored or just don't understand the plans of the rest of the community. Ecore should not depend on Evas, Ecore_Evas should be split out now and this problem would be mostly moot as the circular dep would not exist and evas data types could be moved to ecore_data or merged to create new data types. The above paragraph exactly shows how far you are from the real problem. *I* did the above plan, you are just repeating the words as if you actually know them, i did the poll with the developers asking what modules of ecore should be split, and ecore_data was not elected on that time to be split. The evas / ecore circular problem (ecore_evas) showed up when we want to have support for ecore based libs in evas, specially to allow remote engines (evoak's approach, do you remember?) so please, dont tell me things that i already said two years ago and nothing has done on that way. Please. Your effort is fine, your choice to make it LGPL may just make it useless in the end. If this is the route you want to go, then you'll have to deal with the consequences. On that same thread, can you honestly say that having a random LGPL lib that all these BSD libs depend on in a heavy way not concerning to anyone looking at the EFL? They may stay away just for fear of it all becoming LGPL and them being unable to update their forks. Why don't you ask Peter since he's the other one you mention making some effort on it? Peter already stated his POV on this, he said that he wont contribute, so his stringshare code was respected with the bsd license on top of the file. Did i do something wrong? what happens with edata when it was on cvs, why he didnt put up his effort there and instead made a new library? why he didnt contact me about eina on the beginning? I respect his decision, but looks like mine isnt respected. Well all of the people who are contributing to eina showed no interest before. Since eina hit cvs people have been contributing to it with the intent of making it LGPL the whole time. Saying otherwise seems like a big lie to me as there really wasn't any thought put into the ramifications. Just because the people who like the LGPL tend to have more time to contribute doesn't mean it makes eina any better then the other efforts. You're making assumptions that cannot be made with your limited insight into the project. And if he would have put his effort into eina all his code would now be LGPL or rewritten to make it so, so that argument is pointless. Plus he also has obligations elsewhere and eina was not in E's repo so it wasn't really a good target given
Re: [E-devel] E CVS: proto/eina turran
Luchezar Petkov wrote: Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Imagine our License page on our website: Well, some of our core libraries (evas, ecore...) are licensed under the BSD license, but some others are LGPL'd. This will only frustrate and confuse newcomers. Nobody cares if BSD is comfortable for your or anyone else's company, this is our current license and raster's 10 years arguments on GPL - BSD are still valid and good. Plus, again, we just can't relicense those libraries, you know the reasons. You guys are just doing mistakes and all this is a huge bullshit that frustrates both developers and users. See, Dan already left... A man with a huge contribution to the whole project. You want to make someone else leave? I think a lot of people will support me here. Click here for great computer networking solutions! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMTAkyxiJnXDPUom5FxrSAmYldmm0e7sS5Rhm5lOczjV7/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Time-based releases
On Wed, Aug 06, 2008 at 12:21:28PM -0400, Thiago Marcos P. Santos wrote: Git can also improve the patches quality, because you can work offline (i.e. reorder, redo, refactory, etc your commit) and when you think that everything is perfect, send the patchs. With CVS you will need something like quilt in order to do this. I agree with your point, its all about the workflow. However, if you are in a situation where there can be several cycles of posting and reviewing patches before they are merged, then a tool like quilt can be quite useful even if you are using something like git or hg. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 7:29 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel As a naught but a simple E user and occasional irc-lurker I have kept out of these sorts of discussions. This one however IMO is out of hand. Luchezar Petkov is 100% correct, please read his words above and take them into account. This sort of issue is entirely unworthy of a 50 post war. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Jose Gonzalez wrote: Luchezar Petkov wrote: Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. Ok, let's stop here. It's not about what you want. It's about what we all want. I, and a lot of people in our community do NOT want our CORE base of libraries to be licensed with different licenses. I don't care about third-party (or non-core) things like Etk or Evolve or Edje_Editor or some theme/module or Ewl, etc, etc. I personally made the compromise to relicense my contribution (of about 80 icons) to Evolve because I respect Hisham and his choice. And I'm not against LGPL or any other license, but we MUST keep your CORE code base consistent. As you all already saw it's nearly impossible to move our code base to another license, so just simply KEEP IT BSD! Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. What difference in opinion is there in the core libs. The core libs have always been defined as those libs used by E. By this definition, EWL, ETK, etc are not core libs. They do however depend on these core libs in some way. The reason for all the inconsistency in the community is due to things like this. Someone tends to complain about something without good reasons to be doing so and just goes off and does their own thing instead of contributing back to the original effort. There are cases when this is fine such as some incredibly bad unfinished start of code from a dev who has completely left. In that case there is cause to start a new effort and this has been done a few times in the past. There are cases however where people wouldn't compromise and it's lead to fracture. Not saying one side or the other was right, just saying that there tends to be a lack of compromise and maybe that's good since we have been able to keep things lean and light till now. Sometimes compromise just leads things down the wrong path and if the authors of a lib feel that a compromise cannot be reached then that's their choice as the initial developers of that lib. They have a say in what hits mainline. So maybe we just don't feel like polluting our code with certain things just to please people in the short term and instead we actually weigh their suggestions against our goals and decide whether their contribution is helpful in that cause. Some people don't take rejection well. Are we elitist or just realistic about what we want? I find that too many people are too willing to accept shit these days and not ask questions... Imagine our License page on our website: Well, some of our core libraries (evas, ecore...) are licensed under the BSD license, but some others are LGPL'd. This will only frustrate and confuse newcomers. Nobody cares if BSD is comfortable for your or anyone else's company, this is our current license and raster's 10 years arguments on GPL - BSD are still valid and good. Plus, again, we just can't relicense those libraries, you know the reasons. You guys are just doing mistakes and all this is a huge bullshit that frustrates both developers and users. See, Dan already left... A man with a huge contribution to the whole project. You want to make someone else leave? I think a lot of people will support me here. Click here for great computer networking solutions! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMTAkyxiJnXDPUom5FxrSAmYldmm0e7sS5Rhm5lOczjV7/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin
Re: [E-devel] E CVS: proto/eina turran
Zachary Goldberg wrote: On Wed, Aug 6, 2008 at 7:29 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel As a naught but a simple E user and occasional irc-lurker I have kept out of these sorts of discussions. This one however IMO is out of hand. Luchezar Petkov is 100% correct, please read his words above and take them into account. This sort of issue is entirely unworthy of a 50 post war. Believe me, this will go on much longer then 50 posts unfortunately. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:32 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: True, it looks like but it isnt. Let me explain. The community fragmentation is *not only* the license, it is mainly because of point 1. Point 2 is refered to people that won't code on eina and for people that *hears* raster to make a decision by themselves. Is not that contradictory, happens that those points are related to two different groups of ppl. I have never stated that making a project licensed under lgpl will make it have more developers or being it bsd it will have less coders at all, i have said that it can't be confirmed. What i have stated is that *i* don't want my code to be freely available to companies that won't follow the same openness on the code, that's it. it wont alter the POV for specific developers that want to code to open source projects, just alters those developers that don't want their code to be restricted on its use by companies that won't release the code. Except this isn't just about you. You can do as you please licensing your own code, but you are importing code into an existing project with a well established license. If you want your code in such a project, you need to work with the other members to determine the license. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. Regards to all for what is still my preferred interface after many years. Thanks. M On Wed, Aug 6, 2008 at 6:36 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 7:29 PM, Luchezar Petkov [EMAIL PROTECTED] wrote: On Thu, Aug 7, 2008 at 2:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Luchezar Petkov wrote: Our core base libs? Obviously there's a difference in opinion between various contributors to these core libs. Consistency may or may not be the ultimate aim, and the growth of the project may depend on changes... But whichever way it goes, it would be up to those who are working on the code and doing real contributions on those libs - growth as the market decides. When you're writing open source code you are writing it for the people, for the community at first. Then for yourself and for your company. Therefore those our (our community's) libraries. And although the developers make the decisions about how the code is going to work/be packaged/be relased/etc every user should have the right to express his opinion and help making the decisions. Consistency in the project's core code base is a must. Face it. If it's not, what kind of project it is? This is ridiculous, and you know it. If it's someone or else's dictated views, and that does not address the concerns of current or potential developers, then you may well find this becoming a very small project indeed, or simply remaining the elitist niche it's been for so very long. Stop talking about dictators and dictating. Adolf Hitler was a dictator and we have no Hitlers around. The project itself and its community/user base are growing and I can see it. But, if you keep fooling around with these license shit that is doing nothing but frustrating people others may leave, yes. In my opinion, Eina is a good thing, but you guys should either keep it's license consistent with the licensing of the other core libraries or take it somewhere else and stop this insane bullshit. -- Luchezar P. Petkov http://luchko.net - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel As a naught but a simple E user and occasional irc-lurker I have kept out of these sorts of discussions. This one however IMO is out of hand. Luchezar Petkov is 100% correct, please read his words above and take them into account. This sort of issue is entirely unworthy of a 50 post war. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Mark Dickie +57 314 204 6358 Email [EMAIL PROTECTED] Skype blaeberries - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 9:16 PM, Mark Dickie [EMAIL PROTECTED] wrote: As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 4:52 PM, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote: You can't tell me that im wrong as i did eina and took the decisions about it. I have to explain this as this totally wrong. Eina's attempt was known, i already commented about it on irc and on ml, *with* intention to get developers contribute to it, contribute not only on the sense of coding it, but actually *using* it to have a common data library. You are wrong again, I can examine the evidence and draw conclusions and I'm perfectly capable of saying that I think you're wrong. You are repeating your opinion and drawing conclusions which are not founded by the arguments you present. You worked in a repository outside of the normal project. This means only developers that explicitly want to jump into your effort will follow the activity, you won't pick up work from the project members that don't sign on. How many E related side projects have you seen become heavily adopted before they went into CVS? I can't think of any except for maybe E-Live and that was primarily because it was well linked from E.org and was an entire distribution to help users try E. Myself, I did not follow eina outside CVS mainly because we have many people mention wanting to help with things that never come to fruition. I would not be surprised if others were in the same situation. I also did not see any statements from raster that he was willing to let evas depend on an external data type lib. Without that, there was not much point to another data structure lib as it would just be more duplication. Nothing to do with the license. Cedric may have been interested because it was LGPL, but most Cedric was interested on the project by himself and because it was technically good, i think having a common library for data types is something we all agree. I think he will reply on this. And yes, the license do has something to do with this, as *i* want it to be lgpl. As I stated in another email, that's fine for you, but not necessarily fine for broader project. people I know of are interested because we can finally remove some redundant API's. If so, why on the past two years, no interest on this library (concept) has been shown? i even received comments like: ecore already provides it and ecore means core so it should belong there and not in evas/eet. kind of absurd, imho. Because you were working in an external repository. By being outside CVS it was not really part of the project. E doesn't get a ton of developer attention as it is, and you expect an unknown experimental lib developed outside the project to get more attention? Also, you mentioned previously that it was already LGPL, if you're proposing the license change is the driving force for interest, how was there a change? I don't really know where those comments came from so it's not up to me to defend them. Why don't you ask Peter since he's the other one you mention making some effort on it? Peter already stated his POV on this, he said that he wont contribute, so his stringshare code was respected with the bsd license on top of the file. Did i do something wrong? what happens with edata when it was on cvs, why he didnt put up his effort there and instead made a new library? why he didnt contact me about eina on the beginning? I respect his decision, but looks like mine isnt respected. Assuming Peter contributed under the understanding that it was BSD licensed, then you're fine. Since eina didn't have a license in CVS, or he may not have bothered to check since everything else is BSD, he probably assumed it was BSD. It may not seem like it to you, but being in an external repository is a huge problem for something you want integrated into a bigger project and I think you're experience reinforces that. You are misquoting this argument. The argument is we can't easily inter-change code with LGPL because it's now a one way relationship. We can only put things INTO eina because if we take anything out, we have to use the LGPL or GPL. True, so? i understand that having that flexibility is something you are interested on, and i respect that; but i have a different vision there, doing that is what e has exactly been doing with no real gain, just moving/renaming and code things on a monolithic way; and i dont like that approach. Like you moved code from evas into eina? Evas is a large monolithic structure, and I agree that the data structures needed to be split out. There is otherwise not that much code shifting going on. What we do see here and there is a nice abstraction in a piece of code which then gets split out into a lib, and on occasion an abstraction that is really only useful in one case that gets moved into a different component. Here's a realistic example. What if I decide to use the memory pools API from eina in EWL, but we find evidence that the memory pools are actually worse in most use cases than the standard allocator (trust me this
Re: [E-devel] E CVS: proto/eina turran
This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. See, It's not about BSD vs LGPL. It's just that we can't and we must not have our core libs dual licensed. I'm not saying that you or anyone else is not contributing or have to fork the tree or whatever. Just keep the consistency in the core. If the WHOLE core base cannot be LGPL'd then dont LGPL the new parts of it. This is ridiculous. I respect you all, your work, your desire to change the license but this is not the way to go. -- Luchezar P. Petkov http://luchko.net - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
So your argument is that you don't need to justify your choices because you're more active right now? On Wed, Aug 6, 2008 at 8:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:16 PM, Mark Dickie [EMAIL PROTECTED] wrote: As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Also, this is exactly my point about being disrespectful and hurting the community. You are devaluating the opinions of volunteers in the community because you get to spend your paid time on it. I still contribute multiple hours each week to the project either through reviewing patches, helping evaluate bug reports or working with my SoC student. Apparently, this is of no value to you and anyone in that role should just leave. If that were the case, anyone in the project for more than two years shouldn't be allowed to speak up, because we've all had to cut back our commit levels at some points. On Wed, Aug 6, 2008 at 8:09 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:16 PM, Mark Dickie [EMAIL PROTECTED] wrote: As another long-term enlightenment user (since at least 2000) who has never entered these discussions before I'd like to add by tuppence worth too. Saying that you wish to increase the community while at the same time creating a serious rift which may cause people, devs or users, to be put off or leave is nonsensical. There is an established policy regarding licensing and it seems to a relative outsider to be both foolish and frankly rude to insist that your way is best when flying in the face of that policy when there is no concensus for change. This policy is not fitting current developer's need anymore, at least a big part of active developers. These developers are willing to invest even more efforts, making EFL even better, but they want some changes. People already said about forks and do these kind of things out of CVS or main project tree, but really, most of ACTIVE developers either do not care or are pro-LGPL, thus if one forks it, probably current cvs would die. Before anyone reply to this mail to flame me, just check the amount of benefits from those that are strictly BSD and those that want to move to LGPL, than judge who is doing any work and who is talking. I really wonder why these guys that do no code nowadays want so strongly to talk about these stuff, give up, go away, or help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: So your argument is that you don't need to justify your choices because you're more active right now? Basically, and because your license says so. As for keeping core consistent, we CAN, if this is the only blocker, relicense ALL core components as LGPL and keep individual files as BSD, this is perfectly doable, just need to have the file header with the proper license. BSD files, while cannot be relicensed, can be casted (like in strongly typed language's cast) to LPGL. So whenever, during runtime, you link against LGPL, your resulting process is governed by LGPL. LGPL, on the other side, when linked to GPL, results in GPL and so the process and associated libraries. If you make this linkage static, or files inside the same process (can be defined as static linkage as well), you have to consider it all as the most demaing (ie: LGPL). That means we can license the PROJECT (ie: evas, ecore) under LGPL without asking anyone, we don't even have to mention that some files inside the project are BSD (since we're open source and bsd-raster says we don't have to acknoldge if it's open source, just if it's closed we need to inform the authors). What we must do is to keep BSD files with the proper header, if one wants to be smart and take files to compose a proprietary product, he can go through every file and check if it's possible or not, but the project overview or advice is to be LGPL. And before you continue, your license permits this, it's ok for you. If you find this is WRONG, then we're in the same boat, and we should go to LGPL to progressively fix this, replacing BSD bits with code evolution. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Also, this is exactly my point about being disrespectful and hurting the community. You are devaluating the opinions of volunteers in the community because you get to spend your paid time on it. I still contribute multiple hours each week to the project either through reviewing patches, helping evaluate bug reports or working with my SoC student. And you forgot to include ... keeping the flamewar hot, since that's what you've being doing these days. Apparently, this is of no value to you and anyone in that role should just leave. If that were the case, anyone in the project for more than two years shouldn't be allowed to speak up, because we've all had to cut back our commit levels at some points. this have some value, but I guess in a meritocracy those doing more, have more rights. And my point is not about talking much, but doing few. As Jorge said, people talked and talked about split data library. Nobody did a shit, it was he that did the work. It will be he and some other few to convert the libs to use it. If you, instead of talking, did the split and ported the libs, nothing of this would happen. Nobody has any right to force you to do such things, but you have no right to impose your opinion on the others too. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] What would you like to see on the new site?
I'd like to see a new forum. The current one is pretty lame :( Perhaps something a little more standard or as folks like to say, Better. :) Toma 2008/8/5 Ian Caldwell [EMAIL PROTECTED]: whoops messed up on the link it's http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png On Mon, Aug 4, 2008 at 12:17 AM, Toma [EMAIL PROTECTED] wrote: On 04/08/2008, Ian Caldwell [EMAIL PROTECTED] wrote: absolutely and I believe in redoing the navigation would involve redoing the site. If anyone would like to share any other mock ups other than mekius go ahead. I personally like simple site designs like this: http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png(flame me if you want) minus the fact that I think the inkscape in brief section should be just a wider news section and take the little news box off the side. but I like designs like that because they list all the links to the different web software. Songbird does this on their site too but their site is a little too busy http://getsongbird.com/ just my thoughts I like the Inkscape mockup. Looks professional and has all the content at a place thats very easy to see. The icons help too for those that dont know english and cant be bothered switching to their language translation. Songbird one give me the idea of using some cool ajax for the icons. Since EFL and all can do cool animations, maybe something neat like that could make its way into the website? Toma On Sun, Aug 3, 2008 at 9:06 PM, dan sinclair [EMAIL PROTECTED] wrote: On 3-Aug-08, at 10:07 PM, Nick Hughart wrote: Carsten Haitzler (The Rasterman) wrote: On Fri, 01 Aug 2008 13:33:34 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Ian Caldwell wrote: Yup, I'd like to eliminate submenus completely One navigation on all pages that has links to pretty much everything. The goal of the new site is make it a lot more usable. With regularly updated news, and a lot of static content around it. This is bad design imo, it leads to overload. Having to dig through a ton of links to find the one you want is crazy, it's best to be able to filter towards your goal IMO. Much easier to filter then to try and find a link among many that sounds like what you want. This is how my brain works anyway. we don't need some new navigation system... we need to simplify content, only put up what we absolutely need on the e.org brochure site (it's meant to be a simple couple of pages brochure/flier like set of pages with just the minimum needed to find out what e is, who is involved, how/where to get it). the other bits (trac/bugzilla, wiki, docs etc. etc.) are what is intended for large-scale documentation and info - and those (the wiki especially) is READILY accessible to people to edit. Yes, I realize this, most of the links in the submenus will just point to the wiki/tracker/etc. But people found it hard to even find these things on the current site. So it would be nice to point them to where they need to look instead of them having to decode links that don't necessarily match anything they are looking for. So the changes to navigation are nothing stellar, just reorganizing the menu and making the submenu a little more visible so people immediately see things to click on. At least this is what I did with my mockup, haven't seen anyone else come forward with anything yet. I'm with Mekius. The number one complaint that I get about the website is that the navigation sucks. If we can do something to make it easier for people to find stuff then it's a win. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 8:45 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: So your argument is that you don't need to justify your choices because you're more active right now? Basically, and because your license says so. The license we're using does not say change the project-wide license decisions at the whim of newer committers. As for keeping core consistent, we CAN, if this is the only blocker, relicense ALL core components as LGPL and keep individual files as BSD, this is perfectly doable, just need to have the file header with the proper license. Yes, you can, though you can't use the names of components without permission as those belong to the authors No big deal renaming them though. BSD files, while cannot be relicensed, can be casted (like in strongly typed language's cast) to LPGL. So whenever, during runtime, you link against LGPL, your resulting process is governed by LGPL. LGPL, on the other side, when linked to GPL, results in GPL and so the process and associated libraries. If you make this linkage static, or files inside the same process (can be defined as static linkage as well), you have to consider it all as the most demaing (ie: LGPL). That means we can license the PROJECT (ie: evas, ecore) under LGPL without asking anyone, we don't even have to mention that some files inside the project are BSD (since we're open source and bsd-raster says we don't have to acknoldge if it's open source, just if it's closed we need to inform the authors). What we must do is to keep BSD files with the proper header, if one wants to be smart and take files to compose a proprietary product, he can go through every file and check if it's possible or not, but the project overview or advice is to be LGPL. And before you continue, your license permits this, it's ok for you. If you find this is WRONG, then we're in the same boat, and we should go to LGPL to progressively fix this, replacing BSD bits with code evolution. I know the license permits this, and I want it to permit it. Have fun, go fork a LGPL version of everything, couldn't care less. In fact I suggested that turran go do this to test his hypothesis that the choice of license is what is preventing community growth. I don't want the LGPL to be the single license for the official project because you now remove that freedom from anyone else choosing a different license in the future. Moving to the LGPL is a one-way change that we can't come back from without extraordinary effort. That would require getting permission from every author that contributed under the license, and it's already been shown that it's extremely difficult to track down past authors. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 8:55 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 10:42 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Also, this is exactly my point about being disrespectful and hurting the community. You are devaluating the opinions of volunteers in the community because you get to spend your paid time on it. I still contribute multiple hours each week to the project either through reviewing patches, helping evaluate bug reports or working with my SoC student. And you forgot to include ... keeping the flamewar hot, since that's what you've being doing these days. I guess so, although other people have spoken up and were ignored or given half-answers. I've received a number of private messages from community members that feel their voices are being ignored thanking me for not letting this license change slip in unchallenged. You think I like this ridiculous discussion? Not a bit, it's killing any motivation to do what little I can for E these days. I am only spending this much time because it's a very crucial and time sensitive issue. As I've learned in the past, if you don't speak up quickly on these things some people assume that means agreement. Apparently, this is of no value to you and anyone in that role should just leave. If that were the case, anyone in the project for more than two years shouldn't be allowed to speak up, because we've all had to cut back our commit levels at some points. this have some value, but I guess in a meritocracy those doing more, have more rights. And you get to choose the time scale and individual value of this meritocracy? How do I get that job? The way meritocracies work is that you gain respect within a community by contributing merit over a long period of time. You don't get granted authority by anyone, but people within the community weigh your opinion more heavily because of your long standing contributions. As I pointed out before, everyone that has worked on E for any significant amount of time has had a lull in their commit levels. You are not an exception to this rule either. And my point is not about talking much, but doing few. As Jorge said, people talked and talked about split data library. Nobody did a shit, it was he that did the work. It will be he and some other few to convert the libs to use it. Wrong again. I did this once already at least 6 years ago. At that time raster had decided that evas was not going to have any dependencies directly below it. As Jorge pointed out, his work has been sitting there for 2 years already. This was not about someone doing the work, but about the willingness to accept a data lib dependency on Evas. If you, instead of talking, did the split and ported the libs, nothing of this would happen. Nobody has any right to force you to do such things, but you have no right to impose your opinion on the others too. I already answered about the split. I am not the one trying to impose my opinion on the project. Did I come to the project and force us all to accept a new license? Have you refuted any of my reasons that I laid out for why this move doesn't make sense? There is a long email where I laid them out in detail. It got no real response from the proponents of this move, and the little response that I did get didn't counter any of my arguments. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 8:45 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 10:26 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: So your argument is that you don't need to justify your choices because you're more active right now? Basically, and because your license says so. The license we're using does not say change the project-wide license decisions at the whim of newer committers. As for keeping core consistent, we CAN, if this is the only blocker, relicense ALL core components as LGPL and keep individual files as BSD, this is perfectly doable, just need to have the file header with the proper license. Yes, you can, though you can't use the names of components without permission as those belong to the authors No big deal renaming them though. BSD files, while cannot be relicensed, can be casted (like in strongly typed language's cast) to LPGL. So whenever, during runtime, you link against LGPL, your resulting process is governed by LGPL. LGPL, on the other side, when linked to GPL, results in GPL and so the process and associated libraries. If you make this linkage static, or files inside the same process (can be defined as static linkage as well), you have to consider it all as the most demaing (ie: LGPL). That means we can license the PROJECT (ie: evas, ecore) under LGPL without asking anyone, we don't even have to mention that some files inside the project are BSD (since we're open source and bsd-raster says we don't have to acknoldge if it's open source, just if it's closed we need to inform the authors). What we must do is to keep BSD files with the proper header, if one wants to be smart and take files to compose a proprietary product, he can go through every file and check if it's possible or not, but the project overview or advice is to be LGPL. And before you continue, your license permits this, it's ok for you. If you find this is WRONG, then we're in the same boat, and we should go to LGPL to progressively fix this, replacing BSD bits with code evolution. I know the license permits this, and I want it to permit it. Have fun, go fork a LGPL version of everything, couldn't care less. In fact I suggested that turran go do this to test his hypothesis that the choice of license is what is preventing community growth. I don't want the LGPL to be the single license for the official project because you now remove that freedom from anyone else choosing a different license in the future. Moving to the LGPL is a one-way change that we can't come back from without extraordinary effort. That would require getting permission from every author that contributed under the license, and it's already been shown that it's extremely difficult to track down past authors. I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) dh - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 9:57 PM, Christopher Michael [EMAIL PROTECTED] wrote: I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) IANAL either, but the common understanding of the LGPL is that you are only allowed to relicense to GPL, and the GPL allows no relicensing. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] [website] What would you like to see on the new site?
I dont think the forums are getting much use. Few, if any, of the devs look at it, and while a bunch of users seem to post questions, there are very few answers. I'd like to see the forums turned off (made read-only) and the mailing lists really emphasized as the main location for discussions/support (apart from IRC). Eventually, we could install lurker on the server http://lurker.sourceforge.net/ tweak it to fit the website's style and add a web form so that people can send messages to the mailing list through the interface. (kinda like a hybrid mailing-list/forum) But for now, (k-s's suggestion) we could just link here http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/ Its at least more usable than sourceforge's UI. On Wed, Aug 6, 2008 at 10:00 PM, Toma [EMAIL PROTECTED] wrote: I'd like to see a new forum. The current one is pretty lame :( Perhaps something a little more standard or as folks like to say, Better. :) Toma 2008/8/5 Ian Caldwell [EMAIL PROTECTED]: whoops messed up on the link it's http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png On Mon, Aug 4, 2008 at 12:17 AM, Toma [EMAIL PROTECTED] wrote: On 04/08/2008, Ian Caldwell [EMAIL PROTECTED] wrote: absolutely and I believe in redoing the navigation would involve redoing the site. If anyone would like to share any other mock ups other than mekius go ahead. I personally like simple site designs like this: http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png(flame me if you want) minus the fact that I think the inkscape in brief section should be just a wider news section and take the little news box off the side. but I like designs like that because they list all the links to the different web software. Songbird does this on their site too but their site is a little too busy http://getsongbird.com/ just my thoughts I like the Inkscape mockup. Looks professional and has all the content at a place thats very easy to see. The icons help too for those that dont know english and cant be bothered switching to their language translation. Songbird one give me the idea of using some cool ajax for the icons. Since EFL and all can do cool animations, maybe something neat like that could make its way into the website? Toma On Sun, Aug 3, 2008 at 9:06 PM, dan sinclair [EMAIL PROTECTED] wrote: On 3-Aug-08, at 10:07 PM, Nick Hughart wrote: Carsten Haitzler (The Rasterman) wrote: On Fri, 01 Aug 2008 13:33:34 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Ian Caldwell wrote: Yup, I'd like to eliminate submenus completely One navigation on all pages that has links to pretty much everything. The goal of the new site is make it a lot more usable. With regularly updated news, and a lot of static content around it. This is bad design imo, it leads to overload. Having to dig through a ton of links to find the one you want is crazy, it's best to be able to filter towards your goal IMO. Much easier to filter then to try and find a link among many that sounds like what you want. This is how my brain works anyway. we don't need some new navigation system... we need to simplify content, only put up what we absolutely need on the e.org brochure site (it's meant to be a simple couple of pages brochure/flier like set of pages with just the minimum needed to find out what e is, who is involved, how/where to get it). the other bits (trac/bugzilla, wiki, docs etc. etc.) are what is intended for large-scale documentation and info - and those (the wiki especially) is READILY accessible to people to edit. Yes, I realize this, most of the links in the submenus will just point to the wiki/tracker/etc. But people found it hard to even find these things on the current site. So it would be nice to point them to where they need to look instead of them having to decode links that don't necessarily match anything they are looking for. So the changes to navigation are nothing stellar, just reorganizing the menu and making the submenu a little more visible so people immediately see things to click on. At least this is what I did with my mockup, haven't seen anyone else come forward with anything yet. I'm with Mekius. The number one complaint that I get about the website is that the navigation sucks. If we can do something to make it easier for people to find stuff then it's a win. dan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize
Re: [E-devel] E CVS: proto/eina turran
Nathan Ingersoll wrote: On Wed, Aug 6, 2008 at 9:57 PM, Christopher Michael [EMAIL PROTECTED] wrote: I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) IANAL either, but the common understanding of the LGPL is that you are only allowed to relicense to GPL, and the GPL allows no relicensing. Thanks for clearing that up Nathan. That being the case, then count my vote in the don't change license column please :) dh - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 11:09 PM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 9:57 PM, Christopher Michael [EMAIL PROTECTED] wrote: I'm not much of a lawyer, nor do I claim to know much about LGPL, but if in fact this is the case and we can't change back at a later date without much effort, then by all means put me down for the Not Changing crowd :) IANAL either, but the common understanding of the LGPL is that you are only allowed to relicense to GPL, and the GPL allows no relicensing. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Sort of ancillary to this discussion but as point of fact: GPL was designed to keep software free, away from people who would close it and then sell it. The Changing the license is hard with the GPL is very intentional and not entirely a negative point. It prevents someone from changing it 3 years later and making it not-free. If you read any of Richard Stallman the above comes through loud and clear everytime he talks, and like everybody else here, IANAL but that's common Stallman rhetoric. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Wed, Aug 6, 2008 at 10:19 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: Sort of ancillary to this discussion but as point of fact: GPL was designed to keep software free, away from people who would close it and then sell it. The Changing the license is hard with the GPL is very intentional and not entirely a negative point. It prevents someone from changing it 3 years later and making it not-free. If you read any of Richard Stallman the above comes through loud and clear everytime he talks, and like everybody else here, IANAL but that's common Stallman rhetoric. No disagreement from me on any of those points. Those are the reasons some people prefer it. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Licensing suggestion [OFFTOPIC]
http://en.wikipedia.org/wiki/Beerware To those unfamiliar with it /* * * THE BEER-WARE LICENSE (Revision 42): * [EMAIL PROTECTED] wrote this file. As long as you retain this notice you * can do whatever you want with this stuff. If we meet some day, and you think * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp * */ Its basically a modification on BSD. I think with all the gratitude towards whats already been done with EFL and friends in CVS (soon to be SVN), I think a lot of the contributors could reach the infamous 'Ballmer Peak' [1], which could then push E17 closer to a release. Otherwise, we could modify it to something along these lines. As long as you retain this notice you can do whatever you want with this stuff. If you wish to use this in a commercial product, you must supply the AUTHOR or AUTHORS with 1 case of beer each. Which is probably a little closer to a GPL type of Beerware license. I await your replies. Toma [1] http://xkcd.com/323/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
