Mailinglist Archive: opensuse-project (502 mails)

< Previous Next >
Re: [opensuse-project] Balsam Professional & Balsam Enterprise
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxxxxx>
  • Date: Thu, 21 Apr 2011 21:27:37 +0200
  • Message-id: <20110421192737.GJ21543@hera>
On 2011-04-21 16:54:42 (+0200), Kim Leyendecker <kimleyendecker@xxxxxxxxxx>
Am 21.04.2011 16:32, schrieb Jos Poortvliet:
On 2011-04-21 Kim wrote:
That´s the way how the RHEL/CentOS-modell runs.
But not because Red Hat wants that but because they can't stop it.
Of course they can stop it. If you look at the GPL, you only have to
make your source code available to your clients. So, they could do
it so, if they want but with CentOS they get a free bugfinding
community. So why handle it different?

EMAILTOOLONG, yeah, I know.

The next bit is a summary of the "openSLES" endeavour we had
many months ago. If you know the story, you may skip here ;)
Well, yes, they could do that, and that's actually what Novell
is doing with SLES. You need a registration key to get the
package repositories.
When you have a license, you also have access to the source
packages (*.src.rpm).

And that's the loophole: you only need one person with one
license to have access to the source packages and "just" rebuild

Of course, it's a lot more work than that, because it also
involves rebranding a lot, because CentOS cannot ship it as RHEL
(that would be a copyright and/or trademark infringement).

The same can be done with SLES. It was one of the options that
was mentioned when we discussed options for an "openSLES"
(that's really just a codename ;)).

But it would be tedious. It would be a lot easier if we could
have Novell's blessing to do that, as well as direct access to
the patches, the source packages, etc. And also use the OBS
instance on build.o.o to build the distribution.

I took it as a task to ask around and see what could be done,
and Novell's position, at least at that time, but I highly doubt
it has changed by now, was that effectively, having an
"openSLES" would most likely hurt Novell in the short term.
It *might* help spread SLES, but as much as I also believe that
CentOS is a major accelerator for RHEL:
* there are *no* hard numbers about whether and by what margin
CentOS increases the adoption of RHEL
* my personal interpretation from the few discussions I had is
that the "subscription only" (the cheapest option, you get the
software and the updates, and that's it) licenses for SLES do
make up a non negligible share of the revenue that comes from

Hence, there is no guarantee whatsoever that an "openSLES" would
1) not make Novell lose money (which means laying people off)
2) would highly drive up the adoption of SLES

Read again: no *guarantee*, no numbers, nothing. The fact that
CentOS helps RHEL is just an opinion, nothing more.

a SLE Server license costs 290 euro per year, nothing for even a
small company. A desktop license starts at 47 euro/year. Not too

Well, the cost are really low, I have to say, but for this I can
also use openSUSE 11.1 feat. Evergreen. So Evergreen is a harm to
Novell´s business too...

For a business, that's a ridiculous amount of money, peanuts
really. So that can't be the target audience.

For a business with large clusters, yeah, that would be
horrendously expensive, but I'm sure they can work out a more
suitable mass-licensing contract with Novell sales.

For users at home or people who have hosted servers where it is
effectively an important feature to have a long period of
support, such as CentOS or, to some extent, Debian, "openSLES"
might indeed be an interesting option.

But those don't care about compatibility with SLES, and hence it
doesn't matter whether it's an "openSUSE LTS" or an "openSLES".

Binary compatibility with SLES for 0 EUR/USD, well, I'm not sure
what use case that's supposed to be.
If it's just for a development or evaluation phase, you can
already download SLES for free and try it out (without updates,
but who cares for eval and development).

If it's for hosting mission critical services, you totally want
the support contract as well, anyway, and that's what you pay
for. Note that even the full blown support licenses for SLES are
cheap, compared to other options (and cheaper than RHEL,

So the only purpose of an "openSLES" (or "Balsam Enterprise") is
to hurt Novell by taking revenue from Novell.

If someone knows of a different purpose, I'd love to hear about

-o) Pascal Bleser
/\\ -- we haz green
_\_v -- we haz conf
< Previous Next >