You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2014/01/10 05:44:08 UTC
Re: Third-Party Licensing Policy
Hi
It's a difference between inclusion, usage, and reference.
For instance, GPL license is a intrusive license. It means that any
software that use a code under GPL has to be itself under the GPL
license. That's why you can't use GPL in a Apache project. It's the case
for usage, inclusion or reference.
LGPL is a bit permissive in the cave of reference. LGPL is a Category X
for inclusion and usage. It means that it's not possible to use LGPL if
the project embeds some jar under LGPL, or ship some code (like
copy/paste) under LGPL. However, if you just reference the project
without embedding it, and it's an user action to actually download and
add the LGPL jar, it's fine.
Regarding your question:
1/ category A
2/ category A
3/ category A and B
4/ category A and B (and we have to "publish" the changes)
5/ all
6/ category A and B
Regards
JB
On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
> Hi
>
> I have some licensing questions.
>
> I have found following page http://www.apache.org/legal/3party.html
> which defines 3 categories of third party licenses. According to this
> page LGPL v2.1 is category X, but further remark says, the
> LGPL-v2.1-licensed work can be listed as system requirements but can not
> be included by Apache products. I'm not good in licensing but I try to
> understand it. Is the category of LGPL really B (and the page should be
> corrected) or is the LGP category X. In the second case, can we still
> list Hibernate in Karaf features (e.g. using the remark about listing of
> system requirements)?
>
> Assume following use cases of third-party work usage:
> 1. reference 3rd-party library as (maven) dependency and use the classes
> in ASF code
> 2. reference 3rd-party library as (maven) dependency and use the classes
> only in ASF configuration files (e.g. blueprint.xml)
> 3. include/copy some unmodified 3rd-party code (e.g. some classes) in
> ASF project
> 4. include/copy some 3rd-party code (e.g. some classes) in ASF project
> and modify it
> 5. list some 3rd-party libraries in Karaf features, but not include them
> as binaries in one of the Karaf distributions
> 6. list some 3rd-party libraries in Karaf features, and include them as
> binaries in one of the Karaf distributions in system repository
>
> Could anybody please answer which of above points are allowed for
> following 3rd-party works
> a. category A as the whole category - I assume, all above use cases are
> allowed in this category, is it ok?
> b. category B as the whole category
> c. category X as the whole category
> d. LGPL
> e. GPL
> f. EPL
>
> I have chosen Karaf as sample ASF project, but it could be any other ASF
> project, e.g. ServiceMix or Aries
>
> Do the rules from the page mentioned above apply only for ASF projects
> or for any project licensed under Apache License?
>
> Best regards
> Krzysztof
>
>
>
> On 03.01.2014 11:51, Jean-Baptiste Onofré wrote:
>> LGPL is category B (not X), so we can reference it but not "include"
>> it: it's what we do.
>>
>> FYI, in Karaf 3.0.0, I've already added a hibernate feature.
>>
>> Regards
>> JB
>>
>> On 01/03/2014 11:46 AM, Freeman Fang wrote:
>>> Though it's a very useful feature, I'm not sure if we can add it in
>>> Karaf, as Hibernate is under LGPL license, can we?
>>> －－－－－－－－－－－－－
>>> Freeman(Yue) Fang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: AspectJ WeavingHook (was :Third-Party Licensing Policy)
Posted by Cristiano Costantini <cr...@gmail.com>.
I'm with you on the idea of a Blueprint AOP (I would love to abandon spring for
blueprint in a future day).
Il giorno sabato 11 gennaio 2014, Krzysztof Sobkowiak ha scritto:
> I thought about a separate implementation of WeavingHook. But I could
> look at Aries weaving. Is it implemented in the Aries Proxy project? Are
> there any samples of Aries weaving usage?
>
> I think, the implementation should be universal, installable on any OSGi
> 4.3 runtime. If Arise weaving is a separate bundle which could be installed
> with the AspectJ weaving and it doesn't force the usage of other Aries
> subprojects, like Aries Blueprint, it should be ok.
>
> I think also, it would be nice to have later some art of integration with
> blueprint (like Spring AOP schema) which allows to wire blueprint beans
> into the aspect using aspectOf factory method. Or even more, something more
> lightweight like Spring AOP - Blueprint AOP - extension for blueprint which
> can use blueprint beans annotated with AspectJ annotations and apply them
> as aspects on bean proxies. But it is theme for Aries project.
>
> Regards Krzysztof
>
> On 11.01.2014 14:08, Jean-Baptiste Onofré wrote:
>
> Good point. Theoretical, I would say aries-extra if you are based on Aries
> weaving. However, as Aries is a library, in order to use/test it you have
> to use it in a container like Karaf. So as a ready to use solution (with
> features), it could be in karaf-extra. Actually, it's likely like the other
> Aries project: the library/API codebase is in Aries, the execution
> (features and usage) is in Karaf.
>
> Regards
> JB
>
> On 01/11/2014 01:02 PM, Krzysztof Sobkowiak wrote:
>
> By the way, which project would be the best final place for the solution
> with AspectJ? Karaf (in this case karaf-extra) or Aries (aries-extra)?
>
> Best regards
> Krzysztof
>
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center<http://www.pl.capgemini-sdm.com/>| Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <javascript:_e({}, 'cvml',
> 'krzys.sobkowiak@gmail.com');> | Twitter: @KSobkowiak
>
AspectJ WeavingHook (was :Third-Party Licensing Policy)
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
I thought about a separate implementation of WeavingHook. But I could
look at Aries weaving. Is it implemented in the Aries Proxy project? Are
there any samples of Aries weaving usage?
I think, the implementation should be universal, installable on any OSGi
4.3 runtime. If Arise weaving is a separate bundle which could be
installed with the AspectJ weaving and it doesn't force the usage of
other Aries subprojects, like Aries Blueprint, it should be ok.
I think also, it would be nice to have later some art of integration
with blueprint (like Spring AOP schema) which allows to wire blueprint
beans into the aspect using aspectOf factory method. Or even more,
something more lightweight like Spring AOP - Blueprint AOP - extension
for blueprint which can use blueprint beans annotated with AspectJ
annotations and apply them as aspects on bean proxies. But it is theme
for Aries project.
Regards Krzysztof
On 11.01.2014 14:08, Jean-Baptiste Onofré wrote:
> Good point. Theoretical, I would say aries-extra if you are based on
> Aries weaving. However, as Aries is a library, in order to use/test it
> you have to use it in a container like Karaf. So as a ready to use
> solution (with features), it could be in karaf-extra. Actually, it's
> likely like the other Aries project: the library/API codebase is in
> Aries, the execution (features and usage) is in Karaf.
>
> Regards
> JB
>
> On 01/11/2014 01:02 PM, Krzysztof Sobkowiak wrote:
>> By the way, which project would be the best final place for the solution
>> with AspectJ? Karaf (in this case karaf-extra) or Aries (aries-extra)?
>>
>> Best regards
>> Krzysztof
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: AspectJ WeavingHook
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi
Any idea?
Best regards
Krzysztof
On 11.06.2014 22:20, Krzysztof Sobkowiak wrote:
> Hi
>
> I'd like to do one small step towards the AspectJ WeavingHook
> implementation. If it should be part of karaf-extra, what a package
> naming should be used? Do you have any idea which license should be
> used for this code?
>
> Best regards
> Krzysztof
>
> On 11.01.2014 14:08, Jean-Baptiste Onofré wrote:
>> Good point. Theoretical, I would say aries-extra if you are based on
>> Aries weaving. However, as Aries is a library, in order to use/test
>> it you have to use it in a container like Karaf. So as a ready to use
>> solution (with features), it could be in karaf-extra. Actually, it's
>> likely like the other Aries project: the library/API codebase is in
>> Aries, the execution (features and usage) is in Karaf.
>>
>> Regards
>> JB
>>
>> On 01/11/2014 01:02 PM, Krzysztof Sobkowiak wrote:
>>> By the way, which project would be the best final place for the
>>> solution
>>> with AspectJ? Karaf (in this case karaf-extra) or Aries
>>> (aries-extra)?
>>>
>>> Best regards
>>> Krzysztof
>>>
>>> On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>>>>>
>>>>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>>>>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>>>>> (reference AspectJ as maven dependency and use the classes in my
>>>>> code).
>>>>> Does it mean, my code can not be included in Apache licensed project,
>>>>> but I can implement the hook in a project under other license and
>>>>> eventually reference it in Karaf feature?
>>>>
>>>> Correct, you can't include in Apache project. You can create your
>>>> project outside of Apache project and reference it. Same as before:
>>>> you can do your WeavingHook in karaf-extra.
>>>
>>
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
> Calendar: goo.gl/yvsebC
--
Krzysztof Sobkowiak
JEE & OSS Architect | Senior Solution Architect @ Capgemini | Committer
@ ASF
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC
AspectJ WeavingHook (was: Third-Party Licensing Policy)
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi
I'd like to do one small step towards the AspectJ WeavingHook
implementation. If it should be part of karaf-extra, what a package
naming should be used? Do you have any idea which license should be used
for this code?
Best regards
Krzysztof
On 11.01.2014 14:08, Jean-Baptiste Onofré wrote:
> Good point. Theoretical, I would say aries-extra if you are based on
> Aries weaving. However, as Aries is a library, in order to use/test it
> you have to use it in a container like Karaf. So as a ready to use
> solution (with features), it could be in karaf-extra. Actually, it's
> likely like the other Aries project: the library/API codebase is in
> Aries, the execution (features and usage) is in Karaf.
>
> Regards
> JB
>
> On 01/11/2014 01:02 PM, Krzysztof Sobkowiak wrote:
>> By the way, which project would be the best final place for the solution
>> with AspectJ? Karaf (in this case karaf-extra) or Aries (aries-extra)?
>>
>> Best regards
>> Krzysztof
>>
>> On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>>>>
>>>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>>>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>>>> (reference AspectJ as maven dependency and use the classes in my
>>>> code).
>>>> Does it mean, my code can not be included in Apache licensed project,
>>>> but I can implement the hook in a project under other license and
>>>> eventually reference it in Karaf feature?
>>>
>>> Correct, you can't include in Apache project. You can create your
>>> project outside of Apache project and reference it. Same as before:
>>> you can do your WeavingHook in karaf-extra.
>>
>
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Calendar: goo.gl/yvsebC
Re: Third-Party Licensing Policy
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Good point. Theoretical, I would say aries-extra if you are based on
Aries weaving. However, as Aries is a library, in order to use/test it
you have to use it in a container like Karaf. So as a ready to use
solution (with features), it could be in karaf-extra. Actually, it's
likely like the other Aries project: the library/API codebase is in
Aries, the execution (features and usage) is in Karaf.
Regards
JB
On 01/11/2014 01:02 PM, Krzysztof Sobkowiak wrote:
> By the way, which project would be the best final place for the solution
> with AspectJ? Karaf (in this case karaf-extra) or Aries (aries-extra)?
>
> Best regards
> Krzysztof
>
> On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>>>
>>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>>> (reference AspectJ as maven dependency and use the classes in my code).
>>> Does it mean, my code can not be included in Apache licensed project,
>>> but I can implement the hook in a project under other license and
>>> eventually reference it in Karaf feature?
>>
>> Correct, you can't include in Apache project. You can create your
>> project outside of Apache project and reference it. Same as before:
>> you can do your WeavingHook in karaf-extra.
>>
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Third-Party Licensing Policy
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
By the way, which project would be the best final place for the solution
with AspectJ? Karaf (in this case karaf-extra) or Aries (aries-extra)?
Best regards
Krzysztof
On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>>
>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>> (reference AspectJ as maven dependency and use the classes in my code).
>> Does it mean, my code can not be included in Apache licensed project,
>> but I can implement the hook in a project under other license and
>> eventually reference it in Karaf feature?
>
> Correct, you can't include in Apache project. You can create your
> project outside of Apache project and reference it. Same as before:
> you can do your WeavingHook in karaf-extra.
>
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: Third-Party Licensing Policy
Posted by Christoph Emmersberger <ce...@gmail.com>.
Hi Jean-Baptiste
interesting point, that I’ve been also looking at in the past.
Issues I encountered in the past are:
(1) Where to place the *-extra project on github. ASF related projects are mirrored under the Apache user [1]. To keep it consistent, we might need an apache-extra user on github.
(2) How does the mirroring actually work? As far as I read, you need to open a request on github so that they will run the mirroring commands since those are not exposed to the public, but maybe I am wrong.
Best,
- Christoph
[1] https://github.com/apache
On 10 Jan 2014, at 15:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Henryk,
>
> you are right. My proposal is more a mirror on github: so the code itself stays on googecode, but we have a mirror on github (as we have for other Apache projects).
>
> Regards
> JB
>
> On 01/10/2014 03:17 PM, Henryk Konsek wrote:
>>> I meant the [camel,servicemix]-extra projects from googlecode. It would be
>>> nice to have git repositories for the code.
>>
>> Keep in mind guys, that Google Code supports git repositories. We have
>> migrated Camel Extra to git [1] few months back.
>>
>> BTW I think that usage of Google Code repository [2] is somehow
>> regulated by the Apache Extras rules [3]. However to be honest I would
>> prefer to have Camel Extra at GitHub as well :) .
>>
>> Cheers.
>>
>> [1] http://code.google.com/a/apache-extras.org/p/camel-extra/source/checkout
>> [2] http://code.google.com/a/apache-extras.org/hosting/
>> [3] http://community.apache.org/apache-extras/faq.html
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Third-Party Licensing Policy
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Henryk,
you are right. My proposal is more a mirror on github: so the code
itself stays on googecode, but we have a mirror on github (as we have
for other Apache projects).
Regards
JB
On 01/10/2014 03:17 PM, Henryk Konsek wrote:
>> I meant the [camel,servicemix]-extra projects from googlecode. It would be
>> nice to have git repositories for the code.
>
> Keep in mind guys, that Google Code supports git repositories. We have
> migrated Camel Extra to git [1] few months back.
>
> BTW I think that usage of Google Code repository [2] is somehow
> regulated by the Apache Extras rules [3]. However to be honest I would
> prefer to have Camel Extra at GitHub as well :) .
>
> Cheers.
>
> [1] http://code.google.com/a/apache-extras.org/p/camel-extra/source/checkout
> [2] http://code.google.com/a/apache-extras.org/hosting/
> [3] http://community.apache.org/apache-extras/faq.html
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Third-Party Licensing Policy
Posted by Henryk Konsek <he...@gmail.com>.
> I meant the [camel,servicemix]-extra projects from googlecode. It would be
> nice to have git repositories for the code.
Keep in mind guys, that Google Code supports git repositories. We have
migrated Camel Extra to git [1] few months back.
BTW I think that usage of Google Code repository [2] is somehow
regulated by the Apache Extras rules [3]. However to be honest I would
prefer to have Camel Extra at GitHub as well :) .
Cheers.
[1] http://code.google.com/a/apache-extras.org/p/camel-extra/source/checkout
[2] http://code.google.com/a/apache-extras.org/hosting/
[3] http://community.apache.org/apache-extras/faq.html
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Third-Party Licensing Policy
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Ah ok. You are right, I gonna propose and create it.
Regards
JB
On 01/10/2014 09:09 AM, Krzysztof Sobkowiak wrote:
> I meant the [camel,servicemix]-extra projects from googlecode. It would
> be nice to have git repositories for the code.
>
> Regards
> Krzysztof
>
> On 10.01.2014 09:05, Jean-Baptiste Onofré wrote:
>> I didn't create the karaf-extra project yet as we didn't have the need.
>>
>> I will create it when we need some extra/contrib.
>>
>> When you said "any plans to migrate the projects", you mean Karaf
>> projects ?
>>
>> Regards
>> JB
>>
>> On 01/10/2014 08:21 AM, Krzysztof Sobkowiak wrote:
>>> Ok thanks a lot, it clarified me my questions. The license content use
>>> juridical language. I don't understand it always. I could find
>>> camel-extra and servicemix-extra projects. But I can't find karaf-extra.
>>> Where is this project? Have you any plans to migrate the projects in git
>>> (or even host on Github)?
>>>
>>> Best regards
>>> Krzysztof
>>>
>>> On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>>>> Hi Krzysztof,
>>>>
>>>> I invite you to read the GPL, APL, etc license content.
>>>>
>>>> My comments inline:
>>>>
>>>> On 01/10/2014 07:36 AM, Krzysztof Sobkowiak wrote:
>>>>> Hi
>>>>>
>>>>> Thanks for answers. I need still some clarifications. I'll use some
>>>>> samples
>>>>>
>>>>> On 10.01.2014 05:44, Jean-Baptiste Onofré wrote:
>>>>>> Hi
>>>>>>
>>>>>> It's a difference between inclusion, usage, and reference.
>>>>>>
>>>>>> For instance, GPL license is a intrusive license. It means that any
>>>>>> software that use a code under GPL has to be itself under the GPL
>>>>>> license. That's why you can't use GPL in a Apache project. It's the
>>>>>> case for usage, inclusion or reference.
>>>>>> LGPL is a bit permissive in the cave of reference. LGPL is a Category
>>>>>> X for inclusion and usage. It means that it's not possible to use
>>>>>> LGPL
>>>>>> if the project embeds some jar under LGPL, or ship some code (like
>>>>>> copy/paste) under LGPL. However, if you just reference the project
>>>>>> without embedding it, and it's an user action to actually download
>>>>>> and
>>>>>> add the LGPL jar, it's fine.
>>>>> I don't know if I have understood it correctly. I can reference
>>>>> Hibernate libraries in Karaf feature (e.g. because it is referenced by
>>>>> other library which is also included in Karaf feature ans uses the
>>>>> code
>>>>> from Hibernate or because we need Hibernate as JPA provider) . But
>>>>> I can
>>>>> not implement any sample with Karaf which shows, how to use Spring
>>>>> with
>>>>> plain Hibernate, because the Hibernate code (e.g. SessionFactory)
>>>>> would
>>>>> be referenced in this code. But I can implement such a sample outside
>>>>> Karaf (probably under another license, which? LGPL?) and eventually
>>>>> reference the sample somewhere in the Karaf feature like the Hibernate
>>>>> libraries?
>>>>
>>>> Correct. That's why we have karaf-extra (like camel-extra,
>>>> servicemix-extra) to store such code/sample outside Apache codebase.
>>>>
>>>>>
>>>>>> Regarding your question:
>>>>>> 1/ category A
>>>>>> 2/ category A
>>>>>> 3/ category A and B
>>>>>> 4/ category A and B (and we have to "publish" the changes)
>>>>>
>>>>> Does it mean I can copy some code (e.g. classes) from category B
>>>>> library
>>>>> into Apache licensed project, eventually change the code, and and ship
>>>>> it as part of this project (usage 3 and 4) but I can not reference the
>>>>> category B libraries as maven dependencies and use the classes from
>>>>> the
>>>>> dependencies in Apache licensed project (usage 1 and 2)?
>>>>
>>>> Not really, it depends in the license. Basically, all code in Apache
>>>> project should be under Apache license. Again, we can add it in
>>>> karaf-extra.
>>>>
>>>>>
>>>>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>>>>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>>>>> (reference AspectJ as maven dependency and use the classes in my
>>>>> code).
>>>>> Does it mean, my code can not be included in Apache licensed project,
>>>>> but I can implement the hook in a project under other license and
>>>>> eventually reference it in Karaf feature?
>>>>
>>>> Correct, you can't include in Apache project. You can create your
>>>> project outside of Apache project and reference it. Same as before:
>>>> you can do your WeavingHook in karaf-extra.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>>
>>>>> Best regards
>>>>> Krzysztof
>>>>>
>>>>>> 5/ all
>>>>>> 6/ category A and B
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I have some licensing questions.
>>>>>>>
>>>>>>> I have found following page http://www.apache.org/legal/3party.html
>>>>>>> which defines 3 categories of third party licenses. According to
>>>>>>> this
>>>>>>> page LGPL v2.1 is category X, but further remark says, the
>>>>>>> LGPL-v2.1-licensed work can be listed as system requirements but
>>>>>>> can not
>>>>>>> be included by Apache products. I'm not good in licensing but I
>>>>>>> try to
>>>>>>> understand it. Is the category of LGPL really B (and the page
>>>>>>> should be
>>>>>>> corrected) or is the LGP category X. In the second case, can we
>>>>>>> still
>>>>>>> list Hibernate in Karaf features (e.g. using the remark about
>>>>>>> listing of
>>>>>>> system requirements)?
>>>>>>>
>>>>>>> Assume following use cases of third-party work usage:
>>>>>>> 1. reference 3rd-party library as (maven) dependency and use the
>>>>>>> classes
>>>>>>> in ASF code
>>>>>>> 2. reference 3rd-party library as (maven) dependency and use the
>>>>>>> classes
>>>>>>> only in ASF configuration files (e.g. blueprint.xml)
>>>>>>> 3. include/copy some unmodified 3rd-party code (e.g. some
>>>>>>> classes) in
>>>>>>> ASF project
>>>>>>> 4. include/copy some 3rd-party code (e.g. some classes) in ASF
>>>>>>> project
>>>>>>> and modify it
>>>>>>> 5. list some 3rd-party libraries in Karaf features, but not include
>>>>>>> them
>>>>>>> as binaries in one of the Karaf distributions
>>>>>>> 6. list some 3rd-party libraries in Karaf features, and include
>>>>>>> them as
>>>>>>> binaries in one of the Karaf distributions in system repository
>>>>>>>
>>>>>>> Could anybody please answer which of above points are allowed for
>>>>>>> following 3rd-party works
>>>>>>> a. category A as the whole category - I assume, all above use cases
>>>>>>> are
>>>>>>> allowed in this category, is it ok?
>>>>>>> b. category B as the whole category
>>>>>>> c. category X as the whole category
>>>>>>> d. LGPL
>>>>>>> e. GPL
>>>>>>> f. EPL
>>>>>>>
>>>>>>> I have chosen Karaf as sample ASF project, but it could be any
>>>>>>> other ASF
>>>>>>> project, e.g. ServiceMix or Aries
>>>>>>>
>>>>>>> Do the rules from the page mentioned above apply only for ASF
>>>>>>> projects
>>>>>>> or for any project licensed under Apache License?
>>>>>>>
>>>>>>> Best regards
>>>>>>> Krzysztof
>>>>>
>>>>>
>>>>> --
>>>>> Krzysztof Sobkowiak
>>>>>
>>>>> JEE & OSS Architect | Technical Architect @ Capgemini
>>>>> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
>>>>> <http://www.pl.capgemini-sdm.com/> | Wroclaw
>>>>> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>>>>> Twitter: @KSobkowiak
>>>>
>>>
>>>
>>> --
>>> Krzysztof Sobkowiak
>>>
>>> JEE & OSS Architect | Technical Architect @ Capgemini
>>> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
>>> <http://www.pl.capgemini-sdm.com/> | Wroclaw
>>> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>>> Twitter: @KSobkowiak
>>
>
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Third-Party Licensing Policy
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
I meant the [camel,servicemix]-extra projects from googlecode. It would
be nice to have git repositories for the code.
Regards
Krzysztof
On 10.01.2014 09:05, Jean-Baptiste Onofré wrote:
> I didn't create the karaf-extra project yet as we didn't have the need.
>
> I will create it when we need some extra/contrib.
>
> When you said "any plans to migrate the projects", you mean Karaf
> projects ?
>
> Regards
> JB
>
> On 01/10/2014 08:21 AM, Krzysztof Sobkowiak wrote:
>> Ok thanks a lot, it clarified me my questions. The license content use
>> juridical language. I don't understand it always. I could find
>> camel-extra and servicemix-extra projects. But I can't find karaf-extra.
>> Where is this project? Have you any plans to migrate the projects in git
>> (or even host on Github)?
>>
>> Best regards
>> Krzysztof
>>
>> On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>>> Hi Krzysztof,
>>>
>>> I invite you to read the GPL, APL, etc license content.
>>>
>>> My comments inline:
>>>
>>> On 01/10/2014 07:36 AM, Krzysztof Sobkowiak wrote:
>>>> Hi
>>>>
>>>> Thanks for answers. I need still some clarifications. I'll use some
>>>> samples
>>>>
>>>> On 10.01.2014 05:44, Jean-Baptiste Onofré wrote:
>>>>> Hi
>>>>>
>>>>> It's a difference between inclusion, usage, and reference.
>>>>>
>>>>> For instance, GPL license is a intrusive license. It means that any
>>>>> software that use a code under GPL has to be itself under the GPL
>>>>> license. That's why you can't use GPL in a Apache project. It's the
>>>>> case for usage, inclusion or reference.
>>>>> LGPL is a bit permissive in the cave of reference. LGPL is a Category
>>>>> X for inclusion and usage. It means that it's not possible to use
>>>>> LGPL
>>>>> if the project embeds some jar under LGPL, or ship some code (like
>>>>> copy/paste) under LGPL. However, if you just reference the project
>>>>> without embedding it, and it's an user action to actually download
>>>>> and
>>>>> add the LGPL jar, it's fine.
>>>> I don't know if I have understood it correctly. I can reference
>>>> Hibernate libraries in Karaf feature (e.g. because it is referenced by
>>>> other library which is also included in Karaf feature ans uses the
>>>> code
>>>> from Hibernate or because we need Hibernate as JPA provider) . But
>>>> I can
>>>> not implement any sample with Karaf which shows, how to use Spring
>>>> with
>>>> plain Hibernate, because the Hibernate code (e.g. SessionFactory)
>>>> would
>>>> be referenced in this code. But I can implement such a sample outside
>>>> Karaf (probably under another license, which? LGPL?) and eventually
>>>> reference the sample somewhere in the Karaf feature like the Hibernate
>>>> libraries?
>>>
>>> Correct. That's why we have karaf-extra (like camel-extra,
>>> servicemix-extra) to store such code/sample outside Apache codebase.
>>>
>>>>
>>>>> Regarding your question:
>>>>> 1/ category A
>>>>> 2/ category A
>>>>> 3/ category A and B
>>>>> 4/ category A and B (and we have to "publish" the changes)
>>>>
>>>> Does it mean I can copy some code (e.g. classes) from category B
>>>> library
>>>> into Apache licensed project, eventually change the code, and and ship
>>>> it as part of this project (usage 3 and 4) but I can not reference the
>>>> category B libraries as maven dependencies and use the classes from
>>>> the
>>>> dependencies in Apache licensed project (usage 1 and 2)?
>>>
>>> Not really, it depends in the license. Basically, all code in Apache
>>> project should be under Apache license. Again, we can add it in
>>> karaf-extra.
>>>
>>>>
>>>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>>>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>>>> (reference AspectJ as maven dependency and use the classes in my
>>>> code).
>>>> Does it mean, my code can not be included in Apache licensed project,
>>>> but I can implement the hook in a project under other license and
>>>> eventually reference it in Karaf feature?
>>>
>>> Correct, you can't include in Apache project. You can create your
>>> project outside of Apache project and reference it. Same as before:
>>> you can do your WeavingHook in karaf-extra.
>>>
>>> Regards
>>> JB
>>>
>>>>
>>>> Best regards
>>>> Krzysztof
>>>>
>>>>> 5/ all
>>>>> 6/ category A and B
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
>>>>>> Hi
>>>>>>
>>>>>> I have some licensing questions.
>>>>>>
>>>>>> I have found following page http://www.apache.org/legal/3party.html
>>>>>> which defines 3 categories of third party licenses. According to
>>>>>> this
>>>>>> page LGPL v2.1 is category X, but further remark says, the
>>>>>> LGPL-v2.1-licensed work can be listed as system requirements but
>>>>>> can not
>>>>>> be included by Apache products. I'm not good in licensing but I
>>>>>> try to
>>>>>> understand it. Is the category of LGPL really B (and the page
>>>>>> should be
>>>>>> corrected) or is the LGP category X. In the second case, can we
>>>>>> still
>>>>>> list Hibernate in Karaf features (e.g. using the remark about
>>>>>> listing of
>>>>>> system requirements)?
>>>>>>
>>>>>> Assume following use cases of third-party work usage:
>>>>>> 1. reference 3rd-party library as (maven) dependency and use the
>>>>>> classes
>>>>>> in ASF code
>>>>>> 2. reference 3rd-party library as (maven) dependency and use the
>>>>>> classes
>>>>>> only in ASF configuration files (e.g. blueprint.xml)
>>>>>> 3. include/copy some unmodified 3rd-party code (e.g. some
>>>>>> classes) in
>>>>>> ASF project
>>>>>> 4. include/copy some 3rd-party code (e.g. some classes) in ASF
>>>>>> project
>>>>>> and modify it
>>>>>> 5. list some 3rd-party libraries in Karaf features, but not include
>>>>>> them
>>>>>> as binaries in one of the Karaf distributions
>>>>>> 6. list some 3rd-party libraries in Karaf features, and include
>>>>>> them as
>>>>>> binaries in one of the Karaf distributions in system repository
>>>>>>
>>>>>> Could anybody please answer which of above points are allowed for
>>>>>> following 3rd-party works
>>>>>> a. category A as the whole category - I assume, all above use cases
>>>>>> are
>>>>>> allowed in this category, is it ok?
>>>>>> b. category B as the whole category
>>>>>> c. category X as the whole category
>>>>>> d. LGPL
>>>>>> e. GPL
>>>>>> f. EPL
>>>>>>
>>>>>> I have chosen Karaf as sample ASF project, but it could be any
>>>>>> other ASF
>>>>>> project, e.g. ServiceMix or Aries
>>>>>>
>>>>>> Do the rules from the page mentioned above apply only for ASF
>>>>>> projects
>>>>>> or for any project licensed under Apache License?
>>>>>>
>>>>>> Best regards
>>>>>> Krzysztof
>>>>
>>>>
>>>> --
>>>> Krzysztof Sobkowiak
>>>>
>>>> JEE & OSS Architect | Technical Architect @ Capgemini
>>>> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
>>>> <http://www.pl.capgemini-sdm.com/> | Wroclaw
>>>> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>>>> Twitter: @KSobkowiak
>>>
>>
>>
>> --
>> Krzysztof Sobkowiak
>>
>> JEE & OSS Architect | Technical Architect @ Capgemini
>> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
>> <http://www.pl.capgemini-sdm.com/> | Wroclaw
>> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>> Twitter: @KSobkowiak
>
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: Third-Party Licensing Policy
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I didn't create the karaf-extra project yet as we didn't have the need.
I will create it when we need some extra/contrib.
When you said "any plans to migrate the projects", you mean Karaf projects ?
Regards
JB
On 01/10/2014 08:21 AM, Krzysztof Sobkowiak wrote:
> Ok thanks a lot, it clarified me my questions. The license content use
> juridical language. I don't understand it always. I could find
> camel-extra and servicemix-extra projects. But I can't find karaf-extra.
> Where is this project? Have you any plans to migrate the projects in git
> (or even host on Github)?
>
> Best regards
> Krzysztof
>
> On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
>> Hi Krzysztof,
>>
>> I invite you to read the GPL, APL, etc license content.
>>
>> My comments inline:
>>
>> On 01/10/2014 07:36 AM, Krzysztof Sobkowiak wrote:
>>> Hi
>>>
>>> Thanks for answers. I need still some clarifications. I'll use some
>>> samples
>>>
>>> On 10.01.2014 05:44, Jean-Baptiste Onofré wrote:
>>>> Hi
>>>>
>>>> It's a difference between inclusion, usage, and reference.
>>>>
>>>> For instance, GPL license is a intrusive license. It means that any
>>>> software that use a code under GPL has to be itself under the GPL
>>>> license. That's why you can't use GPL in a Apache project. It's the
>>>> case for usage, inclusion or reference.
>>>> LGPL is a bit permissive in the cave of reference. LGPL is a Category
>>>> X for inclusion and usage. It means that it's not possible to use LGPL
>>>> if the project embeds some jar under LGPL, or ship some code (like
>>>> copy/paste) under LGPL. However, if you just reference the project
>>>> without embedding it, and it's an user action to actually download and
>>>> add the LGPL jar, it's fine.
>>> I don't know if I have understood it correctly. I can reference
>>> Hibernate libraries in Karaf feature (e.g. because it is referenced by
>>> other library which is also included in Karaf feature ans uses the code
>>> from Hibernate or because we need Hibernate as JPA provider) . But I can
>>> not implement any sample with Karaf which shows, how to use Spring with
>>> plain Hibernate, because the Hibernate code (e.g. SessionFactory) would
>>> be referenced in this code. But I can implement such a sample outside
>>> Karaf (probably under another license, which? LGPL?) and eventually
>>> reference the sample somewhere in the Karaf feature like the Hibernate
>>> libraries?
>>
>> Correct. That's why we have karaf-extra (like camel-extra,
>> servicemix-extra) to store such code/sample outside Apache codebase.
>>
>>>
>>>> Regarding your question:
>>>> 1/ category A
>>>> 2/ category A
>>>> 3/ category A and B
>>>> 4/ category A and B (and we have to "publish" the changes)
>>>
>>> Does it mean I can copy some code (e.g. classes) from category B library
>>> into Apache licensed project, eventually change the code, and and ship
>>> it as part of this project (usage 3 and 4) but I can not reference the
>>> category B libraries as maven dependencies and use the classes from the
>>> dependencies in Apache licensed project (usage 1 and 2)?
>>
>> Not really, it depends in the license. Basically, all code in Apache
>> project should be under Apache license. Again, we can add it in
>> karaf-extra.
>>
>>>
>>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>>> (reference AspectJ as maven dependency and use the classes in my code).
>>> Does it mean, my code can not be included in Apache licensed project,
>>> but I can implement the hook in a project under other license and
>>> eventually reference it in Karaf feature?
>>
>> Correct, you can't include in Apache project. You can create your
>> project outside of Apache project and reference it. Same as before:
>> you can do your WeavingHook in karaf-extra.
>>
>> Regards
>> JB
>>
>>>
>>> Best regards
>>> Krzysztof
>>>
>>>> 5/ all
>>>> 6/ category A and B
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
>>>>> Hi
>>>>>
>>>>> I have some licensing questions.
>>>>>
>>>>> I have found following page http://www.apache.org/legal/3party.html
>>>>> which defines 3 categories of third party licenses. According to this
>>>>> page LGPL v2.1 is category X, but further remark says, the
>>>>> LGPL-v2.1-licensed work can be listed as system requirements but
>>>>> can not
>>>>> be included by Apache products. I'm not good in licensing but I
>>>>> try to
>>>>> understand it. Is the category of LGPL really B (and the page
>>>>> should be
>>>>> corrected) or is the LGP category X. In the second case, can we still
>>>>> list Hibernate in Karaf features (e.g. using the remark about
>>>>> listing of
>>>>> system requirements)?
>>>>>
>>>>> Assume following use cases of third-party work usage:
>>>>> 1. reference 3rd-party library as (maven) dependency and use the
>>>>> classes
>>>>> in ASF code
>>>>> 2. reference 3rd-party library as (maven) dependency and use the
>>>>> classes
>>>>> only in ASF configuration files (e.g. blueprint.xml)
>>>>> 3. include/copy some unmodified 3rd-party code (e.g. some classes) in
>>>>> ASF project
>>>>> 4. include/copy some 3rd-party code (e.g. some classes) in ASF project
>>>>> and modify it
>>>>> 5. list some 3rd-party libraries in Karaf features, but not include
>>>>> them
>>>>> as binaries in one of the Karaf distributions
>>>>> 6. list some 3rd-party libraries in Karaf features, and include
>>>>> them as
>>>>> binaries in one of the Karaf distributions in system repository
>>>>>
>>>>> Could anybody please answer which of above points are allowed for
>>>>> following 3rd-party works
>>>>> a. category A as the whole category - I assume, all above use cases
>>>>> are
>>>>> allowed in this category, is it ok?
>>>>> b. category B as the whole category
>>>>> c. category X as the whole category
>>>>> d. LGPL
>>>>> e. GPL
>>>>> f. EPL
>>>>>
>>>>> I have chosen Karaf as sample ASF project, but it could be any
>>>>> other ASF
>>>>> project, e.g. ServiceMix or Aries
>>>>>
>>>>> Do the rules from the page mentioned above apply only for ASF projects
>>>>> or for any project licensed under Apache License?
>>>>>
>>>>> Best regards
>>>>> Krzysztof
>>>
>>>
>>> --
>>> Krzysztof Sobkowiak
>>>
>>> JEE & OSS Architect | Technical Architect @ Capgemini
>>> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
>>> <http://www.pl.capgemini-sdm.com/> | Wroclaw
>>> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>>> Twitter: @KSobkowiak
>>
>
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Third-Party Licensing Policy
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Ok thanks a lot, it clarified me my questions. The license content use
juridical language. I don't understand it always. I could find
camel-extra and servicemix-extra projects. But I can't find karaf-extra.
Where is this project? Have you any plans to migrate the projects in git
(or even host on Github)?
Best regards
Krzysztof
On 10.01.2014 08:06, Jean-Baptiste Onofré wrote:
> Hi Krzysztof,
>
> I invite you to read the GPL, APL, etc license content.
>
> My comments inline:
>
> On 01/10/2014 07:36 AM, Krzysztof Sobkowiak wrote:
>> Hi
>>
>> Thanks for answers. I need still some clarifications. I'll use some
>> samples
>>
>> On 10.01.2014 05:44, Jean-Baptiste Onofré wrote:
>>> Hi
>>>
>>> It's a difference between inclusion, usage, and reference.
>>>
>>> For instance, GPL license is a intrusive license. It means that any
>>> software that use a code under GPL has to be itself under the GPL
>>> license. That's why you can't use GPL in a Apache project. It's the
>>> case for usage, inclusion or reference.
>>> LGPL is a bit permissive in the cave of reference. LGPL is a Category
>>> X for inclusion and usage. It means that it's not possible to use LGPL
>>> if the project embeds some jar under LGPL, or ship some code (like
>>> copy/paste) under LGPL. However, if you just reference the project
>>> without embedding it, and it's an user action to actually download and
>>> add the LGPL jar, it's fine.
>> I don't know if I have understood it correctly. I can reference
>> Hibernate libraries in Karaf feature (e.g. because it is referenced by
>> other library which is also included in Karaf feature ans uses the code
>> from Hibernate or because we need Hibernate as JPA provider) . But I can
>> not implement any sample with Karaf which shows, how to use Spring with
>> plain Hibernate, because the Hibernate code (e.g. SessionFactory) would
>> be referenced in this code. But I can implement such a sample outside
>> Karaf (probably under another license, which? LGPL?) and eventually
>> reference the sample somewhere in the Karaf feature like the Hibernate
>> libraries?
>
> Correct. That's why we have karaf-extra (like camel-extra,
> servicemix-extra) to store such code/sample outside Apache codebase.
>
>>
>>> Regarding your question:
>>> 1/ category A
>>> 2/ category A
>>> 3/ category A and B
>>> 4/ category A and B (and we have to "publish" the changes)
>>
>> Does it mean I can copy some code (e.g. classes) from category B library
>> into Apache licensed project, eventually change the code, and and ship
>> it as part of this project (usage 3 and 4) but I can not reference the
>> category B libraries as maven dependencies and use the classes from the
>> dependencies in Apache licensed project (usage 1 and 2)?
>
> Not really, it depends in the license. Basically, all code in Apache
> project should be under Apache license. Again, we can add it in
> karaf-extra.
>
>>
>> I use an example again - AspectJ is licensed under EPL 1.0 license.
>> Assume I'd like to implement a WeavingHook using the AspectJ classes
>> (reference AspectJ as maven dependency and use the classes in my code).
>> Does it mean, my code can not be included in Apache licensed project,
>> but I can implement the hook in a project under other license and
>> eventually reference it in Karaf feature?
>
> Correct, you can't include in Apache project. You can create your
> project outside of Apache project and reference it. Same as before:
> you can do your WeavingHook in karaf-extra.
>
> Regards
> JB
>
>>
>> Best regards
>> Krzysztof
>>
>>> 5/ all
>>> 6/ category A and B
>>>
>>> Regards
>>> JB
>>>
>>> On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
>>>> Hi
>>>>
>>>> I have some licensing questions.
>>>>
>>>> I have found following page http://www.apache.org/legal/3party.html
>>>> which defines 3 categories of third party licenses. According to this
>>>> page LGPL v2.1 is category X, but further remark says, the
>>>> LGPL-v2.1-licensed work can be listed as system requirements but
>>>> can not
>>>> be included by Apache products. I'm not good in licensing but I
>>>> try to
>>>> understand it. Is the category of LGPL really B (and the page
>>>> should be
>>>> corrected) or is the LGP category X. In the second case, can we still
>>>> list Hibernate in Karaf features (e.g. using the remark about
>>>> listing of
>>>> system requirements)?
>>>>
>>>> Assume following use cases of third-party work usage:
>>>> 1. reference 3rd-party library as (maven) dependency and use the
>>>> classes
>>>> in ASF code
>>>> 2. reference 3rd-party library as (maven) dependency and use the
>>>> classes
>>>> only in ASF configuration files (e.g. blueprint.xml)
>>>> 3. include/copy some unmodified 3rd-party code (e.g. some classes) in
>>>> ASF project
>>>> 4. include/copy some 3rd-party code (e.g. some classes) in ASF project
>>>> and modify it
>>>> 5. list some 3rd-party libraries in Karaf features, but not include
>>>> them
>>>> as binaries in one of the Karaf distributions
>>>> 6. list some 3rd-party libraries in Karaf features, and include
>>>> them as
>>>> binaries in one of the Karaf distributions in system repository
>>>>
>>>> Could anybody please answer which of above points are allowed for
>>>> following 3rd-party works
>>>> a. category A as the whole category - I assume, all above use cases
>>>> are
>>>> allowed in this category, is it ok?
>>>> b. category B as the whole category
>>>> c. category X as the whole category
>>>> d. LGPL
>>>> e. GPL
>>>> f. EPL
>>>>
>>>> I have chosen Karaf as sample ASF project, but it could be any
>>>> other ASF
>>>> project, e.g. ServiceMix or Aries
>>>>
>>>> Do the rules from the page mentioned above apply only for ASF projects
>>>> or for any project licensed under Apache License?
>>>>
>>>> Best regards
>>>> Krzysztof
>>
>>
>> --
>> Krzysztof Sobkowiak
>>
>> JEE & OSS Architect | Technical Architect @ Capgemini
>> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
>> <http://www.pl.capgemini-sdm.com/> | Wroclaw
>> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>> Twitter: @KSobkowiak
>
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: Third-Party Licensing Policy
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Krzysztof,
I invite you to read the GPL, APL, etc license content.
My comments inline:
On 01/10/2014 07:36 AM, Krzysztof Sobkowiak wrote:
> Hi
>
> Thanks for answers. I need still some clarifications. I'll use some samples
>
> On 10.01.2014 05:44, Jean-Baptiste Onofré wrote:
>> Hi
>>
>> It's a difference between inclusion, usage, and reference.
>>
>> For instance, GPL license is a intrusive license. It means that any
>> software that use a code under GPL has to be itself under the GPL
>> license. That's why you can't use GPL in a Apache project. It's the
>> case for usage, inclusion or reference.
>> LGPL is a bit permissive in the cave of reference. LGPL is a Category
>> X for inclusion and usage. It means that it's not possible to use LGPL
>> if the project embeds some jar under LGPL, or ship some code (like
>> copy/paste) under LGPL. However, if you just reference the project
>> without embedding it, and it's an user action to actually download and
>> add the LGPL jar, it's fine.
> I don't know if I have understood it correctly. I can reference
> Hibernate libraries in Karaf feature (e.g. because it is referenced by
> other library which is also included in Karaf feature ans uses the code
> from Hibernate or because we need Hibernate as JPA provider) . But I can
> not implement any sample with Karaf which shows, how to use Spring with
> plain Hibernate, because the Hibernate code (e.g. SessionFactory) would
> be referenced in this code. But I can implement such a sample outside
> Karaf (probably under another license, which? LGPL?) and eventually
> reference the sample somewhere in the Karaf feature like the Hibernate
> libraries?
Correct. That's why we have karaf-extra (like camel-extra,
servicemix-extra) to store such code/sample outside Apache codebase.
>
>> Regarding your question:
>> 1/ category A
>> 2/ category A
>> 3/ category A and B
>> 4/ category A and B (and we have to "publish" the changes)
>
> Does it mean I can copy some code (e.g. classes) from category B library
> into Apache licensed project, eventually change the code, and and ship
> it as part of this project (usage 3 and 4) but I can not reference the
> category B libraries as maven dependencies and use the classes from the
> dependencies in Apache licensed project (usage 1 and 2)?
Not really, it depends in the license. Basically, all code in Apache
project should be under Apache license. Again, we can add it in karaf-extra.
>
> I use an example again - AspectJ is licensed under EPL 1.0 license.
> Assume I'd like to implement a WeavingHook using the AspectJ classes
> (reference AspectJ as maven dependency and use the classes in my code).
> Does it mean, my code can not be included in Apache licensed project,
> but I can implement the hook in a project under other license and
> eventually reference it in Karaf feature?
Correct, you can't include in Apache project. You can create your
project outside of Apache project and reference it. Same as before: you
can do your WeavingHook in karaf-extra.
Regards
JB
>
> Best regards
> Krzysztof
>
>> 5/ all
>> 6/ category A and B
>>
>> Regards
>> JB
>>
>> On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
>>> Hi
>>>
>>> I have some licensing questions.
>>>
>>> I have found following page http://www.apache.org/legal/3party.html
>>> which defines 3 categories of third party licenses. According to this
>>> page LGPL v2.1 is category X, but further remark says, the
>>> LGPL-v2.1-licensed work can be listed as system requirements but can not
>>> be included by Apache products. I'm not good in licensing but I try to
>>> understand it. Is the category of LGPL really B (and the page should be
>>> corrected) or is the LGP category X. In the second case, can we still
>>> list Hibernate in Karaf features (e.g. using the remark about listing of
>>> system requirements)?
>>>
>>> Assume following use cases of third-party work usage:
>>> 1. reference 3rd-party library as (maven) dependency and use the classes
>>> in ASF code
>>> 2. reference 3rd-party library as (maven) dependency and use the classes
>>> only in ASF configuration files (e.g. blueprint.xml)
>>> 3. include/copy some unmodified 3rd-party code (e.g. some classes) in
>>> ASF project
>>> 4. include/copy some 3rd-party code (e.g. some classes) in ASF project
>>> and modify it
>>> 5. list some 3rd-party libraries in Karaf features, but not include them
>>> as binaries in one of the Karaf distributions
>>> 6. list some 3rd-party libraries in Karaf features, and include them as
>>> binaries in one of the Karaf distributions in system repository
>>>
>>> Could anybody please answer which of above points are allowed for
>>> following 3rd-party works
>>> a. category A as the whole category - I assume, all above use cases are
>>> allowed in this category, is it ok?
>>> b. category B as the whole category
>>> c. category X as the whole category
>>> d. LGPL
>>> e. GPL
>>> f. EPL
>>>
>>> I have chosen Karaf as sample ASF project, but it could be any other ASF
>>> project, e.g. ServiceMix or Aries
>>>
>>> Do the rules from the page mentioned above apply only for ASF projects
>>> or for any project licensed under Apache License?
>>>
>>> Best regards
>>> Krzysztof
>
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Third-Party Licensing Policy
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi
Thanks for answers. I need still some clarifications. I'll use some samples
On 10.01.2014 05:44, Jean-Baptiste Onofré wrote:
> Hi
>
> It's a difference between inclusion, usage, and reference.
>
> For instance, GPL license is a intrusive license. It means that any
> software that use a code under GPL has to be itself under the GPL
> license. That's why you can't use GPL in a Apache project. It's the
> case for usage, inclusion or reference.
> LGPL is a bit permissive in the cave of reference. LGPL is a Category
> X for inclusion and usage. It means that it's not possible to use LGPL
> if the project embeds some jar under LGPL, or ship some code (like
> copy/paste) under LGPL. However, if you just reference the project
> without embedding it, and it's an user action to actually download and
> add the LGPL jar, it's fine.
I don't know if I have understood it correctly. I can reference
Hibernate libraries in Karaf feature (e.g. because it is referenced by
other library which is also included in Karaf feature ans uses the code
from Hibernate or because we need Hibernate as JPA provider) . But I can
not implement any sample with Karaf which shows, how to use Spring with
plain Hibernate, because the Hibernate code (e.g. SessionFactory) would
be referenced in this code. But I can implement such a sample outside
Karaf (probably under another license, which? LGPL?) and eventually
reference the sample somewhere in the Karaf feature like the Hibernate
libraries?
> Regarding your question:
> 1/ category A
> 2/ category A
> 3/ category A and B
> 4/ category A and B (and we have to "publish" the changes)
Does it mean I can copy some code (e.g. classes) from category B library
into Apache licensed project, eventually change the code, and and ship
it as part of this project (usage 3 and 4) but I can not reference the
category B libraries as maven dependencies and use the classes from the
dependencies in Apache licensed project (usage 1 and 2)?
I use an example again - AspectJ is licensed under EPL 1.0 license.
Assume I'd like to implement a WeavingHook using the AspectJ classes
(reference AspectJ as maven dependency and use the classes in my code).
Does it mean, my code can not be included in Apache licensed project,
but I can implement the hook in a project under other license and
eventually reference it in Karaf feature?
Best regards
Krzysztof
> 5/ all
> 6/ category A and B
>
> Regards
> JB
>
> On 01/09/2014 11:35 PM, Krzysztof Sobkowiak wrote:
>> Hi
>>
>> I have some licensing questions.
>>
>> I have found following page http://www.apache.org/legal/3party.html
>> which defines 3 categories of third party licenses. According to this
>> page LGPL v2.1 is category X, but further remark says, the
>> LGPL-v2.1-licensed work can be listed as system requirements but can not
>> be included by Apache products. I'm not good in licensing but I try to
>> understand it. Is the category of LGPL really B (and the page should be
>> corrected) or is the LGP category X. In the second case, can we still
>> list Hibernate in Karaf features (e.g. using the remark about listing of
>> system requirements)?
>>
>> Assume following use cases of third-party work usage:
>> 1. reference 3rd-party library as (maven) dependency and use the classes
>> in ASF code
>> 2. reference 3rd-party library as (maven) dependency and use the classes
>> only in ASF configuration files (e.g. blueprint.xml)
>> 3. include/copy some unmodified 3rd-party code (e.g. some classes) in
>> ASF project
>> 4. include/copy some 3rd-party code (e.g. some classes) in ASF project
>> and modify it
>> 5. list some 3rd-party libraries in Karaf features, but not include them
>> as binaries in one of the Karaf distributions
>> 6. list some 3rd-party libraries in Karaf features, and include them as
>> binaries in one of the Karaf distributions in system repository
>>
>> Could anybody please answer which of above points are allowed for
>> following 3rd-party works
>> a. category A as the whole category - I assume, all above use cases are
>> allowed in this category, is it ok?
>> b. category B as the whole category
>> c. category X as the whole category
>> d. LGPL
>> e. GPL
>> f. EPL
>>
>> I have chosen Karaf as sample ASF project, but it could be any other ASF
>> project, e.g. ServiceMix or Aries
>>
>> Do the rules from the page mentioned above apply only for ASF projects
>> or for any project licensed under Apache License?
>>
>> Best regards
>> Krzysztof
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak