Sounds good to me. Can I start a vote, or is something a champion/mentor would normally start? The project also does not have a champion--is that necessary/would either of you be interested in being the champion?
Thanks, - Steve On 08/08/2017 10:59 PM, Dave Fisher wrote: > Hi - > > I agree. I'm willing to proceed with John and I as Mentors. > > Regards, > Dave > > Sent from my iPhone > >> On Aug 8, 2017, at 7:10 PM, John D. Ament <johndam...@apache.org> wrote: >> >> Steve, >> >> At this point, I'd recommend we wrap the discussion and call for a vote. >> While ideally we want 3 mentors, we can get started with 2 and see how >> things progress. >> >> John >> >>> On Wed, Aug 2, 2017 at 3:55 PM Steve Lawrence >>> <stephen.d.lawre...@gmail.com> wrote: >>> Thanks John! >>> >>> On 08/02/2017 03:23 PM, John D. Ament wrote: >>>> You can also count me in as a mentor. >>>> >>>> John >>>> >>>> On Wed, Aug 2, 2017 at 3:14 PM Steve Lawrence >>>> <stephen.d.lawre...@gmail.com> >>>> wrote: >>>> >>>>> Understood. Thanks for the interest! >>>>> >>>>> - Steve >>>>> >>>>> On 08/02/2017 02:57 PM, Dave Fisher wrote: >>>>>> Hi Steve, >>>>>> >>>>>> It was not so much the lack of committers as it was the current >>>>> diversity. That is not a blocker for entry to Incubation. >>>>>> >>>>>> I am willing to be one of the Mentors. Once there are at least two more >>>>> we can push forward. >>>>>> >>>>>> Regards, >>>>>> Dave >>>>>> >>>>>>> On Aug 1, 2017, at 5:09 AM, Steve Lawrence < >>>>> stephen.d.lawre...@gmail.com> wrote: >>>>>>> >>>>>>> Discussions have died down, and I think the consensus from the responses >>>>>>> is that the issues are 1) the lack of committers and 2) the lack of a >>>>>>> champion and mentors. We hope to address #1 and grow the community as >>>>>>> part of incubation. Is anyone interested in being a champion or mentor >>>>>>> and help us with #2? >>>>>>> >>>>>>> Thanks, >>>>>>> - Steve >>>>>>> >>>>>>> On 07/26/2017 04:06 PM, Chris Mattmann wrote: >>>>>>>> This sounds like a very interesting project. >>>>>>>> >>>>>>>> I don’t have the time to mentor at the moment but I will keep a close >>>>> eye on it. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Chris Mattmann >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/25/17, 11:53 AM, "McHenry, Kenton Guadron" <mche...@illinois.edu> >>>>> wrote: >>>>>>>> >>>>>>>> Hi Dave, >>>>>>>> >>>>>>>> The developers that were at NCSA have moved on to other >>>>> organizations. While we still leverage Daffodil and are very much >>>>> interested in seeing it move forward, development is currently done by the >>>>> Tresys team. Agreed on the synergy with Tika. >>>>>>>> >>>>>>>> Kenton McHenry, Ph.D. >>>>>>>> Principal Research Scientist, Adjunct Assistant Professor of >>>>> Computer Science >>>>>>>> Deputy Director of the Scientific Software & Applications Division >>>>>>>> National Center for Supercomputing Applications, University of >>>>> Illinois at Urbana-Champaign >>>>>>>> >>>>>>>> On Jul 24, 2017, at 1:55 PM, Dave Fisher <dave2w...@comcast.net >>>>> <mailto:dave2w...@comcast.net>> wrote: >>>>>>>> >>>>>>>> Hi Kenton, >>>>>>>> >>>>>>>> Is there any reason that you and others from the NCSA are not >>>>> Initial Committers? That would make this proposal stronger. >>>>>>>> >>>>>>>> Regarding Apache Tika - it relies on other projects including >>>>> Apache POI and Apache PDFBox. They are pragmatic about what is used. If >>>>> Daffodil works to expand then I think that there would be good synergy >>>>> between the projects. I know as a POI PMC member that the POI community >>>>> has >>>>> significantly benefited from the Tika community some of whom are from >>>>> Mitre. >>>>>>>> >>>>>>>> To date Tika has not emphasized structured data, although they do >>>>> extract content from Excel and OpenOffice. >>>>>>>> >>>>>>>> I am intrigued. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dave >>>>>>>> >>>>>>>> On Jul 24, 2017, at 10:55 AM, McHenry, Kenton Guadron < >>>>> mche...@illinois.edu<mailto:mche...@illinois.edu>> wrote: >>>>>>>> >>>>>>>> Yes, DFDL and its open source implementation Daffodil are more >>>>> about file formats and getting access to the entirety of a file's contents >>>>> in a consistent way through machine readable specifications. The work has >>>>> implications in the area of digital preservation allowing one to preserve >>>>> these machine readable specifications rather than all the tools needed to >>>>> open/save a file in order to work with it. Imagine someone developing >>>>> graphics software to work with 3D models and not having to worry about the >>>>> hundreds of formats out there for 3D meshes (whether there are tools for >>>>> opening the files and whether they can get access to those tools, whether >>>>> the spec is available and worrying about how complex that spec is to >>>>> implement, etc.), and simply building their code around the contents (e.g. >>>>> vertices, faces, etc.). One could come up with similar scenarios for >>>>> other >>>>> data types (documents, images, videos, audio, depth data, numeric data). >>>>> Ideally tools built supporting DFDL, could someday, support any format for >>>>> that type without the developer having to worry about the details of how >>>>> that data is represented within a file. >>>>>>>> >>>>>>>> Kenton McHenry, Ph.D. >>>>>>>> Principal Research Scientist, Adjunct Assistant Professor of >>>>> Computer Science >>>>>>>> Deputy Director of the Scientific Software & Applications Division >>>>>>>> National Center for Supercomputing Applications, University of >>>>> Illinois at Urbana-Champaign >>>>>>>> >>>>>>>> On Jul 24, 2017, at 10:30 AM, Steve Lawrence < >>>>> stephen.d.lawre...@gmail.com<mailto:stephen.d.lawre...@gmail.com><mailto: >>>>> stephen.d.lawre...@gmail.com>> wrote: >>>>>>>> >>>>>>>> I'll preface this saying that I don't have a ton of experience with >>>>>>>> Apache Tika. But based on my understanding, Tika and Daffodil do >>>>> have >>>>>>>> somewhat similar goals, but reach them in different ways. For >>>>> example, >>>>>>>> Tika requires that one writes /code/ to perform data extraction, >>>>> usually >>>>>>>> relying on existing Java libraries to extract the desired metadata. >>>>> The >>>>>>>> downside to this is that code can be buggy, and libraries might not >>>>> even >>>>>>>> exist for formats of interest (especially common with legacy and >>>>>>>> military data). >>>>>>>> >>>>>>>> Daffodil, on the other hand, does not require one to write any code. >>>>>>>> Instead, one writes a DFDL Schema (similar to XML Schema, with DFDL >>>>>>>> annotations) that fully describes the data, which Daffodil then >>>>> uses to >>>>>>>> convert the data to XML/JSON for extraction. So adding support for >>>>> a new >>>>>>>> format means writing a new schema rather than new code. And less >>>>> code >>>>>>>> generally means less bugs. Also, for secure systems that require >>>>>>>> certification, generally speaking, it is easier to certify a schema >>>>> as >>>>>>>> compared to code. >>>>>>>> >>>>>>>> We certainly don't believe that Daffodil could replace Tika, but it >>>>> does >>>>>>>> have the potential to add new functionality to Tika for formats >>>>> that do >>>>>>>> not have existing libraries. One of our goals is to look into >>>>>>>> integrating Daffodil support into tools like Tika. We'd love to hear >>>>>>>> from Tika devs if this is something they'd be interested in. >>>>>>>> >>>>>>>> I'll also add that whereas Tika tends to focus primarily on >>>>> metadata, >>>>>>>> DFDL schemas usually describe an entire file format down to the >>>>> byte, so >>>>>>>> one can extract more than just meta data, including text and binary >>>>>>>> data. Further differentiating, Daffodil has support for serializing >>>>> data >>>>>>>> (called unparse) from the XML/JSON representation, allowing one to >>>>>>>> transform or filter data as well. We don't believe this feature is >>>>> all >>>>>>>> that applicable to Tika, but may be useful to other technologies >>>>> such as >>>>>>>> filtering or data fuzzing technologies. >>>>>>>> >>>>>>>> - Steve >>>>>>>> >>>>>>>> >>>>>>>> On 07/24/2017 10:59 AM, Mike Drob wrote: >>>>>>>> What is the relationship between Daffodil and something like Apache >>>>> Tika's >>>>>>>> extraction engine? >>>>>>>> >>>>>>>> On Mon, Jul 24, 2017 at 9:53 AM, Steve Lawrence < >>>>>>>> stephen.d.lawre...@gmail.com<mailto:stephen.d.lawre...@gmail.com >>>>>> <mailto:stephen.d.lawre...@gmail.com>> wrote: >>>>>>>> >>>>>>>> Dear Apache Incubator Community, >>>>>>>> >>>>>>>> We would like to start a discussion around a proposal to bring >>>>> Daffodil >>>>>>>> into the Apache Incubator. Daffodil is a implementation of the DFDL >>>>>>>> specification used to convert between fixed format data and >>>>> XML/JSON. >>>>>>>> >>>>>>>> The draft proposal can be found in the wiki at the following URL: >>>>>>>> >>>>>>>> https://wiki.apache.org/incubator/DaffodilProposal >>>>>>>> >>>>>>>> We do not yet have a champion or mentors, but it was recommended >>>>> that we >>>>>>>> create a proposal and send it to this list to potentially find those >>>>>>>> that might be interested. The text for the draft proposal is found >>>>>>>> below. We look forward to your input. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Steve >>>>>>>> >>>>>>>> >>>>>>>> = Daffodil Proposal = >>>>>>>> >>>>>>>> == Abstract == >>>>>>>> >>>>>>>> Daffodil is an implementation of the Data Format Description >>>>> Language >>>>>>>> (DFDL) used to convert between fixed format data and XML/JSON. >>>>>>>> >>>>>>>> == Proposal == >>>>>>>> >>>>>>>> The Data Format Description Language (DFDL) is a specification, >>>>>>>> developed by the Open Grid Forum, capable of describing many data >>>>>>>> formats, including both textual and binary, scientific and numeric, >>>>>>>> legacy and modern, commercial record-oriented, and many industry and >>>>>>>> military standards. It defines a language that is a subset of W3C >>>>> XML >>>>>>>> schema to describe the logical format of the data, and annotations >>>>>>>> within the schema to describe the physical representation. >>>>>>>> >>>>>>>> Daffodil is an open source implementation of the DFDL specification >>>>> that >>>>>>>> uses these DFDL schemas to parse fixed format data into an infoset, >>>>>>>> which is most commonly represented as either XML or JSON. This >>>>> allows >>>>>>>> the use of well-established XML or JSON technologies and libraries >>>>> to >>>>>>>> consume, inspect, and manipulate fixed format data in existing >>>>>>>> solutions. Daffodil is also capable of the reverse by serializing or >>>>>>>> "unparsing" an XML or JSON infoset back to the original data format. >>>>>>>> >>>>>>>> == Background == >>>>>>>> >>>>>>>> Many different software solutions need to consume and manage data, >>>>>>>> including data directed routing, databases, data analysis, data >>>>>>>> cleansing, data visualizing, and more. A key aspect of such >>>>> solutions is >>>>>>>> the need to transform the data into an easily consumable format. >>>>>>>> Usually, this means that for each unique data format, one develops a >>>>>>>> tool that can read and extract the necessary information, often >>>>> leading >>>>>>>> to ad-hoc and data-format-specific description systems. Such >>>>> systems are >>>>>>>> often proprietary, not well tested, and incompatible, leading to >>>>> vendor >>>>>>>> lock-in, flawed software, and increased training costs. DFDL is a >>>>> new >>>>>>>> standard, with version 1.0 completed in October of 2016, that solves >>>>>>>> these problems by defining an open standard to describe many >>>>> different >>>>>>>> data formats and how to parse and unparse between the data and >>>>> XML/JSON. >>>>>>>> >>>>>>>> Two closed source implementations of DFDL currently exist. The >>>>> first was >>>>>>>> created by IBM and is now part of their IBM® Integration Bus >>>>> product. >>>>>>>> The second was created by the European Space Agency, called DFDL4S >>>>> or >>>>>>>> "DFDL for Space" targeted at the challenges of their satellite data >>>>>>>> processing. >>>>>>>> >>>>>>>> Around 2005, Pacific Northwest National Lab created Defuddle, built >>>>> as >>>>>>>> an open source implementation and proof of concept of the draft DFDL >>>>>>>> specification and a test bed to feed new concepts into specification >>>>>>>> development. Primary development of Defuddle was eventually taken >>>>> over >>>>>>>> by the National Center for Supercomputing Applications (NCSA). >>>>> However, >>>>>>>> due to evolution of the DFDL specification and architectural and >>>>>>>> performance issues with Defuddle, around 2009, NCSA restarted the >>>>>>>> project with the new name of Daffodil, with a goal of implementing >>>>> the >>>>>>>> complete DFDL specification. Daffodil development continued at NCSA >>>>>>>> until around 2012, at which point development slowed due to budget >>>>>>>> limitations. Shortly thereafter, primary development was picked up >>>>> by >>>>>>>> Tresys Technology where it continues today, with contributions from >>>>>>>> other entities such as the Navy Research Lab, the Air Force Research >>>>>>>> Lab, MITRE, and Booz Allen Hamilton. In February of 2015, Daffodil >>>>>>>> version 1.0.0 was released, including support for the DFDL features >>>>>>>> needed to parse many common file formats. Daffodil version 2.0.0 is >>>>>>>> expected to be released in August of 2017, which will include >>>>> unparse >>>>>>>> support with one-to-one parsing feature parity. >>>>>>>> >>>>>>>> Entities including IBM, MITRE, NATO NCI Agency, Northrop-Grumman, >>>>> Quark >>>>>>>> Security, Raytheon, and Tresys Technology have developed DFDL >>>>> schemas >>>>>>>> for many data formats from varying technology domains, including >>>>> PNG, >>>>>>>> GIF, BMP, PCAP, HL7, EDIFACT, NACHA, vCard, iCalendar, and >>>>> MIL-STD-2045, >>>>>>>> many of which are publicly available on the DFDL Schemas github. >>>>> There >>>>>>>> are also a number of military-application data formats, the >>>>>>>> specifications of which are not public, which have historically been >>>>>>>> very difficult and expensive to process, and for which DFDL schemas >>>>> have >>>>>>>> been created or are actively in development; these include >>>>>>>> MIL-STD-6040/USMTF ATO, MIL-STD-6017/VMF, MIL-STD-6016/NATO STANAG >>>>> 5516 >>>>>>>> (aka "Link16"). >>>>>>>> >>>>>>>> == Rationale == >>>>>>>> >>>>>>>> Numerous software solutions exist that consume, inspect, analyze, >>>>> and >>>>>>>> transform data, many of which can be found in the Apache Software >>>>>>>> Foundation (ASF). In order for tools like these to consume new >>>>> types of >>>>>>>> data, custom extensions are usually required, often with high >>>>>>>> development and testing costs. Daffodil fills a clear gap in many of >>>>>>>> these solutions, providing a simple and low cost way to transform >>>>> data >>>>>>>> to XML or JSON, which many of these tools natively support already. >>>>> With >>>>>>>> the upcoming 2.0.0 release, the Daffodil project will have achieved >>>>> a >>>>>>>> level of functionality in both parse and unparse that, when >>>>> integrated >>>>>>>> into existing solutions, could provide for a new method to quickly >>>>>>>> enable support for new data formats. >>>>>>>> >>>>>>>> == Initial Goals == >>>>>>>> >>>>>>>> * Relicense the existing code from the University of Illinois/NCSA >>>>> Open >>>>>>>> Source License to the Apache License version 2.0, working with >>>>> Apache >>>>>>>> Legal to ensure correctness, and with Daffodil contributors to get >>>>>>>> their permission. >>>>>>>> * Move the existing codebase, documentation, bugs, and mailing >>>>> lists to >>>>>>>> the Apache hosted infrastructure >>>>>>>> * Establish a formal release process and schedule, allowing for >>>>>>>> dependable release cycles in a manner consistent with the Apache >>>>>>>> development process. >>>>>>>> * Build relationships with ASF projects to add Daffodil support >>>>> where >>>>>>>> appropriate >>>>>>>> * Grow the community to establish a diversity of background and >>>>> expertise. >>>>>>>> >>>>>>>> == Current Status == >>>>>>>> >>>>>>>> === Meritocracy === >>>>>>>> >>>>>>>> All initial committers are familiar with the principles of >>>>> meritocracy. >>>>>>>> The Daffodil project has followed the model of meritocracy in the >>>>> past, >>>>>>>> providing multiple outside entities commit access based on the >>>>> quality >>>>>>>> of their contributions. In order to grow the Daffodil user base and >>>>>>>> development community, we are dedicated to continuing to operate >>>>>>>> Daffodil as a meritocracy. >>>>>>>> >>>>>>>> A key ingredient in a meritocracy of developers is open group code >>>>>>>> review. The Daffodil project has operated in this mode throughout >>>>> its >>>>>>>> existence and this provides a forum to improve the code, verify code >>>>>>>> quality, and educate new developers on the code base. >>>>>>>> >>>>>>>> === Community === >>>>>>>> >>>>>>>> Daffodil has a small community of users and developers. Although >>>>> primary >>>>>>>> Daffodil development is done by Tresys Technology, a handful of >>>>> other >>>>>>>> contributions have come from other entities including the Navy >>>>> Research >>>>>>>> Lab, the Air Force Research Lab, MITRE, and Booz Allen Hamilton. In >>>>>>>> addition to developers, multiple users of Daffodil have created DFDL >>>>>>>> schemas, including entities such as MITRE, IBM, Raytheon, Quark >>>>>>>> Security, and Tresys Technology. The DFDL Schemas github community >>>>> has >>>>>>>> been created as a place for DFDL schemas to be published. The >>>>> Daffodil >>>>>>>> project also makes use of mailing lists, !HipChat, and Confluence >>>>>>>> Questions to build a community of users and system for support. >>>>>>>> >>>>>>>> === Core Developers === >>>>>>>> >>>>>>>> The core developers of Daffodil are employed by Tresys Technology. >>>>> We >>>>>>>> will work to grow the community among a more diverse set of >>>>> developers >>>>>>>> and industries. >>>>>>>> >>>>>>>> === Alignment === >>>>>>>> >>>>>>>> Daffodil was created as an open source project with a philosophy >>>>>>>> consistent with The Apache Way. A strong belief in meritocracy, >>>>>>>> community involvement in decisions, openness, and ensuring a high >>>>> level >>>>>>>> of quality in code, documentation, and testing are some of our >>>>> shared >>>>>>>> core beliefs. >>>>>>>> >>>>>>>> Further, as mentioned in the Rationale section, Daffodil fills a gap >>>>>>>> that exists in many ASF projects, including !NiFi, Spark, Storm, >>>>> Hadoop, >>>>>>>> Tika, and others. In order for tools like these to consume new >>>>> types of >>>>>>>> data, custom extensions are usually required. Rather than create >>>>> such >>>>>>>> extensions, Daffodil provides an easy and standards-compliant way to >>>>>>>> transform data to XML or JSON, which many of these tools already >>>>>>>> natively support. >>>>>>>> >>>>>>>> == Known Risks == >>>>>>>> >>>>>>>> === Orphaned Products === >>>>>>>> >>>>>>>> The current core developers are the leading contributors in the >>>>> space of >>>>>>>> DFDL and wish to see it flourish. Though there is some risk that the >>>>>>>> initial committers all come from the same company, a goal of >>>>> entering >>>>>>>> into incubation is to grow the development community to minimize the >>>>>>>> risk of reliance on a single company. >>>>>>>> >>>>>>>> === Inexperience with Open Source === >>>>>>>> >>>>>>>> The Daffodil project began as an open source project and has >>>>> continued >>>>>>>> that model throughout development. This includes public bug >>>>> tracking, >>>>>>>> git revision control, automated builds and tests, and a public wiki >>>>> for >>>>>>>> documentation. >>>>>>>> >>>>>>>> Additionally, the current core developers and initial committers all >>>>>>>> work for a company that relies on, believes in, promotes, and has >>>>> led or >>>>>>>> contributed to many open source software projects, including SELinux >>>>>>>> Userspace, OpenSCAP, CLIP, refpolicy, setools, RPM, and others. As >>>>> such, >>>>>>>> there is low risk related to inexperience with open source software >>>>> and >>>>>>>> processes. >>>>>>>> >>>>>>>> === Homogeneous Developers === >>>>>>>> >>>>>>>> The proposed initial committers come from a single entity, though >>>>> we are >>>>>>>> committed to growing the Daffodil development community to include a >>>>>>>> broad group of additional committers from a wide array of >>>>> industries. >>>>>>>> >>>>>>>> === Reliance on Salaried Developers === >>>>>>>> >>>>>>>> The proposed initial committers are paid by their employer to >>>>> contribute >>>>>>>> to the Daffodil project. We expect that Daffodil development will >>>>>>>> continue with salaried developers, and are committed to growing the >>>>>>>> community to include non-salaried developers as well. >>>>>>>> >>>>>>>> === Relationship with other Apache Projects === >>>>>>>> >>>>>>>> As mentioned in the Alignment section, Daffodil fills a clear gap in >>>>>>>> numerous other ASF projects that consume and manage large amounts >>>>> of data. >>>>>>>> >>>>>>>> As a specific example, Daffodil developers have created a Daffodil >>>>>>>> Apache !NiFi Processor, currently in use in data transfer solutions, >>>>>>>> which allows one to ingest non-native data into an Apache !NiFi >>>>> pipeline >>>>>>>> as XML or JSON. This processor was well received by the Apache !NiFi >>>>>>>> developers, with positive comments about the concise API and how it >>>>>>>> could handle non-native data. Daffodil developers have also >>>>> successfully >>>>>>>> prototyped integration with Apache Spark. We believe Daffodil could >>>>>>>> provide a strong benefit to many other ASF projects that handle >>>>> fixed >>>>>>>> format data. We anticipate working closely with such ASF projects to >>>>>>>> include Daffodil where applicable to increase their ability to >>>>> support >>>>>>>> new data formats with minimal effort. >>>>>>>> >>>>>>>> Daffodil also depends on existing ASF projects, including Apache >>>>> Commons >>>>>>>> and Apache Xerces. >>>>>>>> >>>>>>>> === An Excessive Fascination with the Apache Brand === >>>>>>>> >>>>>>>> Although the Apache brand may certainly help to attract more >>>>>>>> contributors, publicity is not the reason for this proposal. We >>>>> believe >>>>>>>> Daffodil could provide a great benefit to the ASF and the numerous >>>>> data >>>>>>>> focused projects that comprise it, as described in the Rationale and >>>>>>>> Alignment sections. We hope to build a strong and vibrant community >>>>>>>> built around The Apache Way, and not dependent on a single company. >>>>>>>> >>>>>>>> === Documentation === >>>>>>>> >>>>>>>> Daffodil documentation can be found at: >>>>>>>> >>>>>>>> * >>>>>>>> https://opensource.ncsa.illinois.edu/confluence/ >>>>>>>> display/DFDL/Daffodil%3A+Open+Source+DFDL >>>>>>>> >>>>>>>> Information about DFDL can be found at: >>>>>>>> >>>>>>>> * https://www.ogf.org/ogf/doku.php/standards/dfdl/dfdl >>>>>>>> * >>>>>>>> https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0. >>>>>>>> 0/com.ibm.etools.mft.doc/df20060_.htm >>>>>>>> >>>>>>>> Public examples of DFDL Schemas can be found at: >>>>>>>> >>>>>>>> * https://github.com/DFDLSchemas >>>>>>>> >>>>>>>> == Initial Source == >>>>>>>> >>>>>>>> The Daffodil git repo goes back to mid-2011 with approximately 20 >>>>>>>> different contributors and feedback from many users and developers. >>>>> The >>>>>>>> core codebase is written in Scala and includes both a Scala and Java >>>>>>>> API, along with Javadocs and Scaladocs for API usage. The initial >>>>> code >>>>>>>> will come from the git repository currently hosted by NCSA at the >>>>>>>> University of Illinois : >>>>>>>> >>>>>>>> https://opensource.ncsa.illinois.edu/bitbucket/ >>>>>>>> projects/DFDL/repos/daffodil/ >>>>>>>> >>>>>>>> == Source and Intellectual Property Submission == >>>>>>>> >>>>>>>> The complete Daffodil code is licensed under the University of >>>>>>>> Illinois/NCSA Open Source License. Much of the current codebase has >>>>> been >>>>>>>> developed by Tresys Technology, who is open to relicensing the code >>>>> to >>>>>>>> the Apache License version 2.0 and donate the source to the ASF. >>>>>>>> Contacts at NCSA are also open to relicensing their contributions to >>>>>>>> Apache v2. We plan to contact the other contributors and ask for >>>>>>>> permission to relicense and donate their contributed code. For those >>>>>>>> that decline or we cannot contact, their code will be removed or >>>>>>>> replaced. We will work closely with Apache Legal to ensure all >>>>> issues >>>>>>>> related to relicensing are acceptable. >>>>>>>> >>>>>>>> == External Dependencies == >>>>>>>> >>>>>>>> We believe all current dependencies are compatible with the ASF >>>>>>>> guidelines. Our dependency licenses come from the following license >>>>>>>> styles: Apache v2, BSD, MIT, and ICU. The list of current Daffodil >>>>>>>> dependencies and their licenses are documented here: >>>>>>>> >>>>>>>> https://opensource.ncsa.illinois.edu/confluence/ >>>>>>>> display/DFDL/Dependencies+and+Licenses >>>>>>>> >>>>>>>> == Cryptography == >>>>>>>> >>>>>>>> None >>>>>>>> >>>>>>>> == Required Resources == >>>>>>>> >>>>>>>> === Mailing Lists === >>>>>>>> >>>>>>>> * comm...@daffodil.incubator.apache.org >>>>>>>> * d...@daffodil.incubator.apache.org >>>>>>>> * priv...@daffodil.incubator.apache.org >>>>>>>> * u...@daffodil.incubator.apache.org >>>>>>>> >>>>>>>> === Source Control === >>>>>>>> >>>>>>>> git://git.apache.org/incubator-daffodil.git >>>>>>>> >>>>>>>> === Issue Tracking === >>>>>>>> >>>>>>>> JIRA Daffodil (DFDL) >>>>>>>> >>>>>>>> === Initial Committers === >>>>>>>> >>>>>>>> * Beth Finnegan <efinnegan at tresys dot com> >>>>>>>> * Dave Thompson <dthompson at tresys dot com> >>>>>>>> * Josh Adams <jadams at tresys dot com> >>>>>>>> * Mike Beckerle <mbeckerle at tresys dot com> >>>>>>>> * Steve Lawrence <slawrence at tresys dot com> >>>>>>>> * Taylor Wise <twise at tresys dot com> >>>>>>>> >>>>>>>> === Affiliations === >>>>>>>> >>>>>>>> * Beth Finnegan (Tresys Technology) >>>>>>>> * Dave Thompson (Tresys Technology) >>>>>>>> * Josh Adams (Tresys Technology) >>>>>>>> * Mike Beckerle (Tresys Technology) >>>>>>>> * Steve Lawrence (Tresys Technology) >>>>>>>> * Taylor Wise (Tresys Technology) >>>>>>>> >>>>>>>> == Sponsors == >>>>>>>> >>>>>>>> === Champion === >>>>>>>> >>>>>>>> * TBD >>>>>>>> >>>>>>>> === Nominated Mentors === >>>>>>>> >>>>>>>> * TBD >>>>>>>> >>>>>>>> === Sponsoring Entity === >>>>>>>> >>>>>>>> We request the Apache Incubator to sponsor this project. >>>>>>>> >>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> <mailto:general-unsubscr...@incubator.apache.org> >>>>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> <mailto:general-h...@incubator.apache.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
