gnu-octave/octave: a mirror of GNU Octave, and where the real work happens

This is a mirror, so the pull request button is the wrong door

The repository description says it plainly: GNU Octave Mirror, with a link to the Mercurial repository on octave.org, followed by the instruction to report bugs and submit pull requests, patches, at bugs.octave.org. The README makes the same point from the other direction by describing the BUGS file and doc/interpreter/bugs.txi as the place that explains the recommended procedure for reporting bugs on the bug tracker or contributing patches.

So the workflow has two halves. This repository is where the source lives, mirrored, with the tags and the default branch named default. Bugs.octave.org is where changes originate. A pull request opened here would be aimed at a mirror rather than at the project, and the project's own documentation redirects you elsewhere.

The branch naming is a small clue about the history. The default branch is called default rather than master or main, and the top level still carries .hgignore and .hgtags alongside .github, which reflects a project that lived in Mercurial before moving to Git. The build system in the tree is autotools: autogen.sh, configure.ac, bootstrap, bootstrap.conf, bootstrap-funclib.sh and build-aux/ are all present, along with Makefile.am and the top level Makefile machinery.

The source layout is the familiar division for a project this size: liboctave/ for the core, liboctinterp/ for the interpreter, liboctgui/ for the graphical interface, liboctmex/ for the mex interface, src/ and scripts/ for the executable and its helpers, doc/ for the manual, and test/ and examples/ for the test suites and sample code.

The last push was on 2026-10-02, and the repository is not archived.

Downloading means verifying a GPG signature, and the procedure is written out

The availability section states that the latest released version of Octave is always available from ftp.gnu.org/gnu/octave/ and from many mirror sites, with links to binary distributions at the download page and the current development sources under the Source Code tab on Savannah.

The verification procedure is unusually explicit, and it is the part of the README that any engineer downloading a release should actually follow. You are encouraged to verify the installation file you download, and the example file given is octave-11.1.0.tar.xz.

First, make sure you are downloading from the official Octave website or from a GNU mirror linked from it. Then download the corresponding signature file, for example octave-11.1.0.tar.xz.sig. Then import the public key, which needs to be done only once:

  gpg --keyserver hkps://keys.gnupg.net --recv-keys B05F05B75D36644B

That imports John W. Eaton's public key. After that, verify the file you downloaded:

  gpg --verify octave-11.1.0.tar.xz.sig

If everything is well, the output should say:

  gpg: Good signature from "John W. Eaton <[email protected]>

And if the file was corrupted or changed by anyone else, the output will say:

  gpg: BAD signature from "John W. Eaton <[email protected]>"

In that case the instruction is not to install from that file but to start over. The key fingerprint is worth writing down separately, because the whole point of the procedure is defeated if you fetch a key from whatever server answers first and trust it implicitly.

Building from source costs disk space and a GNU-specific toolchain

The disk figures in the README are the ones to look at before you start. Building Octave from source requires approximately 475 MB of disk space, or approximately 3.8 GB with debugging symbols. Once installed, Octave uses approximately 75 MB of disk space, or approximately 415 MB if shared libraries are not built or the binaries include debugging symbols.

That second figure is worth parsing carefully, because it describes two different configurations. A build with shared libraries is the compact one. Building without shared libraries, or shipping binaries that carry debugging symbols, is what pushes the installed footprint to around 415 MB. If you are installing Octave alongside other numerical tooling on a shared machine, that is the difference that matters, and the choice is made at configure time rather than afterwards.

The compiler requirements are narrower than you might expect from a project of this age. You need a recent version of GNU Make, GNU G++ or a different C++20 compiler, and GNU Fortran, a different Fortran 77 compiler, or f2c. The C++20 requirement is the notable one: this is a C++ codebase that expects a modern standard.

The Makefile dependency is not a formality either. The README states that Octave's Makefiles use features of GNU Make that are not present in other versions of make, so a BSD make or a minimal build tool will not work. If you use f2c as the Fortran path, you need a script like fort77 that behaves like a normal Fortran compiler by combining f2c with your C compiler in a single script, which is more setup than most people expect.

For the detailed procedure, the README points at the INSTALL.OCTAVE file in the top level directory and the wiki page on building.

The language is a Matlab dialect, and the licence is GPL-3.0

GNU Octave is described as a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems and for performing other numerical experiments, and it also provides extensive graphics capabilities for data visualisation and manipulation.

The interface story is worth noting because it covers more than one workflow. Octave is normally used through its interactive interface, both a command line and a GUI, but it can also be used to write non-interactive programs. That second mode is what makes it usable in a batch pipeline rather than only at a prompt.

The compatibility claim is the one that decides whether Octave fits your project: the language is quite similar to Matlab, so that most programs are easily portable. Easily is the operative word, and the project is not claiming identical semantics. Portability in the Matlab to Octave direction is a much better supported claim than the reverse, and the documentation section points to a user manual that is described as covering introductory and more advanced topics, a wiki with a FAQ, and Doxygen documentation for the C++ class libraries.

On the licence, Octave is free software under the GNU General Public License, version 3 or at your option any later version, with the copyright held by the Octave Project Developers from 1996 to 2026 and the details in COPYRIGHT.md in the top level directory. The repository carries the GPL text in COPYING. There is also a CITATION file and an octave.doap file in the tree, which are the markers a project adds when it wants to be cited and to be listed in software directories.

For a commercial project, the GPL-3.0 terms mean that a distributed derivative of Octave carries source availability obligations. That is a licensing question for your own review, but the important structural point is that Octave is copyleft, so linking it into a closed product is a different proposition from using a permissive numerical library.

Release tags arrive as a numbered series, and the mirror carries them all

The recent release list on this repository shows three tags in the 11 series, release-11-1-0, release-11-2-0 and release-11-3-0, all published on 2026-07-10. The dates being identical across the three tags reflects how a mirror records upstream history rather than three separate release events on one day, but the tag naming is the real signal: a three-part version after the major number, one tag per patch level.

The pattern across the list is that patch releases accumulate, so a numbering scheme of 11.1.0, 11.2.0, 11.3.0 rather than 11.1.0 and 11.1.1 is what the project uses for a sequence of individual releases. If you are tracking the source rather than a binary package, the tags are how you decide where to check out.

The repository has no GitHub releases attached, so the tags and the commit history are the release record. The README also carries a small set of support pointers beyond the bug tracker: the Octave website, a forum on discourse, and the support page at octave.org/support, where online resources for reporting bugs and contributing patches are said to be available.

The documentation guidance closes the loop on the project's own standards. If you notice omissions or inconsistencies in the documentation, the request is to report them at the bug tracker, with specific suggestions welcome and reports with patches even more welcome. In a project with a mirror as the public face, that redirect to the tracker is the pattern to remember for everything except reading the code.

Editorial conclusion

The gnu-octave/octave repository suits contributors who want a hosted copy of the Octave source to read, clone or build, and it is a reasonable mirror to watch for release tags. It does not suit you as a place to file issues, because the repository description and the README both route bug reports and patches to the upstream tracker at bugs.octave.org, and the bug reporting procedure lives in the BUGS file and doc/interpreter/bugs.txi. Before you build, read INSTALL.OCTAVE and the wiki build page, and check the disk figures, since the source build needs about 475 MB before install and about 3.8 GB with debugging symbols, which is the difference between a one-off build and a comfortable development tree.

Frequently asked questions

Official sources

1. gnu-octave/octave on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases