You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Henri Yandell <ba...@generationjava.com> on 2005/11/06 17:23:49 UTC
Legal worries... Was: Roller 1.3 release
Problems, problems. Which I really hate to bring up as I want Roller to
succeed as an Apache project as much as anyone.
http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/lib/
We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
activation) jars in there.
http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/lib/
jta and jdbc-stdext are BCL.
http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/
hibernate is LGPL.
----
So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not meant
to have these in SVN, and that the imports on the LGPL jars are not meant
to be in SVN either.
Now I know that this was well known before Roller joined, so what's the
status of this? What I've read on legal-discuss/board is not the same as
the message we're giving Roller, so I'm confused. On roller-dev, Noel has
said:
"Check with Cliff, but I believe that projects will be given a timeframe
with which to eliminate LGPL dependencies. It isn't a legal (as in viral)
so much as policy issue. We would certainly need appropriate notices, in
addition to the Incubator disclaimer."
As far as I know, that's for the imports not for the inclusion in
distributions/SVN. It's also going through one of its customary
dead-in-the-water periods regarding becoming new policy.
We (roller-dev) will also need the Incubator PMC to create 'appropriate
notices', depending on what you mean by that. [I'm a part of both, so this
isn't me shirking work :) ].
So what's the deal? How do I make a release of Roller, ie) what needs to
be different from a normal release; and how do I explain this to Cliff
without it sounding like we're ignoring the lawyers.
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 6, 2005, at 1:47 PM, Henri Yandell wrote:
> On 11/6/05, Noel J. Bergman <no...@devtech.com> wrote:
>
>> Henri Yandell wrote:
>>
>>> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
>>> activation) jars in there.
>>>
>>
>>
>>> jta and jdbc-stdext are BCL.
>>>
>>
>>
>>> hibernate is LGPL.
>>>
>>
>> The BCL files are forbidden by that license to be in source
>> control, and
>> must be removed. They *are* permitted to be distributed in a
>> package. The
>> same issue exists for JAMES, Tomcat, and many other packages. At
>> some point
>> in the future, they should not be an issue, as Sun's new versions
>> will be
>> under a more open license.
>>
>
> Geronimo have their own implementations (or at least compilable
> implementations) that can be used for compiling against for probably
> all 4 of these. Then we just need to figure out how you get the Sun
> implementation in place for distributions.
>
>
>> MySQL must be the OLD LGPL driver, and is "safe" because it is
>> invoked via
>> the generic JDBC interface. The new GPL driver is forbidden
>> because our
>> legal advice to date was that MySQL's "FOSS" exception was flawed and
>> inadequate. That should be put to Cliff to raise with MySQL, but
>> he doesn't
>> appear to be around right now.
>>
>
> MySQL driver, be it LGPL or GPL, cannot be in our dists or our source
> repository.
>
> The only point where the move from LGPL to GPL has any effect is if we
> are importing the MySQL driver code directly and not via JDBC. ie)
> it's fine for us to have code that works with the GPL'd MySQL 3.x, it
> just can't import com.mysql.*; whereas the LGPL'd version could be
> imported (based on the newer forthcoming policy).
>
> I doubt we even need the MySQL driver in svn. Users should be putting
> it in the container themselves.
>
> That leaves us with ekit, jazzy and Hibernate.
>
> ekit and jazzy are both optional features. Hibernate not. With the new
> policy, which we pretty much need, ekit and jazzy are fine as long as
> the system works without them (so we need a little bit of magic and
> the ability for the spell-check button to not show); while we would
> have a limited time in which to replace Hibernate.
>
> Anyone know if there are usable implementations of the new JSR that
> Hibernate will be working against?
Hibernate itself does implement the EJB3 persistence engine (which is
what you are referring to...)
That is still LGPL though - the upside is that the API is standard so
there's no import problem, just distribution.
We'll eventually have on in Geronimo-land somehow, as we need it for
J2EE 5 (or JEE 5 or whatever it's called...). I'd also like to see
that API strapped onto the JDO project's persistence engine - it
shouldn't be that hard, but I just don't have the time.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <fl...@gmail.com>.
On 11/6/05, Noel J. Bergman <no...@devtech.com> wrote:
> Henri Yandell wrote:
> > We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
> > activation) jars in there.
>
> > jta and jdbc-stdext are BCL.
>
> > hibernate is LGPL.
>
> The BCL files are forbidden by that license to be in source control, and
> must be removed. They *are* permitted to be distributed in a package. The
> same issue exists for JAMES, Tomcat, and many other packages. At some point
> in the future, they should not be an issue, as Sun's new versions will be
> under a more open license.
Geronimo have their own implementations (or at least compilable
implementations) that can be used for compiling against for probably
all 4 of these. Then we just need to figure out how you get the Sun
implementation in place for distributions.
> MySQL must be the OLD LGPL driver, and is "safe" because it is invoked via
> the generic JDBC interface. The new GPL driver is forbidden because our
> legal advice to date was that MySQL's "FOSS" exception was flawed and
> inadequate. That should be put to Cliff to raise with MySQL, but he doesn't
> appear to be around right now.
MySQL driver, be it LGPL or GPL, cannot be in our dists or our source
repository.
The only point where the move from LGPL to GPL has any effect is if we
are importing the MySQL driver code directly and not via JDBC. ie)
it's fine for us to have code that works with the GPL'd MySQL 3.x, it
just can't import com.mysql.*; whereas the LGPL'd version could be
imported (based on the newer forthcoming policy).
I doubt we even need the MySQL driver in svn. Users should be putting
it in the container themselves.
That leaves us with ekit, jazzy and Hibernate.
ekit and jazzy are both optional features. Hibernate not. With the new
policy, which we pretty much need, ekit and jazzy are fine as long as
the system works without them (so we need a little bit of magic and
the ability for the spell-check button to not show); while we would
have a limited time in which to replace Hibernate.
Anyone know if there are usable implementations of the new JSR that
Hibernate will be working against?
It seems to me that we need to do a java.net release of 1.3. ie) a
community supported 'fork'; and hold 2.0 back until we get the issues
above dealt with. I don't see any reason why we can't do 'internal'
releases; namely tagging SVN at special points and having Sun, IBM,
JRoller build from those tags (given that it's pretty simple and
they're involved with the project anyway).
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <fl...@gmail.com>.
On 11/7/05, Anil Gangolli <an...@busybuddha.org> wrote:
> Inline comments below...
> Henri Yandell wrote:
>
> >
> >For 2.0 I think we should be trying to get a clear LGPL message, or
> >proto-message; and get things dealt with prior to the release.
> >
> >Effectively this means:
> >
> >1) Removing 'bad' jars from SVN.
> >2) Modifying install process/build instructions to instruct user to
> >download the relevant jars themselves.
> >
> >
> For item (2), I'd like to understand the boundary of what we can do.
> For example, can we provide ant scripts / other build infrastructure
> that is generic, and configured specifically to download these jars? If
> so, we should start building a network-based pre-build target and an
> installer in the Roller 2.x line.
Usually the legality is that the user has to initiate the download.
It's an issue lots of things have (Netbeans has it I think), often
with the BCL licensed things.
JAMES probably have a good strategy which we can use.
> >3) Ensuring nobody is concerned with the various usages of LGPL'd code.
> >
> >Hen
> >
> >
> For Hibernate, we do import org.hibernate.* classes and use Hibernate
> APIs directly currently. So we are currently in the "worst" category of
> "offenders".
Not so bad; the worst part is having the jars in SVN.
The legality of being allowed to import org.hibernate.* is pretty much
all cleared up, the question is over the policy. Should ASF projects
depend on LGPL or should it not. Historically the answer was that yes
they can, but only for optional features. Currently it's suggested
that they can for required features too, but with a time limit (1 year
currently the floated time).
> A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
> I think will force us to require Java 5 / JDK 1.5.x.
Yep, looks like Java 5. :(
> The main thing
> that bugs me about this direction is the cramped timing with respect to
> the maturity levels of JSR 220 and the Hibernate support for it,
> although alternate supporting implementations might be considered along
> this line as well.
Yep, though we would have a time period in which to get it done (and
for Hibernate to mature its JSR 220 support).
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <fl...@gmail.com>.
On 11/7/05, Matt Raible <mr...@gmail.com> wrote:
> On 11/7/05, Henri Yandell <fl...@gmail.com> wrote:
> > On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> > > Actually, I'm not sure it's important to Sun. To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
> >
> >
> > While not wanting to end up in a 'he-said, she-said'; I thought the
> > history was that the Roller chose not to join prior to Dave joining
> > Sun, but that Sun pointed out further advantages. One of these being
> > attention to legal issues, and the matter was rethought. I apologise
> > if I've got that wrong though, much of that is probably reading into
> > things being said.
> >
> > I just mailed concerning the issue being over ASF policy now; that
> > policy is most concerned with the rights of downstream users. ie) if a
> > company were to release a commercial version of the project, that the
> > LGPL usage wouldn't torpedo their desire to do so.
>
> I know this is a dead horse, but I feel like beating something today. ;-)
I'll be at ApacheCon, just promise to give me some beer after the beating :)
> http://www.hibernate.org/196.html
>
> <quote>
> Using Hibernate (by importing Hibernate's public interfaces in your
> Java code), and extending Hibernate (by subclassing or implementation
> of an extension interface) is considered by the authors of Hibernate
> to be dynamic linking. Hence our interpretation of the LGPL is that
> the use of the unmodified Hibernate source does not affect the license
> of your application code.
> </quote>
>
> We haven't modified Hibernate at all, so including hibernate3.jar in
> our code does not have a viral nature to it - at least as far as I'm
> concerned.
Yep. Kinda. No. My head hurts.
So src/java/roller is fine, not affected by the LGPL licence, however
Roller.zip is affected by the LGPL. The product would not be ASL, but
rather ASL/LGPL. Given that LGPL is stricter on some subjects than ASL
(I'll have to dig into email to list them), this means that
effectively the Roller distribution is more encumbered than a product
from Apache usually is.
Although originally the aim was to get the Hibernate clause recognised
as usable, and we even made a generic lawyer-written version of it,
talking with the FSF allowed Cliff to get to a point where we're all
happy that linkage is not a problem; distribution then reared its
head.
> That being said, if it's just a matter of not being able to include
> JARs in SVN, we could use Maven 2's Ant tasks, and download them
> dynamically before building everything. I've played with this a bit
> and it seems to work pretty well (though the metadata for Maven's
> transitive dependencies still needs quite a bit of work).
I think an important legal part is user awareness. Or even possibly interaction.
If we had a bit that pops up and says: "Please click here to download
FOO, by clicking here you are agreeing to the licence in <url to
LGPL>", then I think we can do it. Or we might have to actually show
them the license.
In reality the onus would be on us to match what the community is
doing; ie) how much do James do etc. If that's not enough, the ASF at
large would need to adjust.
Easiest, in the short term, is just to ask people to download jars
from ibiblio urls with a disclaimer that they are accepting the LGPL
license.
> I'd rather pursue fancy installation
> tactics than re-write anything. Although, we probably could've
> re-wrote everything by now rather than sending all these e-mails. ;-)
The above takes care of the short term problem, and then just leaves
questions of the pressure to not have a required dependency on LGPL
licensed works. ie) pressure to make Hibernate optional.
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Matt Raible <mr...@gmail.com>.
On 11/7/05, Henri Yandell <fl...@gmail.com> wrote:
> On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> > Actually, I'm not sure it's important to Sun. To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
>
>
> While not wanting to end up in a 'he-said, she-said'; I thought the
> history was that the Roller chose not to join prior to Dave joining
> Sun, but that Sun pointed out further advantages. One of these being
> attention to legal issues, and the matter was rethought. I apologise
> if I've got that wrong though, much of that is probably reading into
> things being said.
>
> I just mailed concerning the issue being over ASF policy now; that
> policy is most concerned with the rights of downstream users. ie) if a
> company were to release a commercial version of the project, that the
> LGPL usage wouldn't torpedo their desire to do so.
I know this is a dead horse, but I feel like beating something today. ;-)
http://www.hibernate.org/196.html
<quote>
Using Hibernate (by importing Hibernate's public interfaces in your
Java code), and extending Hibernate (by subclassing or implementation
of an extension interface) is considered by the authors of Hibernate
to be dynamic linking. Hence our interpretation of the LGPL is that
the use of the unmodified Hibernate source does not affect the license
of your application code.
</quote>
We haven't modified Hibernate at all, so including hibernate3.jar in
our code does not have a viral nature to it - at least as far as I'm
concerned.
That being said, if it's just a matter of not being able to include
JARs in SVN, we could use Maven 2's Ant tasks, and download them
dynamically before building everything. I've played with this a bit
and it seems to work pretty well (though the metadata for Maven's
transitive dependencies still needs quite a bit of work).
We could also have an "installer" that downloads JARs and prompts the
user to restart their context. I'd rather pursue fancy installation
tactics than re-write anything. Although, we probably could've
re-wrote everything by now rather than sending all these e-mails. ;-)
Matt
>
>
> > That being said, I agree with Matt. I am just here to develop code and make the project better. From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason. So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.
>
>
> Agreed. +1 :) What needs deciding is what we think 'fairly easily' is.
>
> Currently I see us needing to:
>
> 1) remove some jars from SVN and have Ant post a message to the user
> asking them to put those files in place (with URLs). Not pretty, but
> good and workable.
>
> 2) do the same when installing a distribution
>
> 3) have a plan for required dependencies (namely Hibernate). JSR 220
> seems like a good eventual plan, we just have to get a feel for the
> timing. We're already on the right version of Hibernate right?
>
> Then we have to decide how long we release 'forks' at java.net and
> when we can start to release at apache.org. 1.3 is looking like a
> java.net; and it sounds like 2.0 wants to release very quickly so that
> would imply java.net there too.
>
> So... is the above too far from 'fairly easily'? Should we be talking
> about extracting to java.net, or about modifying things?
>
> Hen
>
Re: Legal worries... Was: Roller 1.3 release
Posted by Allen Gilliland <Al...@Sun.COM>.
On Mon, 2005-11-07 at 11:06, Henri Yandell wrote:
> On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> > Actually, I'm not sure it's important to Sun. To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
>
>
> While not wanting to end up in a 'he-said, she-said'; I thought the
> history was that the Roller chose not to join prior to Dave joining
> Sun, but that Sun pointed out further advantages. One of these being
> attention to legal issues, and the matter was rethought. I apologise
> if I've got that wrong though, much of that is probably reading into
> things being said.
>
> I just mailed concerning the issue being over ASF policy now; that
> policy is most concerned with the rights of downstream users. ie) if a
> company were to release a commercial version of the project, that the
> LGPL usage wouldn't torpedo their desire to do so.
>
I actually don't know anything about the connection between Sun and moving to Apache, I am really just a code monkey. However, I wouldn't have thought Sun would encourage us to move out of java.net.
>
> > That being said, I agree with Matt. I am just here to develop code and make the project better. From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason. So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.
>
>
> Agreed. +1 :) What needs deciding is what we think 'fairly easily' is.
>
> Currently I see us needing to:
>
> 1) remove some jars from SVN and have Ant post a message to the user
> asking them to put those files in place (with URLs). Not pretty, but
> good and workable.
this is really only a pain for us developers and something I'm sure we could live with.
>
> 2) do the same when installing a distribution
a bummer, but would it be possible for us to package this stuff somewhere non-Apache like rollerweblogger.org and have an easy bundle for people to access? i.e. a Roller-1.3-dependencies.zip?
>
> 3) have a plan for required dependencies (namely Hibernate). JSR 220
> seems like a good eventual plan, we just have to get a feel for the
> timing. We're already on the right version of Hibernate right?
this is the part I have a problem with. I think Anil's points are exactly the same concerns I have.
- how mature is JSR 220? do we really want to commit to it now even if we don't have to implement it until later in the year?
- jdk 1.5? i think this would be a big no-no. i strongly disagree with requiring our users to be on the very latest jdk. i think we should be supporting the 2 latest jdk versions, which at this time is 1.4 and 1.5
- and even if we did agree on both of the above, we would have to go back and do a fairly significant amount of work just to change something that's already working just fine :(
-- Allen
>
> Then we have to decide how long we release 'forks' at java.net and
> when we can start to release at apache.org. 1.3 is looking like a
> java.net; and it sounds like 2.0 wants to release very quickly so that
> would imply java.net there too.
>
> So... is the above too far from 'fairly easily'? Should we be talking
> about extracting to java.net, or about modifying things?
>
> Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <fl...@gmail.com>.
On 11/7/05, Allen Gilliland <Al...@sun.com> wrote:
> Actually, I'm not sure it's important to Sun. To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
While not wanting to end up in a 'he-said, she-said'; I thought the
history was that the Roller chose not to join prior to Dave joining
Sun, but that Sun pointed out further advantages. One of these being
attention to legal issues, and the matter was rethought. I apologise
if I've got that wrong though, much of that is probably reading into
things being said.
I just mailed concerning the issue being over ASF policy now; that
policy is most concerned with the rights of downstream users. ie) if a
company were to release a commercial version of the project, that the
LGPL usage wouldn't torpedo their desire to do so.
> That being said, I agree with Matt. I am just here to develop code and make the project better. From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason. So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.
Agreed. +1 :) What needs deciding is what we think 'fairly easily' is.
Currently I see us needing to:
1) remove some jars from SVN and have Ant post a message to the user
asking them to put those files in place (with URLs). Not pretty, but
good and workable.
2) do the same when installing a distribution
3) have a plan for required dependencies (namely Hibernate). JSR 220
seems like a good eventual plan, we just have to get a feel for the
timing. We're already on the right version of Hibernate right?
Then we have to decide how long we release 'forks' at java.net and
when we can start to release at apache.org. 1.3 is looking like a
java.net; and it sounds like 2.0 wants to release very quickly so that
would imply java.net there too.
So... is the above too far from 'fairly easily'? Should we be talking
about extracting to java.net, or about modifying things?
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Allen Gilliland <Al...@Sun.COM>.
Actually, I'm not sure it's important to Sun. To my knowledge the decision to move to apache was made by the Roller community and had nothing to do with Sun.
That being said, I agree with Matt. I am just here to develop code and make the project better. From all the recent discussions it sounds like being part of Apache will force us to backtrack quite a bit for no good reason. So I agree that if we can't find a way to resolve the legal issues fairly easily then maybe we shouldn't be an Apache project yet.
-- Allen
On Mon, 2005-11-07 at 08:29, Matt Raible wrote:
> I know that having Roller as an Apache project is important for Dave
> and Sun. However, I think it's important to state my opinion. If
> it's going to require a significant re-write of Roller - my vote is to
> back out of the incubator and continue as an open-source project on
> java.net (or another location that doesn't have LGPL restrictions).
>
> Matt
>
> On 11/7/05, Anil Gangolli <an...@busybuddha.org> wrote:
> > Inline comments below...
> > Henri Yandell wrote:
> >
> > >
> > >For 2.0 I think we should be trying to get a clear LGPL message, or
> > >proto-message; and get things dealt with prior to the release.
> > >
> > >Effectively this means:
> > >
> > >1) Removing 'bad' jars from SVN.
> > >2) Modifying install process/build instructions to instruct user to
> > >download the relevant jars themselves.
> > >
> > >
> > For item (2), I'd like to understand the boundary of what we can do.
> > For example, can we provide ant scripts / other build infrastructure
> > that is generic, and configured specifically to download these jars? If
> > so, we should start building a network-based pre-build target and an
> > installer in the Roller 2.x line.
> >
> >
> > >3) Ensuring nobody is concerned with the various usages of LGPL'd code.
> > >
> > >Hen
> > >
> > >
> > For Hibernate, we do import org.hibernate.* classes and use Hibernate
> > APIs directly currently. So we are currently in the "worst" category of
> > "offenders".
> >
> > A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
> > I think will force us to require Java 5 / JDK 1.5.x. The main thing
> > that bugs me about this direction is the cramped timing with respect to
> > the maturity levels of JSR 220 and the Hibernate support for it,
> > although alternate supporting implementations might be considered along
> > this line as well.
> >
> >
> >
Re: Legal worries... Was: Roller 1.3 release
Posted by Matt Raible <mr...@gmail.com>.
I know that having Roller as an Apache project is important for Dave
and Sun. However, I think it's important to state my opinion. If
it's going to require a significant re-write of Roller - my vote is to
back out of the incubator and continue as an open-source project on
java.net (or another location that doesn't have LGPL restrictions).
Matt
On 11/7/05, Anil Gangolli <an...@busybuddha.org> wrote:
> Inline comments below...
> Henri Yandell wrote:
>
> >
> >For 2.0 I think we should be trying to get a clear LGPL message, or
> >proto-message; and get things dealt with prior to the release.
> >
> >Effectively this means:
> >
> >1) Removing 'bad' jars from SVN.
> >2) Modifying install process/build instructions to instruct user to
> >download the relevant jars themselves.
> >
> >
> For item (2), I'd like to understand the boundary of what we can do.
> For example, can we provide ant scripts / other build infrastructure
> that is generic, and configured specifically to download these jars? If
> so, we should start building a network-based pre-build target and an
> installer in the Roller 2.x line.
>
>
> >3) Ensuring nobody is concerned with the various usages of LGPL'd code.
> >
> >Hen
> >
> >
> For Hibernate, we do import org.hibernate.* classes and use Hibernate
> APIs directly currently. So we are currently in the "worst" category of
> "offenders".
>
> A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
> I think will force us to require Java 5 / JDK 1.5.x. The main thing
> that bugs me about this direction is the cramped timing with respect to
> the maturity levels of JSR 220 and the Hibernate support for it,
> although alternate supporting implementations might be considered along
> this line as well.
>
>
>
Re: Legal worries... Was: Roller 1.3 release
Posted by Anil Gangolli <an...@busybuddha.org>.
Inline comments below...
Henri Yandell wrote:
>
>For 2.0 I think we should be trying to get a clear LGPL message, or
>proto-message; and get things dealt with prior to the release.
>
>Effectively this means:
>
>1) Removing 'bad' jars from SVN.
>2) Modifying install process/build instructions to instruct user to
>download the relevant jars themselves.
>
>
For item (2), I'd like to understand the boundary of what we can do.
For example, can we provide ant scripts / other build infrastructure
that is generic, and configured specifically to download these jars? If
so, we should start building a network-based pre-build target and an
installer in the Roller 2.x line.
>3) Ensuring nobody is concerned with the various usages of LGPL'd code.
>
>Hen
>
>
For Hibernate, we do import org.hibernate.* classes and use Hibernate
APIs directly currently. So we are currently in the "worst" category of
"offenders".
A JSR-220-based rewrite would entail quite a bit of effort for 2.0, and
I think will force us to require Java 5 / JDK 1.5.x. The main thing
that bugs me about this direction is the cramped timing with respect to
the maturity levels of JSR 220 and the Hibernate support for it,
although alternate supporting implementations might be considered along
this line as well.
Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <fl...@gmail.com>.
(Dropped the PMC, sorry, resending).
On 11/6/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
> > On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
> >> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not
> >> meant
> >> to have these in SVN, and that the imports on the LGPL jars are not
> >> meant
> >> to be in SVN either.
> >
> > Correct. The official ASF policy today is "No LGPL dependencies in
> > Java
> > projects." As you mention, the board has discussed allowing LGPL for
> > Java projects but any resolution stating that has been tabled
> > indefinitely. A small part of the reason for the delay is that we've
> > been told Eben Moglen from the FSF will be issuing an opinion
> > clarifying
> > the relationship between LGPL and Java.
>
> We in the Roller project and the Apache folks who helped usher us into
> the Incubator were all well aware of Roller's dependence on LGPL
> libraries. When we voted to move Roller to Apache, we all knew that
> work would have to be done to resolve the LGPL issue. We also
> discussed the worst-case scenario of replacing Hibernate with JDO or
> something similar.
The thinking is that we can replace Hibernate with the JSR-xxx API.
Then Hibernate would be much like using a JDBC driver.
> We heard that a new LGPL policy was forthcoming, so
> we entered the incubator and crossed our fingers hoping for the best.
>
> I keep on hearing different proposed LGPL policies, so I'm pretty
> confused at this point.
It's confusing. I'll buy you a beer in San Diego and bring you up to
date on however things are then.
> In the interim, we still need to ship releases to our users. Roller 1.3
> is ready for release and Roller 2.0 is close on it's heels. If we've
> really painted ourselves into a corner and can't make releases through
> either the ASF or Java.Net, then we should back out of the Incubator
> and come back later when ASF has figured out an LGPL policy.
There's no reason to my mind why we can't release through Java.Net. It
leaves a bad taste in some people's mouths for committers to release
forks (which in essence this would be); and yet we fight for the right
for companies to be able to re-release/fork our code. Anyone who
complains need merely be invited to submit some patches to solve the
LGPL issue :)
The important part to figure out is whether the previous release was
correct. We need to make sure it's not called Apache Xxxxat all, and
make sure we include "This code based on Apache code" type of
messages.
> I really REALLY don't want to do that, so can we please get a green
> light to ship interim "incubating" releases through Java.Net?
+1. It's the only way forward for 1.3.
We need to kill the bad jars from SVN asap; but hopefully we can make
a java.net release more asap than killing the bad jars. Any open
issues with 1.3 apart from the LGPL stuff?
For 2.0 I think we should be trying to get a clear LGPL message, or
proto-message; and get things dealt with prior to the release.
Effectively this means:
1) Removing 'bad' jars from SVN.
2) Modifying install process/build instructions to instruct user to
download the relevant jars themselves.
3) Ensuring nobody is concerned with the various usages of LGPL'd code.
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <fl...@gmail.com>.
On 11/6/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
> > On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
> >> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not
> >> meant
> >> to have these in SVN, and that the imports on the LGPL jars are not
> >> meant
> >> to be in SVN either.
> >
> > Correct. The official ASF policy today is "No LGPL dependencies in
> > Java
> > projects." As you mention, the board has discussed allowing LGPL for
> > Java projects but any resolution stating that has been tabled
> > indefinitely. A small part of the reason for the delay is that we've
> > been told Eben Moglen from the FSF will be issuing an opinion
> > clarifying
> > the relationship between LGPL and Java.
>
> We in the Roller project and the Apache folks who helped usher us into
> the Incubator were all well aware of Roller's dependence on LGPL
> libraries. When we voted to move Roller to Apache, we all knew that
> work would have to be done to resolve the LGPL issue. We also
> discussed the worst-case scenario of replacing Hibernate with JDO or
> something similar.
The thinking is that we can replace Hibernate with the JSR-xxx API.
Then Hibernate would be much like using a JDBC driver.
> We heard that a new LGPL policy was forthcoming, so
> we entered the incubator and crossed our fingers hoping for the best.
>
> I keep on hearing different proposed LGPL policies, so I'm pretty
> confused at this point.
It's confusing. I'll buy you a beer in San Diego and bring you up to
date on however things are then.
> In the interim, we still need to ship releases to our users. Roller 1.3
> is ready for release and Roller 2.0 is close on it's heels. If we've
> really painted ourselves into a corner and can't make releases through
> either the ASF or Java.Net, then we should back out of the Incubator
> and come back later when ASF has figured out an LGPL policy.
There's no reason to my mind why we can't release through Java.Net. It
leaves a bad taste in some people's mouths for committers to release
forks (which in essence this would be); and yet we fight for the right
for companies to be able to re-release/fork our code. Anyone who
complains need merely be invited to submit some patches to solve the
LGPL issue :)
The important part to figure out is whether the previous release was
correct. We need to make sure it's not called Apache Xxxxat all, and
make sure we include "This code based on Apache code" type of
messages.
> I really REALLY don't want to do that, so can we please get a green
> light to ship interim "incubating" releases through Java.Net?
+1. It's the only way forward for 1.3.
We need to kill the bad jars from SVN asap; but hopefully we can make
a java.net release more asap than killing the bad jars. Any open
issues with 1.3 apart from the LGPL stuff?
For 2.0 I think we should be trying to get a clear LGPL message, or
proto-message; and get things dealt with prior to the release.
Effectively this means:
1) Removing 'bad' jars from SVN.
2) Modifying install process/build instructions to instruct user to
download the relevant jars themselves.
3) Ensuring nobody is concerned with the various usages of LGPL'd code.
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by Cliff Schmidt <cl...@apache.org>.
On Nov 6, 2005, at 2:24 PM, Dave Johnson wrote:
> On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
>> On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
>>> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're
>>> not meant
>>> to have these in SVN, and that the imports on the LGPL jars are
>>> not meant
>>> to be in SVN either.
>>
>> Correct. The official ASF policy today is "No LGPL dependencies
>> in Java
>> projects." As you mention, the board has discussed allowing LGPL for
>> Java projects but any resolution stating that has been tabled
>> indefinitely. A small part of the reason for the delay is that we've
>> been told Eben Moglen from the FSF will be issuing an opinion
>> clarifying
>> the relationship between LGPL and Java.
>
> We in the Roller project and the Apache folks who helped usher us
> into the Incubator were all well aware of Roller's dependence on
> LGPL libraries. When we voted to move Roller to Apache, we all knew
> that work would have to be done to resolve the LGPL issue. We also
> discussed the worst-case scenario of replacing Hibernate with JDO
> or something similar. We heard that a new LGPL policy was
> forthcoming, so we entered the incubator and crossed our fingers
> hoping for the best.
>
> I keep on hearing different proposed LGPL policies, so I'm pretty
> confused at this point. One proposed policy said that we can depend
> on LGPL, but we can't ship it. Another said that we can ship LGPL
> jars, but we can't have a "hard" dependency on them. So I'm all for
> resolving the LGPL issues but I want to see the new policy first.
> We've got a lot of features on our TODO list and I really don't
> want to do unnecessary work. Please put the LGPL issue back on the
> table. We need a resolution.
And I apologize that this policy has taken as long as it has. The
easy part for me was doing the research to understand the LGPL
incompatibility issues. The hard part was getting consensus across
the ASF about what other-licensed software we should be taking
dependencies on and/or distributing. I've already tried solving the
LGPL issue in a one-off style, and it was rejected. I now realize
the only way to deal with the LGPL issue is to get some solid
licensing principles ratified by the board, based on a policy that
has more consensus than anything that has been proposed so far.
So, I'm not sure if this seems like too far from now for you, but I
am committed to getting something formally agreed upon and announced
by ApacheCon, on 12 Dec -- five weeks from tomorrow.
Cliff
> In the interim, we still need to ship releases to our users. Roller
> 1.3 is ready for release and Roller 2.0 is close on it's heels. If
> we've really painted ourselves into a corner and can't make
> releases through either the ASF or Java.Net, then we should back
> out of the Incubator and come back later when ASF has figured out
> an LGPL policy.
>
> I really REALLY don't want to do that, so can we please get a green
> light to ship interim "incubating" releases through Java.Net?
>
> - Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@incubator.apache.org
> For additional commands, e-mail: pmc-help@incubator.apache.org
>
Re: Legal worries... Was: Roller 1.3 release
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 6, 2005, at 1:16 PM, Justin Erenkrantz wrote:
> On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
>> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not
>> meant
>> to have these in SVN, and that the imports on the LGPL jars are not
>> meant
>> to be in SVN either.
>
> Correct. The official ASF policy today is "No LGPL dependencies in
> Java
> projects." As you mention, the board has discussed allowing LGPL for
> Java projects but any resolution stating that has been tabled
> indefinitely. A small part of the reason for the delay is that we've
> been told Eben Moglen from the FSF will be issuing an opinion
> clarifying
> the relationship between LGPL and Java.
We in the Roller project and the Apache folks who helped usher us into
the Incubator were all well aware of Roller's dependence on LGPL
libraries. When we voted to move Roller to Apache, we all knew that
work would have to be done to resolve the LGPL issue. We also
discussed the worst-case scenario of replacing Hibernate with JDO or
something similar. We heard that a new LGPL policy was forthcoming, so
we entered the incubator and crossed our fingers hoping for the best.
I keep on hearing different proposed LGPL policies, so I'm pretty
confused at this point. One proposed policy said that we can depend on
LGPL, but we can't ship it. Another said that we can ship LGPL jars,
but we can't have a "hard" dependency on them. So I'm all for resolving
the LGPL issues but I want to see the new policy first. We've got a lot
of features on our TODO list and I really don't want to do unnecessary
work. Please put the LGPL issue back on the table. We need a
resolution.
In the interim, we still need to ship releases to our users. Roller 1.3
is ready for release and Roller 2.0 is close on it's heels. If we've
really painted ourselves into a corner and can't make releases through
either the ASF or Java.Net, then we should back out of the Incubator
and come back later when ASF has figured out an LGPL policy.
I really REALLY don't want to do that, so can we please get a green
light to ship interim "incubating" releases through Java.Net?
- Dave
Re: Legal worries... Was: Roller 1.3 release
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Nov 06, 2005 at 11:23:49AM -0500, Henri Yandell wrote:
> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not meant
> to have these in SVN, and that the imports on the LGPL jars are not meant
> to be in SVN either.
Correct. The official ASF policy today is "No LGPL dependencies in Java
projects." As you mention, the board has discussed allowing LGPL for
Java projects but any resolution stating that has been tabled
indefinitely. A small part of the reason for the delay is that we've
been told Eben Moglen from the FSF will be issuing an opinion clarifying
the relationship between LGPL and Java.
However, none of the board's discussions around LGPL have discussed
allowing any LGPL code to be checked into the ASF Subversion repository.
What has been discussed is allowing an ASF project, under the ALv2
license, to optionally *use* but not *distribute* LGPL code. If a
project requires LGPL code to operate, the board has discussed a
one-year exception to remove that hard dependency.
Plus, if an ASF project wants to use an LGPL library, end users will
have to fetch the LGPL dependencies themselves.
However, none of this has been approved by the Board. There might be
some eventual wiggle room in allowing re-distribution in end-user
releases, but that would have to be hammered out. -- justin
Re: Legal worries... Was: Roller 1.3 release
Posted by Anil Gangolli <an...@busybuddha.org>.
Henri,
Thanks for pushing this and also doing an audit/survey of our dependency
jars.
I was surprised to see the the BCL jars mentioned. Are Sun BCL
redistributables also not kosher here? This is the first time I've
heard of that, and I don't quite understand the rationale, (as opposed
to LGPL, where I think I do). Is this due to the US export restriction
compliance clause? Pointer to some description of this issue on Apache?
--a.
Henri Yandell wrote:
>
> Problems, problems. Which I really hate to bring up as I want Roller
> to succeed as an Apache project as much as anyone.
>
> http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/lib/
>
> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
> activation) jars in there.
>
> http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/lib/
>
>
> jta and jdbc-stdext are BCL.
>
> http://svn.apache.org/repos/asf/incubator/roller/trunk/tools/hibernate-3.0/
>
>
> hibernate is LGPL.
>
> ----
>
> So at least 5 LGPL jars and 4 BCL jars. As far as I know, we're not
> meant to have these in SVN, and that the imports on the LGPL jars are
> not meant to be in SVN either.
>
> Now I know that this was well known before Roller joined, so what's
> the status of this? What I've read on legal-discuss/board is not the
> same as the message we're giving Roller, so I'm confused. On
> roller-dev, Noel has said:
>
> "Check with Cliff, but I believe that projects will be given a
> timeframe with which to eliminate LGPL dependencies. It isn't a legal
> (as in viral) so much as policy issue. We would certainly need
> appropriate notices, in addition to the Incubator disclaimer."
>
> As far as I know, that's for the imports not for the inclusion in
> distributions/SVN. It's also going through one of its customary
> dead-in-the-water periods regarding becoming new policy.
>
> We (roller-dev) will also need the Incubator PMC to create
> 'appropriate notices', depending on what you mean by that. [I'm a part
> of both, so this isn't me shirking work :) ].
>
> So what's the deal? How do I make a release of Roller, ie) what needs
> to be different from a normal release; and how do I explain this to
> Cliff without it sounding like we're ignoring the lawyers.
>
> Hen
>
>
Re: Legal worries... Was: Roller 1.3 release
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 6, 2005, at 3:12 PM, Henri Yandell wrote:
>
>
> On Sun, 6 Nov 2005, Geir Magnusson Jr. wrote:
>
>
>>
>> On Nov 6, 2005, at 1:10 PM, Noel J. Bergman wrote:
>>
>>
>>> Henri Yandell wrote:
>>> The BCL files are forbidden by that license to be in source
>>> control, and
>>> must be removed. They *are* permitted to be distributed in a
>>> package. The
>>> same issue exists for JAMES, Tomcat, and many other packages. At
>>> some point
>>> in the future, they should not be an issue, as Sun's new versions
>>> will be
>>> under a more open license.
>>>
>>
>> Why? The BCL requires us (and our users) to indemnify Sun.
>> That's now acceptable?
>>
>
> Something for you to continue to push on legal-discuss/board etc
> Geir. The current policy that I've seen repeated is that we can
> ship as a package, but not individually or put in svn (unsure if
> that's because putting in svn would mean ship individually).
Ug. Yes, the license prevents distribution outside of the program
that uses it, hence no CVS/SVN. When I was focused on this with Sun,
they did offer to give us permission to keep in SVN/CVS because that
was part of our bona fide open source development process, rather
than a distribution system.
We got rid of the field of use problem (no use in nukes...) but never
could get past the indemnification.
>
> Until we have an official policy on it, the community policy is all
> we have to work with; so another one for Cliff's TODO list to get
> ironed out :)
>
Yes, I'll certainly defer to Cliff on this one.
geir
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@incubator.apache.org
> For additional commands, e-mail: pmc-help@incubator.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Legal worries... Was: Roller 1.3 release
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 6 Nov 2005, Geir Magnusson Jr. wrote:
>
> On Nov 6, 2005, at 1:10 PM, Noel J. Bergman wrote:
>
>> Henri Yandell wrote:
>>
>> The BCL files are forbidden by that license to be in source control, and
>> must be removed. They *are* permitted to be distributed in a package. The
>> same issue exists for JAMES, Tomcat, and many other packages. At some
>> point
>> in the future, they should not be an issue, as Sun's new versions will be
>> under a more open license.
>
> Why? The BCL requires us (and our users) to indemnify Sun. That's now
> acceptable?
Something for you to continue to push on legal-discuss/board etc Geir. The
current policy that I've seen repeated is that we can ship as a package,
but not individually or put in svn (unsure if that's because putting in
svn would mean ship individually).
Until we have an official policy on it, the community policy is all we
have to work with; so another one for Cliff's TODO list to get ironed out
:)
Hen
Re: Legal worries... Was: Roller 1.3 release
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Nov 6, 2005, at 1:10 PM, Noel J. Bergman wrote:
> Henri Yandell wrote:
>
>> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
>> activation) jars in there.
>>
>
>
>> jta and jdbc-stdext are BCL.
>>
>
>
>> hibernate is LGPL.
>>
>
> The BCL files are forbidden by that license to be in source
> control, and
> must be removed. They *are* permitted to be distributed in a
> package. The
> same issue exists for JAMES, Tomcat, and many other packages. At
> some point
> in the future, they should not be an issue, as Sun's new versions
> will be
> under a more open license.
Why? The BCL requires us (and our users) to indemnify Sun. That's
now acceptable?
>
> MySQL must be the OLD LGPL driver, and is "safe" because it is
> invoked via
> the generic JDBC interface. The new GPL driver is forbidden
> because our
> legal advice to date was that MySQL's "FOSS" exception was flawed and
> inadequate. That should be put to Cliff to raise with MySQL, but
> he doesn't
> appear to be around right now.
>
> I cannot comment on the other LGPL code beyond the current
> discussions,
> which have yet to be ratified.
>
>
>> I believe that projects will be given a timeframe with which to
>> eliminate
>> LGPL dependencies. It isn't a legal (as in viral) so much as policy
>>
> issue.
>
>
>> We (roller-dev) will also need the Incubator PMC to create
>> 'appropriate
>> notices', depending on what you mean by that.
>>
>
> The standard Incubator disclaimer, plus notice of any license other
> than the
> Apache License.
>
>
>> how do I explain this to Cliff
>>
>
> Cliff should understand this well. If he is around, we can try to
> push
> through a ratified policy.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@incubator.apache.org
> For additional commands, e-mail: pmc-help@incubator.apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: Legal worries... Was: Roller 1.3 release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Henri Yandell wrote:
> We have 4 LGPL (ekit, ekit-applet, jazzy, mm.mysql), 2 BCL (mail,
> activation) jars in there.
> jta and jdbc-stdext are BCL.
> hibernate is LGPL.
The BCL files are forbidden by that license to be in source control, and
must be removed. They *are* permitted to be distributed in a package. The
same issue exists for JAMES, Tomcat, and many other packages. At some point
in the future, they should not be an issue, as Sun's new versions will be
under a more open license.
MySQL must be the OLD LGPL driver, and is "safe" because it is invoked via
the generic JDBC interface. The new GPL driver is forbidden because our
legal advice to date was that MySQL's "FOSS" exception was flawed and
inadequate. That should be put to Cliff to raise with MySQL, but he doesn't
appear to be around right now.
I cannot comment on the other LGPL code beyond the current discussions,
which have yet to be ratified.
> I believe that projects will be given a timeframe with which to eliminate
> LGPL dependencies. It isn't a legal (as in viral) so much as policy
issue.
> We (roller-dev) will also need the Incubator PMC to create 'appropriate
> notices', depending on what you mean by that.
The standard Incubator disclaimer, plus notice of any license other than the
Apache License.
> how do I explain this to Cliff
Cliff should understand this well. If he is around, we can try to push
through a ratified policy.
--- Noel