Skip to content

MBARI Software Licensing Guide

For Engineers and Software Developers

Version 1.0 | January 2026

Quick Reference

Default License: Apache 2.0

Decision Time: 2 minutes or less

Questions? Contact: TBD (IP Committee)

Choosing the Right License

Choosing the right license:

  • Protects MBARI and our collaborators
  • Enables scientific collaboration
  • Complies with funding requirements
  • Clarifies intellectual property rights
  • Supports MBARI's mission as a 501(c)(3) research institute

The Simple Decision Tree

START: I'm creating a new software project
    │
    ├─→ Contains ITAR/EAR restricted technology?
    │   └─→ YES → Keep PRIVATE, contact legal before any release
    │   
    ├─→ Already has a commercial license agreement?
    │   └─→ YES → Contact tech transfer office, may need dual-licensing
    │
    ├─→ Collaborative project with external partners?
    │   └─→ YES → Match their license OR use Apache 2.0 (if no preference)
    │
    ├─→ Want to ensure derivatives stay open-source?
    │   └─→ YES → Use GPL-3.0 or AGPL-3.0
    │
    ├─→ Simple utility, script, or small library?
    │   └─→ YES → Use MIT (simpler) or Apache 2.0
    │
    └─→ Everything else?
        └─→ Use Apache 2.0 (default)

License Quick Reference

License When to Use Key Feature MBARI Usage
Apache 2.0 Default choice for most projects Patent protection, permissive Most common
MIT Simple utilities, small libraries Very simple, widely understood Alternative
BSD-3-Clause Legacy compatibility needed Similar to MIT with attribution Occasional
GPL-3.0 Derivatives must stay open Copyleft protection Strategic use
AGPL-3.0 Web services that must stay open Network copyleft Rare, web services

Common Scenarios

Scenario 1: New Data Processing Tool

Situation: Building a Python tool to process ROV navigation data
License: Apache 2.0
Why: Standard research tool, want broad adoption, patent protection

Scenario 2: Quick Utility Script

Situation: Bash script to convert file formats
License: MIT
Why: Simple, low complexity, no patent concerns

Scenario 3: AUV Control Software

Situation: Core software that interfaces with expensive hardware
License: Apache 2.0
Why: Patent protection important, widely used by collaborators

Scenario 4: Collaborative Machine Learning Project

Situation: Joint project with three other oceanographic institutions
License: Apache 2.0 (or match partner's preference)
Why: Standard for ML research, patent clarity, NSF-friendly

Scenario 5: Modified Open-Source Web Application

Situation: Forked annotation tool that others should be able to improve
License: Match original (likely GPL-3.0 or AGPL-3.0)
Why: Derivative work license compatibility

Scenario 6: Export-Controlled Navigation System

Situation: Software using ITAR-restricted GPS/navigation tech
License: None - keep private
Why: Legal requirement, cannot be publicly released

License Explanations

What it means: - Anyone can use, modify, and distribute the code - Includes explicit patent grant (you can't sue users for patent infringement) - Requires attribution and license notice - Changes must be documented

Best for: - Research tools and libraries - Projects with potential patent concerns - Collaboration with industry partners - NSF/NOAA funded projects

MIT

What it means: - Anyone can use, modify, and distribute the code - Very short, simple license - Only requires attribution and license notice - No explicit patent grant

Best for: - Small utilities and scripts - Projects with no patent concerns - Maximum simplicity desired

GPL-3.0

What it means: - Anyone can use, modify, and distribute - Derivatives MUST also be GPL-3.0 (copyleft) - Ensures modifications remain open-source - Strong community protection

Best for: - Projects where keeping derivatives open is critical - Community-driven development - When you want to prevent proprietary forks

Special Cases

ITAR/EAR Restrictions

  • DO NOT make public without legal clearance
  • Keep in private repositories
  • Maintain list of restricted projects
  • Contact: TBD [Legal Contact]

Commercial Licensing

  • Some MBARI technology has been licensed commercially
  • May require dual-licensing (open + commercial)
  • MUST consult tech transfer office first
  • Contact: TBD[Tech Transfer Contact]

Grant Requirements

  • Check funding agency requirements
  • NSF: Generally expects open-source
  • NOAA: Policy NAO 201-118 requires open licensing
  • Private foundations: Check agreement terms
  • If unsure, contact: TBD[Grants Office]

Third-Party Dependencies

  • Your license must be compatible with dependencies
  • Apache 2.0 is compatible with most licenses
  • GPL requires careful compatibility checking
  • When in doubt, check: https://choosealicense.com/appendix/

Implementation Checklist

When creating a new repository:

  • Choose appropriate license using decision tree
  • Add LICENSE file to repository root
  • Add license notice to README.md
  • Include copyright notice in LICENSE file
  • Add license headers to source files (optional but recommended)
  • Document third-party dependencies and their licenses

File Header Templates

Apache 2.0 Header (Python)

# Copyright (c) 2026 Monterey Bay Aquarium Research Institute
# SPDX-License-Identifier: Apache-2.0

Apache 2.0 Header (Java/C++)

// Copyright (c) 2026 Monterey Bay Aquarium Research Institute
// SPDX-License-Identifier: Apache-2.0

MIT Header (Python)

# Copyright (c) 2026 Monterey Bay Aquarium Research Institute
# SPDX-License-Identifier: MIT

README.md License Section Template

Add this to your README.md:

## License

This project is licensed under the Apache License 2.0 - see the [LICENSE](LICENSE) file for details.

Copyright (c) 2026 Monterey Bay Aquarium Research Institute

FAQ

Q: Can I change the license later?
A: Yes, but it's complicated. Best to choose correctly from the start. All previous versions remain under the old license.

Q: What if collaborators want a different license?
A: Discuss with them early. Apache 2.0 is usually acceptable. If not, document the reasoning and get approval.

Q: Do I need a license for internal-only code?
A: No, but it's good practice. Assume everything might eventually be shared.

Q: What about data, not code?
A: Use Creative Commons licenses (typically CC BY 4.0). Not covered in this guide.

Q: Can I use code from Stack Overflow?
A: Small snippets are typically fine (fair use). Larger portions require checking the license. When in doubt, rewrite it.

Q: What if I'm modifying existing open-source code?
A: You typically must keep the original license. Check the original project's license terms.

Q: Someone wants to use our code commercially. Is that OK?
A: With Apache 2.0 or MIT, yes! That's the point. GPL-3.0 requires them to open-source their derivatives.

Resources

MBARI Resources

  • GitHub Organization: https://github.com/mbari-org
  • License Templates: https://github.com/mbari-org/.github
  • Tech Transfer Office: [Contact]
  • Legal: [Contact]

External Resources

  • Choose a License: https://choosealicense.com/
  • Apache 2.0 Full Text: https://www.apache.org/licenses/LICENSE-2.0
  • MIT Full Text: https://opensource.org/licenses/MIT
  • GPL-3.0 Full Text: https://www.gnu.org/licenses/gpl-3.0.en.html
  • SPDX License List: https://spdx.org/licenses/

Peer Institutions

  • OOI Licensing: https://github.com/oceanobservatories
  • WHOI Licensing: https://github.com/WHOIGit
  • NOAA Policy: https://www.noaa.gov/administration/nao-201-118-software-governance-and-public-release-policy

Contact

Questions about licensing?

  • Software Engineering Lead: [Name/Email]
  • Tech Transfer Office: [Name/Email]
  • Legal Counsel: [Name/Email]

Still not sure?

When in doubt, use Apache 2.0 and reach out for a quick review.

Document History

  • v1.0 (January 2026): Initial release based on peer institution research

This guide is intended to help MBARI engineers make informed licensing decisions. It does not constitute legal advice. For specific legal questions, consult MBARI's legal counsel.