Open-source AI, open-weight models and proprietary AI services differ in what people can inspect, download, modify, run and share. A publicly accessible AI API does not necessarily expose its model weights. Downloadable weights do not automatically grant unrestricted commercial use or the full freedoms of open-source AI.
This guide compares four fictional model offers for a tutoring centre. You will inspect local-use permission, commercial rights, adaptation, documentation and operational limits, then change one requirement at a time to see why the eligible choices change. It also explains why access, privacy, cost, reproducibility and learning quality need separate evaluation.
It fills topic 090 in How Super Intelligence Works. The title is an educational umbrella for present-day AI rather than a claim that contemporary models have achieved artificial superintelligence.
Chapter contents and reading routes
Understand openness · Four Model School · The licence table · Independent transfer · Sources
Chapters 1–9: 1. Open, open-weight and proprietary are not synonyms · 2. What does access to model weights mean? · 3. The Open Source AI Definition provides a stronger test · 4. Open APIs are interfaces, not open internals · 5. Local deployment does not automatically equal openness · 6. Training data transparency is separate from model access · 7. The fictional Four Model School laboratory · 8. Fern: a service available only through a hosted API · 9. Maple: downloadable weights with a noncommercial condition
Chapters 10–18: 10. Cedar: a broader rights and documentation package · 11. Pine: proprietary but locally deployable · 12. A simple decision table needs explicit questions · 13. Open model terminology needs careful scopes · 14. A licence is not a benchmark result · 15. Weights and training state are different resources · 16. Practical compute is another independent constraint · 17. A downloaded model still needs a maintenance owner · 18. Privacy requires a complete information-flow inspection
Chapters 19–26: 19. Security and updates matter under every licence · 20. Evaluation should test the complete application · 21. A worked cost boundary without invented vendor prices · 22. Independent transfer: add an offline requirement · 23. Independent transfer: relax the adaptation condition · 24. A sensible model-selection worksheet · 25. Frequently asked questions · 26. Primary references and the eduKate reading route
1. Open, open-weight and proprietary are not synonyms
AI models differ in which parts of their development and use are available to the public and which rights accompany that access. A service may allow anyone to make API requests while withholding model weights. Another system may publish its weights yet restrict commercial use, modification or redistribution. A third may supply code, training information and permissions broad enough to support a stronger claim of open-source AI.
The word open becomes meaningful only when the reader asks what is accessible and what the user may legally do with it. Marketing labels alone do not settle those questions. This chapter turns the distinction into a repeatable checklist and a fictional model-selection exercise.
An advanced model can be useful without being open; an openly available model can be unsuitable for a particular educational job. Openness, quality, price, privacy and appropriateness are separate dimensions that need separate evidence.
2. What does access to model weights mean?
Model weights are learned parameters used by the model architecture during computation. An open-weight release generally makes those parameter values available under some stated terms, which may allow local inference or adaptation. The degree of access depends on the files, formats and licence.
Having the weights does not automatically mean knowing how the training data were gathered or how every parameter was obtained. Full training reproducibility may require unavailable code, dataset information, compute resources and exact methodological details.
Do not confuse weights with an entire finished application. Running them may still require a tokenizer, inference implementation, compatible hardware and software. The capability to download a file is not proof that a particular pupil, tutor or organisation can practically run it.
3. The Open Source AI Definition provides a stronger test
The Open Source Initiative’s Open Source AI Definition 1.0 sets out freedoms to use, study, modify and share an AI system and identifies the relevant model parameters, code and data information. It provides a technical and legal reference stronger than simply calling downloadable weights open.
The definition recognises that sharing all training data may not always be practical or appropriate, but it calls for information sufficient to understand and modify the system’s construction. The exact licence and accompanying documentation still have to be inspected.
Do not call every open-weight model open-source AI under this definition. A release with extensive restrictions may be valuable and available, yet fail one or more required freedoms. Conversely, a provider’s use of the term open-source does not by itself prove compliance.
4. Open APIs are interfaces, not open internals
A hosted API can make advanced model functionality available without disclosing weights, source code or training details. Users may pay per request and gain access to managed infrastructure, capacity and updates. The provider retains control over many implementation and service decisions.
This arrangement can be attractive for a school that wants practical capabilities without operating a data centre. It also creates dependencies on provider availability, pricing, data-handling policies and the versions selected by the provider.
An API being publicly documented says something about access to the service, not that the underlying model can be downloaded, modified, audited internally or redistributed. Separate the interface from the asset it exposes.
5. Local deployment does not automatically equal openness
A proprietary licence may permit an organisation to install and operate a model on its own machines while restricting modification and redistribution. Conversely, an open-weight system could be legally reusable but too large for the intended local hardware. These are different questions.
Local execution can reduce dependence on an external inference service for selected tasks, but it does not automatically ensure privacy. Logs, backups, connected plugins, remote maintenance and user permissions can still create exposure.
Describe both legal and operational control. Can the organisation operate the software offline? Modify it? Share a version? Audit its training? Access necessary updates? Each question may have a different answer.
6. Training data transparency is separate from model access
A model’s weights may be available even when the original training datasets are not. The model may have been trained on a complex mixture of sources with different rights and restrictions. Dataset documentation may be partial, absent or deliberately summarised.
For research and education, provenance matters: where did the examples come from, how were they filtered and what limitations may affect model behaviour? Better documentation can improve responsible evaluation even when it does not give a complete recipe for reproducing training.
Do not imply that an open-source licence guarantees freedom from bias, copyright questions or misuse. Legal permissions, social risk and evidence quality still require their own assessment.
7. The fictional Four Model School laboratory
Our worked case is an invented tutoring centre planning a local teaching-support system. The centre requires four conditions: the model must be runnable on approved local infrastructure; commercial tutoring use must be permitted; its operator must be allowed to adapt the system; and enough information must be documented to inspect what is being adopted.
Four fictional model offers—Fern, Maple, Cedar and Pine—provide different combinations of access. These names and terms are teaching fixtures rather than actual product offers. The task is not to pick the most fashionable system; it is to check which option satisfies the declared constraints on paper.
Even a candidate passing these preliminary requirements still needs tests for language quality, pupil safety, hardware suitability and actual cost before any adoption.
8. Fern: a service available only through a hosted API
Fictional Fern supplies a documented endpoint and permission for commercial requests subject to its service terms. It does not supply downloadable weights or a permitted local runtime. Its training data and implementation details are not fully available in the teaching packet.
Fern might deliver useful responses, but it fails the centre’s local-operation requirement. Describing Fern as open because its API documentation is public would conflate service access with model openness.
A school could reconsider Fern if its needs change, but the answer to the original set of requirements should not be altered merely because the model gives fluent demonstrations.
9. Maple: downloadable weights with a noncommercial condition
Fictional Maple releases weights, a compatible inference program and enough information to run locally for personal or noncommercial educational experiments. Its invented licence prohibits commercial tutoring use and does not provide the full training information needed for the stronger openness claim.
Maple satisfies some technical requirements but fails the stated commercial-use condition. The fact that files are downloadable does not override a licence restriction. The centre should not assume that educational purpose automatically makes a fee-charging operation noncommercial.
A practitioner must inspect the exact licence and applicable legal advice when the situation is consequential. This classroom example is not a real licence interpretation for any model.
10. Cedar: a broader rights and documentation package
Fictional Cedar supplies weights, inference code, training and modification information, and a documented licence granting the required use, adaptation and sharing permissions under this exercise’s assumptions. The centre can therefore consider it a plausible candidate for its local-and-commercial requirements.
That is a conditional conclusion about an invented document packet, not an OSI certification. The exact contents and terms would still need to be inspected before asserting that a real model conforms to the Open Source AI Definition. A technically open model may also run too slowly or poorly to satisfy tutoring needs.
This distinction matters in a purchasing decision. Meeting a licence checklist is necessary for some workflows, but does not replace empirical teaching-quality checks and operational responsibility.
11. Pine: proprietary but locally deployable
Fictional Pine is supplied under a paid self-hosting contract. The centre may run it locally for the agreed commercial purpose, but the contract restricts modification or redistribution. Training details remain limited in this packet.
Pine passes the locality and commercial-use conditions but fails the centre’s requirement to adapt the model. It also cannot be called open-source simply because its weights may be installed in a private machine room.
The example disproves a tempting shortcut: ‘runs on our servers’ does not mean ‘we have the rights and information to change it’.
12. A simple decision table needs explicit questions
For each fictional candidate, record local running, commercial-use permission, modification rights, documentation and toolchain support as separate fields. Fern fails local execution; Maple fails commercial permission; Pine fails adaptation rights. Cedar alone appears to pass those stated legal and technical gates under the simplified assumptions.
The result is a screening answer, not a final recommendation. No measurements of task accuracy, availability, maintenance effort, local device compatibility or learning benefit were supplied. An honest report should say ‘Cedar is the only candidate remaining for further testing’ rather than ‘Cedar is the best model’.
Decision quality improves when readers can identify exactly which document supports each check and what evidence is still missing.
13. Open model terminology needs careful scopes
Hugging Face’s Open Model explainer distinguishes open-weight, open-source AI, open-API and locally deployable systems. This is helpful because everyday language often uses the same word open for different parts of the development stack.
An open model might provide architecture and weights but not unrestricted usage rights. An openly accessible API might use a closed underlying model. A local model might be entirely proprietary. Describe the actual components and permissions instead of using a single badge.
Terminology varies across vendors and research communities, so keep the operative licence and artefact list visible in any real comparison.
14. A licence is not a benchmark result
A broad use licence can allow a centre to adapt a model, but it does not establish that its answers are accurate for Singapore educational material. A restricted service can still be excellent on particular tasks. Legal freedom and model quality answer different questions.
Test reading comprehension, Mathematics, Science explanations, source citations and changed-context questions using suitable reference answers. Record unexpected refusal, unsupported statements, bias and privacy failures. Include the appropriate subject expertise and human review.
Do not choose a model merely because it fits a philosophy about openness. Choose the operating arrangement that can legitimately and dependably meet the learner’s actual needs.
Continue across this AI curriculum branch: Quantisation, Caching and Compression · Deployment and Monitoring · Independent Learning. Together these chapters connect efficient computation, dependable operation, permission to use a model and the separate question of what a learner can do independently. Return to the complete numbered series.
15. Weights and training state are different resources
Downloading inference weights does not imply receiving optimiser states, exact training batches, random seeds or full training infrastructure. Replicating the training process may be difficult even when the released model can be run and fine-tuned.
The Distributed Training chapter explains gradient coordination, sharding and checkpointing. Those stages involve data and state not necessarily included with a model intended only for inference.
An honest research claim distinguishes ‘I can execute this released model’ from ‘I can reproduce the exact process that created it’.
16. Practical compute is another independent constraint
A model might be licensed for local commercial use yet require more memory than the centre’s available device provides. An imaginary twelve-gigabyte weight file is not guaranteed to fit in twelve gigabytes of working memory once activations, attention caches and runtime allocations are included.
Quantisation or a smaller specialised model might help, but may also change output quality. Test representative tasks and full application memory peaks. The licence cannot promise that hardware and latency are adequate.
Read Quantisation, Caching and Compression for the separate mechanisms of numerical representation and computation reuse.
17. A downloaded model still needs a maintenance owner
Someone must track security updates, library compatibility, licence revisions, input handling, evaluations and unexpected failures. Hosting locally moves many responsibilities from the provider to the operator. That could offer control while increasing technical work.
A managed provider may perform some infrastructure tasks on the customer’s behalf, though the customer still owns legitimate use and data governance. Compare responsibilities alongside visible prices rather than assuming local and hosted deployments have the same maintenance burden.
The desired outcome is reliable teaching support, not collecting model files for their own sake.
18. Privacy requires a complete information-flow inspection
A locally executed model can still produce logs, backups and exports that reveal student data. A hosted service can have documented security and privacy safeguards, but it requires checking contracts, supported controls and the particular data involved. Neither category is universally private by definition.
Map the task from source documents to input processing, model execution, retrieved information, output review and retention. Identify who may read each copy. A model licence grants rights to use software; it does not grant rights to upload confidential student records.
Responsible adoption treats software permission and personal-data authority as separate boundaries.
19. Security and updates matter under every licence
An openly accessible implementation can attract independent review, but visibility alone does not guarantee vulnerabilities will be found or repaired. A closed provider can patch a service, but users may have limited ability to inspect its internals. Security claims must be evaluated from specific evidence.
Check whether the deployment has appropriate identity controls, dependency management, logging, incident response and a process to update or roll back versions. A local model may introduce new exposure through poorly configured tools even if its weights are harmless files.
Do not treat open or closed as a universal security ranking.
20. Evaluation should test the complete application
Different packaging changes what a team can measure. With local weights, an evaluator may have additional options to inspect resource use or adapt a model. With a hosted API, the evaluator may rely more on observable input-output behaviour and provider documentation.
Both can be tested on task performance, response latency, source faithfulness and authorised tool outcomes. A comparison must use representative examples and describe differences in available tools and context. A system with stronger benchmarks is not necessarily easier for a teacher to oversee.
Reader decisions should rest on evidence produced under the intended operating conditions.
21. A worked cost boundary without invented vendor prices
Consider two fictional local models requiring different amounts of staff upkeep. Their download rights do not determine the operating bill. A local service may pay for hardware, energy, updates and technical support; a hosted service may charge by use. Both may incur human review and error repair.
Define the cost per successfully checked tutoring task rather than per model download or generated paragraph. A low token price or a zero-fee weight licence cannot prove the full service is inexpensive.
The Cost of Intelligence chapter offers a fictional hundred-job calculation showing why repair effort can reverse the apparent ranking.
22. Independent transfer: add an offline requirement
Change the school centre’s constraints. It still needs commercial use and permission to adapt, but now the application must function during a planned network outage. Which fictional candidates remain eligible from the original packet?
Fern remains ineligible because it is hosted-only. Maple still fails the commercial-use condition. Pine may run locally but does not meet the required adaptation permission. Cedar remains the provisional candidate under the fictional terms, provided the actual package can operate without external calls.
The last qualification matters. A downloadable model that relies on a remote licence check or retrieval endpoint may not satisfy the offline workflow. Verify actual network dependence rather than assuming the word local proves independence.
23. Independent transfer: relax the adaptation condition
Now suppose the centre no longer needs model modification. It still requires permitted commercial self-hosting and sufficient operational documentation. Cedar remains a candidate, while Pine may also meet the changed rights conditions, subject to its exact agreement and technical tests.
Under this changed task, it would be incorrect to repeat ‘Cedar is the only possible option’ merely because that was the earlier answer. Fern still fails locality and Maple still fails commercial permission, while Pine’s previous blocking condition has been removed.
This is the essential reasoning exercise: carry requirements explicitly, change only the named condition and recompute the eligible set.
24. A sensible model-selection worksheet
Ask which part of the system is actually accessible: API, weights, tokenizer, source code, training instructions or documented datasets. Read licence terms for commercial use, modification, redistribution and any sector restrictions. Record model version and available security updates.
Then test the real task under the intended operating conditions: language quality, source accuracy, privacy, human review, memory, latency, monitoring and full cost. Keep unanswered questions visible rather than declaring a winner from one attractive attribute.
An appropriate final outcome may be a shortlist for controlled evaluation, not a commitment to deploy. This is a strength of rigorous selection rather than a failure to make a decision.
25. Frequently asked questions
Are open weights automatically open-source AI? No. Weight availability alone does not establish the full rights and supporting material contemplated by the Open Source AI Definition.
Is a public API an open model? It offers access to model functionality, but the underlying weights and training system may remain private.
Does self-hosting guarantee privacy? No. Access controls, local logs, backups and connected services still matter.
Does openness guarantee better AI for pupils? No. Test task accuracy and educational usefulness independently. Legal freedom and observed capability are different properties.
Applying model rights to a real task: licence, operation, evaluation and maintenance
Why a licence gate comes before a speed benchmark
A school that intends to run a model in a fee-charging tutorial cannot treat downloadable files as permission for commercial use. The licence and intended operations must be compared before committing to expensive evaluation or deployment. Maple’s fictional noncommercial restriction blocks that planned use even though the model might be technically easy to install.
Technical performance can be examined for other authorised purposes, but a good procurement workflow separates the rights decision from the capability decision. A tool that runs an unapproved model successfully has demonstrated an operation, not justified its use.
A rights matrix should follow the intended activity
Write each proposed activity as a verb: download weights, host on school equipment, modify or fine-tune, share derivatives, charge for the service, distribute a copy, or disclose the model’s outputs. Then connect each activity to the governing licence or contract condition. A broad phrase such as ‘available for research’ does not settle every later commercial scenario.
A distinction between inference and modification also matters. Pine’s fictional contract permits commercial local inference but withholds adaptation rights. Cedar’s invented documents grant both under our assumed conditions. Those differences are more informative than a single column labelled open or closed.
The Open Source AI Definition tests more than downloadable weights
The Open Source Initiative’s Open Source AI Definition 1.0 describes essential freedoms to use, study, modify and share AI systems. It also discusses preferred forms for making modifications, including relevant model parameters, code and information about training data. It is a framework for evaluating the substance of a release, not a marketing suffix that automatically follows the words community model.
Raw training datasets need not simply be made public in every circumstance for the definition’s data-information requirement, especially where rights and privacy create constraints. That nuance should not be confused with claiming the training provenance never matters. A conscientious reader checks the definition’s actual requirements and the released materials.
Local operation is a technical claim to verify
A model offered for self-hosting may still rely on online authentication, a remote tokenizer, a hosted content filter or an external retrieval service. If a user requires operation without internet connectivity, merely finding downloadable weight files is insufficient evidence.
Test the complete proposed workflow within the permitted environment, including preprocessing, model execution, dependencies and output validation. An offline requirement is passed by an appropriately verified offline service, not by a promise that a licence mentions local deployment.
Weights are not a training recipe
Model parameters encode a learned computational state. Reproducing the original training process may require data curation, architecture details, optimisation configuration, random seeds, specialised hardware and other resources. Downloading weights alone does not establish reproducibility of the complete learning history.
This does not make the weights useless. They may support inference, evaluation and some permitted adaptations. The correct report distinguishes those achievable operations from an unsupported assertion that any researcher can reproduce the entire original model at the same cost and quality.
A legal pass is not a pupil-learning pass
Cedar remains the provisional legal and technical candidate under the fictional packet, but nothing yet establishes that it can explain Secondary Mathematics at an appropriate level or reliably check pupil answers. A model can be licensed for school use and still generate misleading Mathematics examples. A decision about educational suitability requires a separate evaluation.
Create fictional, age-appropriate tests with verified solutions, meaningful error examples and changed-context questions. Record how the tool responds when the source curriculum is missing or an algebra problem is ambiguous. Access rights answer whether the organisation may try the tool; they do not prove that the learner benefits.
A model’s cost depends on the whole permitted deployment
Running weights locally may create direct costs for hardware, electricity, security updates and a trained operator. A hosted service may charge per request while maintaining much of the infrastructure centrally. Without representative workload data, neither arrangement can be declared universally cheaper.
A decision should compare equivalent completed tasks, including checking and human review. The Cost of Intelligence chapter shows how cheaper generation can become costlier when errors are repaired. Here model rights shape which deployment options are even legally available.
Privacy depends on information flow, not the marketing label
Self-hosting can reduce some external transfers, but an organisation may still leak records through logs, support integrations or poor access controls. A proprietary hosted service may offer specific contractual protections, yet those protections must be examined against the actual data involved. Neither open weights nor closed APIs confer privacy automatically.
For a pupil feedback workflow, identify the permitted data categories, recipients, retention period, keys and administrator access. The intended school decision requires a real information-flow map, not an assumption that a model’s licence predicts its treatment of student material.
Updates and repairs still need an owner
Downloadable weights do not maintain themselves. New versions can change outputs and introduce regressions, while external packages can acquire security vulnerabilities. Someone must monitor relevant upstream releases, test changes, validate compatibility and decide when to update or roll back.
A managed service also changes over time, so the institution should document model versions and behaviour where its provider permits. The Deployment and Monitoring chapter develops those responsibilities. A school cannot offload all accountability merely by selecting one licensing category.
Public access does not automatically mean permission to redistribute
A website may invite anyone to try a model through an interface. That is service accessibility, not a grant to copy weights, modify software or resell the service. Even when code is downloadable, separate conditions may govern other assets or redistribution.
Model cards, contracts and licences should be read as separate evidence sources. If a term is unclear or a use is high stakes, the responsible organisation may need qualified legal review. This educational article explains how to frame the question; it does not determine actual rights for any commercial provider.
Changed-context exercise: the school no longer needs local running
Suppose Four Model School permits an online service but still requires commercial use and model adaptation rights. Under the original fictional packet, Fern offers hosted commercial use but does not grant the school model-modification rights; Maple remains restricted to noncommercial use. Pine’s local commercial contract continues to restrict modification. Cedar remains the sole provisional candidate for the specified full set of rights.
This conclusion depends on the exact fictional terms. If the centre removed the adaptation requirement as well, Fern and Pine might join Cedar for further evaluation, subject to their service contracts. The exercise teaches that a candidate set should be recalculated from the current requirements rather than carried forward from an earlier scenario.
The final model-selection checklist
Before adopting a model, state the intended task and deployment mode. Check weight access, permissible commercial use, modification and distribution rights, available source and training information, local dependency requirements, update responsibilities and privacy controls. Record the source and version for every claim.
After that legal and technical screen, run representative task-quality, cost, latency and recovery evaluations. An honest recommendation may be conditional, especially when a real product’s terms or capabilities could change. Model openness is one important dimension of a responsible decision, not a substitute for the decision itself.
26. Primary references and the eduKate reading route
Use the OSI Open Source AI Definition 1.0 and the Hugging Face Open Model explainer as starting points for distinguishing weights, code, training information and usage rights. The exact licence on a particular release controls legal permissions; this fictional laboratory is not legal advice or a certification.
Continue with Quantisation, Caching and Compression, Deployment and Monitoring and Privacy and Data Security. Return to How Super Intelligence Works, How X Works and Gold Standard of Education.
Every fictional candidate, licence scenario and eligibility outcome is invented educational material. No commercial licence, software release or product was legally assessed or purchased for this exercise. Source review: 22 October 2026.