Many questions inline.
On Fri, Oct 12, 2012 at 4:46 AM, Noah Slater <nsla...@tumbolia.org> wrote:
>> DISCLAIMER
>
> Why is this not picked up by RAT?
I don't know. bug with RAT? What is actionable here for us?
>
>> KEYS
>
> This should not be in the repository.
Where should it be? More explicitly, why shouldn't it be in our git
repo? Where would we place it otherwise? SVN? I went to a number of
git-based TLPs and don't see KEYS there, (and consider this a bug in
incubator docs, as it tells us we need KEYS, points us to a page on
release-signing - but no indication of where KEYS should live - if
you'll tell me I'll add notes to existing incubator documentation)
>
>> awsapi/NOTICE.txt
>> awsapi/README.txt
>
> These files should probably not exist.
>
> This information should be in the top level NOTICE and LICENSE files.
>
Indeed - these are documents for axis2.
Same thing with License.txt
>> debian/changelog
>> debian/README
>
> I am guessing RAT recognises these as files not needing a license.
>
>> deps/XenServerJava/LICENSE.txt
>> deps/XenServerJava/README.txt
>
> These files should probably not exist.
>
> This information should be in the top level NOTICE and LICENSE files.
>
So effectively we are bundling an upstream library (XenServerJava) in
its entirety - are you suggesting we should strip the readme and
license files from that library.
>> docs/publican-cloudstack/NOTICE
>
> This file should probably not exist.
>
> This information should be in the top level NOTICE and LICENSE files.
So I have a question - the notice and license files in
publican-cloudstack are used in the generation of the
publican-cloudstack RPM package (see
docs/publican-cloudstack/publican-cloudstack.spec - including the
toplevel LICENSE or NOTICE file would contain erroneous information
for the publican-cloudstack package How do we resolve this so that the
publican-cloudstack package can contain proper LICENSE/NOTICE
information for the resulting package? Same issue with Marvin - it
has it's own LICENSE/NOTICE/README - but its really designed to be
shipped as a standalone python library when it emerges into 'binary'
form
>
>> patches/systemvm/debian/config/etc/logrotate.conf
>> patches/systemvm/debian/config/etc/logrotate.d/apache2
>> patches/systemvm/debian/config/etc/logrotate.d/dnsmasq
>> patches/systemvm/debian/config/etc/logrotate.d/haproxy
>> patches/systemvm/debian/config/etc/logrotate.d/ppp
>> patches/systemvm/debian/config/etc/logrotate.d/rsyslog
>> patches/systemvm/debian/config/etc/sysctl.conf
>> patches/systemvm/debian/config/opt/cloud/bin/vpc_passwd_server
>> patches/systemvm/debian/config.dat
>
> Why are these files not picked up by RAT?
>
>> patches/systemvm/debian/README
>
> What is this doing here?
>
>> patches/systemvm/debian/vpn/etc/ipsec.conf
>> patches/systemvm/debian/vpn/etc/ipsec.secrets
>> patches/systemvm/debian/vpn/etc/ppp/options.xl2tpd
>> patches/systemvm/debian/vpn/etc/xl2tpd/xl2tpd.conf
>
> Why are these files not picked up by RAT?
>
>> test/conf/README
>> test/integration/component/README
>> test/integration/README
>> test/integration/smoke/README
>> tools/devcloud/veewee/README
>
> Should we have this many README files?
>
> Moving on to a more manual check of the files...
>
> `waf` seems to be some sort of composite binary file. Can we ship this? My
> guess is no.
>
> LICENSE is ISO-8859 encoded. This should be changed to UTF-8 to match our
> other text files.
>
> I then ran this file (based on experimentation with `file` over the source
> tree):
>
> cat > ../okay_file_types.txt << EOF
> ASCII C\+\+ program text
> a python script text executable
> Bourne-Again shell script text executable
> a python script text executable
> ASCII English text
> exported SGML document text
> XML document text
> a bash script text executable
> PNG image data
> ASCII c program text
> SVG Scalable Vector Graphics image
> HTML document text
> POSIX shell script text executable
> PNG image data
> GIF image data
> Lotus 1-2-3
> RFC1421 Security Certificate Signing Request text
> a /usr/bin/make -f script text executable
> ASCII text
> JPEG image data
> UTF-8 Unicode
> Netpbm PBM image text
> a /usr/bin/python script text executable
> ISO-8859 English text
> a /usr/bin/python -u script text executable
> DOS batch file text
> a /usr/bin/python -W ignore::Depr script text executable
> EOF
>
> And then this:
>
> $ find . -type f | xargs file | grep -vEf ../okay_file_types.txt | sed
> 's,:.*,,'
>
> Which gave me this output:
>
> ./awsapi/resource/AmazonEC2/xes.keystore
> ./client/tomcatconf/cloudmanagementserver.keystore
> ./console-proxy/certs/realhostip.keystore
> ./utils/certs/cloud.keystore
>
> These files are binary. Do we need to ship the source?
>
> Then I ran:
>
> $ grep -rsi "copyright" * | grep -v "regarding copyright ownership" | sed
> 's,:, ,' | awk '{print $1}' | sort | uniq > ../files_to_check.txt
>
> I manually reconciled this list with the pom.xml file.
>
>> awsapi/src/com/cloud/bridge/io/DimeDelimitedInputStream.java
>
> This file has two license headers in. One of them is incorrect.
Good catch - top is incorrect - Chip: this likely needs a NOTICE entry as well.
>
>> deps/XenServerJava/BSD
>> deps/XenServerJava/LICENSE.Apache-2.0.txt
>> deps/XenServerJava/LICENSE.txt
>
> These should not be here. They need to be moved to the top level LICENSE.
>
> (And the exclusion in pom.xml needs to be removed.)
>
>> docs/publican-cloudstack/LICENSE
>> docs/publican-cloudstack/NOTICE
>
> These files need to be removed, and merged into the top level LICENSE and
> NOTICE.
See the other publican-cloudstack comments above and let me know how
to resolve it.
>
>> test/integration/component/test_allocation_states.py
>
> This file claims "Copyright 2012 Citrix Systems, Inc." No mention in
> LICENSE.
Already fixed.
>
>> tools/whisker/descriptor.xml
>
> This file has our standard boiler plate, but is crammed full of other
> licenses. Is this okay?
That's as shipped by the Apache RAT (incubating) project.
>
>> ui/lib/excanvas.js
>
> This file claims it is "Copyright 2006 Google Inc.". No mention in LICENSE.
Good catch
Thanks for the review!
