From mr at sun.com  Tue Dec  4 07:45:41 2007
From: mr at sun.com (Mark Reinhold)
Date: Tue, 04 Dec 2007 07:45:41 -0800
Subject: OpenJDK GB Minutes: 2007/8/23
Message-ID: <20071204154541.ACE771B52@callebaut.niobe.net>

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

-------------- next part --------------

OpenJDK Governance Board Minutes: 2007/8/23
Mark Reinhold <mr at sun.com>

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]

From dalibor.topic at googlemail.com  Wed Dec  5 14:28:23 2007
From: dalibor.topic at googlemail.com (Dalibor Topic)
Date: Wed, 05 Dec 2007 23:28:23 +0100
Subject: OpenJDK GB Minutes for 2007/8/23 posted
In-Reply-To: <20071204154545.36AD31B52@callebaut.niobe.net>
References: <20071204154545.36AD31B52@callebaut.niobe.net>
Message-ID: <47572607.9060405@kaffe.org>

Mark Reinhold wrote:
> The minutes of the third OpenJDK GB meeting have been posted to the
> gb-discuss list [1] and to the web [2].
>
> Please direct comments and questions to the gb-discuss list.  You'll need
> to subscribe first if you haven't already; messages from non-subscribers
> are discarded in order to avoid spam.
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/mailman/listinfo/gb-discuss
> [2] http://openjdk.java.net/groups/gb/2007-08-23.html
>   
Thank you very much for posting the minutes, Mark, and the work
going into compiling them into the very readable form. I'd like to thank
Mark, Roman, Andrew, Christian, Petteri and Matthias, too, for their
questions and input about the OpenJDK TCK license, and Carla for
taking the time to answer them.

cheers,
dalibor topic

From openjdk at jazillian.com  Fri Dec  7 10:05:36 2007
From: openjdk at jazillian.com (Andy Tripp)
Date: Fri, 07 Dec 2007 13:05:36 -0500
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <20071204154541.ACE771B52@callebaut.niobe.net>
References: <20071204154541.ACE771B52@callebaut.niobe.net>
Message-ID: <47598B70.6050206@jazillian.com>

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.
>   
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

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.
>   
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? 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.
>   
Is there a way to find out what the TCK User's Guide says before 
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.
>   
Well, anyone can ship anything they want, they just can't claim that 
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.
>   
I assume that when you talk about what "Sun wants" here, you actually 
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

From David.Herron at Sun.COM  Fri Dec  7 11:12:00 2007
From: David.Herron at Sun.COM (David Herron)
Date: Fri, 07 Dec 2007 11:12:00 -0800
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <47598B70.6050206@jazillian.com>
References: <20071204154541.ACE771B52@callebaut.niobe.net>
	<47598B70.6050206@jazillian.com>
Message-ID: <47599B00.2030408@sun.com>


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



From openjdk at jazillian.com  Fri Dec  7 11:37:48 2007
From: openjdk at jazillian.com (Andy Tripp)
Date: Fri, 07 Dec 2007 14:37:48 -0500
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <47599B00.2030408@sun.com>
References: <20071204154541.ACE771B52@callebaut.niobe.net>
	<47598B70.6050206@jazillian.com> <47599B00.2030408@sun.com>
Message-ID: <4759A10C.30705@jazillian.com>

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.
To be "derived", I would that that number would have to be higher than 
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
>
>


From mark at klomp.org  Sat Dec  8 10:54:09 2007
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 08 Dec 2007 19:54:09 +0100
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <47598B70.6050206@jazillian.com>
References: <20071204154541.ACE771B52@callebaut.niobe.net>
	<47598B70.6050206@jazillian.com>
Message-ID: <1197140049.3134.39.camel@dijkstra.wildebeest.org>

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


From dalibor.topic at googlemail.com  Sat Dec  8 13:00:19 2007
From: dalibor.topic at googlemail.com (Dalibor Topic)
Date: Sat, 08 Dec 2007 22:00:19 +0100
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <47598B70.6050206@jazillian.com>
References: <20071204154541.ACE771B52@callebaut.niobe.net>
	<47598B70.6050206@jazillian.com>
Message-ID: <475B05E3.6000107@kaffe.org>

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

From openjdk at jazillian.com  Mon Dec 10 07:06:41 2007
From: openjdk at jazillian.com (Andy Tripp)
Date: Mon, 10 Dec 2007 10:06:41 -0500
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <1197140049.3134.39.camel@dijkstra.wildebeest.org>
References: <20071204154541.ACE771B52@callebaut.niobe.net>	
	<47598B70.6050206@jazillian.com>
	<1197140049.3134.39.camel@dijkstra.wildebeest.org>
Message-ID: <475D5601.7050801@jazillian.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/gb-discuss/attachments/20071210/6417d3d4/attachment.html 

From mark at klomp.org  Tue Dec 11 14:31:49 2007
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 11 Dec 2007 23:31:49 +0100
Subject: OpenJDK GB Minutes: 2007/8/23
In-Reply-To: <475D5601.7050801@jazillian.com>
References: <20071204154541.ACE771B52@callebaut.niobe.net>
	<47598B70.6050206@jazillian.com>
	<1197140049.3134.39.camel@dijkstra.wildebeest.org>
	<475D5601.7050801@jazillian.com>
Message-ID: <1197412309.3262.24.camel@localhost.localdomain>

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


From Carla.Schroer at Sun.COM  Thu Dec 13 17:15:26 2007
From: Carla.Schroer at Sun.COM (Carla.Schroer at Sun.COM)
Date: Thu, 13 Dec 2007 17:15:26 -0800
Subject: OpenJDK GB Minutes: 2007/8/23
Message-ID: <4761D92E.5020500@Sun.COM>

Hi Folks,

I'm sorry to be a bit late to the party here, Mark Reinhold forwarded 
Andy's questions and comments to me, and I just signed up for the list 
and read this thread.

I am really glad to see interest in these issues.  I certainly think 
they are important and I have spent a lot of the last 12 years working 
on them.  Some of these issues have easy answers, others don't.  I'm 
going to break with convention and respond to some general themes I see 
running through this thread, rather than going item by item.  I hope 
this will provide a bit more background and thinking for the 
discussion.  I also want to encourage folks to continue to discuss these 
issues with the TCK team, once the proposed conformance group is formed. 
Paul Rank is leading the effort from the TCK group.

You can get the JCK (The TCK for Java SE) in it's entirety, including 
the user guide with the compatibility rules, under a "read-only" 
license. it's been available for 3 years.  If anyone wants to look at 
things that way, it's available here: https://jck.dev.java.net/

Graham Hamilton wrote a blog about it at the time that discusses the 
license and why we did it:

http://weblogs.java.net/blog/kgh/archive/2004/12/j2se_compatibil.html

We are also looking at ways to release more TCK information publicly. We 
will use the conformance group page to do this. Stay tuned.

There was a bunch of discussion about people's "intent" when they sign a 
contract.  I'm not a lawyer.  I do work with the legal team here at Sun 
quite a bit, and am often in the role of liaison to legal from 
engineering.  Most contracts are forward looking and try to cover 
situations expected to arise in the future during the course of the 
agreement. It is not uncommon to have some language around the parties' 
intent.  There is also usually language about what happens if either 
party doesn't do what they intended at the time they signed the 
license.  My point is that I don't think there is anything weird about 
setting up a license that makes clear who is eligible and who it's 
intended users are.

This comment of mine seemed to spark a lot of discussion:
    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.

I'll add a bit more explanation.  The folks who have commercial source 
code licenses with Sun have obligations under those license around 
compatibility. Sun has the ability to negotiate a "remedy" if a 
company's implementation turns out to not be compatible.  This has 
happened many times over the years.  The only case that folks know about 
publicly is the Microsoft one, because it ended in litigation.  No one 
in their right mind wants to litigate.  It's a last resort, and in the 
case with Microsoft we had discussed with them on several occasions 
compatibility issues with their implementation.  They made it clear that 
they had no intention of fixing the problems. That's why it went to 
litigation.  In all the other cases, including Netscape in 1997, the 
companies worked with us to create a "get well plan" for fixing the 
issues.  Those plans might include notification to their users, not 
using the brand until the issue was fixed, and other similar things.

So, what did I mean by the "good faith" item above? Really it's about 
the fact that testing something as complex and broad as the Java SE 
platform means that there are some things that aren't testable, some 
things we don't have the resources to write tests for, and there is more 
to testing than just running a test suite once and seeing if everything 
passes.  We had to create a program that was practical for our source 
licensees and for us. We also had to have a program that could be used 
to certify implementations on platforms we don't have and don't know 
anything about, and that may not be publicly available at the time of 
certification (hardware and/or software)  We also felt that the 
implementors themselves were the best experts on their implementations 
and all the configurations of their implementations.  Further, the 
licensees all had to have a support license, so we could work with them 
to answer questions and resolve issues.  At the end of the day, they 
needed to use our tools and tests and rules to test their products and 
then state back to us that they met all the requirements.  As stated 
above, we have recourse if someone makes a mistake or misses something 
that turns out to be an issue.  In my experience, all of our commercial 
licensees since 1995 except one (and you can probably guess who) have 
wanted compatibility, and supported the program.  It was in their best 
interest to ship compatible implementations.  Sure, some mistakes were 
made, but they were mistakes, and they worked with us to resolve them 
when they were pointed out. 

The last item I will comment on in this email is quality vs 
conformance.  The TCKs are about testing for conformance to the specs.  
They can only be as good as the specs, and practically speaking they 
can't test everything in the specs.  So, we do a lot of other testing 
besides the TCKs.  We have a large regression test suite, much of which 
is available in the OpenJDK project under GPL, and more will be over 
time (some things contain 3rd party code or media files we don't have 
distribution rights to, etc.)  We strongly encourage members of the 
community to contribute to this test suite and to use it as well.  We 
also have a variety of additional tests for performance, reliability, 
and implementation specific behavior, not required by the specs.  Our 
licensing model has always assumed that conformance to the specs was 
critical across implementations, but that licensees could and should 
compete on these other factors like performance and reliability.

Thanks for listening.

Carla





From mr at sun.com  Tue Dec 18 10:39:57 2007
From: mr at sun.com (Mark Reinhold)
Date: Tue, 18 Dec 2007 10:39:57 -0800
Subject: CFV: Conformance Group
Message-ID: <20071218183957.64CC32789C4@eggemoggin.niobe.net>

The extended two-week discussion period for the Conformance Group
proposal [1,2] is now over.

Per the interim governance guidelines for Groups [3] the Interim
Governance Board now has two decisions to make, each by a simple
majority vote:

  (1) Shall this new Group be created?

  (2) If it is created, shall it have the power to grant
      Membership in the OpenJDK Community?

GB members: Please cast your votes in replies to this message.

- Mark


[1] http://mail.openjdk.java.net/pipermail/announce/2007-September/000036.html
[2] http://mail.openjdk.java.net/pipermail/announce/2007-December/000047.html
[3] http://openjdk.java.net/groups

From mr at sun.com  Tue Dec 18 10:48:21 2007
From: mr at sun.com (Mark Reinhold)
Date: Tue, 18 Dec 2007 10:48:21 -0800
Subject: CFV: Conformance Group 
In-Reply-To: mr@sun.com; Tue, 18 Dec 2007 10:39:57 PST;
	<20071218183957.64CC32789C4@eggemoggin.niobe.net> 
Message-ID: <20071218184821.9BCE42789C4@eggemoggin.niobe.net>

> From: Mark Reinhold <mr at sun.com>
> Date: Tue, 18 Dec 2007 10:39:57 -0800

> The extended two-week discussion period for the Conformance Group
> proposal [1,2] is now over.
> 
> Per the interim governance guidelines for Groups [3] the Interim
> Governance Board now has two decisions to make, each by a simple
> majority vote:
> 
>   (1) Shall this new Group be created?

Yes.

>   (2) If it is created, shall it have the power to grant
>       Membership in the OpenJDK Community?

Yes.

- Mark

From robilad at kaffe.org  Tue Dec 18 13:44:52 2007
From: robilad at kaffe.org (Dalibor Topic)
Date: Tue, 18 Dec 2007 22:44:52 +0100
Subject: CFV: Conformance Group
In-Reply-To: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
References: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
Message-ID: <47683F54.1010509@kaffe.org>

Mark Reinhold wrote:
> The extended two-week discussion period for the Conformance Group
> proposal [1,2] is now over.
> 
> Per the interim governance guidelines for Groups [3] the Interim
> Governance Board now has two decisions to make, each by a simple
> majority vote:
> 
>   (1) Shall this new Group be created?

Yes.

> 
>   (2) If it is created, shall it have the power to grant
>       Membership in the OpenJDK Community?
>

Yes

cheers,
dalibor topic

From Simon.Phipps at Sun.COM  Tue Dec 18 13:50:09 2007
From: Simon.Phipps at Sun.COM (Simon Phipps)
Date: Tue, 18 Dec 2007 21:50:09 +0000
Subject: CFV: Conformance Group
In-Reply-To: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
References: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
Message-ID: <14641FD0-1813-452D-842E-FD4823CA44D4@Sun.COM>

Yes to both.

On Dec 18, 2007, at 18:39, Mark Reinhold wrote:

> The extended two-week discussion period for the Conformance Group
> proposal [1,2] is now over.
>
> Per the interim governance guidelines for Groups [3] the Interim
> Governance Board now has two decisions to make, each by a simple
> majority vote:
>
>   (1) Shall this new Group be created?
>
>   (2) If it is created, shall it have the power to grant
>       Membership in the OpenJDK Community?
>
> GB members: Please cast your votes in replies to this message.
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/announce/2007-September/ 
> 000036.html
> [2] http://mail.openjdk.java.net/pipermail/announce/2007-December/ 
> 000047.html
> [3] http://openjdk.java.net/groups

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2494 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/gb-discuss/attachments/20071218/adae806e/attachment.bin 

From fabiane at tridedalo.com.br  Tue Dec 18 14:18:04 2007
From: fabiane at tridedalo.com.br (Fabiane Bizinella Nardon)
Date: Tue, 18 Dec 2007 20:18:04 -0200
Subject: CFV: Conformance Group
In-Reply-To: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
References: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
Message-ID: <4768471C.6020709@tridedalo.com.br>



Mark Reinhold wrote:
> The extended two-week discussion period for the Conformance Group
> proposal [1,2] is now over.
>
> Per the interim governance guidelines for Groups [3] the Interim
> Governance Board now has two decisions to make, each by a simple
> majority vote:
>
>   (1) Shall this new Group be created?
>   

YES.

>   (2) If it is created, shall it have the power to grant
>       Membership in the OpenJDK Community?
>   

YES.

> GB members: Please cast your votes in replies to this message.
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/announce/2007-September/000036.html
> [2] http://mail.openjdk.java.net/pipermail/announce/2007-December/000047.html
> [3] http://openjdk.java.net/groups
>
>
>   

From dl at cs.oswego.edu  Wed Dec 19 03:49:45 2007
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 19 Dec 2007 06:49:45 -0500
Subject: CFV: Conformance Group
In-Reply-To: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
References: <20071218183957.64CC32789C4@eggemoggin.niobe.net>
Message-ID: <47690559.5010700@cs.oswego.edu>

I vote yes to both.


Mark Reinhold wrote:
> The extended two-week discussion period for the Conformance Group
> proposal [1,2] is now over.
> 
> Per the interim governance guidelines for Groups [3] the Interim
> Governance Board now has two decisions to make, each by a simple
> majority vote:
> 
>   (1) Shall this new Group be created?
> 
>   (2) If it is created, shall it have the power to grant
>       Membership in the OpenJDK Community?
> 
> GB members: Please cast your votes in replies to this message.
> 
> - Mark
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/announce/2007-September/000036.html
> [2] http://mail.openjdk.java.net/pipermail/announce/2007-December/000047.html
> [3] http://openjdk.java.net/groups
> 


From mr at sun.com  Thu Dec 20 20:35:22 2007
From: mr at sun.com (Mark Reinhold)
Date: Thu, 20 Dec 2007 20:35:22 -0800
Subject: CFV: Conformance Group 
In-Reply-To: mr@sun.com; Tue, 18 Dec 2007 10:39:57 PST;
	<20071218183957.64CC32789C4@eggemoggin.niobe.net> 
Message-ID: <20071221043522.3260166C3@callebaut.niobe.net>

> From: Mark Reinhold <mr at sun.com>
> Date: Tue, 18 Dec 2007 10:39:57 -0800

>   (1) Shall this new Group be created?
> 
>   (2) If it is created, shall it have the power to grant
>       Membership in the OpenJDK Community?

Thank you for your prompt votes.

For the record, the GB has voted unanimously in favor of both motions.

- Mark