[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-dev
Subject:    Re: Maven plugin - some licensing questions
From:       Stian Soiland-Reyes <stain () apache ! org>
Date:       2016-06-30 10:24:17
Message-ID: CAMBJEmX4B4F_UJUt094nG-dw8JxciMC_9EBGMGwRXV7dnUhO4Q () mail ! gmail ! com
[Download RAW message or body]

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 <gslowikowski@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

[prev in list] [next in list] [prev in thread] [next in thread]