You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Kevin Menard <km...@servprise.com> on 2008/01/03 20:37:19 UTC
Dynarch licensing issue
Hi all,
I just noticed that the dynarch library used by Tapestry 5 is LGPL.
According to ASF lawyers, this is a no-no:
http://apache.org/legal/3party.html
So, this puts Tapestry in the unfortunate position of not really being able
to use another piece of open source code.
Anyway, I just wanted to alert the development team before opening a JIRA
issue so discussion can ensue on the best course of action.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Dynarch licensing issue
Posted by Kevin Menard <km...@servprise.com>.
On 1/3/08 6:12 PM, in article
ecd0e3310801031512u3c6e5147le65a08b61a4cadb3@mail.gmail.com, "Howard Lewis
Ship" <hl...@gmail.com> wrote:
> Or ask Dynark to add a compatible license.
Also a viable option, although they sell a commercial version so they may be
using the LGPL for more reasons other than freedom. That's just speculation
though based upon my experience with other such projects. In any event, it
never hurts to ask.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Dynarch licensing issue
Posted by Howard Lewis Ship <hl...@gmail.com>.
Or ask Dynark to add a compatible license.
On Jan 3, 2008 2:18 PM, Kevin Menard <km...@servprise.com> wrote:
> It's an extra hurdle that isn't needed. I'd just assume not use the
> DateField component at all because I don't need to be chasing down a
> dependency everytime I want to use that component. Best case is that the
> javascript gets packaged up into a component hosted on a non-ASF server and
> can be deployed via maven, but someone has to step up to do that.
> Otherwise, how do you distribute the JS in a standard manner? Tell the user
> that they also have to add it to the classpath for the component to find it?
>
> Now, is this to be acceptable for each different component if each is to use
> an LGPL library (obviously not the case, but worst case)?
>
> At least in the case of the non-distributable JARs you mentioned there's a
> standard way to deal with the problem. Heck, maven even tells you where to
> download the JARs from and how to deploy them to an internal repository. A
> process that's well defined and needs to be executed precisely once for each
> maven environment as a whole.
>
> At the end of the day, it's likely easier to just find another calendar that
> has a compatible license or to roll our own.
>
> Regards,
> Kevin
>
>
> On 1/3/08 4:48 PM, in article
> b539f7630801031348s7dfff4d7id1986a84275de2b@mail.gmail.com, "Paul Cooley"
>
> <pe...@gmail.com> wrote:
>
> > The same argument can be made for quite a few of the specific java libraries
> > as well. Those that are not included in maven require you to manually
> > install them in your repository for builds, since they cannot be
> > distributed. I understand the warning, but I fail to see how this is a
> > showstopper. If it's an important library for the project, then all we need
> > are release notes to know what needs to be installed separately from the
> > distribution.
> >
> > After all, we're going to run into the same kinds of issues when packaging
> > public webapps to be distributing via tomcat/jboss/etc for libraries that
> > can't legally be packaged in an application.
> >
> > Cheers.
> >
> > On Jan 3, 2008 3:38 PM, Kevin Menard <km...@servprise.com> wrote:
> >
> >> Correct, but that makes it practically useless as a core component :-/
> >>
> >> --
> >> Kevin
> >>
> >>
> >> On 1/3/08 3:23 PM, in article
> >> b539f7630801031223h335d1a1bqcb21161ad3f81134@mail.gmail.com, "Paul Cooley"
> >> <pe...@gmail.com> wrote:
> >>
> >>> Actually it appears it can be listed as a system requirement: just not
> >>> included for distribution.
> >>>
> >>> On Jan 3, 2008 2:21 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> >>>
> >>>> Sounds like the policy has shifted again. It's like quicksilver.
> >>>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Dynarch licensing issue
Posted by Kevin Menard <km...@servprise.com>.
It's an extra hurdle that isn't needed. I'd just assume not use the
DateField component at all because I don't need to be chasing down a
dependency everytime I want to use that component. Best case is that the
javascript gets packaged up into a component hosted on a non-ASF server and
can be deployed via maven, but someone has to step up to do that.
Otherwise, how do you distribute the JS in a standard manner? Tell the user
that they also have to add it to the classpath for the component to find it?
Now, is this to be acceptable for each different component if each is to use
an LGPL library (obviously not the case, but worst case)?
At least in the case of the non-distributable JARs you mentioned there's a
standard way to deal with the problem. Heck, maven even tells you where to
download the JARs from and how to deploy them to an internal repository. A
process that's well defined and needs to be executed precisely once for each
maven environment as a whole.
At the end of the day, it's likely easier to just find another calendar that
has a compatible license or to roll our own.
Regards,
Kevin
On 1/3/08 4:48 PM, in article
b539f7630801031348s7dfff4d7id1986a84275de2b@mail.gmail.com, "Paul Cooley"
<pe...@gmail.com> wrote:
> The same argument can be made for quite a few of the specific java libraries
> as well. Those that are not included in maven require you to manually
> install them in your repository for builds, since they cannot be
> distributed. I understand the warning, but I fail to see how this is a
> showstopper. If it's an important library for the project, then all we need
> are release notes to know what needs to be installed separately from the
> distribution.
>
> After all, we're going to run into the same kinds of issues when packaging
> public webapps to be distributing via tomcat/jboss/etc for libraries that
> can't legally be packaged in an application.
>
> Cheers.
>
> On Jan 3, 2008 3:38 PM, Kevin Menard <km...@servprise.com> wrote:
>
>> Correct, but that makes it practically useless as a core component :-/
>>
>> --
>> Kevin
>>
>>
>> On 1/3/08 3:23 PM, in article
>> b539f7630801031223h335d1a1bqcb21161ad3f81134@mail.gmail.com, "Paul Cooley"
>> <pe...@gmail.com> wrote:
>>
>>> Actually it appears it can be listed as a system requirement: just not
>>> included for distribution.
>>>
>>> On Jan 3, 2008 2:21 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>>>
>>>> Sounds like the policy has shifted again. It's like quicksilver.
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Dynarch licensing issue
Posted by Paul Cooley <pe...@gmail.com>.
The same argument can be made for quite a few of the specific java libraries
as well. Those that are not included in maven require you to manually
install them in your repository for builds, since they cannot be
distributed. I understand the warning, but I fail to see how this is a
showstopper. If it's an important library for the project, then all we need
are release notes to know what needs to be installed separately from the
distribution.
After all, we're going to run into the same kinds of issues when packaging
public webapps to be distributing via tomcat/jboss/etc for libraries that
can't legally be packaged in an application.
Cheers.
On Jan 3, 2008 3:38 PM, Kevin Menard <km...@servprise.com> wrote:
> Correct, but that makes it practically useless as a core component :-/
>
> --
> Kevin
>
>
> On 1/3/08 3:23 PM, in article
> b539f7630801031223h335d1a1bqcb21161ad3f81134@mail.gmail.com, "Paul Cooley"
> <pe...@gmail.com> wrote:
>
> > Actually it appears it can be listed as a system requirement: just not
> > included for distribution.
> >
> > On Jan 3, 2008 2:21 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> >> Sounds like the policy has shifted again. It's like quicksilver.
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Gotta find my destiny, before it gets too late.-- Ian Curtis
Re: Dynarch licensing issue
Posted by Kevin Menard <km...@servprise.com>.
Correct, but that makes it practically useless as a core component :-/
--
Kevin
On 1/3/08 3:23 PM, in article
b539f7630801031223h335d1a1bqcb21161ad3f81134@mail.gmail.com, "Paul Cooley"
<pe...@gmail.com> wrote:
> Actually it appears it can be listed as a system requirement: just not
> included for distribution.
>
> On Jan 3, 2008 2:21 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> Sounds like the policy has shifted again. It's like quicksilver.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Dynarch licensing issue
Posted by Paul Cooley <pe...@gmail.com>.
Actually it appears it can be listed as a system requirement: just not
included for distribution.
On Jan 3, 2008 2:21 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Sounds like the policy has shifted again. It's like quicksilver.
>
> On Jan 3, 2008 11:37 AM, Kevin Menard <km...@servprise.com> wrote:
> > Hi all,
> >
> > I just noticed that the dynarch library used by Tapestry 5 is LGPL.
> > According to ASF lawyers, this is a no-no:
> >
> > http://apache.org/legal/3party.html
> >
> > So, this puts Tapestry in the unfortunate position of not really being
> able
> > to use another piece of open source code.
> >
> > Anyway, I just wanted to alert the development team before opening a
> JIRA
> > issue so discussion can ensue on the best course of action.
> >
> > --
> > Kevin
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Gotta find my destiny, before it gets too late.-- Ian Curtis
Re: Dynarch licensing issue
Posted by Howard Lewis Ship <hl...@gmail.com>.
Sounds like the policy has shifted again. It's like quicksilver.
On Jan 3, 2008 11:37 AM, Kevin Menard <km...@servprise.com> wrote:
> Hi all,
>
> I just noticed that the dynarch library used by Tapestry 5 is LGPL.
> According to ASF lawyers, this is a no-no:
>
> http://apache.org/legal/3party.html
>
> So, this puts Tapestry in the unfortunate position of not really being able
> to use another piece of open source code.
>
> Anyway, I just wanted to alert the development team before opening a JIRA
> issue so discussion can ensue on the best course of action.
>
> --
> Kevin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org