Open-Source License Research for NMKR Studio
Research Overview
**Date**: October 9, 2025
**Purpose**: Determine the most appropriate open-source license for NMKR Studio
**Scope**: Analysis of major open-source licenses and their implications
---
1. Executive Summary
This document presents research on open-source licenses suitable for NMKR Studio, a comprehensive NFT management platform for the Cardano blockchain. Based on the analysis, **three primary license options** are recommended, each with distinct characteristics suited to different strategic goals.
Key Findings
- **Most Permissive**: MIT or Apache 2.0 License
- **Protective (Copyleft)**: GPL-3.0
- **Business-Friendly with Restrictions**: AGPL-3.0 or Business Source License (BSL)
---
2. Project Context
2.1 NMKR Studio Characteristics
- **Type**: Full-stack web application (.NET 8.0, C, Blazor)
- **Purpose**: NFT minting, management, and marketplace platform
- **Components**: API services, background workers, UI, shared libraries
- **Dependencies**: Multiple third-party packages with various licenses
- **Business Model**: Potentially commercial/SaaS
- **Community**: Open to contributions from Cardano developer community
2.2 Strategic Considerations
**Goals for Open-Sourcing:**
1. Foster community contribution and innovation
2. Build trust and transparency in the Cardano ecosystem
3. Enable developers to self-host and customize
4. Protect against unauthorized commercial exploitation (optional)
5. Maintain flexibility for future commercial licensing (optional)
---
3. License Options Analysis
3.1 MIT License
Overview
The MIT License is one of the most permissive and popular open-source licenses.
Key Characteristics
**Permissions:**
- ✅ Commercial use
- ✅ Modification
- ✅ Distribution
- ✅ Private use
**Conditions:**
- ⚠️ License and copyright notice must be included
**Limitations:**
- ❌ No liability
- ❌ No warranty
Pros
- **Maximum Adoption**: Most permissive, encourages widespread use
- **Simple**: Easy to understand, minimal legal complexity
- **Compatible**: Compatible with almost all other licenses
- **Business-Friendly**: Companies can use, modify, and even create closed-source derivatives
- **Low Friction**: No requirements to share modifications
Cons
- **No Protection**: Others can create competing closed-source products using your code
- **No Copyleft**: Improvements don't have to be shared back
- **Attribution Only**: Only requires copyright notice, not code sharing
Use Case for NMKR Studio
✅ **Best if**: You want maximum adoption and don't care if companies create closed-source versions
❌ **Not ideal if**: You want to ensure modifications remain open-source or prevent commercial competition
---
3.2 Apache License 2.0
Overview
Similar to MIT but with explicit patent grant and trademark protection.
Key Characteristics
**Permissions:**
- ✅ Commercial use
- ✅ Modification
- ✅ Distribution
- ✅ Private use
- ✅ Patent use
**Conditions:**
- ⚠️ License and copyright notice
- ⚠️ State changes (document modifications)
**Limitations:**
- ❌ No trademark use
- ❌ No liability
- ❌ No warranty
Pros
- **Patent Protection**: Explicit patent grant protects users from patent litigation
- **Trademark Protection**: Explicitly prevents trademark use without permission
- **Business-Friendly**: Like MIT, allows commercial closed-source derivatives
- **Change Documentation**: Requires stating what was changed (better for tracking modifications)
- **Industry Standard**: Used by major projects (Android, Apache projects, Kubernetes)
Cons
- **Slightly More Complex**: More legal text than MIT
- **No Copyleft**: Like MIT, doesn't require sharing modifications
- **License Compatibility**: Incompatible with GPL-2.0 (but compatible with GPL-3.0)
Use Case for NMKR Studio
✅ **Best if**: You want MIT-style permissiveness but with patent protection and trademark control
✅ **Recommended if**: NMKR has or will have patents related to the technology
❌ **Not ideal if**: You want to ensure all derivatives remain open-source
---
3.3 GNU General Public License v3.0 (GPL-3.0)
Overview
Strong copyleft license ensuring all derivatives remain open-source.
Key Characteristics
**Permissions:**
- ✅ Commercial use
- ✅ Modification
- ✅ Distribution
- ✅ Private use
**Conditions:**
- ⚠️ Disclose source code
- ⚠️ License and copyright notice
- ⚠️ State changes
- ⚠️ Use same license (copyleft)
**Limitations:**
- ❌ No liability
- ❌ No warranty
Pros
- **Strong Copyleft**: All derivatives must be open-source under GPL-3.0
- **Community Protection**: Prevents companies from creating closed-source versions
- **Patent Protection**: Includes patent grant similar to Apache 2.0
- **Anti-Tivoization**: Prevents hardware lockdown that restricts modification
- **Established**: Well-understood and widely used (Linux kernel, GNU tools)
Cons
- **Business Restrictions**: Many companies avoid GPL code due to copyleft requirements
- **License Compatibility**: Incompatible with some licenses (MIT/Apache can be integrated, but result must be GPL)
- **Reduced Adoption**: May limit commercial use and contributions
- **Complexity**: More complex license text and requirements
Use Case for NMKR Studio
✅ **Best if**: You want to ensure all forks and derivatives remain open-source
✅ **Good if**: You want to prevent competitors from creating closed-source versions
❌ **Not ideal if**: You want maximum commercial adoption or may want to dual-license later
---
3.4 GNU Affero General Public License v3.0 (AGPL-3.0)
Overview
GPL-3.0 with additional requirement: must share code even when running as a service.
Key Characteristics
Same as GPL-3.0, plus:
**Additional Condition:**
- ⚠️ **Network Use = Distribution**: If you run the software as a service (SaaS), you must provide source code to users
Pros
- **SaaS Protection**: Closes the "SaaS loophole" in GPL
- **Strongest Copyleft**: Even service providers must share modifications
- **Prevents Exploitation**: Companies can't run modified versions as SaaS without sharing code
- **True Open-Source**: Ensures even web services remain open
Cons
- **Very Restrictive**: Most restrictive major open-source license
- **Business Deterrent**: Many companies completely avoid AGPL code
- **Reduced Adoption**: Significantly limits commercial use
- **Complex Compliance**: Network provision requirement can be unclear
Use Case for NMKR Studio
✅ **Best if**: You want to prevent companies from running modified closed-source SaaS versions
✅ **Perfect for**: Preventing competitors from using your code in their own NFT platforms
⚠️ **Warning**: Will significantly reduce business adoption and contributions
❌ **Not ideal if**: You want broad commercial adoption
---
3.5 Mozilla Public License 2.0 (MPL-2.0)
Overview
Weak copyleft - only modified files must remain open-source.
Key Characteristics
**Permissions:**
- ✅ Commercial use
- ✅ Modification
- ✅ Distribution
- ✅ Private use
- ✅ Patent use
**Conditions:**
- ⚠️ Disclose source code (only for modified MPL files)
- ⚠️ Same license for modified files
**Limitations:**
- ❌ No trademark use
- ❌ No liability
Pros
- **Balanced**: Middle ground between permissive and copyleft
- **File-Level Copyleft**: Only modified files must stay open-source
- **Integration-Friendly**: New files can be proprietary
- **Patent Protection**: Includes patent grant
- **Business-Friendly**: More acceptable to businesses than GPL
Cons
- **Less Protection**: Easier to create mostly-closed derivatives
- **Complex**: File-level copyleft can be confusing
- **Less Common**: Not as widely understood as MIT/Apache/GPL
Use Case for NMKR Studio
✅ **Best if**: You want some protection but more flexibility than GPL
⚠️ **Moderate choice**: Compromise between permissive and protective
---
3.6 Business Source License (BSL) 1.1
Overview
Source-available license that converts to open-source after a period.
Key Characteristics
**Initial Period (e.g., 4 years):**
- ⚠️ Source code is visible but usage is restricted
- ❌ Limited to specific use rights (e.g., no competing SaaS)
- ⚠️ Must define "Additional Use Grant"
**After Conversion Date:**
- ✅ Automatically converts to permissive license (e.g., Apache 2.0)
- ✅ Becomes fully open-source
Pros
- **Delayed Competition**: Prevents immediate commercial competition
- **Eventually Open**: Guarantees eventual open-source release
- **Business Protection**: Protects commercial interests during critical period
- **Flexibility**: Can define specific prohibited uses
- **Popular**: Used by companies like MariaDB, CockroachDB, Sentry
Cons
- **Not True Open-Source**: OSI does not recognize BSL as open-source
- **Complex**: Requires defining conversion date and use grants
- **Trust Issues**: Community may be skeptical of delayed opening
- **Legal Complexity**: More complex than standard licenses
Use Case for NMKR Studio
✅ **Best if**: You want to prevent competitors while planning eventual full open-source
✅ **Good for**: Protecting a business model while showing commitment to openness
❌ **Not true open-source**: Cannot claim to be fully open-source initially
---
4. License Comparison Matrix
| Feature | MIT | Apache 2.0 | GPL-3.0 | AGPL-3.0 | MPL-2.0 | BSL 1.1 |
|---------|-----|------------|---------|----------|---------|---------|
| **Permissiveness** | Very High | Very High | Low | Very Low | Medium | N/A (Time-bound) |
| **Closed-Source Derivatives** | ✅ Allowed | ✅ Allowed | ❌ Prohibited | ❌ Prohibited | ⚠️ Partial | ❌ Initially |
| **Patent Protection** | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | Varies |
| **Trademark Protection** | ❌ No | ✅ Yes | ❌ No | ❌ No | ✅ Yes | Varies |
| **SaaS Must Share Code** | ❌ No | ❌ No | ❌ No | ✅ Yes | ❌ No | ⚠️ Depends |
| **Business Friendly** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| **Community Friendly** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| **Adoption Potential** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| **Competitive Protection** | ⭐ | ⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
---
5. Recommendations for NMKR Studio
5.1 Scenario-Based Recommendations
Scenario 1: Maximum Community Adoption
**Recommended License: Apache 2.0**
Choose if you want:
- Maximum adoption by developers and companies
- Patent and trademark protection
- Broad community contributions
- No restrictions on commercial use
**Rationale**: Apache 2.0 provides the best balance of permissiveness and protection. It's used by major enterprise projects and is well-understood by corporate legal teams.
---
Scenario 2: Prevent Closed-Source Competition
**Recommended License: AGPL-3.0**
Choose if you want:
- Strong protection against competitors creating closed-source versions
- Require SaaS providers to share modifications
- Ensure all derivatives remain open-source
- Willing to accept reduced commercial adoption
**Rationale**: AGPL-3.0 is the strongest protection available for SaaS applications. It prevents competitors from using your code in proprietary platforms.
---
Scenario 3: Balanced Approach
**Recommended License: GPL-3.0 or MPL-2.0**
Choose if you want:
- Moderate protection with reasonable adoption
- Ensure derivatives remain open-source (GPL-3.0)
- Or allow some proprietary integration (MPL-2.0)
**Rationale**: GPL-3.0 provides strong copyleft without the SaaS restriction of AGPL. MPL-2.0 offers file-level copyleft as a middle ground.
---
Scenario 4: Business Protection with Future Opening
**Recommended License: BSL 1.1 → Apache 2.0**
Choose if you want:
- Initially protect against competition (e.g., 2-4 years)
- Automatic conversion to fully open-source
- Show commitment to eventual openness
**Configuration Example**:
```
License: Business Source License 1.1
Change Date: 2029-10-09 (4 years from release)
Change License: Apache License 2.0
Additional Use Grant: Non-commercial use, research, and development
```
**Rationale**: Protects business interests during critical growth period while guaranteeing eventual full open-source release.
---
5.2 Final Decision
**NMKR Studio License: MIT License**
**Reasoning:**
1. **Maximum Adoption**: Encourages the widest possible adoption in the Cardano ecosystem
2. **Simplicity**: Easiest to understand for contributors and users
3. **Business-Friendly**: Enables companies and developers to use, modify, and integrate without restrictions
4. **Community Growth**: Removes barriers to contribution and collaboration
5. **Ecosystem Alignment**: Many successful blockchain projects use permissive licenses
6. **Universal Compatibility**: Works with virtually all other open-source licenses
7. **Developer Freedom**: Empowers developers to build on top of NMKR Studio however they see fit
**Trade-offs Accepted:**
While MIT License doesn't provide patent protection (Apache 2.0) or prevent closed-source derivatives (GPL/AGPL), NMKR Studio prioritizes:
- Community growth over competitive protection
- Adoption over restriction
- Simplicity over legal complexity
- Enabling innovation over controlling usage
---
6. License Compatibility with Dependencies
6.1 Common .NET Dependencies
Most .NET libraries use permissive licenses:
- **MIT**: Most NuGet packages
- **Apache 2.0**: Microsoft libraries, ASP.NET Core
- **BSD**: Some database drivers
6.2 Compatibility Chart
| Your License | Can Use MIT | Can Use Apache | Can Use GPL | Can Use AGPL |
|--------------|-------------|----------------|-------------|--------------|
| **MIT** | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| **Apache 2.0** | ✅ Yes | ✅ Yes | ⚠️ GPL-3.0 only | ❌ No |
| **GPL-3.0** | ✅ Yes | ✅ Yes | ✅ Yes | ⚠️ Must be AGPL |
| **AGPL-3.0** | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
**Note**: When combining licenses, the result must comply with the most restrictive license.
---
7. Legal Considerations
7.1 License Headers
Whichever license you choose, add headers to source files:
```csharp
// Copyright (c) 2025 NMKR Studio
// Licensed under the MIT License
// See LICENSE file in the project root for full license information.
```
7.2 Third-Party Attribution
Create `NOTICE` file listing all third-party dependencies and their licenses.
7.3 Contributor License Agreement (CLA)
Consider requiring contributors to sign a CLA to:
- Ensure you have rights to their contributions
- Protect against future license issues
- Allow potential dual-licensing
---
8. Implementation Checklist
- [x] Choose license based on strategic goals - **MIT License Selected**
- [ ] Create `LICENSE` file in repository root with MIT License text
- [ ] Add license headers to all source files
- [ ] Create `NOTICE` file with third-party attributions
- [ ] Update `README.md` with license information
- [ ] Add MIT license badge to README
- [ ] Set GitHub repository license metadata to MIT
- [ ] Consider CLA for contributors (optional for MIT)
- [x] Document license choice and reasoning - **Completed in this document**
---
9. References and Resources
9.1 Official License Texts
- MIT: https://opensource.org/licenses/MIT
- Apache 2.0: https://www.apache.org/licenses/LICENSE-2.0
- GPL-3.0: https://www.gnu.org/licenses/gpl-3.0.html
- AGPL-3.0: https://www.gnu.org/licenses/agpl-3.0.html
- MPL-2.0: https://www.mozilla.org/MPL/2.0/
- BSL 1.1: https://mariadb.com/bsl11/
9.2 License Selection Tools
- Choose a License: https://choosealicense.com/
- SPDX License List: https://spdx.org/licenses/
- TLDRLegal: https://tldrlegal.com/
9.3 Additional Reading
- "Understanding Open Source Licensing" - O'Reilly
- GitHub's License Guide: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
---
10. Conclusion
The choice of open-source license for NMKR Studio depends on strategic priorities:
- **Want maximum adoption?** → **MIT or Apache 2.0**
- **Want to prevent competition?** → **AGPL-3.0**
- **Want middle ground?** → **GPL-3.0 or MPL-2.0**
- **Want time-delayed opening?** → **BSL 1.1**
**Final Decision: NMKR Studio has chosen the MIT License**, prioritizing maximum adoption, simplicity, and developer freedom. This reflects the project's commitment to fostering an open, collaborative ecosystem in the Cardano blockchain space where innovation and community growth are valued over competitive protection.
---
**Document Version**: 1.1
**Date**: October 9, 2025
**Prepared By**: NMKR Studio Open-Source Committee
**Status**: Final Decision - MIT License Selected
