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.

Hi,

"Robin Rowe" 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

Hi,

"Robin Rowe" 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

Hi,

Sven Neumann wrote:

"Robin Rowe" 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.

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.

Hi,

Dave Neary 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

Hi,

Dave Neary 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. 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.

Sven

Hi,

Sven Neumann wrote:

Dave Neary 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.

Hi,

Dave Neary 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

On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary 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.

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

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.

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary 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.

Robin Rowe wrote:

How do you get permission to move GIMP code from GPL into LGPL?

You get the explicit permission of everyone who's ever contributed to the code in question. For the entirety of the GIMP, that's about 100 people.

I can tell you right now that I object to relicensure, which means you're going to have to exclude anything I've ever written. Good luck with that; I'm responsible for some pretty substantial parts of GIMP's infrastructure code.

Kelly

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

On Wed, May 12, 2004 at 03:55:31PM +0200, Dave Neary 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.

Hi,

Marc A. Lehmann wrote:

On Wed, May 12, 2004 at 03:55:31PM +0200, Dave Neary wrote:

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.

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.

Hi,

"Robin Rowe" 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

pcg@goof.com ( 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

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 ------------------------------------------------------------------- Robin.Rowe@MovieEditor.com Hollywood, California www.CinePaint.org Open source digital motion picture film software

Tor Lillqvist wrote:

pcg@goof.com ( 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...?

For a licence to be considered GPL, it can impose no further restrictions beyond what is in the GPL, excluding exceptions which are explicitly allowed (linking to library X, for example). Of course, the copyright holders can place the software under any licence they see fit. Including the GPL, but also including weird GPL hybrids.

But since the MySQL copyright holders say that the licence is GPL, I suppose they get to have some say in what they consider to be a derived work.

Cheers, Dave.

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.

On Thu, May 13, 2004 at 01:04:23AM +0000, Tor Lillqvist wrote:

pcg@goof.com ( 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.

First of all, it should have been "could", not "would" in the above sentence.

But these restrictions are placed by the MySQL copyright holders themselves, aren't they?

Yes. But they can't license a product to me saying it's licensed under the GPL and then, in another part of the documentation _outside_ the license, place restrictions not mentioned in the GPL.

This is at best contradicting.

Also, I am quite sure that not everybody who contributed code to mysql is aware that the GPL is, in fact, not the whole license.

That is, *iff* these are additional restrictions, which is a point of view not everybody needs to share.

My point is solely that most arguing (even by me, I might interpret the license totally correctly, yet still fail to predict reality) about the requirements of the GPL is moot if somebody goes to court :)

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

Hi,

Manish Singh wrote:

But it's pretty
clear that you never bother to do any research before posting.

You must
have some weird sort of logic goes on in your head that made you conflate these things.

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.

On Sun, May 23, 2004 at 09:11:49PM +0200, David Neary wrote:

Hi,

Manish Singh wrote:

But it's pretty
clear that you never bother to do any research before posting.

You must
have some weird sort of logic goes on in your head that made you conflate these things.

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

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

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

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.

maybe this issue can be solved sportively during a boxing match on the GUADEC conference. ;-)

Dave Neary (dneary@free.fr) 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