Monday, August 23, 2010

The OpenSolaris Governing Board resigns

It is sad news, the OpenSolaris Governing Board resigned today collectively with the following resolution:

Motion concerning dissolution of the OGB

Whereas Oracle has continued to ignore requests to appoint a liaison to work with the OGB concerning the future of OpenSolaris development and our community, and

Whereas Oracle distributed an email to its employees on Aug 13 2010 that set forth Oracle’s decision to unilaterally terminate the development partnership between Oracle and the OpenSolaris Community, and

Whereas, without the continued support and participation of Oracle in the open development of OpenSolaris, the OGB and the community Sun/Oracle created to support the open Solaris development partnership have no meaning, and

Whereas the desire and enthusiasm for continuing open development of the OpenSolaris code base has clearly passed out of Oracle’s (and thus this community’s) hands into other communities,

Be it Resolved that the OpenSolaris Governing Board hereby collectively resigns, noting that under the terms of the OpenSolaris Charter section 1.1 (and Constitution 1.3.5) the responsibility to appoint an OGB passes to Oracle.

The motion was accpeted without any vote against.

The OGB had not other way, as Oracle did not talk with the OGB since at least April (when the current OGB was constituted). On August, Friday 13th there was a Letter from Oracle that Oracle will shut down collaboration with the OpenSolaris Community. On August 18th, Oracle did the last public to the Mercurial source repository.

The community moves on to the free and open Illumos project.

Tuesday, August 03, 2010

To fork or not to fork

When people talk about OpenSource, they often ask whether a project is free enough to allow to create a fork from the original project. They never ask whether it makes sense to fork. When OpenSolaris was first published on June 14th 2005, people asked whether OpenSolaris is free enough to create a fork, they did not ask whether it makes sense to fork OpenSolaris.

When OpenSolaris was announced by Sun on September 14th 2004, it was announced to become a true OpenSource project with co-development and collaboration between Sun and the community. It could not become 100% OpenSource in the first attempt as not all of the code was owned by Sun. When OpenSolaris did become OpenSource on June 14th 2005, Sun probably thought that this was more for an academic purpose, as important parts for the base of the Operating System where missing. When we did publish the first version of SchilliX based on the OpenSolaris code on June 17th 2005, nobody thought that this was possible. We did not fork as there was no need to fork, we just added missing code from the OSS community and code we did write ourself.

After some years, the community still had problems to contribute into the OpenSolaris code base from Sun. As Sun did publish source and binaries for OpenSolaris on a regular base, nobody was interested in a fork.

Then Oracle bought Sun and stopped publishing binaries for recent OpenSolaris releases and stopped talking to the community at the same time. Now more and more people started to talk about forking, but they felt helpless.

Then a group of former Sun/Oracle employees and people from the community started to work on a truely open OpenSolaris base owned by the community and stored in the open. This group started to replace the closed source bits from Solaris by OSS code. Today this project has been announced under the name Illumos, see

Is this project a fork?

No, we still believe that it is better to keep it as a maintained child of the OpenSolaris source from Oracle as this allows for collaboration with Oracle and that allows to let code flow in both directions.

We however demonstrated that we now definitely can fork in case this will be needed, e.g. because Oracle stops publishing sources.

OpenSource does not live from forking but from being able to fork in case forking could be needed.

Thursday, June 17, 2010

OSSCC clears OSS license jungle

Collaboration between different OpenSource Software groups and projects currently increasingly suffers from a wide variety of OSS licenses. This problem is caused by the imperfect compatibility of the licenses. The OSSCC (OpenSource Software Collaboration Counseling has the mission to foster collaboration between different OpenSource Software groups and projects. The OSSCC amongst others offers to counsel authors with making licensing decisions that allow best collaboration with other projects.

To support such collaboration, OSS authors should select OSS licenses that are compatible with each other and that allow to create greater works based on code from different sources. For better collaboration, it would also desirable to select licenses that allow code flow from and to any project using an OSI compliant license to any other project using an OSI compliant license. As some licenses create a one-way of code flow towards the specific license, licenses need to be selected carefully in order to grant collaboration that is more than a one-way.

To simplify license selection, OSSCC provides the OSSCC license interoperability guide together with a commented list of preferred OSS licenses. See:

Licenses that allow to merge parts of the code from one work into other works are called compatible and support collaboration in the OSS area. When judging, OSSCC also considers problems problems that are caused by permissive licenses (like the BSD license) that does not make free of charge patent grants.

The OSSCC intends to help with gaining legal certainty with collaboration in OSS projects. The statements regarding license compatibility are based on statements from independent lawyers (like Lawrence Rosen, the legal advisor of the OpenSource Initiative and Catherine Olanich Raymond, the wife of Eric Raymond). The OSSCC is proud to present the initial publication of an essay on OpenSource license compatibility from Thomas F. Gordon.

In future, other projects e.g. a platform for translations are planned.

Saturday, October 04, 2008

Does Jim Zemlin harm the Linux Foundation?

Jim Zemlin recently in an InfoWorld article claimed Is Sun Solaris on its deathbed?

In this article, Zemlin only gives Linux and Microsoft a chance for the
future. He then continues with the well known stereotypes we already
read many times before from people who believe the best way to support
Linux is to belittle other OpenSource projects.

If DTrace was a minor feature as Zemlin claims, would FreeBSD, Apple
and IBM adopt it? If ZFS was a minor feature, would FreeBSD and Apple
adopt it? DTrace and ZFS have been adopted by others because the people
behind FreeBSD Apple and IBM believe that they are important
innovations and because the license is free enough to allow them
to use DTrace and ZFS with their OS.

At the same time, some people from the Linux camp still try to hide
their missing will to integrate behind a so-called "license
incompatibility". A license like the CDDL that allows to combine code
under CDDL with code under any other license is supposedly incompatible
with Linux? Do some people from the Linux camp really believe that the
GPL is a non-free license? Well, the GPL is a free license and thus
cannot require other projects to change their license if they are just
delivered together with GPL code.

There is no license incompatibility but a VFS incompatibility between
ZFS and the Linux kernel. A code incompatibility can be resolved if there
is a will.

Some non-open-minded people cannot make a free license like the GPL
non-free. POSIX compliant operating systems (like Solaris) and system
that are similar to POSIX (like Linux) should not be enemies. People
who develop OpenSource software should cooperate against non POSIX
systems like Microsofts OS. People like Zemlin who like to drive a
spearhead between different OpenSource projects have no place in
our world. They should resign to allow other open-minded people to
take their place.

Our OpenSource world does not need Zemlin but visionary people who
sopport OpenSource.

Sunday, June 19, 2005

SchilliX is real now

SchilliX is an OpenSolaris-based live CD and distribution that
is intended to help people discover OpenSolaris. When installed
on a hard drive, it also allows developers to develop and compile
code in a pure OpenSolaris environment.

After 4 months of hard work, the first OpenSolaris based
UNIX distribution is ready for download at

Well, I should mention that the project started in December 2003
with the first discussions with Sun about a Solaris Live CD.
Then in September 2004, there was a OpenSolaris summit in
Santa Clara and the OpenSolaris Piolot started with a growing
number of people (at last ~150) talking about the background.
We needed to find a License and Sun did make a great job
with cheking more than 9 million lines of code for encumberences.

Let me describe what OpenSolaris is and what the differences
to Schillix are. OpenSoplaris is currently the Sun O/N Source
tree for Solaris. This source tree is much more than a kernel
but a few things are missing in order to allow a boot to the
multi user mode. The following pieces of code are missing:

The source is part of the Sun Compiler suite but Sun
did OpenSource a 1993 version for BSD-4.4Lite.
The effort to port a recent FreeBSD version was 5 days.

These programs are free software and needed for Solaris, so
they need to be added

The Netscape LDAP libs
They are needed for PAM and must be compiled from sources...

This lib is a major prerequisite for SMF and needs to be
compiled from sources.

Some of the SMF tools
are part of the Suninstall sources and needed to be replaced.

Some small programs
needed to be devloped to make a CD boot with few RAM possible.

is of couse also needed

The NIC drivers from Masayuki Murayama
are nice to have and have been added

is nice to have and has been added

is nice to have and has been added

is nice to have and even needed for some of the
Sun Replacements. As /usr/ccs/bin/make is part
of the Sun Compiler Sources, it had to be replaced
by my 'smake' that is _the_ OpenSource "make"
implementation that is closest to Sun Make.

The main goal was to implement as much source/binary
compatibility to Sun Solaris as possible. Something
that was not simple, giving the fact of the missing

Load SchilliX from Berlios and enjoy
SchilliX. If you like it and if you like to help
bus as a volunteer, please send me a mail...

Tuesday, June 14, 2005

OpenSolaris is out, SchlliX will be out soon

SchilliX now boots from a split CD (root is mounted
from a ramdisk and /usr from CD). The boot from CD
takes one minute and needs 256 MB of RAM.

The first SchilliX distribution will be published in
a few days.

Saturday, May 28, 2005

SchilliX single user nearly complete

Since yesterday, smf/greenline is up and running and we are
close before getting to a real single user mode. Only one
single service description is still inconsistent and needs
to be fixed.

The network is up and running but still needs manual configuration. Once the issue with ifconfig -a plumb has been
fixed, we will be able to autostart with dhcp from any
supported nic card.

As OpenSolaris goes public next month, I am sure we will be
able to publish the SchilliX version in July.