You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Grzegorz Słowikowski <gs...@gmail.com> on 2016/06/29 18:30:27 UTC
Maven plugin - some licensing questions
Hi guys.
Answer my questions or tell me the right list to ask them, please.
I'm developing some Maven plugins. All have ASLv2 licenses.
My questions are:
1. Can I include slightly modified class from Maven code in one of my
plugins? How should I note this fact?
2. Can I include classes from other project with ASLv2 license (Play!
Framework)?
3. Slightly more complicated case. I'm porting source files watching
mechanism from Play! Framework SBT plugin to my Maven plugin.
I have an API module and some implementations: JDK6, JNotify, polling.
Implementation can be selected or chosen automatically based on Java
version and OS (Maven artifact resolved dynamically).
In Play! Framework, if Java is 1.7+, default implementation is
- JNotify for OSX
- JDK7 for other systems
JNotify uses different licenses: GNU LGPL 2.1 + EPL
Can, from legal PoV, JNotify implementation be used automatically
(without user configuration) in any case (OSX here)?
Can it be used, if it requires user configuration (in pom.xml or command
line parameter)?
Regards
Grzegorz Slowikowski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven plugin - some licensing questions
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 1 July 2016 at 12:54, Grzegorz Słowikowski <gs...@gmail.com> wrote:
> I have some more technical questions.
I'll let the actual Maven developers chip in on those :)
> My second questions is how and where should I describe my modifications?
> Do I need to provide somehow the original source of modified class?
So in this case it's easy, it just needs to "carry prominent notices
stating that You changed the files".
The top of the file says:
/*
* Licensed to the Apache Software Foundation (ASF) under one
(..)
* specific language governing permissions and limitations
* under the License.
*/
Simply add right below:
/*
* This file was adapted from Apache Maven Embedder
* https://github.com/apache/maven/blob/maven-3.3.5/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java
* and modified by XXX Inc.
* to use org.apache.maven.plugin.logging.Log
* instead of org.slf4j.Logger
*/
Note that legally you don't have to say WHAT you have changed, but of
course that's good engineering practice as otherwise you wouldn't know
why this file was modified at all. :)
I would include the exact tag/commit id and repository of where it
came from - this will make it easier if you come back later to compare
with a newer ExecutionEventLogger from Maven.
> When using (not modified) classes from another ASLv2 project do I need
> to create NOTICE file (I've had no NOTICE file before) in the root
> directory of my repository containing:
No, you do not NEED to create a NOTICE file if none exists already in
any of the sources you have redistributed.
In a way not having a NOTICE file is good for the user as then they
don't need to propagate it; it's almost like a "Public domain under
ASF" option.
But in your case I think you are including code from Apache Maven,
which HAS a NOTICE file, in which case you would want to propagate it.
However you need to insert your stuff to the top, as your new thing is
not "Apache Maven". :)
> This product includes software developed at
> XXX Inc. <https://www.xxx.com>,
> which is licensed under the Apache 2 license.
>
> Is this note OK?
I would keep your private NOTICE in a similar format to the Apache
style, e.g. for a product Foo Bar:
Foo Bar
Copyright 2015-2016 XXX Inc.
This product includes software developed at
XXX Inc. <https://www.xxx.com>.
And then as you have included your Apache Maven files, in the same
NOTICE file also add BELOW:
---------
foo-module-x/src/main/java/com/example/ExecutionEventLogger.java
Apache Maven
Copyright 2001-2015 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
--------
(and similar for any other files from other AL2 sources that also have
a NOTICE).
You have to propagate the NOTICE content verbatim - except if it
doesn't apply to what you copy. (E.g. if someone copies from you now,
but don't copy your modified ExecutionEventLogger.java, then they
don't need to propagate those separate Maven NOTICE lines, but would
have to propagate the Foo Bar lines.)
Because of this, for Apache projects we try to keep our NOTICEs slim -
so don't add stuff there that you don't need to.
> Additionally, identical NOTICE file should be added to
> /src/main/resources/META-INF directory of every module using external
> classes, right?
Yes, that would be very good practice - however you should only NEED
to do this if you are going to distribute the compiled JARs separate
from your source code (which would also have the top level NOTICE).
Publishing to Maven Central could be seen as such a distribution - but
if you just provide your JARs within say a ZIP file, then you can just
put the NOTICE (and LICENSE) file in that ZIP file.
> I will ask next questions on legal-discuss@apache.org. Thank you in
> advance. Regards.
You seem to have got a great understanding of this already - but that
would probably be the best place for more generic Apache license and
attribution questions :-)
And thank you for following open source licensing seriously! :-)
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven plugin - some licensing questions
Posted by Mark Derricutt <ma...@talios.com>.
When I was writing my LifecycleExtension recently I hit this same issue,
with the two different logger classes depending on where my common code was
being called from.
I just changed my base code to accept a Consumer<String> and passed in
getLog()::info and the relevant other method from the other logger as
method references. Worked a charm in my small use case anyway.
On Sat, Jul 2, 2016 at 12:35 AM, Grzegorz Słowikowski <
gslowikowski@gmail.com> wrote:
> I didn't want to depend on 'maven-embedder', so my first thought was to
> copy this class, change 'org.slf4j.Logger' class of the 'logger'
> variable to 'org.apache.maven.plugin.logging.Log', I have (in
> 'AbstractMojo')
>
> Advantage - I control the class
> Disadvantages - e.g. no colors in future Maven versions (because using
> class from Maven not supporting colors yet), licensing questions
>
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: Maven plugin - some licensing questions
Posted by Grzegorz Słowikowski <gs...@gmail.com>.
Hi Karl
On 2016-07-01 14:09, Karl Heinz Marbaise wrote:
> Hi,
>
> On 7/1/16 1:54 PM, Grzegorz S\u0142owikowski wrote:
>> Thank you very much Stian.
>>
>> I have some more technical questions.
>>
>> 1.
>>
>> When I wrote about using modified class from Maven core I thought about
>> ExecutionEventLogger class from maven-embedder
>> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java)
>>
>
>>
>> I wanted to change Logger interface
>> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java#L50)
>>
>> and use org.apache.maven.plugin.logging.Log available in Maven plugins.
>
> This means you changing the interface which means your version of Maven
> is not compatible with the Apache Maven ?
No
>
>>
>> Now I'm testing another approach. I've added provided dependency on
>> maven-embedder and use original class. Minimal Maven version is set to
>> 3.1.0 in prerequisities of my plugin.
>>
>> My first question is, can I expect ExecutionEventLogger to be stable API
>> in future releases?
>
>
> What I don't understand is why you need to change such interface? May be
> you can describe your exact problems (here on the list) or better into a
> JIRA ticket and may be the Maven project can help or change things there
> if it makes sense...Or your provide a patch (as already mentioned) to
> solve your problem ?
>
> Otherwise you start to creating a Maven which is not compatible with
> Apache Maven which will confuse people and will produce many problems...
>
I didn't write it before, I'm implementing mojo running the application
(Play! Framework), watching source changes and rebuilding projects, all
this while application is still running. Play! Framework supports this.
They use SBT and I'm reimplementing this functionality in Maven.
To run Maven build, I create 'MavenExecutionRequest', new
'MavenSession', etc. and execute this session using 'LifecycleExecutor'.
To see build progress, I need 'ExecutionListener' (see
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java#L376)
There is one implementation available in maven-embedder
https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java
I didn't want to depend on 'maven-embedder', so my first thought was to
copy this class, change 'org.slf4j.Logger' class of the 'logger'
variable to 'org.apache.maven.plugin.logging.Log', I have (in
'AbstractMojo')
Advantage - I control the class
Disadvantages - e.g. no colors in future Maven versions (because using
class from Maven not supporting colors yet), licensing questions
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>>
>> My second questions is how and where should I describe my modifications?
>> Do I need to provide somehow the original source of modified class?
>>
>> 2.
>>
>> When using (not modified) classes from another ASLv2 project do I need
>> to create NOTICE file (I've had no NOTICE file before) in the root
>> directory of my repository containing:
>>
>> This product includes software developed at
>> XXX Inc. <https://www.xxx.com>,
>> which is licensed under the Apache 2 license.
>>
>> Is this note OK?
>>
>> Additionally, identical NOTICE file should be added to
>> /src/main/resources/META-INF directory of every module using external
>> classes, right?
>>
>>
>> I will ask next questions on legal-discuss@apache.org. Thank you in
>> advance. Regards.
>>
>> Grzegorz Slowikowski
>>
>>
>> On 2016-06-30 12:24, Stian Soiland-Reyes wrote:
>>> This would be more a question for legal-discuss@apache.org, but I'll
>>> try to respond anyway :). Sorry for the long answer.. Please correct
>>> me!
>>>
>>> On 29 June 2016 at 19:30, Grzegorz S\u0142owikowski
>>> <gs...@gmail.com> wrote:
>>>> 1. Can I include slightly modified class from Maven code in one of my
>>>> plugins? How should I note this fact?
>>>
>>> Of course - that's explicitly permitted as long as you follow the
>>> Apache License clause 5
>>>
>>> https://www.apache.org/licenses/LICENSE-2.0.html#redistribution
>>>
>>>
>>> You should note it by keeping the license header in the files, and by
>>> propagating the content of the NOTICE from the Maven code, e.g. from
>>>
>>> https://github.com/apache/maven/blob/master/NOTICE
>>>
>>> if the code you are modifying is from the main Maven code. (Note that
>>> most plugins have their own repositories with slightly different
>>> NOTICE files)
>>>
>>> Remember:
>>>
>>>> You must cause any modified files to carry prominent notices stating
>>>> that You changed the files; and
>>>
>>> So if you modify a file, then append to the existing license header
>>> what you have changed.
>>>
>>>
>>>
>>> You will probably want to add your own (c) as well to the new NOTICE.
>>>
>>> Note that Apache trademarks mean you can't call your derived product
>>> for "Apache Maven", however you may want to say "partially based on
>>> Apache Maven" if that is true.
>>>
>>>
>>>
>>> You should still reconsider if you really NEED to do your own
>>> modifications - perhaps the modifications can be provided to us
>>> upstream instead in order for you to do subclassing or use the Maven
>>> classes as they are? This would remove your need in the future to
>>> "keep track" with Apache Maven development.
>>>
>>>
>>>> 2. Can I include classes from other project with ASLv2 license (Play!
>>>> Framework)?
>>>
>>> You can mix and match source code from any compatible license, as long
>>> as you keep their license headers and NOTICE content, and provide the
>>> Apache license with your work.
>>>
>>> You are not required to license your own derived work under the Apache
>>> license (e.g. you could license it as GPL 3.0 or a commercial license
>>> instead), but in most cases keeping it as Apache License 2.0 makes
>>> things easier :)
>>>
>>> Note that while software from ASF always ensures that there is a
>>> NOTICE file and /** Apache **/ license header, not all open source
>>> software under the Apache License do this (it's not a requirement).
>>> You should still append a license header saying which files you have
>>> modified, if you need to.
>>>
>>> You may want to keep note in your new NOTICE what files came from where.
>>>
>>>> JNotify uses different licenses: GNU LGPL 2.1 + EPL
>>>> Can, from legal PoV, JNotify implementation be used automatically
>>>> (without user configuration) in any case (OSX here)?
>>>
>>> Yes, there is no legal reason why you can't use Apache licensed
>>> software with LGPL or EPL. You will have to respect LGPL or EPL
>>> separately for those parts - you can't distribute those as if they are
>>> Apache License. This is normally easily achieved by your software
>>> downloading their JARs separately using normal Maven <dependency>
>>> mechanisms.
>>>
>>> Note that LGPL contains a clause that requires downstream users to be
>>> get the source for, modify, debug and replace the LGPL part. The code
>>> that uses LGPL can be under any license as long (and even just a
>>> binary) as it does not restrict those possibilities.
>>>
>>> This is normally quite easy to achieve by keeping the LGPL dep as a
>>> separate JAR - but this is a restrictions of the "freedoms" of the
>>> Apache License, e.g. you are allowed to take your modified Apache
>>> Maven source code and burn it into a ROM within a hardware component,
>>> without having to provide the source code or a mechanism for
>>> downstream users to modify it.
>>>
>>> LGPL on the other hand protects the "freedom of the source" - you
>>> can't deny your downstream users the source code of the LGPL bit and
>>> the freedom to modify that. And so your "closed" or "other" bit can't
>>> do things like "Ensure that jnotify.jar has the correct checksum".
>>>
>>> Because of these complications it is an Apache Software Foundation
>>> policy to not allow LGPL dependencies [1] in software contributed to
>>> the ASF because we want all our software to be usable by the Apache
>>> LIcense alone (or by licenses which don't permit less than AL2).
>>> (Truly <optional> LGPL dependencies are allowed as long as the Apache
>>> software still works without that).
>>>
>>> A EPL-licensed dependency is however easier [2] as long as the EPL
>>> dependency is kept as a binary and not mixed into the source code.
>>>
>>> I must say JNotify is confusing with its two licenses, is it a
>>> dual-license where you can choose, or do you have to comply with both
>>> licenses? Make sure your own README and LICENSE makes clear what is
>>> the case for your end produxct.
>>>
>>>
>>> If you are not considering contributing your work to the Apache
>>> Software Foundation (why wouldn't you? :) - then you are not required
>>> to follow ASF policies. You only need to follow the Apache License
>>> terms for the source code that is covered by that license.
>>>
>>>
>>>
>>> [1] https://www.apache.org/legal/resolved#category-x
>>> [2] https://www.apache.org/legal/resolved#category-b
>>>
>>>> Can it be used, if it requires user configuration (in pom.xml or
>>>> command
>>>> line parameter)?
>>>>
>>>> Regards
>>>> Grzegorz Slowikowski
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven plugin - some licensing questions
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 7/1/16 1:54 PM, Grzegorz S\u0142owikowski wrote:
> Thank you very much Stian.
>
> I have some more technical questions.
>
> 1.
>
> When I wrote about using modified class from Maven core I thought about
> ExecutionEventLogger class from maven-embedder
> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java)
>
> I wanted to change Logger interface
> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java#L50)
> and use org.apache.maven.plugin.logging.Log available in Maven plugins.
This means you changing the interface which means your version of Maven
is not compatible with the Apache Maven ?
>
> Now I'm testing another approach. I've added provided dependency on
> maven-embedder and use original class. Minimal Maven version is set to
> 3.1.0 in prerequisities of my plugin.
>
> My first question is, can I expect ExecutionEventLogger to be stable API
> in future releases?
What I don't understand is why you need to change such interface? May be
you can describe your exact problems (here on the list) or better into a
JIRA ticket and may be the Maven project can help or change things there
if it makes sense...Or your provide a patch (as already mentioned) to
solve your problem ?
Otherwise you start to creating a Maven which is not compatible with
Apache Maven which will confuse people and will produce many problems...
Kind regards
Karl Heinz Marbaise
>
> My second questions is how and where should I describe my modifications?
> Do I need to provide somehow the original source of modified class?
>
> 2.
>
> When using (not modified) classes from another ASLv2 project do I need
> to create NOTICE file (I've had no NOTICE file before) in the root
> directory of my repository containing:
>
> This product includes software developed at
> XXX Inc. <https://www.xxx.com>,
> which is licensed under the Apache 2 license.
>
> Is this note OK?
>
> Additionally, identical NOTICE file should be added to
> /src/main/resources/META-INF directory of every module using external
> classes, right?
>
>
> I will ask next questions on legal-discuss@apache.org. Thank you in
> advance. Regards.
>
> Grzegorz Slowikowski
>
>
> On 2016-06-30 12:24, Stian Soiland-Reyes wrote:
>> This would be more a question for legal-discuss@apache.org, but I'll
>> try to respond anyway :). Sorry for the long answer.. Please correct
>> me!
>>
>> On 29 June 2016 at 19:30, Grzegorz S\u0142owikowski <gs...@gmail.com> wrote:
>>> 1. Can I include slightly modified class from Maven code in one of my
>>> plugins? How should I note this fact?
>>
>> Of course - that's explicitly permitted as long as you follow the
>> Apache License clause 5
>>
>> https://www.apache.org/licenses/LICENSE-2.0.html#redistribution
>>
>>
>> You should note it by keeping the license header in the files, and by
>> propagating the content of the NOTICE from the Maven code, e.g. from
>>
>> https://github.com/apache/maven/blob/master/NOTICE
>>
>> if the code you are modifying is from the main Maven code. (Note that
>> most plugins have their own repositories with slightly different
>> NOTICE files)
>>
>> Remember:
>>
>>> You must cause any modified files to carry prominent notices stating that You changed the files; and
>>
>> So if you modify a file, then append to the existing license header
>> what you have changed.
>>
>>
>>
>> You will probably want to add your own (c) as well to the new NOTICE.
>>
>> Note that Apache trademarks mean you can't call your derived product
>> for "Apache Maven", however you may want to say "partially based on
>> Apache Maven" if that is true.
>>
>>
>>
>> You should still reconsider if you really NEED to do your own
>> modifications - perhaps the modifications can be provided to us
>> upstream instead in order for you to do subclassing or use the Maven
>> classes as they are? This would remove your need in the future to
>> "keep track" with Apache Maven development.
>>
>>
>>> 2. Can I include classes from other project with ASLv2 license (Play!
>>> Framework)?
>>
>> You can mix and match source code from any compatible license, as long
>> as you keep their license headers and NOTICE content, and provide the
>> Apache license with your work.
>>
>> You are not required to license your own derived work under the Apache
>> license (e.g. you could license it as GPL 3.0 or a commercial license
>> instead), but in most cases keeping it as Apache License 2.0 makes
>> things easier :)
>>
>> Note that while software from ASF always ensures that there is a
>> NOTICE file and /** Apache **/ license header, not all open source
>> software under the Apache License do this (it's not a requirement).
>> You should still append a license header saying which files you have
>> modified, if you need to.
>>
>> You may want to keep note in your new NOTICE what files came from where.
>>
>>> JNotify uses different licenses: GNU LGPL 2.1 + EPL
>>> Can, from legal PoV, JNotify implementation be used automatically
>>> (without user configuration) in any case (OSX here)?
>>
>> Yes, there is no legal reason why you can't use Apache licensed
>> software with LGPL or EPL. You will have to respect LGPL or EPL
>> separately for those parts - you can't distribute those as if they are
>> Apache License. This is normally easily achieved by your software
>> downloading their JARs separately using normal Maven <dependency>
>> mechanisms.
>>
>> Note that LGPL contains a clause that requires downstream users to be
>> get the source for, modify, debug and replace the LGPL part. The code
>> that uses LGPL can be under any license as long (and even just a
>> binary) as it does not restrict those possibilities.
>>
>> This is normally quite easy to achieve by keeping the LGPL dep as a
>> separate JAR - but this is a restrictions of the "freedoms" of the
>> Apache License, e.g. you are allowed to take your modified Apache
>> Maven source code and burn it into a ROM within a hardware component,
>> without having to provide the source code or a mechanism for
>> downstream users to modify it.
>>
>> LGPL on the other hand protects the "freedom of the source" - you
>> can't deny your downstream users the source code of the LGPL bit and
>> the freedom to modify that. And so your "closed" or "other" bit can't
>> do things like "Ensure that jnotify.jar has the correct checksum".
>>
>> Because of these complications it is an Apache Software Foundation
>> policy to not allow LGPL dependencies [1] in software contributed to
>> the ASF because we want all our software to be usable by the Apache
>> LIcense alone (or by licenses which don't permit less than AL2).
>> (Truly <optional> LGPL dependencies are allowed as long as the Apache
>> software still works without that).
>>
>> A EPL-licensed dependency is however easier [2] as long as the EPL
>> dependency is kept as a binary and not mixed into the source code.
>>
>> I must say JNotify is confusing with its two licenses, is it a
>> dual-license where you can choose, or do you have to comply with both
>> licenses? Make sure your own README and LICENSE makes clear what is
>> the case for your end produxct.
>>
>>
>> If you are not considering contributing your work to the Apache
>> Software Foundation (why wouldn't you? :) - then you are not required
>> to follow ASF policies. You only need to follow the Apache License
>> terms for the source code that is covered by that license.
>>
>>
>>
>> [1] https://www.apache.org/legal/resolved#category-x
>> [2] https://www.apache.org/legal/resolved#category-b
>>
>>> Can it be used, if it requires user configuration (in pom.xml or command
>>> line parameter)?
>>>
>>> Regards
>>> Grzegorz Slowikowski
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven plugin - some licensing questions
Posted by Grzegorz Słowikowski <gs...@gmail.com>.
Thank you very much Stian.
I have some more technical questions.
1.
When I wrote about using modified class from Maven core I thought about
ExecutionEventLogger class from maven-embedder
(https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java)
I wanted to change Logger interface
(https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java#L50)
and use org.apache.maven.plugin.logging.Log available in Maven plugins.
Now I'm testing another approach. I've added provided dependency on
maven-embedder and use original class. Minimal Maven version is set to
3.1.0 in prerequisities of my plugin.
My first question is, can I expect ExecutionEventLogger to be stable API
in future releases?
My second questions is how and where should I describe my modifications?
Do I need to provide somehow the original source of modified class?
2.
When using (not modified) classes from another ASLv2 project do I need
to create NOTICE file (I've had no NOTICE file before) in the root
directory of my repository containing:
This product includes software developed at
XXX Inc. <https://www.xxx.com>,
which is licensed under the Apache 2 license.
Is this note OK?
Additionally, identical NOTICE file should be added to
/src/main/resources/META-INF directory of every module using external
classes, right?
I will ask next questions on legal-discuss@apache.org. Thank you in
advance. Regards.
Grzegorz Slowikowski
On 2016-06-30 12:24, Stian Soiland-Reyes wrote:
> This would be more a question for legal-discuss@apache.org, but I'll
> try to respond anyway :). Sorry for the long answer.. Please correct
> me!
>
> On 29 June 2016 at 19:30, Grzegorz S\u0142owikowski <gs...@gmail.com> wrote:
>> 1. Can I include slightly modified class from Maven code in one of my
>> plugins? How should I note this fact?
>
> Of course - that's explicitly permitted as long as you follow the
> Apache License clause 5
>
> https://www.apache.org/licenses/LICENSE-2.0.html#redistribution
>
>
> You should note it by keeping the license header in the files, and by
> propagating the content of the NOTICE from the Maven code, e.g. from
>
> https://github.com/apache/maven/blob/master/NOTICE
>
> if the code you are modifying is from the main Maven code. (Note that
> most plugins have their own repositories with slightly different
> NOTICE files)
>
> Remember:
>
>> You must cause any modified files to carry prominent notices stating that You changed the files; and
>
> So if you modify a file, then append to the existing license header
> what you have changed.
>
>
>
> You will probably want to add your own (c) as well to the new NOTICE.
>
> Note that Apache trademarks mean you can't call your derived product
> for "Apache Maven", however you may want to say "partially based on
> Apache Maven" if that is true.
>
>
>
> You should still reconsider if you really NEED to do your own
> modifications - perhaps the modifications can be provided to us
> upstream instead in order for you to do subclassing or use the Maven
> classes as they are? This would remove your need in the future to
> "keep track" with Apache Maven development.
>
>
>> 2. Can I include classes from other project with ASLv2 license (Play!
>> Framework)?
>
> You can mix and match source code from any compatible license, as long
> as you keep their license headers and NOTICE content, and provide the
> Apache license with your work.
>
> You are not required to license your own derived work under the Apache
> license (e.g. you could license it as GPL 3.0 or a commercial license
> instead), but in most cases keeping it as Apache License 2.0 makes
> things easier :)
>
> Note that while software from ASF always ensures that there is a
> NOTICE file and /** Apache **/ license header, not all open source
> software under the Apache License do this (it's not a requirement).
> You should still append a license header saying which files you have
> modified, if you need to.
>
> You may want to keep note in your new NOTICE what files came from where.
>
>> JNotify uses different licenses: GNU LGPL 2.1 + EPL
>> Can, from legal PoV, JNotify implementation be used automatically
>> (without user configuration) in any case (OSX here)?
>
> Yes, there is no legal reason why you can't use Apache licensed
> software with LGPL or EPL. You will have to respect LGPL or EPL
> separately for those parts - you can't distribute those as if they are
> Apache License. This is normally easily achieved by your software
> downloading their JARs separately using normal Maven <dependency>
> mechanisms.
>
> Note that LGPL contains a clause that requires downstream users to be
> get the source for, modify, debug and replace the LGPL part. The code
> that uses LGPL can be under any license as long (and even just a
> binary) as it does not restrict those possibilities.
>
> This is normally quite easy to achieve by keeping the LGPL dep as a
> separate JAR - but this is a restrictions of the "freedoms" of the
> Apache License, e.g. you are allowed to take your modified Apache
> Maven source code and burn it into a ROM within a hardware component,
> without having to provide the source code or a mechanism for
> downstream users to modify it.
>
> LGPL on the other hand protects the "freedom of the source" - you
> can't deny your downstream users the source code of the LGPL bit and
> the freedom to modify that. And so your "closed" or "other" bit can't
> do things like "Ensure that jnotify.jar has the correct checksum".
>
> Because of these complications it is an Apache Software Foundation
> policy to not allow LGPL dependencies [1] in software contributed to
> the ASF because we want all our software to be usable by the Apache
> LIcense alone (or by licenses which don't permit less than AL2).
> (Truly <optional> LGPL dependencies are allowed as long as the Apache
> software still works without that).
>
> A EPL-licensed dependency is however easier [2] as long as the EPL
> dependency is kept as a binary and not mixed into the source code.
>
> I must say JNotify is confusing with its two licenses, is it a
> dual-license where you can choose, or do you have to comply with both
> licenses? Make sure your own README and LICENSE makes clear what is
> the case for your end produxct.
>
>
> If you are not considering contributing your work to the Apache
> Software Foundation (why wouldn't you? :) - then you are not required
> to follow ASF policies. You only need to follow the Apache License
> terms for the source code that is covered by that license.
>
>
>
> [1] https://www.apache.org/legal/resolved#category-x
> [2] https://www.apache.org/legal/resolved#category-b
>
>> Can it be used, if it requires user configuration (in pom.xml or command
>> line parameter)?
>>
>> Regards
>> Grzegorz Slowikowski
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven plugin - some licensing questions
Posted by Stian Soiland-Reyes <st...@apache.org>.
This would be more a question for legal-discuss@apache.org, but I'll
try to respond anyway :). Sorry for the long answer.. Please correct
me!
On 29 June 2016 at 19:30, Grzegorz Słowikowski <gs...@gmail.com> wrote:
> 1. Can I include slightly modified class from Maven code in one of my
> plugins? How should I note this fact?
Of course - that's explicitly permitted as long as you follow the
Apache License clause 5
https://www.apache.org/licenses/LICENSE-2.0.html#redistribution
You should note it by keeping the license header in the files, and by
propagating the content of the NOTICE from the Maven code, e.g. from
https://github.com/apache/maven/blob/master/NOTICE
if the code you are modifying is from the main Maven code. (Note that
most plugins have their own repositories with slightly different
NOTICE files)
Remember:
> You must cause any modified files to carry prominent notices stating that You changed the files; and
So if you modify a file, then append to the existing license header
what you have changed.
You will probably want to add your own (c) as well to the new NOTICE.
Note that Apache trademarks mean you can't call your derived product
for "Apache Maven", however you may want to say "partially based on
Apache Maven" if that is true.
You should still reconsider if you really NEED to do your own
modifications - perhaps the modifications can be provided to us
upstream instead in order for you to do subclassing or use the Maven
classes as they are? This would remove your need in the future to
"keep track" with Apache Maven development.
> 2. Can I include classes from other project with ASLv2 license (Play!
> Framework)?
You can mix and match source code from any compatible license, as long
as you keep their license headers and NOTICE content, and provide the
Apache license with your work.
You are not required to license your own derived work under the Apache
license (e.g. you could license it as GPL 3.0 or a commercial license
instead), but in most cases keeping it as Apache License 2.0 makes
things easier :)
Note that while software from ASF always ensures that there is a
NOTICE file and /** Apache **/ license header, not all open source
software under the Apache License do this (it's not a requirement).
You should still append a license header saying which files you have
modified, if you need to.
You may want to keep note in your new NOTICE what files came from where.
> JNotify uses different licenses: GNU LGPL 2.1 + EPL
> Can, from legal PoV, JNotify implementation be used automatically
> (without user configuration) in any case (OSX here)?
Yes, there is no legal reason why you can't use Apache licensed
software with LGPL or EPL. You will have to respect LGPL or EPL
separately for those parts - you can't distribute those as if they are
Apache License. This is normally easily achieved by your software
downloading their JARs separately using normal Maven <dependency>
mechanisms.
Note that LGPL contains a clause that requires downstream users to be
get the source for, modify, debug and replace the LGPL part. The code
that uses LGPL can be under any license as long (and even just a
binary) as it does not restrict those possibilities.
This is normally quite easy to achieve by keeping the LGPL dep as a
separate JAR - but this is a restrictions of the "freedoms" of the
Apache License, e.g. you are allowed to take your modified Apache
Maven source code and burn it into a ROM within a hardware component,
without having to provide the source code or a mechanism for
downstream users to modify it.
LGPL on the other hand protects the "freedom of the source" - you
can't deny your downstream users the source code of the LGPL bit and
the freedom to modify that. And so your "closed" or "other" bit can't
do things like "Ensure that jnotify.jar has the correct checksum".
Because of these complications it is an Apache Software Foundation
policy to not allow LGPL dependencies [1] in software contributed to
the ASF because we want all our software to be usable by the Apache
LIcense alone (or by licenses which don't permit less than AL2).
(Truly <optional> LGPL dependencies are allowed as long as the Apache
software still works without that).
A EPL-licensed dependency is however easier [2] as long as the EPL
dependency is kept as a binary and not mixed into the source code.
I must say JNotify is confusing with its two licenses, is it a
dual-license where you can choose, or do you have to comply with both
licenses? Make sure your own README and LICENSE makes clear what is
the case for your end produxct.
If you are not considering contributing your work to the Apache
Software Foundation (why wouldn't you? :) - then you are not required
to follow ASF policies. You only need to follow the Apache License
terms for the source code that is covered by that license.
[1] https://www.apache.org/legal/resolved#category-x
[2] https://www.apache.org/legal/resolved#category-b
> Can it be used, if it requires user configuration (in pom.xml or command
> line parameter)?
>
> Regards
> Grzegorz Slowikowski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org