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) >> 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. > Regards, > Mark. > > [0] If "svn co" is a release and we support working at the classlib/module/* > level then perhaps we need to create the 30+ LICENSE/NOTICE files in > the modules too. It isn't so we don't :-) Regards, Tim
