Re: [E-devel] License questions
On Thu, Jul 24, 2008 at 12:25 PM, Vincent Torri [EMAIL PROTECTED] wrote: I've learned a lot about the licences reading these mails, and it seems that the fact is not such licence is a hindrance but such licence can give us developpers. That's different. So, from what i've understood, wrt companies : 1) either with stay with BSD, and only the companies that accept to work with code licenced under BSD would eventually share code with us 2) either we switch to, for example LGPL, or other similar licence (I was told that MPL is not that bad), and then companies that accept to share code with LGPL AND BSD licenced code would eventually help us. The difference can be great. So if we want to have more than 5 devs on the core efl, we should seriously discuss about which licence to use. First off, there are a lot of false assumptions and statements about history being thrown around in order to argue the point we should switch licenses. The library efforts around KDE and GNOME pre-date anything that is considered part of the EFL, or even the idea that E as a project is a platform. KDE is built on top of an already existing toolkit Qt which began development in 1991! A large proportion of the core development on this project is paid for by Trolltech (now Nokia). The functionality provided by Qt was a huge jumping off point to get KDE development rolling quickly. GTK+ on the other hand was written in 1997 for the GIMP and became a standalone library primarily because of the fact that the Qt license had a non-commercial use clause. This prevented it from being compatible with any OSI approved license (though OSI didn't exist at the time). For those people saying that E should be at the same place as GNOME, that is pretty off-base since E was the original GNOME window manager. Raster wrote the theme engine support for GTK+ while at RedHat, and E was being developed as part of the GNOME environment for a few years. Even after GNOME and E parted ways, we were still only a window manager and terminal project for the most part, with the only libraries being developed were for direct use by the window manager only. Also, if you look at the core libraries in use by GNOME, you would probably be surprised at how few people actually make changes to them on a regular basis. The advantage they tend to have is that there are enough people that some of them will touch GTK+ while others will touch another component such as Pango. Lastly, I think people are ignoring some major issues. For instance, the X desktop is so fragmented already between KDE and GNOME that it's hard for the majority of users to justify yet another major player that is not already established. As dan pointed out, we make this situation even worse by micro-fragmenting into duplicate projects within the E project. The fact that we don't have any applications that are clearly better than their counter-parts in other projects doesn't help either. We're reaching a point where many users never change their window manager or are content with the more integrated environments in KDE or GNOME, so providing a great window manager is a difficult selling point. We're seeing some nice headway in the embedded space, but this is an area that is difficult to attract broad community attention so far. So blaming the community size on the license seems like an exercise in finger pointing. Some of the most broadly adopted open source software is in the BSD/MIT/Apache family. FreeBSD is used extensively in server rooms (along with the other BSD's but they tend to be less popular). Apache drives a huge percentage of the web. Subversion is an example of commercially developed and supported software with the Apache license. X is on almost every Linux/UNIX desktop regardless of environment. Most operating systems TCP/IP implementations owe their roots to the code that came out of the original BSD distribution (though many of them have been re-implemented later). As you can tell, I'm pretty much against the idea of relicensing things, and I think the burden has been unfairly placed on the old guard, as Gustavo seems to want to characterize some of us as, to justify the license. Let's flip this around, does anyone have a way to show that changing our license would result in community growth? Nathan - 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] [EFM] Typebuf
Hello everyone.
Attached patch fixes a couple issues with current typebuf in EFM.
First, now typebuf is cleared out when you change current directory.
Second, it has a 5 seconds timeout, so if you don't type anything
during this time, it's cleared out too.
PS: Typebuf is a way for faster navigation in EFM, you type what you
what to find, and matching file is automatically selected.
--
King regards,
Fedor Gusev.
diff --git a/src/bin/e_fm.c b/src/bin/e_fm.c
index 4ede60e..b2c0ca8 100644
--- a/src/bin/e_fm.c
+++ b/src/bin/e_fm.c
@@ -97,6 +97,7 @@ struct _E_Fm2_Smart_Data
struct {
char*buf;
+ Ecore_Timer *timer;
} typebuf;
int busy_count;
@@ -596,6 +597,9 @@ e_fm2_path_set(Evas_Object *obj, const char *dev, const char *path)
_e_fm2_client_monitor_add(sd-id, sd-realpath);
sd-listing = 1;
}
+
+ /* Clean up typebuf. */
+ _e_fm2_typebuf_hide(obj);
evas_object_smart_callback_call(obj, dir_changed, NULL);
sd-tmp.iter = 0;
@@ -4373,6 +4377,24 @@ _e_fm2_typebuf_complete(Evas_Object *obj)
_e_fm2_typebuf_match(obj);
}
+static int
+_e_fm_typebuf_timer_cb(void *data)
+{
+ Evas_Object *obj = data;
+ E_Fm2_Smart_Data *sd;
+
+ if(!data) return 0;
+ sd = evas_object_smart_data_get(obj);
+ if (!sd) return 0;
+
+ if (!sd-typebuf_visible) return 0;
+
+ _e_fm2_typebuf_hide(obj);
+ sd-typebuf.timer = NULL;
+
+ return 0;
+}
+
static void
_e_fm2_typebuf_char_append(Evas_Object *obj, const char *ch)
{
@@ -4390,6 +4412,13 @@ _e_fm2_typebuf_char_append(Evas_Object *obj, const char *ch)
sd-typebuf.buf = ts;
_e_fm2_typebuf_match(obj);
edje_object_part_text_set(sd-overlay, e.text.typebuf_label, sd-typebuf.buf);
+
+ if(sd-typebuf.timer)
+ {
+ ecore_timer_del(sd-typebuf.timer);
+ }
+
+ sd-typebuf.timer = ecore_timer_add(5.0, _e_fm_typebuf_timer_cb, obj);
}
static void
-
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] [SoC] Evil, Eet win32 project files
Hi With this extern directory and your new Efl_win32.zip evil compiles. GREAT ! I will test eet tonight. thanks very much 2008/7/25 Dmitriy Mazovka [EMAIL PROTECTED]: Hello! Thank you for interest:). Sorry for compilation problems, it is my fault. Till today I had a plug instead of the current fnmatch, and when I placed normal version of it I didn't try to rebuild the project from scratch, so old .obj file was used, so I didn't see any errors:). However I corrected that and you can get a fresh Evil win32 directory at the same location: http://sionix.pbwiki.com/f/Evil_win32.zip About the second problem, I suppose we have different versions of unistd.h (at least). Because mine has only 48 lines. I took it and most of other files from MinGW. I think it will be better to provide proper version of libs:). You can download my extern directory at: http://sionix.pbwiki.com/f/extern.zip Please ask if you will have any problems again:). Best regards, Dzmitry -Original Message- From: Nicolas Aguirre [EMAIL PROTECTED] To: Dmitriy Mazovka [EMAIL PROTECTED] Date: Thu, 24 Jul 2008 23:38:11 +0200 Subject: Re: [E-devel] [SoC] Evil, Eet win32 project files Hi, I'mtrying to copile evil with Visual Studio 2005, but I have some troubles :) I think that I have found all files specified in your REAME, in fact I found all of them in GnuWin32 sourceforge repository. I have some problem with unistd.h, stdint.h and sys/param.h that are present in libgw32c package. Are these files the good one? I must include a lot of files that you have not specified, and wich are included by unistd.h or param.h. Attached my log error. Regards, Nicolas 2008/7/24 Dmitriy Mazovka [EMAIL PROTECTED]: Hello, I have updated the archive I posted before and provided the same package for Eet. And again I'd like to ask you to examine them and post any notes if you have. Here are they: http://sionix.pbwiki.com/f/Evil_win32.zip http://sionix.pbwiki.com/f/Eet_win32.zip Both should be unpacked to the proper library directories. Thank you, Dzmitry Mazouka -Original Message- From: Dmitriy Mazovka [EMAIL PROTECTED] To: enlightenment-devel@lists.sourceforge.net Date: Wed, 16 Jul 2008 22:07:11 +0400 Subject: [SoC] Evil win32 project files Hello, I'm one of the GSoC's students working on Enlightenment Win32 port project. Together with my mentor (Vincent Torri) we considered that Evil is currently in enough good shape to be submitted to the main repository. Please take a look to the archive I'm sending - it contains necessary sources and project files for Evil to be compiled with Microsoft Visual Studio 8. If there will be no objections, it will be commited in 2 days. Zip content should be unpacked to proto/Evil/ directory. Also pay attention to README and MANIFEST files. Link: http://sionix.pbwiki.com/f/Evil_win32.zip Best regards, Dzmitry Mazouka - 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 ATTACHMENT: application/octet-stream (evil_VS2005_compilation_error.log.log) - 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] License questions
dan sinclair schrieb: On 24-Jul-08, at 5:26 PM, Peter Wehrfritz wrote: Gustavo Sverzut Barbieri schrieb: One thing I'd like to see here is the opinion of those that do most of the code these days, guys like englebass, dj2, pfritz and raster. You wrote lots of code already, and continue to do, what do you think about relicensing the code under LGPL? I'm not an author of one of the core libs, but since you are asking me, here is what i think about it. I personally don't like the LGPL, because IMHO it doesn't really work for applications. It sounds somewhat odd if you read the license for an application and they only talk about libraries. And I strongly believe that one should use the same license for applications and libraries. It happens often that you move some code from a lib to an app and vice versa, or you turn a whole app into a library. So maybe something like MPL would be better, but afaik you get with the MPL troubles with the debian folks. Don't know how it is with the CPL. I still prefer the 3-clause BSD license, I code, because it is fun. If some makes money with my code, it doesn't change the fact that i had fun while writing it and he also doesn't steal my code. I still have my code! Besides that believing that a company contributes to your LGPLed library/application because it uses/modifies your code is wrong. Take a look on the khtml history and you'll see that using the lgpl doesn't implicate or ensure that you'll receive useful patches. At the end, this decision is not up to me. Couldn't have said it better myself. (Oh, and Peter, you are listed as a main author of Ewl (for almost a year and a half, heh)) I know :), I thought we are talking about the core-libs, of course, I hope that ewl will stay under the BSD 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] Porting E to an ARM based embedded system.
On Fri, Jul 25, 2008 at 4:31 AM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Be sure to give OpenEmbedded a try, this will give you a major kickstart. All of E is in OE. Openmoko is relying on OE as well. And it is WAY better than ltib. It have lots of packages, including E, and their system is more sane, you'd avoid having to do all the work on different places... -- 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] License questions
On Thu, Jul 24, 2008 at 11:08 PM, Michael Jennings [EMAIL PROTECTED] wrote: On Friday, 25 July 2008, at 00:41:51 (+1000), Carsten Haitzler wrote: if this is for code going into an existing application and/or library he is right. code is to be the same license as the existing tree - if it is to be a different license - it cannot go into the tree. this is simply standard practice. if someone wants to create a new library, a new app (and by this i would define it as having its own configure.in/ac and build tree) then they may choose any license they like. if they make is a GPL library - then it will never be used by me as a basis for any other apps that are not GPL (as the GPL thus infects). if it's LGPL - it's moot as the license does not extend beyond the boundaries of that library. if its an app - it doesn't matter. Assuming no one using another license ever wants to use that code. If Peter writes a really badass EWL app and LGPL's or GPL's it, that code could not be used in E or Evas (unless Peter himself relicensed it) without changing their licenses to LGPL/GPL. Yes. That's the exact purpose of the GPL/LPGL. The reason we originally required all items in the repo to be BSD licensed (and yes, this decision was made a long time ago) was so that code could be moved seamlessly between projects without having to worry about relicensing or infecting other projects. Worrying about the reuse of the code is a good thing. But imho when we move code around, most of the time it's our own code and we can always move our code around. And if it's not our code, I think it's nicer to discuss this before moving it. And please stop using infecting and word like that. Word matter and by choosing them unwisely you are encouraging troll and flamewar, not discussion. It sounds like you're rescinding that decision. If so, that's fine, but everyone needs to understand that code can't just move around at will any more. But it's your call. as i said - IMHO GPL is not right - it infects beyond the boundaries of its container. LGPL is acceptable. Unfortunately, so does the LGPL. Let's look at LGPLv2.1 first (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). According to Section 2a, any work based on the Library (that is, anything containing the Library's code, or any portion thereof, even just a single function or code block cut-and-pasted in) MUST itself be a LIBRARY. Wait, what? Yup, that's right. The LGPL forbids you from snagging a portion of code from an LGPL library and using it in a program (i.e., independent executable). In fact, I can't find anything anywhere in the LGPLv2.1 that allows it to be used for non-libraries. LGPLv3 doesn't appear to have this limitation, since Library is defined as any work covered by the LGPLv3. But LGPLv2.1 only covers objects you link with to create executables, not executables. So LGPL code cannot be used in applications (e.g., E itself). Yes, you can't move code from a LGPL library into a BSD licenced application. In fact, if you want to move code from a LGPL library to an application you should enable section 3 and this application should be GPL, but that's the exact purpose of the LGPL. LGPL give the freedom to link with the library whatever the licence of your app is, but you can't copy code from it in your app. Yes, that's the purpose of the LGPL. And in fact, most of the time, we should not copy code, but merge it and share it in a common place, a library. That's always a good software practice, but this argument is general and doesn't reflect any particular case. Perhaps you have in mind an example of a copy of code that could be usefull. Based on the clear language of the license, trying to apply it to a software program (like OpenOffice.org) doesn't seem to make any sense, since the legal term Library used throughout the license cannot apply to something like Writer which you would never link against to form executables. I think that Sun lawyer are not completely dumb and they did choose the licence carefully. And it will be LGPLv3 for next release, see http://www.openoffice.org/license.html. The only provision in LGPLv2.1 that would allow someone to use LGPL code in an application is Section 3 which allows the LGPL to be replaced by the GPL at any time (and at version 2 or any later version). So in order to cut-paste-and-modify code from an LGPL library into an application, the application MUST become GPL. Obviously this does not include linking, but one of the primary reasons we picked the license we did was so that our code could be used in other software under other licenses (Apache, Artistic, Mozilla, or yes, even the GPL). Because of Sections 2c and 3, any code coming from an LGPL project which is used in any way other than linking can only be used in GPL/LGPL software. Yes, that's the historic reason. Here's an example of the danger: Let's say EWL is BSD, and the authors want to
Re: [E-devel] License questions
On Thu, Jul 24, 2008 at 11:08 PM, Michael Jennings [EMAIL PROTECTED] wrote: On Friday, 25 July 2008, at 00:41:51 (+1000), Carsten Haitzler wrote: if this is for code going into an existing application and/or library he is right. code is to be the same license as the existing tree - if it is to be a different license - it cannot go into the tree. this is simply standard practice. if someone wants to create a new library, a new app (and by this i would define it as having its own configure.in/ac and build tree) then they may choose any license they like. if they make is a GPL library - then it will never be used by me as a basis for any other apps that are not GPL (as the GPL thus infects). if it's LGPL - it's moot as the license does not extend beyond the boundaries of that library. if its an app - it doesn't matter. Assuming no one using another license ever wants to use that code. If Peter writes a really badass EWL app and LGPL's or GPL's it, that code could not be used in E or Evas (unless Peter himself relicensed it) without changing their licenses to LGPL/GPL. Yes. That's the exact purpose of the GPL/LPGL. The reason we originally required all items in the repo to be BSD licensed (and yes, this decision was made a long time ago) was so that code could be moved seamlessly between projects without having to worry about relicensing or infecting other projects. Worrying about the reuse of the code is a good thing. But imho when we move code around, most of the time it's our own code and we can always move our code around. And if it's not our code, I think it's nicer to discuss this before moving it. And please stop using infecting and word like that. Word matter and by choosing them unwisely you are encouraging troll and flamewar, not discussion. It sounds like you're rescinding that decision. If so, that's fine, but everyone needs to understand that code can't just move around at will any more. But it's your call. as i said - IMHO GPL is not right - it infects beyond the boundaries of its container. LGPL is acceptable. Unfortunately, so does the LGPL. Let's look at LGPLv2.1 first (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). According to Section 2a, any work based on the Library (that is, anything containing the Library's code, or any portion thereof, even just a single function or code block cut-and-pasted in) MUST itself be a LIBRARY. Wait, what? Yup, that's right. The LGPL forbids you from snagging a portion of code from an LGPL library and using it in a program (i.e., independent executable). In fact, I can't find anything anywhere in the LGPLv2.1 that allows it to be used for non-libraries. LGPLv3 doesn't appear to have this limitation, since Library is defined as any work covered by the LGPLv3. But LGPLv2.1 only covers objects you link with to create executables, not executables. So LGPL code cannot be used in applications (e.g., E itself). Yes, you can't move code from a LGPL library into a BSD licenced application. In fact, if you want to move code from a LGPL library to an application you should enable section 3 and this application should be GPL, but that's the exact purpose of the LGPL. LGPL give the freedom to link with the library whatever the licence of your app is, but you can't copy code from it in your app. Yes, that's the purpose of the LGPL. And in fact, most of the time, we should not copy code, but merge it and share it in a common place, a library. That's always a good software practice, but this argument is general and doesn't reflect any particular case. Perhaps you have in mind an example of a copy of code that could be usefull. Based on the clear language of the license, trying to apply it to a software program (like OpenOffice.org) doesn't seem to make any sense, since the legal term Library used throughout the license cannot apply to something like Writer which you would never link against to form executables. I think that Sun lawyer are not completely dumb and they did choose the licence carefully. And it will be LGPLv3 for next release, see http://www.openoffice.org/license.html. The only provision in LGPLv2.1 that would allow someone to use LGPL code in an application is Section 3 which allows the LGPL to be replaced by the GPL at any time (and at version 2 or any later version). So in order to cut-paste-and-modify code from an LGPL library into an application, the application MUST become GPL. Obviously this does not include linking, but one of the primary reasons we picked the license we did was so that our code could be used in other software under other licenses (Apache, Artistic, Mozilla, or yes, even the GPL). Because of Sections 2c and 3, any code coming from an LGPL project which is used in any way other than linking can only be used in GPL/LGPL software. Yes, that's the historic reason. Here's an example of the danger: Let's say EWL is BSD, and the authors want to
Re: [E-devel] License questions
On Fri, Jul 25, 2008 at 4:03 AM, Michael Jennings [EMAIL PROTECTED] wrote: On Friday, 25 July 2008, at 01:53:24 (+0200), Jorge Luis Zapata Muga wrote: If you think that a project is successful based on how many companies have used your software then of course actually licensing your sw is not a matter just give it to the world, bsd license is the most free license (afaik) that you can have and of course you'll find thousands of projects that are out there being closed or open that use your software, so your meaning of successful is achieved. So for companies that actually want to use someone else code (because of a technical decision or not), and dont want or can't send something back (code, money, whatever) to the author then bsd is the best option. And that is indeed what happense on many on the companies that use bsd code, they dont give back code, of course they are not obligated to do so, its your license that allows that, but is that what we want? You make a good point about how we measure success in terms of the previous assertions about one license or the other making us more successful. You're absolutely right. And everything you said about the BSD license is also completely true and fair. As for the final question, is that what we want? From my perspective, it goes back to what Nathan said: Parts that are directly a *part of* EFL are almost certainly going to be given back because the cost of maintaining a fork (or a parallel LoD) is not insignificant. Works based on (i.e., making use of) the EFL which are separate, independent entities are almost certainly not going to be given back anyway because that's from where the company's profit is derived. That's just wrong. Maintaining a fork is in my opinion completely doable and will really not cost much. We are a few people, with less 5 of us breaking things in the core. I have almost 20 differents git branch on my hard drive of the CVS. Each of them could be considered as a fork. In fact they are just big change waiting for review or a good time to break E CVS again. Nothing force me to give them back, running a git pull is enought most of the time for keeping this fork alive and running. If your meaning of successful is on how many developers are out there on bsd or *gpl projects, i really dont know the statistics, but i think gpl is beyond, might be something related with the media, maybe, but the number of developers is something we need. I'm not sure the simple quantity of developers on BSD- versus GPL-licensed projects is the right metric; a developer working on a GPL project may or may not be willing to contribute to a BSD project, and vice versa. Same with companies. Some companies like the GPL because it prevents competitors from co-opting, closed-sourcing, and extending their code. (This is the argument that Active Directory might not exist if Kerberos and OpenLDAP had been GPL'd instead of BSD'd. Then again, AD being based primarily on open standards helped quite a bit with creating free software that talks to AD...a task which would've been much harder had it been completely opaque and proprietary.) Other companies prefer the BSD license because promotes wider use and does not require them to give up their intellectual property rights. But as my initial question, what happens with companies that actually want to give something back, that believe in the concept of community but dont want other companies that dont share the same vision as you to use the code to make profit, close source, etc? i think that for that case (and is not a small group of companies that are working like that right now) bsd is not an option. When you release something under the BSD license, it is always under the BSD license. In order to closed-source it, they would have to make extensive modifications and provide significant value-add; otherwise, no one would use it when there's a freely-available BSD alternative. I don't understand your statement. The BSD license give you the right to distribute just the binary. It doesn't say anything about the amount of change you need to do to distribute it in binary form. And a modified EFL library distributed as a binary is useless expect for the application that was designed to use it. So yes, people will use the freely availabe one, but nobody benefit from the improvement and change made for the binary one. But that's just the purpose of the BSD license. Active Directory is the only example I can think of right now where somebody did that to great success, and the success of AD was not due to AD itself, but rather the GUI tools they provided that made it easy (for some definition of that word) to set up and manage. X is actually a very good example of the opposite happening -- all the major UNIX vendors cooperated and collaborated to the mutual benefit of all. They did the same with CDE (taking HP's VUE front-end combined with Sun's
Re: [E-devel] License questions
On Fri, Jul 25, 2008 at 4:03 AM, Michael Jennings [EMAIL PROTECTED] wrote: On Friday, 25 July 2008, at 01:53:24 (+0200), Jorge Luis Zapata Muga wrote: Well, this thread has of course mutated from its original form, but has raised several good opinions, and in fact it has turned into what do we do internally with the efl. I tried to point people back to your original question, but I seem to have failed. :-] If you think that a project is successful based on how many companies have used your software then of course actually licensing your sw is not a matter just give it to the world, bsd license is the most free license (afaik) that you can have and of course you'll find thousands of projects that are out there being closed or open that use your software, so your meaning of successful is achieved. So for companies that actually want to use someone else code (because of a technical decision or not), and dont want or can't send something back (code, money, whatever) to the author then bsd is the best option. And that is indeed what happense on many on the companies that use bsd code, they dont give back code, of course they are not obligated to do so, its your license that allows that, but is that what we want? You make a good point about how we measure success in terms of the previous assertions about one license or the other making us more successful. You're absolutely right. And everything you said about the BSD license is also completely true and fair. As for the final question, is that what we want? From my perspective, it goes back to what Nathan said: Parts that are directly a *part of* EFL are almost certainly going to be given back because the cost of maintaining a fork (or a parallel LoD) is not insignificant. Works based on (i.e., making use of) the EFL which are separate, independent entities are almost certainly not going to be given back anyway because that's from where the company's profit is derived. If your meaning of successful is on how many developers are out there on bsd or *gpl projects, i really dont know the statistics, but i think gpl is beyond, might be something related with the media, maybe, but the number of developers is something we need. I'm not sure the simple quantity of developers on BSD- versus GPL-licensed projects is the right metric; a developer working on a GPL project may or may not be willing to contribute to a BSD project, and vice versa. Same with companies. Some companies like the GPL because it prevents competitors from co-opting, closed-sourcing, and extending their code. (This is the argument that Active Directory might not exist if Kerberos and OpenLDAP had been GPL'd instead of BSD'd. Then again, AD being based primarily on open standards helped quite a bit with creating free software that talks to AD...a task which would've been much harder had it been completely opaque and proprietary.) Other companies prefer the BSD license because promotes wider use and does not require them to give up their intellectual property rights. But as my initial question, what happens with companies that actually want to give something back, that believe in the concept of community but dont want other companies that dont share the same vision as you to use the code to make profit, close source, etc? i think that for that case (and is not a small group of companies that are working like that right now) bsd is not an option. When you release something under the BSD license, it is always under the BSD license. In order to closed-source it, they would have to make extensive modifications and provide significant value-add; otherwise, no one would use it when there's a freely-available BSD alternative. Active Directory is the only example I can think of right now where somebody did that to great success, and the success of AD was not due to AD itself, but rather the GUI tools they provided that made it easy (for some definition of that word) to set up and manage. X is actually a very good example of the opposite happening -- all the major UNIX vendors cooperated and collaborated to the mutual benefit of all. They did the same with CDE (taking HP's VUE front-end combined with Sun's tooltalk backend and making a desktop that ran on all 3 major UNIXes). I think we should take this topic in the sense of what do we want or expect from the e project. So for me and my vision of how e should be, i want e to be open source, but i want all of its derivative work to be also open source, i dont want to code on this project for the next 5 years and suddenly the number of developers (which is small) goes to zero, a company takes our code, close source it, and then you see your code on the next cell phone you buy, it will be frustrating. I think many of us want to make a living from it, at the end is our effort and sacrifice that is in discussion here. Would it really frustrate you to see code you
[E-devel] Nightly build log for E17 on 2008-07-25 07:10:57 -0700
Build log for Enlightenment DR 0.17 on 2008-07-25 07:10:57 -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] [EFM] Typebuf
typebuf should understand some basic shell commands like cd, cd -, cd ~, cd .., that would be cool and even faster :) On Fri, Jul 25, 2008 at 10:30 AM, Гусев Фёдор [EMAIL PROTECTED] wrote: Hello everyone. Attached patch fixes a couple issues with current typebuf in EFM. First, now typebuf is cleared out when you change current directory. Second, it has a 5 seconds timeout, so if you don't type anything during this time, it's cleared out too. PS: Typebuf is a way for faster navigation in EFM, you type what you what to find, and matching file is automatically selected. -- King regards, Fedor Gusev. - 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] License questions
On Friday, 25 July 2008, at 15:49:01 (+0200), Cedric BAIL wrote: That's just wrong. No, it's not just wrong. You may not agree with it, but that doesn't make it wrong, particularly if you don't offer any counterexamples or evidence to prove it. Maintaining a fork is in my opinion completely doable and will really not cost much. If maintaining a fork were easy, there'd be who-knows-how-many old Linux kernel forks still alive, samba-tng would not be foundering, and Canonical would only have to employ salespeople. It's simply not that easy. Ask RedHat how many developers they employ to maintain the kernel packages for each of their distros (which are essentially forks, albeit with a well-defined life span). It's doable but costly, and more often than not, the costs outweigh the gains. And none of the successful forks I can think of, including the ones I mentioned, are closed forks, other than the previous example I gave yesterday (of which I've yet to see another). (And regarding that one example, I'll say it again: The fact that Microsoft *used* the standard proves that the BSD license did its job: promoting use and sharing.) We are a few people, with less 5 of us breaking things in the core. I have almost 20 differents git branch on my hard drive of the CVS. Each of them could be considered as a fork. In fact they are just big change waiting for review or a good time to break E CVS again. Nothing force me to give them back, running a git pull is enought most of the time for keeping this fork alive and running. And for how long would you do this? 6 months? A year? Two? The longer you try to keep it up, the harder and harder it gets. Trust me; I've done it multiple times for a year or more. Costs increase exponentially with time. I don't understand your statement. The BSD license give you the right to distribute just the binary. It doesn't say anything about the amount of change you need to do to distribute it in binary form. Distributing a binary doesn't make it closed source. If you make changes and *then* distribute a binary, your changes are closed source, but as I said, unless they're appreciably different from the original, it's not compelling or significant. And a modified EFL library distributed as a binary is useless expect for the application that was designed to use it. So yes, people will use the freely availabe one, but nobody benefit from the improvement and change made for the binary one. Which is why that generally doesn't happen: they gain nothing by keeping it closed, but they could potentially gain a great deal from opening it. And they tend to do just that. Mission accomplished. :-) Yes, X is a good example. They did fork to solve some of their problem. And why did they fork? Because the previous project lead changed the license. Q.E.D. ;-) You got the point. Today we need less than 5 trucks to stop this project. This is an issue. By switching the core library to LGPL, it will be easier to advocate them and gain more core developper. See, people keeping saying that, but so far there's been absolutely no proof or evidence whatsoever that this is actually true. It's nice to see my code running on any device that's sure, but I really don't care. What I care is about this project. I want it to grow, to be faster, smaller and have more features (nah, it's possible :-) ). I want it to be strong and survive 5 trucks. I want to see more beautifull apps using it. I don't think anyone is disagreeing with those things. But so far no one has proven that changing the license will accomplish that. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- It's late in the evening. She's wondering what clothes to wear. She puts on her make up and brushes her long, blonde hair. And then she asks me, 'Do I look alright?' And I say, 'Yes, you look wonderful tonight.'-- Eric Clapton, Wonderful Tonight - 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] License questions
On Friday, 25 July 2008, at 15:56:20 (+0200), Jorge Luis Zapata Muga wrote: I think all the above points are frustrating , why? simply because *i* dont want that my effort makes others take profit and dont give anything to me. Of course you'll be proud that your library/application is used on something you buy on the store, that's great, but pride doesnt buy bread. Again we are on the same discussion of success, for you and all the pure freedom guys, what really matters is that you are the author of what is being used by others, that's why you use the three clause bsd license and not the two clause license, because at some point you want the recognition, and that's it. I dont think that kind of thinking fits well on a market, but that's me, unless you dont care on the market. I think there are two points to note here. First, the core E project has never been about profit, and it still isn't IMHO. Second, the EFL are exactly that: Foundation Libraries. That means that they sit underneath other stuff, and they're useless without applications that use them. That's where the opportunity for profit is: applications, not libraries. And contributing back to the community which creates the foundation for your application only helps insure its success and longevity. I think if your idea is to actually do whatever with my code why the third clause? You missed a bit. Do whatever with my code so long as you give credit where it's due. That last part is important too, whether attribution is in the form of credit or contribution to the community. For me the success is not how many people use it, but if im able to live from what i code on my spare time with my own ideas on not my boss' and of course being part of the os community, that's it, and bsd doesnt allows me that BSD allows you to be part of the OSS community. Whether or not it allows you to make a living from writing code has more to do with the company than the license. I can think of people making a living doing BSD code, public domain code, MPL code, IPL code, and of course closed source. The license simply isn't the make-or-break factor; it's the company and the business model. Of all the for-profit companies whose revenues are derived 100% from software alone, I can't think of too many doing strictly open source under *any* license, *GPL or otherwise. I think pretty much everyone would like to get paid to do something they'd do anyway. That's the dream. But it's very rare, and IMHO, not something to steer a project by. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- You know, we're sitting on four million pounds of fuel, one nuclear weapon, and a thing that has 270 thousand moving parts built by the lowest bidder. Makes you feel good, doesn't it? -- Steve Buscemi (Rockhound), Armageddon - 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] License questions
On Friday, 25 July 2008, at 14:33:25 (+0200), Cedric BAIL wrote: Yes. That's the exact purpose of the GPL/LPGL. I know what the purpose is. I've read both quite thoroughly. Worrying about the reuse of the code is a good thing. But imho when we move code around, most of the time it's our own code and we can always move our code around. This statement indicates that there is a fundamental misunderstanding when it comes to copyright law and ownership. We do not own anything because we are not a legal entity. So there is no such thing as our code. There is raster's code, and there's devilhorns' code, and there's your code...but there's no our code. And I don't believe there's anything anywhere that says all code committed to the repository requires assignment of copyright to any person or organization. Thus, the code is owned solely by the author. And please stop using infecting and word like that. Word matter and by choosing them unwisely you are encouraging troll and flamewar, not discussion. The term is accurate and is commonly used when referring to the manner in which the terms of a particular license may exert unexpected or unintended influence over works covered by another license. Even Lawrence Rosen himself used the same term, and not just with regard to the GPL: http://www.linuxjournal.com/article/5670 Yes, you can't move code from a LGPL library into a BSD licenced application. In fact, if you want to move code from a LGPL library to an application you should enable section 3 and this application should be GPL, but that's the exact purpose of the LGPL. LGPL give the freedom to link with the library whatever the licence of your app is, but you can't copy code from it in your app. Yes, that's the purpose of the LGPL. And that's exactly what we DON'T want to have happen. As raster said, the GPL is clearly bad. All I'm pointing out is that the LGPL has some, but not all, of the same implications. And in fact, most of the time, we should not copy code, but merge it and share it in a common place, a library. That's always a good software practice, but this argument is general and doesn't reflect any particular case. Perhaps you have in mind an example of a copy of code that could be usefull. Almost all the arguments, from all sides, have been general and hypothetical. So the precedent is set for not needing to cite a particular case. Suppose raster has some particularly elegant border-handling code in E, and EWL wants to copy and adapt it for use with widget layouts. Or vice versa. Whatever. What's important is that the need to move code around occurs routinely within large software projects, especially those under heavy development. I think that Sun lawyer are not completely dumb and they did choose the licence carefully. But we don't know their reasoning, nor do they work for us. Without the advice of our own legal counsel, we can't afford to do things that are potentially legally questionable...particularly not based on what someone else's lawyer determined about their specific situation. Their is a condition in the LGPL that you missed, in section 5, you can include header from the library with small inline, if that's what you want. No, I didn't miss it. It only covers headers and only to a maximum of 10 lines. But again, that's not the point. We are not lawyers, so doing something that isn't clearly and obviously defined within the plain language of the license is simply not a wise move. If you want to talk about something that could keep businesses from being able to use E, how about a legally-dubious license flop? You saw what happened to XFree86 when they tried that. And I am in favor of switching the core EFL to LGPL, not E and I perhaps missunderstood others on this, but we are speaking about the core library (eet,embryo,evas,ecore and edje). Who says what is core and what isn't? What about e_dbus? efreet? the much-discussed data type library? No, that's just wrong. Again, it's not wrong simply because you disagree with it. You can't make statements like that without defending them (well, you can, but they aren't inherently valid), and everything you go on to say is about our situation specifically and does not in any way refute that the LGPL can still infect BSD code in the situations I previously outlined. The way I understand your reasoning is that we will pick code from one of the core library put it in E. Then switch E to GPL. Then you will take code from E and EWL will become GPL too. I was illustrating a point, describing a scenario that could potentially occur. This will not happen. That's not the plan. There isn't a plan yet. That doesn't mean the described scenario is impossible, because it isn't. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
Re: [E-devel] License questions
Jose Gonzalez schrieb: Peter wrote: to it and the original code was LGPL. But would you share code with someone, that doesn't share code with you? Good point. And that's precisely why many people don't like to contribute to bsd licensed projects. In the case of corporations, this is an even more serious issue - a total 'no' in many instances. With share I didn't mean make it accessible for someone else, but bring it into a shape where he can use it. That are two different things. Of course you can take bsd code an add it into your lgpl lib. But I meant, if I would change it that way, i.e. writting a patch that it can be seamlessly used. There is difference between the offer I give you my code and it'd be nice if you give me something back and the dictate Take my code, but you have to use _my_ license and put it on some random website, no matter if it is useful for me or not. - 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] License questions
On Fri, 25 Jul 2008 15:16:17 -0700 Michael Jennings [EMAIL PROTECTED] wrote: We do not own anything because we are not a legal entity. So there is no such thing as our code. There is raster's code, and there's devilhorns' code, and there's your code...but there's no our code. Which is precisely why any change is a wasted effort. There is an email circulating asking all known authors of EFL their opinion on changing the license. The CC list is massive, so much so that my email server refused to send my reply and I had to trim out some addresses. Even then I got 10 bounces due to email addresses no longer existing. To change the license we need a unanimous decision by every author. That is very likely not possible. There may or may not be any gains in changing, but I doubt the gains will be worth the huge effort. The effort is very likely to fail anyway. Can we get back to coding now? signature.asc Description: PGP signature - 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] License questions
2008/7/26 Jose Gonzalez [EMAIL PROTECTED]: Peter wrote: to it and the original code was LGPL. But would you share code with someone, that doesn't share code with you? Good point. And that's precisely why many people don't like to contribute to bsd licensed projects. In the case of corporations, this is an even more serious issue - a total 'no' in many instances. And here is a quote from a Microsoft guy about the GPL. http://www.microsoft.com/presspass/exec/craig/05-03sharedSource.mspx Some of the most successful OSS technology is licensed under the GNU General Public License or GPL. The GPL mandates that any software that incorporates source code already licensed under the GPL will itself become subject to the GPL. When the resulting software product is distributed, its creator must make the entire source code base freely available to everyone, at no additional charge. This viral aspect of the GPL poses a threat to the intellectual property of any organization making use of it. It also fundamentally undermines the independent commercial software sector because it effectively makes it impossible to distribute software on a basis where recipients pay for the product rather than just the cost of distribution. So theres a real world example of why a company doesnt use GPL licenses. Theres also a good point about forking just before that paragraph... The OSS development model leads to a strong possibility of unhealthy forking of a code base, resulting in the development of multiple incompatible versions of programs, weakened interoperability, product instability, and hindering businesses ability to strategically plan for the future. Furthermore, it has inherent security risks and can force intellectual property into the public domain. Now seriously, dont debate these point on this thread, its already long enough. Someone said it before on this thread but I cant find it; Coding is fun. Let keep it that way. Toma Click here for great computer networking solutions! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMVYr1xjZP1AyqKTjJx1EpLLgUn7EjKWn7F253A18fomU/ - 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] License questions
On 25-Jul-08, at 7:48 PM, Jose Gonzalez wrote: Peter wrote: to it and the original code was LGPL. But would you share code with someone, that doesn't share code with you? Good point. And that's precisely why many people don't like to contribute to bsd licensed projects. In the case of corporations, this is an even more serious issue - a total 'no' in many instances. Also precisely why I try to avoid the GPL. The sharing comes with serious restrictions. Also a total no in many instances for corporations. 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
