Am 27.09.2011 12:06, schrieb Markus Slopianka:

...

open-slx is planning an SLE 12 clone with the completely retarded name Balsam Enterprise, although I don't know if they plan that with community participation.

According to the first announcement they are planning exactly the same business model as SLES but just a few bucks cheaper. "Kunden, die Support und Maintenance benötigen, sollen zudem entsprechende Leistungen bei open-slx ordern können."

Honestly: No, this is not my intention. Of course, we all want to do good business, and as I said this could be optional - I really want to see this community controlled (with some guys for admin-stuff, tracking, etc.) - not company controlled (similar to what openSUSE does). open-slx simply looks to me as it wants to copy SLES, rebrand it, and make money of it. It is a business model, but none I would like to support. And BTW: Roadmap says SLES12 is to be released in Q3-4/2013[1]. Really: I want to get something done earlier, since open-slx could only start their work probably somewhere in 2013 (when the first betas come up if they really do) ... ;) @Wolfgang: Thx. I really appreciate your help! - mike [1] http://www.slideshare.net/NOVL/suse-linux-enterprise-technology-roadmap -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Dienstag 27 September 2011 13:01:44 DenverD wrote:

what is "retarded" about that?

It's name for beauty products. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Hi,

If you _really_ want to do it, you should first open a concept. You´re interested in doing it, I also would like to see such a system, and I think there also other people who wants to get into this.

In fact: I'm working on a concept already. Good to know that it is not only my point of view that this is something people would like to see.

But we all know, /how/ difficuilt it is to create an enterprise system, even if you just "branch" an existing one. Remember that you have to remove all brandings because this might could hurt SUSE and they will hurt you, if you do it :-)

Full ACK. It is a hard job. I've seen the guys at CentOS doing this, and I've seen also the typical ressources (such as buildsystems) as one bottleneck. The branding issue is in fact one very important (if not _the_ most important ;)) thing. One of the first things I am up to is to check the license on all packages within SLES, since there will be some packages which can not be included out of the box.

On the other hand, what is your motivation to create such a project? You don´t seem to want money, so, just for fun? Then I really would suggest you to join the evergreen project, even if it isn´t 100% the same as SLES. You have the force to change it, by supporting the project.

If even Wolfgang (as maintainer for Evergreen) is interested on this one I really think I'm moving a good direction. He himself stated, that he originally wanted to make a SLES clone. Really: It's a hard job, and you bet this will not be done within weeks or even months. Such a process is something you could rather calculate in quarters (if you really are into on this one). About my motivation: It's a mixture between fun and "business", but more for fun. Business is not what you may think from my side - It's about the motivation to get SUSE respinable also for complete different distro rebuilds, etc. There are companies out there which would love to use a SUSE-based distro, and in fact I want to rebuild a rock-solid SLES with no regulations, obligations or anything else on it. I mean, isn't this is what OSS is all about? As I said, all of this should not do any harm to SUSE at all. I love SUSE, probably will always do - I also have good contacts to SUSE employees and really admire all work they do and would never risk to get into a bad situation with them. For the fun side: Hey, how often do you have the chance to really something cool and have people asking for it? ;) Additionally: SUSE Studio (or kiwi in specific) is one hell of a nice piece of software. But what are the problems people will be facing with it: Yes, you can build with openSUSE, customize down like whatever you like, but sooner or later you will get into that specific update-problem (repos, etc. what I've mentioned earlier) - If you take SLES and you want updates: Go and get a subscription. About the pricing: SUSE in my opinion is cheap, really cheap (maybe even too cheap - my honest opinion) - But it is just too expensive if you might want to respin something with a rock solid basis (!and!) want to redistribute it. I know this fairly well, since about 4 years ago I've been in development with an asterisk-based appliance. Realistic I had 2 choices: CentOS and openSUSE, guess what I've taken. I bet you took CentOS - nope. I took openSUSE however this was really a pain in the a**. There have been updates which simply caused major changes and therefore we had to work around it in numerous ways. With SLES (or a clone of it) you might also have issues, but by far not at a comparable frequency.

Also, I guess that there dozens of people who would like such a project, but who haven´t the time or who don´t want to support it, because they have enough to do with openSUSE or/and they are working for SUSE.

I've taken this into account. I have no idea on how SUSE would handle this. Really, no idea. But I also have to make clear: My business day is >12 hours mostly, but my decision to do this is something I really have been thinking about. I had about 3 drafts already done to send to this list (the first time over a year ago) - Now I regret I hadn't done it before. As I said: This all should be about community - The same way with openSUSE, if people are dedicated and like what they see, they might go for it and help. So nothing really new here. I have no idea how much this might attract people, however: CentOS proves it _can_ work. What I offer to do is providing infrastructure, taking a look on legal issues, building a base system and providing the community with everything with as much time and ressources I can. As this might grow this concept might be something you have to think about after some time of course (since nobody can spend endless ressources for nothing), but there must be some way to start - And correct me if I'm wrong, but you have to start somewhere - and if this works out well it'll just be another community OS with maybe some companies backing infrastructure, etc.

I would suggest you to wait what open-slx is doing *or* to use SUSE Studio (____but____ you have to remove ***all*** branding and other non-free things. This will really be something I don´t wanna do, because it´s so f..... difficiult to do.)

No. As I said before, open-slx is not an option for me. And why should we wait? Is there any reason? I know, we IT guys can be called lazy at some point, but at least I'm not too lazy to wait for somebody else doing the job. Who knows: Maybe they'll branch off from us at some point. That in fact would be funny - just kidding.... ;)

hope this helps,

It does, really - The title "RFC" was screaming for valuable input such as yours. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

...

My idea is to build a SLES binary-compatible distribution completely supported by the community (and optionally supported by companies which are willing to do so) - most of you will probably see lots of similarities with CentOS in this way - And in fact: This is exactly what I intend it to be.

Why?

Another question: how ?

If you want it to be binary compatible with SLES, you will obviously need to get ahold of the source RPMs of SLES. So you need a SLES subscription.

Sorry, but this is not true. Take SLES DVD2-images - there you are. We are talking here about OSS, how do you think CentOS did it? GPL clearly states that you somehow must deliver the sources.

Do you plan to just copy over the source RPMs of SLES (including the SPs and security updates), hack the artwork, and rebuild?

No, as said before: We need to check out the license of each and every package. This actually gives the resultset of what is possible to be used. Since most of it _is_ OSS, I (at least at the moment) don't see any regulatory problems. My intention is to start with SLES11SP1 Images and work upwards. As GPL clearly states that redistribution _must_ be done (in short), updates should not be an issue. But, yes I have some SLES subscriptions, so at the moment this is not the breaking point. The short term agenda would be: - Build up secondary OBS infrastructure - Clean rebuild (non-public for the initial work) of the packages including original artwork (For example original opie rpm-rebuild results in a compile error) - Replace all Artwork, Deep check all packages - Create ISO-Builder Process - And lots of other tasks (just writing the list)

[...]

...

- Yes, I do know about openSUSE Evergreen, but it lacks some points I've mentioned above like "Enterprise Features", 1-on-1-("binary")compatibility with SLES and the great quality work by SUSE to get SLES certified by OEM's etc. - and no one really points its OBS tree to build against Evergreen, it points it to major channels like SLES11, SLES11SP1, oS11.4, etc.

Not having the many repositories in OBS build against Evergreen 11.1 or 11.2 is indeed an issue. But something that can be taken care of independently of your approach.

Is it about "LTS" or is it about binary compatibility? Or both?

Both.

If so, why do you want binary compatibility with SLES?

Fairly simple, if you as a system engineer want to install/upgrade/test something you traditionally test your stuff _somewhere_. _Why_ should somebody buy a SLES for such tasks? And why is it a bad idea to also be capable of using OBS SLES11-rpms on such a clone? Or let me turn this question: What is so bad about it?

...

- No, I do not want to work "against" SUSE or anything like

This discussion has taken place already ~ 2 years ago. I took it up to discuss this matter with Gerald Pfeifer.

The situation back then, and I don't think it has changed, is that SUSE makes a non negligible part of its income through the subscription-only licenses -- that is, just the software, without support.

I guess you are talking about the upgrade subscription, right? However, as GPL clearly states that you cannot charge anything for the Software itself, you actually pay for the "service around packaging, power, ethernet - simply infrastructure and update service".

I don't have numbers, and I don't want to, nor would I get them ;), but if there is a free of charge, binary compatible clone of SLES out there, it could potentially hurt the income of SUSE (at least as far as SLES is concerned).

Why should it? Would you just switch over to SLES? At least I wouldn't. Critical and business related systems ("production systems") should never run on such "only community-supported" OS, not even CentOS. Even Canonical provides professional support for Ubuntu - This lets them also be a viable solution - But Debian for example: Well _if_ you use Debian on production systems you traditionally have the qualified staff to handle the problem. A colleague of mine _is_ debian maintainer and I was suprised that in Etch 4.0 there was a _major_ bug with the openssl-lib in combination with perl. Bad stuff. For us not too bad, since he could get that upstream pretty fast. For customers: Have fun. With SLES and RH you have support, somebody on the phone or via mail, you have first class engineers to your availability, doesn't matter how deep you are in package "a", "b" or "c". This is the reason where I think that SLES is too cheap (just my thought). However it shouldn't be too much higher since RH offers free RHN which also gives you a brief overview of all systems managed (which can only be reconstructed with SUSE Manager (SUSE)~=Spacewalk (OSS)~=Satellite (RH)~=Red Hat Network (RHN). If I want a system to test software (before setting them up on production systems), binary compatibility is the winner. People wanting to redistribute a solid "LTS" variant of the distro they like would then probably also see SUSE more strategical. As I've been doing this business now for a while I can tell you: There are more people moving from SLES to RHEL than the other way round (And this somewhat hurts badly, really). (_Also_) one large reason is that there _is_ CentOS. Believe me, RH benefits from CentOS as well. And I guess (though I don't know) there could be a break-even on loss/profit because of it.

Gerald made it very clear that, because of those reasons, SUSE would not support such an effort in any way, at all. They probably cannot prevent it, but you get the picture.

So you might not want to "work against SUSE", but, effectively, you might actually do so.

I can understand this point. However I'm open to any discussion with any SUSE employee in this topic. SUSE shall not give support on it - but now it comes: They _could_! This is something you also won't hear from RH officially, but there is a division at Red Hat which exactly does support CentOS as well ("Professional Services"). Believe it or not. I hope a former colleague of mine (now at RH) is also reading this list - He could confirm what I'm talking about. In fact, SUSE could even have higher rates for support of this one ("if you really need it") - so you could then upsell even better. To keep this short: I've been thinking a long time about this one (really, really, really did) - and all your thoughts have bugged me more than once as well.

Personally, after that discussion and after reporting about it on the list, I opted out of that initiative because I don't want to risk a single layoff at SUSE because of something like that.

Nor would I want to do any harm. But to be clear: We are talking OSS, SUSE also profits from developers around the world as well. SUSE Manager is in fact an upstream patched Spacewalk with SUSE extensions (a bit simple, but I guess you get the point...)

I'm not saying you shouldn't, you do whatever you want, but you might want to consider what I wrote above. And maybe check back with some people (e.g. with Gerald) to have their opinion -- at least, as long as you don't want to "work against SUSE".

I clearly do. Gerald: I invite you also for a beer so we could also discuss this one... Nuremberg? Munich? You tell. Maybe cdegen is a good option as well.

...

that. The complete opposite is the case: Without SUSE this would not work well. In fact I really think SUSE also can profit from a community base around the SLES packages. Take a

Well, without SUSE this would not work well. So why reuse their work without them having a financial retribution? You said yourself that the subscription-only licenses are really cheap.

As I've written: They _could_ have financial retribution, if they want to - maybe not for the updates, but very much likely for support (which should be more expensive of course) and professional implementations (consultants at the customer, etc.). Yes, they are. For server-systems you just want deployed somewhere. Customers are willing to pay, this is what I can say so far. You wouldn't get the hardcore gentoo/debian-fanatics - they live in their own tombstones (just kidding) - but if customers would realize if they would have to pay more in case of something _not_ working with _no direct_ support attribution (calls, tickets, etc., typical: you broke it - you fix it stuff) - they will see the value added to SLES and still buy it. It won't be much of a difference from openSUSE in that way.

...

look at CentOS - Does it really hurt RHEL? I don't think so,

Ha, you don't *think* so :)

Well, I'm sorry, I don't have my crystal ball with me right at the moment, so I really _can't_ foresee the future. ;)

Look, we probably all believe that CentOS is very beneficial to Redhat. It certainly has been in the past, and people from Redhat have also been saying that off the record.

Jup. Agree.

*But* there is no proof whatsoever that it has been the case, or that it would be the case for an "open SLES clone". No proof, no numbers, nobody can tell.

Well, why should they have a problem? http://linux.slashdot.org/comments.pl?sid=349751&cid=21234239 - ok - yes - 4 years ago - but what should have changed since then? RH is just like SUSE a company not just investing as also taking profit from the whole open source model. I agree: Nobody can tell for real, since we simply don't have the possibility to take a look at parallel timelines for specific events .... ;)

And, actually, nowadays, Redhat isn't really all that fond of CentOS anymore.

Well, as far as I've been working with them I can simply say: They tolerate each other very well, since (please read the link in terms of "Gateway drug"). They might not never communicate on their relationsship to each other deeply, but I guess tolerating each other (now over YEARS) is not a bad thing. _If_ RH would have had any problems with CentOS in the past I think they would have done something. In fact I never heard some RH associate speaking bad about CentOS either behind the doors or in front of a customer. And RH being also willing to support CentOS ("in extreme cases" or "more expensive" or "only through professional services") is something which is a good model.

...

at least not to a major extent. Lets get the facts straight: If you are in a corporate environment you _will_ (or at least you _should_) buy a SLES. Reasons: Support, Updates, Faster upstream process, tracking, direct contact, etc. But: If you want to build a steady home system which you do not want to upgrade less than every year in a major way or you might want to build a distro fork for special purpose (like for system integrators, etc.) you (probably) wouldn't want to go with the fully blown SLES.

Why binary compatibility with SLES then ?

As I've written: Appliances, Release Cycle, Perfect Test-Platform, and some other reasons as well.

...

- Yes, I see this as lots of work. Please let me know if you are willing to help. ;)

Do you believe it is more work than Evergreen ? Or less ?

(Re-)Building SLES "from scratch" is by far way more work. Especially when you want to provide ISO's with some installer, etc. You need to repackage everything, Evergreen is so far more "value added", not base.

Don't you think that, instead, contributing to Evergreen has at least the potential of creating much more synergies, as it is part of the openSUSE project, on the same infrastructure as the rest of the project (build.o.o) ?

("Sorry Wolfgang"): Take a look at Evergreen, if this would have been accepted that much, this wouldn't only be a one-man-show, and he would have received way more support for this.

I know very well that the current situation of Evergreen is not all that great, because there are barely any people who are contributing to it (and kudos again to Wolfgang). Why would that be different with a fork of SLES ? Why not, instead, try to revigorate Evergreen and contribute there ?

see above.

If you create a fork of SLES, you will not be able to use build.opensuse.org, and you probably won't be able to even _link to it.

hmmm... this one really freaks me out. Since when...? In OBS I can see Debian, Fedora, Red Hat, Mandriva, <you name it>. Why whould a natively compatible distro be handled so differently? - mike -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tue, 27 Sep 2011 18:56:10 +0000, Jim Henderson wrote:

On Tue, 27 Sep 2011 20:46:53 +0200, Michael Kromer wrote:

...

I guess you are talking about the upgrade subscription, right? However, as GPL clearly states that you cannot charge anything for the Software itself, you actually pay for the "service around packaging, power, ethernet - simply infrastructure and update service".

I don't believe this is correct. To the best of my knowledge, the GPL doesn't prohibit charging for the software, but it states that the source must be freely available. The GPL doesn't have a lot (if anything) to say about cost, because "free" doesn't mean "as in beer" in the GPL.

Seems I am correct on this. See: http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney (As well as the other questions present) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On 2011-09-27 21:28:48 (+0200), Michael Kromer wrote:

...

...

...

I guess you are talking about the upgrade subscription, right? However, as GPL clearly states that you cannot charge anything for the Software itself, you actually pay for the "service around packaging, power, ethernet - simply infrastructure and update service".

I don't believe this is correct. To the best of my knowledge, the GPL doesn't prohibit charging for the software, but it states that the source must be freely available. The GPL doesn't have a lot (if anything) to say about cost, because "free" doesn't mean "as in beer" in the GPL.

Seems I am correct on this. See:

http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney

(As well as the other questions present)

Indeed this is something I wasn't aware of - Thanks for pointing this out!

Actually, the only obligation SUSE has with SLES there, to comply with the GPL and other open source licenses, is to make the source of updates available when you have a subscription. As you can't get ahold of the updates without a subscription. The key here is the updates, as the release in itself is available anyway. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf

On 2011-09-27 19:39:28 (+0000), Jim Henderson wrote:

On Tue, 27 Sep 2011 21:32:52 +0200, Pascal Bleser wrote: [...]

...

Actually, the only obligation SUSE has with SLES there, to comply with the GPL and other open source licenses, is to make the source of updates available when you have a subscription. As you can't get ahold of the updates without a subscription.

I don't think that's entirely true either, though - someone has to have a subscription, sure, but AFAIK the GPL doesn't permit SUSE from restricting the distribution of those updates or the source by a recipient of those packages.

So, if I don't have a subscription to SLES but I know someone who does, they are free to distribute any GPL'ed software from their subscription to me if they want to.

If the code is GPL'ed, then the binary and source can be redistributed by anyone who obtains it from SUSE.

Yes, correct, that is what I meant to say, thanks for the patch :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf

On Tue, Sep 27, 2011 at 3:00 PM, Jim Henderson wrote:

On Tue, 27 Sep 2011 18:56:10 +0000, Jim Henderson wrote:

...

On Tue, 27 Sep 2011 20:46:53 +0200, Michael Kromer wrote:

...

I guess you are talking about the upgrade subscription, right? However, as GPL clearly states that you cannot charge anything for the Software itself, you actually pay for the "service around packaging, power, ethernet - simply infrastructure and update service".

I don't believe this is correct.  To the best of my knowledge, the GPL doesn't prohibit charging for the software, but it states that the source must be freely available.  The GPL doesn't have a lot (if anything) to say about cost, because "free" doesn't mean "as in beer" in the GPL.

Seems I am correct on this.  See:

http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMoney

(As well as the other questions present)

Jim

The key feature of GPL for this discussion is any buyer of SLES / updates, must have the ability to get the source. And that source must still have the GPL in place, so the recipient can do anything with it that they want. How useable that source is another question. ie. providing it on paper would satisfy the GPL as far as I know. Fortunately, I've not heard of any company trying to abuse the GPL like that. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tue, Sep 27, 2011 at 03:33:01PM -0400, Greg Freemyer wrote:

How useable that source is another question. ie. providing it on paper would satisfy the GPL as far as I know. Fortunately, I've not heard of any company trying to abuse the GPL like that.

I have, believe me, they are out there, I have the proof of an obfuscated kernel driver that was sent to me as a printout a long time ago. Fortunatly, SUSE is not such a company. greg k-h -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org