Ignoring open source package issues

Considerations when ignoring issues

When implementing ignore rules for open source issues, it is important to start conservatively. Initially, only ignore issues on a project-level basis for the specific version of the package being used. This cautious approach ensures that no critical issues are overlooked. As you gain more understanding of how a package is utilized within your organization, you can broaden the ignore scope. This can be done by updating the ignore rules to apply to the entire policy or even globally for all versions of the package.

Types of issues to ignore

Licenses in Example, Test, and Documentation Directories

Common Directories to Consider:

• examples/
• tests/
• docs/
• sample/
• demo/

Licenses to Watch For:

• Copyleft Licenses: GPL, LGPL, AGPL and the like
• Creative Commons Licenses

Ignore These Licenses If:

1. Non-Distributed Code: The files are not included in your distributed product or application.
2. Test Dependencies: The files are only used during testing and not in production.
3. Documentation and Samples: The files are solely for reference or educational purposes and are not part of the final product.

Test Dependencies

Common Issues with Test Dependencies:

• License Mismatches: Test dependencies may have licenses that are incompatible with your main project.
• Security Vulnerabilities: Issues found in test dependencies that do not affect the production code.

Ignore These Issues If:

1. Not in Production: The test dependencies are not included in the production environment.
2. Temporary Use: The dependencies are only used during the development phase and not shipped with the final product.

Documentation Licenses

Common Directories to Consider:

• docs/
• manual/
• guide/

Licenses to Watch For:

• Creative Commons: Often used for documentation and/or pertaining to a package’s logo.

Ignore These Licenses If:

1. Not Part of Codebase: The documentation is not bundled with the software product.
2. Reference Only: The documentation serves as a reference for developers and is not redistributed.

Build Scripts and Configuration Files

Common Files to Consider:

• Makefile
• Dockerfile
• .travis.yml
• Jenkinsfile

Licenses to Watch For:

• Varied: Build scripts may come with different licenses, but they generally do not affect the distribution of the software.

Ignore These Licenses If:

1. Build Only: The files are used exclusively for building the software and are not included in the distributed product.
2. Internal Use: The scripts are for internal development processes.
3. 
   

License Headers in Code Snippets and Templates

Common Issues:

• License Headers: Code snippets or templates may contain license headers from different open source projects.

Ignore These Issues If:

1. Non-Executable Code: The snippets or templates are not part of the executable code in the final product.
2. Reference Material: The snippets are used for educational or reference purposes only.

Summary

When managing open source projects, focus on the code and dependencies that are directly included in the distributed product. You can typically ignore licenses and issues in directories and files meant for development, testing, documentation, and examples, as long as they do not affect the production environment or are not redistributed with the final product.