Dave, Robin, Sven et al: Although the word "refactoring" seems to have gained acceptance in the world of commercial software and technology services, it doesn't seem to be brought up very often in the context of open source development. Not never, just rarely. Something similar might be observed about "extreme programming" which certainly has an analogue in the collaborative efforts that occur in public software projects such as the gimp on IRC and elsewhere. In both cases, many of the activities are the same but the process is differently named.
Reorganizations of the code are obviously important. It isn't as clear that this is the case with "refactoring." So here's my point in bringing this up: refactoring entails a reorganization or reordering of code. I argue that the reorganizations and reorderings themselves can have licensed status. In other words, the copyright/left can belong to the arrangement of the pieces just as it can to the individual pieces. Accordingly it would belong to whoever is making the reorganization/reordering (or paying for this to be done in a work-for-hire case) to determine what license that work falls under. IMPORTANT: The phrase "refactoring from GPL to LGPL" is not necessarily consistent with the commonly held definition of the term: "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/ Refactoring could occur from LGPL to GPL, or not even affect the licensing in any way and this will have a lot to do with the intention of the person who does the work of rearranging the parts. It generally helps to get the meanings of the words we're using straight first, so I think a discussion of what exactly is "refactoring" would be helpful, although not necessarily entirely appropriate to the focus of this mailing list.. Mat Caughron On Wed, 12 May 2004, Robin Rowe wrote: > 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 > _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
