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) ----------------------------------------------------------------------- "The first lesson reading teaches is how to be alone." -- Jonathan Franzen ------------------------------------------------------------------------- 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=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
