Re: [Gimp-developer] Refactoring code from GPL to LGPL

2004-05-25 Thread Simon Budig
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

2004-05-25 Thread William Skaggs

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

2004-05-24 Thread Dave Neary
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


Re: [Gimp-developer] Refactoring code from GPL to LGPL

2004-05-23 Thread David Neary
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

2004-05-23 Thread Manish Singh
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

2004-05-23 Thread Christopher Curtis
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

2004-05-23 Thread Manish Singh
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

2004-05-20 Thread Manish Singh
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

2004-05-13 Thread Dave Neary
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

2004-05-13 Thread Robin Rowe
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

2004-05-12 Thread Dave Neary
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

2004-05-12 Thread Dave Neary
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

2004-05-12 Thread Sven Neumann
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

2004-05-12 Thread Dave Neary
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

2004-05-12 Thread Sven Neumann
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

2004-05-12 Thread Adam D. Moss
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

2004-05-12 Thread pcg
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

2004-05-12 Thread Kelly Martin
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

2004-05-12 Thread Kelly Martin
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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Refactoring code from GPL to LGPL

2004-05-12 Thread Robin Rowe
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

2004-05-12 Thread David Neary
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

2004-05-12 Thread Sven Neumann
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

2004-05-11 Thread Sven Neumann
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