On Thu, Jul 06, 2000 at 09:52:09AM -0700, Per Bothner wrote: > First, it is not clear whether the license has any legal meaning at all. > It is publicly available documentation, and I don't know how they > could legally restrict someone from using it to build a clean-room > implementation. I.e. are they just permitting us to do something > we can do anyway? (And of course the legal status of reverse > engineering varies from country to country.)
I agree, unfortunatly these are theories that will ultimately be tested by bringing one set of legal resources against another. In this department, Sun has us at a definate disadvantage. > I could argue the onus is on Sun: If we don't have access to the > test-suite, we can't verify compliance. However, our *goal* is > to comply, and if any discrepencies are pointed out, we will > attempt to fix the problem, to the extent of our abilities. Again, we ultimately have to answer these questions in a court of law. I'm a tremendous Java (the language, the technology) advocate, but the picture Sun has painted for us is fuzzy at best, and fraut with peril. In the end, I think that the best thing to do is a slow migration from Sun technologies (especially new SCSL things) to open standards such as DOM and SAX where we have a foothold. If the community can expand its influence with successful APIs then we have something worth fighting for. This is where I find Apache's strategy of cooperation almost troubling. Integrating silly glommed-on API extensions like JAXP into their systems is a strange move. I find it ironic that Sun (who makes such a fuss about extending their APIs) has turned an Open Source project into a tool for "extending and embracing" the open SAX and DOM technologies. -- ___________________________________________________________________ Ean Schuessler Director of Strategic Weapons Systems Brainfood, Inc. A Devices that Kill People company --- Some or all of the above signature may be a joke
