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
[Gimp-developer] GPL discussion (was something else)
Hi, I guess since we explicitly exempt libgimp and plug-ins, this discussion is purely of academic interest. Anyway - it interests me enough to ask a couple of questions. [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary [EMAIL PROTECTED] wrote: 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.) I've read and re-read this, and I'm having trouble figuring out how anyone can consider a network client as being a derivative work of the server. The client does not contain any of the server. The server exposes an API using an open protocol, and the client formulates requests to the server, and gets a response (still using xml-rpc as the example). At no stage does the client contain part of the server. The client can exist with an alternate, non-GPL implementation of the same server with no change (similarly, someone could conceivably use libgimpwire to implement a simple plugin-based batch processor and use the existing farm of GIMP plug-ins with no changes). The client and the server are distinct entities. Somewhere along the line, I don't get it. But that's OK :) So I hope it's very clear now that it depends. Ummm.. no. And getting unclearer all the time. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New Exif browser plugin
Hi, I have put together a first pass at a plug-in for working with exif data -- the code can be downloaded from the registry, at http://registry.gimp.org/plugin?id=4153 It places itself in the menu as Filters-Generic-Exif Browser. Here are the contents of the README file: GIMP Exif Browser = Copyright (C) 2004 William Skaggs [EMAIL SUPPRESSED] This is a Gimp 2.0 plug-in that permits the user to view EXIF data from jpeg files. EXIF data is meta-data created by many digital cameras, containing information about the image and the circumstances under which it was created. The plug-in is based on the code for the gtk-exif-browser widget developed by the libexif project (see http://sourceforge.net/projects/libexif). In fact it is little more than a wrapper around that widget. To be able to use this, you must [1] have libexif installed (download it from the sourceforge site), and [2] have built Gimp with libexif support (this basically means that you need to have installed libexif before you built Gimp, or else you need to rebuild it). Note that many jpeg files do not contain EXIF data. If this plug-in does not show anything and you think it should, please install my meta-data plug-in, available from the Gimp Plug-in Registry, and use it to check whether the image has an attachment called jpeg-exif-data. If it does not, then the problem has nothing to do with this plug-in. If it does but you can't view it, then it is a bug, and I would like to hear about it. Currently the plug-in only works on images loaded from jpeg files, and does not allow the EXIF data to be altered by the user, only viewed. These things will change in later releases. == Any feedback is welcome. -- 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
[Gimp-developer] Re: Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] Could you read the sketchpad.pdf and check how it differs from how the path tool is handled? It would be your task to explain to explain to me what you want. As I said earlier I am quite satisfied with the way it works now. No. It is better that some of you too will read about the topic. The provided sketchpad paper has a good framework, and I would like to know if that gives any ideas to anyone of you. My posting was not meant for unwilling persons like you, but for anyone who could read the papers and fit the strong ideas given in the papers to GIMP. Also, the path tool deals with bezier curves, the paper does not. The path tool handles polygonal line segments, the paper does not (only single straight lines). Please don't read too narrow-mindedly. The Sketchpad has been used to construct more complex geometries than a single stright line. Read the whole paper, don't stop to first figure. The framework in Sketchpad is the most important part (not the curves): the constraints and the object oriented data management. It can be used for any new objects, including Bezier curves. Last I ckecked, your framework in Path Tool was not used in the rectangle selection tool nor in crop tool. Can you put your framework to a form in which I may use it to code new unirectangle and new crop tool for us? We need not to check new frameworks if existing ones are good enough; and they are good enough if they can be used to program new tools. For circles a significant different way to handle them has become quite standard for vector applications. And I'd prefer to match the handling in other recent programs than a paper from 1963. Qoca constraints solver papers have been published quite recently (200?). The papers with good intro sections has been published at 199?. What papers you have been reading? Does your framework in Path Tool implement any constraints based manipulations? Just read the papers and check if they raise up any ideas. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Constraints, Path tool
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: Last I ckecked, your framework in Path Tool was not used in the rectangle selection tool nor in crop tool. Can you put your framework to a form in which I may use it to code new unirectangle and new crop tool for us? We need not to check new frameworks if existing ones are good enough; and they are good enough if they can be used to program new tools. The fact that the new vectors architecture isn't more widely used yet doesn't mean that it can't be put to more use. The vectors framework in the GIMP core is very new and IMO it fits our needs. You haven't explained yet what exactly you don't like about it. If you actually tried to use it and failed then your complaints would make sense, but as it stands you are suggesting to replace a perfectly working framework with lots of potential by some vaporware. And so far you failed to give any reason why that should happen. The papers you are pointing us at might be worth reading and they could certainly inspire us for new ideas. But I don't see why you keep bashing on the current vectors framework since obviosuly you didn't even look at it yet. 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: 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] Re: Constraints, Path tool
[while this is a rant, there is useful content in this mail] Juhana Sadeharju ([EMAIL PROTECTED]) wrote: From:Sven Neumann [EMAIL PROTECTED] bashing on the current vectors framework since obviosuly you didn't even look at it yet. The Path Tool framework was just mentioned to me. Then I quickly re-checked out those papers if somebody would actually want read them now. Only a good intention. But I got flamed. I have not bashed the current vector framework because I have not seen it yet. May I quote yourself? The selection tool vector drawing and the crop tool vector drawing are not visible in other views of the same image because the framework is kludge. [...] missing completely the point in this kludge code Calling something a kludge *is* bashing, especially when you did not even bother to look at it. As I wrote earlier, I thought quite a lot about that stuff to get it right. I rewrote it two times basically from scratch. I worked on this for a really long time. Now you come along, tell me that Gimps framework is a kludge and you did not even look at it, but suggest me to read dozends of pages to realize what is a cludge with my stuff. And you expect me to take you seriously? What I want is written very clearly in the intro sections of those mentioned papers (published at 199?; in constraints/ dir at my site). If you don't even have an idea of what I'm talking about, how ever I could go in to details? It would be a good idea to explain the basic ideas in a comprehensible way. The previous poster confused at level of a basic stright line vs. a Bezier curve; missing completely the point in this kludge code vs. constraints code discussion (started in gimp-user). The original post I replied to (on gimp-user) does not contain the word constraint. In your second mail you also do not explain what you mean by constraint. In your first mail you wrote: What we need is a good old vertex/edge/polygon framework. We *have* a vertex/edge/polygon framework, and the edges even can be bezier segments, which is far more suitable for defining pretty common curved shapes. But you called this a kludge. And now you complain that I get pissy? No need to ask me to repeat. I have mailed on constraints in several mails within last months, but nobody informed me that constraints are already implemented in GIMP. I did not find them in a recent CVS code (taken february or march). Sure I will check how the Path Tool stuff could be used in implementing the new tools. It just is not the vectors I want, but the powerful constraints framework. After installing the unirectangle geometry I don't want manipulate it at vector value level. Now unirectangle is simple stuff, but things gets more complicated if I need more complex tools. Some extra power would make things simpler. Read the papers for what I mean. Please explain what a unirectangle is. A google search for this word turned up exactly one mail from you - where you don't explain it. After looking at sketchpad.pdf again I understand that the constraints you are talking about seem to be relations between vector objects (this rectangle has the same height as the length of this line, these polygonal edges lie evenly spaced on a circle etc. I believe hints in fonts are a similiar idea. While this certainly could be useful for technical/mathematical drawings I don't see how this could be useful in an image manipulation context. If implemented for a program primarily intended for vector stuff (Skencil, Sodipodi) this might be very helpful, but in GIMP the primary goal for now is to create pixel based images - which is notoriously bad for above mentioned technical drawings. So, unless you can bring up some compelling use cases for constraints in an image manipulation context, I don't believe that they will be implemented in the near future. On the other and I am fully aware, that the vectors infrastructure in the GIMP could be more widely integrated. It should be fairly easy to implement rectanges and ellipses as vector objects. It definitely would be cool to have them used for Crop and the selection tools, but we need to iron out the usage scenario for adding/intersecting/substracting selections in connection with the ability to manipulate the vector shapes. I am willing to continue this discussion, but not if you continue to call my stuff kludge. And I don't want to read scientific publications to guess what your ideas are. You apparently are deeply into that stuff, so it should be fairly easy to you to bring up examples. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GPL discussion (was something else)
On Wed, May 12, 2004 at 03:55:31PM +0200, Dave Neary [EMAIL PROTECTED] wrote: into another language. (Hereinafter, translation is included without limitation in the term modification.) I've read and re-read this, and I'm having trouble figuring out how anyone can consider a network client as being a derivative work of the server. The client does not contain any of the server. The point is that whatever you think is of no concern, mostly. What counts is what local law says, to a lesser extent what the authors of the program or the license say, and to most extent what decision this might result in court. It might matter to people in the sense of influencing them to either use or not use a piece of software based on their understanding of the license or the laws. However, licenses are a purely legal tool. I am sure the FSF would rather do without licenses and copyright law (which is the reason for the term copyleft, basically it means abusing increasingly restrictive copyright laws to _force_ sharing). As a legal tool, they only mean something in court (well, depending on the legal system in force :) gets a response (still using xml-rpc as the example). At no stage does the client contain part of the server. The client can exist with an alternate, non-GPL implementation of the same server with no change (similarly, It mostly doesn't matter. If the authors say it is covered by the GPL it might be, or it might not be. If you want to know, ignore the authors and if they go to court, hope that you prevail As an example, mysql itself is under the General Public License. The mysql interface library is under the Lesser General Public License. You would expect that you can link against the interface library and get away with only providing a dynamically linked binary. However, a little known clarification to the mysql license states that if your product requires mysql (because it e.g. it either uses SQL features only available in mysql OR it is being delivered with mysql) then it's not mere aggregation but a derived work, and the GPL applies to your software. According to you, this shouldn't be. Additionally, one would assume that these are additional restrictions that are explicitly forbidden by the GPL itself. I'd bet, however, that in a court the mysql authors/owners would have good chances to force the GPL license on your product, at least in some countries. It's still a game of chance, though. The point really is to understand that no license can exactly define terms that are completely outside of it's scope, e.g. derived work, or even dependent on local laws. The GPL doesn't try to define this, and that is what you have to cope with. It's vague, ugly (especially for hackers us who would like to have everything strictly defined and unambgiuous), but really no different to the situation in mathematics, which also contains paradoxies and unresolvable problems. It's something that, I believe, one just has to live with. So I hope it's very clear now that it depends. Ummm.. no. And getting unclearer all the time. Get used to it. The unclearness is *precisely* :) what this is about. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
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] Re: GPL discussion (was something else)
Hi, Marc A. Lehmann wrote: On Wed, May 12, 2004 at 03:55:31PM +0200, Dave Neary [EMAIL PROTECTED] wrote: big snip So I hope it's very clear now that it depends. Ummm.. no. And getting unclearer all the time. Get used to it. The unclearness is *precisely* :) what this is about. Thanks for the explanation. I think I understand things better now. (Dave furrows brow pensively...) 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, 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
[Gimp-developer] Re: GPL discussion (was something else)
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: According to you, this shouldn't be. Additionally, one would assume that these are additional restrictions that are explicitly forbidden by the GPL itself. But these restrictions are placed by the MySQL copyright holders themselves, aren't they? It's those who *copy* (download, install) and redistribute MySQL that the license applies to, and it's they who can't add any additional restrictions. Or am I confused...? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 5.0.0-alpha3
Welcome to Gimp-Print 5.0 Alpha 3! Please read these release notes carefully. Gimp-Print 5.0.0-alpha3 is the third alpha release (technology preview) in the line that will eventually lead to Gimp-Print 5.0. It is based on the 4.3 series that has been in development for two years, and includes many improvements over the very popular 4.2 series. This release is not considered to be a fully stable release (there are still various things in flux, and it has not undergone the extensive testing that is required to declare a release stable), but we've been using it and we believe that it will be useful for many purposes. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and 10.3) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality, and can be used for demanding printing tasks requiring flexibility and high quality. This software package includes the Print plug-in for the GIMP and Ghostscript and CUPS drivers, as well as Foomatic data. Gimp-Print currently contains over 200 drivers supporting in excess of 600 printer models. The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the 1.2 line (more recent versions of the GIMP, such as 1.3 and 2.0, are not supported at present). You may need to install packages named gimp-devel, gtk-devel, and glib-devel (or similar equivalents) on many systems. This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or similar on many systems. Please the rest of the release notes for full details on installation, as there is an important caveat. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gimp-Print provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gimp-Print as a general-purpose printing solution. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. The options for this driver are very complex, and it is normally used with the Foomatic driver integration system. Users of Macintosh OS X 10.2 (Jaguar) and 10.3 (Panther) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We highly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5), as those systems do not use CUPS as their printing system. This is NOT going to be fixed; you must upgrade to at least OS X 10.2 in order to use this package. The reason why is that OS X 10.2 and above use CUPS as the basis of the printing system. OS X 10.0 and 10.1 use a different system that would require a separate driver, and we do not plan to write that driver. The README file included with this package provides full instructions on building and installing Gimp-Print. * Major changes between Gimp-Print 5.0.0 alpha 2 and 5.0.0 alpha 3: 1) Borderless printing now works correctly in the native CUPS driver. In previous releases it printed garbage. Note that while borderless printing works correctly in CUPS, the actual prints don't come out perfectly borderless in all cases. 2) A problem manifesting itself as unprinted horizontal stripes within a page has been fixed. 3) A number of crash problems in the Print plugin have been fixed, and potential crash problems in the core library have been fixed. 4) The CUPS driver now prints correctly at 1440x1440 DPI on certain Epson printers. Previously it rendered at 2880x1440, which in addition to being slower could also cause incorrect results on certain types of material. 5) A minor compliance issue in the CUPS PPD files is fixed. 6) Boolean options are handled correctly in the Foomatic data. 7) escputil now returns ink levels correctly on all Epson printers. In addition, it is more robust on printers that it previously worked correctly on. 8) The header files have been reorganized; all header files intended for use by either client programs or modules (such as family drivers) have
Re: [Gimp-developer] the license status of refactored code
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
