[illumos-Developer] Closed-bin accords of the OpenSolaris conference... / was: Re: illumos_145 i386 build status

Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de
Sun Aug 8 12:15:06 PDT 2010


"Matt Lewandowsky " <matt at greenviolet.net> wrote:

> Garrett, In all due respect, I think choosing FreeBSD's sed is not necessarily the wisest move at this point. Sun indicated that AST sed is their choice to replace the closed sed. I've not seen solid evidence that Oracle's changed that plan. (If there's been more than communications breakdowns, I'd be interested in links.) If/when Oracle actually replaces the closed sed, Illumos would then have to decide whether to ditch its FreeBSD sed (if you choose it), or whether to have a different sed from upstream. The former choice is a waste of time and effort, and the latter goes against "not forking for forking's sake". (Paraphrase, not actual quote.) Roland and Olga have put a lot of work into a project that's been approved by Illumos's upstream (Sun/Oracle), and w which has made many putbacks over its life, and is on a path to a tangible and worthwhile (if nothing more than an implementation detail to most people) goal. Right now, they may be having issues with communication with Oracle. But they're not the only ones; paying customers are too. In my opinion, choosing a different implementation than Sun/Oracle has already favored should be done only if you have good reason to believe that Roland and Olga's work will no longer be accepted by Oracle. I was under the impression that Illumos was going to try to remain as compatible as possible to upstream ON. The best indication given by upstream so far has been that AST sed would be "the" sed at some point. Bearing these two points in mind, this whole conversation seems silly and bordering upon barnshedding. --Matt Sent from my HTC Touch Pro2 on the Now Network from Sprint?.
>

Matt, we had a proposal for testing from Roland, the software was tested and 
it turned out there are bugs that prevent integration.

We do not have any statement on a possible time-frame for fixing the bugs but 
we at Illumos have the goal to replace closed source applications by OSS as 
soon as possible.

For sed, we seem to have a replacement proposal to use sed from FreeBSD
and for pax we have a replacement proposal to use star. Both programs have been
tested and there are currently no known issues.

For FreeBSD sed, I would like to see a binary that allows testing on Solaris.
If I could test a FreeBSD sed binary on Solaris without problems, I am willing 
to give my OK for integration instantly.

For star, the Solaris ON integration is already available at:

	ftp://ftp.berlios.de/pub/star/alpha/star-on.tar.xz

This archive does not replace anything, it only adds star.

BTW: star already implements most of Sun's extensions and the missing ones will
follow soon after the integration happened. ast-pax currently does not support 
any of the Sun extensions. If you like to replace /usr/bin/pax by star, you 
just need to add a line to usr/src/cmd/star/Makefile to create a link between
star and the name "pax".

I suspect that Oracle currently has no plan to replace the closed source bits 
in OpenSolaris anytime soon. We need to avoid to get into a similar position as
the OGB by waiting om soemthing that may not happen at all. It seems that we
need to find a way for Illumos anyway. Could this be done by the simple rule:
it needs to be available and it needs to be without known issues that may cause
problems for existing users of the software.



Let me add a side note on the CPL (the license used by the ast code ). I know 
that the license is not a result of a decision from David Korn but from AT&T. 
The CPL however is a license that is indented to keep software projects 
separate. There is permission to contribute to the original work:

See: http://www.osscc.net/en/licenses.html#compatibility
http://www.osscc.net/en/cpl.html

but there is no permission to use parts from a CPLd work in other works.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



More information about the Developer mailing list