xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: freehep and batik
Date Fri, 02 Dec 2005 12:18:03 GMT
Yes, that is currently so. Until the board votes on a resolution that
allows this, it is impossible. The last resolution that was suggested
somehow didn't pass. I'd have to look up the details. But the idea is to
allow just that AFAIK: Creating components based on LGPL-based libraries
under the ALv2, but not allowing the redistribution of LGPL libraries.
One of the biggest issues was to get the FSF to publicly state how the
LGPL is to be interpreted WRT Java, because there were major question
marks there.

On 02.12.2005 12:13:17 thomas.deweese wrote:
> Hi Jeremias,
> Jeremias Maerki <dev@jeremias-maerki.ch> wrote on 12/01/2005 02:42:35 PM:
> > Nice idea, but unfortunately, FreeHEP is licensed under the LGPL which
> > currently makes it off-limits for any Apache project. You could, 
> however,
> > publish such a transcoder somewhere else and under the LGPL.
>    Is this right?  I was under the impression that one of the key
> distinctions between GPL and LGPL is that code depending on LGPL
> could be under a separate license from the 'library' code (in this
> case freeHEP).   So we certainly couldn't distribute the FreeHEP
> jar files but I would have thought that one could include a freeHEP
> transcoder under say the 'contrib' tree (which isn't normally built).
> With the code in the transcoder under Apache License.
> > I've been keeping an eye on FreeHEP for ages now since they've got a 
> nice
> > PostScript interpreter that I'd love to use in FOP. But I can't because
> > of the LGPL. Fortunately, this situation may yet change in the near
> > future.
>    I have no idea about the quality of the code but it certainly looks
> interesting from a sheer functionality point of view....
> > On 01.12.2005 19:22:39 Anthony Cavalliotis wrote:
> > <snip/>
> > > I'd be interested to see any Transcoder re-implementation (or a start)
> > > if someone has the time.  Then you could add it as an (optional) part
> > > of batik (cause you'd need the freehep jar).  Looking at the other
> > > (printer, image) transcoders in org.apache.batik.transcoder, I agree
> > > that a cleaner solution (for future reuse) would best be a
> > > EMFTranscoder.
> > <snip/>

Jeremias Maerki

To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message