You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave Johnson <da...@rollerweblogger.org> on 2005/07/11 17:38:53 UTC
The Roller LGPL issue
Noel wrote:
> At this time, LGPL code is an issue unless you access it very
> indirectly,
> e.g., an LGPL JDBC driver, where your code is entirely naive about
> which
> driver is in use. We are hopeful that these issues will be resolved
> with
> the FSF, but until then, LGPL would be a blocker. Cliff Schmidt is
> managing
> licensing issues for the ASF at this time, and can go into detail.
To get the LGPL ball rolling...
Here are Roller's current LGPL dependencies
----
Hibernate - persistence engine required by Roller
http://hibernate.org/
- Status: Roller code uses Hibernate directly, jars are in Subversion
- Cost of removal: very high, possibly a showstopper
Jazzy - spell checker used in Roller's web based weblog editor
http://jazzy.sourceforge.net/
- Status: Roller code uses Jazzy directly, jars are in Subversion
- Cost of removal: low, but users lose a feature
JSPWiki - used in a plugin
- Status: Roller accesses JSPWiki via a "plugin" interface, JSPWiki
jars in Subversion
- Cost of removal: low and plugins should be bundled separately anyway
And here are some ideas for resolving this issue
----
1) Rewrite Roller to use non-LGPL components
2) Rewrite Roller to access LGPL components indirectly
3) Don't store LGPL components at Apache, instead download them at
build/install time
4) Convince Apache to allow us to use, store and ship LGPL components
For the Hibernate case, ideas #1 and #2 are expensive and will be
*very* difficult to justify to Roller committers, management, Roller
users, Roller fans, etc.
Idea #3 has been suggested by some at Apache (Cliff?), but seems to me
to be essentially a trick. I've been playing with the HTTPUnit
dependencies task, which would make this pretty easy, except that the
Maven repos don't seem include Rome 0.6, JSPWiki, and Jazzy. Also, we'd
need to do the downloads in both our build scripts and our installer
(we don't have an installer yet). Read more about HTTPUnit dependencies
task here: http://www.httpunit.org/doc/dependencies.html
Item #4 seems to be what we really need. Doesn't Harmony need to be
able to do that? We need a little of that license harmony over here
too!
- Dave
Re: The Roller LGPL issue
Posted by Rudman Max <mr...@steelbrick.com>.
Option #2 might be a bit more attractive if we use Spring Framework
(which is distributed under Apache 2.0 license) to "inject" Hibernate
dependency. Still, there will be a fair amount of work involved,
especially in getting rid of calls to Hibernate criteria API and
using strictly HQL-based queries which can be passed in to Spring's
HibernteTemplate.
We are running Roller with (partial) Spring-managed data access so
I'd be happy to contribute some code and expertise if we decide to
pursue option #2.
Max
On Jul 11, 2005, at 11:38 AM, Dave Johnson wrote:
> Noel wrote:
>
>> At this time, LGPL code is an issue unless you access it very
>> indirectly,
>> e.g., an LGPL JDBC driver, where your code is entirely naive about
>> which
>> driver is in use. We are hopeful that these issues will be
>> resolved with
>> the FSF, but until then, LGPL would be a blocker. Cliff Schmidt
>> is managing
>> licensing issues for the ASF at this time, and can go into detail.
>>
>
>
> To get the LGPL ball rolling...
>
>
> Here are Roller's current LGPL dependencies
> ----
> Hibernate - persistence engine required by Roller
> http://hibernate.org/
> - Status: Roller code uses Hibernate directly, jars are in Subversion
> - Cost of removal: very high, possibly a showstopper
>
> Jazzy - spell checker used in Roller's web based weblog editor
> http://jazzy.sourceforge.net/
> - Status: Roller code uses Jazzy directly, jars are in Subversion
> - Cost of removal: low, but users lose a feature
>
> JSPWiki - used in a plugin
> - Status: Roller accesses JSPWiki via a "plugin" interface, JSPWiki
> jars in Subversion
> - Cost of removal: low and plugins should be bundled separately anyway
>
>
> And here are some ideas for resolving this issue
> ----
> 1) Rewrite Roller to use non-LGPL components
> 2) Rewrite Roller to access LGPL components indirectly
> 3) Don't store LGPL components at Apache, instead download them at
> build/install time
> 4) Convince Apache to allow us to use, store and ship LGPL components
>
> For the Hibernate case, ideas #1 and #2 are expensive and will be
> *very* difficult to justify to Roller committers, management,
> Roller users, Roller fans, etc.
>
> Idea #3 has been suggested by some at Apache (Cliff?), but seems to
> me to be essentially a trick. I've been playing with the HTTPUnit
> dependencies task, which would make this pretty easy, except that
> the Maven repos don't seem include Rome 0.6, JSPWiki, and Jazzy.
> Also, we'd need to do the downloads in both our build scripts and
> our installer (we don't have an installer yet). Read more about
> HTTPUnit dependencies task here: http://www.httpunit.org/doc/
> dependencies.html
>
> Item #4 seems to be what we really need. Doesn't Harmony need to be
> able to do that? We need a little of that license harmony over here
> too!
>
> - Dave
>
Re: The Roller LGPL issue
Posted by Matt Raible <mr...@gmail.com>.
Don't know if this will help, but since Hibernate is a JBoss project.
<quote>
To state our view clearly, usage via importing or subclassing of
classes in an lgpl jar DOES NOT create a derivative of the lgpl jar
that requires the application/library using the lgpl jar to be
released under the LGPL.
</quote>
http://jboss.org/jbossBlog/blog/smstark/?permalink=Java_and_the_LGPL_still.txt
Matt
On 7/11/05, Noel J. Bergman <no...@devtech.com> wrote:
> > Sounds like we could easily get clarifications from the authors of our
> > three LGPL dependencies.
>
> As I understand it, the Hibernate web site commentary regarding the license
> is legally insufficient. The LGPL prohibits such external conditions, so
> changes need to be done as PART of the license. Basically, my understanding
> is that unless the FSF issues a corrective statement regarding the LGPL and
> Java, developers such as those whom you mention cannot use the LGPL in the
> manner in which they believe they can. They must take the license, fix it,
> and issue that as a new license. If they are willing to do so, we can give
> them remedial text to repair the license. Similar issues effect the
> GPL+Library Exception.
>
> This may give you some feel for the "fun" that we've been having fixing the
> problem.
>
> --- Noel
>
>
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Jul 14, 2005, at 11:35 AM, Dave Johnson wrote:
> Allen is already working on Roller 1.2 in Subversion trunk
oops. I meant 1.3
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
-1 for these reasons:
I made the Roller 1.2 release from Apache subversion.
Allen is already working on Roller 1.2 in Subversion trunk
I'm hoping to be done with Roller 2.0 in August.
I need to keep Roller 2.0 in sync with ongoing work in Roller 1.3
I'd *really* prefer not to move back to CVS if at all possible.
- Dave
On Jul 14, 2005, at 10:49 AM, Lance Lavandowska wrote:
> A Modest Proposal:
>
> Perhaps we should only consider Roller 2.0 for the Apache Incubator,
> and only have the 1.x branch at java.net. Ick, two codebases to
> maintain, but it "solves" the problem for the now, as a 2.0 release is
> some time off anyhow.
>
> And the two repositories use different versioning systems (SVN vs CVS)
> so it wouldn't be difficult to have them sitting side-by-side...
>
> Lance
>
> On 7/13/05, Henri Yandell <fl...@gmail.com> wrote:
>>
>> Seems like a generic Incubator problem. New projects need to release
>> bugfix or minor-updates while in the Incubator. I imagine the solution
>> is to use the old release location. So to consider the java.net CVS
>> repository (if it even still exists) as a bugfix branch for 1.x and
>> the asf SVN repository as the 2.0 branch.
>>
>> Hen
>>
>
Re: The Roller LGPL issue
Posted by Lance Lavandowska <la...@gmail.com>.
A Modest Proposal:
Perhaps we should only consider Roller 2.0 for the Apache Incubator,
and only have the 1.x branch at java.net. Ick, two codebases to
maintain, but it "solves" the problem for the now, as a 2.0 release is
some time off anyhow.
And the two repositories use different versioning systems (SVN vs CVS)
so it wouldn't be difficult to have them sitting side-by-side...
Lance
On 7/13/05, Henri Yandell <fl...@gmail.com> wrote:
>
> Seems like a generic Incubator problem. New projects need to release
> bugfix or minor-updates while in the Incubator. I imagine the solution
> is to use the old release location. So to consider the java.net CVS
> repository (if it even still exists) as a bugfix branch for 1.x and
> the asf SVN repository as the 2.0 branch.
>
> Hen
>
Re: The Roller LGPL issue
Posted by Henri Yandell <fl...@gmail.com>.
On 7/13/05, Anil Gangolli <an...@busybuddha.org> wrote:
>
> Personally I feel that:
> - Trying to get the LGPL amended or at least officially re-interpreted by FSF to be compatible with the Apache license with respect
> to Java linking/subclassing is best left to the ASF.
>
> - Failing that, trying to get Hibernate / JBoss to relicense its components under an alternate license, is also probably best left
> to the ASF.
Right. Harmony probably wants LGPL usability to kickstart itself, many
Java projects want to use Hibernate and there are other areas too.
Plus people outside the ASF; I could stop having a separate structure
with JFreeChart plugins for an osjava tool of mine etc.
> However, we do need a constructive way to push on this, and to understand the rate of progress and likelihood of eventual success.
> Suggestions Henri? Is anything really moving on this front or is this pointless?
I just became an ASF member, which should allow me to start to see how
things are moving (my odd chair but not member status had left me a
bit in the dark up til now). Though there's the private information
issue there so even if I'd seen stuff already, I'd have to get
permission to quote/summarise etc.
Cliff Schmidt has just been put in charge of legal issues, with the
LGPL issue seeming to be the biggest thing on his plate right now. If
the generic LGPL issue fails to reach a conclusion, then I plan to be
a right royal pain in the arse about the Hibernate clause in
particular to see if that is still workable. 6 months ago, I'd have
felt very confident, but the various conversations concerning the
generic LGPL issue might mean that the conversations at the end of
last year would be reinterpreted.
> We've managed to wedge ourselves on proper releases until we resolve it one way or another.
Yup, I'm to blame for a lot of it too. Things seemed to be looking
good, but then the larger issue swallowed it up. Hoping that we can
make things work out and not end up with a complete mess.
On the release problem itself:
Seems like a generic Incubator problem. New projects need to release
bugfix or minor-updates while in the Incubator. I imagine the solution
is to use the old release location. So to consider the java.net CVS
repository (if it even still exists) as a bugfix branch for 1.x and
the asf SVN repository as the 2.0 branch.
Hen
Re: The Roller LGPL issue
Posted by Henri Yandell <fl...@gmail.com>.
Ah, you already have in the status. Cool :) Much better as it means
it'll get to the board too.
Hen
On 7/14/05, Henri Yandell <fl...@gmail.com> wrote:
> On 7/14/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> >
> > On Jul 13, 2005, at 11:10 PM, Henri Yandell wrote:
> > > On 7/13/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> > >> I don't think so. We can still make totally unofficial and non-Apache
> > >> releases on Java.Net, can't we? If can't do that, then perhaps we made
> > >> a mistake starting to move into the incubator before this issue was
> > >> resolved. In that case, and I hate to say this, we might have to
> > >> consider backing out.
> > >
> > > I can't see why you wouldn't be able to. I'm not sure if there would
> > > be any minor legal loops to jump through (change package name, remove
> > > Apache copyright etc).
> >
> > The Roller 1.2 release was made from the code base in the roller_1.2
> > branch in Apache's Subversion. The code still has the org.roller
> > packaging and no Apache copyrights have been applied (but I did replace
> > the Roller Public License file with Apache Software License v2.0. The
> > release files were made available on java.net and announced on
> > rollerweblogger.org, like most of the previous Roller releases. There
> > was no indication that the release had anything to do with Apache
> > (except for the fact that the code came from the Apache repo).
> >
> > If we're still in the incubator, I'm planning on doing that again for
> > the Roller 1.3 and Roller 2.0 releases which are rapidly approaching.
> > Is that wrong?
>
> I don't think it's bad. I imagine there's some nitpicking that could
> be done but that it mostly depends on how you look at it.
>
> Seems to me that this should be a common issue for projects in
> Incubation, a need to keep their users supported and not leave them
> hanging while they go through Incubation. I think the informal rule is
> not to have official Apache releases while in the Incubator, but apart
> from nitpicking over which licence files should appear in the release,
> it seems fine to continue releasing at java.net.
>
> Someone may contradict me, we should probably have it out on the
> general@incubator list soon. Probably best to wait until after
> ApacheCon, things always slow down then for these kinds of question.
>
> Hen
>
Re: The Roller LGPL issue
Posted by Henri Yandell <fl...@gmail.com>.
On 7/14/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>
> On Jul 13, 2005, at 11:10 PM, Henri Yandell wrote:
> > On 7/13/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> >> I don't think so. We can still make totally unofficial and non-Apache
> >> releases on Java.Net, can't we? If can't do that, then perhaps we made
> >> a mistake starting to move into the incubator before this issue was
> >> resolved. In that case, and I hate to say this, we might have to
> >> consider backing out.
> >
> > I can't see why you wouldn't be able to. I'm not sure if there would
> > be any minor legal loops to jump through (change package name, remove
> > Apache copyright etc).
>
> The Roller 1.2 release was made from the code base in the roller_1.2
> branch in Apache's Subversion. The code still has the org.roller
> packaging and no Apache copyrights have been applied (but I did replace
> the Roller Public License file with Apache Software License v2.0. The
> release files were made available on java.net and announced on
> rollerweblogger.org, like most of the previous Roller releases. There
> was no indication that the release had anything to do with Apache
> (except for the fact that the code came from the Apache repo).
>
> If we're still in the incubator, I'm planning on doing that again for
> the Roller 1.3 and Roller 2.0 releases which are rapidly approaching.
> Is that wrong?
I don't think it's bad. I imagine there's some nitpicking that could
be done but that it mostly depends on how you look at it.
Seems to me that this should be a common issue for projects in
Incubation, a need to keep their users supported and not leave them
hanging while they go through Incubation. I think the informal rule is
not to have official Apache releases while in the Incubator, but apart
from nitpicking over which licence files should appear in the release,
it seems fine to continue releasing at java.net.
Someone may contradict me, we should probably have it out on the
general@incubator list soon. Probably best to wait until after
ApacheCon, things always slow down then for these kinds of question.
Hen
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Jul 13, 2005, at 11:10 PM, Henri Yandell wrote:
> On 7/13/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>> I don't think so. We can still make totally unofficial and non-Apache
>> releases on Java.Net, can't we? If can't do that, then perhaps we made
>> a mistake starting to move into the incubator before this issue was
>> resolved. In that case, and I hate to say this, we might have to
>> consider backing out.
>
> I can't see why you wouldn't be able to. I'm not sure if there would
> be any minor legal loops to jump through (change package name, remove
> Apache copyright etc).
The Roller 1.2 release was made from the code base in the roller_1.2
branch in Apache's Subversion. The code still has the org.roller
packaging and no Apache copyrights have been applied (but I did replace
the Roller Public License file with Apache Software License v2.0. The
release files were made available on java.net and announced on
rollerweblogger.org, like most of the previous Roller releases. There
was no indication that the release had anything to do with Apache
(except for the fact that the code came from the Apache repo).
If we're still in the incubator, I'm planning on doing that again for
the Roller 1.3 and Roller 2.0 releases which are rapidly approaching.
Is that wrong?
- Dave
Re: The Roller LGPL issue
Posted by Henri Yandell <fl...@gmail.com>.
On 7/13/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>
> Is this LGPL thing some sort of sadistic new project initiation rite?
> Is there some easy way out, like mooning the JBoss crew or posting
> naked pictures of ourselves to our blogs? I thought hazing was no
> longer politically correct.
Took you a week longer than Apache Directory to figure it out; I'm
afraid it'll come out of your budget for next year's Apache Swimathon.
> On Jul 13, 2005, at 11:07 AM, Anil Gangolli wrote:
> > Personally I feel that:
> > - Trying to get the LGPL amended or at least officially re-interpreted
> > by FSF to be compatible with the Apache license with respect to Java
> > linking/subclassing is best left to the ASF.
>
> Yes, that's true, but (and this is for everybody) is there anything we
> can do to move this along?
Keep reminding Cliff/Sam that it's a big issue for you. I'm on the
legal-internal list now and will be able to keep a much closer eye on
where this is going.
> > - Failing that, trying to get Hibernate / JBoss to relicense its
> > components under an alternate license, is also probably best left to
> > the ASF.
>
> Yes but again, is there anything we can do to help here?
The hardest part is knowing when the previous one has failed. It's
such a good thing to get results on that pushing for just Hibernate
usage at the ASF seems detrimental, but how long can we wait?
I've an unwritten email in my head that can be sent as soon as the FSF
one fails :)
> > However, we do need a constructive way to push on this, and to
> > understand the rate of progress and likelihood of eventual success.
> > Suggestions Henri? Is anything really moving on this front or is this
> > pointless?
> >
> > We've managed to wedge ourselves on proper releases until we resolve
> > it one way or another.
>
> I don't think so. We can still make totally unofficial and non-Apache
> releases on Java.Net, can't we? If can't do that, then perhaps we made
> a mistake starting to move into the incubator before this issue was
> resolved. In that case, and I hate to say this, we might have to
> consider backing out.
I can't see why you wouldn't be able to. I'm not sure if there would
be any minor legal loops to jump through (change package name, remove
Apache copyright etc).
> > Would it be utterly inappropriate for me to raise the possibility of
> > adopting a JDO implementation or trying to achieve pluggable
> > persistence all over again? Hold the tomatoes please.
>
> Moving to JDO is not entirely out of the question, but it is a hell of
> a lot of work and IMO brings our users almost nothing. As a Sun
> employee, perhaps I should advocate moving to Java standard JDO. As an
> Apache fan, maybe I should advocate Apache JDO (also in the incubator,
> BTW). But personally I'd rather exhaust every other avenue before going
> down the path of ditching Hibernate.
+1
> I'm willing to wait this out for a while (assuming we can still make
> Java.Net releases).
+1
> In the meantime, what about the possibility of pursuing Cliff's
> suggestion that we may be able to depend on LGPL jars, but not ship
> them. We could go ahead and implement a build and install process that
> downloads jars as needed.
Seems good. It's the most likely positive endgame of the FSF
conversations, so I guess the best line to aim for (between covert and
making the user do it themselves) would be:
Page opens stating that Hibernate (and other libs) will be downloaded.
User must click OK.
Or possibly show licences (all same in this case) and require user to OK those.
They'd be downloaded from iBiblio and put into place. I guess it would
require write access to the dirs, and knowing where those are in the
container. Also juggling so that the server doesn't need to be
restarted (hopefully).
> I've already started experimenting with the HTTPUnit project's
> dependency task (for Ant), which does just that; it downloads
> dependencies at runtime from a Maven repository. That approach works
> for Hibernate, because it is available in the Maven repos. But it
> doesn't work for JSPWiki and Jazzy, which are not. That's not a real
> big problem in my mind. I'm willing to complete this work, but it's
> going to have to wait until after the Roller 2.0 work is merged back in
> to the trunk.
>
> So, my question is this: can we make a release from the incubator if we
> use a Maven-like "download at build/install time" approach?
Do you mean a release from java.net?
Hen
Re: The Roller LGPL issue
Posted by Matt Raible <mr...@gmail.com>.
On 7/13/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>
> Is this LGPL thing some sort of sadistic new project initiation rite?
> Is there some easy way out, like mooning the JBoss crew or posting
> naked pictures of ourselves to our blogs? I thought hazing was no
> longer politically correct.
>
>
> On Jul 13, 2005, at 11:07 AM, Anil Gangolli wrote:
> > Personally I feel that:
> > - Trying to get the LGPL amended or at least officially re-interpreted
> > by FSF to be compatible with the Apache license with respect to Java
> > linking/subclassing is best left to the ASF.
>
> Yes, that's true, but (and this is for everybody) is there anything we
> can do to move this along?
>
>
> > - Failing that, trying to get Hibernate / JBoss to relicense its
> > components under an alternate license, is also probably best left to
> > the ASF.
>
> Yes but again, is there anything we can do to help here?
>
>
> > However, we do need a constructive way to push on this, and to
> > understand the rate of progress and likelihood of eventual success.
> > Suggestions Henri? Is anything really moving on this front or is this
> > pointless?
> >
> > We've managed to wedge ourselves on proper releases until we resolve
> > it one way or another.
>
> I don't think so. We can still make totally unofficial and non-Apache
> releases on Java.Net, can't we? If can't do that, then perhaps we made
> a mistake starting to move into the incubator before this issue was
> resolved. In that case, and I hate to say this, we might have to
> consider backing out.
>
>
> > Would it be utterly inappropriate for me to raise the possibility of
> > adopting a JDO implementation or trying to achieve pluggable
> > persistence all over again? Hold the tomatoes please.
>
> Moving to JDO is not entirely out of the question, but it is a hell of
> a lot of work and IMO brings our users almost nothing. As a Sun
> employee, perhaps I should advocate moving to Java standard JDO. As an
> Apache fan, maybe I should advocate Apache JDO (also in the incubator,
> BTW). But personally I'd rather exhaust every other avenue before going
> down the path of ditching Hibernate.
>
> I'm willing to wait this out for a while (assuming we can still make
> Java.Net releases).
>
> In the meantime, what about the possibility of pursuing Cliff's
> suggestion that we may be able to depend on LGPL jars, but not ship
> them. We could go ahead and implement a build and install process that
> downloads jars as needed.
>
> I've already started experimenting with the HTTPUnit project's
> dependency task (for Ant), which does just that; it downloads
> dependencies at runtime from a Maven repository. That approach works
> for Hibernate, because it is available in the Maven repos. But it
> doesn't work for JSPWiki and Jazzy, which are not. That's not a real
> big problem in my mind. I'm willing to complete this work, but it's
> going to have to wait until after the Roller 2.0 work is merged back in
> to the trunk.
If you enter an issue in Maven's JIRA - they'll upload the JSPWiki and
Jazzy JARs for you. I've done this with a number of other projects.
>
> So, my question is this: can we make a release from the incubator if we
> use a Maven-like "download at build/install time" approach?
+1. I don't see any point in ditching Hibernate just so we can be an
Apache project. I know that Tapestry does something similar b/c it
can't distribute certain JARs. Of course, there's lots of complaints
about dependencies not working - but that's the nature of projects
that can't package all the dependencies in a distro.
Matt
>
> - Dave
>
>
>
> >
> > --a.
> >
> >
> > ----- Original Message ----- From: "Henri Yandell" <fl...@gmail.com>
> > To: <ro...@incubator.apache.org>
> > Sent: Tuesday, July 12, 2005 5:20 PM
> > Subject: Re: The Roller LGPL issue
> >
> >
> >> On 7/11/05, Noel J. Bergman <no...@devtech.com> wrote:
> >>> > Sounds like we could easily get clarifications from the authors of
> >>> our
> >>> > three LGPL dependencies.
> >>>
> >>> As I understand it, the Hibernate web site commentary regarding the
> >>> license
> >>> is legally insufficient. The LGPL prohibits such external
> >>> conditions, so
> >>> changes need to be done as PART of the license. Basically, my
> >>> understanding
> >>> is that unless the FSF issues a corrective statement regarding the
> >>> LGPL and
> >>> Java, developers such as those whom you mention cannot use the LGPL
> >>> in the
> >>> manner in which they believe they can. They must take the license,
> >>> fix it,
> >>> and issue that as a new license. If they are willing to do so, we
> >>> can give
> >>> them remedial text to repair the license. Similar issues effect the
> >>> GPL+Library Exception.
> >>>
> >>> This may give you some feel for the "fun" that we've been having
> >>> fixing the
> >>> problem.
> >>
> >> To give you more of a feel:
> >>
> >> I thought it was illegal to release a modified GPL/LGPL:
> >>
> >> "Copyright (C) 1989, 1991 Free Software Foundation, Inc.
> >> 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
> >>
> >> Everyone is permitted to copy and distribute verbatim copies
> >> of this license document, but changing it is not allowed."
> >>
> >> Also, I thought it was said that the Hibernate clause was a legally
> >> applicable concept but needed strengthening in the words. There's been
> >> a lot said though, so Noel and I are probably both right and the
> >> actual answer is undecided.
> >>
> >> As I think someone else has said, it's currently joined with the
> >> larger issue of ASL/LGPL compatibility. So (for the last N months)
> >> I've quit hassling about the specific Hibernate example to see what
> >> happens at the higher level. If that dies, we can push on getting an
> >> answer on the Hibernate specific.
> >>
> >> Not a good answer for Roller's incubation, but there's no way we can
> >> get any interest in the specific issue again until the more generic
> >> one has played out.
> >>
> >> Hen
> >
>
>
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
Is this LGPL thing some sort of sadistic new project initiation rite?
Is there some easy way out, like mooning the JBoss crew or posting
naked pictures of ourselves to our blogs? I thought hazing was no
longer politically correct.
On Jul 13, 2005, at 11:07 AM, Anil Gangolli wrote:
> Personally I feel that:
> - Trying to get the LGPL amended or at least officially re-interpreted
> by FSF to be compatible with the Apache license with respect to Java
> linking/subclassing is best left to the ASF.
Yes, that's true, but (and this is for everybody) is there anything we
can do to move this along?
> - Failing that, trying to get Hibernate / JBoss to relicense its
> components under an alternate license, is also probably best left to
> the ASF.
Yes but again, is there anything we can do to help here?
> However, we do need a constructive way to push on this, and to
> understand the rate of progress and likelihood of eventual success.
> Suggestions Henri? Is anything really moving on this front or is this
> pointless?
>
> We've managed to wedge ourselves on proper releases until we resolve
> it one way or another.
I don't think so. We can still make totally unofficial and non-Apache
releases on Java.Net, can't we? If can't do that, then perhaps we made
a mistake starting to move into the incubator before this issue was
resolved. In that case, and I hate to say this, we might have to
consider backing out.
> Would it be utterly inappropriate for me to raise the possibility of
> adopting a JDO implementation or trying to achieve pluggable
> persistence all over again? Hold the tomatoes please.
Moving to JDO is not entirely out of the question, but it is a hell of
a lot of work and IMO brings our users almost nothing. As a Sun
employee, perhaps I should advocate moving to Java standard JDO. As an
Apache fan, maybe I should advocate Apache JDO (also in the incubator,
BTW). But personally I'd rather exhaust every other avenue before going
down the path of ditching Hibernate.
I'm willing to wait this out for a while (assuming we can still make
Java.Net releases).
In the meantime, what about the possibility of pursuing Cliff's
suggestion that we may be able to depend on LGPL jars, but not ship
them. We could go ahead and implement a build and install process that
downloads jars as needed.
I've already started experimenting with the HTTPUnit project's
dependency task (for Ant), which does just that; it downloads
dependencies at runtime from a Maven repository. That approach works
for Hibernate, because it is available in the Maven repos. But it
doesn't work for JSPWiki and Jazzy, which are not. That's not a real
big problem in my mind. I'm willing to complete this work, but it's
going to have to wait until after the Roller 2.0 work is merged back in
to the trunk.
So, my question is this: can we make a release from the incubator if we
use a Maven-like "download at build/install time" approach?
- Dave
>
> --a.
>
>
> ----- Original Message ----- From: "Henri Yandell" <fl...@gmail.com>
> To: <ro...@incubator.apache.org>
> Sent: Tuesday, July 12, 2005 5:20 PM
> Subject: Re: The Roller LGPL issue
>
>
>> On 7/11/05, Noel J. Bergman <no...@devtech.com> wrote:
>>> > Sounds like we could easily get clarifications from the authors of
>>> our
>>> > three LGPL dependencies.
>>>
>>> As I understand it, the Hibernate web site commentary regarding the
>>> license
>>> is legally insufficient. The LGPL prohibits such external
>>> conditions, so
>>> changes need to be done as PART of the license. Basically, my
>>> understanding
>>> is that unless the FSF issues a corrective statement regarding the
>>> LGPL and
>>> Java, developers such as those whom you mention cannot use the LGPL
>>> in the
>>> manner in which they believe they can. They must take the license,
>>> fix it,
>>> and issue that as a new license. If they are willing to do so, we
>>> can give
>>> them remedial text to repair the license. Similar issues effect the
>>> GPL+Library Exception.
>>>
>>> This may give you some feel for the "fun" that we've been having
>>> fixing the
>>> problem.
>>
>> To give you more of a feel:
>>
>> I thought it was illegal to release a modified GPL/LGPL:
>>
>> "Copyright (C) 1989, 1991 Free Software Foundation, Inc.
>> 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
>>
>> Everyone is permitted to copy and distribute verbatim copies
>> of this license document, but changing it is not allowed."
>>
>> Also, I thought it was said that the Hibernate clause was a legally
>> applicable concept but needed strengthening in the words. There's been
>> a lot said though, so Noel and I are probably both right and the
>> actual answer is undecided.
>>
>> As I think someone else has said, it's currently joined with the
>> larger issue of ASL/LGPL compatibility. So (for the last N months)
>> I've quit hassling about the specific Hibernate example to see what
>> happens at the higher level. If that dies, we can push on getting an
>> answer on the Hibernate specific.
>>
>> Not a good answer for Roller's incubation, but there's no way we can
>> get any interest in the specific issue again until the more generic
>> one has played out.
>>
>> Hen
>
Re: The Roller LGPL issue
Posted by Anil Gangolli <an...@busybuddha.org>.
Yes, one can't just add amending text to the LGPL due to the FSF's copyright and restrictions on the license text itself.
They'd have to write a new and different license "from scratch." Either way, however, it's not a small thing from the perspective
of companies like JBoss.
I also think the Hibernate authors (particularly the JBoss employees) will likely by policy just redirect us to JBoss Legal if we're
requesting alternate licensing of Hibernate. I don't think this is likely to be a fruitful path at our individual group level.
Personally I feel that:
- Trying to get the LGPL amended or at least officially re-interpreted by FSF to be compatible with the Apache license with respect
to Java linking/subclassing is best left to the ASF.
- Failing that, trying to get Hibernate / JBoss to relicense its components under an alternate license, is also probably best left
to the ASF.
However, we do need a constructive way to push on this, and to understand the rate of progress and likelihood of eventual success.
Suggestions Henri? Is anything really moving on this front or is this pointless?
We've managed to wedge ourselves on proper releases until we resolve it one way or another.
Would it be utterly inappropriate for me to raise the possibility of adopting a JDO implementation or trying to achieve pluggable
persistence all over again? Hold the tomatoes please.
--a.
----- Original Message -----
From: "Henri Yandell" <fl...@gmail.com>
To: <ro...@incubator.apache.org>
Sent: Tuesday, July 12, 2005 5:20 PM
Subject: Re: The Roller LGPL issue
> On 7/11/05, Noel J. Bergman <no...@devtech.com> wrote:
>> > Sounds like we could easily get clarifications from the authors of our
>> > three LGPL dependencies.
>>
>> As I understand it, the Hibernate web site commentary regarding the license
>> is legally insufficient. The LGPL prohibits such external conditions, so
>> changes need to be done as PART of the license. Basically, my understanding
>> is that unless the FSF issues a corrective statement regarding the LGPL and
>> Java, developers such as those whom you mention cannot use the LGPL in the
>> manner in which they believe they can. They must take the license, fix it,
>> and issue that as a new license. If they are willing to do so, we can give
>> them remedial text to repair the license. Similar issues effect the
>> GPL+Library Exception.
>>
>> This may give you some feel for the "fun" that we've been having fixing the
>> problem.
>
> To give you more of a feel:
>
> I thought it was illegal to release a modified GPL/LGPL:
>
> "Copyright (C) 1989, 1991 Free Software Foundation, Inc.
> 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
>
> Everyone is permitted to copy and distribute verbatim copies
> of this license document, but changing it is not allowed."
>
> Also, I thought it was said that the Hibernate clause was a legally
> applicable concept but needed strengthening in the words. There's been
> a lot said though, so Noel and I are probably both right and the
> actual answer is undecided.
>
> As I think someone else has said, it's currently joined with the
> larger issue of ASL/LGPL compatibility. So (for the last N months)
> I've quit hassling about the specific Hibernate example to see what
> happens at the higher level. If that dies, we can push on getting an
> answer on the Hibernate specific.
>
> Not a good answer for Roller's incubation, but there's no way we can
> get any interest in the specific issue again until the more generic
> one has played out.
>
> Hen
>
Re: The Roller LGPL issue
Posted by Henri Yandell <fl...@gmail.com>.
On 7/11/05, Noel J. Bergman <no...@devtech.com> wrote:
> > Sounds like we could easily get clarifications from the authors of our
> > three LGPL dependencies.
>
> As I understand it, the Hibernate web site commentary regarding the license
> is legally insufficient. The LGPL prohibits such external conditions, so
> changes need to be done as PART of the license. Basically, my understanding
> is that unless the FSF issues a corrective statement regarding the LGPL and
> Java, developers such as those whom you mention cannot use the LGPL in the
> manner in which they believe they can. They must take the license, fix it,
> and issue that as a new license. If they are willing to do so, we can give
> them remedial text to repair the license. Similar issues effect the
> GPL+Library Exception.
>
> This may give you some feel for the "fun" that we've been having fixing the
> problem.
To give you more of a feel:
I thought it was illegal to release a modified GPL/LGPL:
"Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed."
Also, I thought it was said that the Hibernate clause was a legally
applicable concept but needed strengthening in the words. There's been
a lot said though, so Noel and I are probably both right and the
actual answer is undecided.
As I think someone else has said, it's currently joined with the
larger issue of ASL/LGPL compatibility. So (for the last N months)
I've quit hassling about the specific Hibernate example to see what
happens at the higher level. If that dies, we can push on getting an
answer on the Hibernate specific.
Not a good answer for Roller's incubation, but there's no way we can
get any interest in the specific issue again until the more generic
one has played out.
Hen
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Jul 11, 2005, at 6:00 PM, Noel J. Bergman wrote:
>> Sounds like we could easily get clarifications from the authors of our
>> three LGPL dependencies.
> As I understand it, the Hibernate web site commentary regarding the
> license
> is legally insufficient. The LGPL prohibits such external conditions,
> so
> changes need to be done as PART of the license. Basically, my
> understanding
> is that unless the FSF issues a corrective statement regarding the
> LGPL and
> Java, developers such as those whom you mention cannot use the LGPL in
> the
> manner in which they believe they can. They must take the license,
> fix it,
> and issue that as a new license. If they are willing to do so, we can
> give
> them remedial text to repair the license.
Yes, please. Let's give them the remedial text to be added into the
license. I bet the authors of our dependent libraries would agree to do
that. I'll contact them and make the request.
- Dave
RE: The Roller LGPL issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Sounds like we could easily get clarifications from the authors of our
> three LGPL dependencies.
As I understand it, the Hibernate web site commentary regarding the license
is legally insufficient. The LGPL prohibits such external conditions, so
changes need to be done as PART of the license. Basically, my understanding
is that unless the FSF issues a corrective statement regarding the LGPL and
Java, developers such as those whom you mention cannot use the LGPL in the
manner in which they believe they can. They must take the license, fix it,
and issue that as a new license. If they are willing to do so, we can give
them remedial text to repair the license. Similar issues effect the
GPL+Library Exception.
This may give you some feel for the "fun" that we've been having fixing the
problem.
--- Noel
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Jul 11, 2005, at 12:05 PM, Sam Ruby wrote:
> Dave Johnson wrote:
>> Noel wrote:
>>> At this time, LGPL code is an issue unless you access it very
>>> indirectly,
>>> e.g., an LGPL JDBC driver, where your code is entirely naive about
>>> which
>>> driver is in use. We are hopeful that these issues will be resolved
>>> with
>>> the FSF, but until then, LGPL would be a blocker. Cliff Schmidt is
>>> managing
>>> licensing issues for the ASF at this time, and can go into detail.
>> To get the LGPL ball rolling...
>> Here are Roller's current LGPL dependencies
>> ----
>> Hibernate - persistence engine required by Roller
>> http://hibernate.org/
>> - Status: Roller code uses Hibernate directly, jars are in Subversion
>> - Cost of removal: very high, possibly a showstopper
>> Jazzy - spell checker used in Roller's web based weblog editor
>> http://jazzy.sourceforge.net/
>> - Status: Roller code uses Jazzy directly, jars are in Subversion
>> - Cost of removal: low, but users lose a feature
>> JSPWiki - used in a plugin
>> - Status: Roller accesses JSPWiki via a "plugin" interface, JSPWiki
>> jars in Subversion
>> - Cost of removal: low and plugins should be bundled separately anyway
>> And here are some ideas for resolving this issue
>
> While I am not hopeful of the discussions with the FSF resolving
> themselves any time soon, I do believe that a combination of having
> the ASF deciding what clarifications are sufficient for our purposes,
> and getting projects to follow Hibernate's lead is worth pursuing.
Janne Jalkenen (author of JSPWiki) offered to help, I bet he'd clarify
what LGPL means.
Min Idzellis (author of Jazzy) was a Roller contributor, I bet he'd do
the same.
Sounds like we could easily get clarifications from the authors of our
three LGPL dependencies.
- Dave
Re: The Roller LGPL issue
Posted by Sam Ruby <ru...@apache.org>.
Dave Johnson wrote:
> Noel wrote:
>
>> At this time, LGPL code is an issue unless you access it very indirectly,
>> e.g., an LGPL JDBC driver, where your code is entirely naive about which
>> driver is in use. We are hopeful that these issues will be resolved with
>> the FSF, but until then, LGPL would be a blocker. Cliff Schmidt is
>> managing
>> licensing issues for the ASF at this time, and can go into detail.
>
> To get the LGPL ball rolling...
>
> Here are Roller's current LGPL dependencies
> ----
> Hibernate - persistence engine required by Roller
> http://hibernate.org/
> - Status: Roller code uses Hibernate directly, jars are in Subversion
> - Cost of removal: very high, possibly a showstopper
>
> Jazzy - spell checker used in Roller's web based weblog editor
> http://jazzy.sourceforge.net/
> - Status: Roller code uses Jazzy directly, jars are in Subversion
> - Cost of removal: low, but users lose a feature
>
> JSPWiki - used in a plugin
> - Status: Roller accesses JSPWiki via a "plugin" interface, JSPWiki jars
> in Subversion
> - Cost of removal: low and plugins should be bundled separately anyway
>
> And here are some ideas for resolving this issue
> ----
> 1) Rewrite Roller to use non-LGPL components
> 2) Rewrite Roller to access LGPL components indirectly
> 3) Don't store LGPL components at Apache, instead download them at
> build/install time
> 4) Convince Apache to allow us to use, store and ship LGPL components
>
> For the Hibernate case, ideas #1 and #2 are expensive and will be *very*
> difficult to justify to Roller committers, management, Roller users,
> Roller fans, etc.
>
> Idea #3 has been suggested by some at Apache (Cliff?), but seems to me
> to be essentially a trick. I've been playing with the HTTPUnit
> dependencies task, which would make this pretty easy, except that the
> Maven repos don't seem include Rome 0.6, JSPWiki, and Jazzy. Also, we'd
> need to do the downloads in both our build scripts and our installer (we
> don't have an installer yet). Read more about HTTPUnit dependencies task
> here: http://www.httpunit.org/doc/dependencies.html
>
> Item #4 seems to be what we really need. Doesn't Harmony need to be able
> to do that? We need a little of that license harmony over here too!
I'd state #4 differently.
Just so I don't have to start at the beginning, I hope that everybody
realizes that use GPL (note the missing L up front) components in this
manner is clearly out of the question.
So, the question is: what difference does the "L" make? LGPL is GPL
with a specific exception for "linking". And the definition of
"linking" is very specificly enumerated in the LGPL - down to the number
of lines an inline function can be. So the question is: what does
"linking" mean in the context of Java?
In an attempt to resolve this, earlier this year, Brian Behlendorf sent
the FSF a set of specific questions. The FSF indicated that the would
prefer a dialog over answering these questions. To date, the results of
this dialog have been somewhat... inconclusive.
Cliff has been a central figure in that dialog.
At the same time, there are projects like Hibernate which have
proactively taken a step to identify exactly how they interpret the term
"dynamic linking". Needless to say, the intentions of the authors means
a lot in circumstances such as these.
While I am not hopeful of the discussions with the FSF resolving
themselves any time soon, I do believe that a combination of having the
ASF deciding what clarifications are sufficient for our purposes, and
getting projects to follow Hibernate's lead is worth pursuing.
- Sam Ruby
Re: The Roller LGPL issue
Posted by Dave Johnson <da...@rollerweblogger.org>.
Cool. Please keep us posted. Any timelines you can share?
On Jul 11, 2005, at 4:42 PM, Cliff Schmidt wrote:
> Based on the conversations between ASF and FSF (which Sam referred to
> in a separate post), I'm optimistic that we will soon be able to allow
> projects to take dependencies on any unmodified LGPL library as long
> as the projects do not redistribute the library. However, we still
> need to get feedback from our legal folks and the get an official
> resolution from the board on this issue. It could go the other way,
> but this is my feeling right now.
If that comes to pass, then we could use a Maven-like approach to fetch
all of our jars (including the LGPL ones) at build time. Not perfect,
but it is workable.
> However, I would not advocate that a project has an installer that
> covertly downloads the LGPL library. I haven't done any research into
> this, but there's a line we need to draw between requiring that the
> user goes out and manually gets the library and having the installer
> invisibly put the library (including the source?) on their machine.
I agree. Covert is bad.
But an installer that displays licenses and informs the user of it's
actions would be OK? The installer could use the same Maven-like
mechanism that the build script uses.
- Dave
Re: The Roller LGPL issue
Posted by Cliff Schmidt <cl...@gmail.com>.
On 7/11/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> And here are some ideas for resolving this issue
> ----
> 1) Rewrite Roller to use non-LGPL components
> 2) Rewrite Roller to access LGPL components indirectly
> 3) Don't store LGPL components at Apache, instead download them at
> build/install time
> 4) Convince Apache to allow us to use, store and ship LGPL components
>
> For the Hibernate case, ideas #1 and #2 are expensive and will be
> *very* difficult to justify to Roller committers, management, Roller
> users, Roller fans, etc.
>
> Idea #3 has been suggested by some at Apache (Cliff?), but seems to me
> to be essentially a trick. I've been playing with the HTTPUnit
> dependencies task, which would make this pretty easy, except that the
> Maven repos don't seem include Rome 0.6, JSPWiki, and Jazzy. Also, we'd
> need to do the downloads in both our build scripts and our installer
> (we don't have an installer yet). Read more about HTTPUnit dependencies
> task here: http://www.httpunit.org/doc/dependencies.html
Based on the conversations between ASF and FSF (which Sam referred to
in a separate post), I'm optimistic that we will soon be able to allow
projects to take dependencies on any unmodified LGPL library as long
as the projects do not redistribute the library. However, we still
need to get feedback from our legal folks and the get an official
resolution from the board on this issue. It could go the other way,
but this is my feeling right now.
However, I would not advocate that a project has an installer that
covertly downloads the LGPL library. I haven't done any research into
this, but there's a line we need to draw between requiring that the
user goes out and manually gets the library and having the installer
invisibly put the library (including the source?) on their machine.
Cliff