You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2006/09/01 04:51:09 UTC
Re: Should I move JMood to the trunk?
On Thursday 31 August 2006 23:07, Richard S. Hall wrote:
> Stephane,
>
> Are you hosting these in the repo or are you simply depending on them? I
> assume you are just depending on them, but not checking them into the
> repo. If so, then that is ok, right Upayavira?
No, that is not correct.
Since FSF is still considering Java to trigger the viral behavior of LGPL when
you have a dependency through an import statement, ASF plays safe and do not
allow projects to have a direct binary dependency.
IIUIC, the exception is; If the dependency can be made totally optional, so
that when the LGPLd code is not used by the user, there are no links into the
LGPL'd code, and that the user must explicitly enable the extension that
brings in the LGPL'd part (I also think there are some notice requirements
around that, to make sure the user understand what he/she is doing).
Typically this is done by creating a facade interface which can have many
implementations and one of those (not the default one) uses the LGPL'd part.
I hope this helps. If any doubts, check with legal-discuss@a.o
Cheers
Niclas
Re: Should I move JMood to the trunk?
Posted by "Nektarios K. Papadopoulos" <np...@inaccessnetworks.com>.
Niclas Hedhman wrote:
> On Friday 01 September 2006 15:47, Nektarios K. Papadopoulos wrote:
>>> Since FSF is still considering Java to trigger the viral behavior of LGPL
>>> when you have a dependency through an import statement, ASF plays safe
>>> and do not allow projects to have a direct binary dependency.
>> IANAL, but according to http://www.gnu.org/licenses/lgpl-java.html it is
>> safe to have a dependency through an import statement. The problem would
>> be to link to GPL, *not* LGPL.
>> Nevertheless, indeed ASF do not allow this, with the exceptions
>> described in the link provided by Upayavira
>
> Mr Turner's statement is of course both accurate and misleading.
I guess I fall in the misleading part ;-)
>
> Though the derived work may not be required to be LGPL'd, the LGPL requires
> concession's in the downstream licenses that are not acceptable by the ASF,
> i.e. someone making a commercial version of Felix and its constituents must
> not be required to allow reverse-engineering of the codebase, which LGPL
> require us to enforce on our downstream users. Hence the virality...
I took the time to look closer into the #6 clause of LGPL and -despite
Mr.Turner's statement- reverse-engineering of the codebase is required.
Thanks for pointing out.
> Therefor LGPL is listed as Excluded Licenses.
I understand.
>
> <quote source="Cliff Schmidt" >
> Inclusion within the product
> YOU MUST NOT include any portion of a prohibited work within the Apache
> product, whether or not that work is considered required or optional.
>
> YOU MAY include code within the Apache product necessary to achieve
> compatibility with a prohibited work through the use of API calls, "bridge
> code", or protocols, provided that the compatibility code was contributed
> under a CLA. However, any such code used for compatibility with a
> third-party work that is licensed under terms that violate criterion #2
> ("must not place restrictions on the distribution of independent works that
> simply use or contain the covered work."), such as the GPL, requires review
> and explicit approval of both the PMC chair and the Legal Affairs officer.
> This review will ensure that the Apache product takes only the necessary
> steps to achieve compatibility.
>
> YOU MAY ALSO include a feature within an Apache product that allows the
> user to explicitly choose to download an optional third-party add-on, as
> long as that feature also alerts the user of the associated license.
> </quote>
>
> I interpret this as;
> If JMood (I haven't checked) uses LGPL code that part shall not be part of the
> Felix project, irregardless if it is optional or not. And to be safe, the
> Facade API reside in Felix (without the linking prohibited code) and the
> implementation of that Facade resides elsewhere, e.g. SF.
Well, this part is covered by the replies from Upayavira[1] (this was my
understanding of the whole issue) and Manuel Santillán [2].
[1]http://www.mail-archive.com/felix-dev@incubator.apache.org/msg02241.html
[2]http://www.mail-archive.com/felix-dev@incubator.apache.org/msg02242.html
>
> Any other use, I guess Cliff wants a say about it...
>
>
> Cheers
> Niclas
>
Cheers
Nek
--
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue. Tel : +30-210-6837640
152 34 Halandri Athens Fax : +30-210-6899504
______________________________________________________________
Re: Should I move JMood to the trunk?
Posted by Upayavira <uv...@odoko.co.uk>.
Niclas Hedhman wrote:
> On Friday 01 September 2006 15:47, Nektarios K. Papadopoulos wrote:
>>> Since FSF is still considering Java to trigger the viral behavior of LGPL
>>> when you have a dependency through an import statement, ASF plays safe
>>> and do not allow projects to have a direct binary dependency.
>> IANAL, but according to http://www.gnu.org/licenses/lgpl-java.html it is
>> safe to have a dependency through an import statement. The problem would
>> be to link to GPL, *not* LGPL.
>> Nevertheless, indeed ASF do not allow this, with the exceptions
>> described in the link provided by Upayavira
>
> Mr Turner's statement is of course both accurate and misleading.
>
> Though the derived work may not be required to be LGPL'd, the LGPL requires
> concession's in the downstream licenses that are not acceptable by the ASF,
> i.e. someone making a commercial version of Felix and its constituents must
> not be required to allow reverse-engineering of the codebase, which LGPL
> require us to enforce on our downstream users. Hence the virality...
> Therefor LGPL is listed as Excluded Licenses.
>
> <quote source="Cliff Schmidt" >
> Inclusion within the product
> YOU MUST NOT include any portion of a prohibited work within the Apache
> product, whether or not that work is considered required or optional.
>
> YOU MAY include code within the Apache product necessary to achieve
> compatibility with a prohibited work through the use of API calls, "bridge
> code", or protocols, provided that the compatibility code was contributed
> under a CLA. However, any such code used for compatibility with a
> third-party work that is licensed under terms that violate criterion #2
> ("must not place restrictions on the distribution of independent works that
> simply use or contain the covered work."), such as the GPL, requires review
> and explicit approval of both the PMC chair and the Legal Affairs officer.
> This review will ensure that the Apache product takes only the necessary
> steps to achieve compatibility.
>
> YOU MAY ALSO include a feature within an Apache product that allows the
> user to explicitly choose to download an optional third-party add-on, as
> long as that feature also alerts the user of the associated license.
> </quote>
>
> I interpret this as;
> If JMood (I haven't checked) uses LGPL code that part shall not be part of the
> Felix project, irregardless if it is optional or not. And to be safe, the
> Facade API reside in Felix (without the linking prohibited code) and the
> implementation of that Facade resides elsewhere, e.g. SF.
>
> Any other use, I guess Cliff wants a say about it...
I don't see it /quite/ so strongly as that. If this charting component
is optional (either the charting, or the entire Felix component), and
the user has to consciously acknowledge its license before proceeding,
that would be accepable, IMO.
More acceptable would be using a charting component that doesn't add
restrictions above and beyond those of the Apache License, if finding
such a library was possible.
As Niclas is trying to make clear above, it is worth noting that these
restrictions are not about Apache just being difficult (although it
sometimes seems like that) - it is about respecting and protecting our
users and their freedom to use the code that we produce. I wonder if it
is this thoroughness around licensing that has been largely responsible
for the strength of the Apache brand.
Regards, Upayavira
Re: Should I move JMood to the trunk?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 01 September 2006 15:47, Nektarios K. Papadopoulos wrote:
> > Since FSF is still considering Java to trigger the viral behavior of LGPL
> > when you have a dependency through an import statement, ASF plays safe
> > and do not allow projects to have a direct binary dependency.
>
> IANAL, but according to http://www.gnu.org/licenses/lgpl-java.html it is
> safe to have a dependency through an import statement. The problem would
> be to link to GPL, *not* LGPL.
> Nevertheless, indeed ASF do not allow this, with the exceptions
> described in the link provided by Upayavira
Mr Turner's statement is of course both accurate and misleading.
Though the derived work may not be required to be LGPL'd, the LGPL requires
concession's in the downstream licenses that are not acceptable by the ASF,
i.e. someone making a commercial version of Felix and its constituents must
not be required to allow reverse-engineering of the codebase, which LGPL
require us to enforce on our downstream users. Hence the virality...
Therefor LGPL is listed as Excluded Licenses.
<quote source="Cliff Schmidt" >
Inclusion within the product
YOU MUST NOT include any portion of a prohibited work within the Apache
product, whether or not that work is considered required or optional.
YOU MAY include code within the Apache product necessary to achieve
compatibility with a prohibited work through the use of API calls, "bridge
code", or protocols, provided that the compatibility code was contributed
under a CLA. However, any such code used for compatibility with a
third-party work that is licensed under terms that violate criterion #2
("must not place restrictions on the distribution of independent works that
simply use or contain the covered work."), such as the GPL, requires review
and explicit approval of both the PMC chair and the Legal Affairs officer.
This review will ensure that the Apache product takes only the necessary
steps to achieve compatibility.
YOU MAY ALSO include a feature within an Apache product that allows the
user to explicitly choose to download an optional third-party add-on, as
long as that feature also alerts the user of the associated license.
</quote>
I interpret this as;
If JMood (I haven't checked) uses LGPL code that part shall not be part of the
Felix project, irregardless if it is optional or not. And to be safe, the
Facade API reside in Felix (without the linking prohibited code) and the
implementation of that Facade resides elsewhere, e.g. SF.
Any other use, I guess Cliff wants a say about it...
Cheers
Niclas
Re: Should I move JMood to the trunk?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 9/2/06, Alex Karasulu <ao...@bellsouth.net> wrote:
>
> Yep I agree. Let's just start the vote ASAP. I don't want to miss
> graduation in September and am willing to check emails on Labor day.
>
Labor Day - Isn't that the day of the year you actually work... ;o)
But, yes, Justin and others have expressed that the 72 hour vote period is
plenty, even if it is over holidays and weekends. In some 'senior guys' PoV,
votes are not there as "everyone must check and vote", but among the many
Incubator PMC members "enough eyeballs" have the opportunity to make sure
that everything is Ok.
I am really looking forward to this :o)
Cheers
Niclas
Re: Should I move JMood to the trunk?
Posted by Alex Karasulu <ao...@bellsouth.net>.
Enrique Rodriguez wrote:
> Upayavira wrote:
>> stephane.frenot@insa-lyon.fr wrote:
>>> It's done.
>>
>> Wow. That was quick. Thanks for this!
>>
>> I now propose to start the graduation vote on Monday, subject to any
>> other complaints in the meantime :-)
>
> Monday is a U.S. holiday, and thus a short week for many of us. Though,
> I still think you should start the vote, since it should be a formality
> at this point. Just don't worry if you don't hear from a few people at
> first!
>
Yep I agree. Let's just start the vote ASAP. I don't want to miss
graduation in September and am willing to check emails on Labor day.
Alex
Re: Should I move JMood to the trunk?
Posted by Enrique Rodriguez <en...@gmail.com>.
Upayavira wrote:
> stephane.frenot@insa-lyon.fr wrote:
>> It's done.
>
> Wow. That was quick. Thanks for this!
>
> I now propose to start the graduation vote on Monday, subject to any
> other complaints in the meantime :-)
Monday is a U.S. holiday, and thus a short week for many of us. Though,
I still think you should start the vote, since it should be a formality
at this point. Just don't worry if you don't hear from a few people at
first!
Enrique
Re: Should I move JMood to the trunk?
Posted by Upayavira <uv...@odoko.co.uk>.
stephane.frenot@insa-lyon.fr wrote:
> It's done.
Wow. That was quick. Thanks for this!
I now propose to start the graduation vote on Monday, subject to any
other complaints in the meantime :-)
Regards, Upayavira
> Regards
> /stephane
> On Fri, Sep 01, 2006 at 02:46:03PM +0100, Upayavira wrote:
>> stephane.frenot@insa-lyon.fr wrote:
>>> Actually I have a smarter solution,
>>> those libraries are dynamically downloaded in the Console (thanks to
>>> OSGi :).
>>> So I can remove the tab without problem and make it available from my
>>> site as it was before.
>>>
>>> The only issue is that the tab is not hosted at apache svn.
>> Sounds good. Thanks for this. Note, this will need to be done before the
>> incubator PMC vote which'll happen in maybe 1 week's time. :-(
>>
>> Regards, Upayavira
>>
>>
>>
>>> /stephane
>>> On Fri, Sep 01, 2006 at 09:28:46AM -0400, Richard S. Hall wrote:
>>>> stephane.frenot@insa-lyon.fr wrote:
>>>>> On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
>>>>>
>>>>>> Niclas Hedhman wrote:
>>>>>>
>>>>>>> On Friday 01 September 2006 16:58, santillan wrote:
>>>>>>>
>>>>>>>> Just a note: while JMood's initial version was LGPL'd, a software grant
>>>>>>>> was
>>>>>>>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>>>>>>>> Moreover, I've removed the dependency to MX4J just in case (as it was
>>>>>>>> easy
>>>>>>>> to refactor), so currently only depends on osgi.core, osgi.compendium,
>>>>>>>> the
>>>>>>>> framework and Junit, so no licensing problems here :-)
>>>>>>>>
>>>>>>> Cool. So we are discussing a hypothetical case ;o)
>>>>>>>
>>>>>> Well, the issue that remains is how we use jfree and jcommon, both of
>>>>>> which are, as I understand it, Jmood dependencies, and both are LGPL.
>>>>>>
>>>>> Not Jmood, but MOSGi dependencies.
>>>> Yes, people seemed to have gotten lost. :-)
>>>>
>>>> Well, the way I see it, if we cannot find compatible graphing libraries,
>>>> then we can either remove the component and Stephane can host it
>>>> separately (perhaps at Source Forge) or we can create some sort of
>>>> bridging and make it optional somehow. Stephane probably knows what
>>>> makes the most sense.
>>>>
>>>> -> richard
>
Re: Should I move JMood to the trunk?
Posted by st...@insa-lyon.fr.
It's done.
Regards
/stephane
On Fri, Sep 01, 2006 at 02:46:03PM +0100, Upayavira wrote:
> stephane.frenot@insa-lyon.fr wrote:
> > Actually I have a smarter solution,
> > those libraries are dynamically downloaded in the Console (thanks to
> > OSGi :).
> > So I can remove the tab without problem and make it available from my
> > site as it was before.
> >
> > The only issue is that the tab is not hosted at apache svn.
>
> Sounds good. Thanks for this. Note, this will need to be done before the
> incubator PMC vote which'll happen in maybe 1 week's time. :-(
>
> Regards, Upayavira
>
>
>
> > /stephane
> > On Fri, Sep 01, 2006 at 09:28:46AM -0400, Richard S. Hall wrote:
> >> stephane.frenot@insa-lyon.fr wrote:
> >>> On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
> >>>
> >>>> Niclas Hedhman wrote:
> >>>>
> >>>>> On Friday 01 September 2006 16:58, santillan wrote:
> >>>>>
> >>>>>> Just a note: while JMood's initial version was LGPL'd, a software grant
> >>>>>> was
> >>>>>> given to the ASF and the JMood code in the trunk is properly ASL'd.
> >>>>>> Moreover, I've removed the dependency to MX4J just in case (as it was
> >>>>>> easy
> >>>>>> to refactor), so currently only depends on osgi.core, osgi.compendium,
> >>>>>> the
> >>>>>> framework and Junit, so no licensing problems here :-)
> >>>>>>
> >>>>> Cool. So we are discussing a hypothetical case ;o)
> >>>>>
> >>>> Well, the issue that remains is how we use jfree and jcommon, both of
> >>>> which are, as I understand it, Jmood dependencies, and both are LGPL.
> >>>>
> >>> Not Jmood, but MOSGi dependencies.
> >> Yes, people seemed to have gotten lost. :-)
> >>
> >> Well, the way I see it, if we cannot find compatible graphing libraries,
> >> then we can either remove the component and Stephane can host it
> >> separately (perhaps at Source Forge) or we can create some sort of
> >> bridging and make it optional somehow. Stephane probably knows what
> >> makes the most sense.
> >>
> >> -> richard
> >
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: Should I move JMood to the trunk?
Posted by Upayavira <uv...@odoko.co.uk>.
stephane.frenot@insa-lyon.fr wrote:
> Actually I have a smarter solution,
> those libraries are dynamically downloaded in the Console (thanks to
> OSGi :).
> So I can remove the tab without problem and make it available from my
> site as it was before.
>
> The only issue is that the tab is not hosted at apache svn.
Sounds good. Thanks for this. Note, this will need to be done before the
incubator PMC vote which'll happen in maybe 1 week's time. :-(
Regards, Upayavira
> /stephane
> On Fri, Sep 01, 2006 at 09:28:46AM -0400, Richard S. Hall wrote:
>> stephane.frenot@insa-lyon.fr wrote:
>>> On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
>>>
>>>> Niclas Hedhman wrote:
>>>>
>>>>> On Friday 01 September 2006 16:58, santillan wrote:
>>>>>
>>>>>> Just a note: while JMood's initial version was LGPL'd, a software grant
>>>>>> was
>>>>>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>>>>>> Moreover, I've removed the dependency to MX4J just in case (as it was
>>>>>> easy
>>>>>> to refactor), so currently only depends on osgi.core, osgi.compendium,
>>>>>> the
>>>>>> framework and Junit, so no licensing problems here :-)
>>>>>>
>>>>> Cool. So we are discussing a hypothetical case ;o)
>>>>>
>>>> Well, the issue that remains is how we use jfree and jcommon, both of
>>>> which are, as I understand it, Jmood dependencies, and both are LGPL.
>>>>
>>> Not Jmood, but MOSGi dependencies.
>> Yes, people seemed to have gotten lost. :-)
>>
>> Well, the way I see it, if we cannot find compatible graphing libraries,
>> then we can either remove the component and Stephane can host it
>> separately (perhaps at Source Forge) or we can create some sort of
>> bridging and make it optional somehow. Stephane probably knows what
>> makes the most sense.
>>
>> -> richard
>
Re: Should I move JMood to the trunk?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
stephane.frenot@insa-lyon.fr wrote:
> Actually I have a smarter solution,
> those libraries are dynamically downloaded in the Console (thanks to
> OSGi :).
> So I can remove the tab without problem and make it available from my
> site as it was before.
>
> The only issue is that the tab is not hosted at apache svn.
>
Yes, that is a bummer, but I guess we don't have much choice. If, in the
future, we find a compatible substitute for the libraries, then we can
move it back to the repo.
-> richard
> /stephane
> On Fri, Sep 01, 2006 at 09:28:46AM -0400, Richard S. Hall wrote:
>
>> stephane.frenot@insa-lyon.fr wrote:
>>
>>> On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
>>>
>>>
>>>> Niclas Hedhman wrote:
>>>>
>>>>
>>>>> On Friday 01 September 2006 16:58, santillan wrote:
>>>>>
>>>>>
>>>>>> Just a note: while JMood's initial version was LGPL'd, a software grant
>>>>>> was
>>>>>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>>>>>> Moreover, I've removed the dependency to MX4J just in case (as it was
>>>>>> easy
>>>>>> to refactor), so currently only depends on osgi.core, osgi.compendium,
>>>>>> the
>>>>>> framework and Junit, so no licensing problems here :-)
>>>>>>
>>>>>>
>>>>> Cool. So we are discussing a hypothetical case ;o)
>>>>>
>>>>>
>>>> Well, the issue that remains is how we use jfree and jcommon, both of
>>>> which are, as I understand it, Jmood dependencies, and both are LGPL.
>>>>
>>>>
>>> Not Jmood, but MOSGi dependencies.
>>>
>> Yes, people seemed to have gotten lost. :-)
>>
>> Well, the way I see it, if we cannot find compatible graphing libraries,
>> then we can either remove the component and Stephane can host it
>> separately (perhaps at Source Forge) or we can create some sort of
>> bridging and make it optional somehow. Stephane probably knows what
>> makes the most sense.
>>
>> -> richard
>>
>
>
Re: Should I move JMood to the trunk?
Posted by st...@insa-lyon.fr.
Actually I have a smarter solution,
those libraries are dynamically downloaded in the Console (thanks to
OSGi :).
So I can remove the tab without problem and make it available from my
site as it was before.
The only issue is that the tab is not hosted at apache svn.
/stephane
On Fri, Sep 01, 2006 at 09:28:46AM -0400, Richard S. Hall wrote:
> stephane.frenot@insa-lyon.fr wrote:
> >On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
> >
> >>Niclas Hedhman wrote:
> >>
> >>>On Friday 01 September 2006 16:58, santillan wrote:
> >>>
> >>>>Just a note: while JMood's initial version was LGPL'd, a software grant
> >>>>was
> >>>>given to the ASF and the JMood code in the trunk is properly ASL'd.
> >>>>Moreover, I've removed the dependency to MX4J just in case (as it was
> >>>>easy
> >>>>to refactor), so currently only depends on osgi.core, osgi.compendium,
> >>>>the
> >>>>framework and Junit, so no licensing problems here :-)
> >>>>
> >>>Cool. So we are discussing a hypothetical case ;o)
> >>>
> >>Well, the issue that remains is how we use jfree and jcommon, both of
> >>which are, as I understand it, Jmood dependencies, and both are LGPL.
> >>
> >Not Jmood, but MOSGi dependencies.
>
> Yes, people seemed to have gotten lost. :-)
>
> Well, the way I see it, if we cannot find compatible graphing libraries,
> then we can either remove the component and Stephane can host it
> separately (perhaps at Source Forge) or we can create some sort of
> bridging and make it optional somehow. Stephane probably knows what
> makes the most sense.
>
> -> richard
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: Should I move JMood to the trunk?
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> stephane.frenot@insa-lyon.fr wrote:
>> On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
>>
>>> Niclas Hedhman wrote:
>>>
>>>> On Friday 01 September 2006 16:58, santillan wrote:
>>>>
>>>>> Just a note: while JMood's initial version was LGPL'd, a software
>>>>> grant was
>>>>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>>>>> Moreover, I've removed the dependency to MX4J just in case (as it
>>>>> was easy
>>>>> to refactor), so currently only depends on osgi.core,
>>>>> osgi.compendium, the
>>>>> framework and Junit, so no licensing problems here :-)
>>>>>
>>>> Cool. So we are discussing a hypothetical case ;o)
>>>>
>>> Well, the issue that remains is how we use jfree and jcommon, both of
>>> which are, as I understand it, Jmood dependencies, and both are LGPL.
>>>
>> Not Jmood, but MOSGi dependencies.
>
> Yes, people seemed to have gotten lost. :-)
Well, I have, certainly. Remember, when it comes to Felix, I'm
definitely not technical - and can't follow everything you guys are up
to :-)
> Well, the way I see it, if we cannot find compatible graphing libraries,
> then we can either remove the component and Stephane can host it
> separately (perhaps at Source Forge) or we can create some sort of
> bridging and make it optional somehow. Stephane probably knows what
> makes the most sense.
Yes, that sounds right. (The bridging basically could simply be a readme
that says "This component can also handle graphing, but requires LGPL
libraries which are Apache License incompatible to do so. If you are
happy to use these libraries, you can download them from ..."
We could check that on legal-discuss, but I suspect that would be
acceptable wording.
This should, IMO, be fine, as MOSGi itself is an optional component of
Felix, and the charting part is an optional part of that. I think we've
got the 'optional' bit covered :-)
Regards, Upayavira
Re: Should I move JMood to the trunk?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
stephane.frenot@insa-lyon.fr wrote:
> On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
>
>> Niclas Hedhman wrote:
>>
>>> On Friday 01 September 2006 16:58, santillan wrote:
>>>
>>>> Just a note: while JMood's initial version was LGPL'd, a software grant was
>>>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>>>> Moreover, I've removed the dependency to MX4J just in case (as it was easy
>>>> to refactor), so currently only depends on osgi.core, osgi.compendium, the
>>>> framework and Junit, so no licensing problems here :-)
>>>>
>>> Cool. So we are discussing a hypothetical case ;o)
>>>
>> Well, the issue that remains is how we use jfree and jcommon, both of
>> which are, as I understand it, Jmood dependencies, and both are LGPL.
>>
> Not Jmood, but MOSGi dependencies.
Yes, people seemed to have gotten lost. :-)
Well, the way I see it, if we cannot find compatible graphing libraries,
then we can either remove the component and Stephane can host it
separately (perhaps at Source Forge) or we can create some sort of
bridging and make it optional somehow. Stephane probably knows what
makes the most sense.
-> richard
Re: Should I move JMood to the trunk?
Posted by st...@insa-lyon.fr.
On Fri, Sep 01, 2006 at 02:20:36PM +0100, Upayavira wrote:
> Niclas Hedhman wrote:
> > On Friday 01 September 2006 16:58, santillan wrote:
> >> Just a note: while JMood's initial version was LGPL'd, a software grant was
> >> given to the ASF and the JMood code in the trunk is properly ASL'd.
> >> Moreover, I've removed the dependency to MX4J just in case (as it was easy
> >> to refactor), so currently only depends on osgi.core, osgi.compendium, the
> >> framework and Junit, so no licensing problems here :-)
> >
> > Cool. So we are discussing a hypothetical case ;o)
>
> Well, the issue that remains is how we use jfree and jcommon, both of
> which are, as I understand it, Jmood dependencies, and both are LGPL.
Not Jmood, but MOSGi dependencies.
/stephane
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: Should I move JMood to the trunk?
Posted by Upayavira <uv...@odoko.co.uk>.
Niclas Hedhman wrote:
> On Friday 01 September 2006 16:58, santillan wrote:
>> Just a note: while JMood's initial version was LGPL'd, a software grant was
>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>> Moreover, I've removed the dependency to MX4J just in case (as it was easy
>> to refactor), so currently only depends on osgi.core, osgi.compendium, the
>> framework and Junit, so no licensing problems here :-)
>
> Cool. So we are discussing a hypothetical case ;o)
Well, the issue that remains is how we use jfree and jcommon, both of
which are, as I understand it, Jmood dependencies, and both are LGPL.
Upayavira
Re: Should I move JMood to the trunk?
Posted by Upayavira <uv...@odoko.co.uk>.
santillan wrote:
> We already did fax separate software grants (one for each of the three
> copyright owners/contributors) along with the ICLAs and CCLAs for JMood to
> the secretary, so AFAIK all paperwork was in order when we did it (it was an
> awesomely large fax BTW ;-)). If anything more's needed, though, just tell
> me...
Now, come to think of it, I remember seeing that and wondering what
jmood was. I have just confirmed that three grants are on record.
Regards, Upayavira
RE: Should I move JMood to the trunk?
Posted by santillan <sa...@dit.upm.es>.
We already did fax separate software grants (one for each of the three
copyright owners/contributors) along with the ICLAs and CCLAs for JMood to
the secretary, so AFAIK all paperwork was in order when we did it (it was an
awesomely large fax BTW ;-)). If anything more's needed, though, just tell
me...
Cheers!
/manuel
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: Niclas Hedhman [mailto:niclas@hedhman.org]
Enviado el: viernes, 01 de septiembre de 2006 14:55
Para: felix-dev@incubator.apache.org
Asunto: Re: Should I move JMood to the trunk?
On Friday 01 September 2006 19:34, Manuel Santillan wrote:
> The software grant was for jmood (http://jmood.forge.os4os.org), and
> changes from that version have not been released and are under our ICLA
> and CCLA.
Ok. ASF normally requires a separate Software Grant to be faxed in, when the
codebase has existed elsewhere (as in this case).
http://www.apache.org/licenses/software-grant.txt
Just to satisfy the Incubator PMC, it would be good if this was faxed into
the
Secretary, and that this record is entered into the STATUS file of Felix.
Sorry, for all the bureaucracy, but this is what ASF requires to ensure
legal
paper trail in case of problem in the future.
Cheers
Niclas
Re: Should I move JMood to the trunk?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 01 September 2006 19:34, Manuel Santillan wrote:
> The software grant was for jmood (http://jmood.forge.os4os.org), and
> changes from that version have not been released and are under our ICLA
> and CCLA.
Ok. ASF normally requires a separate Software Grant to be faxed in, when the
codebase has existed elsewhere (as in this case).
http://www.apache.org/licenses/software-grant.txt
Just to satisfy the Incubator PMC, it would be good if this was faxed into the
Secretary, and that this record is entered into the STATUS file of Felix.
Sorry, for all the bureaucracy, but this is what ASF requires to ensure legal
paper trail in case of problem in the future.
Cheers
Niclas
Re: Should I move JMood to the trunk?
Posted by Manuel Santillan <sa...@dit.upm.es>.
The software grant has been given by all the copyright owners (myself,
JL Ruiz and JC Dueñas) with a Corporate CLA also.
The software grant was for jmood (http://jmood.forge.os4os.org), and
changes from that version have not been released and are under our ICLA
and CCLA.
All files contain the header except from the pom, quickstart and two
resources. AFAIK everything's fine...
Cheers!!
//manuel
Niclas Hedhman escribió:
> On Friday 01 September 2006 16:58, santillan wrote:
>
>> Just a note: while JMood's initial version was LGPL'd, a software grant was
>> given to the ASF and the JMood code in the trunk is properly ASL'd.
>> Moreover, I've removed the dependency to MX4J just in case (as it was easy
>> to refactor), so currently only depends on osgi.core, osgi.compendium, the
>> framework and Junit, so no licensing problems here :-)
>>
>
> Cool. So we are discussing a hypothetical case ;o)
>
> Question;
> Who has given the software grant?
> And what is the software grant covering??
> (pointer would be good).
>
>
>> My question was more related to formalisms such as Jira issues or
>> headers/license files additional to the standard ASL header on every source
>> file (which of course is included)
>>
>
> 1. Only the Copyright owner is allowed to remove Copyright notices.
> 2. There is a new Apache header to be used from now on.
>
> See http://www.apache.org/legal/src-headers.html#3party and the rest of that
> page for more details.
>
> Cheers
> Niclas
>
Re: Should I move JMood to the trunk?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 01 September 2006 16:58, santillan wrote:
> Just a note: while JMood's initial version was LGPL'd, a software grant was
> given to the ASF and the JMood code in the trunk is properly ASL'd.
> Moreover, I've removed the dependency to MX4J just in case (as it was easy
> to refactor), so currently only depends on osgi.core, osgi.compendium, the
> framework and Junit, so no licensing problems here :-)
Cool. So we are discussing a hypothetical case ;o)
Question;
Who has given the software grant?
And what is the software grant covering??
(pointer would be good).
> My question was more related to formalisms such as Jira issues or
> headers/license files additional to the standard ASL header on every source
> file (which of course is included)
1. Only the Copyright owner is allowed to remove Copyright notices.
2. There is a new Apache header to be used from now on.
See http://www.apache.org/legal/src-headers.html#3party and the rest of that
page for more details.
Cheers
Niclas
RE: Should I move JMood to the trunk?
Posted by santillan <sa...@dit.upm.es>.
Nektarios K. Papadopoulos wrote:
>IMHO, this can be safely done for JMood. JMood can be considered a
>totally optional add-on. It's not the Framewrok, not even a standard
>service.
Just a note: while JMood's initial version was LGPL'd, a software grant was
given to the ASF and the JMood code in the trunk is properly ASL'd.
Moreover, I've removed the dependency to MX4J just in case (as it was easy
to refactor), so currently only depends on osgi.core, osgi.compendium, the
framework and Junit, so no licensing problems here :-)
My question was more related to formalisms such as Jira issues or
headers/license files additional to the standard ASL header on every source
file (which of course is included)
Cheers!
//manuel
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
Re: Should I move JMood to the trunk?
Posted by "Nektarios K. Papadopoulos" <np...@inaccessnetworks.com>.
Niclas Hedhman wrote:
> On Thursday 31 August 2006 23:07, Richard S. Hall wrote:
>> Stephane,
>>
>> Are you hosting these in the repo or are you simply depending on them? I
>> assume you are just depending on them, but not checking them into the
>> repo. If so, then that is ok, right Upayavira?
>
> No, that is not correct.
>
> Since FSF is still considering Java to trigger the viral behavior of LGPL when
> you have a dependency through an import statement, ASF plays safe and do not
> allow projects to have a direct binary dependency.
IANAL, but according to http://www.gnu.org/licenses/lgpl-java.html it is
safe to have a dependency through an import statement. The problem would
be to link to GPL, *not* LGPL.
Nevertheless, indeed ASF do not allow this, with the exceptions
described in the link provided by Upayavira
(http://people.apache.org/~cliffs/3party.html#options-optional)
..(see below)
>
> IIUIC, the exception is; If the dependency can be made totally optional, so
> that when the LGPLd code is not used by the user, there are no links into the
> LGPL'd code, and that the user must explicitly enable the extension that
> brings in the LGPL'd part (I also think there are some notice requirements
> around that, to make sure the user understand what he/she is doing).
IMHO, this can be safely done for JMood. JMood can be considered a
totally optional add-on. It's not the Framewrok, not even a standard
service.
> Typically this is done by creating a facade interface which can have many
> implementations and one of those (not the default one) uses the LGPL'd part.
IIUC, a facade interface is not a requirement as long as the retrieval
of the LGPL'd part and the building of the dependent part is not enabled
by default in the standard build scripts.
>
>
> I hope this helps. If any doubts, check with legal-discuss@a.o
>
>
> Cheers
> Niclas
>
I hope this helps.
cheers,
nek
--
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue. Tel : +30-210-6837640
152 34 Halandri Athens Fax : +30-210-6899504
______________________________________________________________