# Caffe: a mandatory Makefile.config, BSD 2-Clause, and a 2017 release tag > Caffe is the C++ deep learning framework from BAIR and BVLC, and the repository is still readable and buildable. The build refuses to start until you create Makefile.config, the vendor builds live on branches, and the last release tag is 1.0 from April 2017. **BVLC/caffe** — Caffe: a fast open framework for deep learning. - Repository: https://github.com/BVLC/caffe - Website: http://caffe.berkeleyvision.org/ - Stars: 34,548 · Forks: 18,402 - Language: C++ - License: NOASSERTION - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/bvlc-caffe ## Makefile.config is mandatory, and make -k would sail past it Caffe's build refuses to start until you write a config file. The Makefile names it up front as CONFIG_FILE := Makefile.config and includes it on the next line. When the file is missing, the build stops with an error reading Makefile.config not found. See Makefile.config.example, which is why Makefile.config.example sits at the top of the repository next to INSTALL.md and CMakeLists.txt. The reason for the check is written in a comment above it: without the explicit test, make -k proceeds anyway. That is the practical trap. A parallel build with -k is a reasonable thing to want on a C++ project, and on Caffe it is precisely the mode in which a missing config can slip through and surface later as something harder to read. Set the file up before the first build rather than after the first strange error. CMakeLists.txt and the cmake/ directory offer a second build path, but the README prints no commands of its own and sends you to the installation instructions page at caffe.berkeleyvision.org for the steps. ## The build emits libcaffe.a and libcaffe.so.1.0.0 with the version baked in The Makefile produces two library shapes and hardcodes a version into both. STATIC_NAME resolves to libcaffe.a inside the build directory, and the shared object is versioned as libcaffe.so.1.0.0 from DYNAMIC_VERSION_MAJOR 1, DYNAMIC_VERSION_MINOR 0 and DYNAMIC_VERSION_REVISION 0. Those same three numbers reach every compile through COMMON_FLAGS += -DCAFFE_VERSION=1.0.0, so code that asks the library its version reads a value frozen by the Makefile rather than one taken from the repository tags. One line in that block is commented out: DYNAMIC_SONAME_SHORT. The versioning scheme is therefore visible while the soname assignment is not switched on, which matters when the shared object is packaged into a system library directory or an image where something else links against it. Source discovery is plain find over src/caffe with test_*.cpp and test_*.cu excluded, so a new file enters the build by existing in the tree rather than by being registered anywhere. ## Intel, OpenCL and Windows support are branches, not separate projects The three vendor flavours live in this same repository rather than in separate projects. Intel Caffe sits on the intel branch, described as optimized for CPU and with support for multi-node, in particular Intel Xeon processors. OpenCL Caffe sits on opencl, aimed at AMD or Intel devices. Windows Caffe sits on windows. Each is reached as a tree path under BVLC/caffe. The cost of that arrangement is that three forks share one name and one issue tracker while diverging in code. The README does not say how closely the intel branch tracks master, how often it is rebased, or which of the three carries a given fix. A team standardising on Intel Caffe for a Xeon deployment is choosing a branch whose divergence it has to measure itself, while the tutorials and reference models the README points to are written against master. ## The tutorial link is a slide deck; the notebooks are the real documentation The reference material is uneven. Tutorials live at caffe.berkeleyvision.org/tutorial/, and the first link in the README is a Google Slides deck called DIY Deep Learning for Vision with Caffe, which is a presentation you cannot search or version. Models come from two places, BAIR reference models on the project site and a community model zoo kept as a GitHub wiki page. The examples directory is where the repository earns its keep. It ships notebooks you can read in place: 00-classification.ipynb, 01-learning-lenet.ipynb, 02-fine-tuning.ipynb, detection.ipynb, net_surgery.ipynb, brewing-logreg.ipynb and pascal-multilabel-with-datalayer.ipynb, beside runnable directories for cifar10, mnist, imagenet, siamese, hdf5_classification, finetune_flickr_style, finetune_pascal_detection, feature_extraction, cpp_classification, pycaffe and web_demo. Start there instead of with the deck. Each notebook is versioned with the branch rather than with the wiki, so an example and a model link can drift apart, and the web_demo example is the one to look at if you need the serving path rather than the training path. ## python/ wraps a C++ core, so pycaffe inherits the native build Caffe's primary language is C++, and the Python tree is a layer over it rather than a replacement for it. The top level carries include/, src/, python/, matlab/, tools/, scripts/, data/, docs/ and models/, with a .Doxyfile for API documentation and caffe.cloc for a line count. pycaffe/ appears among the examples, and python/ is what lets a notebook import the framework at all. That shape has a consequence for teams arriving from Python. Importing the Python interface does not remove the C++ build. The library that python/ wraps is the one produced by the Makefile described above, so a pycaffe environment inherits the same Makefile.config requirement, the same compiler expectations and the same library versioning as a pure C++ consumer. Treat the notebooks as evidence that the framework is scriptable, not as evidence that the native build can be skipped. The matlab/ directory in the same tree is that arrangement repeated one interface over. ## BSD 2-Clause for the code, unrestricted use for the reference models The README states that Caffe is released under the BSD 2-Clause license and links the LICENSE file at the top of the repository. It then draws a separate line for the assets: the BAIR and BVLC reference models are released for unrestricted use. Two grants over two sets of files means the model you download from the project site and the framework you build from source do not carry the same terms. Then there is the citation. The README asks you to cite Caffe in publications if it helps your research and gives the reference as Jia, Shelhamer, Donahue, Karayev, Long, Girshick, Guadarrama and Darrell, an arXiv preprint numbered 1408.5093 from 2014. That is a request printed in a README rather than a clause in the BSD terms, and the models are described as unrestricted. What it does mean is that a published paper is expected to carry that reference, which is reason enough to keep the arXiv identifier next to the model rather than lose it in a download folder. ## Last push 2024-07-31 against a 1.0 tag from April 2017 Two dates frame any decision here. The repository is not archived, and the last push was 2024-07-31. The most recent release tag is 1.0 from 2017-04-18, preceded by the release candidate rc5 on 2017-02-21 and rc4 on 2017-01-20, so the distance between the last tagged release and the last commit is measured in years rather than weeks. Support for a project in that position runs through people rather than process. The README points to the caffe-users Google group and a Gitter room for questions, and says framework development discussions and thorough bug reports are collected on GitHub Issues, with CONTRIBUTING.md and CONTRIBUTORS.md in the tree and a Travis badge wired to .travis.yml. None of that comes with a stated support window, so the useful check before adopting Caffe is whether the problem you are trying to solve already has a fix in a branch, an issue or somebody's fork. A C++ deep learning framework with a last push on 2024-07-31 is a codebase you can read and vendor; it is not a destination for a bug report you expect to be answered. ## Conclusion Adopt Caffe when you need a specific reference model, you are already building C++ and can maintain the build yourself, and the last commit on 2024-07-31 leaves you comfortable vendoring a tree that has had no tagged release since 2017-04-18. Do not adopt it expecting an answered issue tracker, and stay on master unless you measure what the intel, opencl or windows branches diverge from. Before you start, copy Makefile.config.example to Makefile.config, because the Makefile stops with an error until that file exists, and read the notebooks under examples/ rather than the slide deck, since that is where the working code is. ## FAQ ### How do I install Caffe? The README sends you to the installation instructions at caffe.berkeleyvision.org/installation.html, and the repository ships INSTALL.md, CMakeLists.txt and Makefile.config.example. The build stops with an error until Makefile.config exists, so producing that file from the example is the first step any of those routes reaches. ### What licence is Caffe released under? The README says BSD 2-Clause and links the LICENSE file in the repository root. It states separately that the BAIR and BVLC reference models are released for unrestricted use, so the models and the framework do not carry the same grant. ### Is Caffe still being developed? The repository is not archived and the last push was 2024-07-31, but the most recent release tag is 1.0 from 2017-04-18, after rc5 on 2017-02-21 and rc4 on 2017-01-20. The README states no support window and no roadmap. ### Where are the Caffe models, tutorials and worked examples? The README links BAIR reference models and a community model zoo wiki, plus tutorial documentation at caffe.berkeleyvision.org/tutorial/ and a slide deck titled DIY Deep Learning for Vision with Caffe. Runnable examples live in the repository itself as Jupyter notebooks and directories under examples/, including cifar10, mnist, imagenet, siamese and pycaffe. ### Does Caffe have Intel, OpenCL or Windows builds? Yes, as branches of this repository rather than separate projects. Intel Caffe on the intel branch is described as optimized for CPU with support for multi-node on Intel Xeon processors, OpenCL Caffe on opencl targets AMD or Intel devices, and Windows Caffe sits on the windows branch. ## Sources - [Official documentation](http://caffe.berkeleyvision.org/) - [Official README](https://github.com/BVLC/caffe#readme) - [Project repository](https://github.com/BVLC/caffe) - [Release notes](https://github.com/BVLC/caffe/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bvlc-caffe