Re: [Gimp-print-devel] packaging or: trying to break bogus MS patents

[Torsten L. <to...@de...>]

Hi *, 

Sorry, I am very late in this discussion but to be honest I did not 
quite understand what was expected from me...

On Sat, May 06, 2000 at 10:30:42AM -0400, sh...@su... wrote:
> 
> (Quick review for Ben and Torsten: We're discussing how to package
> Gimp's print plug-in for Debian.  Gimp-print is trying to separate
> itself from the Gimp and become a generalized printer driver package.
> It currently works from within Ghostscript as well as from the Gimp.)

Interesting. May I ask what the gimp-print plugin provides to the 
application and to the user?

> > I thought I put everything in there (except a 1 MB
> > gs-aladdin_5.50-8.diff file -- should that be in there?)

While the context is not clear to me I can explain why I have such a big
.diff.gz. The reason is quite simple actually - the Debian gs package 
includes a lot of contributed drivers as well as kanji support. This sums
up to about 2.7MB unpacked...

The next package will use doogie's build system to get rid of this large
diff.gz. I hope to finish the package this weekend.

> Hmm.  Possibly, but I'm not sure what's in it.  I'm surprised it's that
> long.  Can you put a copy of it somewhere where I can grab it and then
> I'll take a look at it and decide if it needs to be included or not.
> It may be better to include a script which can generate such a file,
> but I'd still like to get a copy of it to see what he's done.

See above. I really dislike the current state of the gs package. As an aside
the next release will include the libjpeg sources because currently the 
autobuilders can't handle building gs without manual interaction (I think 
there is a feature for this which was added only for gs :(

The right solution to this problem is to separate the core of gs from the 
printer drivers and have a small gs package along with a number of 
gs-driver-xxx packages which are dynamically loaded.

I want to work for the implementation of that but it is a lot of work and
I will not probably start it before I have a weekend to spend.

> I think gimp-print will need to be removed from the official debian
> gimp package and separated into its own package.  This is not so hard
> to do.

In fact a small modification to the gimp package would do it for now. Just
move the gimp-print parts away and create another package from it.

> Unfortunately, ghostscript is not as easy to handle.  Since there is no
> plug-in architecture, and the gimp-print driver must be actually compiled
> into ghostscript, I think the only way to optionally provide gimp-print
> at this time would be to have alternative ghostscript packages.

So gimp-print needs a driver in ghostscript? I don't see the problem, 
it's just another driver for me to add to the Debian package. Or am I 
missing something?

> There are also legal issues involved with making a gs-aladdin-gimp-print
> package.  I don't think such a beast could be legally distributed.
> Using gnu ghostscript should work, though, and has no licensing problems.
> Anyone care to comment on that?

I guess using the AFPL for gimp-print is out of question. OTOH you could 
distribute the driver for ghostscript under a dual license so that the user
can select between the AFPL and GPL for that driver. 

Or even use the LGPL for gimp-print. That would probably suffice to allow
linking to gs. Otherwise we will just have the gimp-print driver in the 
gnu gs package and included in the gs-aladdin source but disabled by 
default. A user could still compile a custom package with gimp-print for 
local use.

cu
    Torsten

-- 
Torsten Landschoff           Bluehorn@IRC               <to...@de...>
           Debian Developer and Quality Assurance Committee Member