Re: [Gimp-developer] Refactoring code from GPL to LGPL
Dave Neary ([EMAIL PROTECTED]) wrote: Manish Singh wrote: Dave, ask yourself why you replied to this. The thread was long finished, and *you* certainly didn't contribute anything meaningful to it. And if you must reply to this, don't clutter the list with it further. My contribution was limited to showing that there is at least one person around here who doesn't think it's acceptable to treat people the way that you did. And since when are you the lord and master of what gets to clutter the list or not? Please take that flamewar into personal Mail. Thanks. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
I would like to point out that even if you feel compelled to respond to a rude comment (usually it is better to be silent), you still have the choice whether to be more rude or less rude. Being more rude will almost always escalate the problem. At this point the evolution of this discussion is still mainly an improvement on the way things have gone in this list in the past, and if you just let it die out, you can still on the whole treat it as a victory of reason over flamage. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Manish Singh wrote: Dave, ask yourself why you replied to this. The thread was long finished, and *you* certainly didn't contribute anything meaningful to it. And if you must reply to this, don't clutter the list with it further. My contribution was limited to showing that there is at least one person around here who doesn't think it's acceptable to treat people the way that you did. And since when are you the lord and master of what gets to clutter the list or not? Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
OFF TOPIC [Gimp-developer] Refactoring code from GPL to LGPL
maybe this issue can be solved sportively during a boxing match on the GUADEC conference. ;-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Manish Singh wrote: snip But it's pretty clear that you never bother to do any research before posting. snip You must have some weird sort of logic goes on in your head that made you conflate these things. snip But your postings leave the impression that you do not understand it. Then again, this disjoint thinking is probably one of the reasons there hasn't been much progress on your project. Was there any reason to be this unpleasant, yosh? This thread was long finished, and you certainly didn't contribute anything meaningful to it - wouldn't it have been easier to say nothing than be an asshole? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Sun, May 23, 2004 at 09:11:49PM +0200, David Neary wrote: Hi, Manish Singh wrote: snip But it's pretty clear that you never bother to do any research before posting. snip You must have some weird sort of logic goes on in your head that made you conflate these things. snip But your postings leave the impression that you do not understand it. Then again, this disjoint thinking is probably one of the reasons there hasn't been much progress on your project. Was there any reason to be this unpleasant, yosh? This thread was long finished, and you certainly didn't contribute anything meaningful to it - wouldn't it have been easier to say nothing than be an asshole? I *did* contribute something meaningful, which you seem to have conveniently snipped out: the fact that clueless Robin completely missed the point that there was plenty of refactoring done into GPL libraries, quite independent of the PDB infastructure. The reason to be so harsh is that Robin keeps on spreading his lies and misinformation about the GIMP project. He completely deserves to be called on his lack of understanding and knowledge, and his complete inexperience with real software development. Dave, ask yourself why you replied to this. The thread was long finished, and *you* certainly didn't contribute anything meaningful to it. And if you must reply to this, don't clutter the list with it further. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Manish Singh wrote: snipped out: the fact that clueless Robin completely missed the point that there was plenty of refactoring done into GPL libraries, quite independent of the PDB infastructure. [...] misinformation about the GIMP project. He completely deserves to be called on his lack of understanding and knowledge, and his complete inexperience with real software development. Hmm ... seeing as most decisions seem to be made on IRC, patches are only accepted if they are attached to bugs in the BTS, and evidently it's some great sin to ask a question here, what exactly IS the purpose of this mailing list? Or is Robin just special? I would imagine that if there are any archives of this mailing list that people can search that the number of flagrantly ignorant questions would go down. Of course, if the list archives convery no knowledge except 'ask not lest ye don asbestos and return none the wiser' that the archives are better off nonexistant. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Sun, May 23, 2004 at 07:19:20PM -0400, Christopher Curtis wrote: Manish Singh wrote: snipped out: the fact that clueless Robin completely missed the point that there was plenty of refactoring done into GPL libraries, quite independent of the PDB infastructure. [...] misinformation about the GIMP project. He completely deserves to be called on his lack of understanding and knowledge, and his complete inexperience with real software development. Hmm ... seeing as most decisions seem to be made on IRC, patches are only accepted if they are attached to bugs in the BTS, and evidently it's some great sin to ask a question here, what exactly IS the purpose of this mailing list? Or is Robin just special? I would imagine that if there are any archives of this mailing list that people can search that the number of flagrantly ignorant questions would go down. Of course, if the list archives convery no knowledge except 'ask not lest ye don asbestos and return none the wiser' that the archives are better off nonexistant. Robin *is* a special idiot. He is Mr. Cinepaint, which is heavily based on the film branch of gimp, from the 1.0 days. For someone who has supposedly been working with the filmgimp codebase for so long, he displays a pretty major lack of understanding of how the code works, and how free software licensing works. He has continually spread lies and misinformation about the GIMP project, in some strange attempt to promote his own project. I suspect it's trying to make a smokescreen to cover up his obvious technical inadequacies and inexperience. If a newbie had asked the same question he did, it would've been fine, and this is the appropriate forum. But Robin is not a newbie: he claims to have been working on the filmgimp code for years. On top of that, he has been badmouthing the GIMP project for years, with no basis, so I'm going to call him on his idiocy. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Thu, May 13, 2004 at 12:44:51AM -0700, Robin Rowe wrote: Dave, It seems like you're limiting refactoring to code re-use via extraction to libraries. No, I'm using the same definition that Mat refers to: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - Martin Fowler on http://www.refactoring.com/ What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. My question was why not being able to do that due to license barriers isn't a significant obstacle to long term GIMP code maintenance. Sven has answered that question. The client-server design of the PDB sidesteps the license issue by exposing functionality in app (which includes the PDB) without linking (instead using sockets). This works for GIMP because no other apps use libgimp as a system library except for GIMP plug-ins, and plug-ins all expect to talk to the GIMP app rather than run independently without it. Actually, you missed the point. There's been plenty of refactoring, and most of the 2.x app code *is* separated into libraries. But it's pretty clear that you never bother to do any research before posting. Also, moving code into a library doesn't mean the license has to be changed to LGPL. It's perfectly valid to have a GPLed library. You must have some weird sort of logic goes on in your head that made you conflate these things. It's very odd that you'd be confused about such basic architectural issues when you've been dealing with the filmgimp codebase for this long. The PDB is a pretty fundamental part of GIMP from way back, and it really hasn't changed. But your postings leave the impression that you do not understand it. Then again, this disjoint thinking is probably one of the reasons there hasn't been much progress on your project. Just leave this criticism be and do not reply. Since you've spread a ton of FUD and lies about GIMP already, do not expect any privleges here. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Robin Rowe wrote: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - Martin Fowler on http://www.refactoring.com/ This is exactly what happened to the code in /app between 1.2 and 2.0 - its internal structure changed drastically, without reducing its external behaviour. Although of course, not only was the code refactored, quite a few features were implemented with the new structure too. What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. I would rather say that the modularising of an architecture, the separation of distinct functionality into distinct modules, is an essential part of refactoring. Putting this functionality into a library is simply a matter of passing the linker the right flags. Sven has answered that question. The client-server design of the PDB sidesteps the license issue by exposing functionality in app (which includes the PDB) without linking (instead using sockets). Actually, shared memory. But it amounts to the same thing. It's all IPC. Appreciate the clarification. No problem :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Dave, It seems like you're limiting refactoring to code re-use via extraction to libraries. No, I'm using the same definition that Mat refers to: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - Martin Fowler on http://www.refactoring.com/ What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. My question was why not being able to do that due to license barriers isn't a significant obstacle to long term GIMP code maintenance. Sven has answered that question. The client-server design of the PDB sidesteps the license issue by exposing functionality in app (which includes the PDB) without linking (instead using sockets). This works for GIMP because no other apps use libgimp as a system library except for GIMP plug-ins, and plug-ins all expect to talk to the GIMP app rather than run independently without it. Appreciate the clarification. Thanks, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Open source digital motion picture film software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Sven Neumann wrote: Robin Rowe [EMAIL PROTECTED] writes: I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Good technical anwer, thanks. Well, the answer was technically incorrect since it's the PDB and libgimp that's a wrapper around code in the core, not the other way around. Oops. At least I qualified it by saying I wasn't sure what was involved :) My understanding came from looking at libgimpthumb, which was added into 2.0 - what's in libgimpthumb looks to me like a complete implementation of the thumbnail spec, as opposed to PDB wrapper code. Ah - looking at the gimp-2.0 binary it looks like we just link libgimpthumb into gimp-2.0, and let plug-ins link with it if they want, so it is pure implementation. How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it. May I ask why you are asking these questions? I imagine it's because he wants to do the same thing... just a wild guess. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi Robin, Robin Rowe wrote: Good technical anwer, thanks. Apparently I got it wrong. Anyway - I just improved my understanding with a concrete example. Let's take gimp_layer_add_alpha() as the example (the function adds an alpha channel to an RGB background layer that doesn't have one yet). The implementation is in app/core/gimplayer.c. In app/pdb/layer_cmds.c (still in application space), we have a wrapper function (layer_add_alpha_invoker), and a procedure which we register with the PDB (layer_add_alpha_proc), which registers the _invoker function as the run callback. Finally, in libgimp/gimplayer_pdb.c, we have the wrapper function which is called in plug-ins. This calls gimp_run_procedure on the procedure above, and invoked the core code as a direct result, as with a normal user-defined PDB function. Core types and enums are wrapped automatically by the perl scripts in tools/pdbgen (although this is somewhat black magic to me). I'm also wondering from a license standpoint. The code in app is GPL, but libgimp is LGPL. Given the above, the core code is GPL, the app/pdb code is GPL, and libgimp/* is LGPL, so there are no licence issues. Hope this clears everything up, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Dave Neary [EMAIL PROTECTED] writes: My understanding came from looking at libgimpthumb Well, I was talking about libgimp explicitely since I think that's what the question was all about. Of course libgimpbase, libgimpcolor, libgimpmath, libgimpthumb and libgimpwidgets play a completely different role here. These libraries contain code that is shared between the core and plug-ins. Still most of this code has been developed in the libraries and was never before part of the GIMP core. libgimpthumb is an exception here but it has been written from scratch with the intention to move it into a library eventually. Same is true for the GimpUnitComboBox that I recently added to the core but already noted that it's supposed to end up in libgimpwidgets as soon as it's full-featured and the API has settled. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it. Well, there are license issues when a non-GPL application makes calls to GPL-ed code by whatever means. I don' think this is an accurate representation of the issue. It certainly doesn't tally with my understanding. That said, I'm no expert. But let's take an example... I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? How about if the relationship is via an ORB? A GIMP plug-in is a completely different process space than the GIMP core. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. This is a difficult subject and it's hard to judge if a plug-in should be considered part of the GIMP application (which would mean that the GPL applies) or if it's a mere aggregation as per section 2 of the GNU General Public License. Our position on this is outlined in the file LICENSE which is included with the GIMP source tree. While the exemption in the LICENCE file does indeed clear up any possible confusion, I'm not sure it's necessary. What it also clears up, though, is that there are no licence issues with exporting a core procedure to the PDB, and wrapping that procedure in libgimp, which was the case in point. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Dave Neary [EMAIL PROTECTED] writes: A GIMP plug-in is a completely different process space than the GIMP core. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. Well, we have had this discussion before and not everyone necessarily sees it your way. That's why we added that extra file that explains our view of the license. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Dave Neary wrote: I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? Potentially, yes. :) A GIMP plug-in is a completely different process space than the GIMP core. I don't think that the GPL cares in the slightest about process spaces per se. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. Sure, but I don't think that's relevant, as such. We are basically talking about something very function-oriented like RPC, not something data-oriented like FTP. Putting it another way, we wouldn't expect for example a (non-system) GPL DLL to be licence- safe to link to a closed-source app just because ld.so was under a BSD-like license. Note that if this were not an issue then any app could use GPL code freely as long as it interceded IPC like a simple wire-protocol. (Personally, 'linking' like this would be entirely fine by me, but it's trivial to interpret the GPL as disallowing it, so we explicitly except it for the PDB/gimpwire.) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Disobedience is the true foundation of liberty. The obedient must be slaves. --Thoreau ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary [EMAIL PROTECTED] wrote: But let's take an example... I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? Well, that's what the license says: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term modification.) [...] If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. [maybe other sections apply] So I hope it's very clear now that it depends. On what it does depend very much is influenced by local jurisdiction. In short, you won't know what a derived or a seperate work is until you go to court. No matter what people here think or claim, what counts is an actual decision by the court. Always. Usually, there are two groups that might be consulted when one goes to court: the author of the original license document (the FSF) and the author of the program in question. It's a very good idea to have a clarification accompanying the license for this case (as is the case with the linux kernel, and the gimp). In most courts, it counts a lot if the gimp developers say: uses of libgimp to interface with the gimp do not fall under the gpl, even though it's doing rpc to the gimp. What most people want, however, is a clear indication and definition of derived work, just like you seem to do. However, it's important to understand that this is impossible, not just because local laws apply different in each country, but also because a precise definition is impossible in general. So the best bet you can do is to say: ok, the authors specified their intent explicitly, and I depend on that. Wether that works in court is a different question that not even a lawyer can answer, but usually a court does depend on statements of intent by the program authors. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Dave Neary wrote: A GIMP plug-in is a completely different process space than the GIMP core. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. We specifically moved libgimp from GPL to LGPL to allow for the possibility of proprietary plugins. Spencer and Peter affirmatively agreed to that change when it was made. That was either late in the 0.99 cycle or early in the 1.0 cycle, although I forget which. Yosh should remember. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Sven, Just to clarify for others reading along, my question is not about linking GPL and LGPL. It is about cut-and-pasting code from GPL into LGPL during refactoring. With the benefit of hindsight years later, it seems a maintainer doing code clean-up should find application code that would better serve as library functions (refactoring). However, in GIMP such code can't be moved without getting everyone's permission due to the differing licenses. Sven has said in the past that he often checks in patches in his own name in CVS, that GIMP does not keep exact records of who its authors are. Sorry, but that's not true. Whenever I check code into CVS I mention the authors explicitely so it's completely possible to track the authors by looking at the CVS log. Pardon me if I misspoke based on recollection. I have now referred back to your post of December 2, 2002. You said: [ We often apply patches from people that don't have CVS commit access. I'd like to see the names of the patch authors in the list of contributors but it's not trivial to extract them from the ChangeLog entries. ] Related question, does GIMP always list the patch author and his contact info in CVS entries? How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. May I ask why you are asking these questions? For years you have been saying that something that makes GIMP great is that you have taken the code through a major clean-up process. I wanted to understand how GIMP does refactoring without being held back by GPL/LGPL licensing barriers. However, you say above you rarely do refactoring. Why do you suppose little GIMP application code has migrated into libraries? Is refactoring unimportant? Thanks, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Open source digital motion picture film software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi Robin, Robin Rowe wrote: How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. For years you have been saying that something that makes GIMP great is that you have taken the code through a major clean-up process. [...] However, you say above you rarely do refactoring. Your definition of refactoring is rather limited. Refactoring is a whole big fioeld and lots of it is imposing order on something without that order. A classic example is the creation of the GIMP object hierarchy which exists now, from essentially flat code as it was in 1.2. It seems like you're limiting refactoring to code re-use via extraction to libraries. This is a very small part of what is known as refactoring. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Robin Rowe [EMAIL PROTECTED] writes: Pardon me if I misspoke based on recollection. I have now referred back to your post of December 2, 2002. You said: [ We often apply patches from people that don't have CVS commit access. I'd like to see the names of the patch authors in the list of contributors but it's not trivial to extract them from the ChangeLog entries. ] Not trivial meant that it will be difficult to write a script that does this automatically. It doesn't mean that it can't be done for a particular piece of code. For years you have been saying that something that makes GIMP great is that you have taken the code through a major clean-up process. I wanted to understand how GIMP does refactoring without being held back by GPL/LGPL licensing barriers. However, you say above you rarely do refactoring. Please have a look at the core and compare it with the codebase four years ago. You will notice that the GIMP core has been refactored into a number of subsystems with clear dependencies. Why do you suppose little GIMP application code has migrated into libraries? Is refactoring unimportant? Refactoring doesn't necessarily mean moving code from the core to our libraries. Moving code to libgimp* only makes sense if it provides functionality that is useful for plug-ins. That isn't very often the case. Most of the time it's better to expose the functionality to the plug-ins through the PDB. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Robin Rowe [EMAIL PROTECTED] writes: I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Good technical anwer, thanks. Well, the answer was technically incorrect since it's the PDB and libgimp that's a wrapper around code in the core, not the other way around. I'm also wondering from a license standpoint. The code in app is GPL, but libgimp is LGPL. I'm not a lawyer, but it would seem that to change the code license from GPL that GIMP would need to get permission from all authors, or reserve the right to change the license later. Sven has said in the past that he often checks in patches in his own name in CVS, that GIMP does not keep exact records of who its authors are. Sorry, but that's not true. Whenever I check code into CVS I mention the authors explicitely so it's completely possible to track the authors by looking at the CVS log. How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. May I ask why you are asking these questions? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring?
Hi Robin, Robin Rowe wrote: Does code in app ever get moved into libgimp? In what cases and who decides? A recent example of code that was moved from the main app to libgimp is libgimpthumb. The decision process behind this is documented in a bugzilla report (if you search in the GIMP product, including resolved and closed bugs, with thumbnail in the search criteria, you should find it - unfortunately at this precise moment bugzilla is down, otherwise I'd do it an include a link). I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Related question, what tools use libgimp without GIMP? To the best of my knowledge, none. There was one person about a year ago who wanted to write a GIMP PDB for batch processing, but I don't know what happened to him. There isn't a whole lot of utility code that can be used independent of the PDB (I suppose the GimpWidgets are pretty handy). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring?
Hi, Robin Rowe [EMAIL PROTECTED] writes: Would like to better understand the development approach the GIMP has used over the years to segregate code in the main app from code in libgimp. Seem to recall seeing some app code that had moved into libgimp, but am not sure. Do GIMP maintainers later refactor code? Looks like you didn't understand the role of libgimp. libgimp is strictly a plug-in library; the core doesn't use libgimp. It's basically the C language binding of the PDB. Perhaps this information can help you to refactor your question. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Refactoring?
Would like to better understand the development approach the GIMP has used over the years to segregate code in the main app from code in libgimp. Seem to recall seeing some app code that had moved into libgimp, but am not sure. Do GIMP maintainers later refactor code? Does code in app ever get moved into libgimp? In what cases and who decides? Related question, what tools use libgimp without GIMP? Thanks, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Open source digital motion picture film software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
