Open Source, what does that really mean? No, really-really?

Date: April 14, 2025

Reading time:
41m.

Categories:
business
legal
software

The Gist

Chalk board with buzz words on open-source.

The term ‘Open Source’ is all but a household term these days. It certainly has come a long way from its humble beginnings as a dream for a better world.

Some products or projects taut it as their defining characteristic (Linux, Firefox), while others keep it out of sight as a secret ingredient (Sony PlayStation, Apple…i…Everything).

But, what does it mean though? And perhaps most importantly, what does it mean for you, your uncle, his cousin, and their neighbours business? Well, as more and more organisations have gotten in on it, its meaning has become somewhat…muddled.

No matter, we’re going to unravel it in this guide.

FOSS and OSS

No, we’re not pulling your personal transport device, FOSS and OSS are real abbreviations. While at first glance their meaning seems rather similar, there are a few important differences that we have to discuss.

FOSS

FOSS is the common abbreviation for ‘Free and Open Source Software’. ‘Free’ in this instance refers to Freedom, or Liberty. It does not mean free as in gratis, no charge, on the house. In other words it does not refer to price. A great deal of FOSS licensed software is however also free of charge, but not all of it.

A good example of this is the Linux kernel, which is licensed under a FOSS licence. It is for the most part also available free of charge from various websites. There are also versions of the Linux kernel available that while still under a FOSS licence, require a paid subscription to obtain.

OSS

OSS (‘Open Source Software’) is an abbreviation that is also commonly used in the IT industry. The notable difference here is the absence of ‘Free’ (Liberty). Both ‘FOSS’ and ‘OSS’ refer to software that allows users to obtain a copy of the (human readable) code of that software. Both also allow users to study, change and distribute changes to that code.

The key difference being that FOSS licensed software requires the changed code to be released under the same licence. This means that while the code may be changed, the rights, privileges, and obligations related to that code may not.

Software released under an OSS licence on the other hand, does not have such requirements. As with FOSS, it is allowed to make changes to OSS licensed software. Keeping the same licence however, is not required. Someone could download OSS licensed software, make changes and then sell the changed software as closed source, proprietary software, if they so desired.

In short, unlike FOSS licences, OSS licences do not guarantee the same Freedom to access the software’s code in perpetuity.

Why make this distinction?

Because that is what some believed would be a requirement to entice businesses to adopt the open source concept in their business activities. Many businesses were not, and still are not, all that keen on having to release the code to any changes they make.

Not necessarily because they wish to resell other people’s work. Sure, this has happened on occasion. But for many businesses that is not the issue. More commonly, it is a complicated mix of legal compliance, and risk adversity in potentially having to publish internal company secrets.

The disagreement between the premier authorities on FOSS licences (the Free Software Foundation) and the OSS licences (the Open Source Initiative) is quite strong. So strong in fact that we might go so far to say…they might not actually like one another very much. Harsh words, we know. But we suspect it to be true.

So, what does that mean for me?

Well, as it turns out, quite a few things, actually. You might want to run an open-source application of some kind at home, or you might want to run it on a server for friends and family to access. You may even wish to develop some software of your own, but find yourself without a trust fund and an army of lawyers to safeguard your work.

But if you run, or plan to run, an organisation of some sort, things get especially fickle. Why say organisation? Well, because we mean ‘< insert your organisation here >’. Whether it’s a business, a non-profit, a local chapter of your favourite fan club, or the first steps in your plan for global domination, IT is going to be a part of it one way or the other.

There are great cost savings to be had, substantial environmental impact reductions to be made, as well as mind-blowing advancements to be achieved. But as you’ll also see in this guide, the implications that different licences may have for your organisation can be quite confusing.

Fret not, we shall attempt to lubricate this dry substance dear reader. We’ll need to clarify the whole licensing gibberywhatsit in a bit more detail though. We know, we know, you must be riveting with exhilaration, at the thought of closing this guide, and wondering what on earth possessed you to click on it in the first place. But bear with us, it’s worth the trudging.

Still here? Spiffing. Then let’s get started.

FOSS Licences

The defining characteristic of a FOSS licence is a unique concept called ‘Copyleft’. If we were to pretend Copyright and Copyleft were people, with one being the evil twin of the other, they might say:

Copyright: ‘we own it, don’t touch it…or else!’

Copyleft: ‘it is a shared work, created in the spirit of liberty and equality! Don’t you dare refrain from giving back, or worse, attempt to lock anyone out in any shape, way, or form…or else!’’

Indeed, as we briefly touched upon earlier, FOSS licences require changes to be shared under the same licence. In effect, ensuring that future versions of the code cannot become inaccessible all of a sudden, for whatever reason. Turns out this idea had a name all along. Copyleft. What will they think of next? Copyup, Copydown…? Perhaps CopyCentre, but that name might already be taken by the copy shop down the road.

In all seriousness however, the concept of Copyleft has proven to be a game-changer in the realm of licensing, and we owe its creators some genuine thanks. Without it, the state of software development would have turned out quite differently. Not to mention, the rate of technological progress. More on that later though, so let’s crack on.

Terminology

What makes Copyleft a little trickier to understand, is that it comes in two distinct varieties: weak and strong. In order to explain the difference we’re going to have to delve into a few important terms. As you’ll see in due course, they pop up all over the shop, whether you like them or not.

Modification:

In the context of this guide, this refers to the modification of human-readable source code. Editing a single character in a source file, will trigger the modification clause of the licence that the software is under. Seems straightforward enough, but we’re required to be thorough. Never can tell with all this legalese and legal-fu…

Linking:

The best way to explain this is by briefly touching on the way programming languages are structured. They will usually have at least two components, a mechanism to run the code, and a library of pre-built functions to make programming in that language easier and more efficient.

Imagine having to explain what a circle is every time you wish to develop software that features a circle. Ghastly. That’s what libraries are for, to store frequently used functions and information. It makes thing less ghastly.

Linking means that software borrows functions or information from a library, but neither changes that library in any way, nor does it make the library a part of the software itself. The library instead becomes a requirement so that the software can run. This is usually, called a ‘dependency’.

Interaction:

Interaction means, well to interact with a piece of software. But in the context of licensing, it mostly refers to interactions over a network. This distinction will become very important a little later on. For now, it would be good to make the following distinction: when a person makes software available for download, they are in essence distributing that software. Thus they are required under a FOSS license to make both the source code and its licence available as well.

But what if someone is offering a service over a network, say a tool that generates puppy emoji on the internet? Well, technically they wouldn’t be distributing the software, but instead ‘allowing for network interaction’. Food for thought. More on that soon.

Now that we’ve gotten those fiddledyjibbits out of the way, we can have a brief look at the actual licences. Don’t worry, we wouldn’t dream of slapping you in the business card with the actual licences. We’ll be limiting ourselves to the minimal amount of key points, takeaways and whatnots.

Disclaimer: this is neither the exlusive, nor definitive meaning of fiddledyjibbit. We reserve the right to insert it anywhere we get confused, er, mean to. Lovely word. We like it and have great plans for its future.

Addendum to Disclaimer: same thing goes for gibberywhatsit

The GPL

The ‘GNU General Public License’ or GPL is the original copyleft licence and the premier example of a ‘strong’ copyleft licence. Later on it became the foundation for an even ‘stronger’ copyleft licence. ‘Stronger’ isn’t a definition that anyone actually uses however, just ‘strong’ and ‘weak’.

What makes it a ‘strong’ copyleft licence is that either modifying or linking (or both), will trigger the provisions of the GPL licence. In other words, making any modifications, or building on the code by either taking the code and using it elsewhere, or linking against it (see? Told you we’d need that term) will require the resulting work to follow the provisions of the GPL. Which means providing the new source code along with a copy of the licence.

This is how copyleft works. Touch it in any of the ways mentioned above, and you will not have seized the opportunity to make a new proprietary product. You will instead have added to the total amount of FOSS software. Some people have thus taken to calling copyleft ‘viral’ (especially strong copyleft), and defined its functioning as ‘virality’. Doesn’t sound very nice that way does it? How about healthy-reproductive? No, people likely wouldn’t like the sound of that either…

In any case, all of that only really applies to software developers though. For regular users, we are happy to say dear reader, that you may dilly-dally with any GPL licensed software to your hearts content, both privately and professionally, in business and in health, till neither of you feel that way any more. Just remember that any modifications need to be published as well.

Most software included with operating systems under a FOSS licence, is generally licensed under the GPL. The list truly is far too long to mention them all. It’s safe to say however that any operating system based on the Linux kernel has the majority of its software licensed under the GPL. From the kernel itself, to the desktop and many of its tools and applications. Blender, a popular 3D modelling application is licensed under the GPL for instance, and so is popular Adobe Photoshop alternative GIMP.

The LGPL

The ‘GNU Lesser General Public License’ by contrast is the premier example of a ‘weak’ copyleft licence. It retains most of the GPL rules and regulations, but has one clear distinction: it allows other software to link to (there’s that word again, see?) an LGPL licensed work, without copyleft taking effect.

The long and short of it is that if you make modifications to an LGPL licensed work, you’ll be obliged to publish those in a similar way to the GPL. But developing software that only links to an LGPL licensed work, has no such requirement. Unless you want to of course, they don’t mind that at all.

The LGPL is for this reason a very popular choice for software libraries. A more concise example here would be the implications of having a fully GPL licensed programming language vs an LGPL licensed programming language.

If the programming language, not one in particular, let’s call it Bertie for now, was fully licensed under the GPL, it would only be possible to use it for the creation of other GPL licensed software. If Bertie was LGPL licensed however, you could use it to develop software and release it under any licence you wanted. This is because of the whole ’linking’ gibberywhatsit.

This is of course all very much focused on software development, but it does illustrate a very important difference. Strong: copyleft all the way. Weak: copyleft, only if you make modifications.

In terms of philosophical beliefs, we might add one last point before we move on to the next licence. The LGPL can be viewed as the Free Software Foundation’s reluctant admission that a compromise might be necessary to gain corporate acceptance of the FOSS concept. It is quite clear that they don’t like it, as they strongly recommend software developers to license future software libraries under the GPL instead. We’ll discuss that sticky wicket in the takeaway section of the guide.

The AGPL

The ‘GNU Affero General Public License’, or AGPL. This licence is more complicated. Not so much in theory, as it is in practice. We can explain it fairly easily in terms of what it brings to the table. Applying that knowledge in the real world is a different story.

The gist of it is this: In addition to all the provisions of the GPL, the AGPL adds our third keyword as a high priority item. ‘Interaction’ or more specifically, ‘Interaction over a Network’. The AGPL embodies a sincere attempt by the FSF (Free Software Foundation) to address an issue that the regular GPL didn’t quite take into account. This is because networked services, such as cloud computing, weren’t all that prevalent back when the notion of copyleft was first conceived.

If someone modifies a GPL licensed work and makes that work available as an online (or otherwise networked) service, then this usually does not mean distribution of the modified work. People instead make the functionality of that software available, they don’t allow people to download the software itself. This means that people could, under the GPL, get away with making modifications to FOSS without following up on the rules and regulations of the GPL.

This is what the AGPL seeks to address: if a modified work is accessible over the network, then interactions with it no longer count as ‘private use’, thus it becomes subject to the same rules as the GPL. Modify, link, or interact over a network connection, and you must provide the modified source code and licence as well, but in this case under the AGPL instead of the GPL.

The thing is, dear reader, this one doesn’t have a sticky wicket. More like a bunch of them. We’ll get to that in the ‘real world’ section of this guide. So let’s move on to the permissive licenses.

Permissive Licences (OSS)

That sounds nice, doesn’t it? Permissive. Makes things sound so…care-free. So what does ‘permissive’ mean then? Broadly speaking it means that you may use the product and its source code in any way you see fit, provided you mention its creators, and the licence they put it under.

That also means you are free to build on the code or even the whole product. You’re essentially allowed to release a new product, under a different licence. Even a proprietary, closed source licence. As long as you mention the original authors and the original licence, you’re all set.

One immediate takeaway from a philosophical perspective is this: permissive licences are without any type of copyleft. The goal with these licences must then be different. Indeed, they don’t focus as much on building a world without closed source, proprietary software. Permissive licences tend to focus more on collaboration, adoption and simplicity.

Great, that clears that up. Or does it? Well, no, we do have a tad more to discuss here as well. It’ll be more fun though, promise. Yes, we see that saying fun and licence in the space of a few sentences may seem insincere…but we’ll make it work. Promise.

Apache, MIT, BSD

The three musketeers of OSS: Apache, MIT and BSD. We won’t need to spend too long on these as they are all very, very permissive. Use the code, use the product, do what thou will, provided a few provisos are observed. There are always provisos aren’t there. Well yes, this is a guide about Legalese, or Legal-Fu. They’re pretty straightforward and user friendly in the case of the three musketeers though.

The main thing these licences focus on are the following:

protecting the authors of the work from any legal action, class or otherwise
protecting the good name of the authors from association with you and potentially nefarious scheming
protecting the message of the authors by forcing you to include it in the licence

More specifically:

Apache: I declare this work free to use, and free to build upon. Keep this license, along with any included notices, with the work at all times. If you make any changes, provide them on a neat, dry-cleaned, starched and ironed list along with the licence. Don’t worry, no need to include the new or changed code, just mention the changes. We also declare that any user is granted a licence to use, offer, sell, import or otherwise transfer the work, regardless of any patents that might be connected to this work. There’s a good user, sign here. Oh and don’t mention anywhere that you’re our friend. We have a reputation to uphold you know.

MIT: Just give us a shout-out. It’s all good. Don’t forget the shout-out, we do care about that. Aside from that, do as you please.

BSD: Got you! There’s not one BSD licence. There’s four of us!

0-Clause: Nothing to see here people, move along.
2-Clause: Keep the copyright and disclaimer with the code, even if it’s an executable binary.
3-Clause: Everything from the 2-clause. Don’t mention or suggest that we know each other. Or hung out. We mean it. Don’t. We likely don’t have the Legal-Fu to come at you, then again we might. But at the very least: we won’t like you.
4-Clause: Everything from the 2-clause licence, but mention our contribution to your stuff. Yes, on marketing as well. What…did you think this was a charity? We don’t want to get sued, but we want our due credit! Don’t suggest we know each other though. We’re your benefactor in code, not reputation.

So that’s it then? No, not quite, just a few more to go… We wouldn’t want to be considered less than thorough, or license-ist.

Okay, we are license-ist, but only to the really sneaky ones. Aside from that we are open and welcoming to licences of all races, creeds, genders, species (both biological and non-biological) along with any preferences they might have. As long as they aren’t sneaky. Or bullies. We don’t like those either. Especially sneaky-bullies. They’re the worst.

On a brighter note: the next licences could not be more opposite to any form of nastiness.

Public Domain

Another category of licences worth mentioning are the ‘public domain’ licences. These represent an effort by software developers (and creators of other creative works), to release their products out into the wild. No strings attached. To let them run free into the great beyond, to let them evolve, and possibly raise families of other little creative works.

One of the more…shall we say…direct attempts at bringing this point across is the aptly named ‘Do What the Bleep You Want To Public License’, or WTFPL. Currently at version 2 we believe. Indeed, it does not say bleep on the actual licence. Look, we want to keep the option open to be a family friendly magazine okay? If we haven’t botched that option already.

Other examples include the Unlicense and the CC0. These and others are all different attempts to convey the same message: ‘Do What the Bleep You Want To!’ possibly, with a spot of ‘Look, weren’t you bleepin’ listening? We thought we were being pretty bleepin’ specific with this. Now leave us the bleep alone. We mean it. Bleep off.’’ Well…can’t argue with that logic, can we dear reader? Best move on then.

Without spending too much time on this category, we want to mention that they exist to essentially remove all ambiguity surrounding works under these licences. Various noble pondering wise people recognised the need for these licences, as laws are not the same the world over, and some countries might not recognise the ‘public domain’ concept. By licensing works under one of these licences, any and all doubt is (reasonably) removed.

There are quite a few works released under one of these licences, including but not limited to software, articles, and images. One of the most notable examples might well be the SQLite database. It is the most widely deployed SQL database on the planet, no doubt thanks to the smartphone revolution. It doesn’t use one of the licences above directly, but instead features a lengthy…claimer…or…disclaimer…waiving any and all rights, rules, and provisions. Ironically they do offer an expensive enterprise licence in case a user is still in doubt, or lives in an area that doesn’t acknowledge the public domain concept. What a world we live in, eh?

We’re nearing the end now dear reader, much obliged to still see you here. There’s one licence left to discuss before we move on to the ‘real world’ section of this guide: The Mozilla Public License, or MPL. A so-called ‘middle ground’ licence.

The MPL

The ‘Mozilla Public License’ or MPL. Created by the lovely people that brought you the Mozilla Firefox web browser. The MPL is a variation of the weak copyleft category of licences. Then what is it doing in the permissive section we hear you ask? Good point, well made.

You see, the MPL has a clever little proviso that puts in the no-mans-land between the laissez-faire licensing (OSS) and guerilla licensing camps (FOSS). It features a provision that allows users to create new works, even closed source ones, by keeping the MPL licensed files separate from the new, potentially proprietary licensed ones. They call this addition ‘file-based copyleft’. It takes the ’linking’ part of the LGPL and extends it to an entire products worth of code.

They won’t let you use the trademarks, logos and related items from the original work however. That’s a no-no. That explains why there are so many variations of Firefox then right? Well, no, because they are all under open source licenses as well. Projects that demonstrate the concept a little better are the MPL licensed LibreOffice project, and the (formerly) MPL licensed Hachicorp Terraform project.

Both of these projects saw the merits of an MPL approach: Keep a clean, MPL licensed open source edition, and keep the option open to sell an ‘Enterprise’ edition later on by bundling in non-MPL licensed extensions later on.

In the case of Libre Office, this is ‘Collabora Office’, although whether or not that is created by the same developers is not clear. What is clear is that the MPL licensing is what makes the existence of Collabora Office possible. With Terraform, they just followed a common pattern: Community Edition, and Enterprise Edition.

Now that we’ve finally trudged through all this legalese we can finally get to the good stuff! What on earth (or other planets, or space, you know just in case) does all this mean in practice, and what does it mean for you dear reader? Well, let’s find out.

The Real World

Perhaps the easiest way to make any sense of all of this, is to have a look at how people and organisations actually apply all this licensing gibberywhatsit to the real world. Having a grand philosophical plan is one thing, but how does that take shape on the 3rd rock from the sun, with all its scheming on one side, and its idealism on the other?

Well, one thing that popped up very early on, no doubt much to the chagrin of the FSF, are the concepts of ‘open core’ and ‘dual-licensing’. The birth of ‘strategic licensing’. Okay, perhaps not the birth as proprietary licensing was always about strategic licensing, long before copyleft popped up. Let’s just say that FOSS and OSS licensing increased the size of the strategy map.

Open Core

Open Core is a strategy applied by many organisations, as a…mixed-bag of things. Marketing? Demoing? Involving community development, yet only on a limited set of features?

What it means in most cases is that a company will release a basic version under a FOSS license, without including any of the industry standard features required to use it in any meaningful way. What we mean by that in particular, is user management integration. IT infrastructures, both FOSS and proprietary alike are centred around user management, and automating user access to services and applications.

As most ‘open core’ software lacks user management integration, they are in fact little more than glorified demos. To use software in any real capacity (with user management integration) of course requires paying for the ‘Enterprise’ edition. These days, that usually means taking out a subscription that becomes very expensive, very fast.

Companies that apply the open core stratagem get to say that they are an ‘open source company’, that they ’love open source’ and more of that fluffy kind of speech. Whether or not that is true is highly debatable, and of course quite subjective.

Some companies may not even accept contributions to their open core, while others use it as a form of free labour. Some might actually be fairly open to the idea of people creating extended works. They do, of course, realise that only a large and well motivated community of software developers might actually be able to pull that off. Maintaining software is not easy, and it requires a significant ongoing investment in time and money. Some might argue that it is yet another variety of corporate strategy, while others might perceive it as a promise of sorts: ‘If we misbehave, you can reboot the project under a different name’. That last bit is called ‘forking’ in the industry.

A good, but somewhat opaque example of this is Mattermost. They release the core of their product as an AGPL licensed work. But at the same time they do two interesting things:

They release the binaries (ready to use version, aka ’executables’) under a permissive licence, in this case the MIT license. The code itself however is released under the AGPL.
They promise ’not to act’ on any of the AGPL provisions, meaning that they allow use beyond what the AGPL would normally allow. This is no doubt because of the missing features in the open core, ‘community’ edition.

So, what does that mean? Is Mattermost truly an open source company, or are they using clever tricks to get the love and attention that FOSS brings, without actually delivering on that promise?

The fact that Mattermost is missing even basic user management integration in its community edition, would make us lean towards ’no, not really’. But then they do make it possible in a convoluted way, by allowing users to integrate user management with an unrelated product called Gitlab. The latter’s community edition is of course, also hamstrung.

So which is it? Difficult to say, but for our proverbial 2 pence: We consider it more of a tactical marketing strategy, and less actual ‘openness’. For us to consider Mattermost open and consumer friendly, we would want to see user management integration (SSO) included in the open core release. As a possible compromise, they could limit genuine enterprise functionality such as large scale deployment and real-time customer support, to the enterprise edition.

As for our interpretation of ‘Open Core’ in general, in the spirit of FOSS, as prescribed by the FSF, Open Core cannot be considered compliant with the notion of Software Freedom. Absolutist? Perhaps. But that doesn’t necessarily make it wrong. More on that in the takeaway section. Ultimately however, it is up to you to decide what to make of Open Core dear reader.

Next on the agenda is ‘strategic (re-)licensing’, a hearty topic to fire a flame of indignation? A nitpickers buffet? A business strategist’s epitome of admirable case studies? Or just people making it up as they go along? We’ll see dear reader…but whatever the case, it will offer fuel for the ol’ thought-o-matic.

Strategic (Re-)Licensing

For those of us that’ve been watching the FOSS vs OSS vs Proprietary landscape for a while now, okay, a long while now, it’s a mishmash that combines sports, intrigue, sci-fi and drama. Inspirational for some, emotional for others, downright entertaining for yet other-others. So get yourself a fresh cup of Bovril, or Marmite for our vegetarian chums and prepare to be both jarred and inspired in equal measure. For our friends across the pond…popcorn perhaps?

Our first contender is the company Hashicorp, with its flagship product Terraform. It doesn’t really matter whether or not you are familiar with them. What matters is the case study they have presented us with.

Their Terraform product was originally released under the MPL. As we saw earlier, the MPL allows a company to release both an open source and a closed source version of a product, while offering trademark protections as well. All by design.

The product quickly amassed a considerable following in the IT industry, and as a result, quickly became a new standard for its intended purpose. The company then, without much further ado, changed their licensing to a ‘Source Available’ licence instead. Which is a roundabout way of saying, look but don’t touch, and any use of the actual product will require a subscription.

Their community, outraged, decided to take the most recent code still under the MPL licence, and start a new project, under a different name. They created a project ‘fork’, which establishes a shared ancestry for a project, but will henceforth take both projects in different directions.

Were it not for the power of open source, many users the world over would have found themselves with a very costly decision either way. Submit to enterprise pricing, or move to an alternative.

But what about Hashicorp? Did they have this in mind all along, or did they just change their minds somewhere along the way? Are they still an ‘Open Source’ company? It’s impossible to answer the first question with any certainty, but their aggression toward the forked community edition in recent months does somewhat answer the second.

This story does illustrate some of the insecurity that corporate backed open source projects may bring to the table. Our next tidbit shows a less obvious example, which raises a whole new category of questions.

Minio is a product released by a company of the same name, that engaged in a spot of relicensing as well. They went from the permissive Apache licence, to the far more complicated AGPL licence. By complicated we mean that it requires very careful analysis of specific use-cases, before an organisation can feel secure on its legal compliance.

Unlike Mattermost from our Open Core section, Minio does not hamstring its open source offering. It comes with all the bells and whistles an organisation would need to deploy the product successfully. The issue with Minio is instead its ambiguous language surrounding the use of its FOSS edition.

It clearly states that compliance with the AGPL in the case of Minio must include source code, full license text and original copyright notice, along with the object code. It adds: talk to a lawyer if you have any questions. So what does that mean? Using the FOSS version of Minio requires an organisation to release any and all source code that might have any bearing on their use of Minio? Including possibly the designs of the water fountain next to the server room?

We actually reached out to Minio on this, and they initially blocked our question with ‘ask a lawyer’. After a few more attempts, the best we got was ‘internal use is unlikely to trigger the AGPL, but consult a lawyer’. We choose to interpret that as: ‘Minio reserves the right to litigate on compliance with the AGPL to the fullest extent’.

So, either consult an expensive highly specialised lawyer, or get an enterprise subscription. The subscription Minio offers, at the time of writing, starts at $48,000 per year. Neither of these options would seem all that realistic for small organisations, let alone unfunded start-ups.

Is this Open Source, or in the spirit of FOSS? Well, yes and no. The fact that the product is both fully open source and licensed under a strong copyleft license do point in that direction. Their absolute refusal to specify anything at all regarding what may or may not trigger the provisions of the AGPL however, somewhat suggest ‘scare tactics’. The colourful addition of ‘usage without validation is at your own risk’ in their compliance readme, while suggesting an enterprise subscription at every opportunity, certainly don’t detract from that notion.

Under the Apache licence, compliance is not an issue, but Software Freedom is not guaranteed. Under the AGPL Software Freedom is guaranteed, but compliance becomes something that requires very careful consideration. Is this strategic re-licensing? We are inclined to say yes, but not necessarily for nefarious reasons. Overlooking the obvious ‘ominous’ tone in all communication surrounding legal compliance with Minio however, is something we cannot bring ourselves to do.

We for one feel that Minio did well by adopting a strong copyleft licence, we also agree that Minio has every right to look out for their own interests. If an organisation plans to build on Minio, or incorprate it in a product offering of some sort, then yes, they should work together with Minio and formulate a plan of sorts.

If an organisation, in particular a small one, is simply looking for a way to store their files internally or host their webshop, that is a different matter. For one, it shouldn’t have to be this unnerving or expensive to find answers.

We will try to answer some of these questions in the next section, for FOSS licensed works in general.

FOSS Licences in Practice

To make sure we’re all on the same page, we shall do a quick recap. In particular, on FOSS and OSS licensing and their implications in the real world. If you don’t know the difference between FOSS and OSS, well, then you skipped to this section without reading that bit didn’t you? Naughty, naughty. Now, scroll back up there and read that bit.

No, seriously, we mean it.

Still trying to read on anyway? Look, we mean it, scroll back up there and read the requisite material.

Go on. It’s okay, we can wait.

Sorry about that dear reader, can’t write a guide without a naughty scallywag turning up can we…

Where were we…Ah right. Licensing and real world implications. So, each licence, for the most part, allows us to use the software in any way we see fit. Should we make any changes however, then we will be required to publish those changes under the same licence in the case of a copyleft licensed work. In the case of a permissive licence, we do not, but if we decide to publish our changes or instead publish a ready-to-use version of our new software, then we do need to mention that we borrowed bit and bobs from other people. There is however one exception to this, and that is in regards to AGPL licensed software. The addition of ‘interaction over a network’ makes that one a little trickier to wrap our heads around.

Look, what the flippitybollywhats does ’network interaction’ actually imply anyway?

Good question, dear reader. We have wondered the same thing.

As we mentioned when we introduced the AGPL to you, and asked you to politely shake hands with it, the intention of the AGPL is to make GPL provisions more suitable for today’s world of cloud computing. The AGPL makes the distinction that allowing users to interact with a licensed work over a network, also triggers the obligation to publish any and all changes, no longer only when making the software available for download. Yes, we were just using download to try and be done with it. It also includes putting it on any other kind of media and enabling other people to get a hold of it.

This is where the confusion starts…what does interaction over a network mean, to which degree, and so on and so forth. As there haven’t been all that many court cases on the matter, it isn’t really possible to answer that question definitively.

What we can do however, is describe a number of scenarios that either will or (likely) will not trigger the copyleft obligations of the AGPL. Let’s start with the one we are most interested in, the scenario that is less likely to make us have to talk to lawyers, and pretend to be interested in their holiday experiences.

If we use an AGPL licensed work in its unaltered, original form, and we configure it as per the recommendations of its creators, for the purposes that the creators have specified, then we are less likely to trigger the obligations of the AGPL.

We shall illustrate this with the help of Minio.

Example 1: A standard installation of Minio on the internal network of an organisation, based on a standard configuration. Its intended purpose: storing and accessing files by company staff. Interaction with Minio is done in one of two ways:

Directly through industry-standard tools that work with any such file storage mechanism (S3 in this case). If Minio was replaced with an alternative solution, it would make no difference, there are no Minio-specific configurations or automations of any kind.
Indirectly, using industry-standard network storage tools (i.e. NFS, SFTP, DAV, or connecting to a Windows Network Share). Again, if Minio was replaced with an alternative solution, it would make no difference.

Example 2: A standard installation of Minio, under the same conditions as example 1, but with files hosted by Minio, that are accessible on the internet. The purpose is hosting static website files such as images, fonts, and perhaps files related to the website itself. Under the following conditions, it would again be less likely that the AGPL provisions come into play:

The files and the website itself could be hosted on any standard web server. Doing so in a ‘copy-paste’ way, would require no changes whatsoever. There is no specific integration with anything particular to Minio.
Any advanced features of the website, that require communication with a separate back-end, do not result in any instructions, automations, links or otherwise, that are specific to Minio in any way. If a standard web server was used instead of Minio, no changes would be required as there is nothing specific to Minio that comes into play.

Both of these examples portray Minio as:

An unmodified, standard installation with standard configuration.
Minio is used for its original purpose, to host files. Whatever other functionality Minio might offer is not used or accessed.
Minio is not being used for the purposes of ‘reselling’ either Minio itself, or any functionality it may offer. It is used as an infrastructure component for services that in and of themselves have nothing to do with the purpose of Minio (file storage).
Minio could, without modification of any tooling, scripts or related items be replaced by another product, such as a HTTP server.

Now for some examples, that almost certainly would trigger the obligations of the AGPL:

Making changes to the code of Minio
Offering Minio itself as a paid service to customers
Incorporating Minio as part of a paid service that serves the same function as Minio to customers (in this case file storage)
Writing software (including automation scripts) that specifically targets Minio APIs and functionality

Why such careful use of language? Because we don’t have much choice, dear reader. This is after all very much legal-fu. Neither can we offer any guarantees whatsoever, and no rights, warranties or anything of the sort can be derived from anything mentioned in this guide. We wish we could give any sort of binding advice, but we simply can’t.

For any kind of certainty, one would indeed need to consult legal counsel. But even that would not offer any complete guarantee until your specific use-case has been decided upon in the courts. Sad, but true. Hence, our earlier exploration of ‘strategic (re-)licensing’ and its implications.

If the risk is too great, then the only remaining choice is either to avoid (‘high risk’) AGPL licensed software, or to take out an enterprise subscription. In particular when it comes to software that exists at the ‘infrastructure’ level of your IT department. What we mean by that is the foundation upon which your applications may function, such as file storage, networking, user management and the like.

It is however ‘unlikely’ that a company such as Minio, or others in the same category of business, would litigate small, to medium sized organisations (or start-ups) that use their product in the same way as the ’less likely’ category of examples. Ultimately dear reader, it is for you to weigh the benefits and risks.

That’s all good and well, but what do you make of all this then?

Fair question, dear reader, fair question.

Well, there is a lot to unwrap here, no doubt about that. The gains that can be made in reducing expenses, reducing environmental impact, and reducing dependence on (specific) service providers are too great to ignore. All that, while increasing the functionality and flexibility of your organisation’s IT stack as well. Not just with Minio, but with FOSS solutions in general. A growing number of which are licensed under the AGPL.

We believe the intentions of the AGPL are noble, and companies releasing versions of their products that aren’t hamstrung under the AGPL, are to be applauded. We’d like to see some ‘kindness’ towards smaller organisations however, before we could applaud loudly.

If Minio for example, listed specific use-cases and promised to wave the threat of litigation, provided those use-cases were followed very closely (if not to the letter), that would make things a lot more inviting and substantially less unnerving. Until they do, we are inclined to say ‘strategic (re-)licensing’ does apply to them, and as such, it would perhaps be prudent to look for an alternative.

More on that in our final section, the takeaway. If you’re still here, reading this dear reader, you have our sincere appreciation and respect. We know it’s not easy sitting through all this gibberywhatsit.

The Takeaway

There’s no simple takeaway from all this to be honest, it’s a complex dish. It even has links. We might have to get serious for a bit, but we’ll turn that ship around before the barnacles start showing.

We’ll start by weaving it all together under the banner of Software Freedom, after which we’ll have a look at some ideas, before leaving you with resources for further reading.

More reading?!

Aye, but just a wee bit, and it’ll be worth it dear reader.

Software Freedom

The thing is, that without ‘Software Freedom’, we’d all be subject to the whims of corporations, without any real alternatives. It is more than likely that we wouldn’t have progressed this far with technology in the first place, as the proverbial wheel would have had to be invented by every corporation independently. It is because of Free and Open Source Software that things have progressed far more quickly, of that there can be no doubt.

We believe the copyleft side of things, has to be aggressive in its approach. There is wisdom in their way of doing things, even if they themselves don’t like it very much. To get things started, an uncompromising stance is an effective tool to provoke both thought and action. It will invariably be met with equally opposing forces of resistance (proprietary licensing) and moderation (permissive licensing). Between these forces, we are presented with choice. And in making our choices, the wheels of progress will always be churning.

Something, we believe, the copyleft-ers have always been well aware of.

Some years back, one of us talked to Mr Stallman of the Free Software Foundation by email, looking for approval of the FSF for a project. They were met with disappointment, as Mr Stallman was most resolute: ‘If a solution requires the inclusion of proprietary software, even a driver, then we say the thing cannot be done.’

A disappointing response, met with youthful confusion and strong emotion on our part. All those hundreds of hours of programming and testing, all for nothing. Until it dawned on us: ‘Mr Stallman’s role is that of unrelenting opposition, to waver would mean a disruption in that opposition. To ask is in and of itself both foolish, and quite possibly, in hindsight, selfish’, thus back to the drawing board. And here we are.

To make progress, we need one another. Software Freedom, as a concept, is among the first movements in modern technology, that embody this understanding. With hopefully, many more to come.

In an ideal world, all competition in business would be based on knowledge and skill, with those closest to the customer having a natural preference. It would not be based on large corporations threatening continuously with litigation, patent trolls lurking in the shadows, or the right of commercial entities to hold patents in perpetuity because of legal loopholes. But we do not live in an ideal world. Even though we should strive towards one, we should adapt to reality.

Compromise, but only very reluctantly so. Copyleft builds towards a brighter future, with our 3 musketeers of Apache, MIT and BSD possibly smoothing the transition. Right, and some of that Public Domain and Mozilla whatsit.

We for one, believe in Free and Open Source Software. We will release our software as copyleft where we can, as creative commons in others (i.e. this website, licence is at the bottom) and perhaps a smidgen of some BSD or MIT for good measure.

We believe the AGPL can be a tool for change, but without some specifics, it is likely to have a bumpy road ahead. Whether it is up the FSF to revise the AGPL again, or up to the users of the AGPL license to provide some more detail, we leave that up to you to decide for yourself dear reader.

For our part, we think those who licence their works under the AGPL are the ones who should help clear things up, at least for their specific use-cases. Those who refuse to do so, should be noted as such, and perhaps, for safety sake, be avoided.

Ah, the barnacles show their prickly faces, time to turn this ship around.

Some Suggestions

So, what are some of our alternatives? Well, in the interim, if we deem certain AGPL licensed works to be too risky, we should probably look for more permissively licensed alternatives. At least for the risky ones, not all of them of course. We might consider opening up discussions here and there as well.

We’re not suggesting that you start practising your graffiti skills. A ‘FOSS-4-Life’ tattoo isn’t something we’d recommend either. Although that would be funny. Seriously though, probably best not to get one of those.

A conversation around the water cooler might be a good start. Mentioning a thing or two at your next meeting wouldn’t hurt. Writing a blog post might not spark an overnight revolution, but it would certainly contribute.

You never know, it might spark a revolution. That’d be nifty. Recognition of your fine accomplishment likely wouldn’t come from your closest relatives, but you’d be famous in select circles. If you do succeed in that, consider teaching us how to do it as well. We’ll send you a thank you T-Shirt: ‘My fiddledyjibbit changed the course of FOSS’.

As for alternatives to some of the AGPL licensed software that we’ve mentioned in this guide, we have a guide for that in this magazine. Our upcoming ‘IT Infrastructure Foundations’ series of guides features a blueprint for a completely FOSS-based IT infrastructure. It offers a complete path from a small home office start-up, to that of a large organisation with offices all over the globe.

For those short on time, (especially after reading this guide), you might consider the following quick suggestions:

Terraform: OpenTofu, the official community fork, backed by the Linux Foundation.
Minio: SeaweedFS, possibly with SFTPGo as a front-end. Together they offer a set of features beyond even that of Minio.
Mattermost: While not a complete replacement, consider using Tigase XMPP until the less resource demanding implementations of Matrix (i.e. Dendrite, Conduit) finally feature proper user management (SSO) integrations.

We’ll provide more alternatives to riskier AGPL licensed products in other upcoming articles, tutorials and guides. Be sure to check back in regularly. Oh and if you find any of our suggestions useful, consider donating to those projects. The developers of these projects could really do with some backing. The work they’ve done is of the highest quality, and their choices in licensing are the reason their software is available for all to use, modify and share. If you can find it in your ticky-ticker, it’d be nice to show your appreciation.

Last but not least: if you’re a decision-maker, consider sharing your organisation’s solutions. It may very well pay off in ways you do not yet fully appreciate. If you’re a software developer, consider contributing to one of the many fine FOSS projects out there. It’ll open the door to a whole new world of opportunities. If you’re well, not one of the other two categories, er…hello? Fancy seeing you here! Nice one!