Nextcloud on Björn Schießle - I came for the code but stayed for the freedom

Nextcloud and OpenID-Connect

Björn Schießle (bjoern@schiessle.org) — Tue, 04 Jul 2023 08:00:00 +0200

This is a updated version of a old blog post from 2020. The guide here was tested with Nextcloud Hub 5 and Keycloak 21.1.2.

Please keep in mind, the main goal of this article is to get Keycloak up and running quickly to test the Nextcloud OIDC connector. It is not a detailed guide how to setup Keycloak for production! It is quite likely that I missed some important security setting which you would like to enable for a live system.

Get a OpenID Connect provider

After installing Keycloak we go to http://localhost:8080/admin which is the default URL in “standalone” mode and login as admin. The first thing we do is to configure a new Realm in the “Realm Settings”. We only set a Realm name, no “resource file” needed:

Next we move on to the “Clients” tab, and created a new client. In the dialog we first set a random “Client ID”, I have chosen “nextcloud” in this example.

On the second page we enable “Client authentication”

and on the last page we set the “Root URL” to the Nextcloud, in this case “http://nextcloud.local”.

All other settings are already set correctly, this is now the final client setting looks like:

Finally we create a user who should be able to login to Nextcloud later.

While technically the “Username” is enough I directly set email address, first- and second name. Nextcloud will reuse this information later to pre-fill the users profile nicely. Don’t forget to go to the “Credentials” tab and set a password for your new user.

That’s it, now we just need to get the client secret fot the final Nextcloud configuration. We can find this in the credential tab of the “nextcloud” client settings:

Nextcloud setup

Before we continue, make sure to have the following two lines in your config.php:

'allow_local_remote_servers' => true,
'debug' => true,

Otherwise Nextcloud will refuse to connect to Keycloak on localhost through a unsecure connection (http).

Now we can move on and configure Nextcloud. If you go to the Nextcloud apps management and search for “openid” you will not only find the official app but also the community apps. Make sure to chose the app called “OpenID Connect user backend”. Just to avoid misunderstandings at this point, the Nextcloud community does an awesome job! I’m sure the community apps work great too, they may have even more features compared to the official app. But the goal of this article was to try out the officially supported OpenID-Connect app.

After installing the app we go to the admin settings where we will find a new menu entry called “OpenID Connect” on the left sidebar and register a new provider:

The app supports multiple OpenID Connect providers in parallel, so the first thing we do is to chose a “Identifier” which will be shown on the login page to let the user chose the right provider. For the other fields we enter the “Client ID”, “Client secret” and “Discovery endpoint” from Keycloak. The discovery endpoint looks like the following: http://<your-keycloak-base-url>/realms/<REALM-NAME>/.well-known/openid-configuration. As you can see there are many more configuration parameters, for example a custom attribute mapping. But for the base installation we are complete.

Now let’s try to login with OpenID Connect:

As you can see, we have now an additional button called “Login with Keycloak”. Once clicked we get redirected to Keycloak:

After we successfully logged-in to Keycloak we get directly redirected back to Nextcloud and are logged-in. A look into our personal settings shows us that all our account detail like the full name and the email address where added correctly to our Nextcloud account:

Nextcloud and OpenID-Connect

Björn Schießle (bjoern@schiessle.org) — Sun, 26 Jul 2020 08:00:00 +0200

NOTE: There is a updated version of the article which works with the latest Nextcloud and Keycloak. Please continue here!

If you looked at the Nextcloud app store you could already find OpenID-Connect connectors before but since Nextcloud 19 it is an officially supported user back-end. So it was time for me to have a closer look at it and to try it out.

Get a OpenID Connect provider

First step was to get an OpenID-Connect provider, sure I could have chosen one of the public services. But why not have a small nice provider running directly on my machine? Keycloak makes this really simple. By following their Getting Started Guide I could setup a OpenID-Connect provider in just a few minutes and run it directly on my local demo machine. I will show you how I configured Keycloak as an OpenID-Connect provider for Nextcloud but please keep in mind, this is the first time I configured Keycloak and my main goal was to get it running quickly to test the Nextcloud connector. It is quite likely that I missed some important security setting which you would like to enable for a productive system.

After installing Keycloak we go to http://localhost:8080/admin which is the default URL in “standalone” mode and login as admin. The first thing we do is to configure a new Realm in the “Realm Settings”. Only “Name” and “Display name” need to be set, the rest can be kept as it is:

Next we move on to the “Clients” tab, and created a new client:

Set a random “Client ID”, I chose “nextcloud” in this example, and the root URL of your Nextcloud which is http://localhost/stable in this case. After that we get redirected to the client configuration page. Most settings are already set correctly. We only need to adjusted two more settings.

First we set the “Access Type” to “confidential”, this is needed in order to get a client secret which we need for the Nextcloud setup later on. While the “Valid Redirection URIs” work as it is with the wildcard, I used the one proposed by the Nextcloud OIDC app http://localhost/stable/index.php/apps/user_oidc/code. This is the Nextcloud end-point to which Keycloak will redirect the user back after a successful login.

Finally we create a user who should be able to login to Nextcloud later.

While technically the “Username” is enough I directly set E-Mail address, first- and second name. Nextcloud will reuse this information later to pre-fill the users profile nicely. Don’t forget to go to the “Credentials” tab and set a password for your new user.

That’s it, now we just need to grab a few information to complete the Nextcloud configuration later on.

First we go back to the “Realm Settings” of the “OIDCDemo”, under “OpenID Endpoint Configuration” we get a JSON document with all the parameter of our OpenID-Connect end-point. For Nextcloud we only need the “authorization_endpoint” which we find in the second line of the JSON file.

The second value is the client secret. We can find this in the credential tab of the “nextcloud” client settings:

Nextcloud setup

Before we continue, make sure to have this line in your config.php 'allow_local_remote_servers' => true,, otherwise Nextcloud will refuse to connect to Keycloak on localhost.

Now we can move on and configure Nextcloud. As mentioned before, the official OpenID-Connect app was released together with Nextcloud 19, so you need Nextcloud 19 or later. If you go to the Nextcloud apps management and search for “openid” you will not only find the official app but also the community apps. Make sure to chose the app called “OpenID Connect user backend”. Just to avoid misunderstandings at this point, the Nextcloud community does an awesome job! I’m sure the community apps work great too, they may even have more features compared to the new official app. But the goal of this article was to try out the officially supported OpenID-Connect app.

After installing the app we go to the admin settings where we will find a new menu entry called “OpenID Connect” on the left sidebar. The setup is quite simple but contains everything needed:

The app supports multiple OpenID Connect providers in parallel, so the first thing we do is to chose a “Identifier” which will be shown on the login page to let the user chose the right provider. For the other fields we enter the “Client ID”, “Client secret” and “Discovery endpoint” from Keycloak. After accepting the setting by clicking on “Register” we are done. Now let’s try to login with OpenID Connect:

As you can see, we have now an additional button called “Login with Keycloak”. Once clicked we get re-directed to Keycloak:

After we successfully logged-in to Keycloak we get directly re-directed back to Nextcloud and are logged-in. A look into our personal settings shows us that all our account detail like the full name and the email address where added correctly to our Nextcloud account:

Real-time communication and collaboration in a file sync & share environment - A introduction to Nextcloud Talk

Björn Schießle (bjoern@schiessle.org) — Sat, 07 Mar 2020 08:00:00 +0200

At the beginning of this year I gave two times a presentation about Nextcloud Talk. First at the annual CS3 conference in Copenhagen and just one week later at FOSDEM in Brussels. Nextcloud Talk provides a full featured real-time communication platform. Completely Free Software, self-hosted and nicely integrated with all the other aspects of Nextcloud.

(This blog contain some presentation slides, you can see them here.)

CS3 Workshop 2018 - Global Scale and the future of Federated Cloud Sharing

Björn Schießle (bjoern@schiessle.org) — Thu, 01 Feb 2018 19:00:00 +0200

At this years CS3 Workshop in Krakow I presented the current state of Nextcloud’s Global Scale architecture. Probably the most interesting part of the talk was the current development in the area of Federated Cloud Sharing, a central component of Global Scale. Originally, Federated Cloud Sharing was developed by Frank Karlitschek and me in 2014 at ownCloud. These day it enables cloud solutions from ownCloud, Pydio and Nextcloud to exchange files.

As part of Global Scale we will add federated group sharing in the coming months. Further we want to enable apps to provide additional “federated share providers” in order to implement federated calendar sharing, federated contact sharing and more.

The next iteration of Federated Cloud Sharing will be based on the Open Cloud Mesh (OCM) specification. The Open Cloud Mesh initiative by GÉANT aims to turn our original idea of Federated Cloud Sharing into a vendor neutral standard. Something I explicitly support. In the process of implementing OCM we will propose some minor changes and additions to the existing specification to meet all our requirements. Directly after my talk I received a lot of positive feedback from different members of the Open Cloud Mesh initiative. I was especially happy to hear that PowerFolder already started to implement OCM as well and that our friends at Seafile also want to join us. I’m looking forward to work together with the OCM-Community in the following weeks and months in order to make our changes part of the official specification.

I will write a more detailed article once we have a first prototype of our implementation. For now I want to share my presentation slides with you:

(This blog contain some presentation slides, you can see them here.)

Nextcloud Conference 2017: Free Software licenses in a Nutshell

Björn Schießle (bjoern@schiessle.org) — Mon, 25 Sep 2017 15:44:52 +0200

At this years Nextcloud conference I gave a lightening talk about Free Software licenses. Free Software developers often like to ignore the legal aspects of their project, still I think it is important to know at least some basics. The license you chose and other legal decisions you make are a important cornerstone to define the basic rules of the community around your code. Making good choices can enable a level playing field for a large, diverse and growing community.

Explaining this huge topic in just five minutes was a tough challenge. The goal was to explain why we are doing things the way we are doing it. For example why we introduced the Developer Certificate of Origin, a tool to create legal certainty, used by many large Free Software initiatives such as Linux, Docker or Eclipse these days. Further the goal was to transfer some knowledge about license compatibility and give some useful pointers for app developers how to decide whether a third party license is compatible or not. If the five minute lightening talk was to fast (and yes, I talked quite fast to match the time limit) or if you couldn’t attend, here are the slides to reread it:

(This blog contain some presentation slides, you can see them here.)

The most sincere form of flattery

Björn Schießle (bjoern@schiessle.org) — Tue, 14 Feb 2017 10:51:31 +0000

Nextcloud now exists for almost exactly 8 months. During this time we put a lot of efforts in polishing existing features and developing new functionality which is crucial to the success of our users and customers.

As promised, everything we do is Free Software (also called Open Source), licensed under the terms of the GNU APGLv3. This gives our users and customers the most possible flexibility and independence. The ability to use, study, share and improve the software also allows to integrate our software in other cloud solutions as long as you respect the license and we are happy to see that people make use of this rights actively.

Code appearing in other app stores

We are proud to see that the quality of our software is not only acknowledged by our own users but also by users of other cloud solutions. Recently more and more of our applications show up at the ownCloud App Store. For example the community driven News app or the Server Info app, developed by the Nextcloud GmbH. Additionally we have heard that our SAML authentication application is widely considered far better quality than other, even proprietary alternatives, and used by customers of our competitors in especially the educational market. All this is completely fine as long as the combination of both, our application and the rest of the server, is licensed under the terms of the GNU AGPLv3.

Not suitable for mixing with enterprise versions

While we can’t actively work on keeping our applications compatible with other cloud solutions, we welcome every 3rd party efforts on it. The only draw-back, most of the other cloud solutions out there make a distinction between home users and enterprises on a license level. While home users get the software under a Free Software license, compatible with the license of our applications, Enterprise customers don’t get the same freedom and independence and are therefore not compatible with the license we have chosen. This means that all the users who uses propriety cloud solutions (often hidden by the term “Enterprise version”) are not able to legally use our applications. We feel sorry for them, but of course a solution exists – get support from the people who wrote your software rather than a different company. In general, we would recommend buying support for real Free Software and not just Open Source marketing.

Of course we don’t want to sue people for copyright violation. But Frank choose the AGPL license 7 years ago on purpose and we want to make sure that the users of our software understand the license and it’s implications. In a nutshell, the GNU AGPLv3 gives you the right to do with the software whatever your want and most important all the entrepreneurial freedom and independence your business needs, as long as the combined work is again licensed under the GNU AGPLv3. By combining GNU AGPLv3 applications with a proprietary server, you violate this rule and thus the terms of the license. I hope that other cloud solutions are aware of this problem, created by their open-core business model, and take some extra steps to protect their customers from violating the license of other companies and individual contributors. For example by performing a license check before a application gets enabled.

Open Core is a bad model for software development

This is one of many problems arising from the usage of open core business models. It puts users on risk if they combine the proprietary part with Free Software, more about it can be read here. That’s why we recommend all enterprise and home users to avoid a situation where proprietary and free licensed software is combined. This is a legal minefield. We at Nextcloud decided to take a clear stance on it. Everything is Free Software and there is only one version of the software for both home users and enterprises. Thus allows every home user, customer or partner to use all applications available as long as they respect the license.

Cloud Federation – Getting Social

Björn Schießle (bjoern@schiessle.org) — Tue, 13 Dec 2016 10:45:48 +0000

With Nextcloud 11 we continue to work on one of our hot topics: Cloud Federation. This time we focus on the social aspects. We want to make it as easy as possible for people to share their contact information. This enabled users to find each other and to start sharing. Therefore we extended the user profile in the personal settings. As the screenshot at the top shows, users can now add a wide range of information to their personal settings and define the visibility for each of them by clicking on the small icon next to it.

Privacy first

We take your privacy serious. That’s why we provide fine grained options to define the visibility of each personal setting. By default all new settings will be private and all settings which already exists before will have the same visibility as on Nextcloud 10 and earlier. This means that the users full name and avatar will only be visible to users on the same Nextcloud server, e.g. through the share dialog. If enabled by the administrator, this values, together with the users email address, will be synced with trusted servers to allow users from trusted servers to share with each other seamlessly.

As shown at the screenshot at the right we provide three levels of visibility: “Private”, “Contacts” and “Public”. Private settings will be only visible to you, even users on the same server will not have access to it. The only exceptions are the avatar and the full name because this are central data used at Nextcloud for activities, internal shares, etc. Settings which are set to “Contacts” will be shared with users on the same server and trusted servers, defined by the administrator of the Nextcloud server. Public data will be synced to a global and public address book.

Introducing the global address book

The best real world equivalent to the global address book is a telephone directory. For a new phone number people can chose to publish their phone number together with their name and address to a public telephone directory to enable other people to find them. The global address book follows the same pattern. By default nothing gets published to the global address book. Only if the user sets at least one value in their personal settings to “Public”. In this case all the public data will be synced to the global address book together with the users Federated Cloud ID. Users can remove their data at any time again by simply setting their personal data back to “Contacts” or “Private”.

In order to use the global address book as a source to find new people, this lookup needs to be enabled explicitly in the “Federated Cloud Sharing” settings by the administrator. For privacy reasons this is disabled by default. If enabled the share dialog of Nextcloud will query the global address book every time a user wants to share a file or folder, and suggest people found in the global address book. In the future there might be a dedicated button to access the global address book, both for performance reasons and to make the feature more discoverable.

Future work

The global address book can return many results for a given name. How do we know that we share with the right person? Therefore we want to add the possibility to verify the users email address, website and Twitter handle in Nextcloud 12. As soon as this feature is implemented the global address book will only return users where at least one personal setting is verified and also visualize the verified data so that the user can use this information to pick the right person.

Further, I want to extend the meaning of “Contacts” in one of the next versions. The idea is that “Contacts” should not be limited to trusted servers but include the users personal contacts. For example the data set to “Contacts” could be shared with every person to which the user already established at least one federated share successfully, or to all contacts with a Federated Cloud ID in the users personal address book. This way we will move slowly in the direction of some kind of decentralized and federated social network based on the users address book. This will also enable users to easily push their new phone number or other personal data to all their friends and colleagues, things for which most people use centralized and proprietary services like so called “business networks” these days.

Another interesting possibility, made possible by the global address book is to move complete user accounts from one server to another. Given that the user published at least some basic information on the global address book, they could use it to announce their move to another server. Other Nextcloud servers could find this information and make sure that existing federated shares continue to work.

Keynote at Open16 - Restore the Internet

Björn Schießle (bjoern@schiessle.org) — Thu, 29 Sep 2016 08:02:32 +0000

This year I was invented to the Open16 in Mechelen (Belgium) to give a keynote. It was a really nice event with many interesting presentation and talks.

I was asked by the organizer to started the keynote with the history of Nextcloud. Why did we started Nextcloud and what do we want to do different. Then I moved on with the main topic: “Restore the Internet - free, decentralized, open”. Why it is important and what we are doing at Nextcloud to make it happen. This are the slides to my talk:

(This blog contain some presentation slides, you can see them here.)

Transfer Public Links to Federated Shares

Björn Schießle (bjoern@schiessle.org) — Thu, 21 Jul 2016 09:56:48 +0000

Creating public links and sending them to your friends is a widely used feature of Nextcloud. If the recipient of a public link also has a Nextcloud or ownCloud account he can use the “Add to your Nextcloud” button to mount the content over WebDAV to his server. On a technical level all mounted public links use the same token, the one of the public link, to reference the shared file. This means that as soon as the owner removes the public link all mounts will disappear as well. Additionally, the permissions for public links are limited compared to normal shares, public links can only be shared read-only or read-write. This was the first generation of federated sharing which we introduced back in 2014.

A year later we introduced the possibility to create federated shares directly from the share dialog. This way the owner can control all federated shares individually and use the same permission set as for internal shares. Both from a user perspective and from a technical point of view this lead to two different ways to create and to handle federated shares. With Nextcloud 10 we finally bring them together.

Improvements for the owner

Public link converted to a federated share for bjoern@myNextcloud.net

From Nextcloud 10 on every mounted link share will be converted to a federated share, as long as the recipient also runs Nextcloud 10 or newer. This means that the owner of the file will see all the users who mounted his public link. He can remove the share for individual users or adjust the permissions. For each share the whole set of permissions can be used like “edit”, “re-share” and in case of folder additionally “create” and “delete”. If the owner removes the original public link or if it expires all federated shares, created by the public link will still continue to work. For older installations of Nextcloud and for all ownCloud versions the server will fall-back to the old behavior.

Improvements for the user who mounts a public link

After opening a public link the user can convert it to a federated share by adding his Federated Cloud ID or his Nextcloud URL

Users who receive a public link and want to mount it to their own Nextcloud have two options. They can use this feature as before and enter the URL to their Nextcloud to the “Add to your Nextcloud” field. In this case they will be re-directed to their Nextcloud, have to login and confirm the mount request. The owners Nextcloud will then send the user a federated share which he has to accept. It can happen that the user needs to refresh his browser window to see the notification.

Additionally there is a new and faster way to add a public link to your Nextcloud. Instead of entering the URL to the “Add to your Nextcloud” field you can directly enter your federated cloud ID. This way the owners Nextcloud will send the federated share directly to you and redirect you to your server. You will see a notification about the new incoming share and can accept it. Now the user also benefit from the new possibilities of the owner. The owner can give him more fine grained permissions and from the users point of view even more important, he will not lose his mount if the public link gets removed or expires.

Nextcloud 10 introduces another improvement in the federation area: If you re-share a federated share to a third server, a direct connection between the first and the third server will be created now so that the owner of the files can see and control the share. This also improves performance and the potential error rate significantly, avoiding having to go through multiple servers in between.

History and Future of Cloud Federation

Björn Schießle (bjoern@schiessle.org) — Mon, 04 Jul 2016 11:22:33 +0000

I’m now working for about two years on something called Federated Cloud Sharing. It started on June, 23er 2014 with the release of ownCloud 7.0. Back then it was simply called “Server to Server sharing”. During all this years I never wrote about the broader ideas behind this technology, why we do it, what we achieved and where we are going.

Motivation

The Internet started as a decentralized network, meant to be resilient to disruptions, both due to accidents or malicious activity. This was one of the key factors which made the Internet successful. From the World Wide Web, over IRC, news groups, e-mail to XMPP. Everything was designed as decentralized networks, which is why if you are on the Google servers you can email people at Yahoo. Everybody can set up his own web server, e-mail or chat server and communicate with everyone else. Individuals up to large organisations could easily join the network, participate and build business without barriers. People could experiment with new innovative ideas and nobody had the power to stop them or to slow them down. This was only possible because all underlying technology and protocols were build on both Open Standards and Free Software.

This changed dramatically over the last ten years. Open and inclusive networks were replaced by large centralized services operated by large companies. In order to present yourself or your business in the public it was no longer enough to have your own website, you had to have a page on one or two key platforms. For communication it was no longer enough to have a e-mail address, or be on one of the many IRC or XMPP servers. Instead people expected that you have a account on one of the major communication platforms. This created huge centralized networks, with many problems for privacy, security and self-determination. To talk to everybody, you have to have an account on Facebook, at Google, Skype, Whatsapp, Signal and so on. The centralization also made it quite easy to censor people or manipulate their view by determining the content presented to them. The algorithms behind the Facebook news feed or the “what you missed” in Twitter are very clever — or so we assume, as we don’t know how they work or determine what is important.

The last few years many initiatives started to solve this problem in various ways, for example by developing distributed social networks. I work in the area of liberating people who share and sync all sort of data. We saw the rise of successfully projects such as ownCloud, Pydio and now of course Nextcloud. They all have in common that they built Free Software platforms based to a large extend on Open Standards to allow people to host, edit and share their data without giving up control and privacy. This was a huge step in creating more competition and restoring decentralized structures. But it also had one big drawback. It created many small islands. You could only collaborate with people on the same server, but not with others who run their own server. This leads us to the concept of federated cloud sharing.

The first version of this ideas was implemented in ownCloud 7.0 as “Server to Server Sharing”. ownCloud already knew the concept of sharing anonymous links with people outside of the server. And, as ownCloud offered both a WebDAV interface and could mount external WebDAV shares, it was possible to manually hook a ownCloud into another ownCloud server. Therefore the first obvious step was to add a “Add to your ownCloud” button to this link shares, allowing people to connect such public links with their cloud by mounting it as a external WebDAV resource.

Server to server sharing already helped a lot to establish some bridges between many small islands created by the ability to self-host your cloud solution. But it was still not the kind of integration people where used to from the large centralized services and it only worked for ownCloud, not across various open source file sync and share solutions.

The next iteration of this concept introduced what we called a “federated cloud ID”, which looks similar to a e-mail address and, like email, refers to a user on a specific server. This ID could then be used in the normal share dialog to share files with people on a different server!

The way servers communicate with each other in order to share a file with a user on a different server was publicly documented with the goal to create a standardized protocol. To further the protocol and to invite others to implement it we started the Open Cloud Mesh project together with GÉANT, an European research collaboration initiative. Today the protocol is already implemented by ownCloud, Pydio and now Nextcloud. This enables people to seamlessly share and collaborate, no matter if everyone is on the same server or if people run their own cloud server based on one of the three supporting servers.

Trusted Servers

In order to make it easier to find people on other servers we introduced the concept of “trusted servers” as one of our last steps. This allows administrator to define other servers they trust. If two servers trust each other they will sync their user lists. This way the share dialogue can auto-complete not only local users but also users on other trusted servers. The administrator can decide to define the lists of trusted servers manually or allow the server to auto add every other server to which at least one federated share was successfully created. This way it is possible to let your cloud server learn about more and more other servers over time, connect with them and increase the network of trusted servers.

Of course there are still many areas to improve. For example the way you can discover users on different server to share with them, for which we’re working on a global, shared address book solution. Another point is that at the moment this is limited to sharing files. A logical next step would be to extend this to many other areas like address books, calendars and to real-time text, voice and video communication and we are, of course, planning for that. I will write about this in greater detail in on of my next blogs but if you’re interested in getting involved, you are invited to check out what we’re up to on GitHub and of course, you can contact me any time.

Freedom for whom?

Björn Schießle (bjoern@schiessle.org) — Wed, 15 Jun 2016 20:34:22 +0000

This discussion is really old. Since the first days of the Free Software movement people like to debate to whom the freedom in Free Software is directed? The users? The code? The developers? Often this goes along with a discussion about copyleft vs non-protecting Free Software licenses like the BSD- and the MIT-License. I don’t want to repeat this discussion but look at the question from a complete different angle. I want to look at it from the position of a software company and its business model.

If you talk to Free Software companies you realize, that very few have a business model completely based on Free Software. Most companies add proprietary extensions on top and use this as the main incentive for customers to buy their software. In 2008 Andrew Lampitt coined the term open core to describe this kind of business models. There are many ways to argue in favor of open core. One argument I hear quite often is that the proprietary parts are only useful for large enterprises, so nothing is taken away from the community. This way the community gets reduced to the typical home user, which is a interesting way of looking at it. Why should we make such a distinction? And why does home users deserve software freedom more then large organizations?

I understand that freedom in the context of software is a concept which can sound scary to some companies at the beginning. After all, that was the main reason why Open Source was invented, a marketing campaign for Free Software to make business people feel more comfortable. Interestingly this changes quickly if you go into more details about what software freedom really means. More entrepreneurial freedom, control over the tools they use, software freedom as a precondition for privacy and security, independence, freedom to chose the supplier with the best offering and in case of software development the freedom to build on existing, well established technology instead of building everything from scratch. These are freedoms well understood and appreciated by entrepreneurs and they demand it in many other areas of their daily business. This lead me to the conclusion that software freedom is not only something for home users but it also important for large organizations.

Open core often comes with a important side-effects. Most companies pick a strong copyleft license like the GNU GPL or the GNU AGPL, and then demand that every contributor signs a Contributor License Agreement (CLA). This CLA puts the company in a strong position. They are the only one who can distribute the software under a proprietary license and add proprietary extensions. This effectively removes one of the biggest strengths of copyleft licenses. If you set CLAs aside, copyleft licenses are a great tool to create an ecosystem of equal participants. Equality is really important to make individuals and organizations feel confident that joining the initiative is worthwhile in the long term. Everybody having the same rights and the same duties is the only way to develop a strong ecosystem with many participants. Therefore it is no wonder that projects using CLAs often get slowed down and have a less diverse community.

RedHat was one of the first company which understood that all this, CLA’s and proprietary extensions, do more harm than good. It slows down the development. It keeps your community smaller as necessary and it adds the burden to develop all the proprietary extensions by your own instead of leveraging the power of a large community which can consists of employees, hobbyists, partners and customers. This goes so far that RedHat even embrace competitors like CentOS, which basically gives RedHat Enterprise Linux away for free to people who don’t need the support. For a truly open organization this is not a problem but a great opportunity to spread the software and to become more popular. That’s a key factor to make sure, that RedHat is the de facto standard if it comes to enterprise GNU/Linux distributions.

If a initiative is driven by a strong company it can be useful to move some parts out to a neutral entity. RedHat did this by founding the Fedora project. Another way to do this is by creating a foundation which makes sure that everyone has the same rights. Such a foundation should hold all rights necessary to make sure the project can continue no matter what happens to individual participants, including companies. For the governance of such a foundation it is important that it is not controlled by a single entity.

This is exactly what makes me feel so excited about what we are doing at Nextcloud. We are building a complete free cloud solutions, not only for home users but for everyone. This solution will be much more than just file sync and share, from a company point of view stuff like calendar, contacts and video conferencing will become a first class citizen. All this will be Free Software, developed together with a great community. Home users, customers and partners are invited to be part of it, not just as a consumer but as part of a large and diverse community. Everybody should be empowered to change things to the better. In order to make all this independent from a single company we will set up a foundation. As described above the foundation will make sure that we have a intact and growing ecosystem with no single point of failure. This guarantees that Nextcloud can survive us and any other participant if needed.

Nextcloud on Björn Schießle - I came for the code but stayed for the freedom

Nextcloud and OpenID-Connect

Get a OpenID Connect provider

Nextcloud setup

Nextcloud and OpenID-Connect

Get a OpenID Connect provider

Nextcloud setup

Real-time communication and collaboration in a file sync & share environment - A introduction to Nextcloud Talk

CS3 Workshop 2018 - Global Scale and the future of Federated Cloud Sharing

Nextcloud Conference 2017: Free Software licenses in a Nutshell

The most sincere form of flattery

Code appearing in other app stores

Not suitable for mixing with enterprise versions

Open Core is a bad model for software development

Cloud Federation – Getting Social

Privacy first

Introducing the global address book

Future work

Keynote at Open16 - Restore the Internet

Transfer Public Links to Federated Shares

Improvements for the owner

Improvements for the user who mounts a public link

History and Future of Cloud Federation

Motivation

Server to Server Sharing

Federated Cloud Sharing

Trusted Servers

Open Challenges: where we’re taking Federated Cloud Sharing

Freedom for whom?