| Category | Evaluation Metric | Technical / Legal Requirement | Resourcing & Labor Impact |
|---|---|---|---|
| 🛡️ Freedom 0: Right to Use | [ ] Infrastructure Fit | Software can be executed indefinitely on domestic bare-metal servers or fully controlled, sovereign infrastructure. | University has the physical server capacity, storage, cooling, and electricity budget to run the software locally. |
| [ ] Zero Policy Risk | License is free from restrictions regarding user counts, academic department types, or geopolitical usage limits. | Current infrastructure team has the training and bandwidth to deploy this platform without dropping existing services. | |
| [ ] Emergency Isolation | System can function completely offline or air-gapped during a network crisis without requiring an external cloud handshake. | Team has allocated manual staff hours to manage system updates if the environment is kept completely offline for maximum security. | |
| [ ] No Forced Deactivations | Platform architecture guarantees that an external vendor cannot remotely disable or lock the university out. | — | |
| 🔍 Freedom 1: Right to Inspect | [ ] Code Visibility | Full, human-readable source code is completely accessible, unencrypted, and auditable by internal cybersecurity teams. | University employs qualified internal cybersecurity staff capable of auditing an open codebase, avoiding expensive consultants. |
| [ ] Independent Testing | University has the explicit legal right to perform vulnerability scans and threat models without seeking vendor permission. | Specific roles within the IT security team are assigned to monitor and disable hidden data-tracking or telemetry pings. | |
| [ ] Data Transparency | System stores, formats, and exports all information in open, non-proprietary formats to maintain clear pipeline visibility. | Existing university security orchestration and scanning tools can scan this specific codebase automatically. | |
| [ ] Zero Hidden Backdoors | Codebase is verified to ensure it is free from hidden foreign tracking tools, unauthorized telemetry, or silent auto-updates. | — | |
| 🔄 Freedom 2: Right to Share | [ ] Licensing Freedom | Open-source license explicitly allows the university to duplicate and distribute copies across campuses without per-seat fees. | University has legal and administrative staff available to manage shared governance and cost-splitting with partner schools. |
| [ ] Consortium Fit | Software can legally and technically be co-hosted with partner universities or provincial bodies to pool infrastructure costs. | Internal IT team possesses enough foundational knowledge to switch support vendors smoothly if market costs rise. | |
| [ ] No Artificial Barriers | Zero technical restrictions preventing the software from being modified and handed over to allied public institutions. | IT engineers have dedicated time allocated to write internal deployment documentation so other departments can reuse the software. | |
| [ ] Supplier Diversity | Project is backed by a broad marketplace of independent support vendors, preventing single-vendor lock-in. | — | |
| 🛠️ Freedom 3: Right to Modify | [ ] Upstream Alignment | Project's codebase is structured cleanly so that local modifications can easily stay synchronized with the main public repository. | System's custom code is thoroughly documented internally so that if a lead developer leaves the university, the project does not collapse. |
| [ ] Custom Patching | Internal IT engineers have the technical capacity to write, compile, and deploy a critical security hotfix immediately during a crisis. | University dedicates an explicit percentage of staff hours each year solely to keep local customizations compatible with global updates. | |
| [ ] Sovereign Hardening | Software architecture allows developers to strip out non-compliant features to build a version that respects local privacy laws (like FIPPA). | IT department has an on-call rotation of skilled developers capable of hotfixing the open codebase on weekends or during outages. | |
| [ ] Upgrade Longevity | Custom modifications are kept modular to avoid a "hard fork" nightmare that blocks the university from receiving future upgrades. | — | |
| 🏗️ Sustainability Layer | [ ] Ecosystem Metrics | Software is actively backed by a vibrant, multi-organization public community rather than being an orphaned or dying repository. | Core operational and security features are fully open-source, rather than being gated behind a vendor's proprietary commercial plugin layer. |
The university must formally select and fund one of the three resource models below before signing the procurement order:
- CO-MANAGED MODEL (Low Resources): We pay a trusted local vendor to host and maintain the open software. We retain ownership of the data and code, but outsource the daily labor.
- CONSORTIUM MODEL (Medium Resources): We pool our money and IT staff with 3–4 partner universities. We split the hosting costs and maintenance responsibilities equally.
- FULLY SOVEREIGN MODEL (High Resources): We have a dedicated, permanent team of in-house open-source engineers. We run, secure, patch, and modify everything completely on our own.
To make this matrix operational, consider:
- Turning this table into an RFP questionnaire with written response fields for vendors.
- Developing a numerical scoring system to weight the operational impact versus technical compliance.
- Reviewing specific open-source licensing types (like AGPL vs. MIT) to auto-fill the legal columns.