OpenJDK projects promoting proprietary builds
Dmitri Trembovetski
Dmitri.Trembovetski at Sun.COM
Sat May 30 23:20:21 UTC 2009
Geir Magnusson Jr. wrote:
> Hi David,
>
> On May 30, 2009, at 7:05 PM, David Herron wrote:
>
>> Mark,
>>
>> Please recall that JDK<n> != OpenJDK<n> though for values of n >= 7 the
>> difference is very small. The JDK7 builds have some proprietary bits in
>> them.
>
> Why? For heaven's sake... why?
Because the corresponding open source parts aren't good enough yet and we
don't have enough resources to make them on par with the proprietary bits
although this is what we want in the long run.
Specific parts that I know of are color management, AA shape rasterizer and
font rasterizer.
You must understand that "passing the TCK" doesn't necessarily mean "has
acceptable performance, fidelity and stability".
Thanks,
Dmitri
>
>>
>>
>> It's valuable to the JDK product cycle for JDK builds to have early
>> access
>> exposure so people can report bugs etc. Sun started doing
>> very-early-access
>> releases with JDK6 and the Peabody Project, and early exposure was a
>> purpose
>> of the <project-name-never-to-be-spoken-again> Regressions Contest
>> which I
>> ran in early 2006. (See my java.net blog posting of Jan 30, 2006) I'm
>> sure
>> you can understand the value, right?
>>
>> There would also be value to the OpenJDK project for reference OpenJDK
>> builds to be available. For example to help those like you who are
>> involved
>> with packaging OpenJDK-derived builds. Anybody could do those builds
>> couldn't they?
>>
>> I don't think it's correct to say Sun is "pushing proprietary
>> derivatives as
>> early access OpenJDK builds.." is it? The name JDK7 is distinguished
>> from
>> OpenJDK7, right? Isn't it well known that they are approximately 96% the
>> same and that there are differences in specific areas?
>
> As an interested observer and fan of open and even Free(tm) Java, I need
> to ask why would you want to have this differentiation?
>
> I can understand the need to provide source and/or binaries to
> commercial partners and customers under licenses that aren't the GPL,
> but given your right to relicense the whole thing, the same code should
> be able to be offered under the GPL...
>
> geir
>
>
>>
>>
>> - David Herron
>>
>> On Sat, May 30, 2009 at 12:31 PM, Mark Wielaard <mark at klomp.org> wrote:
>>
>>> On Fri, 2009-05-29 at 22:10 +0100, Andrew John Hughes wrote:
>>>> I agree wholeheartedly, but have to say I long ago ceased to be
>>>> surprised by Sun builds beinge proprietary. Sadly the converse is
>>>> true; I'd be surprised by a Sun build released under the same terms as
>>>> our IcedTea builds.
>>>
>>> And that is indeed what is sad about this. That it seems OpenJDK builds
>>> are actually Sun builds, and by extension such things are proprietary.
>>> And that is what I object to. OpenJDK builds should be just that,
>>> OpenJDK builds distributed under the (GPL) terms everybody in our
>>> community adheres to.
>>>
>>> If a project wants to publish "early access" builds then they really
>>> should if they feel people would like to play with the bits. But such
>>> builds should follow the standard OpenJDK project rules
>>> (http://openjdk.java.net/legal/) that everybody else also uses.
>>>
>>> Going to Sun legal and requesting alternative proprietary terms and then
>>> publishing the code and binaries under non-free software licenses is
>>> just bad for creating a community. It is bad enough that the current SCA
>>> rules around OpenJDK assign all rights to one commercial party, Sun. But
>>> projects then abusing those rights by pushing proprietary derivatives as
>>> early access OpenJDK project builds undermines the whole community of
>>> equals.
>>>
>>> You are right that we have IcedTea to fix that. If you get your packages
>>> through IcedTea (derivatives) you are guaranteed that it truly is Free
>>> Software. But wouldn't it be better if we could say that about OpenJDK
>>> itself? Wouldn't that make the community stronger?
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>>
>
More information about the discuss
mailing list