directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <m...@stefan-seelmann.de>
Subject Re: Questions about the release
Date Mon, 08 May 2017 12:44:42 GMT
On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
> 
> 
> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>> Hi Emmanuel,
>>
>> Is there a wiki page or something that you are aware of at Apache that
>> clearly lays out what the obligations of projects are for licenses + notice
>> files for third party dependencies? It's something I've yet to clearly wrap
>> my head around.
> 
> I think the page is the one pointed out by Stefan :
> 
> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> 
> The thing is that it's not really clear to me too, because there is no
> example on this page.

Here is another one, that makes it IMHO clear that the source N&L should
not include any information about dependencies:

"LICENSE and NOTICE MUST NOT provide unnecessary information about
materials which are not bundled in the package, such as separately
downloaded dependencies."

https://www.apache.org/legal/release-policy.html#licensing-documentation

> The logic is the following : we are distributing packages (either
> sources or bianeis - for convenience, as The ASF is only required to
> deliver source packages for the users to build them -), and we *must*
> not give an opportinuty for our users to make a mistake and embed an
> incompatible component, or forget to add a required notice or license in
> their own packages, putting them at risk of being sued because of that.
> 
> We can think that if a company is going to use our packages should do
> their due diligence, but that is putting too much of a burden on them.
> More important, it would be very bad PR for The ASF if we were to forgot
> some of teh required N&L.

I agree with you. But I think it's two differenct cases:

1) The content of a distributed package.
1a) If the package only contains source code witten by ASF committers or
the compiled class files then the minimal N&L applies. (Note: this would
probably not apply if we would code against an API of an GPL library,
that's why it's not allowed in ASF projects).
1b) If some source code was borrowed e.g. from some 3rd party licensed
under MIT then we need to include that license and copyright notice.
1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
uber jars or binary distribution or installer) then all required N&L of
the bundled artifacts have to be added.

2) The dependencies. As long as they are not bundled then they must not
be added to N&L. But of course it's our duty to make sure that all used
dependencies are compatible to ALv2. And we should be nice to our users
and list the dependencies. And in fact we do that :). All the Maven
generated jars contain a META-INF/DEPENDENCIES file with all
dependencies and its licenses listed. And the Maven generated source zip
also containse a DEPENDENCIES file The only issue I see is that the
Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
looks fine). It's probably because of the multi-module build, but maybe
we can tune the Maven release build to include all dependencies for the
whole project.

> So what does it mean for Kerby, specifically ? Let's check teh different
> use cases...
> 
> 1) We are distributing sources only
> 
> Ok, so we basically don't distribute any binary (libs or exe). Our users
> *must* build Kerby if they want to use one of the packages, or
> copy/paste kerby's code in their one code. Are we safe ? Not that much,
> as building the packages may pull some external dependencies and add
> them in the produced jars (typically, slf4j). In this case, the produced
> packages *must* include the embedded jars' N&L, if they are not fully AL
> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
> bundle may have a NOTICE file that requires us to embed it. It could be
> attribution, a tribute for the cat's author, or anything...)

Here I disagree. If the users builds it then it's not our duty to
provide prober N&L because we don't redistribute what th user builds.

> 2) We are distributing binaries
> 
> And, yes, the jars pulled from Maven *are* binaries. Again, we have to
> make sure that those binaries contain all the required N&L for all the
> embedded components in our jars.

If and only if 3rd party dependencies are bundled within the jar (like
an uber jar).

> 3) We are distributing installers
> 
> This is not Kerby's choice, it's ApacheDS and Studio choice, so I'll
> explain what is required for teh sake of clarity, but it wo'nt apply to
> Kerby. Installers are usually binaries that generate binaries. We have
> to verify that the installer's binaries are fully AL 2.0 compatible, and
> that the generated installers contain all the required N&L too.

Right, and it's lot of work to get it right ;)

> Why should we not add extraneous N&L files ? Because that would make our
> user's task too complex, and we don't want that.
> 
> 
> One last note about GPL/LGPL dependencies : GPL are clearly a no-no for
> us. As GPL is a contaminating license, taht would make all our code GPL.
> That one of our user decide to embed a GPL component is not our
> business, but in any case, they expect our packahes to be AL 2.0, not GPL.
> 
> LGPL is slightly different, but for teh exact same reason, we can't
> embed such a component in our packages. What we can do though, and this
> is what we do for MINA, is to tell users : "ok, if you want to use this
> specific LGPL library which is required fr that specific functionality,
> then you have to build the package yoruself, using a specific flag". For
> MINA, we have a flag for the rxtx package, which is LGPL : building MINA
> with this package requires the user to run 'mvn clean install -Pserial"
> where the 'serial' flag will embed the rxtx library. But when we release
> MINA, we don't use this flag, so our packages never embed rxtx.
> 
> 
> I hope this is clear enough, but to be frank, this is not a simple
> thing, and this is my understanding on how it works...
> 
> 


Mime
View raw message