harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [legal] Re: Bringing License arguments to Sun
Date Tue, 22 Aug 2006 21:35:59 GMT
Dalibor Topic wrote:
> On Tue, Aug 22, 2006 at 04:18:48PM -0400, Geir Magnusson Jr. wrote:
>> Dalibor Topic wrote:
>>> Geir Magnusson Jr. wrote:
>>>> Maybe - or just declaring a patent peace or patent commons.  I think 
>>>> that there's nothing wrong with proprietary software, so if they want 
>>>> to keep competing using it, great.
>>> I don't see a point in proprietary JVMs, and class libraries for major 
>>> operating systems, in today's situation.
>>> The only purpose I could see them used for is as a tool for attacks on 
>>> the integrity of the platform through locking in users into proprietary 
>>> extensions.
>> How about performance, either in speed, real-time predictability, memory 
>> usage/footprint, reliability, serviceability, manageabliity?
> I am talking about proprietary extensions, you're talking about memory
> footprint. One has nothing to do with the other. Could we stay on topic,
> please?

I wasn't only talking about "memory footprint".  How about native 
integration with Tivoli?  Proprietary and an extension, and something 
that people will and probably do pay for.

How about real-time GC?  Clearly an extension - the spec says nothing 
about doing GC in real-time - but I bet the aeronautical and military 
industry would pay for something like that...

>> I can see all of these, and none of these are an attack on the Java 
>> compatiblity promise.
>> Sure, they are features that are beyond the scope of the specs, and 
>> sure, you may be "locked in" in the sense you depend on some feature 
>> (integration with your favorite management system), but your programs 
>> are portable...
>>> I don't think the market would be able to sort out a distributor with a 
>>> strong channel, like IBM, that went that route, as our experience in 
>>> Apache Harmony
>>> with code using unspecified sun.* classes shows.
>> LOL.  What experience is that?  What we're doing this is just supporting 
>> what has become the 'de facto' spec from Sun. :)
> No. What we're doing is clapping our hands with forte because Sun has been
> kind enough to announce that they'll open up all of their code base,
> including the unspecified bits, which would allow us, in theory, to
> integrate them, without having to reverse engineer them.
> Do you want to take a bet that the next 'de facto' standard extensions
> will be opened up within 10 years by their owners, or less?
> I don't want proprietary Java vendors to waste our time in the future with
> undocumented de-facto standards around proprietary extensions.

I think there's a big difference with someone choosing to use a base64 
encoder that just happens to be in the sun package namespace because 
they saw someones example doing that, and extensions that are intended, 
designed and marketed to cause some kind of lock in.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message