That's where I get fuzzy (and why I've taken some time to ponder a reply).
The below is my understanding of the policy, and I've talked to Cliff a lot about it so am pretty sure I'm not saying anything incorrect. We can't distribute LGPL, but we can decide to ship an incomplete product that people have to actively plug the non-distributable dependencies into (a system requirement). A more obvious example is a JVM - there aren't any complete JVMs out there that we could ship, but every Java project requires it. The 'we' there is the fuzzy bit. It's described as the PMC of the project, so that means that Roller can ship with a Hibernate system requirement if and only if the Incubator PMC decide to do that. So I don't know. I think we're going to need to come up with a list of things left to do before graduation, then after finishing off as many as we feel we want can we need to ask the PMC if we can graduate. I'll kick that off in a different thread. Hen On 8/21/06, Dave Johnson <[EMAIL PROTECTED]> wrote:
That's pretty good. We're not being forced to ditch Hibernate, but it's in our best interest to do so -- to make installation easier and to benefit the parts of the community that have problems with LGPL. And it seems to imply that we can graduate from the incubator in our current state and only bring in a new persistence layer when we (and the implementation) are good and ready. Or am I reading that wrong? - Dave On 8/21/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 8/16/06, Dave Johnson <[EMAIL PROTECTED]> wrote: > > On 8/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > The first thing I would like to know is what the final apache stance is > > > on our use of Hibernate. Maybe it's just me, but it hasn't been totally > > > clear on what exactly our options are. I know that apache doesn't like > > > LGPL libraries, but I thought at some point there was some discussion > > > that we may be able to keep Hibernate in some situations. i.e. if we > > > were using hibernate through an open api like JPA or if there was some > > > form of alternative also available. In any case, I would like to get a > > > firm statement from apache about our options before I make any decisions > > > about what to do. can someone provide an official stance from apache? > > > > Yes. I would like that too. I've never seen the official Apache policy > > on projects shipping or depending on LGPL. Does one exist yet? > > > > I added Cliff Scmidt to the CC list. > > http://people.apache.org/~cliffs/3party.html is still as official as > it gets - it's 98% official though. We (everyone at the ASF) are > leaping in and using it. Cliff has some changes to make before > releasing it to www.apache, but they're not ground breaking changes as > far as I understand. > > LGPL policy: > > * We may not distribute LGPL licensed works. > * We can depend on LGPL licensed works, provided the user is aware of > this before using our product (forcing them to go download it from the > original source being the simplest and best way). > > The first is because LGPL is still the most weakly worded of the soft > copyleft licenses. The other main ones can be distributed, but LGPL > cannot. > > The second makes clearer sense if you consider the LGPL editor that > Roller used to ship with. After installing that as a blog server, the > Roller instance is still distributing that editor out to everyone and > so the owners of the blog server are now distributing LGPL. This may > or may not be something they are comfortable with. > > For a solely back-end dependency like Hibernate, distribution is only > going to be when somebody ships an enhanced version of Roller - which > isn't as unlikely as it sounds given that Roller seems to be doing > well in the enterprise in-house market. > > So officially - the choice for Apache Roller is between shipping > without a persistence layer and having the user add it later; and > finding a new persistence API. > > As it's a new policy, there's always a chance that the former for the > long term would incite community-wide unhappiness - it's hard to get a > consensus for what the consensus is on soft-copyleft licenses. > > Hen >
