OpenJDK GB Minutes: 2007/8/23
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
OpenJDK GB Minutes: 2007/8/23
by Mark Reinhold
::
Rate this Message:
Attached please find the minutes of the first meeting of the Governance
Board. The minutes are also available on the web: http://openjdk.java.net/groups/gb/2007-08-23.html Respectfully submitted, - Mark OpenJDK Governance Board Minutes: 2007/8/23 Mark Reinhold <mr@...> The third meeting of the OpenJDK Governance Board took place via conference call on Thursday, 23 August 2007 at 15:00 UTC. The topic was the OpenJDK Community TCK License, which had been announced two weeks prior. All GB members were present: Doug Lea, Fabiane Nardon, Dalibor Topic, Simon Phipps, and Mark Reinhold. Carla Schroer of Sun, who was deeply involved in the crafting of the new license, joined the call in order to answer questions and provide context. The meeting was essentially a long question-and-answer session, with no agreed resolutions, so these minutes are structured in a Q&A format in the following sections: 1 License-application process 2 License eligibility 3 Running the TCK 4 Certifying a platform implementation 5 Confidentiality 6 Miscellaneous On the whole the GB membership was pleased with the new TCK license. Most members would like to see the TCK itself open-sourced in the long term, and also made available to certify any platform implementation rather than only those substantially derived from the OpenJDK code base. The license was, nonetheless, generally praised as a big step in the right direction and something with which most Linux distributors, in particular, will be able to work. 1 License-application process Q1: When will the online TCK license-application process be available? There are developers who want to start working with the TCK as soon as possible. Sun's TCK team and the JCP Program Management Office are working on that. It's been delayed a bit by other responsibilities, but it should be done in the next few weeks. [Note: As of early December the online application page is not yet available, but interested parties have been able to execute the license agreement and acquire the TCK by contacting Sun directly.] Q2: How long should it take for someone to receive the TCK once they've submitted an online application? It depends partly on how many people apply; a large number would slow things down. With a moderate number it should be possible to approve an application in under a month. The TCK will be delivered to licensees using the same mechanism aleady in place for Sun's commercial partners. Q3: Is the OpenJDK TCK license meant to be executed by individuals, by organizations, or either? It's written to accommodate both cases. Which one is best depends upon your specific situation. Q4: Suppose that a student at a university is working with the OpenJDK code and wants to get the TCK. Should he sign his own license, or should the university sign for him? What's the best way to handle that kind of situation? Students at universities are different than employees of corporations because they aren't employees of the university and often do not have the ability to control access to university computers. That said, the recommendation is that students sign the TCK license as individuals if they want to put the TCK on computers that they can control. If a group of students is working on a project together then they can sign a single license and fill in the names of all the students working on the project. This could include a professor too, if that's appropriate. In other words, students should act as individuals or as groups of individuals, and install the software on computers they control. 2 License eligibility Q5: What about hybrid implementations, for example what the Cacao folks are working on, where they're using the OpenJDK class libraries on top of their own VM to run on PowerPC or S/390 machines? Would they be eligible for the TCK license? Absolutely! As long as they're GPL-licensed and contain substantial amounts of OpenJDK code then it's in everybody's interest to help them build a compatible implementation. Q6: What does it mean for an implementation to be "substantially derived," as the license says, from the OpenJDK code? For example, would the Classpath library combined with the HotSpot VM count as "substantially derived?" There's no precise definition of "substantial." It can't be expressed in terms of, e.g., a specific number of lines of code. It's more of a principle which says that you can't just take a few small things from OpenJDK into your own code base and claim that your code is "substantially derived." The Classpath library running with the HotSpot VM would certainly count as substantially derived, since the HotSpot VM is a significant chunk of code. Another obvious kind of case is where someone has replaced a few packages with alternative implementations, e.g., to customize for a particular operating system or windowing environment. That would also be considered to be substantially derived. Q7: Suppose it's 2008. The Classpath library has moved to GPLv3, and someone ships it with the VM from Apache Harmony. Does that count as "substantially derived?" No. Aside from the likely absence of significant amounts of OpenJDK code, such a combination would not be considered derived because the OpenJDK TCK license requires that a tested implementation be released under the same license as the OpenJDK code itself, which at the moment is GPL version 2 only. Q8: Would the Harmony class libraries combined with the HotSpot VM be considered "substantially derived?" In terms of the code, yes, this combination would be considered to be substantially derived. To be eligible for the OpenJDK TCK License, however, you'd have to be planning to release the whole combination under GPLv2, and that's likely a problem. Neither Apache, the FSF, nor Sun view the Apache license as compatible with GPLv2, at least not if you're incorporating Apache code as-is. You'd have to decide for yourself whether such a combination is legitimate. 3 Running the TCK Q9: So I get the license application approved, I download the TCK from Sun, and then I can run it locally against my implementation, right? Right. Q10: Are the TCK tests fully automated, or are they interactive? The selection of tests and logging of results is fully automated. Most of the tests themselves are automated, but some of the GUI tests are interactive. When you run an interactive test a dialog box pops up, tells you what to do (e.g., "click the mouse here") and what to look for, and gives you a button to click if the right thing happens. The test harness then records the result in its log file. You can run the automated tests separately from the interactive tests. Q11: How long does it take to run the whole TCK suite? There are tens of thousands of tests in the suite. It obviously depends on the speed of your machine, but running the automated tests on reasonably modern hardware is a matter of hours, not days. Many of Sun's engineering teams have machines set up to run the automated tests every night, so they can review the results each morning. It's also easy to configure the harness to run just a subset of the tests, e.g., those for a specific package or feature, and that's how most developers tend to use it when they're working in a specific area. The test harness, which has been open-sourced in the "JT Harness" project on java.net, has fairly sophisticated test-selection facilities using keywords and other criteria. You can also easily re-run just the tests that failed in your most recent run. 4 Certifying a platform implementation Q12: How complete is the TCK? The primary quality metric for the TCK suite is specification coverage rather code coverage, as for most other kinds of tests. The breadth and depth of coverage varies across the platform. The VM, language, and core libraries are pretty well covered by now; some of the newer areas, especially those further away from the core, are not as well covered. Q13: Does an implementation have to pass every single test? Yes, every single valid test in the suite must pass. You can challenge the validity of specific tests, however, and sometimes tests are thrown out as a result of such challenges. Q14: What's the difference between passing the test suite and actually certifying an implementation as compatible? That's an important distinction. A compatible implementation must meet all the requirements that are spelled out in the TCK User's Guide, specifically those in Chapter 2. It must not only pass the test suite but also satisfy a set of rules that are, inherently, untestable. In other words, there are parts of the certification process that amount to you asserting that, to the best of your knowledge, you're not breaking compatibility. It doesn't mean that you don't have any bugs, it just means that you're not knowingly violating any of the relevant specifications and other requirements. The TCK rules also cover things like how you run the tests; e.g., you must use the provided test harness, unmodified, since the harness itself determines what passes and fails. That's especially important for negative tests, e.g., compiler tests that are not intended to compile and should be considered to fail if they do. The harness contains all that pass/fail logic, so obviously if you could modify the harness then that could change the results. Perhaps the most important rule is the famous "all modes" rule, which requires that an implementation be able to pass in all modes, i.e., in all possible combinations of command-line flags, environment variables, and whatever other configuration data may govern its behavior. It's not sufficient to say that the test suite passes in some configuration, it must in principle be able to pass in all configurations. An implementation that has a flag to disable array-bounds checking, e.g., would fail this rule. Now the practical reality, of course, is that there will be modes that don't pass, e.g., modes that just print a version string and exit, or that provide certain kinds of debugging information. The rules cover all these sorts of special cases and exceptions. Q15: How hard is it to certify a new implementation? A lot of it depends on how that implementation is constructed. Historically Sun has found that when people have something that's almost completely based on Sun's source code, and built in pretty much the way that Sun builds it, then it doesn't take that much effort to certify. When people have written their own VMs or other significant components then the tests will find bugs, and they'll have to be fixed. The time to certify such an implementation tends to be dominated by the time required to find and fix the bugs rather than the time required to run the tests. This can take weeks or even months, if the code in question has a lot of issues. People who replace a lot of Sun's code often find that the hardest part of certifying is in handling error conditions correctly. They'll implement all of the required positive behaviors and then discover that the TCK contains pretty thorough tests for negative behaviors too, e.g., throwing the correct exception for particular invalid inputs. Q16: Have any of Sun's commercial licensees replaced significant portions of the Sun codebase? Yes. Several Sun partners have written their very own VMs, e.g., and the first couple of times that happened some issues in the tests were identified. Some of the testing techniques even had to be changed to eliminate assumptions that'd been true only of Sun's VMs. At this point the suite has been pretty well vetted, especially in the VM and compiler areas, by third parties testing implementations that are only partly derived from Sun's code. Q17: What about source-based distributions such as Gentoo, in which binaries don't exist until the source code is compiled on the end-user's machine? Will the TCK be of interest to people working on such distributions? Claims of compatibility in the Java world apply only to binaries, not to source code. If people working on a source-based distribution make modifications to the OpenJDK code they'll still probably want to get their hands on the TCK, however, to help flush out bugs and to verify that they can build a compatible implementation -- even if that isn't what they'll actually ship in the end. The trademark license, by the way, requires compatibility, so a source-based distribution containing OpenJDK code wouldn't be able to carry the Java brand. Q18: Suppose that the maintainer of an OpenJDK-derived implementation needs to issue an emergency release to fix a security hole. Is it okay to do that without actually running the TCK all over again? Yes. In general Sun tries to handle situations like this in a reasonable, common-sense sort of way. (Sun is in the business of shipping software too, so they understand.) Claims of compatibility rest upon what is essentially a self-certification process. You get the test suite, you get the rules, you look at them. When you think you're ready, you write back to Sun and say, "I certified that this product meets your requirements using this version of the TCK." It's understood that implementors sometimes have to do things quickly, like ship security fixes. Whether to retest is a judgement call that you, as an implementor, would have to make for yourself. If the fix involves a low-level change in the VM that could have broad consequences then you'd obviously want to retest before you continue to claim compatibility. If it's an isolated fix further up the stack, however, and you judge the risk to be low, then you might reasonably move ahead. There's certainly not the expectation that you'll always test every combination on every build; that's just not practical. The expectation is that people are acting in good faith, trying to meet the compatibility requirements, and that they aren't knowingly doing something that would violate them. They're expected to make their own choices around risk, with the understanding that if a mistake is made and an implementation isn't compatible then Sun could ask them to stop claiming it's compatible and stop using the Java logo with it. This is pretty much how Sun has worked with its commercial licensees for many years now. This should scale to the relatively modest expected number of new OpenJDK TCK licensees that will want to self-certify and carry the brand. Q19: If an OpenJDK-derived implementation is still in beta, or is declared final but isn't compatible, can it still be shipped? Yes. This is a key difference between the OpenJDK TCK license and the traditional TCK license available under commercial terms from Sun. Under the commercial license an implementor can ship early-access or beta releases and not worry about compatibility, so long as they don't claim compatibility and don't allow production use. Once they're ready to ship the final release to customers and support it in production, however, then it must be compatible -- otherwise they can't ship it. The GPL, of course, doesn't permit such constraints. An incompatible OpenJDK-derived implementation can go final and be shipped -- it just can't be claimed to be compatible, nor can it carry the Java brand or logo. Q20: Suppose that an implementation depends upon some libraries provided by the underlying system, e.g., the X11 library. When that library is updated then does the implementation have to be re-certified? Claims of compatibility are always made against a specific set of software configurations. An implementation might be compatible on some other, possibly related configuration, or it might not; there's no guarantee. When Microsoft shipped Windows Vista, e.g., Sun had to re-certify its implementations on Vista in order to be able to claim compatibility on Vista. 5 Confidentiality Q21: What about the confidentiality clause in the OpenJDK TCK license? Does it allow for the publication of test results? That is, can one talk about what passes and fails in public? Yes. Sharing the results of test runs is fine, per section 5.1 of the license. You can say things like "I passed all the tests," or "I passed all the VM tests, but failed these seven compiler tests," or you could even, if you really wanted to, publish the entire log of a TCK run. Sun doesn't, however, want people to make comparative claims of compatibility, e.g., "I'm just as compatible as that other guy over there, but not really actually compatible," since that will tend to confuse people about what compatibility means. The confidentiality clause is intended to protect the tests themselves, not the results of running the tests. You can't disclose the details of the tests publicly, though you can discuss them with other parties who've also signed the OpenJDK TCK license. 6 Miscellaneous Q22: How does one go about writing TCK tests? Since specification coverage is the goal, the process is best started by marking up the specification to be tested in order to identify all the assertions it makes, and then figuring out which assertions are testable. Q23: Will Sun accept contributions of new TCK tests? Yes, but since TCK tests are so different from other kinds of tests any contributions will have to meet the standards of the rest of the suite. Given the overhead involved it's probably not worthwhile for people to contribute just a few tests here and there. Sun does, however, very much welcome large sets of new tests, especially for new features. Doug Lea and the JSR-166 Expert Group, e.g., have made significant contributions to the TCK, as have some of Sun's commercial partners over the years. Q24: What other kinds of tests does Sun have, besides the TCK? Sun has several different kinds of tests. The TCK tests are fairly special given their role in defining what it means to be a compatible implementation, being able to run in a wide variety of environments, having to be robust enough to stand up to challenges of validity, and being the basis of various commercial contracts. These qualities tend to make compatibility tests harder to write than most other kinds of tests. Aside from the TCK, Sun also has a large collection of regression and unit tests, written and maintained by the development team. Many of these tests have already been published under the GPL. The long-term goal is to publish as many of them as possible, subject to legal constraints. Finally there are functional, performance, and reliability test suites. Some of these will likely be open-sourced over time although some cannot, again due to legal constraints. Q25: When will the regression/unit-test harness, jtreg, be open-sourced? The jtreg harness is actually just a small plugin for JT Harness, which has already been open-sourced. JT Harness is really more of a harness framework than a simple harness; it has some special features for compatibility testing but can actually be used for a wide variety of different kinds of tests. It's understood that people are interested in an open-source version of jtreg, and Sun does intend to release it, but doing so hasn't been among the highest priorities. [end] |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by Andy Tripp-2
::
Rate this Message:
I have a few questions and comments about the IGB meeting on the TCK...
Mark Reinhold wrote: > 2 License eligibility > > Q5: What about hybrid implementations, for example what the Cacao folks > are working on, where they're using the OpenJDK class libraries on > top of their own VM to run on PowerPC or S/390 machines? Would they > be eligible for the TCK license? > > > The Classpath library running with the HotSpot VM would certainly count as > substantially derived, since the HotSpot VM is a significant chunk of code. > "substantially derived": a) Your own VM with OpenJDK libraries b) Your own libraries with the OpenJDK VM That seems to me like saying that both of these are "derived" from a Honda: a) A Honda engine in a non-Honda car b) A non-Honda engine in a Honda car What's to stop, say, Apache Harmony, from releasing three versions: 1) A GPL2 version, tested with TCK, consisting of Harmony libraries and Hotspot 2) A GPL2 version, tested with TCK, consisting of Harmony VM and OpenJDK libraries 3) Their current product, Apache license, not tested with TCK, but consisting of the *same code* that has been tested with the TCK Also, the explanations given just don't seem to match up with a reasonable definition of "substantially derived". Rather, they're just talking about mixing-and-matching pieces (VM and libraries) of a whole. I think neither a Honda engine in a non-Honda car nor a Honda car with some other engine is "substantially derived" from an original Honda. The engine is just too big of a part of the car, and a VM is too big a part of a JDK. And I think there's just no "deriving" going on here anyway. "Deriving" would be to modify something from the original, not mix-and-match parts. > because the OpenJDK TCK > license requires that a tested implementation be released under the same > license as the OpenJDK code itself, which at the moment is GPL version 2 > only. > I don't see how you can decide whether some release qualifies based on what might be done with it in the future (more below). > Q8: Would the Harmony class libraries combined with the HotSpot VM be > considered "substantially derived?" > > In terms of the code, yes, this combination would be considered to be > substantially derived. > > To be eligible for the OpenJDK TCK License, however, you'd have to be > planning to release the whole combination under GPLv2, and that's likely a > problem. Neither Apache, the FSF, nor Sun view the Apache license as > compatible with GPLv2, at least not if you're incorporating Apache code > as-is. You'd have to decide for yourself whether such a combination is > legitimate. > the future? What if, say, Classpath says they're "planning" a future release under GPL2, but then never actually release it? What if Apache says they are "planning" a GPL2 release, but you don't believe them? > Q13: Does an implementation have to pass every single test? > > Yes, every single valid test in the suite must pass. You can challenge the > validity of specific tests, however, and sometimes tests are thrown out as a > result of such challenges. > How will this challenge process work? For example, the "spec" (javadoc) for the DateFormat.equals() says something so vague that virtually anything should pass the test. Assuming that the test actually tests something, and assuming that some implementation fails, what happens? Does "thrown out" mean the test is actually removed from the suite, or is the test case fixed to match the spec? If the test case is fixed, is the implementation considered to have passed in the meantime? If it's the spec that's to be fixed (which could take a very long time), what's the status of the implementation in the meantime? > Q14: What's the difference between passing the test suite and actually > certifying an implementation as compatible? > > That's an important distinction. A compatible implementation must meet all > the requirements that are spelled out in the TCK User's Guide, specifically > those in Chapter 2. It must not only pass the test suite but also satisfy a > set of rules that are, inherently, untestable. In other words, there are > parts of the certification process that amount to you asserting that, to the > best of your knowledge, you're not breaking compatibility. It doesn't mean > that you don't have any bugs, it just means that you're not knowingly > violating any of the relevant specifications and other requirements. > actually licensing it? The reason I ask is that its wording here is crucial. Historically, C and C++ implementors have worked hard for years on standards to ensure that they're not "breaking compatibility", and yet one of the major advantages of Java is WORA - that it's compatible across platforms and implementations, while C and C++ are not. So how can someone like me, who wants Java to succeed but has not built my own implementation, figure out whether this is just "the C/C++ standards process all over again" or something better? One good example here is keywords. Both the C/C++ standards and the JLS specify a list of valid keywords. But they do not say "...and these are the only keywords". This was a key issue in the MS trial, where MS added their own keywords. Isn't it reasonable for the general Java developer community to know what this TCK User's Guide says? For example, I wouldn't dare try another implementation unless I know that the other implementation has no additional keywords. The TCK User's Guide may ensure reasonable compatibility, but if only licencees can read it, very few people will care. Suppose an implementation feels that they do comply with the TCK User's Guide wording, but Sun disagrees. Then what? Or suppose an implementation feels that the wording should be changed? Than what? Does an implementation have any way to appeal Sun's decision? > > Now the practical reality, of course, is that there will be modes that don't > pass, e.g., modes that just print a version string and exit, or that provide > certain kinds of debugging information. The rules cover all these sorts of > special cases and exceptions. > I don't see how it's possible to have wording that allows things like "debug mode", where arbitrary trace info is printed, but disallows "fast mode" where array bounds checking is skipped. I guess I'll have to take your word for it, if I can't see the TCK User's Guide. > > The expectation is that people are acting in good faith, trying to meet the > compatibility requirements, and that they aren't knowingly doing something > that would violate them. They're expected to make their own choices around > risk, with the understanding that if a mistake is made and an implementation > isn't compatible then Sun could ask them to stop claiming it's compatible and > stop using the Java logo with it. > Sun should know better than to assume that it's as simple as expecting people to be acting in good faith. For example, there was a discussion on the Classpath mailing list a while back about what the various toString() methods should print. There's nothing in the "spec" (Javadoc) covering this, and people naturally wondered "should I print what I think is reasonable, or do I have to go through lots of work to figure out exactly what Sun's implementation prints and match that character-for-character?" These people are clearly working in good faith, but it's completely unreasonable to expect them to have full compatibility. IIRC, it was left up to each developer. Also, some say that the Netscape implementation was less compatible than the Microsoft implementation at the time that Sun sued Microsoft for being incompatible. Most Java developers think that was the right decision, and it was a decision that certainly did not expect that everyone was acting in good faith. And Apache may be acting "in good faith" when it comes to compatibility, but not so much when it comes to releasing under a GPL-compatible license. > This is pretty much how Sun has worked with its commercial licensees for many > years now. This should scale to the relatively modest expected number of new > OpenJDK TCK licensees that will want to self-certify and carry the brand. > Of course, there's the problem that an implementation may start out compatible, become dominant, and then stray. This is exactly what's happened with C, C++, Javascript, HTML, CSS, and other languages. > Q19: If an OpenJDK-derived implementation is still in beta, or is > declared final but isn't compatible, can it still be shipped? > > Yes. This is a key difference between the OpenJDK TCK license and the > traditional TCK license available under commercial terms from Sun. > > Under the commercial license an implementor can ship early-access or beta > releases and not worry about compatibility, so long as they don't claim > compatibility and don't allow production use. Once they're ready to ship the > final release to customers and support it in production, however, then it > must be compatible -- otherwise they can't ship it. > it's "Java compatible", right? And in practice, they could even do that, and it would be up to Sun to take them to court to stop them. > > > 5 Confidentiality > > Q21: What about the confidentiality clause in the OpenJDK TCK license? > Does it allow for the publication of test results? That is, can > one talk about what passes and fails in public? > > Yes. Sharing the results of test runs is fine, per section 5.1 of the > license. You can say things like "I passed all the tests," or "I passed all > the VM tests, but failed these seven compiler tests," or you could even, if > you really wanted to, publish the entire log of a TCK run. > > Sun doesn't, however, want people to make comparative claims of > compatibility, e.g., "I'm just as compatible as that other guy over there, > but not really actually compatible," since that will tend to confuse people > about what compatibility means. > mean that the license has wording to enforce what "Sun wants". Yes? > The confidentiality clause is intended to protect the tests themselves, not > the results of running the tests. You can't disclose the details of the > tests publicly, though you can discuss them with other parties who've also > signed the OpenJDK TCK license. > If a licensee can't disclose the details of tests publicly, how will that work? Say Classpath has a license. Does that mean that Classpath developers can't say "...the TCK checks for such-and-such here, could someone fix that?" on their public mailing list? And who is even considered "a Classpath developer", and so is allowed to see the TCK, considering that to become "a Classpath developer", you just need to go ahead and contribute? > Finally there are functional, performance, and reliability test suites. Some > of these will likely be open-sourced over time although some cannot, again > due to legal constraints. > Suppose an implementation is compatible, but very unreliable. Is there any provision in the TCK (or elsewhere) where Sun can attempt to stop the use of the Java trademark in that case where Sun just wants to protect the integrity of the brand? Thanks for making all these discussions so open. I hope you find these comments useful and not just paranoid ranting. Enough people have struggled with incompatible compilers for decades to justify some paranoia. Andy Tripp |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by David Herron @ Sun
::
Rate this Message:
Andy Tripp wrote: > That seems to me like saying that both of these are "derived" from a > Honda: > a) A Honda engine in a non-Honda car > b) A non-Honda engine in a Honda car > > I think neither a Honda engine in a non-Honda car > nor a Honda car with some other engine is "substantially derived" from > an original Honda. > The engine is just too big of a part of the car, and a VM is too big a > part of a JDK. > And I think there's just no "deriving" going on here anyway. > "Deriving" would be to modify something > from the original, not mix-and-match parts. Hi Andy, This is an interesting analogy. I happen to know a lot of people who do EV conversions -- they are recognizing the car companies aren't cooperating with our desire to have electric vehicles, and some take the step to convert their car on their own to electric drive. And that is essentially what you've described; you start with a car, rip out the gas burning junk, and install clean wonderful electric drive systems. And if you go to http://www.evalbum.com you can see descriptions for hundreds of vehicles people have done this with. Almost always they continue calling their car a Honda or a Suburu or a Ford etc.. On the other hand, Solectria used to do similar conversions commercially. They took regular cars and as a commercial operation converted them to electric drive. They relabeled the cars with their own branding.. but there are trademark issues involved.. The Solectria Force was really a Chevy made vehicle, but Chevrolet probably would be unwilling to grant them rights to use those brand names. This is related to why the Iced Tea project has the name its using. A car, after an EV conversion, the part the passengers sit in is the same.. most of the vehicle operation remains the same as how GM or Ford or whoever designed it. It's using the same steering, brakes, doors, seats, mirrors, etc, just replacing the motor. Getting back to your point... I think that starting with OpenJDK code and modifying it by removing parts and adding in other parts could be taken as derivation. That's certainly our position, that swapping out a part like the VM is a derivation. I think it's a matter of ... ah ... percentages? Perhaps? Maybe it could be described as a metric of 80% of the result is OpenJDK code then it's substantiallly derived? 80% is a number I pulled out of the air, but I think it demonstrates what I'm getting at. - David Herron |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by Andy Tripp-2
::
Rate this Message:
Hi David,
As for the car analogy...certainly the "substantially derived" term is an attempt to separate the potential "OpenJDK with a twist" things from the Kaffee/Classpath/Harmony "clean-room" implementations. Of course people might replace a motor and still call it a "Chevy". The question here is not what term real people use, but what term theGM corporation should put into a contract to avoid a real potential huge problem with modifications. They'll try to separate the "true Chevy's" from the "modified Chevy's", and they might use a term like "substantially derived". I can't imagine that Chevy would let a car dealer put a Chevy engine in a Honda and call it a "Chevy". I doubt they'd let a car dealer regularly replace Chevy engines with Honda engines and still call them "Chevys". > Getting back to your point... > > I think that starting with OpenJDK code and modifying it by removing > parts and adding in other parts could be taken as derivation. That's > certainly our position, that swapping out a part like the VM is a > derivation. > > > I think it's a matter of ... ah ... percentages? Perhaps? Maybe it > could be described as a metric of 80% of the result is OpenJDK code > then it's substantiallly derived? 80% is a number I pulled out of the > air, but I think it demonstrates what I'm getting at. 50%, and you can't have both the engine and the rest of the car being more than 50%. If you allow less than 50%, then some other implementation could just grab a chunk of the OpenJDK and be considered "derived". For example, Classpath could grab the missing pieces that it needs. I'm not saying that's a bad thing, just saying that that doesn't make Classpath "derived" from OpenJDK, certainly not "substantially". Andy > > - David Herron > > |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by Mark Wielaard
::
Rate this Message:
Hi Andy,
Saw some comments on GNU Classpath in here, so I thought I should clarify those points for you. Although I should probably preface it with saying that I think the proprietary TCK is not very interesting to me personally. I like the fact that people can now get access to the TCK to verify compatibility claims and still release their software under a free license like the GPL. That is a huge improvement over the old state. But in the long run we will have to find a way to have the TCK itself as Free Software so it can be included with any free JDK implementation and distributions, developers and users can make sure it is always run for their particular environment. Only that will imho really solve the compatibility claims issues. On Fri, 2007-12-07 at 13:05 -0500, Andy Tripp wrote: > What's to stop, say, Apache Harmony, from releasing three versions: > 1) A GPL2 version, tested with TCK, consisting of Harmony libraries and > Hotspot > 2) A GPL2 version, tested with TCK, consisting of Harmony VM and OpenJDK > libraries > 3) Their current product, Apache license, not tested with TCK, but > consisting of the *same code* that > has been tested with the TCK Nothing as far as I can see as long as they solve the GPL/ASL license compatibility issue (hopefully openjdk and classpath will move to GPLv3 soon to make this a non-issue). This is analogous to the situation with GNU Classpath, gcj, cacao or icedtea, there will still be the source code released versions under the GPL even if people might have tested and certified a specific binary release against the TCK (note that GNU Classpath for example only releases source code). > Again, how can you decide based on what someone is "planning" to do in > the future? What if, > say, Classpath says they're "planning" a future release under GPL2, but > then never actually > release it? You have to trust us :) You can already get the GPLv2 version of GNU Classpath, we have already released multiple versions under that. And I can safely say that we are planning to release a version of GNU Classpath under GPLv3 (+ exception) one day. But that we will most likely wait till OpenJDK also moves to GPLv3 to make collaboration between the projects easier. > For example, the "spec" (javadoc) > for the DateFormat.equals() says something > so vague that virtually anything should pass the test. With software it is not just about the "spec". And I don't think anybody would really claim that the javadoc is a very good spec. Luckily there are other sources of information, like in this case The Java Class Libraries, second Edition, Volume 1 book which has an extensive explanation about the behavior of DateFormat, 30 pages, including a proper description of the equals method. And the final judge is as always real applications. If there is code out there, preferably free software, that show what applications expect then that is what you should test and implement. That is what real compatibility is about. > So how can someone like me, who wants Java to succeed but has not built > my own implementation, > figure out whether this is just "the C/C++ standards process all over > again" or something better? See above. Test your applications against an implementation. And lobby for a proper free testsuite (or contribute to one like Mauve) so all end users can make sure for themselves how compatible it is and how good the coverage of the suite is. > For example, there was a discussion on the Classpath mailing list a > while back about what the various > toString() methods should print. There's nothing in the "spec" (Javadoc) > covering this, and people naturally > wondered "should I print what I think is reasonable, or do I have to go > through lots of work to figure out > exactly what Sun's implementation prints and match that > character-for-character?" These people are > clearly working in good faith, but it's completely unreasonable to > expect them to have full compatibility. > IIRC, it was left up to each developer. The rule for GNU Classpath is to have at least as good and meaningful toString() results as other implementations. Of course every developer is encouraged to strive for excellence and make sure the descriptions are even more useful to end users than in other implementations if nothing is specified. The overriding restricting is that if real world, free software, applications depends on a particular toString() format, even if not specified, then we will fix the classpath implementation to make more applications work. > If a licensee can't disclose the details of tests publicly, how will > that work? Say Classpath has a license. > Does that mean that Classpath developers can't say "...the TCK checks > for such-and-such here, could > someone fix that?" on their public mailing list? As far as I know people are allowed to say that as long as they don't directly disclose the TCK source code for such tests. What will happen in practice is probably that people will be asked to write a free test for a free testsuite like Mauve before such an issue is fixed so that all developers can have access to the expected behavior and no regressions slip in. > And who is even considered "a Classpath developer", and > so is allowed to see the TCK, considering that to become "a Classpath > developer", you just need > to go ahead and contribute? GNU Classpath as project doesn't make any proprietary NDA agreements, that would be outside the charter of the FSF, who is the guardian of the project. It wouldn't be in the public interest if there was some secret cabal of classpath developers "in the know" and others not. So it is up to individuals to decide whether or not they sign the TCK agreement. Since signing it doesn't prevent you from contributing to GNU Classpath and releasing the code under the GPL anyone can do that. Whether the inconvenience of signing an NDA and not be able to discuss it with your peers is worth it is up to each individual. Cheers, Mark |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by Dalibor Topic-3
::
Rate this Message:
Andy Tripp schrieb:
> It doesn't make sense to me that both of these would be considered > "substantially derived": > a) Your own VM with OpenJDK libraries > b) Your own libraries with the OpenJDK VM > The basic idea for me behind that is that one would want to encourage compatibile implementations, by letting them reuse as much code as possible or necessary from the reference implementation, i.e. OpenJDK, and making access to the TCK available under sufficiently liberal terms for such implementations. The licensing of OpenJDK is such, that proprietary implementations based on its code are strongly discouraged, which eliminates the typical reason for deliberately incompatible implementations. > What's to stop, say, Apache Harmony, from releasing three versions: The question you are referring to has been asked with an eye on GPLv3, as Mark Wielaard explained. I wouldn't interpret too much into it, I was just interested in the question from a general perspective. > Thanks for making all these discussions so open. > I hope you find these comments useful and not just paranoid ranting. > Enough people have struggled with incompatible compilers for decades > to justify some paranoia. Sure, no worries. I believe a lot of your questions in your post about the nature of the work with the TCK, compatibility, etc. will answer themselves once the Conformance group is instituted, and starts working, provided the IGB approves the proposal to create the group. cheers, dalibor topic |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by Andy Tripp-2
::
Rate this Message:
Hi Mark,
Thanks for the responses. I should also mention that I'm also not personally interested in alternative Java implementations, but I'm quite paranoid about any of them succeeding. I feel that having multiple implementations, even ones attempting to be compatible, is the core problem with C and C++ today, and I'd like to stay in my comfy little "one Java" world :) Mark Wielaard wrote: I hope Sun is listening here. If Harmony (or any other clean-room implementation) can do this then all the legal attemptsOn Fri, 2007-12-07 at 13:05 -0500, Andy Tripp wrote: ("substantially derived") to stop them from using the TCK effectively have failed. You've been "planning to" deliver a 1.0 release for how many years now? :) I do trust that you want to be compatible, in the same sense that all C vendors want to be compatible. They want to be compatible in the sense that people trust them enough to use their products, but not necessarily compatible enough to avoid having to port to/from their implementation. Obviously, though, the question is for a Sun lawyer: "are you really going to have a legal agreement based on one someone states they are planning?" Heck, I'll state that I'm planning my own derivative of OpenJDK if it lets me see the TCK. Dalibor and I have argued about this extensively in the past. I say the Javadoc is a "user's reference", not a "spec". Very few people will trust Classpath to be compatible just because it complies with the Javadoc. Again, I hope Sun is listening. Thinking that an implementation will be compatible just because it doesn't violate this "spec" is an even bigger mistake than thinking that multiple C/C++ implementations will be compatible just because they all conform to the "standard". Very few people have the time or inclination to test their app on other implementations. In the C/C++ world, that's called "porting", and is hated by (almost) everyone. Again, to Sun: I hope you know what you're doing when you encourage multiple implementations. And of course, that's the problem. You want "good", not "compatible". That's the direction C and C++ vendors have taken, each adding their own "good" (but incompatible) features. Thus, we have porting, and thus the emergence of Java with the promise of WORA. I don't want "good" features, I want perfect compatibility. That's why people prefer gcc and that's why people prefer Java. So you only want to be completely compatible if forced to. Nothing wrong with that, I'd doOf course every developer is encouraged to strive for excellence and make sure the descriptions are even more useful to end users than in other implementations if nothing is specified. The overriding restricting is that if real world, free software, applications depends on a particular toString() format, even if not specified, then we will fix the classpath implementation to make more applications work. the same thing, and that's exactly where we are today with C/C++. I think it's quite a gray area, distinguishing between saying "The TCK compares the day and month" vs. "The TCK says day.equals(other.day) && month.equals(other.month)". Again, the point to Sun is... what are you trying to accomplish here, and does your license really accomplish it? I suspect that this "no disclosing the TCK source code" will not be effective in stopping anyone. I've heard that companies will set up a group for situations like this: one group reads the TCK and writes down, in English, what it says. The other group never sees the TCK itself, but writes the code from the English description. OK, Thanks for the clarification. So no one will ever say "The TCK has been licensed to Classpath" - it would only be licensed to individuals. Thanks again,Cheers, Mark Andy |
|
|
Re: OpenJDK GB Minutes: 2007/8/23
by Mark Wielaard
::
Rate this Message:
On Mon, 2007-12-10 at 10:06 -0500, Andy Tripp wrote:
> I should also mention that I'm also not personally interested in > alternative Java implementations, > but I'm quite paranoid about any of them succeeding. I feel that > having multiple implementations, > even ones attempting to be compatible, is the core problem with C and > C++ today, and I'd > like to stay in my comfy little "one Java" world :) In that case I think you are barking up the wrong tree. The whole point of releasing OpenJDK under a free software license under a copyleft license and compatible with all those alternative implementations around GNU Classpath and friends is precisely to give people the freedom to have multiple implementations and have them as compatible as possible with the "one Java" version. If you want to restrict yourself to your comfy little world please just keep using the canonical "one Java", nobody is stopping you, all that is happening is that more people have the same freedom. Cheers, Mark |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
