In message <4a9689f8.1010...@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.1060...@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.
