Governing Board Minutes: 2012/1/12
The OpenJDK Governing Board met via conference call on Thursday, 12 January 2011 at 16:00 UTC with the following agenda:
- OpenJDK TCK License Agreement delay
- Platform ports in JDK Release Projects
- Infrastructure update
All Board members were present: Jason Gartner, Doug Lea, Mike Milinkovich, Mark Reinhold, and Georges Saab.
Two Observers were present: John Duimovich and Andrew Haley.
The intent of these minutes is to capture the conversational flow of the Board’s discussion and also to record decisions. If you are interested only in the latter then search for the word “AGREED” throughout the text.
1. OpenJDK TCK License Agreement delay
Jason asked whether the length of time between JDK 7 GA and the release of the TCK License was typical. Mark replied that there had been some unexpected delays inside Oracle’s legal department, and that he did not expect that there would be a similar delay for JDK 8. Jason noted that such delays make it difficult to encourage others to contribute. Andrew stated that this license delay blocked Red Hat’s adoption of JDK 7. Mark acknowledged that this was a problem and assured the Board that every effort would be made to ensure that it doesn’t occur again.
2. Platform ports in JDK Release Projects
While the JDK works on many platforms, there are many more that are not yet supported. There was a desire to understand whether the Board feels it useful to have a policy for how new platforms are brought in.
Mark provided some historical background. When JDK 7 was open-sourced in 2007 it relied upon several bodies of proprietary code that Sun did not have the right to open source due to legal encumbrances. Sun provided this code in compiled form, as so-called “binary plugs,” as an interim measure so that others could build the JDK. One of the first successes of the OpenJDK Community was to eliminate the need for these bits of proprietary code, which was done in fairly short order. From that point forward the JDK has been completely buildable, from scratch, by anybody with the necessary hardware, operating systems, and build tools.
Mark proposed a general policy based on this experience: Once an OpenJDK Project is based solely upon open-source code, it should stay that way. If a new Project requires binary components based on proprietary code, it must be a priority for those components to be either eliminated or replaced with open-source code. As an example, the OpenJFX Project is in this position today, and that Project’s stated goal is to eliminate its binary plugs over time. Mark said he’d like to propose a policy on the general discussion list after collecting opinions from Board members.
Jason started by asking whether there are currently any mainline
dependencies on proprietary code. When told that there
weren’t any, he questioned that assertion by asking about
test suites (e.g., the TCK) and build infrastructure. Mark
clarified that this policy was only intended to address
what’s required to build the JDK, not test it. Andrew
remarked that branching and then relying on people to check in
things which require proprietary code or tools tends to lead to
rot; John shared Andrew’s concern. Jason introduced the
example of porting the JDK to IBM’s proprietary AIX operating
system. He noted that there was always the potential for somebody
to build and replace the required binary component; however from
the IBM’s perspective, that hurdle seemed large. Mark
commented that in the AIX case, the binary plug was IBM’s J9
virtual machine. Doug asked some probing questions to determine the
policy boundary. He suggested that
system-dependent files, and conditionals in make files all seem
acceptable in mainline code, but the need for an expensive hardware
or software purchase was not. Jason speculated that the need for
expensive tools might encourage people to replace them with
something free. Mike said that took Eclipse six months to define a
similar policy, and that doing so required the consideration of
many different scenarios.
Georges summarized the discussion by saying that Board members clearly had a range of opinions. It would be useful to have a policy, but it would need to be clear and include examples. Mike offered to forward the Eclipse policy to the Board.
3. Infrastructure update
Georges reported that there had been some public discussion about the requirements and design of the bug system. Implementation of the pilot system was behind schedule due delays around acquiring Oracle-internal security approvals and rack space in the data center. He assured the Board that he’d asked for an updated timeline which would be posted publicly. Doug said that he found it frustrating to see arguments about things he didn’t care about, such as how bugs should be categorized in the new system. Georges reminded him that, while not everyone enjoys such theoretical discussions, they are very important to some of those who will have to use the bug system every single day.
At this point the Board adjourned.