Mission and principles
Source Commons Framework (SCF) is a digital commons for documenting, connecting, evaluating, and reusing sources, tools, use cases, methods, and data models. The project follows two defaults: the software core is open source and the graph of public contributions is open data. Exceptions—especially closed Spaces, personal data, secrets, third-party copyrighted content, and Enterprise capabilities—must be explicit.
SCF does not claim ownership of metadata already maintained by a legitimate provider. An external reference retains its URL, provider, and provenance. SCF publishes what its community actually creates: relationships, original descriptions, evaluations, methods, annotations, and models, within the rights held by their authors.
Project stewardship
Source Commons is the project's maintainer and operational steward. It maintains the code, public infrastructure, releases, security, migrations, and contribution processes. Source Commons uses SCF as the foundation for its own projects and client work—the “eat your own dog food” principle. Production needs should improve the shared core whenever the resulting work is generalizable and can be published.
The community includes users, content contributors, developers, data maintainers, public organizations, companies, and technical partners. A contribution does not automatically grant maintainer status, but a record of reliable contributions can lead to greater responsibility.
Decisions and changes
Decisions follow traceability and proportionality:
- factual fixes and reversible changes can be reviewed and merged quickly;
- changes to the model, API, licenses, security, or compatibility must be documented, discussed publicly, and accompanied by a migration plan;
- changes affecting a closed Space or organization require the corresponding rights and do not become public by default;
- Source Commons has final responsibility for security, compliance, service operations, and project consistency, and publishes the rationale whenever doing so does not create risk.
Disagreements should focus on facts, impacts, tests, and user needs. The code of conduct applies to contribution and discussion spaces.
Contributions, provenance, and moderation
A contribution must be accurate to the best of the contributor's knowledge, attributable, verifiable, and compatible with applicable rights. Canonical URLs and provider identifiers are preferred over copies. Evaluations should identify their target, metric, date, method, and confidence.
Maintainers may correct, merge, unpublish, or remove content that is misleading, unlawful, dangerous, insufficiently sourced, or license-incompatible. Corrections retain history where reasonable. Security or sensitive-data reports should not be exposed in a public discussion before they are handled.
Third-party content remains subject to its own license and terms. Referencing a dataset, repository, or API does not place that content under an SCF license.
Open source and open data by default
Core code should remain inspectable, modifiable, and reusable. Public data and contributions created in SCF should remain exportable in interoperable formats. The JSON API and Parquet export of the public graph implement this principle. Cached external metadata is neither claimed nor re-exported as canonical SCF truth.
“By default” does not mean “without controls.” Confidentiality, security, contracts, intellectual-property rights, and the protection of people take priority. Closed and Enterprise Spaces support non-public work when the context requires it.
Licenses
| Scope | License | Coverage | Rationale |
|---|---|---|---|
| Code | Apache License 2.0 | SCF application, services, libraries, and software components published by the project. | Allows commercial use, modification, redistribution, and integration into proprietary products, with conditions and patent protections suited to adoption by governments, companies, open-data communities, and technical providers. |
| Catalog and original contributions | Creative Commons Attribution 4.0 | Original descriptions, quality evaluations, methodologies, structured comments, risk notes, guides, editorial documentation, and composed datasets when SCF or the contributor holds the rights. | Allows copying, adaptation, and commercial use with attribution and an indication of changes. It also covers sui generis database rights and supports provenance, traceability, and recognition. |
| Data model and specifications | CC0 1.0 | Technical property names, JSON schemas, DCAT/DQV profiles, status lists, controlled vocabularies, identifiers, and minimal implementation examples. Components distributed as software may use Apache-2.0. | Lets a government, vendor, open-source project, or proprietary platform implement the model without adding attribution to every API, file, or interface. |
The following social attribution is appreciated for the data model, but is not a legal condition of CC0:
The Source Commons Data Model is maintained by the Source Commons community. Attribution is appreciated but not required.
A contribution can only be offered under CC BY 4.0 or CC0 when its author has the necessary rights. Trademarks, names, and logos are not automatically licensed by these terms.
Economic model
Adoption, inspection of the open-source core, and reuse of public data should not depend on a proprietary license. The economic model funds capabilities beyond that baseline:
- managed hosting and operations;
- private, closed, and Enterprise Spaces;
- advanced compute, automation, and AI capabilities;
- connectors and integrations;
- catalog quality, curation, and maintenance;
- sector expertise;
- brand, community operations, and community growth;
- data-product creation engagements for organizations and clients.
Pricing therefore covers service levels, higher capabilities, operated resources, and expertise—not the closure of the common core.
Autonomy, hosting, and independence
The goal is to move progressively toward autonomous hosting and independent tools that can be installed or replaced without a mandatory dependency on the managed service. This is not a claim that every component is already self-hostable today. User revenue funds component separation, operations documentation, exports, open standards, and reduced proprietary dependencies.
The managed service remains valuable to organizations that want to delegate operations, updates, security, and support. Autonomy and managed hosting should reinforce each other: generic improvements funded by paid use return to the open core whenever they can be published.
Open roadmap
The Roadmap shows available, alpha, beta, and planned capabilities. Priorities are guided by real portal use, reusable client work, community feedback, security, interoperability, and maintainability. A roadmap date is an estimate, not a contractual commitment unless separately agreed.
Requests should describe the problem, affected users, data or interfaces, risks, and an acceptance criterion. Experiments may remain in alpha until their data model, security, and operational cost are sufficiently understood.
Amending this governance
This governance evolves with the project. Any material change to licenses, maintainer responsibility, openness defaults, or decision processes must be announced, explained, and versioned. Editorial corrections may be published directly as long as they do not change the meaning of these commitments.