Yeah, I think that should cover it. In terms of licensing issues with the website code, I would recommend excluding it from the release. If it's not vital to building the metron runtime components, it doesn't need to be in a release.
How are you currently generating and publishing the website? Svnpubsub? -Taylor > On Mar 29, 2016, at 5:36 PM, Billie Rinaldi <[email protected]> wrote: > >> On Tue, Mar 29, 2016 at 12:46 PM, Casey Stella <[email protected]> wrote: >> >> Regarding the use of effective_tld_names.dat, it is in use currently in the >> Whois enrichment adapter (for stripping top level domains from domains), >> but that adapter is not turned on in the tech preview. That being said, >> it's likely we will want to use that file in the future. Since this is a >> reference file and the reason for the binary-only exclusion is "By >> including only the object/binary form, there is less exposed surface area >> of the third-party work from which a work might be derived; this addresses >> the second guiding principle of this policy.", it would seem that its >> inclusion as a piece of reference data lessens the exposed surface area >> from which a work might be derived, no? >> > > I read that part as saying that it's only okay to include the binary > version; but since this is textual data there is no binary version of these > files that we could include. However, I missed this part on my first read: > "For small amounts of source that is directly consumed by the ASF product > at runtime in source form, and for which that source is unmodified and > unlikely to be changed anyway (say, by virtue of being specified by a > standard), inclusion of appropriately labeled source is also permitted. An > example of this is the web-facesconfig_1_0.dtd, whose inclusion is mandated > by the JSR 127: JavaServer Faces specification." > > So it sounds like we could argue that these 3 files (which are all > identical) are a small amount of source, and we will be allowed to include > them with an appropriate reference in our LICENSE **as long as we never > modify the effective_tld_names.dat files**. > > >> >> Casey >> >>> On Tue, Mar 29, 2016 at 2:55 PM, Billie Rinaldi <[email protected]> wrote: >>> >>> These files have Mozilla Public License, which has an unusual policy that >>> says we should only include them in binary form (!) -- see >>> http://www.apache.org/legal/resolved.html#category-b. Can we get rid of >>> them? >>> metron-streaming/Metron-Common/src/test/resources/effective_tld_names.dat >>> >>> >> metron-streaming/Metron-MessageParsers/src/test/resources/effective_tld_names.dat >>> >>> >> metron-streaming/Metron-Topologies/src/main/resources/effective_tld_names.dat >>> >>> The files at metron-ui/lib/public/font/* seem to have SIL Open Font >> License >>> (https://github.com/FortAwesome/Font-Awesome#license), which has the >> same >>> restriction, but they're okay since they're binary. We need to add their >>> info to our LICENSE. >>> >>> - checksums and signature are valid -- next time include a md5 signature >>> - DISCLAIMER is correct -- file name should include "incubating" but >>> "incubator" is close >>> - no binaries in source tarball >>> - build is successful >>> >>> Billie >>> >>> On Tue, Mar 22, 2016 at 3:56 PM, James Sirota <[email protected]> >>> wrote: >>> >>>> >>>> A tag has been created for Metron_0.1BETA_RC5 >>>> >>>> Github: >>>> >>> >> https://github.com/apache/incubator-metron/releases/tag/Metron_0.1BETA_rc5 >>>> Apache: >>>> >>> >> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=shortlog;h=refs/tags/Metron_0.1BETA_rc5 >>>> >>>> With a Git hash: >>>> 443ad7baa2ce5c3127a9691c7d45b7a4a92e257b >>>> >>>> The code is staged at >>>> http://home.apache.org/~jsirota/metron/Metron_0.1BETA_RC/RC_5/ >>>> >>>> The following are instructions for verifying the build. >>>> >>>> Step 1 – Build Metron >>>> >>>> cd incubator-metron/metron-streaming/ >>>> mvn apache-rat:check && cd metron-streaming && mvn clean >> integration-test >>>> && cd .. >>>> >>>> Verify that all tests are passing >>>> >>>> Step 2 – Deploy metron as a single VM via vagrant and ansible >>>> >>>> cd deployment/vagrant/singlenode-vagrant >>>> vagrant plugin install vagrant-hostmanager >>>> vagrant up >>>> >>>> For a more complete set of instructions refer to: >>>> https://github.com/apache/incubator-metron/tree/master/deployment >>>> >>>> Verify metron is working: >>>> - Check Ambari to make sure all the services are up by going to ambari >> in >>>> a browser at http://node1:8080 >>>> - Check Storm to make sure all the topologies are up >>>> From Ambari navigate to Storm -> Quick Links -> Storm UI >>>> - Check that the enrichment topology has emitted some data (could take >> a >>>> few minutes to show up in the Storm UI) >>>> - Check indexes to make sure indexing is done correctly and data is >>>> visualized in Kibana in a browser at http://node1:5000 >>>> - Check that some data is written into HDFS for at least one of the >> data >>>> sources >>>> Look in HDFS under >>>> /apps/metron/enrichment/indexed/yaf_doc|bro_doc|snort_doc >>>> This can be done from the browser by going to >>>> http://node:50070/explorer.html#/apps/metron/enrichment/indexed >>>> >>>> Step 3 (optional) – Verify AWS Multi-Node Deploy with Ansible >>>> cd deployment/amazon-ec2 >>>> ansible-playbook -i ec2.py playbook.yml >>>> >>>> For a more complete set of instructions refer to: >>>> https://github.com/apache/incubator-metron/tree/master/deployment >>>> >>>> To verify the working build go through the same verifications as in >>> Step2, >>>> but on AWS. Reference playbook.yml for location of the services. >>>> Ambari-master contains Ambari, web contains Kibana and sensors. >>>> >>>> Please vote +1 if you approve and –1 if you do not approve. Also, >> please >>>> indicate if your >>>> vote is binding >>>> >>>> >>> >>
