“What is everyones feelings on buying free/open source software? And if we are ok with that could we put DRM on the source code?" - Tom

Ohhhhhh, boy. These are two intense questions.

Short answer:

Buying Free and Open Source Software = Great!

Including DRM in, on, or anywhere near Free and Open Source Software (including on the source code itself) = The Opposite of Great!

Long answer:

Selling Free Software (and open source) is actually encouraged by people such as Richard Stallman and the Free Software Foundation:

“Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.

Actually, we encourage people who redistribute free software to charge as much as they wish or can."

There are many ways to “sell” software (read: to monetize it). Everything from boxed copies… to paid access to exclusive repositories… and even the old fashioned “shareware” model. All of it works and complies with the GPL. So long as the publisher of the software also supplies (free of charge) the source code for any GPL'd software, upon request, it's all good!

There are people out there who see this as problematic. Paying for software is seen, by some, as somehow evil. Or against the spirit of the GPL and Free Software. Those with that viewpoint simply have a misunderstanding of what Free Software is. If Richard Stallman himself is encouraging the selling of Free Software… then I'd say that idea gets a solid thumbs up.

From a practical perspective, selling software (via whatever mechanism) that also has the full source code available does present a challenge: Namely that someone can come along, compile the source code, and distribute that software free of charge. Which, in turn, may impact sales by the original publisher.

This, right there, is one of the biggest hurdles to get over for any publisher looking to sell GPL'd (and, to a lesser extent) open source software.

There are really two ways to approach this:

1) Don't use GPL, go BSD.

If the GPL requirement of publishing (or making available) source code feels like an insurmountable hurdle… there's always the BSD license.

Source code licensed under the BSD… can be used in published applications that are completely closed source – with no source code avaialabe to the public at all. You can publish your source code (and code modifications) but the license itself does not force you to do so.

This is a big reason some people choose BSD (and similar licenses) for projects. It feels, to many, to be more compatibile with traditional, closed source, software selling strategies.

2) Use the GPL, but modify the selling strategy.

Personally, I'm a big fan of the GPL. I like that, if someone wants to use my source code (licensed under the GPL), they are required to make the source available. For me, that's a big selling point in the license.

That said, I certainly must agree that GPL'd software presents a unique set of hurdles when it comes to monetization – hurdles that just don't exist with, say, BSD'd software. Luckily, there are still many (very viable, and very well proven) strategies for selling and otherwise monetizing GPL'd software.

  • Paid Support : This tends to be the route most “Enterprise” offerings go. Paid support services are common amongs the likes of Red Hat, SUSE, and similar companies. And for good reason. This is a proven model that works.

  • Paid Services : Beyond simply support, some software will lend itself well to paid services. Such as online services that can be utilized from within the application. This won't always work, but when it does… it can make a lot of sense.

  • Exclusive Binaries : “Official” installers and packages provided by the original developer / publisher are a big selling point. Gives customers peace of mind that they're getting something without any unwanted modifications (nefarious or otherwise). This can also come in the form of exclusive update repositories, and the like. Users get new changes first, and in a reliable way.

  • Supplementary Materials : Books. Training. Posters. Cheat-sheets. Phsyical media. Shirts. Hardware. Depending on the particulars of the software one is attempting to monetize, there are likely many options here for additional paid goods (or “freebies” given to those that purchase the software).

The reality is that a combination of these is often the best strategy. For example: Paying customers of a piece of software get support (training videos, exclusive support forum and support email), access to exclusive installers and packages, along with a reference guide and cheet-sheet.

For me, personally, the availability of source code is something I want to see in the software I purchase. I would rather purchase Free and Open Source Software than proprietary software – even if, in theory, I could download the same software, free of cost, from a different, third party website. And I'm not alone. The market for people who actively wish to support Free Software is substantial.

Now.

Let's talk about DRM.

I can see why someone would think of wrapping the published source code, of commercial (but open source) software, inside some sort of DRM wrapper. A way of making it so that you only have access to the code after you have made a purchase or something.

But this simply won't work. At least not with the GPL. Once someone has access, under the terms of the GPL, they must be able to modify and redistribute. That's the point. So not only do I think “DRM wrapped Source Code” as a concept wouldnt’ work… I don't like the idea.

Likewise, DRM should be nowhere near any piece of software that is “open” in any way.

DRM is the antithesis of Free and Open Source. The whole point of DRM is to lock things down. To restrict what you can do with your software. With your content. On your computer.

I'll put this as nicely as I can:

Any company or project that utilizes – in any way – DRM schemes that artificially restrict how a piece of software can be used… they're doing it wrong. They're doing something harmful. And this includes the incorporation of DRM functionality within an aspect of the software.

I understand the (many and varied) reasons why utilizing DRM within an otherwise “open” project would be compelling. Heck, I've done that. I've included some (very light) DRM in past Free Software that I wrote. That was stupid of me. It made no sense, in hindsight. It provided no real benefit to me, and provided only harm to the end users (in my case the harm wasn't much more than a mild annoyance… but, still, not a net positive impact). Learn from my mistake (and the mistakes of others).

This would, in my mind, apply to some of the biggest open source and Free Software projects on the planet. Including web browsers. cough

In other words:

Got Free and Open Source Software? Sell it. Monetize it (in whatever creative way you can come up with). Use those funds to continue making it better and better. Just leave the DRM stuff in the trashcan where it belongs.

====

The articles here at the Lunduke Journal are often also available as a Video episode and Audio Podcast.

Ways to watch the show: LBRY, YouTube

Ways to listen to the show: RSS Podcast, iTunes, Google Play Music, Spotify

Ways to read the articles: RSS Article Feed.

The Lunduke Journal wouldn't be possible without the support of Linode. Linode provides some of the awesomest Linux server hosting in the world – sign up using this link to get $20 hosting credit. Which ain't too shabby.

Ways to support The Lunduke Journal:

  • Pick up a nice, nerdy T-Shirt over at The Lunduke Store.
  • Become a monthly patron over at Patreon. This grants access to the exclusive, weekly “Ask Lunduke” show as well as the “Lunduke Journal Quarterly” PDF.