Short Answer: No way, José! Right Answer: Sangoma should fix it. Our Answer: New GPL Repo fixes it… today!
We began our series on FreePBX® by providing a GPL-compliant alternative to the base design of the FreePBX GUI minus the elements which have made redistribution and/or code modification difficult despite the clear language of the product’s GPL licenses. In our last article, we introduced new turnkey versions of Incredible PBX for CentOS featuring your choice of the 2.11 or 12.0 Incredible PBX GUI. Coming soon will be new releases of Incredible PBX for the Ubuntu, Debian, and Raspbian platforms so hang in there.
This week we begin our examination of the actual FreePBX design and the morphing that has taken place. We want to give you the full picture of why this led to our decision to no longer support the FreePBX approach to “GPL” software design. We also will provide some additional GPL tools that open up the platform in the way the GPL license requires.
It’s important for everyone to understand the impact of commercialization on project development when organizations bend the rules to suit their own commercial purposes. None of this was Sangoma’s doing. But FreePBX is now Sangoma’s GPL project, and it’s up to them to clean up the mess. For openers, nobody forced the FreePBX developers to release the FreePBX code with a GPL license. But they did it… almost 10 years ago! Only after the product became hugely popular did these folks apparently conclude that maybe giving away their software wasn’t such a good idea after all. You can track when the wheels came off the bus by looking at the project’s history on SourceForge. Not surprisingly, it coincides with SchmoozeCom’s entry into the picture. As Richard Stallman of the Free Software Foundation would tell you, this isn’t about whether code is open source software. Some FreePBX modules are and many are not. But providing source code is merely one aspect of the GPL. So let’s start with some of the actual language from the GPL license:
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. [Emphasis added.]
Today we want to cover the first of several topics you won’t ever hear about in a (commercial) “advanced” training class for FreePBX. In case you haven’t attended one of these lovefests, the training is intended to let (paying) students learn how to customize the settings of the GUI for others willing to pay someone to build them a PBX. There’s nothing particularly wrong with that unless you believe everything associated with free software should be free. We don’t. In any case, you’ll learn how to create extensions and ring groups, inbound and outbound routes, trunk setups, and many of the other (basic) things that Nerd Vittles has been covering (for free) for years. And, of course, you will learn how to market the FreePBX brand and Sangoma-produced commercial modules.
What you won’t hear is anything about the inner workings of FreePBX much less how to customize the product for your own use, i.e. the types of modifications envisioned by the clear terms of the GPL. Those GPL “features” are available on a per customer basis for substantial “customization fees.” Translation: roughly the same cost as a new Hyundai for your kid headed off to college. And there’s one other hidden surprise. Even with custom branding of FreePBX, you will remain a captive in the so-called FreePBX ecosystem.
If you’ve enjoyed Apple’s App Store approach to system lock-in, then you’ll feel right at home with FreePBX. The wrinkle is that the FreePBX approach is even more restrictive than Apple’s. For openers, anyone wishing to sell their own commercial module need not apply. Unlike Apple, no commercial offerings from anyone but Sangoma are permitted in the FreePBX ecosystem. Imagine if Digium had adopted a similar approach by barring modules from competing hardware companies from interfacing with Asterisk®. Where would that have left Sangoma? In the case of FreePBX, even if you want to give away a FreePBX-compatible GPL module, you’re out of luck with FreePBX 12 unless you’re willing to underwrite Sangoma’s unlimited legal expenses if they ever get sued. Note our emphasis on unlimited. Sangoma claims they merely copied a general indemnification provision used by others such as Rackspace. But, as one of our readers pointed out:
The link that they claim they used as a template is one I would sign. Sangoma reworded things so that ALL liability is yours, even if an issue arises in their code that affects your code (after the fact). Sangoma in that case, is responsible but YOU have to pay for their legal fees. You cannot have a final say in settlements, they do. They can select whatever priced attorneys they want (you have no say). There is no ‘reasonable’ word usage. They dropped it.
As for your GPL module, yes, you can manually load it and run it without signing the indemnification agreement, but users will have to endure nasty warnings and emails every day which suggest that their server has been compromised.1 Apple, on the other hand, screens free and non-free additions to their App Store and includes literally thousands of third-party apps without anyone having to pay Apple’s legal fees. FreePBX proclaims that “Free Stands for Freedom” but…
I’m reminded of a book that was published during the Vietnam War era: “Military Justice is to Justice As Military Music is to Music.” If this is Sangoma’s idea of freedom, I’m not quite sure why anyone would want it except for the fact that they’re the only GUI game in town. The Sherman Act may be unfamiliar territory in Canada, but it might be worth a careful look.
Here’s where the GPL breaks down. Despite the best of intentions, the GPL drafters believed that handing someone the source code for a program was the best way to insure freedom to redesign and redistribute computer programs. That works well when the computer program is a couple hundred lines of code, but it breaks down quickly when you’re dealing with a program that’s been commingled with a commercial Cloud-based hosting service shrouded in secrecy and you’re staring at a million lines of code that can best be described as “engineered obfuscation.” Think of it as handing someone a plate of your grandma’s cookies and, when asked for the recipe, you say, “All of the ingredients are right there in front of you.” Yes, but…
This is a critically important point so let’s cover it in the context of FreePBX. What do you get and what do you not get when you install or use the product? Because the FreePBX GPL modules are written in unencrypted PHP code, you automatically get the source code when you install each module. It used to be that you also could acquire the modules on a public web site provided by the developers, now Sangoma. As noted last week, that openness came to a screeching halt with FreePBX 12. Until our repository was made available, you could scour the web high and low, but you wouldn’t find the GPL “free” modules for FreePBX 12 in a format directly usable by the FreePBX GUI and its Module Admin update feature which is perhaps the best feature of the GUI. In fact, until today, the only way to acquire the modules in a usable format with error correction was through the FreePBX GUI interface itself using the proprietary, hidden “ecosystem” maintained by Sangoma. The acquisition process itself is buried deep in a million lines of spaghetti code. Yes, you can get the source code, but…
@tm1000 Kindly document the steps required to upgrade 10 modules from GitHub vs. 3 button clicks in GUI: Check OnLine, Upgrade All, Process
— Ward Mundy (@NerdUno) May 26, 2015
Sangoma hopefully will ponder the words of Richard Stallman, the Founder and President of the Free Software Foundation:
Clearly that server does not respect our freedom, and we should refuse to use it, for the most part.
If we use a GUI for PBX’s, we should load our modules in some way that treats us decently.
So why the mystery with acquisition of FreePBX modules? The simple is answer is that it restricts everyone’s freedom. You can’t redistribute FreePBX without keeping Sangoma and the “non-free” FreePBX ecosystem in the middle of the equation. This provides the ongoing platform for Sangoma to peddle the sale of (only) their branded SIP trunking service as well as (only) their commercial modules. This may be their idea of freedom, but…
Last week we provided the first glimpse of freedom providing a means to break away from the trademark gimmicks of the mothership by using our reengineered GPL GUI with our repository of GPL modules for the new product. What you still lacked was the freedom to break away from our universe and go your own way. Why? Because the FreePBX developers have never revealed their Cloud’s secret sauce much less the tools necessary to create your own GPL module repository and have it function properly within the GUI. Without the cloud access and control, you lose the key module update and monitoring capabilities of the product itself plus the ability to upgrade the GUI to a later version. We used to call this CrippleWare, software with only limited functionality unless you cough up the big bucks. They’ll tell you that it’s all in the source code…
Well, not quite all. FreePBX is open source GPL software minus the secret sauce hidden in Sangoma’s Cloud which is the antithesis of the freedom component of the GPL. If you don’t appreciate the difference and why this runs counter to the GPL, read Richard Stallman’s explanation here. Because Cloud access by design is the only means provided in the FreePBX GUI to load new GPL modules, or to check for and update existing modules, or to upgrade the FreePBX GUI itself,2 the Cloud component is clearly an integral component of FreePBX. As such, it also must be licensed under the GPL and all its source code made available. In the words of the Free Software Foundation:
I’d like to incorporate GPL-covered software in my proprietary system. Can I do this?
You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too.
A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.
However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs. So the GPL has to cover the whole thing.
If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.
If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.
Of course, every new module release brings a new opportunity to change the file and directory structure hidden in the Cloud to once again disguise the secret components required for proper GUI operation. Trust us. They have. Why else would you change a file name from modules-12 to all-12 except to conceal its identity? It’s called security through obscurity. Try searching your server for all-12 and see what you find. This hidden file is what locks you into the Sangoma commercial ecosystem. They call it freedom. It’s really anything but that. A more descriptive label would be a hidden, proprietary GOTCHA. You get some of the source code to make FreePBX work properly, but…
Building an Independent GPL Cloud Repository for the Incredible PBX GUI
Today we’re going to fix this deficiency at least for those using the new Incredible PBX GUI by offering independently developed GPL code that provides the freedom to build your own Cloud-based ecosystem should you wish to do so. We would encourage Sangoma to do the right thing. Stop listening to the former owners of the FreePBX project and become a good GPL steward. It’s your project now. You’ve owned it for almost six months! You’re also a better company than the one you bought. So start acting like it. Bring the FreePBX Cloud-based components out into the open and provide the tools necessary to use them as your GPL product license requires.
What we are providing today are all the components necessary to build an independent GPL Cloud that is compatible with the Incredible PBX GUI. This includes a base install of existing GPL modules that are compatible with versions 2.11 and 12 of FreePBX plus the toolkit to maintain an independent GPL Cloud. To load future modules and updates into your repository, you’ll need a Linux LAMP server running the latest version of Apache and at least PHP 5.4. Neither Asterisk® nor FreePBX is required on the server platform. Be advised that CentOS 6.5 and 6.6 ship with PHP 5.3 so you’ll need to perform the following steps to bring your server up to the 5.4 or 5.5 version of PHP before proceeding. Be advised that your GPL Cloud will only work with GPL-licensed versions of Incredible PBX running the 2.11 or 12 release of Incredible PBX GUI. See last week’s tutorial to get started.
Before we begin, several cautionary notes are in order. First, we can’t control Sangoma’s behavior. Assuming they decide not to comply with the GPL by keeping their Cloud service proprietary, a simple tweak on their end could change the location of their Cloud’s secret sauce at any time. That could very well break the ability to download future GPL modules from their repositories using this toolkit. But don’t worry. If that happens, we’ll be the first to let you know. We figured it out once, and we can figure it out again. You can run, but you cannot hide! We’ll also show you an alternative method to load new modules into your own repository. Second, don’t even think about using your own repository while retaining the original FreePBX GUI instead of updating to the Incredible PBX GUI. A single module update on their end could do a couple of things. It could overwrite the location of the module repositories and restore theirs. Or it could completely disable your server after detecting that you had changed the internal workings of FreePBX. Remember when Apple did just that with jailbroken iPhones? We’re not suggesting Sangoma would actually pull such a stunt. In fact, we don’t think Sangoma would ever stand for that despite a few developers that might have a different view. But we’re warning that it’s simply not worth the risk.
Before you elect to go your own way with your own repository, be advised that importing new FreePBX-compatible GPL modules without first testing each of them with the Incredible PBX GUI is a very bad idea for the reasons already mentioned. We intend to do that with the new Incredible PBX repository, and we would encourage you to adopt the same approach.
Finally, to protect the security and integrity of your GPL Cloud resources, do not include repo.php and the contents of its accompanying src directory in your public repository. Otherwise, anyone with public access to your server would be able to change the contents of your repository. The proper methodology would be to build and maintain your repository off line and then copy the files to a public web server without the tools used to actually create and update the GPL modules and accompanying XML files. The tools themselves are GPL code, and you are more than welcome to redistribute them pursuant to the GPL license. Just don’t post them in decompressed format in your repo thereby making them functional for anonymous attacks against your repository.
To begin, download GPL-repo.tar.gz from SourceForge and decompress the tarball into a folder on your private server:
mkdir repo cd repo touch index.html wget -O GPL-repo.tar.gz http://sourceforge.net/projects/pbxinaflash/files/IncrediblePBX11.11%2B11.12%20with%20Incredible%20GUI/GPL-repo.tar.gz/download tar zxvf GPL-repo.tar.gz yum -y install php-simplexml
The file structure will look like this where modules and src are subdirectories:
Within the modules subdirectory will be a packages subdirectory that includes folders for each of the GPL modules. There’s also a licenses folder with all of the applicable GPL licenses.
Within each of the package directories, you will find one or two modules for the two currently supported GPL versions. For example, here are the entries for the framework module:
The lists of the available modules for each supported GPL version are contained in the .xml files in the top level directory: modules-2.11.xml and all-12.0.xml. modules-12.0.xml is a symlink to a previous nomenclature for version 12. These XML files are what Module Admin uses to check for updates available for existing modules on your PBX.
To add or update individual modules in your repository, issue one or both of the following commands using the actual name of the module you wish to add or update. You can decipher the actual names for the modules by checking the FreePBX source listings on GitHub. As we cautioned previously, don’t ever add or update modules without first testing the new module on an Incredible PBX server running the Incredible GUI. If an updated module blows things up, please let us know!
./repo.php 2.11 modulename ./repo.php 12.0 modulename
And here’s how to add any compatible module from any FreePBX 2.11 or 12 server or from GitHub to your repo. On the FreePBX platform, switch to the directory holding the modules: cd /var/www/html/admin/modules. By way of example, let’s assume there’s a javassh module directory.
1. Decipher the current version of the module:
grep version javassh/module.xml
2. Create a gzipped tarball of that module including the version:
tar -cvzf javassh-VERSION.tgz javassh/
3. Move javassh-VERSION.tgz to your /repo folder:
mv javassh-VERSION.tgz /var/www/html/repo
Alternatively, you can use the included git-grab12 script to download the latest version 12 modules in tarball format directly from the FreePBX repository on GitHub:
From your /repo folder:
./git-grab12 modulename (there is no javassh version 12 module)
4. Assimilate the javassh module into your repo as either a 2.11 or 12.0 module or both:
cd /var/www/html/repo ./repo.php 2.11 javassh-VERSION.tgz ./repo.php 12.0 javassh-VERSION.tgz rm -f javassh-VERSION.tgz
When you’re ready to go public, move the /repo folder and its subdirectories from your private server to a public web server, issue the following commands within the main destination directory on the public server to remove the GPL repo toolkit:
rm -f git-grab12 rm -f repo.php rm -rf src
The final step is to tell the Incredible PBX GUI the new location of your module repository. For this, you will need a fully-qualified domain name (FQDN) that points to the top-level directory of the repository stored on your public web server, e.g.
http://myrepo.me.com. Once you have set up a DNS entry for this address and tested it to be sure it works, all you have to do is configure the GUI to find it. Issue the following command from the Linux CLI after logging into your server as root. Be sure to substitute your actual FQDN and your actual root password for MySQL if you have changed it from passw0rd. If you’re building a number of new servers, you could simply add this line to the end of the Incredible PBX install script. Be sure to copy the entire line below. It should end with double quotes.
mysql -u root -ppassw0rd asterisk -e "update freepbx_settings set value='http://myrepo.me.com' where keyword='MODULE_REPO' and description='repo server' limit 1"
Isn’t it amazing what you can do with some GPL code and a little documentation on how to use it? Freedom At Last!
Originally published: Tuesday, May 26, 2015
Support Issues. With any application as sophisticated as this one, you’re bound to have questions. Blog comments are a terrible place to handle support issues although we welcome general comments about our articles and software. If you have particular support issues, we encourage you to get actively involved in the PBX in a Flash Forums. It’s the best Asterisk tech support site in the business, and it’s all free! Please have a look and post your support questions there. Unlike some forums, ours is extremely friendly and is supported by literally hundreds of Asterisk gurus and thousands of users just like you. You won’t have to wait long for an answer to your question.
Need help with Asterisk? Visit the PBX in a Flash Forum.
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
Some Recent Nerd Vittles Articles of Interest…
- According to a recent tweet from one of the developers, these warnings now can be disabled. That change was more than a year in coming. [↩]
- The latest versions of the GPL modules are available in FreePBX’s GIT repo. UPDATE: Although tarballs are available for individual modules, even that format on GitHub would require painstaking, individual imports within the FreePBX GUI and totally defeats the design and purpose of the Module Admin component of FreePBX. [↩]