You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Jason Dillon <ja...@planet57.com> on 2009/07/07 14:57:12 UTC
Fwd: [Jline-users] Windows ANSI colors patch
Can anyone chime in here as to wether a java library (jansi) which
uses a LGPL (optional library) JNA is compatible with the ASL 2?
--jason
Begin forwarded message:
> From: Hiram Chirino <hi...@logicblaze.com>
> Date: July 7, 2009 7:21:44 PM GMT+07:00
> To: Jason Dillon <ja...@planet57.com>
> Cc: jline-users@lists.sourceforge.net
> Subject: Re: [Jline-users] Windows ANSI colors patch
>
> Yeah. that's why the JNA bit is optional. JNA is an awesomely
> powerful lib, I do wish it was ASL/BSDish. Maybe we can convince
> them to switch?
>
> Regards,
> Hiram
>
> On Tue, Jul 7, 2009 at 2:16 AM, Jason Dillon <ja...@planet57.com>
> wrote:
> Small problem, JNA is LGPL :-( Too bad, seems very useful.
>
> --jason
>
>
> On Jul 7, 2009, at 12:11 PM, Hiram Chirino wrote:
>
>> Ok.. time to dust off this old thread.
>>
>> I never did find that patch.. but I put together a better
>> implementation for java at:
>> http://jansi.fusesource.org/
>>
>> It's basically a ANSI escape sequence handler implemented as on
>> OutputStream filter. The default implementation just strips out
>> the escape sequences, and then if you have the JNA library in your
>> path, it properly implements the ANSI colorization and cursor
>> operations on Windows.
>>
>> Regards,
>> Hiram
>>
>> On Thu, Mar 5, 2009 at 11:00 AM, Jason Dillon <ja...@planet57.com>
>> wrote:
>> I recall Hiram's mail, but don't recall if there was a patch.
>>
>> --jason
>>
>>
>> On Mar 5, 2009, at 11:13 AM, Charles Oliver Nutter wrote:
>>
>> > Is it in a bug report on sf.net? Can you point it out?
>> >
>> > Chris Custine wrote:
>> >> Hi Charlie,
>> >> If you guys are prepping for a new release, I would like to see
>> Hiram
>> >> Chirino's patch for ANSI colors on Win32 included if possible.�
>> Any
>> >> thoughts?
>> >>
>> >> Chris
>> >>
>> >> --
>> >> Chris Custine
>> >> My Blog :: http://blog.organicelement.com
>> >> Apache ServiceMix :: http://servicemix.apache.org
>> >> Apache Directory Server :: http://directory.apache.org
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> >> Francisco, CA
>> >> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> >> Enterprise
>> >> -Strategies to boost innovation and cut costs with open source
>> >> participation
>> >> -Receive a $600 discount off the registration fee with the source
>> >> code: SFAD
>> >> http://p.sf.net/sfu/XcvMzF8H
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------
>> >>
>> >> _______________________________________________
>> >> Jline-users mailing list
>> >> Jline-users@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/jline-users
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Open Source Business Conference (OSBC), March 24-25, 2009, San
>> > Francisco, CA
>> > -OSBC tackles the biggest issue in open source: Open Sourcing the
>> > Enterprise
>> > -Strategies to boost innovation and cut costs with open source
>> > participation
>> > -Receive a $600 discount off the registration fee with the source
>> > code: SFAD
>> > http://p.sf.net/sfu/XcvMzF8H
>> > _______________________________________________
>> > Jline-users mailing list
>> > Jline-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/jline-users
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source
>> code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Jline-users mailing list
>> Jline-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jline-users
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://fusesource.com/
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited
> time,
> vendors submitting new applications to BlackBerry App World(TM) will
> have
> the opportunity to enter the BlackBerry Developer Challenge. See
> full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> Jline-users mailing list
> Jline-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jline-users
>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
Re: [Jline-users] Windows ANSI colors patch
Posted by Ceki Gulcu <ce...@qos.ch>.
Niclas Hedhman wrote:
> On Wed, Jul 8, 2009 at 3:20 PM, Henri Yandell<hy...@gmail.com> wrote:
>
> *I* am not comfortable with letting the grayzone expand, while still
> maintaining highly idealistic viewpoint; "Everything here is ALv2".
> I am Ok with either stopping the grayzone expansion OR dropping the
> 'spirit' that has been with us for a long time, but not neither.
Better to bend in the wind than to break.
>
> Cheers
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Hiram Chirino <ch...@gmail.com>.
I think there is big difference and you know it.
When the end user links the LGPL with our ASL bits, our ASL bits can remain
licensed under the ASL since the LGPL is not viral when used as a library.
Contrast that to the GPL: once linked, our bits are forced to have all the
GPL restrictions, and transitively end user bits linked to our bits would
also have the be GPLed. So it a much bigger nightmare.
But I understand where your coming from. But I think if the LGPL causes
folks enough pain, then they will pony up and start contributing replacement
libraries.
Regards,
Hiram
On Thu, Jul 9, 2009 at 3:44 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Jul 8, 2009 at 9:57 PM, Hiram Chirino<ch...@gmail.com> wrote:
>
> > I think we need to treat LGPL libraries the same. It seems the worst
> case
> > these days for Apache projects is having a non optional dependency on a
> LGPL
> > library. Most folks would say that's not allowed. I just want to know
> how
> > is that different from the example I have above?
>
> It is indeed as gray as it gets, IMHO. And why stop there?
> Non-optional GPL'd System Requirement?? We only distribute our own
> sources, so that can be Apache licensed, but the one who tries to
> distribute a complete solution has the problem.
>
> Seriously, to me these issues are "boiling the frog" analogy. Every
> single little step can be motivated, technically accurate and perhaps
> desirable, but with enough many such steps something is lost (The frog
> is dead). The ASF has a reputation that its projects are not
> encumbered by complex licensing issues, and the users *knows* that
> they don't need to bother much with lawyers. Large organizations that
> I have been to, who despise the uncertainty of open source licensing,
> still have legal departments that have cleared Apache as a "safe port"
> to get Java software (I only do Java) from. For every 'special
> exception' or should I say "non-straight-forward arrangement", we
> water down such assessments and blanket approval by such legal depts.
>
> Perhaps we are all Ok loosing such privilege, and that the benefits
> exceed that. I just don't belong to the group that thinks so. I think
> we should not "bend in the wind", but be a rock-solid and trusty
> foundation of software one can rely on being encumbrance free. Does
> that suck for some projects?? Yes, it sure does. But there is always
> at least two choices; 1. Create it in-house, 2. Scrap the feature.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Re: [Jline-users] Windows ANSI colors patch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 8, 2009 at 9:57 PM, Hiram Chirino<ch...@gmail.com> wrote:
> I think we need to treat LGPL libraries the same. It seems the worst case
> these days for Apache projects is having a non optional dependency on a LGPL
> library. Most folks would say that's not allowed. I just want to know how
> is that different from the example I have above?
It is indeed as gray as it gets, IMHO. And why stop there?
Non-optional GPL'd System Requirement?? We only distribute our own
sources, so that can be Apache licensed, but the one who tries to
distribute a complete solution has the problem.
Seriously, to me these issues are "boiling the frog" analogy. Every
single little step can be motivated, technically accurate and perhaps
desirable, but with enough many such steps something is lost (The frog
is dead). The ASF has a reputation that its projects are not
encumbered by complex licensing issues, and the users *knows* that
they don't need to bother much with lawyers. Large organizations that
I have been to, who despise the uncertainty of open source licensing,
still have legal departments that have cleared Apache as a "safe port"
to get Java software (I only do Java) from. For every 'special
exception' or should I say "non-straight-forward arrangement", we
water down such assessments and blanket approval by such legal depts.
Perhaps we are all Ok loosing such privilege, and that the benefits
exceed that. I just don't belong to the group that thinks so. I think
we should not "bend in the wind", but be a rock-solid and trusty
foundation of software one can rely on being encumbrance free. Does
that suck for some projects?? Yes, it sure does. But there is always
at least two choices; 1. Create it in-house, 2. Scrap the feature.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Hiram Chirino <ch...@gmail.com>.
Hi Niclas,
I think we need to simplify this to the point where there is very little
gray or no gray at all.
Personally, I would put LGPL libraries in the same category as Propriatary
or Operating system supplied libraries. I don't see why we should treat
them differently. For example. I'm sure no one would object to creating an
Module at Apache that depends on a Windows specific API. Perhaps it's a
Windows GUI program. But wait that dependency is not OSS and not
redistributable... Does that go against our highly idealistic viewpoint? I
don't think so since what we are providing is ASL 2.0 and provides a benefit
to folks who are willing to run Windows.
I think we need to treat LGPL libraries the same. It seems the worst case
these days for Apache projects is having a non optional dependency on a LGPL
library. Most folks would say that's not allowed. I just want to know how
is that different from the example I have above?
I do agree that having the LGPL dependency be optional would be ideal, but
then again that's similar to thinking it's ideal that applications to be
portable across platforms. Since when your portable, end users have more
choice.
Regards,
Hiram
On Wed, Jul 8, 2009 at 4:02 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Jul 8, 2009 at 3:20 PM, Henri Yandell<hy...@gmail.com> wrote:
>
> > Not necessarily. It might be an AL 2.0 project with high overlap with
> > LGPL/GPL. For example we might have something that works closely with
> > Git.
>
> IMHO, the next steps are then obvious;
> 1. Let the "high overlap" project have no relevance without the (L)GPL
> part.
> 2. Let the said project simplify build environment so the (L)GPL
> parts are pulled in automatically.
> 3. Let the dependency be non-optional, since said project can't live
> without the dependent parts.
> 4. Let the said project distribute under mixed licenses...
>
> If the spirit of "all things Apache are ALv2" is eroded (albeit
> technically it might still be kosher), then you might as well allow
> much greater freedom to PMC and instead require them to signal
> deviations from ALv2 according to a common, highly visible scheme
> (perhaps via DOAP files to be aggregated into pages, part of the L&F
> generation...)
>
> *I* am not comfortable with letting the grayzone expand, while still
> maintaining highly idealistic viewpoint; "Everything here is ALv2".
> I am Ok with either stopping the grayzone expansion OR dropping the
> 'spirit' that has been with us for a long time, but not neither.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Re: [Jline-users] Windows ANSI colors patch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 8, 2009 at 3:20 PM, Henri Yandell<hy...@gmail.com> wrote:
> Not necessarily. It might be an AL 2.0 project with high overlap with
> LGPL/GPL. For example we might have something that works closely with
> Git.
IMHO, the next steps are then obvious;
1. Let the "high overlap" project have no relevance without the (L)GPL part.
2. Let the said project simplify build environment so the (L)GPL
parts are pulled in automatically.
3. Let the dependency be non-optional, since said project can't live
without the dependent parts.
4. Let the said project distribute under mixed licenses...
If the spirit of "all things Apache are ALv2" is eroded (albeit
technically it might still be kosher), then you might as well allow
much greater freedom to PMC and instead require them to signal
deviations from ALv2 according to a common, highly visible scheme
(perhaps via DOAP files to be aggregated into pages, part of the L&F
generation...)
*I* am not comfortable with letting the grayzone expand, while still
maintaining highly idealistic viewpoint; "Everything here is ALv2".
I am Ok with either stopping the grayzone expansion OR dropping the
'spirit' that has been with us for a long time, but not neither.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Henri Yandell <hy...@gmail.com>.
On Tue, Jul 7, 2009 at 11:29 PM, Niclas Hedhman<ni...@hedhman.org> wrote:
> On Wed, Jul 8, 2009 at 1:56 PM, Ralph Goers<ra...@dslextreme.com> wrote:
>
>> https://issues.apache.org/jira/browse/LEGAL-30, which is unresolved, asks
>> the question about bridge code to prohibited works. Frankly, it isn't clear
>> to me why that issue is still open and I think the answer you gave above is
>> wrong.
>
> Perhaps the "depends on your technical circumstances" disclaimer
> should have been more encompassing, but it still is largely depending
> on the actual case.
>
>> https://issues.apache.org/jira/browse/LEGAL-18 discusses a plugin for
>> JBoss, which is licensed under the LGPL. We said that that was fine since it
>> is an optional component and the end user has obviously chosen JBoss (which,
>> of course, is licensed under the LPGL). Note that the referenced email
>> thread explicitly says the bridge code will reside within ServiceMix.
>> I see very little difference between this and an optional component that
>> makes use of an LGPL'd library. Just as in the ServiceMix case the LGPL'd
>> library will be required at compile time. The LPGL'd library cannot be
>> distributed with the project and must not be required for the project to run
>> in its default configuration.
>
> For the case at hand, it is unclear (at least to me) how the LGPL
> dependency comes into play. And I maintain that the ServiceMix case is
> Ok, due to "SMX plugin being a subpart of JBoss" whereas cases of
> JFreeChart "being a subpart of Apache Xyz" isn't Ok, even if that is
> 'optional'. The latter case quickly becomes a slippery slope...
+1. The ServiceMix case is not relevant to this - that plugin is
happily able to be under AL 2.0 and fits into a differently licensed
environment.
>> LEGAL-30 should be resolved to say this and the resolved questions page
>> should clarify the use of the LGPL by changing the statement "Therefore,
>> LGPL-licensed works must not be included in Apache products." to an answer
>> such as "Therefore, Apache project must not distribute LGPL licensed works
>> or require an LGPL licensed work to perform functions essential to normal
>> operation. However, projects may use LGPL licensed works in optional
>> features that are not enabled by default".
>
> I think the real problem is the documentation requirement for said
> "enablement" of an optional feature. Another thing, I think, is that
> it is important that this doesn't become the 'norm' instead of the
> 'exception'. For instance, if a modular project (like ServiceMix) had
> most of its optional 'modules', then something about the Apache
> project is falling apart, isn't it?
Not necessarily. It might be an AL 2.0 project with high overlap with
LGPL/GPL. For example we might have something that works closely with
Git.
I like Ralph's text. I think we should maintain a record of where this
has happened - a webpage that lists each project that is using
optional LGPL.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 8, 2009 at 3:54 PM, Ralph Goers<ra...@dslextreme.com> wrote:
> I don't completely agree. In a project like Cocoon, which has many
> components that are mixed and matched, using JFreeChart might be OK since
> the vast majority of users could get by without it.
And I think it is called "Fins" and is not present in the Cocoon
project. Very prudent in my opinion.
That approach has been the 'norm' in the past.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jul 7, 2009, at 11:29 PM, Niclas Hedhman wrote:
> On Wed, Jul 8, 2009 at 1:56 PM, Ralph
> Goers<ra...@dslextreme.com> wrote:
>
>> https://issues.apache.org/jira/browse/LEGAL-30, which is
>> unresolved, asks
>> the question about bridge code to prohibited works. Frankly, it
>> isn't clear
>> to me why that issue is still open and I think the answer you gave
>> above is
>> wrong.
>
> Perhaps the "depends on your technical circumstances" disclaimer
> should have been more encompassing, but it still is largely depending
> on the actual case.
>
>> https://issues.apache.org/jira/browse/LEGAL-18 discusses a plugin
>> for
>> JBoss, which is licensed under the LGPL. We said that that was fine
>> since it
>> is an optional component and the end user has obviously chosen
>> JBoss (which,
>> of course, is licensed under the LPGL). Note that the referenced
>> email
>> thread explicitly says the bridge code will reside within ServiceMix.
>> I see very little difference between this and an optional component
>> that
>> makes use of an LGPL'd library. Just as in the ServiceMix case the
>> LGPL'd
>> library will be required at compile time. The LPGL'd library cannot
>> be
>> distributed with the project and must not be required for the
>> project to run
>> in its default configuration.
>
> For the case at hand, it is unclear (at least to me) how the LGPL
> dependency comes into play. And I maintain that the ServiceMix case is
> Ok, due to "SMX plugin being a subpart of JBoss" whereas cases of
> JFreeChart "being a subpart of Apache Xyz" isn't Ok, even if that is
> 'optional'. The latter case quickly becomes a slippery slope...
I don't completely agree. In a project like Cocoon, which has many
components that are mixed and matched, using JFreeChart might be OK
since the vast majority of users could get by without it. However, in
a spreadsheet project having JFreeChart as the only option, even if
isn't enabled by default, most would argue that it is an essential
part of the project and thus would be a problem. So yes, circumstances
do come into play, but the policy could be worded to account for that.
>
>
>> LEGAL-30 should be resolved to say this and the resolved questions
>> page
>> should clarify the use of the LGPL by changing the statement
>> "Therefore,
>> LGPL-licensed works must not be included in Apache products." to an
>> answer
>> such as "Therefore, Apache project must not distribute LGPL
>> licensed works
>> or require an LGPL licensed work to perform functions essential to
>> normal
>> operation. However, projects may use LGPL licensed works in optional
>> features that are not enabled by default".
>
> I think the real problem is the documentation requirement for said
> "enablement" of an optional feature. Another thing, I think, is that
> it is important that this doesn't become the 'norm' instead of the
> 'exception'. For instance, if a modular project (like ServiceMix) had
> most of its optional 'modules', then something about the Apache
> project is falling apart, isn't it?
Yes, the wording of the documentation is key, but not changing the
documentation on the resolved page because we can't come up with the
exact wording leads to the wrong results.
If "most" of the optional components of a project require incompatible
licenses and the project as a whole I would again question what the
project is about. But if a project like Maven had its core plugins
completely under the Apache license but had many optional plugins that
used other licenses, even if the number of them exceeded the number of
Apache licensed plugins, I doubt there would be a problem. Yes,
wording that might be awkward, but I don't think it is undoable.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 8, 2009 at 1:56 PM, Ralph Goers<ra...@dslextreme.com> wrote:
> https://issues.apache.org/jira/browse/LEGAL-30, which is unresolved, asks
> the question about bridge code to prohibited works. Frankly, it isn't clear
> to me why that issue is still open and I think the answer you gave above is
> wrong.
Perhaps the "depends on your technical circumstances" disclaimer
should have been more encompassing, but it still is largely depending
on the actual case.
> https://issues.apache.org/jira/browse/LEGAL-18 discusses a plugin for
> JBoss, which is licensed under the LGPL. We said that that was fine since it
> is an optional component and the end user has obviously chosen JBoss (which,
> of course, is licensed under the LPGL). Note that the referenced email
> thread explicitly says the bridge code will reside within ServiceMix.
> I see very little difference between this and an optional component that
> makes use of an LGPL'd library. Just as in the ServiceMix case the LGPL'd
> library will be required at compile time. The LPGL'd library cannot be
> distributed with the project and must not be required for the project to run
> in its default configuration.
For the case at hand, it is unclear (at least to me) how the LGPL
dependency comes into play. And I maintain that the ServiceMix case is
Ok, due to "SMX plugin being a subpart of JBoss" whereas cases of
JFreeChart "being a subpart of Apache Xyz" isn't Ok, even if that is
'optional'. The latter case quickly becomes a slippery slope...
> LEGAL-30 should be resolved to say this and the resolved questions page
> should clarify the use of the LGPL by changing the statement "Therefore,
> LGPL-licensed works must not be included in Apache products." to an answer
> such as "Therefore, Apache project must not distribute LGPL licensed works
> or require an LGPL licensed work to perform functions essential to normal
> operation. However, projects may use LGPL licensed works in optional
> features that are not enabled by default".
I think the real problem is the documentation requirement for said
"enablement" of an optional feature. Another thing, I think, is that
it is important that this doesn't become the 'norm' instead of the
'exception'. For instance, if a modular project (like ServiceMix) had
most of its optional 'modules', then something about the Apache
project is falling apart, isn't it?
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [Jline-users] Windows ANSI colors patch
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jul 7, 2009, at 9:19 PM, Niclas Hedhman wrote:
> On Tue, Jul 7, 2009 at 8:57 PM, Jason Dillon<ja...@planet57.com>
> wrote:
>> Can anyone chime in here as to wether a java library (jansi) which
>> uses a
>> LGPL (optional library) JNA is compatible with the ASL 2?
>
> LGPL is not compatible with Apache License v2, a so called Category
> X license.
>
> Since you are mentioning "optional library", it is possible to create
> the software so that the incompatibility bits are not triggered. If
> you can make the Apache project completely independent of the LGPL
> bit, meaning you don't know that it exists and provide instructions
> for the users on how to 'install it', that is Ok. Exactly how this can
> be done depends on your technical circumstances, for instance, if you
> have an SPI that others can implement to provide additional
> functionality, and "someone" writes a "bridge" (hosted on SF) that
> makes the incompatible part an implementation of such SPI, you are in
> the clear. (To be safe, there should be other implementations of the
> mentioned SPI available)
> Certain frameworks allows you to 'configure' Java calls (via
> reflection) of totally unknown components. In certain cases, that may
> also be acceptable.
>
This topic has come up over and over again and I still don't believe
it is documented correctly on http://www.apache.org/legal/
resolved.html. On that page it basically says you cannot use LGPL'd
code at all, which is incorrect.
https://issues.apache.org/jira/browse/LEGAL-30, which is unresolved,
asks the question about bridge code to prohibited works. Frankly, it
isn't clear to me why that issue is still open and I think the answer
you gave above is wrong. https://issues.apache.org/jira/browse/
LEGAL-18 discusses a plugin for JBoss, which is licensed under the
LGPL. We said that that was fine since it is an optional component and
the end user has obviously chosen JBoss (which, of course, is licensed
under the LPGL). Note that the referenced email thread explicitly says
the bridge code will reside within ServiceMix.
I see very little difference between this and an optional component
that makes use of an LGPL'd library. Just as in the ServiceMix case
the LGPL'd library will be required at compile time. The LPGL'd
library cannot be distributed with the project and must not be
required for the project to run in its default configuration.
LEGAL-30 should be resolved to say this and the resolved questions
page should clarify the use of the LGPL by changing the statement
"Therefore, LGPL-licensed works must not be included in Apache
products." to an answer such as "Therefore, Apache project must not
distribute LGPL licensed works or require an LGPL licensed work to
perform functions essential to normal operation. However, projects may
use LGPL licensed works in optional features that are not enabled by
default". We should provide examples of how to accomplish that using
Maven, Ivy, etc.
Ralph
Re: [Jline-users] Windows ANSI colors patch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Jul 7, 2009 at 8:57 PM, Jason Dillon<ja...@planet57.com> wrote:
> Can anyone chime in here as to wether a java library (jansi) which uses a
> LGPL (optional library) JNA is compatible with the ASL 2?
LGPL is not compatible with Apache License v2, a so called Category X license.
Since you are mentioning "optional library", it is possible to create
the software so that the incompatibility bits are not triggered. If
you can make the Apache project completely independent of the LGPL
bit, meaning you don't know that it exists and provide instructions
for the users on how to 'install it', that is Ok. Exactly how this can
be done depends on your technical circumstances, for instance, if you
have an SPI that others can implement to provide additional
functionality, and "someone" writes a "bridge" (hosted on SF) that
makes the incompatible part an implementation of such SPI, you are in
the clear. (To be safe, there should be other implementations of the
mentioned SPI available)
Certain frameworks allows you to 'configure' Java calls (via
reflection) of totally unknown components. In certain cases, that may
also be acceptable.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org