JUST RELEASED: Visit the Incredible PBX Wiki
We’ve always been a believer that things happen for a reason. And so it is with the recent CentOS "acquisition" by Red Hat. It’s no secret that CentOS was cutting into Red Hat’s revenue stream. While Red Hat had announced plans to create its own CentOS-like spinoff, the actual absorption of CentOS and its development team into Red Hat, Inc. was a surprise. So was the claim by Karanbir Singh that he individually owned the CentOS trademark. As we previously described, the whole CentOS story is more than a little murky. What began as a rebellion by some open source developers to the heavy-handed Red Hat reinvention of what open source and the GPL were all about abruptly morphed into something quite different. We hope Red Hat has the best of intentions, but some may see things differently given Red Hat’s history in the open source space. Did one or more developers just throw in the towel in exchange for some undisclosed money and a cushy job? Only the developer(s) know the answer to that. From Red Hat’s perspective, it gives them complete control of the best known, free, competitive and compatible product that was making inroads into their cash cow, Enterprise Linux. Only time will tell whether the goal of this acquisition was to make CentOS a better product. Nothing now prevents Red Hat from diminishing the compatibility between Enterprise Linux and CentOS.
In the VoIP world, CentOS has played a leading role in the evolution of Asterisk-compatible turnkey systems. That history includes Asterisk@Home, trixbox, Elastix, PBX in a Flash, Asterisk Now, and the FreePBX platform. Just as Excel relies upon Windows to run, all of these distributions have relied upon CentOS as the underlying Linux operating system for their VoIP platform. And this has been the case for almost a decade with no objection from the CentOS folks. In fact, some of us that contributed to the CentOS project received tacit approval to do exactly what we’ve been doing by bundling CentOS with the PBX in a Flash VoIP platform. After all, CentOS is GPL2 software, and we can read.
Having said that, the PBX in a Flash Dev Team is shifting gears. Down the road we plan to release 32-bit and 64-bit Scientific Linux-based ISOs. By popular demand, over the next few weeks, we will release the PIAF3-Installer, a freeware installation program that installs PBX in a Flash 3.0.6.5 on an existing Linux platform. You first install the operating system of your choice, and then the PIAF3-Installer takes it from there. The first release will support 32-bit or 64-bit CentOS 6.5 or the Scientific Linux 6.5 minimal install. Future releases will support additional Linux operating systems, and we’ll keep you posted on what those platforms will be. All of the installs have been designed to look and feel and perform exactly as the PIAF 2.0.6.5 ISO works today. The installer also has been designed to work with our cloud partner, RentPBX. And it should work well on other cloud platforms as well as virtual machines including VirtualBox. The PIAF-Green Virtual Machine featuring Scientific Linux 6.5 is already available and was built using the new PIAF3-Installer. For the time being, the PIAF3-Installer gets us out of the operating system business until some of the legal issues are resolved. There’s lots of exciting new PIAF3 software coming your way very shortly. So stay tuned.
So what’s the big deal with the Red Hat acquisition?
Red Hat has a different view of the open source universe and the GNU General Public license (GPL2) under which CentOS is distributed. And, make no mistake, Red Hat has no choice about using the GPL2 license because their aggregations include thousands of components, most of which are licensed under GPL2. One of the fundamental precepts of GPL licensing is you are free to use or add to others’ GPL-licensed products so long as you also license your software under the same terms, i.e. the GPL2 license. Historically, Red Hat has applied its own GPL interpretation.
Here’s where it gets interesting. Red Hat aggregated thousands of these GPL2 products and configured them so that they worked harmoniously. And thus was born Enterprise Linux, a wildly profitable Linux "operating system" which consisted primarily of other developers’ free open source software components. And what did Red Hat bring to the table? A trademarked name and logo consisting of some artwork, a method of installing and configuring the various components so that they played nice with each other, and a marketing, support, and legal department. In pulling off this hat trick, Red Hat sprinkled its trademarked name and copyrighted artwork in various files throughout the operating system in such a way that the system wouldn’t function if you removed or renamed some of the files under which the Enterprise Linux operating system was running. Then Red Hat barred others from using its trademarks and copyrighted artwork in competitive products that sought to fork, use, and enhance the Enterprise Linux GPL2-licensed code claiming brand confusion. Merriam-Webster calls it a gotcha. We do, too.
With CentOS, the developers (perhaps with some Red Hat coaching) were sufficiently savvy to remove the Red Hat branding and artwork and then recompiled the source code substituting their own branding and artwork while never disclosing exactly how they did what they did. Scientific Linux did much the same thing a bit later. Was there a non-disclosure agreement between CentOS and Red Hat that was part of their legal settlement? Who knows? The bottom line was that the CentOS project operating under the cAOS Foundation made bold claims that they’d never act like RedHat in dealing with others that wanted to use their free product. And, more importantly, they kept their word and never did… at least until the 2014 Red Hat acquisition when CentOS license terms abruptly changed.
Here’s the key language that all of us relied upon as far as CentOS licensing and integration into other products:
[W]e will never make the system depend on an item of non-free software.
We won’t object to commercial software that is intended to run on cAos systems, and we’ll allow others to create value-added distributions containing both cAos and commercial software, without any fee from us. To support these goals, we will provide an integrated system of high quality, 100% open source software, with no legal restrictions that would prevent these kinds of use. (Emphasis added)
Indeed, this licensing approach is exactly what GPL2 requires! The Red Hat theory of open source licensing goes something like this. You are free to use our source code (only) to develop your own GPL2 product provided you recompile the executables after removing all of our trademarks and copyrighted artwork from the source before you proceed. And here’s the rub with that approach: the GPL2 license. Three important components of the GPL2 license are listed below. Red Hat’s new CentOS license only partially complies with sections 1 and 2 while ignoring sections 3 and 7.
Sections 1 and 2 of GPL2 give users the right to copy, modify, and redistribute source code provided appropriate notices are attached and the new source code is licensed under GPL2. There’s no authorization to restrict or limit reuse or modification of individual components in the GPL2 program.
Section 3 of GPL2 gives users the right to copy and use or modify the object code provided in the original work. There’s no authorization to restrict or limit reuse or modification of individual executable components in the program.
Section 7 of GPL2 is the enforcement mechanism of the license. If the licensor uses a patent "or any other reason (not limited to patent issues)" to restrict the use of a GPL2-licensed product then the licensor has two options: (1) remove the restriction on use or (2) stop distributing the product pursuant to GPL2. If the licensor insists upon enforcement of a patent, a trademark, or copyright claim whether real or contrived, then "the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program." The quoted passages couldn’t be more clear.
Red Hat wants to have its cake and eat it, too: sell a product using everyone else’s free GPL2 products without restriction and then tie up its own GPL2 product with trademark and copyright land mines that deter others from using the product except in an inoperative form. This is nothing new. Back in the shareware days, we called it Crippleware. Stated another way, Red Hat wants to permit GPL2 use of modified CentOS in source code format only minus the CentOS marks and images and without any object code or executables and without telling you how to restore functionality after removing the required pieces to which RedHat claims ownership. Simply stated, the boat won’t float without major plumbing changes from any user that wants to keep the boat from sinking. And Red Hat won’t tell you where the boat is leaking or how to fix the leaks. Never mind that Red Hat didn’t mind using thousands of other developers’ trademarks and copyrighted artwork in the Enterprise Linux and CentOS aggregations. There’s a reason. Such restrictions are impermissible under the GPL2 license. Indeed, it’s one of the primary reasons that the GPL license came about in the first place. Assuming Red Hat ever obtains the CentOS registered trademark (which we plan to challenge if no one else does), Red Hat has two options under section 7 of GPL2: drop the trademark and artwork removal requirements or stop marketing CentOS and Enterprise Linux as GPL products (which they obviously cannot do since they are using thousands of other folks’ open source trademarked GPL2 products in "their work" at no cost).
Here’s a modest proposal that we believe would make everybody happy. First, many folks don’t give a rip about using either the RHEL or CentOS marks or artwork. It’s the source AND executable code that was released under the GPL that users are after just as they were promised under GPL2 and under CentOS previously published licensing terms. What we’re not going to do is invest hundreds of programming hours rebranding and maintaining what is touted and distributed as a GPL2 product. Personally, I’d prefer to spend the hours on a legal brief blowing Red Hat’s GPL2 reincarnation of open source out of the water. It’s dead wrong based upon the clear language of the GPL2 license. Paying lawyers or experts to twist the meaning of the GPL2 language that’s perfectly clear on its face simply isn’t going to fly. We’ve been down this road before. And David and Goliath is still one of our favorite Bible stories.
If Red Hat wants a generic, mark-free, image-free distribution of CentOS in lieu of waiving its trademark and copyright claims, then Red Hat can produce a clone with binaries AND keep it current as new versions of RHEL and CentOS are released! Make it a 100% RHEL-compatible and call it MugWump™. Use the Nerd Vittles logo for the artwork. Or come up with any other name and logo so long as there are no restrictions on use by others. If Red Hat uses our proposed name and logo, we will license everyone to use the product, the copyrighted artwork and the MugWump trademark pursuant to GPL2 at no cost. If Red Hat chooses its own new name and logo, then Red Hat agrees to license the product under the same terms we have proffered. The end result: everybody will be happy while saving Red Hat hundreds of thousands of dollars in legal fees. What’s not acceptable is distribution of a product which purports to be GPL2 code but places unreasonable and unachievable restrictions on use without hundreds of hours of development work by potential end users. That’s not what GPL2 was ever about. Hopefully the federal courts won’t have to say so.
Originally published: Tuesday, February 11, 2014
Need help with Asterisk? Visit the PBX in a Flash Forum.
Special Thanks to Our Generous Sponsors
FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.
BOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.
The lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.
VitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
Special Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
Some Recent Nerd Vittles Articles of Interest…
There isn’t a single piece of artwork, etc. involved in Red Hat that can’t be removed. The difficulty involved in spinning up CentOS wasn’t removing the artwork, it was the build system that involves handling circular dependencies that is the difficult part.
[WM: You kinda missed the point. Wasn’t suggesting that artwork or anything else couldn’t be removed with sufficient effort. It obviously can and has been by several groups. In fact, Scientific Linux provides the tools to do it. The point is that, under GPL2, you shouldn’t have to remove anything. If it’s proprietary, copyrighted, patented, or trademarked, that burden falls upon Red Hat unless they want to place the resources under GPL2 along with everything else. By all means, enlighten us on the circular dependencies which looks to be further evidence of the crippleware to which we referred. I suspect that’s the reason Red Hat no longer offers free binaries with Enterprise Linux, and you may have seen your last ones with CentOS as well. Binaries are clearly not "independent and separate works" when they are built from GPL2 source code. As such nothing would bar their redistribution pursuant to the terms of GPL2. But we’ll save that discussion for another day. ]
You can redistribute CentOS as is (with no modifications) and call it CentOS … if you Modify it in any way, you can say your distribution is "based on CentOS", but you can not call it CentOS.
===========================================================
This policy is not much different than the Ubuntu policy:
http://www.canonical.com/intellectual-property-rights-policy
Specifically (Quoting from the page):
You can redistribute Ubuntu, but only where there has been no modification to it.
You can redistribute Ubuntu in its unmodified form, complete with the installer images and packages provided by Canonical (this includes the publication or launch of virtual machine images).
Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu. If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below).
===========================================
Debian is not any different …
http://www.debian.org/trademark
Specifically:
When You Can NEVER Use the Debian Trademarks Without Asking Permission – "You cannot use Debian trademarks in a company or organization name or as the name of a product or service."
So, if you change the Debian distribution, you can not use the Debian name or trademarks any more because it is not Debian (because it is now "something else").
==========================================
From OpenSUSE:
http://en.opensuse.org/openSUSE:Trademark_guidelines#Applying_our_Logo
Distributing openSUSE With Modifications
You may distribute openSUSE with modifications. Such distributions can be created via SUSE Studio, KIWI, or the openSUSE Build Service, or via your own build process.
In making such a distribution, you must remove all trademark uses of the openSUSE Marks from the version of openSUSE you are modifying. You may, if you wish, combine your own trademark with one of the following openSUSE Mark tag-lines (or its equivalent): "Based on openSUSE"; "Powered by openSUSE"; "Derived from openSUSE"; "Uses openSUSE"; "Built on openSUSE"; or "Built from openSUSE".
=====================
This is standard Trademark policy … if you change something so that it is no longer "Product A", you can no longer call it "Product A" or use "Product A’s" logo.
If someone changes something, the changed thing is no longer CentOS … it is SOMETHING ELSE. To be able to use the CentOS trademarks in "SOMETHING ELSE", you need special permission. Every other major distribution works exactly the same way.
[WM: This is about CentOS so let’s leave the other distributions for a subsequent discussion. Bottom line is GPL2 controls, not what others are doing. There would be little concern if the only modification Red Hat sought was to change the logo from "CentOS" to "Based on CentOS." That’s a far cry from what the license posted on RedHat’s centos.org site says. And the GPL requirements for CentOS to remove the trademarks and copyrighted artwork or authorize their use under the GPL2 license still stands if you want to continue to market CentOS as a GPL2 product. I’m puzzled why even the most minor change in the CentOS default install transforms it into a non-CentOS product, yet configuration changes made by Red Hat to Apache, SendMail, PHP, MySQL, etc. don’t seem to have the same effect. In other words, Red Hat is changing the configuration of many applications while still referring to the products by their brand names and without removing any of their trademarks or artwork. Would it not still be CentOS if a superset of RPMs from CentOS own repo was included in the base install? If it’s done programmatically rather than letting the end user do it through an installation GUI, what’s the difference? It’s still CentOS or "based on CentOS." We configure CentOS and add additional applications. The server still boots as CentOS, Apache still loads as Apache, etc. If I add Excel to a Windows machine, it’s still a Windows machine. Am I missing something?]
So, CentOS is doing what all the other FOSS distros GPL2 distros are doing and that is irrelevant? So, if the facts don’t agree with your hypothesis then ignore them? It is extremely relevant that every other distro does it the exact same way.
Instead of putting a superset of RPMs in the Base install … why don’t you instead distribute CentOS exactly as is and ADD your RPMs to the mix. Then your are distributing CentOS (perfectly fine) and software for CentOS (also perfectly fine).
You can have a mirror of non-modified CentOS and your software in another repo/directory.
If you distribute software that runs on CentOS, then you can say your software "Runs on CentOS" … however, you can’t say your software IS CentOS. CentOS did not produce your software.
If you are not modifying the original CentOS software, you can say you are providing CentOS and that you are also providing "Program A" that runs on CentOS.
If, on the other hand you want to distribute "Program A, CentOS Edition" then all you need to do is create/join a CentOS Special Interest Group at CentOS.org and put your software in a CentOS.org git repo and you can create a Variant of CentOS. An example might be the CentOS – Storage Edition. CentOS – Storage Edition might contain Ceph and GlusterFS packages and be on a separate ISO.
You can’t possibly think that any Distro, be it Debian or Ubuntu or OpenSUSE or any other would be perfectly fine with you creating and signing packages that they did not produce … creating a new ISO and telling people that this new ISO is Debian or Ubuntu or OpenSUSE … because it is not. It contains things on it that they did not produce and NONE of them allow it. What they will allow is a separate repository that says that these packages are designed to run on Debian or Ubuntu or OpenSUSE … and they will allow you to also distribute their packages or ISOs unmodified. This is what every distro allows.
[WM: None of the Asterisk aggregations has ever claimed to be CentOS. What was claimed by all of them was that their Asterisk implementation was "Powered by CentOS" or running under CentOS. Again, think of it as Excel running under Windows. The difference is that the GPL permits distribution of CentOS (the operating system) with additional application code. You obviously can’t distribute Windows with Excel because Windows is a commercially licensed product. CentOS on the other hand is GPL2 licensed, and the GPL2 license expressly permits (and encourages) enhancement and redistribution. Each aggregation installs a slightly different mix of components so I can’t speak to anything other than the way PBX in a Flash works.
Let’s put our differences on GPL2 aside for a moment and see if we can’t agree on an approach going forward. I don’t think we are far apart after reading your comments. What the PBX in a Flash ISO does now is a two-step install. In Phase I, we use the CentOS anaconda setup pretty much as is. We only customize three ks config files (Std, LVM, and SW RAID). In those config files, we choose a drive type, name the machine, bring up a DHCP network connection, and add several RPMs that are not part of the CentOS repo. We then create some directories for subsequent processing and record what’s been installed. We then patch some startup files to set up our installation environment. Finally, we add our startup script to rc.local. It is contained in one of the additional RPMs that is loaded. The system then reboots and runs our Phase II setup procedure after the user logs into CentOS as root. Most of the Phase II install involves downloading and compiling of the various components that turn the platform into an Asterisk-based PBX.
If it gives the current CentOS developers heartburn, we could easily move all of our custom RPMs from Phase I and download them as part of Phase II. We also could handle the directory creation and file naming tasks in Phase II. Our only essential requirements in Phase I are to set up a DHCP network connection (which CentOS does not do by default) and to modify the rc.local file so that it kicks off our Phase II install on reboot. Let us know if this is acceptable, and we’ll make the necessary changes moving forward.]
Seems pretty obvious that trademarks, artwork, logos, etc., are not components of source code or compiled object code.
[WM: More accurately, they are not essential source code. Once you include them and release an application under GPL2 is when the problems arise.]
Ward, there is just one little thing wrong with your analysis that seems to plague most of these sorts of analyses: The CentOS distribution is not (and cannot be) covered as a whole by the GPL. Mere aggregation with GPL code does not automatically place other code under GPL (see https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation )
The source code for the packages for the trademarked logos are not under the GPL. From my own Red Hat Enterprise Linux 6 system:
[root@www ~]# rpm -qa|grep logo
redhat-logos-60.0.14-1.el6.noarch
[root@www ~]# rpm -qi redhat-logos
Name : redhat-logos Relocations: (not relocatable)
Version : 60.0.14 Vendor: Red Hat, Inc.
Release : 1.el6 Build Date: Thu 26 Aug 2010 11:00:44 AM EDT
Install Date: Thu 19 May 2011 01:39:41 PM EDT Build Host: ppc-003.build.bos.redhat.com
Group : System Environment/Base Source RPM: redhat-logos-60.0.14-1.el6.src.rpm
Size : 28112564 License: Copyright 1999-2010 Red Hat, Inc. All rights reserved.
Signature : RSA/8, Mon 30 Aug 2010 02:00:45 PM EDT, Key ID 199e2f91fd431d51
Packager : Red Hat, Inc.
URL : http://www.redhat.com
Summary : Red Hat-related icons and pictures
Description :
Licensed only for approved usage, see COPYING for details.
[root@www ~]#
So GPL-based redistribution of that package, even in source form, isn’t allowed (it’s not under the GPL!). Redistribution of that package is not in any way affected by the GPL that is used by other packages that are distributed on the same CD.
Please see the license for the same package on a CentOS system; it’s not GPL.
[WM: CentOS is distributed in ISO format as a single file. Once the components are installed and/or intertwined in a manner that they cannot be separated or removed without destroying the basic functionality of the GPL2 components of the "CentOS operating system" (see this link for what would happen), then the components in question are no longer a "mere aggregation" and hence become subject to GPL2. Read your own link which makes the same point. If you don’t believe they’re intertwined, remove the 5 dependencies in the link I’ve provided, then remove the redhat-logos RPM, and reboot. 😉 Just kidding. Please don’t try it.]
Contrary to Lowen’s assertion above, the CentOS-6 distribution has been released as GPL code. Here’s the EULA from /usr/share/doc/centos-release-6/EULA:
A copy of the GPL2 license is also included in that same directory. As we made clear in the main article, under section 7 of GPL2, the licensor cannot use separate copyright or trademark claims to individual components including artwork and marks to prohibit redistribution of the licensed work as a whole pursuant to GPL2. This is especially true where the individual components have interdependencies with essential components of the licensed work. The licensor has only two options under section 7: (1) remove the copyright and trademark restrictions or (2) stop distributing the product. Simple as that.
Ward,
Well, I’ll admit to being in error about the overall collective work license to the Distribution for CentOS. The upstream Red Hat EL EULA is much longer and covers more ground; I’ve read my copy on my RHEL 6 machine.
However, there again is the little issue that the GPL coverage of the Distribution as a whole is a Collective Work copyright, and 17 USC §201(c) says:
"Contributions to Collective Works.— Copyright in each separate contribution to a collective work is distinct from copyright in the collective work as a whole, and vests initially in the author of the contribution. In the absence of an express transfer of the copyright or of any rights under it, the owner of copyright in the collective work is presumed to have acquired only the privilege of reproducing and distributing the contribution as part of that particular collective work, any revision of that collective work, and any later collective work in the same series. "
CentOS as a whole may be GPL, but each individual component keeps it’s own copyright distinct from the collective, as per US copyright law. Further, the GPL states in Section 2:
"These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works."
So the statement you quote from the EULA is not contradictory, since the GPL covers the collective work but each contribution to the collective work, including the logos, retains its distinct copyright and license, especially when separately distributed (as it is in the repositories; CentOS is not just distributed as an ISO).
Lawrence Rosen’s take on this is at http://projects.opensource.org/pipermail/license-discuss/2013-September/001235.html
The trademarked images, as a contribution to a collective work, still have individual copyright, and, well, they are trademarks, much like the rather neat ‘Nerd Vittles’ is your trademark.
[WM: No one is suggesting that CentOS or Red Hat doesn’t have a copyright claim to the artwork or the collective work. For purposes of this discussion, let’s also assume that CentOS and Red Hat also have legitimate trademark claims to the redhat and centos marks. The point is this. If a collective work is licensed under the GPL and the licensor’s artwork and marks form an integral part of the binaries of that work in such a way that they cannot be removed or renamed without crippling the functionality of the collective work, then those components are not "independent and separate works" under GPL2. Hence, those components become an integral part of the whole GPL2 collective work. As such, they also must be covered by the GPL2 license. That’s the price the licensor pays for using other people’s GPL2 stuff. At this juncture, section 7 requires the licensor to either license use of the collective work, the artwork, and the marks under the terms of GPL2 or "refrain entirely from distribution of the Program."
Why do you think the artwork file is still named redhat-logos? Why is there a file named /etc/centos-release (redhat-release in RHEL) that is protected with an encrypted key? Could these files have been named generically? Of course they could. They weren’t! The clear intention was to embed this artwork and these marks into the GPL2 distribution in such a way that removing them would cripple the functionality of the product. Larry Rosen explained why in the first sentence of the message thread you have cited: profit! But it’s also the very reason that section 7 requires the licensor to either authorize use of the images and marks or to not entangle them in the first place. The alternative remedy under section 7 is removal of the product from the market. 17 USC §201 is not inconsistent with the remedial steps outlined in section 7. Simply stated, these components are not "independent and separate works." ]
So, wait. Is it GPL or GPL2? What’s the difference?
[WM: For purposes of our discussion, GPL and GPL2 are being used interchangeably. GPL2 is the controlling license. GPL1 was the original version.
First, Ward, I do respect much of what you do and have done; neither this nor any of my other posts are meant to disparage you personally in any way. I just believe you are misunderstanding the admittedly complex situation.
To satisfy my own curiosity, I just did the following on my CentOS 6.5 laptop:
[root@localhost ~]# rpm -e –nodeps redhat-logos
[root@localhost ~]#
No error messages. I rebooted the system without making any configuration changes.
The only differences I noted while booting was a image file not found error thrown by grub, and my GNOME backgrounds are now a generic blue with no images. Otherwise, the system is operating normally.
Now, I knew exactly what I was doing, and I downloaded the CentOS redhat-logos rpm from one of the mirrors before I did that (putting it in /root, since my /home is LUKS encrypted) just in case I needed to reinstall the package in single user mode.
But I didn’t. The redhat-logos package is not required for the system to run uncrippled; I’m posting right now from that system where redhat-logos has been removed with –nodeps.
Try it, Ward.
Now, I’ve refrained from saying this before, since I really respect you and your work with PBX in a Flash. But if redhat-logos becomes covered by section 7 just by being aggregated into a GPL covered collective work, then so should the compiled piafdl script distributed with PBX in a Flash, and so all the rights under GPL should fall to that script as well, right? You yourself claim the freeware installer piafdl that is bundled in the downloaded ISO is ‘merely aggregated’ (according to your post at http://pbxinaflash.com/community/index.php?threads/gpl2-notice-and-licensing.95/ ) but yet not having piafdl cripples PIAF in much the same way as not having redhat-logos does (that is, PIAF’s phase II can be done without piafdl, just like a CentOS system can be run without redhat-logos; it just takes a bit more effort in both cases). That is, I personally don’t think the collective work GPL causes the ‘essential’ piafdl script to become GPL-covered any more than it causes redhat-logos to become GPL-covered.
Now to answer your questions:
1.) Why is redhat-logos named the way it is? My best guess would be to make it clear what the package is, but the actual dependency is for ‘system-logos’ in your linked image above.
2.) As to /etc/centos-release, the only encrypted key of which I’m aware is the package signing key to prevent trojaned packages on the repository (I have rebuilt the centos-release package for CentOS 5 from source on IA64 without any key, and am running it right now on an old SGI Altix). But I reserve the right to be wrong.
Now, as to the applicability of Section 7, I believe you’re confusing the overall GPL collective work coverage (of the CentOS-owned collective work copyrtight) with the individual GPL coverage of packages in the collection.
The CentOS project owns the collective work copyright to the collection, and cannot violate the collective work GPL as copyright owner (see the GPL FAQ, specifically https://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate ). Redistribution, on the other hand, by third parties must respect the CentOS copyright under the GPL as the collection. Section 7 is not binding upon initial distribution by the copyright owner, but is part of the conditions under which the copyright owner (the collective copyright owned by the CentOS project in this case) licenses third-party redistribution of the collection.
The same is true for Red Hat’s collective work copyright license and is why a third party cannot legally redistribute the collective work (as redistribution by the third party is where section 7 applies, as far as the collective work is concerned).
Red Hat’s GPL grant on the ISO as a collective work doesn’t cause section 7 apply to CentOS, since CentOS is taking the individual works (under each work’s respective license) and building a new collective work, with CentOS as the copyright owner; CentOS is not redistributing the Red Hat collective work.
And thus section 2 applies when redhat-logos is deaggregated from Red Hat’s collective work (causing the individual copyright license for redhat-logos to apply), and must therefore be replaced (which CentOS does do). Now, the CentOS redistribution license for the CentOS logos is pretty clear, and yes for a third-party to redistribute the CentOS ISO, unmodified or modified, section 7 of the license for the collective work applies. But it doesn’t apply to the collective work copyright owner, CentOS.
It’s a matter of distinguishing the collective work license and its owner from the individual contributed package licenses and their owners (as 17 USC §201(c) would seem to require); the collective work’s GPL does not override the PostgreSQL package’s individual BSD license, for instance, but only applies to the collection when redistributed as a collection.
But I always reserve the right to be wrong, and this is not legal advice, etc. And I thank you for your work on PIAF.
[WM: Thank you for your comments. This isn’t personal, and I don’t take it that way. Let me first address your initial question regarding the difference in what CentOS is doing and what PIAF is doing. The simple answer is that PIAF includes a freeware installer that is not licensed under the GPL. It does not have to be under the GPL. The CentOS installer, on the other hand, is distributed as GPL2 code. Once the installer and the collective work are licensed as GPL2 code, CentOS is bound by the terms of the GPL2 license. The PIAF installer is not.
There’s another fundamental difference. You can run the PIAF installer, remove it, and still have a perfectly functioning, CentOS-compatible PBX aggregation. We call it PBX in a Flash, not CentOS PBX. So there is no brand confusion. Stated another way, the GPL2 components of PBX in a Flash don’t blow up by removing the freeware installer after you have run it. In fact, we distribute virtual machine images of PBX in a Flash for a variety of platforms. There’s no installer at all. The reason is the underlying GPL2 binary code is not dependent upon the PIAF installer to continue to function. In the words of GPL2, the installer is an "independent and separate work." Complete source code is available for every GPL component that is installed.
Turning to CentOS, remove the CentOS and Red Hat artwork and marks from the installed binary image of CentOS, and that dog won’t hunt, period. And there’s no way to remove them from the binary ISO image without destroying the ability to install CentOS. Yes, with sufficient effort and expertise, some (not all) of the various gotchas can be manually removed by each end user after installation. But you’ve emasculated (some might say crippled) the GPL2 license. It says you don’t have to do any of that because you have an absolute right to redistribute the GPL2 source AND binaries with or without modification. That includes the original or a modified ISO. Setting up copyright and trademark hoops and making these components interdependent with other GPL2 code in the distribution keeps users from being able to exercise their rights to copy, embellish, and redistribute CentOS under GPL2. As previously noted, section 7 gives CentOS two options: (1) remove the impediments by licensing the copyrighted material and marks or (2) "refrain entirely from distribution of the Program."]
Ward,
Thanks for the thoughtful reply.
But when you say:
"Turning to CentOS, remove the CentOS and Red Hat artwork and marks from the installed binary image of CentOS, and that dog won’t hunt, period."
you’re missing the fact that I did just exactly that on my installed CentOS 6.5 system by ‘rpm -e –nodeps redhat-logos’ and this dog is not only hunting, it’s running a rabbit right now…. 🙂 It should be in Little Canada right about now, and heading to Tuckaseegee and then Sylva…. Now, there are some other embedded images (like in the gdm package) that need expunging, but all that is required is to note what packages CentOS modifies and check them for images, and replace them with your own. Yeah, that’s some work.
Getting it installed in the first place after removing the redhat-logos package from the ISO would be a bit more work (remove all Requires: system-logos lines from dependent packages), but CentOS and SL (and the Clear Foundation, for that matter) already have and already show how to replace the Red Hat ‘redhat-logos’ package, among others.
But, back to the real issue, if Red Hat were going to be the bad guy in this, I think they would do more like SuSE, which doesn’t have open distribution of the SLES/SLED sources from which they build their enterprise distribution (at least I’ve not found them, but, again, I reserve the right to be wrong).
And if the issue affects CentOS, it will also affect SL and ClearOS, since it is the same upstream source. I just don’t think it’s quite as large of an issue as you make it out to be, that’s all. But, yes, I reserve the right to be wrong.
Enjoy the snow.
[WM: Just a few brief points. First, there are two separate issues with the binaries and source: installation and operation after installation. Both are covered by GPL2 since the CentOS distribution (including the ISO) has been licensed as GPL2 code. Second, there’s more to the removal than just the artwork. There are numerous marks sprinkled around the distribution in addition to the images. Changing the file names of those marks will cause the distribution not to load or to run. I provided one example with /etc/centos-release. I suspect there are others. Removing or renaming every reference to centos or redhat (even the ones that wouldn’t cause the binaries to implode) is a huge undertaking particularly in the ISO itself. Third, and most importantly, the burden is not on the end user or someone such as the PIAF Dev Team to remove the trademark/copyright minefields and sort out the dependency failures with the binaries. It’s the intertwining of these copyright/trademark dependencies with GPL2 code plus the exercise of these copyright and trademark rights that causes the aggregation to fail the redistribution requirements of GPL2. The burden to remove the impediments falls squarely upon CentOS, not us and not the end user! That’s what section 7 is all about. And it’s a big deal because Red Hat has chosen to make it so. Keep in mind that, until a month ago, none of this was a problem, and the CentOS Dev Team was fully aware of what was going on. We laid it all out in making a most generous contribution to the CentOS project.]
PS: And I do know Ward is a retired attorney and do respect that.
Let’s look again at section 7, the first paragraph:
"7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. "
The key to this whole thing is just who is the ‘you’ in that paragraph, the licensor or the licensee?
In every other paragraph and section, ‘you’ is consistently the licensee, not the licensor. So how does ‘you’ become the licensor for the purposes of Section 7?
In the preamble, the precedent is set by "We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. " In this sentence, the ‘we’ is the licensor(s) and ‘you’ is the licensee. The ‘we’ is not the authors of the GPL, since they don’t have the copyright to the covered software.
The GPLv3 preamble is a bit more specific with "Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it." This language leaves no question as to who ‘you’ is referring to, that is, the licensee(s).
GPLv3 also specifically calls out, in its section 7: "Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:"
…
"e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or"
…
This is clear; if the copyright owner of added material agrees, then the licensee may decline to grant those rights to people to whom the covered work is redistributed. That’s still the licensee; however, this means that a collective work incorporating GPLv3 components can indeed decline to grant trademark usage rights and remain GPLv3 compliant, even if the GPLv3 code’s license ‘goes viral’ and infects the collective work as a whole. (In the case of trademarked logos and artwork added to a GPLv3 covered work, the copyright holder of the added material is likely the trademark holder as well, and can decline to convey trademark usage to the whole GPLv3 covered program).
Also, in an appeals court in Germany in 2010, the court held that the GPL does not convey trademark use. See http://www.lexology.com/library/detail.aspx?g=5b0c0785-3eac-4cbc-ad08-2afba447b1e3 and https://cyberlaw.stanford.edu/blog/2010/10/recent-developments-anti-circumvention-law-gpl-licensing-and-adwords
Yeah, I know that’s Germany and not the US, and thus it’s not a binding precedent. But I would think that similar reasoning would hold here if this were tested in court; both the US and Germany are party to the Berne Convention and so there are similarities. But courts surprise us all the time, no? 🙂
[WM: My reading is that "you" refers to anyone who redistributes code covered by GPL2. That would include Red Hat, CentOS, Scientific Linux, and the PIAF Dev Team. Otherwise, section 7 would be meaningless if there was no mechanism for assuring that the entity redistributing existing GPL code didn’t comply with the same openness that was accorded to them. I think this interpretation also follows from the patent license example which speaks to anyone wishing to redistribute someone else’s GPL code by including material that includes a patent. While perhaps inartfully worded, the purpose of GPL2 is clear: "the intent is to exercise the right to control the distribution of derivative or collective works based on [an existing GPL2] Program." If you take someone else’s GPL2 code and embellish it, you can’t add patented, copyrighted, or trademarked crap to it and then complain when others seek to redistribute your code. Section 7 says the objectionable material has to be removed, or you cannot distribute the program at all. Anyone that is harmed by your actions would have the legal right to seek injunctive relief to shut down your future distribution of the embellished code pursuant to GPL2… unless you were willing to remove the roadblocks either through licensing or physical removal. The remedy is a subtle one. I can’t force you to license your patent, copyright, or trademark. But, if you don’t, you can’t distribute your product which contains someone else’s GPL2 code. And you have correctly identified why most folks have not moved their works to GPL3 licenses.]
So, Ward, if your legal theory is true (and it hasn’t been tested in court yet), then you need to get the copyright holders of those five packages identified as needing redhat-logos to agree that a violation has occurred, right? Only the copyright owner of the specific GPL-covered software is the one who has standing to initiate proceedings, right?
For the distribution as a whole, CentOS owns the collective work copyright, and they’re not going to initiate proceedings against themselves.
You’re best bet is with GRUB, which is a GNU copyrighted program. So why hasn’t the GNU project initiated proceedings? Could it be that they don’t think a trademarked boot logo being used by their program as configured by default in CentOS and distributed with same constitutes a license violation? They are the only ones with standing to initiate proceedings for GRUB, correct?
Unless I’m missing something, anaconda, although GPL covered, is copyright by Red Hat. Well, they would have difficulty initiating proceedings against CentOS for this specific issue, I would think.
Httpd isn’t GPL covered, but ASL, so a GPL-centric issue doesn’t apply.
Gnome-desktop’s copyright owner is, I believe, the GNOME Foundation. Again, they may be unwilling to initiate proceedings based on a logo or artwork, and they’re the only ones with standing to initiate proceedings.
As a licensee under the GPL we who receive copies have no standing to initiate proceedings, I would think (and no, I am not a lawyer, but I’ve had this very discussion with a couple of lawyers before).
Anyway, this has been a good discussion, but, until it’s actually settled in court, we’re just speculating. So, I hope you have a great day.
[WM: Standing arises from all sorts of circumstances. We prefer to keep our powder dry for the time being. There are a number of legal bases supporting what PBX in a Flash and the other Asterisk distributions have done over the past decade. Some have been covered in this article and our previous one. Hopefully, we can work something out that benefits everyone in the open source community. Unlike some, we don’t do this for profit. Enjoyed the discussion anyway. Thanks for your thought-provoking contributions.]
(Note: I went back and read the latest comments after writing this reply, and it looks like some of the points I make have already been addressed in the comments since the time I first saw your post, so I apologize in advance if I’m duplicating some themes here.)
Ward,
Even though I respect you and I’m glad you’re so passionate about free software and about telephony (as am I!), I’ve got to admit that some of your comments here don’t sit right with me, and I feel like some of my experiences (both outside of Red Hat and inside as well, and now outside again) might add some additional flavor to the conversation. I’ve tried to simply hold my tongue and ignore your post, but enough other people have asked me for my insights that I figured it would only be fair to share them with you as well. In short, what I see in your blog post is a lot of smoke and not a lot of fire.
(For those of you following along at home, and not aware of my background, I’ve spent a lot of time and effort in the Asterisk community over the past eleven years — writing documentation, doing Asterisk training and consulting, and doing open source community outreach. I’ve also been actively involved in the Red Hat and Fedora Linux communities for the past eleven or twelve years. A few years ago I left my job as Training Manager at Digium to work for Red Hat as the Fedora Project Leader, and when my two-year term as the FPL was up, I left Red Hat to take another job. In short — I’ve had a lot of experience with both telephony, with Red Hat, and with open source legal matters. In the interest of full disclosure, I’m not an attorney [and don’t play one on the internet], and please don’t take any of my comments or beliefs as legal advice. I don’t pretend to be an expert either, but I have been around this particular block a few times.)
Since your post started with the relationship between CentOS and Red Hat, let me start there. Even though I no longer work at Red Hat, I can tell you what I’ve heard from both Red Hat insiders and community members about the deal. Red Hat is sponsoring the project (employing some key people, making infrastructure such as build systems and QA resources available, offering legal assistance, etc.) in almost the exact same manner as it does with the Fedora Project. And just like the Fedora Project is run by a board, CentOS is too. As a former Fedora Project Leader, I can state unequivocally that Red Hat never told me or the Fedora Board what to do. They trust that the board and the community will make good decisions. Now, in the case of CentOS, I think it’s even more clear because of the obviously limited scope of the project. Whereas Fedora is out pioneering on the cutting edge of Linux distros and doing a lot of development and integration work (and as such, has an obviously short life-cycle), CentOS is obviously more closely tied to following RHEL’s slower, longer-term cadence. And because it’s mostly a simple rebuild of the Red Hat source RPMS, there’s a much cleaner split.
If you look at the makeup of the CentOS board, you’ll see it’s a good mix of community-minded folks. Maybe you’ve never been lucky enough to meet Karsten Wade, but I have, and I have no doubt that if a tough decision came down to either "community" or "Red Hat", he’d side with the community. I’ve seen Karsten in action in the Fedora community over the past six or seven years, and his actions speak for themselves. I could say similar things about many of the other people on the board — they’re all very community minded. Another is Johnny Hughes — who commented earlier — but maybe you didn’t recognize the name. And while I 100% agree with you that only time will tell if the deal ends up helping CentOS become better, I’m more than willing to give them the benefit of the doubt, because I know many of the people involved. You, on the other hand, seem to be assuming malice or bad intentions without providing any evidence to support your assumptions.
Yes, Red Hat is in the business of making money. That’s what they do — but they’re also smart enough to understand that without the respect and cooperation of the tremendous open source communities that they interact with, they’d never be able to make a dime. That’s why they invest heavily in all kinds of open source projects, whether it be in community distributions like Fedora or RDO or CentOS or in individual projects like the kernel, SAMBA, NFS, OpenStack, GNOME, or LibreOffice. I don’t think most people realize just how much Red Hat does to hire great engineers and then let them spend the vast majority of their time working on open source code in public, and contributing to open source communities that make a difference. Even as someone who was actively involved in the Red Hat Linux and Fedora communities before becoming a Red Hat employee, I didn’t realize just how much Red Hat cares (and invests) in giving back to communities until I got hired and saw the inside perspective.
Now, let me shift gears a bit and address some of your concerns about trademarks and copyright law. Again, I’m no attorney, but it seems to me that you’ve got a very naive view of the way that trademark law works, especially in combination with copyright law and copyright licenses. (This surprises me, considering how much time you’ve spent in the US legal system.) Frankly, I don’t see a lot of difference between the CentOS trademark situation and many of the Fedora trademark issues I dealt with during my tenure as the Fedora Project Leader. In particular, I’ll point out a few key observations. First, trademark law is different than copyright law in the sense that trademark law requires you to actively defend your registered mark, or you can lose it. In particular, the legal concept of "naked licensing" is a big concern in this particular case. (If you want a fascinating legal read, study up on the Freecycle case about naked licensing. You can find an introduction to the case at http://www.theiplawblog.com/archives/-trademark-law-naked-licensing-trademark-owners-beware.html) I don’t have energy to go into all the details, but in short "naked" licensing refers to the act of letting anybody use your registered mark without any sort of quality check. (Remember, the whole point of trademark law is to let your customers know that they’re really getting your quality product, and not an imitation.) If you let anyone use your registered mark without doing any sort of quality check, the mark can no longer be considered a reliable indication of quality, and it’s lost its usefulness. In open source software circles, naked licensing is becoming an increasingly easy way to lose the ability to enforce your trademark rights. So going back to the situation at hand… CentOS appears to me to be simply making sure that it’s trademarks don’t get lost. In Fedora, we went a step forward and specifically created a secondary mark for Fedora "remixes", and created specific trademark guidelines such that people could use that secondary mark without fear of somehow hurting the primary mark. (Debian also has a policy around secondary marks, but I’ve actually only ever seen the secondary mark used in public.) Fedora also created some trademark licensing agreements so that third parties could use the primary Fedora mark on commercial items, etc. In particular, I’ll point you to the Fedora Trademark Guidelines at https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines where we specifically call out uses that do and do not require permission.
The second area of confusion seems to be around copyright licenses and their interaction with trademarks. Your remarks seem to indicate that you think the GPL copyright license (or other open source copyright licenses) somehow grant the user of free software a trademark license to use the trademarks any any way they see fit. I don’t think that’s a fair reading of the GPL, or even a view that is commonly held. Even the GNU free software distribution guidelines say "the distribution itself may hold particular trademarks. It is not a problem if modification requires removal of these trademarks, as long as they can readily be removed without losing functionality." (See http://www.gnu.org/philosophy/free-system-distribution-guidelines.html) Remember — copyright law was designed (at least in the US Constitution) to promote authorship and art, and covers the details of expression of a work. Copyright licenses like the GPL cover the copyright aspects of the source code, and a person’s ability to copy, change, redistribute, and redistribute changed copies of the source code. (The so-called "Four Freedoms" of the GPL.) Trademark law, on the other hand, was not intended to enable consumers to know that the products they are buying or using are of a particular quality and are not imitations — in short, trademarks are about consumer protection. As such, trademark licenses don’t deal with source code — they deal with registered marks, and a person’s ability to use them. (Information on an interesting legal case out of Germany, where the courts there also found that the GPL doesn’t convey a trademark license, can be found at http://www.lexology.com/library/detail.aspx?g=5b0c0785-3eac-4cbc-ad08-2afba447b1e3.)
Last but not least, since you’re insistent on referring to section 7 of the GPL, I’ll point out that section 7 of the GPLv3 specifically calls out several restrictions that are *specifically* allowed, including subsection c (Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version) and subsection e (declining to grant rights under trademark law for use of some trade names, trademarks, or service marks). In short, I hope you’ll see that just because a program is licensed under the GPL, that *copyright* license doesn’t grant the end user an automatic *trademark* license to use the trademarks in the same way that the end user is able to use the source code. And sorry, the trademarks don’t count as "source code", even if images of the registered mark are included with the source code. It doesn’t work that way. For a more complete explanation, I strongly suggest you read an article entitled "Passport without a Visa: Open Source Software Licensing and Trademarks", available at the International Free and Open Source Software Law Review website at http://www.ifosslr.org/ifosslr/article/view/11/37 as well as "Who Owns the Project Name?" at http://www.ifosslr.org/ifosslr/article/view/87/159.
So go ahead, file a legal brief and try to drag Red Hat into court over this if you’re so inclined. But if you think that’s really going to be effective, I strongly suggest at least taking the time to read a few of the articles I’ve posted here to brush up on trademark law, and hopefully not conflate trademark law with copyright law. And if you think a legal fight is going to be less effort than rebranding a distro (or working with a distro to make sure you’re not violating trademark guidelines), I’d say you don’t have a clear understanding of the technical side of building a distro. I’d be happy to show you how easy it is to rebrand Fedora, and I can’t imagine that CentOS would be that much harder. Otherwise, I’m looking forward to seeing more case law here in the US (and abroad too, but as a US citizen, I’m more interested in US case law) around both copyright law and trademark law and how they apply to free and open source software.
[WM: Hi, Jared. Thanks very much for your comments. As my previous responses make clear, we’re not looking to sue anybody, especially Red Hat. I share your view that they have done an incredible amount of constructive work in and for the open source community. I haven’t met most of the people you mentioned, but if you think they’re great people, that’s good enough for me. We want to work this out; however, there are serious trademark issues concerning the CentOS mark. I’ve previously written about it so I won’t repeat it here. The licensing model also is problematic. It directly conflicts with GPL2. Much of your analysis is based upon GPL3 which does exempt trademarks from the license. GPL2 controls in the current situation. That is the way CentOS was licensed. GPL2 prohibits the use of trademarks and copyrights as a means of deterring copying or modification of code released under the license. The fact that GPL3 allows the trademark exemption is one of the primary reasons that few are using the GPL3 license. If you will review the comments that have been made since this article was released, I think it addresses many of the concerns you have raised. Along with other Asterisk aggregations, we have been operating under a set of understandings with the CentOS development team for nearly a decade that were basically turned on their head in January of this year. Like you, I hope we can work this out in a way that benefits everyone, and we would welcome your participation in discussions to make that happen. ]
Having given Jared’s comments some additional thought, let me add the following. First, Red Hat has retained and controls a majority of seats on the new CentOS board to which Jared refers. That’s not necessarily a bad thing, but it does highlight that Red Hat is very much in control of the board’s future actions, and everyone on the board knows it either through a pay check or through the majority vote calculus. Finally, as for the CentOS licensing, we merely want Red Hat to live up to the bargain that the CentOS folks made with the FOSS community almost a decade ago. We’ve all relied upon that. Jared’s former employer (before Red Hat) was Digium. They used CentOS in exactly the same way that the rest of us did. That was on Jared’s watch if I recall correctly. And, if I’m not mistaken, Digium still is distributing AsteriskNOW in the same manner, bundled with a subset of CentOS RPMs to provide the necessary LAMP stack on which to run Asterisk. So, Jared, we didn’t just dream this up to irritate people. Read Red Hat’s new CentOS license. It doesn’t jibe with your tweets. It’s a major shift in direction and one that may also have impact upon whether Red Hat is successful in obtaining a registered CentOS trademark. After all, CentOS openly permitted (in fact, encouraged!) use of the mark by everyone for many, many years.