harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] More license fixes for M11
Date Thu, 27 Aug 2009 13:43:36 GMT

In message <4A9689F8.1010204@gmail.com>, Tim Ellison writes:
>
> On 27/Aug/2009 14:03, Mark Hindess wrote:
> > I've already committed this change in r808406 with Oliver's approval.
> > 
> > In message <4A967DC9.1060004@gmail.com>, Tim Ellison writes:
> >> On 27/Aug/2009 11:29, Mark Hindess wrote:
> >>> I also updated APR during this milestone.  (However, the
> >>> LICENSE/NOTICE sections were missing already AFAICT.)  I'd like to
> >>> commit the appended patch to fix this.
> >> I believe the reason is that we are not redistributing these
> >> dependencies in the source builds.
> > 
> > The zlib notice has been in the NOTICE/THIRD_PARTY_NOTICES.txt file
> > since M1 and that is a similar downloaded dependency?
> 
> Not really, zlib *is* included in our source builds (but I take your
> point, and that is likely true if you had chosen a different dependency)

Oops.  For some reason I thought we downloaded this.  (We probably should
download and then patch it to build it.)

> >> Which raises the thorny question, are you trying to gather the
> >> licenses and notices for the source artifact we are going to vote
> >> on and release, or for the binary which contains copies of the
> >> dependencies we drag in?
> > 
> > Yes! ;-)
> > 
> > 
> > Both.  Currently LICENSE/NOTICE files at each top-level (classlib,
> > jdktools, vm and federated build[0]) are used when we use the source
> > artifacts to create corresponding binary artifacts.
> > 
> > The quick fix would be:
> > 
> > 1) accept that the source artifact has "too much" information in its
> > LICENSE/NOTICE files,
> 
> Yep, and provided the files describe why the licenses/notices are in
> there then people can remove them if they are not applicable to their
> usage.  So while it is not ideal, we can live with it for the moment.
> 
> > 2) not create any binaries and remove the associated entries, or
> 
> This would be a shame, but I agree they are more work and probably
> require help to ensure they are properly maintained.
> 
> > 3) derive separate LICENSE/NOTICE files for use in binaries (patch welcome 
> ;-)
> 
> It should be possible, since the dependencies should only add to the
> existing LICENSE/NOTICE files; but I agree it is not going to happen in
> time for M11.
> 
> > I vote for 1) for this release since we've accepted this since M1 (zlib
> > is a binary not source dependency).
> 
> It is not the binary/source-ness of the dependency, but the fact that we
> are redistributing it that means we need to include the appropriate
> license/notice in our package.

I know.  zlib was a bad example.

-Mark.



Mime
View raw message