You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Christian Müller <ch...@gmail.com> on 2014/07/02 23:30:21 UTC
Re: transitive 3rd party dependencies
We do released the camel-infinispan component, but without the required
dependencies.
The transitive dependency to the LGPL licensed artifact was not by design.
By using a ASL 2.0 licensed dependency we thought all its dependencies are
ok. Sorry for not being carefully enough.
We are also happy that we could resolve this issue and any new release will
be again conform to the ASF policies.
Thanks for your help,
Christian
-----------------
Software Integration Specialist
Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Sun, Jun 29, 2014 at 9:34 PM, Kevan Miller <ke...@gmail.com>
wrote:
>
> On Sun, Jun 29, 2014 at 4:36 AM, Christian Müller <
> christian.mueller@gmail.com> wrote:
>
>> If you build camel-infinispan by your own, Maven will download the
>> required dependencies (also the prohibited dependencies) and it will work.
>>
>
> Was some action taken when building your release binaries to remove the
> prohibited dependencies? Or is it that you don't have a camel-infinispan in
> your binary download? Anyway, it sounds like your current camel-infinispan
> releases violate ASF licensing policy.
>
>
>> If you run camel-infinispan without the prohibited dependencies in your
>> classpath, you will end up with ClassNotFound exceptions. In general, our
>> users use some Maven plugins to collect all required dependencies (if they
>> do it not by hand) and put they together in a WAR/ZIP/... file.
>> If a user has problems to collect the required dependencies, we point him
>> to our pom.xml file and the Maven dependency plugin. We do not provide
>> additional instructions (as we release 170+ components with each release
>> which have totally different dependencies).
>>
>
> If you had wanted to have an LGPL licensed dependency, you could have done
> so. However, it would require documentation for your users -- to insure
> they understand the consequences of their actions. E.g. commenting out the
> jboss-marshalling dependency in a pom.xml file with comments that explain
> to users the consequences of enabling the dependency.
>
> Your community is responsible for policing your releases and insuring they
> conform to ASF policies, period. Regardless of the number of components
> being released.
>
> Luckily, you have a pretty simple fix...
>
> --kevan
>
Re: transitive 3rd party dependencies
Posted by sebb <se...@gmail.com>.
On 2 July 2014 23:21, Kevan Miller <ke...@gmail.com> wrote:
>
> On Wed, Jul 2, 2014 at 2:30 PM, Christian Müller
> <ch...@gmail.com> wrote:
>>
>> We do released the camel-infinispan component, but without the required
>> dependencies.
>
>
> No. You *released* camel-infinispan with the dependency. That's a problem.
> The fact that the dependency is not in the binary that you are distributing
> is somewhat irrelevant (better than containing the dependency), but does not
> negate the problem with your releases.
That could be misinterpreted if taken out of context.
Dependencies on prohibited items are allowed provided that the
dependency is optional
http://www.apache.org/legal/resolved.html#optional
> --kevan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: transitive 3rd party dependencies
Posted by Kevan Miller <ke...@gmail.com>.
On Wed, Jul 2, 2014 at 2:30 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> We do released the camel-infinispan component, but without the required
> dependencies.
>
No. You *released* camel-infinispan with the dependency. That's a problem.
The fact that the dependency is not in the binary that you are distributing
is somewhat irrelevant (better than containing the dependency), but does
not negate the problem with your releases.
--kevan
Re: transitive 3rd party dependencies
Posted by Christian Müller <ch...@gmail.com>.
In the meantime we released Camel 2.13.2 which fixed this issue. It's also
fixed on trunk for the upcoming Camel 2.14.0 release.
Should we consider some further actions on this? What would it be?
Best,
Christian
On Thu, Jul 3, 2014 at 2:41 AM, sebb <se...@gmail.com> wrote:
> On 2 July 2014 22:30, Christian Müller <ch...@gmail.com>
> wrote:
> > We do released the camel-infinispan component, but without the required
> > dependencies.
> >
> > The transitive dependency to the LGPL licensed artifact was not by
> design.
> > By using a ASL 2.0 licensed dependency we thought all its dependencies
> are
> > ok. Sorry for not being carefully enough.
>
> I think this shows why it's important to get the licensing right!
> We don't want others to be caught by similar problems with any of our
> AL2.0 code.
>
> > We are also happy that we could resolve this issue and any new release
> will
> > be again conform to the ASF policies.
> >
> > Thanks for your help,
> >
> > Christian
> > -----------------
> >
> > Software Integration Specialist
> >
> > Apache Member
> > V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
> > Apache Incubator PMC Member
> >
> > https://www.linkedin.com/pub/christian-mueller/11/551/642
> >
> >
> > On Sun, Jun 29, 2014 at 9:34 PM, Kevan Miller <ke...@gmail.com>
> > wrote:
> >>
> >>
> >> On Sun, Jun 29, 2014 at 4:36 AM, Christian Müller
> >> <ch...@gmail.com> wrote:
> >>>
> >>> If you build camel-infinispan by your own, Maven will download the
> >>> required dependencies (also the prohibited dependencies) and it will
> work.
> >>
> >>
> >> Was some action taken when building your release binaries to remove the
> >> prohibited dependencies? Or is it that you don't have a
> camel-infinispan in
> >> your binary download? Anyway, it sounds like your current
> camel-infinispan
> >> releases violate ASF licensing policy.
> >>
> >>>
> >>> If you run camel-infinispan without the prohibited dependencies in your
> >>> classpath, you will end up with ClassNotFound exceptions. In general,
> our
> >>> users use some Maven plugins to collect all required dependencies (if
> they
> >>> do it not by hand) and put they together in a WAR/ZIP/... file.
> >>> If a user has problems to collect the required dependencies, we point
> him
> >>> to our pom.xml file and the Maven dependency plugin. We do not provide
> >>> additional instructions (as we release 170+ components with each
> release
> >>> which have totally different dependencies).
> >>
> >>
> >> If you had wanted to have an LGPL licensed dependency, you could have
> done
> >> so. However, it would require documentation for your users -- to insure
> they
> >> understand the consequences of their actions. E.g. commenting out the
> >> jboss-marshalling dependency in a pom.xml file with comments that
> explain to
> >> users the consequences of enabling the dependency.
> >>
> >> Your community is responsible for policing your releases and insuring
> they
> >> conform to ASF policies, period. Regardless of the number of components
> >> being released.
> >>
> >> Luckily, you have a pretty simple fix...
> >>
> >> --kevan
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: transitive 3rd party dependencies
Posted by sebb <se...@gmail.com>.
On 2 July 2014 22:30, Christian Müller <ch...@gmail.com> wrote:
> We do released the camel-infinispan component, but without the required
> dependencies.
>
> The transitive dependency to the LGPL licensed artifact was not by design.
> By using a ASL 2.0 licensed dependency we thought all its dependencies are
> ok. Sorry for not being carefully enough.
I think this shows why it's important to get the licensing right!
We don't want others to be caught by similar problems with any of our
AL2.0 code.
> We are also happy that we could resolve this issue and any new release will
> be again conform to the ASF policies.
>
> Thanks for your help,
>
> Christian
> -----------------
>
> Software Integration Specialist
>
> Apache Member
> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
> Apache Incubator PMC Member
>
> https://www.linkedin.com/pub/christian-mueller/11/551/642
>
>
> On Sun, Jun 29, 2014 at 9:34 PM, Kevan Miller <ke...@gmail.com>
> wrote:
>>
>>
>> On Sun, Jun 29, 2014 at 4:36 AM, Christian Müller
>> <ch...@gmail.com> wrote:
>>>
>>> If you build camel-infinispan by your own, Maven will download the
>>> required dependencies (also the prohibited dependencies) and it will work.
>>
>>
>> Was some action taken when building your release binaries to remove the
>> prohibited dependencies? Or is it that you don't have a camel-infinispan in
>> your binary download? Anyway, it sounds like your current camel-infinispan
>> releases violate ASF licensing policy.
>>
>>>
>>> If you run camel-infinispan without the prohibited dependencies in your
>>> classpath, you will end up with ClassNotFound exceptions. In general, our
>>> users use some Maven plugins to collect all required dependencies (if they
>>> do it not by hand) and put they together in a WAR/ZIP/... file.
>>> If a user has problems to collect the required dependencies, we point him
>>> to our pom.xml file and the Maven dependency plugin. We do not provide
>>> additional instructions (as we release 170+ components with each release
>>> which have totally different dependencies).
>>
>>
>> If you had wanted to have an LGPL licensed dependency, you could have done
>> so. However, it would require documentation for your users -- to insure they
>> understand the consequences of their actions. E.g. commenting out the
>> jboss-marshalling dependency in a pom.xml file with comments that explain to
>> users the consequences of enabling the dependency.
>>
>> Your community is responsible for policing your releases and insuring they
>> conform to ASF policies, period. Regardless of the number of components
>> being released.
>>
>> Luckily, you have a pretty simple fix...
>>
>> --kevan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org