Sometimes being the open source software leader means distancing yourself from open source claims. Red Hat has bowed to pressure and improved the way it describes partner software licenses on the Red Hat Exchange (RHX). The licenses of companies such as SugarCRM, Zimbra and Alfresco used to be buried on the RHX site, requiring …
Thought they were extinct...
companies with occasional flashes of integrity are becoming slightly more common. i thought they were all driven out of business a long time ago.
perhaps there is profit to be made from integrity. who'lda thunkit?
during a recent house renovation, we contracted over a dozen vendors. only 4 delivered what they promised (or fixed their mistakes).
so that would be about 70% sleazy, 30% honest. nice to find (occasional) decency. it is quite rare these days, usually replaced by marketing...
corporation != paragon of virtue
Look it's red hat they have done some amazing
work with getting a great many things out of the
OS basement and making them available "for
their own profit" which as a corporation is what
they do what they don't do is represent the
community they are a company their opinions
are their own their goals are those which they
think will make them the most money. They don't
want their distribution of Linux to be a desktop
system there are some this ain't one they cater
to servers almost to the exclusion of all else
it's what they know, so they are enterprise centered
which means among other things they have to be
flexible about such things as licenses, so what? The
people using it are using it to make money I don't
think their motives are OS initiative aproved either.
I see this look they don't actually believe in OS they
are just like us attitude, bullshit they aren't even close
the Microsoft , Oracle , IBM type of corporations
make money by stealing it and slavish dweebs
are stuck licking their nuts if it weren't for red hat we
would have had to work very hard to do the things
they have done for us and all those corporations
that constantly use that OS software believe it or not.
This is an excellent example of some of the
of some of the larger, strategic, problems with open source products. Licensing issues and fighting within the commune are not desirable characteristics in business. While technical advances may give open source advantages over some brandware, they aren't enough to overcome issues like those outlined in the article.
Those in the open source community have to learn to operate like businesses before they can expect to be operating in businesses.
"Licensing issues and fighting within the commune are not desirable characteristics in business."
No, it seems like what is desirable in business is a huge nasty EULA in which everyone who uses your software gets to waive all their rights. After all, the customer is stupid, moronic, probably criminal, and they aren't really buying your stuff so much as renting it, right?
In case you missed the sarcasm tags, that is the major problem with business at the high end. Ethics? What are those?
I have lots of respect for Red Hat, because I have yet to see them cave like some of the other corporations that claim to work with the open-source community.
Use of OS cannot possibly force users (Google or otherwise) to release their builds
"The service providers are able to do this because of an archaic notion of distribution tied to many open source license where running code on a server and delivering a service does not count as distribution, while shipping software on CDs or via downloads does."
Not only archaic but also totally modern. The fundamental intention of open source of all types is that suppliers OF SOFTWARE cannot withhold the source from their customers. If you are not providing binaries then there is no need to provide source. The implied stricture that one must provide your customised version of open source to users of your web site/etc is clearly impossible to define in an OSI contract. Which is why is isnt.
re: "This is an excellent example....."
Your "fighting within the commune" is my "open and honest debate".
There is more than one business culture and process that can be successful, and as the earlier (coherent) comment points out, most of today's business cultures present externally as not giving a stuff about the customer, whatever they might believe or promote internally.
All closed-source licenses have major problems too (I'd argue even greater than any open-source license), but that hasn't stopped them succeeding - mostly because the vendors take an "accept these conditions or go whistle" position. How any rational business person can accept the terms of the Microsoft EULAs defies any rationality in my book, but there we go.
defining open source
is a valuable exercise, but it ought to be an open discussion and one in which all parties are honest about where they are coming from. if it's fair to label products with attribution clauses in their licenses as "badgeware," then what would the appropriate term be for products that require the use of a closed source product in order to get support, as is the case with RHEL, which requires a subscription to the closed source Red Hat Network update system? Perhaps "Ball-and-Chain Ware" or "Hinderware" would fit.
So, let's all ask ourselves - what's worse - badgeware or hinderware? At the end of the day, customers don't care, so this is really just a dispute amongst vendors. Red Hat doesn't like badgeware but loves hinderware. And badgeware providers want to get credit for their work and want to avoid getting ripped off. For my two cents, I think badgeware providers are being more honest.
Deep C Phishing .......
""We are working on creating human readable license summaries similar to what the Creative Commons has done."
Is that an admission, like with some other EULAs, that they are deliberately worded so as to be confusing [non human readable] and convey a reasoning at odds with the true terms of the agrreement, with the said agreement being a probable violation of good practice or even law?
Yeah sounds about right, for having a window on your work is bad enough in some cases, but to be able to phish and steal ITs ideas for third party/personal gain is worse and probably New Wave Industrial Espionage/Intellectual Property Theft, which in some cases could be worth literally billions/zillions.
But beware the Poison Pill Defence which lays the robber baron OS low, naked and fully exposed as an impotent host of a clone.
AI VXXXXine to destroy the Source of Viruses.
"If you are not providing binaries then there is no need to provide source."
The intent behind "Open Source" is not to prevent suppliers of software from withholding the source, it is to facilitate innovation. The entire goal behind licensing a product with an OSI license is that other people will help the author improve the software. If people are choosing to release their software with these licenses for some other purpose, that is their prerogative, but the INTENT is specifically to benefit the greater good of the masses by ultimately providing a better product through the community effort.
To that end, as the author was implying, Google et al are not REQUIRED to 'give back' any of their changes to these projects, because they are not re-distributing the modified products. However, the spirit of the license is such that, you're given permission to use the product gratis, so if you do improve it, out of appreciation, and in an effort to continue the evolution of that product, these companies should send their changes upstream. As noted previously, though, the entire 'community' is based on the honor system. If they choose not to be good members of the community, they do have that right.
Quite a lot of people outside the open source community have a misbegotten idea that open source software and open source licenses were created specifically to 'give the finger' to big business, or some other related silly notion.
Yes, much of the rationale behind the new GPL v3 IS to counter predatory business practices, and some parts specifically aimed at microsoft, but the original intent of these types of license is simply to foster the community development concept... and as the years have shown, aside from some fractiousness within the community, it has been largely successful.
As rejoinder to Greg's attempt at the "tu quoque" fallacy, supra: Completely aside from your comment being entirely irrelevant to the issue of badgeware (as keeping the difference between open source and proprietary code would have merit even if Red Hat were itself a proprietary-software vendor), your premise of it being unlawful to redistribute RHEL without an attached RH, Inc. service contract is simply incorrect. Full source code is available in the subtrees of ftp://ftp.redhat.com/pub/redhat/linux/enterprise/, and all software contents are under (genuine) open source licensing.
There are two non-software source packages: In RHEL3 (the last version on which I've done a full licence audit), these are named redhat-logos and anaconda-images, and have mildly restrictive terms encumbering third-party commercial usage, on grounds of trademark. The corresponding non-software packages in RHEL4 and 5 appear to be redhat-artwork and redhat-logos.
If you wish to have a fully redistributable, binary-format set of the same software, you're free to compile it using your own logos and artwork, not treading on RH's trademarks. Or you can download CentOS, which already does that work for you.
(No connection with RH, Inc.; I just get tired of hearing this misinformation.)
let them have their own license label
If these people want to make money saying they are "Open Source", and piggybacking on all the work of the people who came up with the term, defined the term, publicize the term, and certify the term, then let them actually release Open Source software.
If they want to do something that's not in the spirit of Open Source, as the Open Source people see it, then let them call their more restrictive licenses something else.
It's really very simple. Either play by the rules of what game you're playing, or call your game something something else and go play it by your new rules. Nobody calls baseball by the name cricket, and nobody calls backgammon by the name mancala. There is that little matter of soccer vs. American football vs. Canadian football vs. Australian football all being called "football", but people know to differentiate when there's confusion.
Integrity in business
What I'm seeing here is a situation where Red Hat is getting whaled upon by the OS community and is responding by listing the licenses, but not putting any pressure on the vendors to change their own designation of the software as Open Source. That's not really integrity.
shubin, thanks! We're about ready to remodel our master bath. You've really made me feel good about the whole situation. We're tossing between a turn key and doing the general ourselves. At least some of the people are ones we've used in the past.
I didn't say you couldn't distribute it - I said you couldn't get support without RHN.
I'd bet my right arm I'm right about that. If I'm not, ok, fine I stand corrected.
Disentangling source packages vs. binary packages vs. support contracts
Greg's original post had claimed that RHEL "requires a subscription to the closed source Red Hat Network update system". Nope. For reasons cited, this is not true: You can get the full distribution at any time in source RPM format (including the two slightly proprietary non-software packages), without any subscription at all. It's on the public ftp site. You can also get the distribution in built binary format (but with substitutes for RH's trademarked logos and artwork) from CentOS and others.
As to one's ability to "get support without RHN": That's something different. Red Hat ties its support contracts to RHN -- but (avoidable) support contracts have nothing to do with whether software is open source or not.
One might ask: Is it lawful to get a copy of the RHEL binary packages as built by Red Hat, Inc. (e.g., copies of the RHEL binary ISOs)? As mentioned, the source packages from which those get build include two trademark-encumbered non-software packages. The process of compiling the binary RPMs puts some of the trademark-encumbered logos and images into sundry binary RPMs thus built. So, some subsets of the full binary RPMs set would be subject to trademark-based restriction, e.g., against _commercial_ redistribution that arguably could create brand confusion. This is probably the biggest reason why, in practice, it's very rare to find RHEL binary ISOs, along with the fact that the publisher would be underwriting huge bandwidth bills without the legal right to charge for access -- and the fact that it make more sense for people wanting RHEL without a support contract to just fetch CentOS.
That aside, to the best of my knowledge, it would be lawful. But nothing requires that anyone offer it to you, just as nothing requires that support be offered a la carte on term to your liking