owncloud/core: the PHP server behind ownCloud Classic, and the licence question hanging over it
:cloud: ownCloud web server core (Files, DAV, etc.)
At a glance
- What is it?
- owncloud/core is the AGPL-3.0 PHP server for ownCloud Classic, covering WebDAV, CalDAV, CardDAV, sharing and a plugin API. The code is still maintained, but the repository's own README states that a relicensing to Apache 2.0 is in progress, which changes how you should plan an adoption.
- Who is it for?
- Adopt owncloud/core if you need a self-hosted PHP file sync and share server with WebDAV, CalDAV and CardDAV endpoints and an app ecosystem you can extend in PHP, and if AGPL-3.0 obligations are acceptable for your deployment. Do not adopt it if you need permissively licensed server code to embed in a closed product, or if you want the actively developed next-generation platform, which the README points to as ownCloud Infinite Scale.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly PHP, 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 owncloud/core actually is, and who ends up running it
owncloud/core is the server-side component of ownCloud Classic. The README describes it as providing file storage, synchronization and sharing, and lists WebDAV, CalDAV and CardDAV servers, a plugin architecture for apps, user and group management, encryption support, external storage backends and a REST API. The server runs on PHP and supports MySQL, MariaDB, PostgreSQL and SQLite. That combination defines the audience: teams that want a file sync and share service on their own hardware, with a DAV surface that desktop and mobile clients can talk to, and with the option to write PHP apps against an internal API. It is not a general purpose web framework and it is not a storage layer you drop into an existing application. The repository is the foundation that apps such as Activity, Calendar and Contacts extend, so a deployment is rarely just this codebase. The practical unit of installation is the server plus whichever app set you need. The README also points out that this is the Classic line, and directs readers to ownCloud Infinite Scale (oCIS) for the next-generation platform. That pointer matters more than a footnote: it tells you which of the two codebases the vendor treats as the forward path.
The DAV endpoints and the app plugin layer are the two load-bearing parts
Two mechanisms carry most of the weight. The first is the set of DAV servers. WebDAV handles file synchronisation, and CalDAV and CardDAV handle calendars and contacts. Because these are standard protocols rather than a bespoke sync API, clients do not need ownCloud-specific code to read and write data, and the REST API sits alongside them for operations that DAV does not express. The second is the plugin architecture. Apps register with the server and extend it, which is why the repository can stay relatively small in concept while deployments grow large in practice. The cost of that design is visible in the dependency direction: the server defines the interfaces, and the apps in sibling repositories track them. Upgrading the server without matching app releases is the classic way to break a working instance. The README does not document the plugin interface itself, and instead routes developers to the developer manual. For anyone evaluating the architecture before installing, that means the interface contract is not in this repository's README and has to be read from the documentation site.
Building from source and the make target
The README's development build prerequisites are Composer v2, plus Yarn and Node.js v14 or higher. With those in place, the documented build step is a single command: make. The README does not expand what the Makefile does, so treat that as the entry point rather than a complete build recipe. Installation of a real instance is deliberately out of scope here: the README says to see the official installation manual at doc.owncloud.com under the server admin manual installation section. It also notes that the server is published as a Docker image on Docker Hub under the owncloud/server repository, which is the route most people will take rather than a source build. Database support is stated as MySQL, MariaDB, PostgreSQL and SQLite, and the installation manual is the place to confirm which of those is recommended for a given release. If you are contributing rather than deploying, the README sets out the workflow rules: a rebase workflow, PGP or GPG signed commits, and a Signed-off-by line on every commit, with the example git commit -s -S -m "your commit message". GitHub Actions workflows are restricted to actions owned by owncloud, created by GitHub under actions/*, or verified in the GitHub Marketplace. Translations go through Transifex, and the README explicitly asks contributors not to open pull requests for translation changes.
The AGPL-3.0 licence, and the announced move to Apache 2.0
The repository is licensed AGPL-3.0, and the README states this plainly. The more consequential detail is the licence migration section. The Open Source Program Office, described as the Kiteworks Open Source Program Office operating under the ownCloud brand, says it is driving a strategic relicensing of ownCloud repositories toward Apache 2.0, following the Apache Software Foundation's third-party license policy. Repositories migrate as their audit completes, and the README is explicit that the LICENSE file in each repo reflects current status, not the target. For this repository the stated prerequisites are demanding. All past contributors must have signed agreements permitting relicensing. Every AGPL or GPL dependency must be replaced or isolated. Code carrying KDE-era copyrights requires legal analysis. And because AGPL-3.0 is a strong copyleft licence, the README says migration requires full relicensing of all files rather than a header change. It also notes that AGPL-3.0 is Category X under the Apache policy and cannot be included in Apache-2.0 works. The honest reading is that the target licence is a stated intention with a list of unresolved prerequisites, not a shipped fact. This is not legal advice; if the licence governs how you distribute or host the software, get your own review of the COPYING file in the exact tag you deploy.
Where the Classic line stops and oCIS begins
The clearest limitation is structural rather than technical. The README presents ownCloud Classic as the current repository and ownCloud Infinite Scale as the next-generation platform, with a direct link to the oCIS repository. Two server products under one brand means new investment is not evenly distributed, and an operator has to decide which line they are betting on. Choosing Classic means choosing the PHP stack, the app ecosystem built around it, and the DAV and REST interfaces described here. Choosing oCIS means a different codebase entirely. The README does not provide a migration path between them, a feature comparison, or a statement about how long Classic will be supported. That absence is the thing to press on before a multi-year commitment. A second limitation sits in the app model. Because functionality such as calendars and contacts lives in separate repositories, the server alone does not deliver a complete collaboration suite, and the compatibility of each app with a given server release is a separate question the README does not answer. A third is the licence itself. If your plan involves embedding the server in a product you distribute under other terms, AGPL-3.0 is a constraint now, and the Apache 2.0 change is not something you can schedule around.
What you would use instead, and how the approach differs
The alternative named in the material is ownCloud Infinite Scale, the next-generation platform the README links to for anyone who wants to move past Classic. The difference is not a feature checkbox, it is a different codebase with a different server implementation, so the app ecosystem, the build process and the operational model described in this repository do not carry over. That makes the choice a fork in the road rather than an upgrade. If you are already running Classic, the practical question is whether your apps and integrations exist on the other side, and the README does not answer that. If you are starting fresh and have no investment in PHP apps, the pointer in this README is a signal about where the vendor's next-generation effort sits. Beyond that comparison, the material here does not name or describe any other file sync and share server, so I will not invent one. The decision framework the README supports is narrow: Classic if you want this PHP server and its DAV and app model, oCIS if you want the platform the README calls next-generation.
Upgrade and maintenance cost in a two-line repository family
The maintenance picture follows from the repository layout. The server is one repository; Activity, Calendar, Contacts and others are separate ones. Every server release is therefore a coordination event, and the release list shows both a major line and a stable line being maintained in parallel: v11.0.0 with a release candidate v11.0.0-rc3, and v10.16.4 published the same month. Running two supported lines means security fixes and compatibility work are duplicated across them, and it means you have to know which line you are on before you read any changelog. The README does not publish a support window or an end-of-life date for either line, so the upgrade cadence is something you establish from the release notes and the installation manual rather than from this document. Contributions carry their own cost: signed commits, DCO sign-off on every commit, a rebase workflow, and a restricted allowlist for CI actions. For an operator who never sends a patch, most of that is irrelevant. For a team that maintains private apps against the plugin interface, the signed-commit and rebase rules apply the moment they upstream anything, and the app-versus-server version coupling is the recurring tax.
Editorial conclusion
Adopt owncloud/core if you need a self-hosted PHP file sync and share server with WebDAV, CalDAV and CardDAV endpoints and an app ecosystem you can extend in PHP, and if AGPL-3.0 obligations are acceptable for your deployment. Do not adopt it if you need permissively licensed server code to embed in a closed product, or if you want the actively developed next-generation platform, which the README points to as ownCloud Infinite Scale. Before committing, verify three things: the current licence file in the tag you intend to deploy, whether each app you depend on has been released against that tag, and whether your database backend is one the installation manual lists. The Apache 2.0 migration is announced, not finished, and the README states that the LICENSE file reflects current status rather than the target.
Community notes