fastai/fastbook: the notebook edition of Deep Learning for Coders, and its licence split
The fastai book, published as Jupyter Notebooks
At a glance
- What is it?
- fastbook is the Jupyter notebook source behind the fastai course and the O'Reilly book. The code is GPL v3, the prose is not licensed for redistribution, which makes it a teaching resource rather than a library to vendor.
- Who is it for?
- Adopt fastbook if you are learning deep learning through the fastai library and are willing to run the notebooks in Colab or a local Jupyter environment you control. Do not adopt it if you need a redistributable copy of the explanations, or if a training pipeline needs a maintained dependency rather than a teaching artifact.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What fastbook actually is, and who it is written for
fastbook is not a library. It is a set of Jupyter notebooks that cover an introduction to deep learning, the fastai library, and PyTorch, published by Jeremy Howard and Sylvain Gugger. The README states that the notebooks are used for a MOOC and form the basis of the O'Reilly book Deep Learning for Coders with fastai and PyTorch. The intended reader is someone who wants to learn deep learning by running code, not someone looking for a package to import.
The repository is organised as one notebook per chapter, from app_jupyter.ipynb and 01_intro.ipynb through to 20_conclusion.ipynb. Chapter titles in the README give a sense of the arc: production, ethics, MNIST basics, pet breeds, multi-category classification, sizing and test-time augmentation, collaborative filtering, tabular data, NLP, the mid-level API, a second NLP chapter, convolutions, ResNet, architecture details, optimizers and callbacks, foundations, GradCAM, and the Learner. That ordering matters. The early chapters use the high-level API, and the later ones open it up, so the notebooks double as a tour of fastai's layered design.
If you already write PyTorch and want a reference for training loops, this is the wrong shape of resource. It teaches a specific library's idioms, and the prose assumes you are following along in a notebook cell by cell.
How the notebooks are meant to run: Colab first, local second
The README recommends Google Colab for people getting started, on the grounds that there is no need to set up a Python development environment because you can work directly in the browser. Every chapter has a corresponding Colab link of the form https://colab.research.google.com/github/fastai/fastbook/blob/master/01_intro.ipynb. Opening that URL loads the notebook from the GitHub master branch into a Colab session, so the notebook you run is the one in the repository, not a copy you installed.
The alternative is the conventional route: clone the repository and open the notebooks in a local Jupyter environment. The README does not spell out a requirements file or a pinned fastai version, so the dependency surface is whatever the notebooks import at the time you run them. That is a real difference from a packaged project. There is no install command in the README, no setup.py instruction, and no documented environment lock. If a cell fails because a fastai API moved, the fix is to read the cell and adjust it, not to bump a version constraint.
Colab also imposes its own runtime. Sessions are ephemeral, so any dataset you download and any model you train disappears when the session ends unless you save it somewhere. The notebooks are written to be re-runnable, which means the early chapters re-download and re-train from scratch each time.
The licence split is the most consequential design decision
The README is unusually explicit here, and it is the thing to read before you copy anything. The code in the notebooks and the Python .py files is covered by GPL v3, with the LICENSE file as the authority. Everything else, including all markdown cells in the notebooks and other prose, is not licensed for redistribution or for a change of format or medium. The README permits making copies of the notebooks or forking the repo for private use, and states that no commercial or broadcast use is allowed.
That combination is worth pausing on. A notebook is a single file that mixes GPL v3 code cells with prose that carries a different, much narrower grant. You cannot cleanly separate them by file extension, because the markdown cells live inside the same .ipynb. The README also asks readers to tell anyone hosting a copy elsewhere that their actions are not allowed and may lead to legal action, and notes that the published book does not carry the same GPL restrictions as the repository.
For an engineer, the practical reading is that fastbook is fine to study, fork privately, and run. It is not a source you can lift explanations from into your own documentation, and it is not a corpus you can republish. This is a deliberate choice by the authors, not an oversight, and it is stated plainly rather than buried.
Contributions assign copyright, which narrows the usual open source path
The contributions section says that if you make a pull request, you are assigning copyright of that work to Jeremy Howard and Sylvain Gugger. That is a contributor assignment rather than the inbound-equals-outbound model many projects use, and it is consistent with the licence split: the authors retain the ability to license the prose commercially through the book, so they need to hold the rights.
For most readers this is irrelevant. For anyone hoping to fix a typo or improve a chapter and see their name on a permissively licensed derivative, it changes the calculus. The README also asks that small spelling or text edits specify the file name and a brief description of the fix, because reviewers cannot easily tell which corrections have already been made. That is a maintenance detail, and it hints at how many small corrections arrive.
The repository is not archived. The last push was on 2026-09-13, which is recent. The release history tells a different story: the most recent releases listed are 0.0.19 and 0.0.18, both dated 2022-04-16. Versioned releases have not moved in years, so treat the notebooks on master as the artifact and the tags as historical markers rather than a channel you should pin to.
Where fastbook stops being the right tool
The notebooks teach fastai. If your team has settled on plain PyTorch, Keras, or JAX, the fastai-specific material is overhead. You will spend chapters learning an API you will not call.
The second limitation is reproducibility. The README documents no pinned dependency set and no install command, so a reader returning to a notebook months later may find that a cell no longer runs against the current fastai release. That is normal for teaching material that tracks a moving library, but it is a poor fit if you need a fixed environment to hand to a class or a new hire. The Colab links always point at master, which means the notebook content can change under you between sessions.
The third is the licence. If your use case involves redistributing the explanations, translating a chapter, or embedding the prose in an internal course platform, the README's terms do not grant that. You would be relying on the published book, which the README says does not carry the same GPL restrictions, and on whatever terms that book carries.
Finally, the notebooks are not a benchmark or a reference implementation. There is no performance claim to rely on and no production deployment guidance beyond the production chapter's content. Do not treat a chapter's approach as an endorsement of that approach at scale.
fastai versus PyTorch as the thing you actually adopt
The clearest alternative is PyTorch itself, which the README names as one of the three subjects the notebooks cover, alongside fastai and deep learning generally. The difference in approach is layering. fastai is described in the README as a layered API for deep learning, and the fastai paper is linked for the design rationale. PyTorch gives you tensors, autograd, modules, and an optimiser loop, and leaves the training loop, the data pipeline, and the callbacks to you or to a separate library.
fastbook's later chapters make that layering visible. Chapter 11 covers the mid-level API, chapter 16 covers optimizers and callbacks, chapter 17 covers foundations, and chapter 19 covers the Learner. Reading those in order is effectively a guided tour of what fastai adds on top of PyTorch, which is more useful than a feature list. If you want to understand the abstraction rather than just call it, the notebooks are structured for that.
The trade-off is that fastai's defaults are opinionated. They encode choices about learning-rate finding, augmentation, and training schedules that are sensible for the book's examples. If your problem sits outside those defaults, you will be working against the framework rather than with it, and the notebooks will not prepare you for that as well as a lower-level PyTorch codebase would.
Maintenance, upgrade cost, and what to verify before you start
The repository is not archived, and the last push was on 2026-09-13. That is recent activity, but it does not tell you what changed. The README does not document a changelog, a deprecation policy, or a rollback path, and the release tags have been static since 2022-04-16. If you build a course around a specific notebook, capture the notebook content yourself rather than relying on the master branch to stay put.
Upgrade cost is asymmetric. Since there is no packaged dependency, upgrading means re-running notebooks and fixing cells that break against a newer fastai. The README offers no compatibility matrix. For a solo learner this is a minor annoyance. For an instructor maintaining twenty notebooks for a cohort, it is the dominant cost, and the README's contribution process (specify the file and a brief description) suggests that even small corrections are handled manually.
On licensing, the split between GPL v3 code and unlicensed prose is the first thing to confirm. Read the LICENSE file rather than the README summary, since the README points there for details. If your intended use is commercial, broadcast, or redistribution of the explanatory text, the README's terms do not cover it, and this article is not legal advice. The safe starting point is to run the notebooks in Colab from the links in the README, keep any fork private, and treat the published book as the channel for anything you intend to share.
Editorial conclusion
Adopt fastbook if you are learning deep learning through the fastai library and are willing to run the notebooks in Colab or a local Jupyter environment you control. Do not adopt it if you need a redistributable copy of the explanations, or if a training pipeline needs a maintained dependency rather than a teaching artifact. Before you commit, open the LICENSE file to confirm how far the GPL v3 code grant reaches, and check the chapter list against your fastai version.
Community notes