Garrett D'Amore wrote: > James Carlson wrote: >> This isn't the first time such a thing has been discussed, and in the >> previous runs at the problem, the real issue is not the mechanics of >> setting up and maintaining a separate gate, but rather that 99 and >> 44/100ths of the effort is actually a legal review to determine what -- >> if anything at all -- can be released, and under what terms. If there >> isn't enough to maintain the code as the OS evolves, what's the chance >> that there's enough money to do a detailed legal analysis sufficient for >> release? >> > > I'm only talking about resurrecting the bits that are actually in the > open or were in the open at some time. I don't want to get into > questions about "legacy" that requires legal review. (In some cases the > legacy could be "ported" from an alternate source -- such as NetBSD -- > if a suitable Solaris version was never open sourced.)
Then color me baffled. The code isn't actually going away. It's still in the history. If someone can commit to supporting it, it seems like it ought to be a simple matter (community-wise, at least) to bring it right back. Sun doesn't get an automatic trump of what code is "supported," does it? The tougher matter is if you decide to retreat to your own shadow ON gate, then you'll have to deal with all the other projects that are no longer updating the code at issue, because it's "dead" to them. In other words, if the VM guys decide to rewrite their subsystem, you won't magically get updated Ultra I VM code. You'll be on your own. Code that's maintained and "live" in the ON gate is a shared burden; everyone integrating into ON is required to show how they've tested with it, where appropriate. Code that's hidden somewhere else is nobody's responsibility. To bring this back to ARC matters: you're talking about splitting a bunch of consolidation private interfaces across two consolidations. Maybe doable if you have a near-infinite supply of time and money, but probably fairly hard to keep up otherwise. > Can you say "iprb" :-) Actually in "iprb"'s case, everything is ready > to go now, we got all the legal approvals, but the Oracle acquisition > has thrown a wrench into the works, and I can't submit the RTI until an > *Oracle* lawyer approves it. I was actually thinking about the SPARC "se" driver. But, believe me, I don't want to know the details on "iprb." :-/ -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
