Chapter 55: Open Knowledge and Sharing

Chapter Overview

This chapter examines how communities make their knowledgebase accessible to the wider world while maintaining sovereignty, attribution, and reciprocity. It covers open licensing frameworks, API design for programmatic access, federation protocols for connecting knowledgebases, multilingual sharing, and the specific relationships communities build with researchers, journalists, and other external users. The chapter closes the knowledgebase arc (architecture → tagging → maintenance → sharing) and bridges into Part XI's focus on teaching, learning, and sustained practice.

Learning Outcomes

By the end of this chapter, you will be able to:

Explain the distinction between "open" and "public without consent" in community knowledge sharing
Apply appropriate Creative Commons and Open Database licenses to different types of content
Design API access policies that balance openness with community protection
Identify federation protocols and standards for connecting distributed knowledgebases
Evaluate multilingual sharing strategies for diverse communities
Articulate reciprocal obligations between communities and external users (researchers, journalists)
Apply the Closing-the-Loop principle from Chapter 19 to knowledgebase sharing contexts

Key Terms

Open Knowledge: Knowledge made accessible under terms that permit reuse, adaptation, and redistribution while preserving attribution and respecting community authority.
Federation: The practice of connecting independent knowledgebases so they can exchange information while maintaining local governance.
API (Application Programming Interface): A structured method for external systems to query and retrieve data programmatically.
Reciprocity: The ethical obligation for external users of community knowledge to report back what they learned, found, or published using that knowledge.

55.1 Open Knowledge as a Community Practice

"Open" has become a powerful word in knowledge infrastructure. Open data. Open science. Open access. Open government. The term carries a moral weight: openness is framed as inherently good, democratic, and progressive. But for communities — especially those that have experienced extraction, surveillance, or misrepresentation — "open" is not a simple virtue. It is a contested, context-dependent decision.

Open knowledge in the community mapping context means making information accessible under terms that permit reuse, adaptation, and redistribution while preserving attribution, respecting sovereignty, and ensuring that communities retain authority over how their knowledge is used. It does not mean abandoning control. It does not mean making everything public. It does not mean ignoring the risks of exposure.

The foundational principle, established in Chapter 9 and carried through the textbook, is that communities decide what to share, with whom, and on what terms. Some knowledge — sacred sites, vulnerable populations, sensitive locations — must remain protected. Some knowledge may be shared within the community but not outside it. Some knowledge may be shared openly with attribution. Some may be shared only under specific terms that restrict commercial use or require reciprocity.

Open knowledge, done ethically, begins with consent. The community consents to make specific information accessible. The community defines the license. The community retains the right to withdraw consent if the knowledge is misused. These are not technical questions about Creative Commons versions or database schemas. They are governance questions about power, trust, and long-term relationship.

In practice, this means a community knowledgebase might have multiple access tiers. A public tier of general information (parks, transit routes, public services) available to anyone. A registered tier requiring account creation and agreement to terms of use. A researcher tier requiring ethics approval, data-sharing agreements, and reporting obligations. A community-only tier restricted to verified members. This tiered access structure is common in Indigenous data governance (as discussed in Chapter 33) and increasingly adopted by equity-focused knowledge initiatives.

The decision to share openly is strategic. Opening a knowledgebase can attract collaborators, increase visibility, support advocacy, and strengthen the community's voice. It can enable researchers to study patterns that help the community. It can allow journalists to tell stories that need telling. It can let other communities learn from what worked and what didn't. But it can also invite misuse, exploitation, surveillance, or harm. The decision must weigh these possibilities honestly.

Finally, open knowledge is not a one-time choice. As the community changes, as risks evolve, as trust is built or broken, the sharing terms may need to adjust. A community that experienced exploitation may close access temporarily. A community that builds strong reciprocal relationships with external users may expand access. The knowledgebase governance model must include mechanisms for revisiting sharing decisions — not bureaucratically, but deliberately and collectively.

55.2 Open Licenses Revisited

Chapter 35 introduced open licensing in the context of data trusts and community sovereignty. This section revisits licensing specifically for knowledgebase content, distinguishing between licenses for factual data, creative works, and structured datasets.

The Creative Commons license suite is the most widely used framework for sharing creative works — text, images, maps, videos, and other expressive content. The suite offers six main licenses, each defined by combinations of four conditions:

BY (Attribution): Users must credit the creator.
SA (ShareAlike): Derivative works must use the same license.
NC (NonCommercial): Commercial use is prohibited without permission.
ND (NoDerivatives): The work can be shared but not modified.

The most open Creative Commons license is CC BY, which requires only attribution. This is appropriate for community stories, reports, or educational materials where broad reuse supports the community's goals. The most restrictive standard license is CC BY-NC-ND, which allows sharing but prohibits modification or commercial use — appropriate for sensitive content the community wants to circulate but not alter.

For knowledgebase text (governance documents, process guides, educational materials), CC BY-SA is often the best fit. It requires attribution and ensures that derivative works remain open, preventing proprietary capture of community knowledge.

For factual data — service locations, demographic statistics, infrastructure inventories — Creative Commons licenses are less appropriate. Facts are not copyrightable. The Open Database License (ODbL), introduced in Chapter 35, is designed for datasets. ODbL requires attribution, allows reuse and redistribution, and includes a ShareAlike clause that prevents someone from taking community data, adding to it, and locking the enhanced version behind proprietary walls.

ODbL is the license used by OpenStreetMap, making it a proven choice for geographic and structured community data. A community knowledgebase using ODbL for its core dataset ensures that anyone building on that data must contribute improvements back to the commons.

Some communities, particularly Indigenous communities, use custom licenses that go beyond Creative Commons or ODbL. These licenses may include requirements for:

Prior consultation before reuse in certain contexts.
Restrictions on use that contradicts community values.
Obligations to share findings or publications with the community.
Sunset clauses that require users to reconfirm consent after a period.

Custom licenses are more complex to draft and enforce, but they reflect a higher level of community authority. They signal that the community is not simply making data available — it is entering into a relationship with users, and that relationship has obligations.

Licensing decisions should be documented in the knowledgebase governance framework (Chapter 51) and visible on every dataset, map, and document. A clear license statement on the homepage, in metadata, and in API responses prevents ambiguity and protects the community's rights.

55.3 APIs and Programmatic Access

An API (Application Programming Interface) allows external systems to query a knowledgebase programmatically — retrieving structured data without manually downloading files or scraping web pages. APIs are essential for integration, automation, and federation. They also introduce new risks: bulk download, surveillance, and unanticipated uses.

A well-designed community knowledgebase API includes:

Clear authentication and access tiers. Public endpoints for general information (e.g., list of public parks). Authenticated endpoints requiring an API key for higher-volume or more detailed queries. Community-restricted endpoints requiring verified membership.

Rate limiting. Preventing a single user from overwhelming the system or extracting the entire dataset in seconds. A public API might limit requests to 100 per hour per IP address. Authenticated users with data-sharing agreements might have higher limits.

Transparent documentation. An API without documentation is unusable. Documentation should explain what data is available, how to query it, what the response format looks like, and what the terms of use are. Examples and tutorials lower the barrier for good-faith users.

Audit logging. Every API request should be logged: who accessed what, when, and how often. Logs support compliance monitoring, abuse detection, and reciprocity tracking (discussed in §55.9).

License enforcement. API responses should include license metadata. A JSON response might include a "license": "ODbL-1.0" field. A CSV download should have a license header. This makes terms of use explicit and machine-readable.

Graceful degradation. If a dataset becomes restricted (e.g., after a breach of trust), the API should return a clear error message explaining why access has changed, rather than silently failing or returning empty results.

Common API patterns for knowledgebase access include:

REST APIs for querying by resource type (e.g., /services, /events, /places).
GraphQL APIs for flexible, nested queries that retrieve exactly the fields requested.
Bulk export endpoints for researchers or partners who need the full dataset under a data-sharing agreement.
Geospatial APIs (e.g., GeoJSON endpoints) for mapping and GIS integration.

The trade-off is between openness and control. A fully open API with no authentication makes data easy to access but hard to protect. A locked-down API with complex approval processes protects data but limits reuse and collaboration. The right balance depends on the community's risk tolerance, capacity for oversight, and strategic goals.

One emerging practice is the data-sharing agreement API tier. Researchers or organizations sign an agreement that includes reciprocity obligations (discussed in §55.7 and §55.9), then receive an API key with elevated access. This formalizes the relationship, creates accountability, and enables the community to track who is using the data and for what purpose.

55.4 Federation Between Knowledgebases

Community knowledgebases are not meant to be isolated silos. They gain power when they can connect, share, and learn from each other. Federation is the practice of linking independent knowledgebases so they can exchange information while maintaining local governance.

Federation protocols allow one knowledgebase to query another, retrieve updates, or share referrals. For example, a regional network of community service knowledgebases might federate so that when someone searches for housing support, they see results from neighboring communities as well as their own. Each knowledgebase retains sovereignty over its data, but the network functions as a coordinated whole.

The ActivityPub protocol, used by decentralized social networks like Mastodon, is one model for federation. Knowledgebases could publish updates (new services, closed locations, event announcements) that other federated instances subscribe to. A community maps platform could subscribe to updates from a dozen local knowledgebases and display a combined, real-time view.

Another model, used by Wikidata and the Code for All network, is a shared identifier system. Each knowledgebase maintains its own data, but uses common identifiers (e.g., for service categories, license types, or administrative boundaries). This allows queries across knowledgebases without requiring full data replication.

Federation requires trust. A community knowledgebase must decide which other instances to federate with, under what terms, and with what safeguards. A small-town knowledgebase might federate with trusted regional partners but not with corporate data aggregators. An Indigenous knowledge initiative might federate only with other Indigenous-governed platforms.

Key considerations for federation:

Governance alignment. Federating with a knowledgebase that allows commercial data resale undermines a community's non-commercial terms. Federation partners should have compatible values and licenses.

Data sovereignty. Federation should not require surrendering control. Each knowledgebase must retain the right to revoke federation, correct misinformation, or withdraw specific datasets.

Attribution in federated queries. When a user queries one knowledgebase and receives results from three federated sources, the response should clearly attribute each result to its origin.

Interoperability standards. Federation works best when knowledgebases use compatible schemas, identifiers, and formats. This is where the taxonomy and content architecture work from Chapter 52 becomes critical.

The vision, articulated in Chapter 35's discussion of data trusts, is a federated ecosystem of community-controlled knowledgebases that function as a decentralized alternative to platform monopolies. No single corporation owns the data. No single government controls access. Communities govern their own knowledge, but collaborate when it serves mutual goals.

55.5 Translation and Multilingual Sharing

A knowledgebase in only one language excludes people. In multilingual communities — which includes most Canadian cities, many Indigenous territories, and immigrant-destination regions worldwide — accessibility requires translation.

Translation in knowledgebase work has several layers:

Interface translation. The user interface (search forms, navigation, instructions) should be available in the languages spoken by the community. This is the baseline.

Content translation. Service descriptions, event details, governance documents, and help text should be translated. This is more resource-intensive but essential for equitable access.

Metadata translation. Tags, categories, and field labels should be multilingual so users can search and filter in their preferred language.

Community-contributed translation. Rather than hiring external translators (who may not understand local context or use culturally appropriate language), many knowledgebases invite bilingual community members to contribute translations. This is slower but results in higher-quality, culturally grounded text.

Machine translation tools (e.g., Google Translate, DeepL) can assist, but should not replace human review. Machine translation often misses nuance, mistranslates cultural terms, and produces awkward phrasing. A hybrid approach — machine translation for drafts, community review for finalization — balances speed and quality.

For Indigenous languages, translation is not just about accessibility — it is an act of language revitalization. A knowledgebase that includes content in Cree, Inuktitut, Anishinaabemowin, or other Indigenous languages normalizes those languages in digital infrastructure, creates resources for learners, and asserts linguistic sovereignty.

Multilingual knowledgebases should also consider transliteration for languages with non-Latin scripts. A service name written in Arabic, Mandarin, or Punjabi should be searchable in its original script, not just a romanized approximation.

API responses should indicate the language of returned content (e.g., "lang": "fr") and allow users to request specific languages if translations are available. This supports programmatic multilingual access.

55.6 Embedding and Linking from Outside

Community knowledgebases are more useful when they can be embedded in other websites, linked from external resources, and integrated into existing digital infrastructure.

Embed codes allow organizations to display knowledgebase maps, service directories, or event calendars on their own websites. A library website might embed a map of community services. A municipal homepage might embed an events feed. Embeds should:

Include attribution and a link back to the source knowledgebase.
Respect the license (e.g., no embedding in commercial platforms if the license is NC).
Update automatically when the source data changes.
Load quickly and accessibly.

Deep linking allows external sites to link directly to specific entries (a particular service, event, or location) rather than the knowledgebase homepage. Deep links should be stable (not change when data is reorganized) and human-readable (e.g., /services/youth-center rather than /services/12837).

Schema.org markup makes knowledgebase pages machine-readable by search engines and other tools. A service page marked up with Schema.org vocabulary can appear in Google search results with rich snippets (address, hours, contact info). This increases discoverability.

Social media previews (Open Graph and Twitter Card metadata) ensure that when someone shares a knowledgebase link on social media, the preview includes a meaningful title, description, and image — not just a generic homepage.

QR codes linking to knowledgebase pages can be posted in physical locations (community centers, bus stops, bulletin boards), bridging offline and online access. A QR code on a park sign might link to the park's knowledgebase entry, showing upcoming events, accessibility info, and contact details.

Embedding and linking extend the knowledgebase's reach without requiring users to learn a new platform. But they also introduce risks: a site embedding the knowledgebase might misrepresent it, strip attribution, or use it for purposes the community did not intend. Terms of use for embedding should be clear, and communities should monitor how embeds are being used.

55.7 Sharing With Researchers

Researchers — in universities, nonprofits, government agencies, and independent practice — are frequent users of community knowledgebases. They study service ecosystems, analyze spatial patterns, evaluate interventions, and develop theories. Community data is valuable to researchers. But the relationship is often one-sided: researchers extract data, publish findings, advance their careers, and move on. The community sees no benefit.

Ethical knowledgebase sharing with researchers requires reciprocity. Reciprocity means the researcher has obligations to the community that provided the data. Those obligations might include:

Ethics approval. Before accessing restricted data, researchers should demonstrate that their work has been reviewed by an ethics board (or community-equivalent governance body) and meets standards for informed consent, privacy, and benefit-sharing.

Data-sharing agreements. A formal agreement specifying what data will be accessed, how it will be used, how long the researcher will retain it, whether it will be shared with others, and how findings will be reported back.

Plain-language reporting. Academic papers are often inaccessible to community members (paywalled, jargon-heavy, discipline-specific). Researchers using community data should provide a plain-language summary of their findings, accessible to those who contributed the data.

Community co-authorship. When research is collaborative — not just extractive — community members should be named as co-authors, co-investigators, or acknowledged contributors. This is standard practice in participatory action research and should be the norm in knowledgebase-supported research.

Embargo periods. Some communities request that researchers delay publication until the community has reviewed findings, corrected errors, or prepared a response. This protects against misrepresentation and ensures community voice.

Correction rights. If a researcher misinterprets data or draws conclusions the community disputes, the community should have a process for requesting corrections or publishing a counter-narrative.

The researcher-community relationship works best when it is treated as a partnership, not a transaction. The researcher brings methodological expertise, analytical tools, and access to academic networks. The community brings lived experience, contextual knowledge, and the data itself. Both parties contribute. Both should benefit.

Some communities formalize these relationships through community research partnerships or data cooperatives (discussed in Chapter 35). Researchers who want access join the cooperative, agree to its terms, and participate in governance. This shifts power from the researcher (who traditionally controls the research design) to the community (which sets the agenda and priorities).

Knowledgebase APIs can enforce reciprocity technically. A researcher API key might be conditional on submitting a plain-language summary of findings within six months of data access. If the summary is not submitted, the API key is revoked. This is not punitive — it is a reminder that the relationship has obligations.

55.8 Sharing With Journalists

Journalists use community knowledgebases to source stories, verify facts, find interview subjects, and provide context. A knowledgebase showing service deserts can support an investigative piece on inequality. A knowledgebase tracking displacement risk can ground a housing affordability story. Journalists, like researchers, depend on community data — but the relationship has different dynamics.

Journalists work under speed pressure. A researcher might spend months analyzing data. A journalist might have hours. This means journalists are less likely to engage in long-term partnership, ethics review, or formal data-sharing agreements. They need fast, reliable access.

Journalists also face accountability pressures from editors, audiences, and legal standards. A reporter who misrepresents data risks correction, retraction, or reputational damage. This built-in accountability can make journalist relationships safer than some researcher relationships — but it is not automatic.

Communities sharing knowledgebase data with journalists should:

Provide clear, accessible datasets. Journalists are often not trained in GIS, API queries, or complex data formats. Offering CSV exports, pre-built visualizations, and simple data dictionaries makes the knowledgebase more journalist-friendly.

Offer context and interpretation. A dataset alone can be misinterpreted. Providing a one-page context document (what the data shows, what it doesn't show, what the community wants emphasized) helps journalists tell accurate stories.

Request advance review (when possible). Some journalists will share draft stories for fact-checking before publication. This is not censorship — it is accuracy. If a journalist misunderstood a data point or drew an incorrect conclusion, the community can correct it before it goes public.

Monitor coverage. After a journalist uses knowledgebase data, the community should track what was published. Did the story reflect the community's perspective? Was the data cited accurately? Was the community credited? This feedback loop informs future journalist relationships.

Respond to misrepresentation publicly. If a journalist publishes a misleading or harmful story based on knowledgebase data, the community has the right to respond — through letters to the editor, social media, or their own publication. The knowledgebase itself can host a "Media Corrections" page documenting inaccuracies.

Journalists, unlike researchers, rarely have ethics review processes. A university researcher must get IRB approval. A journalist does not. This means community-defined terms of use are even more critical. A knowledgebase might include a "Journalist Agreement" that users must accept before downloading data, specifying attribution requirements, context obligations, and correction rights.

The trade-off is between access and control. Locking down knowledgebase data prevents exploitation but also prevents storytelling that could support community advocacy. Many communities choose a middle path: open access for general information, restricted access for sensitive data, and formalized relationships with trusted journalists.

55.9 Closing the Loop with Source Communities

Chapter 19.9 introduced the principle of closing the loop: when a mapping process involves community members as data sources, those members have a right to see, validate, and respond to what was documented. Chapter 55 extends this principle to external users of knowledgebase data.

When researchers, journalists, organizations, or governments use community knowledgebase data, the source community deserves to know:

What was the data used for?
What was found or concluded?
Was the data represented accurately?
How can the community access the findings?

This is not a courtesy. It is an ethical obligation. Data is not a free resource to be mined without accountability. Data comes from communities — from their labor, their experience, their willingness to share. Using that data creates a relationship, and relationships have responsibilities.

In practice, closing the loop means:

Requiring reporting as a condition of access. A researcher or organization accessing knowledgebase data signs an agreement to report back findings within a specified timeframe (e.g., six months for research, 30 days for media).

Providing accessible summaries. A 40-page academic paper is not closing the loop. A two-page plain-language summary with key findings, implications, and acknowledgments is.

Hosting findings in the knowledgebase. The knowledgebase itself can include a "Research & Publications" section where external users upload their findings. This makes the knowledge circular: data flows out, findings flow back in, and future users can learn from prior work.

Inviting community response. If a researcher's findings contradict community experience, or if a journalist's story misses critical context, the community should have a platform to respond. The knowledgebase can host community commentary alongside external reports.

Public accountability. A knowledgebase can publish a list of who has accessed restricted data, for what purpose, and whether they fulfilled their reporting obligations. Organizations that fail to close the loop can be publicly named.

This is not punitive. It is transparency. Communities have a right to know how their data is being used and to hold users accountable.

The reciprocal relationship also creates incentives for good-faith use. Researchers who want long-term access, or who want the community to share future data, have a strong incentive to treat the relationship respectfully. Journalists who want future scoops have an incentive to represent the community accurately. Organizations that want partnership have an incentive to deliver on commitments.

Closing the loop transforms the knowledgebase from a static archive into a living ecosystem of reciprocal knowledge exchange. Data flows out. Insights flow back. The community learns from what others found. External users build on prior work. Trust deepens. The knowledge commons grows.

55.10 Synthesis and Implications

This chapter has examined how communities share knowledgebase content with the wider world — not as an act of surrender, but as a strategic, governed, and reciprocal practice. The arc of Part X is now complete:

Chapter 51 established the architecture for durable, community-governed knowledgebases.
Chapter 52 developed taxonomy and content structures that make knowledge findable and interoperable.
Chapter 53 introduced agent-based research workflows for maintaining accuracy and currency.
Chapter 54 addressed long-term stewardship, funding, and governance.
Chapter 55 closes the loop by defining how communities make knowledge accessible while protecting sovereignty, demanding reciprocity, and ensuring that external use serves — rather than exploits — the source.

The synthesis brings together several core ideas:

Open does not mean uncontrolled. A community can share knowledge openly while retaining authority over terms of use, attribution, and reciprocity. Licensing, APIs, and data-sharing agreements are governance tools, not barriers.

Federation builds power. Isolated knowledgebases have limited reach. Federated networks of community-controlled knowledgebases can function as a decentralized alternative to platform monopolies — preserving local sovereignty while enabling collective action.

Reciprocity is non-negotiable. External users of community data — researchers, journalists, governments, organizations — have an obligation to report back what they learned, found, or published. Closing the loop is not a courtesy; it is an ethical requirement.

Translation is accessibility. A knowledgebase in only one language excludes people. Multilingual content, interface, and metadata are essential for equity in diverse communities.

Sharing decisions are revisable. What the community chooses to share today may change as risks evolve, trust is built or broken, or strategic goals shift. Governance structures must include mechanisms for revisiting sharing terms.

The implications for practice:

For community mappers: Design sharing policies before data is collected. Make consent, licensing, and reciprocity explicit from the start. Do not assume that "open" is always the right choice — consult the community.

For knowledgebase stewards: Build access tiers, API documentation, audit logs, and reporting requirements into the technical infrastructure. Governance is easier to enforce when it is built into the system, not bolted on later.

For researchers and journalists: Treat community data as a relationship, not a resource. Sign agreements. Report findings. Acknowledge contributors. Close the loop. Your credibility and future access depend on it.

For policymakers and funders: Incentivize reciprocal relationships. Funding agreements for research or journalism that use community data should require plain-language reporting back to the source. Open data mandates should include community authority over sensitive information.

The vision: a knowledgebase ecosystem where communities control their own data, share on their own terms, and benefit from external use — while external users gain access to rich, high-quality, community-validated knowledge. Not extraction. Not transaction. Partnership.

55.11 Open-Knowledge Sharing Plan

This structured exercise guides you through designing a sharing policy for a community knowledgebase.

Purpose: Develop a comprehensive plan for how a community knowledgebase will make its content accessible to external users while protecting community sovereignty and ensuring reciprocity.

Context: You are working with a community that has built a knowledgebase documenting services, events, cultural sites, and community stories. The community wants to share this knowledge to support advocacy, research, and coordination — but has concerns about exploitation, misrepresentation, and loss of control.

Steps:

Define access tiers. Identify at least three levels of access (e.g., public, registered user, researcher, community-only). For each tier, specify:
- What content is available.
- What authentication or agreement is required.
- What the user can do with the data.
Select licenses. Choose appropriate licenses for:
- Textual content (governance documents, stories, guides).
- Structured data (service locations, event listings).
- Maps and visualizations.
- Explain your reasoning for each choice.
Design an API policy. Specify:
- What endpoints will be public vs. authenticated.
- Rate limits for different user types.
- What metadata (including license info) will be included in responses.
Draft a data-sharing agreement for researchers. Include:
- What the researcher commits to (ethics approval, plain-language reporting, attribution).
- What the community commits to (data access, technical support).
- Timeline for reporting findings.
- Consequences for non-compliance.
Create a journalist access protocol. Specify:
- What data journalists can access without formal agreement.
- What context documents or guidance will be provided.
- Process for requesting advance review (if offered).
- How the community will monitor and respond to media coverage.
Plan for closing the loop. Describe:
- How external users will report findings back.
- Where findings will be hosted (in the knowledgebase, external site, both).
- How the community will review and respond to reported findings.
- How compliance will be tracked and enforced.
Address multilingual sharing. Identify:
- What languages the community speaks.
- What content will be translated first.
- Who will do translation (community members, volunteers, paid translators, hybrid approach).
Identify risks and safeguards. For each type of external user (researchers, journalists, other organizations), identify one potential risk and one safeguard to mitigate it.

Deliverable: A 4–6 page Open-Knowledge Sharing Plan covering all eight elements above.

Time Estimate: 3–4 hours

Collaboration Notes: This exercise works well as a group activity with community members, knowledgebase stewards, and potential external users (researchers, journalists) participating. Real-world perspectives strengthen the plan.

Key Takeaways

Open knowledge sharing is strategic, governed, and reciprocal — not uncontrolled or unconditional.
Licensing frameworks (Creative Commons, ODbL) formalize community authority over how knowledge is used.
APIs enable programmatic access while rate limits, authentication, and audit logs protect against exploitation.
Federation allows independent knowledgebases to connect and share while maintaining local sovereignty.
Researchers and journalists using community data have ethical obligations to report findings back, provide plain-language summaries, and close the loop.
Multilingual sharing is essential for equity in diverse communities and supports language revitalization in Indigenous contexts.

Plain-Language Summary

This chapter is about how communities share the knowledge they've built in their knowledgebase with the outside world — while making sure they stay in control and get something back in return.

"Open" doesn't mean giving everything away. Communities can choose to share some information publicly, keep some information private, and require agreements for sensitive data. Licenses (like Creative Commons) let communities set the rules: who can use the knowledge, whether they have to give credit, and whether they can make money from it.

When researchers or journalists use community data, they have responsibilities. They should report back what they found, write summaries that regular people can understand, and give credit to the community. This is called "closing the loop" — making sure the relationship isn't one-way.

Communities can also connect their knowledgebases to others, creating networks where information flows between communities while each one still controls its own data. Translating content into multiple languages makes sure everyone in diverse communities can access and contribute.

Good sharing practices protect the community, build trust with outside users, and make sure the knowledge helps the people it came from — not just the people studying it.

End of Chapter 55.

Chapter 55. Open Knowledge and Sharing