Stephen Hahn wrote: > Well, this seems like an entree to make my economic point. We > cannot > staff each OSS integration effort such that it could modify a > significant subset of commands (or the system) to meet policies > and/or > advised changes on initial integration; the freeware team is at best > able to choose to ship or omit components.
I will add that the authors of the open source software do not want redistributors to make independent changes to their code aside from the minimum necessary to compile the code on a new platform. The authors end up having to deal with the issues that are created when misinformed changes are made to their code. If there are bits of Solaris policy that would be enhanced by an alternative implementation within an OSS project, then the change requests can be sent upstream. Changes based on sensible policies (i.e., those that reduce complexity or improve performance) are usually adopted even when they are platform-specific. I think the ARC should understand that attempting to pick and choose from open source alternatives while making changes to those products is not a feasible course of action. It is okay to do what the case suggests and install the original OSS product in a location that can be selectively included in paths. It is also okay to take an OSS product, rename the product and all of the interfaces, and then place whatever constraints you want on that new product. At worst, that will only waste developer time on the fork and Sun's customers can download the real product from the source. It is not okay to pretend to integrate someone else's product, including their names, while not actually doing so. That results in costing the original developers' time and reputation. Apache would consider it a trade name violation. I hear a lot about Solaris policies and how so-and-so would violate some ancient criterion learned from the olden days (invariably, the ones involving Solaris 1-2 transition history). I don't hear much about the goal of improving Solaris as a platform so that non-Sun developers will consider actively supporting it again. The benefits of having built-in support for GNU coreutils should be weighed against the cost of duplicating some features in the overall operating system. I think it is a clear win, even if it would increase the cost of export checks or FIPS compliance (which I highly doubt given the legal-centric nature of those processes). In short, I agree with Stephen's assessment that, given the potential technical conflicts have been addressed by the case, the remaining decision is economic in nature: does Solaris want to tradeoff the benefit of having a working coreutils versus the cost of duplicate code? Cheers, Roy T. Fielding <http://roy.gbiv.com/> OpenSolaris CAB
