Wiki source code of Open Source Model and Licensing

Last modified by Robert Schaub on 2026/02/08 08:30

version	line-number	content
1.1	1	= Open Source Model and Licensing =
1.2	2
1.1	3	== 1. Purpose and Relation to Other Documents ==
1.2	4
1.1	5	This page explains how FactHarbor is run from a licensing and enforcement perspective – as an open, trustworthy, non-profit oriented, but professionally maintained project.
	6	It covers in particular:
1.2	7
1.1	8	* the licensing choices for code, documentation, data, and core specifications,
	9	* how contributors grant the project the right to use and enforce those licenses,
	10	* how AI-related components (such as AKEL) fit into the licensing picture,
	11	* how licence choices support manipulation-resistance and long-term openness,
	12	* organisational transparency commitments,
	13	* privacy and data protection standards.
	14	Together with the other Organisation pages, it defines how FactHarbor is run:
1.2	15	* [[Governance>>Archive.FactHarbor 2026\.02\.08.Organisation.Governance.WebHome]] – who decides what, and under which principles
1.1	16	* [[Finance & Compliance>>FactHarbor.Organisation.Finance-Compliance]] – how funding, transparency, and internal controls work
	17	* [[Legal Framework>>FactHarbor.Organisation.Legal-Framework]] – legal forms, contracts, and regulatory aspects
	18	The Specification (Mission, Requirements, Architecture, Data Model, Workflows, etc.) describes what FactHarbor does.
	19	This Open Source Model and Licensing page (together with Governance and Finance & Compliance) describes how FactHarbor is run and protected.
	20	For historical context, earlier drafts used a purely AGPLv3-centric model for the core software.
	21	The current licence mix is defined in the sections below and takes precedence over any older drafts.
1.2	22
1.1	23	== 2. Overview ==
1.2	24
1.1	25	FactHarbor is, and will remain, an open source project that:
1.2	26
1.1	27	* publishes its work openly whenever legally and ethically possible
	28	* makes its reasoning and evidence inspectable
	29	* invites contributions under clear, transparent rules
	30	* avoids situations where a "FactHarbor-branded" system becomes a black box
	31	* maintains exceptional organisational transparency to build trust
	32	This page defines:
	33	* the licensing choices currently used,
	34	* the goals and principles behind these choices,
	35	* how contributors are governed from a licensing/enforcement perspective,
	36	* how AI models and third-party components are handled,
	37	* the standards that repositories must follow,
	38	* organisational transparency and privacy commitments.
	39	Normative licensing decisions on this page override any older variants or drafts.
1.2	40
1.1	41	== 3. Licensing (Current Decisions) ==
1.2	42
1.1	43	=== 3.1 Documentation ===
1.2	44
1.1	45	All general documentation (organisational and technical) is licensed under:
1.2	46
1.1	47	* Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0)
	48	This allows:
	49	* reuse, adaptation, and translation of documentation,
	50	* including commercial reuse,
	51	* as long as:
1.2	52	* clear attribution to FactHarbor is preserved, and
	53	* derivative works are shared under the same license (CC BY-SA 4.0).
1.1	54	Exception handling:
	55	* In rare cases, security-sensitive or abuse-enabling documentation may be:
1.2	56	* published only in partial form, or
	57	* made available under more restrictive terms, or
	58	* kept internal.
1.1	59	* Any such exceptions must be explicitly documented where they apply.
1.2	60
1.1	61	=== 3.2 Core Protocol & Data Model ===
1.2	62
1.1	63	The core protocol, core data model (including key ERDs), and other "defining specifications" are licensed under:
1.2	64
1.1	65	* Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0)
	66	Intent:
	67	* enable collaborative evolution of the protocol and data model,
	68	* allow broad reuse, referencing, and implementation,
	69	* ensure derivative specifications remain open (share-alike requirement),
	70	* maintain canonical status through trademark control rather than license restrictions.
	71	Implications:
	72	* You may use, implement, and modify the protocol/data model in your own systems.
	73	* You may publish derivative or modified specifications under CC BY-SA 4.0.
	74	* Derivative specifications must:
1.2	75	* be clearly attributed to FactHarbor,
	76	* use different branding/names (trademark protection),
	77	* state they are "derived from FactHarbor protocol",
	78	* remain under CC BY-SA 4.0 (share-alike).
1.1	79	* Changes to the canonical FactHarbor specification are governed through FactHarbor's internal review and release processes.
	80	Trademark Protection:
	81	The "FactHarbor" name and associated marks are protected separately from the license. Derivative protocols may not use "FactHarbor" branding without explicit permission, ensuring users can distinguish official from derivative implementations.
	82	This approach (license for sharing + trademark for brand protection) follows successful models like Mozilla Firefox and the W3C.
1.2	83
1.1	84	=== 3.3 Code ===
1.2	85
1.1	86	Default License: Unless explicitly stated otherwise, code produced under the FactHarbor project is licensed under:
1.2	87
1.1	88	* MIT License
	89	This allows:
	90	* broad reuse, including in commercial software,
	91	* proprietary integrations and extensions,
	92	* as long as:
1.2	93	* the MIT license text is included, and
	94	* attribution to the FactHarbor project is preserved.
1.1	95	Hybrid Licensing for Core Components:
	96	For the core reasoning engine and AKEL components, we recommend using AGPL-3.0 to prevent black-box deployments and ensure transparency of modifications.
	97	The recommended hybrid approach:
	98	* AGPL-3.0 for: Core verdict engine, AKEL reasoning logic, scenario evaluation engine
	99	* MIT for: Integrations, utilities, frontend clients, libraries, tools
	100	This hybrid model (similar to Wikimedia's use of AGPL for MediaWiki) balances maximum adoption with protection of the transparency mission.
	101	Rationale:
	102	* AGPL-3.0 is network copyleft – requires source disclosure for network services
	103	* Prevents "FactHarbor-as-a-service" black boxes that contradict transparency mission
	104	* MIT for peripheral components maximizes ecosystem growth
	105	* Strong protection of openness of reasoning is handled via:
1.2	106	* open protocol and data model (CC BY-SA),
	107	* open documentation (CC BY-SA),
	108	* AGPL for core reasoning components,
	109	* and explicit transparency rules.
1.1	110	The decision to implement this hybrid model should be made explicitly before the first public release.
1.2	111
1.1	112	=== 3.4 Structured Data & Curation Artefacts ===
1.2	113
1.1	114	Structured data, curated knowledge artefacts and derived datasets are licensed under:
1.2	115
1.1	116	* Open Database License (ODbL)
	117	Note on ODbL: The Open Database License includes a share-alike requirement, ensuring derivative databases remain open. This aligns with FactHarbor's commitment to openness and prevents proprietary capture of community-curated data.
	118	Principles:
	119	* data used for public reasoning should be:
1.2	120	* reusable and remixable,
	121	* properly attributed,
	122	* versioned and traceable,
	123	* kept open through share-alike.
1.1	124	* privacy, safety, and legal constraints may require:
1.2	125	* partial publication or anonymity,
	126	* stronger access control around certain datasets.
1.1	127	Concrete exceptions and more restrictive handling must be documented at dataset level.
1.2	128
1.1	129	=== 3.5 Attribution Guidelines (Non-Mandatory but Recommended) ===
1.2	130
1.1	131	FactHarbor encourages, but generally does not require beyond the base licenses, that:
1.2	132
1.1	133	* user interfaces show a short line such as:
	134	`Powered by FactHarbor (open documentation, open protocol, open data)`
	135	Intent:
	136	* strengthen brand recognition and trust,
	137	* keep attribution light-weight and compatible with open licenses,
	138	* avoid creating extra legal conditions beyond the existing licenses.
1.2	139
1.1	140	== 4. Licensing Goals and Principles ==
1.2	141
1.1	142	Earlier "Open Source Model & Licensing" drafts contained valuable reasoning about why strong open-source protections might be needed. The core goals remain relevant, even though the exact license mix has evolved.
	143	FactHarbor's licensing aims to:
1.2	144
1.1	145	* Protect openness of reasoning
1.2	146	* Users must be able to understand how conclusions were reached.
	147	* Code and documentation that materially affect user-visible behaviour should be inspectable or clearly described.
1.1	148	* Discourage hostile or misleading forks
1.2	149	* Avoid "closed clones" that keep the FactHarbor name or appearance while hiding important changes.
	150	* Forks that significantly diverge should use their own branding and not pretend to be official FactHarbor instances.
1.1	151	* Make modifications traceable
1.2	152	* Substantial changes to code, specs, or governance documents should be documented and versioned.
	153	* Users interacting with a service based on FactHarbor should be able to see which version or fork they are using.
1.1	154	* Support long-term sustainability and legal clarity
1.2	155	* Licenses and governance must be enforceable in practice.
	156	* The organisation should have clear standing to protect the project if needed.
	157
1.1	158	== 5. Contributors, Governance & CLA ==
1.2	159
1.1	160	=== 5.1 Contributor Journey (from licensing perspective) ===
1.2	161
1.1	162	The contributor journey (Visitor → New Contributor → Contributor → Trusted Contributor → Contributor → Moderator → Trusted Contributor) is defined in more detail in the Contributor Processes and Organisation pages.
	163	From a licensing perspective, the key points are:
1.2	164
1.1	165	* All contributions must be compatible with the chosen licenses (CC, MIT, AGPL, ODbL, etc.).
	166	* Contributors confirm that they have the right to contribute the material under these licenses.
	167	* Higher-trust roles (Trusted Contributors, Contributors, Moderators) help enforce licensing and attribution rules when reviewing changes.
	168	For full role definitions, see the Organisation / Contributor Processes documentation.
1.2	169
1.1	170	=== 5.2 Contributor License Agreement (CLA) ===
1.2	171
1.1	172	To keep the legal situation clear and enforceable, FactHarbor uses a Contributor License Agreement (CLA).
	173	See [[Contributor License Agreement>>FactHarbor.Organisation.CLA]].
1.2	174
1.1	175	==== 5.2.1 Dual Contributor Model ====
1.2	176
1.1	177	FactHarbor distinguishes between two contributor types with different copyright arrangements:
	178	Unpaid Contributors (Volunteers):
1.2	179
1.1	180	* Retain copyright of their contributions
	181	* Grant FactHarbor a perpetual, royalty-free license to use and distribute
	182	* Enable the project to enforce licenses on their behalf
	183	* Maintain attribution in version control and documentation
	184	Paid Contributors (Employees, Contractors):
	185	* Transfer copyright to FactHarbor Organisation
	186	* Ensures clear ownership for sponsored work
	187	* Simplifies long-term governance
	188	* Still receive attribution for their contributions
	189	This dual model:
	190	* Respects volunteer contributions while preserving their rights
	191	* Provides clarity for commercially sponsored work
	192	* Ensures FactHarbor can effectively maintain and defend the project
	193	* Maintains transparency about contribution sources
1.2	194
1.1	195	==== 5.2.2 Core Intent (All Contributors) ====
1.2	196
1.1	197	Regardless of contributor type, the CLA ensures:
1.2	198
1.1	199	* Contributors grant the FactHarbor organisation:
1.2	200	* a perpetual, worldwide, irrevocable license to use, modify, and redistribute their contributions under the project's chosen licenses (CC BY-SA, MIT, AGPL, ODbL, etc.), and
	201	* the express right to enforce those licenses and pursue legal action against infringers on their behalf.
1.1	202	This ensures that:
	203	* the organisation has clear standing to defend the project legally,
	204	* individual contributors do not have to act alone against infringements,
	205	* licensing remains enforceable even if contributors become inactive.
1.2	206
1.1	207	==== 5.2.3 Determining Contributor Type ====
1.2	208
1.1	209	* Default: Contributors are considered unpaid volunteers unless they have a written agreement specifying paid status.
	210	* Paid Status Indicators: Employment contract, written contracting agreement, or grant/sponsorship agreement.
	211	* Transparency: Contributor type should be disclosed where applicable.
	212	See [[Contributor License Agreement>>FactHarbor.Organisation.CLA]] for complete terms.
1.2	213
1.1	214	== 6. AI Models and Licensing (AKEL) ==
1.2	215
1.1	216	AKEL (AI Knowledge Extraction Layer) may rely on different types of models. Licensing and transparency rules are crucial here.
1.2	217
1.1	218	=== 6.1 Open vs Proprietary Models ===
1.2	219
1.1	220	AKEL may use:
1.2	221
1.1	222	* Open-source models (preferred):
1.2	223	* weights and code are openly available under compatible licenses,
	224	* prompts, evaluation logic and integration code are made public where licenses permit.
1.1	225	* Proprietary / hosted models (allowed but constrained):
1.2	226	* used only when necessary for quality or feasibility,
	227	* must be clearly disclosed to the user at point of use,
	228	* AKEL must label which parts of its output derive from proprietary tools,
	229	* surrounding integration logic remains open (MIT/AGPL or compatible) and is documented.
1.1	230	Rules:
	231	* No deployment may suggest "fully open" AI if proprietary models are used without disclosure.
	232	* For high-impact reasoning (e.g. health, politics, safety-critical topics), open, auditable models are preferred wherever feasible.
	233	* Where proprietary models are unavoidable, additional care is taken to:
1.2	234	* document limitations,
	235	* avoid overstating certainty,
	236	* and keep reasoning layers as transparent as possible.
	237
1.1	238	=== 6.2 Prompts, Pipelines and Integration Code ===
1.2	239
1.1	240	* Orchestration code, pipelines and evaluation logic around AKEL are treated as part of the open FactHarbor codebase (MIT or AGPL).
	241	* Where prompts or model configurations are licensed in a way that restricts publication, this must be documented clearly, and safe abstractions should be used in public documentation.
1.2	242
1.1	243	=== 6.3 AI Prompts and Orchestration ===
1.2	244
1.1	245	* Prompts, system instructions, and orchestration code are considered Code and licensed under MIT or AGPL (depending on component).
	246	* They must be visible in the repository to ensure the system is not a 'black box'.
	247	* If a proprietary model requires a prompt that cannot be shared (e.g. contractual restriction), that component cannot be part of the open core.
1.2	248
1.1	249	== 7. Third-Party Libraries and Components ==
1.2	250
1.1	251	FactHarbor depends on third-party libraries under:
1.2	252
1.1	253	* permissive licenses (MIT, Apache-2.0, BSD), and/or
	254	* other compatible open-source licenses.
	255	Requirements:
	256	* All dependencies must be license-compatible with:
1.2	257	* the MIT/AGPL-licensed code,
	258	* and the overall FactHarbor licensing strategy.
1.1	259	* License information is documented in:
1.2	260	* `/LICENSE` and, where applicable, `/NOTICE`,
	261	* and a dedicated "Third-Party Licenses" section in project documentation.
1.1	262	FactHarbor actively avoids dependencies that:
	263	* restrict redistribution in ways incompatible with open-source norms,
	264	* prevent network users from accessing the relevant source,
	265	* or conflict with the project's transparency and licensing goals.
1.2	266
1.1	267	== 8. Repository Standards ==
1.2	268
1.1	269	Each official FactHarbor repository must follow a minimum standard.
1.2	270
1.1	271	=== 8.1 Required Files ===
1.2	272
1.1	273	Each repository should contain at least:
1.2	274
1.1	275	* `README` – purpose, scope, status, and how to use it.
	276	* `LICENSE` – the applicable license(s) for the repository.
	277	* `CONTRIBUTING` – how to propose changes; coding/writing guidelines.
	278	* `CODEOWNERS` – who is responsible for which parts.
	279	* `CHANGELOG` – human-readable log of important changes.
	280	* `SECURITY` (or `SECURITY.md`) – how to report vulnerabilities and how they are handled.
1.2	281
1.1	282	=== 8.2 Prohibited Content ===
1.2	283
1.1	284	FactHarbor repositories must not contain:
1.2	285
1.1	286	* purely ideological advocacy texts unrelated to the project's purpose,
	287	* opaque binaries or artefacts that cannot reasonably be inspected or reproduced,
	288	* embedded secrets (API keys, passwords, private tokens),
	289	* content that materially contradicts the stated licenses or governance rules.
1.2	290
1.1	291	== 9. Historical Licensing Option: AGPLv3 for Core Engine (Non-Normative Background) ==
1.2	292
1.1	293	Earlier versions of this page explored a strong copyleft option for the core software based on GNU Affero General Public License v3 (AGPLv3).
	294	Those drafts argued that:
1.2	295
1.1	296	* AGPLv3, as a network-copyleft license, would:
1.2	297	* require modified network services to publish their source to users,
	298	* prevent closed forks of the core reasoning engine,
	299	* ensure that any public "FactHarbor-like" service stays inspectable.
1.1	300	They also defined:
	301	* the scope of AGPLv3 coverage (backend services, AKEL logic, frontend),
	302	* expectations for forks (must remain AGPLv3, must declare they are forks),
1.2	303	* and the same CLA principles now adapted to the current license mix.
1.1	304	These AGPLv3 considerations have been partially adopted in the hybrid licensing model (section 3.3), where AGPL-3.0 is recommended for core reasoning components.
	305	They are preserved here as design background and may be revisited for specific components or future arrangements.
1.2	306
1.1	307	== 10. Organisational Transparency ==
1.2	308
1.1	309	FactHarbor is committed to exceptional transparency in all aspects of its operations, governance, and finances. This commitment is essential to build trust in a system claiming to support well-grounded judgments.
1.2	310
1.1	311	=== 10.1 Financial Transparency ===
1.2	312
1.1	313	We commit to publishing annually:
1.2	314
1.1	315	* Complete financial statements (audited where possible)
	316	* Swiss tax filings (annual statements per Swiss law)
	317	* Income sources in aggregate (grants, donations, sponsorships)
	318	* Expense breakdown by category
	319	* Compensation ranges for staff roles (not individual salaries)
	320	* Major funding relationships and partnerships
1.2	321
1.1	322	=== 10.2 Governance Transparency ===
1.2	323
1.1	324	We commit to publishing:
1.2	325
1.1	326	* All governance documents (bylaws, policies, procedures)
	327	* Governing Team composition and meeting schedules
	328	* Governing Team meeting minutes (with narrow exceptions for privacy, security, or legal matters)
	329	* Policy changes with rationale and effective dates
	330	* Decision-making process documentation
	331	* Conflict of interest policies and disclosures
1.2	332
1.1	333	=== 10.3 Operational Transparency ===
1.2	334
1.1	335	We commit to publishing:
1.2	336
1.1	337	* Transparency reports (published twice yearly)
	338	* Content moderation statistics and practices
	339	* AKEL performance metrics and audit results
	340	* Risk tier assignment statistics
	341	* Partnership agreements and funding relationships
	342	* Incident reports (security, moderation, governance)
	343	* System uptime and performance data
1.2	344
1.1	345	=== 10.4 Privacy Protection ===
1.2	346
1.1	347	While maintaining organisational transparency, we protect:
1.2	348
1.1	349	* Individual user privacy and personal data
	350	* Security vulnerabilities (until patched, typically 30-90 days)
	351	* Personnel matters and personal information
	352	* Ongoing legal matters (until resolved)
	353	* Whistleblower and abuse reports
	354	* Authentication credentials and sensitive operational details
1.2	355
1.1	356	=== 10.5 Review and Oversight ===
1.2	357
1.1	358	* Annual review of all information marked "private"
	359	* Public reporting on transparency compliance
	360	* Community input opportunities on transparency policies
	361	* Appeals process for information requests
	362	* Independent transparency audits (when feasible)
	363	See [[Transparency Policy>>FactHarbor.Organisation.How-We-Work-Together.Transparency-Policy]] for complete details.
1.2	364
1.1	365	== 11. Privacy and Data Protection ==
1.2	366
1.1	367	FactHarbor is committed to protecting user privacy while maintaining transparency in operations and governance.
1.2	368
1.1	369	=== 11.1 Data Collection Principles ===
1.2	370
1.1	371	* Data minimization: Collect only what is necessary for functionality
	372	* Purpose limitation: Use data only for stated purposes
	373	* Short retention: Delete data when no longer needed
	374	* User control: Provide access, correction, and deletion rights
1.2	375
1.1	376	=== 11.2 User Rights ===
1.2	377
1.1	378	Users have the right to:
1.2	379
1.1	380	* Access their personal data
	381	* Correct inaccurate information
	382	* Delete their accounts and associated data
	383	* Export their data (portability)
	384	* Object to certain processing
	385	* Lodge complaints with supervisory authorities
1.2	386
1.1	387	=== 11.3 What We Collect ===
1.2	388
1.1	389	For specific details on data collection practices, retention periods, and processing purposes, see [[Privacy Policy>>FactHarbor.Organisation.How-We-Work-Together.Privacy-Policy]].
	390	In general:
1.2	391
1.1	392	* Public contributions: Permanently public and attributed (essential for transparency)
	393	* Account information: Email, username (minimal required data)
	394	* Technical data: IP addresses, user agents (short retention, logged out users)
	395	* Usage data: Aggregated, anonymized analytics
1.2	396
1.1	397	=== 11.4 What We Never Do ===
1.2	398
1.1	399	* Sell or rent user data
	400	* Share personal data with third parties for marketing
	401	* Track users across unrelated sites
	402	* Use personal data for purposes beyond stated scope
	403	* Keep personal data longer than necessary
1.2	404
1.1	405	=== 11.5 Security Measures ===
1.2	406
1.1	407	* Encryption in transit (TLS/HTTPS)
	408	* Encryption at rest for sensitive data
	409	* Access controls and authentication
	410	* Regular security audits
	411	* Incident response procedures
	412	* Vulnerability disclosure program
	413	* Data Protection Impact Assessments (DPIA) for high-risk processing (required by FADP Article 22)
	414	See [[Privacy Policy>>FactHarbor.Organisation.How-We-Work-Together.Privacy-Policy]] for complete details.
1.2	415
1.1	416	=== 11.6 Data Protection Officer (DPO) ===
1.2	417
1.1	418	If we serve users in the European Union, we will appoint a Data Protection Officer (DPO) as required by EU GDPR Article 37.
	419	The DPO will:
1.2	420
1.1	421	* Advise on data protection compliance
	422	* Monitor FADP and GDPR compliance
	423	* Serve as contact point for Swiss FDPIC and EU data protection authorities
	424	* Conduct privacy audits and DPIAs
	425	* Handle data subject requests
	426	Contact (if appointed): [DPO contact to be established if needed]
	427	Note: Swiss law (FADP) does not require a DPO for organizations of our size. However, EU GDPR Article 37 requires a DPO for:
	428	* Large-scale systematic monitoring of data subjects
	429	* Large-scale processing of sensitive personal data (including political opinions, health information)
	430	Given that FactHarbor processes claims containing political opinions and uses AI for systematic evaluation, we commit to appointing a DPO if we process personal data of EU residents.
1.2	431
1.1	432	== 12. Exceptions and Appeals ==
1.2	433
1.1	434	=== 12.1 Requesting Information ===
1.2	435
1.1	436	If you believe FactHarbor should disclose specific organisational information:
1.2	437
1.1	438	1. Submit a written request to [Transparency contact to be established]
	439	2. Specify the information requested and rationale
	440	3. Expect initial response promptly
1.2	441
1.1	442	=== 12.2 Appeals Process ===
1.2	443
1.1	444	If a transparency request is denied:
1.2	445
1.1	446	1. Appeal to the Transparency Committee (if established)
	447	2. Provide additional context or rationale
	448	3. Expect appeal decision promptly
	449	4. Final appeals may be escalated to the Governing Team
1.2	450
1.1	451	=== 12.3 Exception Criteria ===
1.2	452
1.1	453	Information may be withheld only if disclosure would:
1.2	454
1.1	455	* Violate individual privacy rights
	456	* Compromise security (vulnerability, credential)
	457	* Violate legal obligations (court order, attorney-client privilege)
	458	* Enable abuse or harm (expose victim, enable attack)
	459	* Breach fiduciary duty (ongoing confidential negotiations)
	460	All exceptions are time-limited and reviewed annually.

Wiki source code of Open Source Model and Licensing

Applications

Navigation

Need help?