Hi everyone, I'm attaching the Google Summer of Code proposals submitted regarding SPDX. You will see each currently has an assigned mentor as of April 3rd according to the GSoC site.
I believe that each project can have multiple members. If you are interested in helping out, there is more information here on the mentorship role: http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page Let me know if you have questions or comments. Regards, Matt Germonprez -- Mutual of Omaha Associate Professor of Information Systems University of Nebraska at Omaha Vita <http://myweb.unomaha.edu/~mgermonprez/> Open Communities Lab <http://ocrl.unomaha.edu/> NSF Grant on Open Communities <http://1.usa.gov/17mbd1Z>
SPDX Parser library for the Go Programming Language Student:Vlad Velici (University of Southampton) Assigned mentors: Philippe Ombredanne I am in my second year at university but I have been coding long before coming to uni. I am originally from Romania. I like competitions and hackathons and I attend a lot of them. I am in the committee of the HackaSoton society, a society within the University of Southampton that links entrepreneurs with tech people (organise tech talks, hackathons and trips to various events - we’ve been to FOSDEM). Programming Languages Go OCaml Java JavaScript Bash Ruby PHP HTML/CSS Frameworks and technologies that I have used: YiiFramework, Ruby on Rails, node.js, angular.js, MySQL, sqlite, git. I use git for almost everything. Feel free to have a look at my github: http://github.com/vladvelici although my latest code is in private repos (university coursework). I coded in C++ for solving algorithms on judge websites. I used python for two very small projects (one with django). I am OK coding bash scripts. I have recently written an interpreter (including a parser) for a domain-specific programming language as a coursework and I really enjoyed it. Platform I am now using a MacBook air with the following configuration: Processor 1.3 GHz Intel Core i5 Memory 4 GB 1600 MHz DDR3 Graphics Intel HD Graphics 5000 1024 MB Software OS X 10.9.2 But I have been using an Ubuntu (various versions) machine for a long time before having the Mac. I code in vim. About the project I would like to build a parser library for SPDX in Go, based on the Java implementation already available. I chose this project from the list because I understand the importance of having a standardised way of distributing software licences and I think I am able to deliver a high quality project at the end of SoC. I recently built a parser and interpreter for a programming language (designed by me and my coursework partner) as a coursework. I know it is different than parsing XML/RDF but it is a related experience. I think I’m suitable for this project because I like the Go programming language and I know Java (thus I can understand the existing library and use that as a starting point for architecture and features) and I also have a bit of experience with building a parser (the interpreter coursework and a small hackathon project that was parsing and validating XML data of a specific schema with some constraints). This is just a brief of how I plan to use the time. I have no other commitments during the summer, except my exams in May (mentioned in the table). 2 weeks First two weeks of SoC are clashing with my exams, but I should be able to do some simple tasks: get the Java parser library and play with it, understand how it works and how it is structured. figure out what tools it provides and how to best implement them in a Go library Read more on SPDX specifications Initial (bootstrapping) Go code 5 weeks Decide parsing libraries to be used (if any). Go has nice XML support in the standard library. I would like to do TDD. Also listen to feedback from the community (if any) and react to suggestions. Write tests and implement all the basic functionality, starting with XML import/export, then RDF import/export then tag/value import/export. 1.5 weeks Reviews, testing and bug fixing. 2 weeks React to feedback and reviews, change code and APIs accordingly. Test again. Bug fixing. 2.5 weeks Polishing, maybe small convenience tools (if anything seems to be required), documentation writing, bug fixing. I know that Go is not very popular at the moment but it is one of my favourite languages. However, I’d like to mention that I would be happy to implement this parser in another language if a parser library in Go would not be as important for the community - please contact me if this is the case. If you have any questions please contact me. My contact details IRC nickname I'll use: vla_ve Email: [email protected] ******************************* Python SPDX parser library Student: Ahmed Hisham Ismail (German University in Cairo) Possible mentors: Philippe Ombredanne, Hin-Tak Leung Assigned mentors: Hin-Tak Leung Email: [email protected] Short description: A Python library for creating, importing, exporting and manipulating SPDX files. This proposal is for the SPDX working group of the Linux Foundation. This is a proposal to create an SPDX Parser library using Python. Currently the only open source SPDX parser is in Java, which limits the development of analysis tools that support SPDX. As the developers either have to roll their own library or use the Java one. Why have you chosen your development idea and what do you expect from your implementation? I chose this project as I am familiar with parser development. I expect that my implementation will allow other developers to create more tools with greater ease and widen SPDX support and usage. Project Plan: Planned Features: Ability to create new SPDX documents. Ability to load/import existing SPDX documents in RDF/XML or tag/value format. Ability to export/save SPDX documents in the above formats. Ability to manipulate, modify and query all aspects of an SPDX document. Note: The plan is to support the 1.2 specification, while keeping the library easily extendable to support the upcoming 2.0 spec. and possibly including partial support for the upcoming standard depending on when it will be released. Design outline: I am currently considering two approaches, the first is in object oriented terms have classes for each SPDX class will be created such as SPDXDocument, CreationInfo, Package, etc. Properties will be treated as attributes, for example an SPDXDocument has-a CreationInfo. CreationInfo has zero or one LicenseListVersion, zero or one comment, a set of creators and a creation date. A set of modules will be created that can convert between SPDXDocuments and file formats(RDF/XML and Tag/Value). The exporting modules would traverse the document in a top-down manner from the SPDXDocument. The importing modules will of course do the opposite. In this approach a property P with domain D and range R, would mean that the class representing type D would have an attribute of type R (possibly a vector). The second approach uses the graph model of RDF to represent the document with instances as nodes and properties as directed labelled edges, with the name of the property as the label. This is possibly more flexible and will most likely make it easier to support 2.0 and future changes. In this case the import modules would construct the graph and the export modules would simply traverse it starting from the SPDXDocument. Milestones: The project can be split into 3 major parts : Representation and Manipulation of SPDX documents in memory. RDF/XML and tag/value parsers (import). RDF/XML and tag/value generators (export). Initial Schedule: Before the coding period starts I will be working on the design and object diagrams. The first week will be spent working on the SPDX model, the in memory representation. The second week will be dedicated to implementing and testing the tag/value parser. The third week will be dedicated to implementing and testing the RDF parser. A period of 3-5 days will be dedicated to review the current state of the project with the representation and import features implemented. A week will be spent on implementing the RDF/XML generator and testing it. A week will be spent on implementing the tag/value generator and testing it. Two weeks will be spent on thoroughly testing, reviewing and extending components if need be. Total time Estimate: 7-8 weeks Note: for some tasks a week is used in the broad sense as anything between 4-7 days for tasks such as RDF generator or tag/value parser less than a week is expected. Third Party Libraries of interest: librdf is a library for parsing RDF/XML files, we can use this to implement the RDF/XML import function. rdfxml is another option, however it's documentations is a bit sparse. lrparsing is a parser generator library which we can use, an alternative is ANTLR. lrparsing has the benefit of not being an external tool. About Me: I am currently a CS undergrad at the German University in Cairo. I usually code in C++ and Python. With the occasional Go, Java or Prolog. One of my goals is to join an active open source community and start contributing to it. I am hoping GSoC will introduce me to such a community and familiarize me with the open source development process. I am looking for a long term relationship with a community. My general areas of interest are AI, NLP, Computer Vision, Compilers, formal language theory and Networking. I prefer to listen to deadmau5 or Daft Punk while coding. I like to hang out in chat rooms and can be usually found in the Lounge on stackoverflow. Coding experience: I have about 5 years of coding experience, primarily with C++ but I am also familiar and comfortable writing code in Python, Java, Go or Prolog. My main development platform is Fedora amd64. Experience listed under Desired Knowledge of the project: I have experience with parser development, I have previously used ANTLR and Boost.Spirit to create parsers. I am comfortable writing grammars for languages, and I am familiar with concepts such as left recursion, LL, LR and such. I have worked with XML before, most recently I created a parser for VXML(voiceXML) using Python. How much time do you plan to invest in the project before, during and after the Summer of Code? I have already read the specs on RDF and SPDX and familiarized myself with the SPDX vocab. I plan to continue learning about them, especially the SPDX 2.0 drafts in order to include support for 2.0 in the parser. I plan to spend the majority of the time before the summer on the design of the project. I will be able to dedicate 15 hours / week before the summer of code to this project. During the summer I have no problem committing to 40 hour weeks I am able to free myself completely for GSoC and consider it a full time job during the summer. I will be available full time with 10 hours a day completely dedicated to the project 6 days/week during the coding period . After the summer of code is over I hope to use the contacts I will hopefully make with the SPDX workgroup to continue contributing to SPDX tool development. CONTACT: Email: [email protected] Name: Ahmed Hisham Ismail IRC: ahi GitHub: https://github.com/ah450 Phone: 01096853666 Time Zone: UTC + 2 Location: Giza, Egypt Ideal Contact Time : between 0800 and 2300 UTC ******************************* FOSSology+SPDX Project Proposal Student: Zachary McFarland (University of Nebraska at Omaha) Mentor: Matt Germonprez Email: [email protected] Introduction FOSSology+SPDX aims to support the advancement of tooling to produce SPDX documents from the FOSSology open source package scanner. This tool supports the integration of the SPDX standard into current license scanning practices. SPDX or The Software Package Data Exchange specification is a standard format for communicating the components, licenses and copyrights associated with a software package (http://spdx.org/ 2014). FOSSology is a source code scanning tool used to identify license and copyright. The University of Nebraska at Omaha’s Open Systems development class is currently creating other tools to facilitate the use of SPDX documents for the business setting. These tools include a web based dashboard to view SPDX documents in a more user friendly way. Another tool the class has been developing is the SPDX Product History Utility, which will allow business to associate products with software packages in order to inventory which software licenses and copyrights are on their products. Current Status The Product History Utility and the Dashboard are currently in development and will be continued to be worked on through the course of the Spring 2014 semester. The FOSSology+SPDX has a current working prototype that allows potential users to view the functioning system. The current plan is to implement the Product History Utility as a side car of the Dashboard with a few minimal integrations between the two. Prototypes Fossology+SPDX https://fossologyspdx.ist.unomaha.edu/ Dashboard http://spdxhub.ist.unomaha.edu/ Product History Utility http://54.218.86.78/SPDX/index.php Note: These are prototype systems and maybe unstable. Context SPDX is currently a developing specification looking to expand its influence on license and copyright documentation of open source code. In order to do so the tools that utilize the standard must become more easily used by users, and perhaps more importantly users that don’t have a foreknowledge of SPDX. The tools should not only enable SPDX creation and consumption, but promote the use of SPDX, provide knowledge of what is being captured and stored in an SPDX document. Goals Redesign the current user interface of FOSSology+SPDX. Current interface isn’t as intuitive as it could be, the aim is to allow users with less knowledge of the SPDX standard to be able to understand how to use the system and potentially even learn something about SPDX in the process. Enhance the performance of the FOSSology scanning tool. Currently scanning packages can take a considerable amount of time. There needs to be a thorough analysis of how the process can be improved. Create a standard design template across the three systems. I would like to bring a uniformity to the three systems to express a commonality between the systems. Additional Features I would like to add an option to upload to Fossology+SPDX directly from an SPDX document. This will allow consumers of SPDX documents to be able to inventory the licenses the hold as well as provide an user friendly view of SPDX documents. Potential Targets Discuss the possibility of combining all three systems into one SPDX tool suite. Another project listed on http://www.linuxfoundation.org/collaborate/workgroups/gsoc/gsoc2014-spdx-projects is Online Validation Tools. This project entails a SPDX syntax validation tool which i believe, if the new FOSSology offers an SPDX document upload, it should be able to provide SPDX syntax validation at that point. Experience Senior Computer Science Student at the University of Nebraska at Omaha. Two years experience as a web application development intern at the Union Pacific Railroad. Created websites using: PHP, Cold Fusion, Javascript, CSS, and Jquery. Administrator of personal Linux web server for personal projects. Currently working on the Product History Utility team at the University of Nebraska at Omaha. Designed and implemented multiple databases in multiple environments: MySql, MS Sql, and PLSQL. Implementation Plan Identify and compile detailed list of problem areas on FOSSology+SPDX page. I will be talking to current users of the system as well as the developers to find out what needs updated. This will also allow me to determine which components of the system require attention. I need to get an idea of who is using this system and whom the SPDX community would like to have using this system in the future. Generate Use Cases and initial system specification document. I will be compiling the information gathered in part one of the implementation plan into a solution in the format of a system specification document and use cases. Make any necessary database schema modifications. I don’t anticipate any database schema changes. Create redesigned interface. During this time I will create the redesigned interface based upon the input from users and developers. The redesigned interface will serve as the first deliverable for midterm evaluation. Analyze FOSSology scanning process. Enhance the scanning process’s performance. Create additional functionality Adding the option to upload SPDX documents directly into the Dashboard. Create an SPDX parser that can review the syntax of an SPDX document and return any errors. Combine systems into a single entity. This will be based on how long the additional functionality takes to implement, and if there are other features the community would like to see added in place of a unified system. Additional Details The current revision of the SPDX specification is 1.2. There is currently a planned update to SPDX 2.0, changes regarding this update will need to be considered when designing the new interface. Summary I am currently a student contributing to SPDX projects at the University of Nebraska at Omaha. This proposal outlines the work I would like to continue to contribute to the SPDX Tooling project. The bulk of this project will be redesigning the FOSSology+SPDX user interface to create a more user oriented system, and improving the performance of the FOSSology source code scanner. ******************************* SPDX Merge Tool Student: Gang Ling (University of Nebraska at Omaha) Mentor: Gary O'Neall [email protected]/[email protected] Project Details The Merge tool will include the following main procedures: read two SPDX documents from user input; parse the two documents’ contents separately in each section; compare the contents at appropriate level (such as package level info.); merge the result from parsing and comparison; output new document in SPDX RDF format. Part of the project goal is using the existing tools and functions from SPDX java library. For example, when the program is parsing document, it will apply using RDF parser. After viewing the code of some SPDX tools, I can see the merge tool can borrow ideas from them. The SPDX Compare Utility provides the method of how to compare two SPDX documents. The SPDX Viewer gives the idea about how to format a SPDX document in RDF format. Therefore, I will use source code from SPDX to write the Merge program if the existing tools and functions give back results that fit to the requirements. Otherwise, I will contribute additional code to add new functionalities in the existing tools and functions to accomplish the tasks. I will follow the current code styles to keep the consistency in each program. Before starting to code, I plan to spend a short time to run and understand any function that I may use from SPDX java library. During the development, I will work closely with the SPDX Tech group. Report the project progress by weekly schedule. Later development suggestions to increase the usability: •Allow user to submit more than two SPDX documents to merge into a single document. •Allow user to submit different document format. Use FilenameUtils.getExtension to get file extension data. Then, call existing file translator tools to covert file into RDF format. •Allow user to choose output format. The merge tool prompt user to choose file format after the merge processes. Similar to the function above, call file translator tools to covert file as user needs. Success Criteria 1.Merge tool can be called from command line and promote to input two SPDX documents in RDF format. 2.Merge tool parse contents, compare contents, and merge contents correctly. 3.Merge tool can output new SPDX document in pretty format successfully. Timeline Here is a general view of my project timeline. Depends on the code progress, the date may shift. At the most situation, the date should shift ahead. 1.Set up the development environment. Run and understand the current SPDX tools and functions. Start working on the command line code and File I/O code. (April) 2.Document the command line user interface and review with community members and potential users. (April) 3.Work on the document parse section and content comparison section. (2nd -4th week of May) 4.Finish working on the content comparison section and start working on merge section. (1st -3rd week of June) 5.Work on the output format section. (4th week of June to 3rd week of July) 6.Run the test and solve the code problems. (4th week of July to 1st week of August) 7.Deliver Merge tool to the SPDX Tech group. (August 9th) Additional Information I am a current undergraduate student major at Management Information System. I took three programming courses in the past. Two of them are Java programming, and rest one is about Perl, Html, and XML. I really like programming, but most of works I have done are in class project and homework. From Professor Matt’s class last semester, I heard SPDX project and interested at it. This semester, I begin to work at the Open Source Lab. Therefore, I understand SPDX framework. The way that I handle a coding project is getting the core functions done first. I make sure my program does the most important goal of the project. Then, I will simplify the code to improve the program performance.
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
