You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Tim Bray <Ti...@Sun.COM> on 2007/07/12 16:41:31 UTC
TSFKAJ
On Jul 12, 2007, at 3:31 AM, Steve Loughran wrote:
> thinking about this, I can see that Sun's Java SE stack is also
> going to have some fun here. If I were to take their stack, fix
> their networking to be laptop-aware and build it, how can I,
> myself, release that build without verifying that it passes the TCK?
That's the downside of defining Java as "the binary that passed the
TCK". (Of course, there are upsides too.) I had always assumed that
once SE was GPL'ed, there'd be lots of people shipping interesting
and useful deltas that aren't called Java. "TSFKAJ, Toshiba
Satellite U205-S5068 version". -Tim
PS: TSFKAJ = 'The Software Formerly Known As..."
Re: TSFKAJ
Posted by Steve Loughran <st...@apache.org>.
Tim Bray wrote:
> On Jul 12, 2007, at 3:31 AM, Steve Loughran wrote:
>
>> thinking about this, I can see that Sun's Java SE stack is also going
>> to have some fun here. If I were to take their stack, fix their
>> networking to be laptop-aware and build it, how can I, myself, release
>> that build without verifying that it passes the TCK?
>
> That's the downside of defining Java as "the binary that passed the
> TCK". (Of course, there are upsides too.) I had always assumed that
> once SE was GPL'ed, there'd be lots of people shipping interesting and
> useful deltas that aren't called Java. "TSFKAJ, Toshiba Satellite
> U205-S5068 version". -Tim
>
> PS: TSFKAJ = 'The Software Formerly Known As..."
This is the kind of problem linux has, certainly bugreps related to
stuff not working debian-unstable are things to fear, because you are
probably never going to replicate the remote system. What RedHat provide
-admittedly for a fee- is the promise of stability for you to test and
run on, which is one reason why RHEL is popular not just in the
enterprise, but with 'enterprise grade' apps like Oracle DB, and
telco-grade things like HP OpenCall SS7. I wouldnt run those on
linux-steve-nightly regardless of which JRE is hosted there.
One of the differences in Linux-land is there is no barrier to me
creating a new linux distro, but at the same time, the lack of test kits
means there's no guarantee anything works: without RedHat's test
infrastructure, there's no way to show that my build would come even
close to their level of stability. The value is in the brand "Red Hat
Linux" and not "Linux".
-steve
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: TSFKAJ
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 13, 2007, at 8:31 AM, Andrew C. Oliver wrote:
> I bet that the AS/400 has one kick ass sound card!
>
> ...and yet it's JVM presumably passes all the tests ;-)
Yup, its only about $45,000 :)
Re: TSFKAJ
Posted by Steve Loughran <st...@apache.org>.
Andrew C. Oliver wrote:
> I bet that the AS/400 has one kick ass sound card!
>
> ...and yet it's JVM presumably passes all the tests ;-)
>
> -Andy
It probably has something wierd that only takes MP3 files as virtual
punched cards in EBCDIC byte structure.
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: TSFKAJ
Posted by "Andrew C. Oliver" <ac...@buni.org>.
I bet that the AS/400 has one kick ass sound card!
...and yet it's JVM presumably passes all the tests ;-)
-Andy
Steve Loughran wrote:
>
> Interesting. Now, if you want to keep maintenance costs down you want
> to get your fixes back in to the main branch, and no doubt sun would
> like to take on the bugfixes that get proxy support working on kde
> desktops, etc. But nobody likes to take patches from random
> developers. Patches that say "Here's my fix to the proxy code, it
> passes all tests" you'd be much happier. Having a completely open test
> suite makes it much easier, especially if it comes with a set of
> VMware images to emulate reference platforms (or the OSS ones, anyway)
>
> Looking at the IcedTea release, it appears they are stubbing out the
> stuff that is restricted: sound, snmp and bits of AWT. For server-side
> JREs, you probably dont need a functional sound subsystem, and its
> pretty hard to test too -I suspect that the TCK doesn't, not unless it
> requires you to connect audio out to audio in so that it can verify
> round tripping, and even then you can't easily distinguish between a
> loopback in software, a noisy loopback in software and real sound
> hardware. AWT is testable, and the TCK may have something there, but
> you are up against the problem of verifying acceptability of different
> rendering algorithms. Bit-for-bit image comparision works for
> regression testing on identical hardware, but not for testing
> different renderers, which, on windows, can mean different display
> drivers.
>
> -steve
>
>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: TSFKAJ
Posted by Chris Gray <ch...@kiffer.be>.
Hi Geir,
> I think this is cool. It's a shame Sun didn't do this.
It's cool, but IMO it's not a shame that Sun didn't do it: on the contrary,
it's great that others can do it without having to wait until it filters to
the top of Sun's TODO list. Shame maybe that Sun waited so long to make this
possible.
[Re: mauve]
> Yes - also, in Harmony, we have a lot of good tests too. (I remember
> you guys using the GUI tests that Intel contributed.)
>
> We should find a way to make it easy to bring together. Some sort of
> packaging convention or something...
The Mauve framework is so simple that it can be integrated with any other
framework or packaging convention or whatever very simply. It has the
potential to be better than the JCK - in fact in an ideal world it would
already have been better for years. Non-ideal factors in this instance are a
spec not written with testability in mind and the "certification as a revenue
stream" mentality (which BTW is not unique to Sun or JCP).
On the Mika project (and on Wonka before that), we basically use the Mauve
framework and then use a wrapper to run some JUnit tests we inherited. That
approach should work for Harmony too - the main challenge will be to
eliminate duplications without losing valuable tests.
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Re: TSFKAJ
Posted by Mark Wielaard <ma...@klomp.org>.
Geir Magnusson Jr. <ge...@...> writes:
> On Jul 16, 2007, at 5:40 PM, Mark Wielaard wrote:
> > Lets discuss there if
> > you want to collaborate on a free and open collaborative core
> > classes test suite
> > (especially if the jck discussions break down).
> >
>
> Do you think they are going well?
I personally don't have any real discussion going (except for my ritual weekly
nagging about the promised TCK for OpenJDK to which the answer for the last
couple of months has been an unqualified "soon") so I have no idea about that.
Mauve is cool and effective though. Even found stuff in openjdk now that has
been accepted as bugs upstream. And now that the reference implementation is (at
least through IcedTea) also available to the larger free software community
people are fixing questionable tests in Mauve also that in turn lead to fixes in
GNU Classpath. So I think Mauve is going well.
Cheers,
Mark
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 16, 2007, at 5:40 PM, Mark Wielaard wrote:
> Lets discuss there if
> you want to collaborate on a free and open collaborative core
> classes test suite
> (especially if the jck discussions break down).
>
Do you think they are going well?
geir
Re: TSFKAJ
Posted by Mark Wielaard <ma...@klomp.org>.
Geir Magnusson Jr. <ge...@...> writes:
> On Jul 13, 2007, at 8:06 AM, Mark Wielaard wrote:
> > But that was just phase 1. Getting a
> > completely free
> > setup without any proprietary encumbrances buildable and
> > bootstrappable with
> > only free software on GNU/Linux systems. Which is what IcedTea 1.0
> > was.
>
> I think this is cool. It's a shame Sun didn't do this.
Sure if Sun had infinite resources. But as we all know innovation happens
elsewhere :) And it is cool that Sun (finally) made it possible. So I do think
Sun only deserves praise for it. Even when they weren't completely ready they
invited and gave the community at large everything they needed to make it happen.
> > For 1.1 (hopefully out today or this weekend) the stubbed out bits
> > are slowly
> > replaced with full free versions. Crypto (and in particular https
> > ssl support)
> > is now done http://mail.openjdk.java.net/pipermail/discuss/2007-
> > July/000103.html
> > for graphics various efforts are underway either replacing it
> > wholesale with the
> > GNU Classpath awt peers
> > http://kennke.org/blog/2007/07/11/swing-on-gtk-peers-again/ or
> > replacing the
> > encumbered low level graphics and font rasterizers with free versions
> > http://fkung.wordpress.com/2007/06/25/icedtea-graphics/ and
> > http://fkung.wordpress.com/2007/07/06/more-fonts/ there is also a
> > summary of the
> > efforts on java.net
> > http://weblogs.java.net/blog/editors/archives/2007/07/
> > just_out_of_rea.html
>
> This is cool too. Do you have any plan to re-sync w/ openJPA?
Not with OpenJPA. IcedTea isn't something that really stands on its own or that
people believe will be needed for a long time. So it is just a mashup of free
code. GNU Classpath and OpenJDK mainly with some distro specific stuff thrown
in. Contributors are encouraged to submit upstream if they feel the patches are
appropriate (some patches are clearly just to get things bootstrapping). All
IcedTea development takes place on one of the openjdk mailinglists. See
http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions
BTW. IcedTeaa 1.1 was pushed out:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-July/000129.html
> > So if no solution is found for the JCK (openjdk also doesn't have
> > access to it
> > yet, GNU Classpath, kaffe, gcj have asked years ago but never got
> > through all
> > the red tap - this was one of the reasons for starting harmony btw
> > since we
> > hoped Apache would have a lot more experience with that - although
> > accepting
> > NDAs was something most GNU hackers would never agree to)
>
> Serious question - does the FSF have any private lists?
I believe so and I am sure there are people mailing each other privately. But
for example GNU Classpath only has public lists for all development.
Seeing some of the replies to this question I see most people assume you were
making some connection with the NDA comment above. To be more clear about that
comment "GNU Classpath & Friends" are called that for a reason. It really is a
conglomerate of companies, individuals, volunteers, students, company research
centers, overlapping and sometimes competing projects, people working full time
on just one tiny part like the compiler or partime on all the parts. People
working on providing something exactly like the JDK just with alternative
execution models and people doing funny mixes with .net/mono or creating
micro-gcj based languages and runtimes, etc. All communication must be in the
open and accessible for everybody to be valuable. NDAs and especially some of
the restricted language of the JSPA makes this happy interplay between hackers
just a major pain. Especially with a non-centralized, collaborative and
distributed development model that we are all used to.
> > then it might be a
> > good idea to bundle forces and push Mauve forward as the shared
> > testsuite to use
> > for all the TSFKAJs.
>
> Yes - also, in Harmony, we have a lot of good tests too. (I remember
> you guys using the GUI tests that Intel contributed.)
>
> We should find a way to make it easy to bring together. Some sort of
> packaging convention or something...
Sure. As Chris Gray said Mauve is super flexible. So it can be morphed into
anything that works for any project that wants to use it. And it also only has
public mailinglists (see http://sourceware.org/mauve/). Lets discuss there if
you want to collaborate on a free and open collaborative core classes test suite
(especially if the jck discussions break down).
Cheers,
Mark
Re: TSFKAJ
Posted by Sam Ruby <ru...@apache.org>.
On 7/14/07, Andrew C. Oliver <ac...@buni.org> wrote:
>
> >> accepting
> >> NDAs was something most GNU hackers would never agree to)
> >
> > Serious question - does the FSF have any private lists?
> There is a massive leap from having a private list to accepting an NDA.
Be that as it may, it still is a valid question.
- Sam Ruby
Re: TSFKAJ
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Geir Magnusson Jr. wrote:
>
> On Jul 15, 2007, at 5:37 PM, William A. Rowe, Jr. wrote:
>
>> Geir Magnusson Jr. wrote:
>>>
>>> Which brings me back to the question that started my ratholing of this
>>> thread :)
>>>
>>> Does the FSF have private lists?
>>
>> And equally, does the FSF require NDAs? :)
>
> You just argued they aren't equal :)
Of Equal Importance to the discussion at hand.
Not of equal effect or consequence.
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 15, 2007, at 5:37 PM, William A. Rowe, Jr. wrote:
> Geir Magnusson Jr. wrote:
>>
>> Which brings me back to the question that started my ratholing of
>> this
>> thread :)
>>
>> Does the FSF have private lists?
>
> And equally, does the FSF require NDAs? :)
You just argued they aren't equal :)
geir
Re: TSFKAJ
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Geir Magnusson Jr. wrote:
>
> Which brings me back to the question that started my ratholing of this
> thread :)
>
> Does the FSF have private lists?
And equally, does the FSF require NDAs? :)
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 15, 2007, at 5:09 PM, William A. Rowe, Jr. wrote:
> Geir Magnusson Jr. wrote:
>>
>> I think you're confusing the content with the restrictions. Sure, it
>> should be people issues and not technical issues, but tech issues
>> pop up
>> from time to time. Either way...
>>
>> "...once they are informed of the confidential nature..."
>>
>> where do you go from there? How do you know people agree? A
>> "read-through license"? ("By reading this mail, you accept the
>> confidential nature...") :)
>
> Simply by accepting an invitation to those lists. I liked Roy's
> change
> from pmc@/private@ - how much more obvious can we be? If we have some
> tck-private@ (an idea I *really* don't feel is appropriate, but...) it
> will be only for ASF committers. Why not a message that it's private?
>
> I don't believe an NDA establishes any stronger protection than the
> private@ label on a list.
Interesting.
> But if you feel these NDA's are necessary, by
> all means continue. Humans rise to expectations. Let's treat them as
> techno-kindergardeners to ensure that's the most we expect?
Whether or not I think they are necessary is beside the point here,
just as is your POV regarding "techno-kindergardeners", whatever they
are.
All I'm trying to figure out is why implicit agreement of
confidentiality is ok, and NDAs are community-dividing.
Which brings me back to the question that started my ratholing of
this thread :)
Does the FSF have private lists?
geir
Re: TSFKAJ
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Geir Magnusson Jr. wrote:
>
> I think you're confusing the content with the restrictions. Sure, it
> should be people issues and not technical issues, but tech issues pop up
> from time to time. Either way...
>
> "...once they are informed of the confidential nature..."
>
> where do you go from there? How do you know people agree? A
> "read-through license"? ("By reading this mail, you accept the
> confidential nature...") :)
Simply by accepting an invitation to those lists. I liked Roy's change
from pmc@/private@ - how much more obvious can we be? If we have some
tck-private@ (an idea I *really* don't feel is appropriate, but...) it
will be only for ASF committers. Why not a message that it's private?
I don't believe an NDA establishes any stronger protection than the
private@ label on a list. But if you feel these NDA's are necessary, by
all means continue. Humans rise to expectations. Let's treat them as
techno-kindergardeners to ensure that's the most we expect?
Bill
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 15, 2007, at 7:24 AM, William A. Rowe, Jr. wrote:
> Geir Magnusson Jr. wrote:
>>
>
>> I take it then, Bill, that if the ASF asked every PMC member to
>> sign an
>> NDA to join the PMC's private@*.apache.org lists, that would be ok
>> with
>> you?
>
> No
>
>> For example, if you took
>>
>> http://www.apache.org/jcp/ApacheNDA.pdf
>>
>> and tweaked it so that it wasn't only about "confidential materials"
>> from "third parties", wouldn't it represent the state of affairs
>> that we
>> hope exists for private@*, members@*, board@*, etc?
>
> Perhaps, and again, no, ApacheNDA.pdf is superfluous.
Well, that clears it up for me... :)
>
>> I imagine that under the right circumstances, someone could do
>> quite a
>> bit of damage with some of the info floating around on various
>> private
>> lists...
>
> And they have, in the past. The point is, we are unlikely to sue.
> We are
> more likely to remove the individual from participation on such
> forums.
On what grounds?
>
> But once they are informed of the confidential nature of private@
> pmc lists
> we use to discuss **people issues**, and once they know the license
> that
> binds them for TCK usage terms, we need to give our participants a
> *little*
> credit that they will follow such policies. I'm totally against
> having them
> sign an NDA to that effect.
I think you're confusing the content with the restrictions. Sure, it
should be people issues and not technical issues, but tech issues pop
up from time to time. Either way...
"...once they are informed of the confidential nature..."
where do you go from there? How do you know people agree? A "read-
through license"? ("By reading this mail, you accept the
confidential nature...") :)
geir
Re: TSFKAJ
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Geir Magnusson Jr. wrote:
>
> On Jul 15, 2007, at 12:29 AM, William A. Rowe, Jr. wrote:
>
>> Geir Magnusson Jr. wrote:
>>>
>>> The point I'm trying to make is that the basic notions of an NDA - to
>>> agree not to disclose information given to you in a specific context
>>> except to those who have agreed to the same conditions - are the same
>>> basic notions of a private list, which we accept.
>>
>> With respect to technical or code discussions? That would come as a huge
>> surprise and shock to me.
>
> We do for security lists. And the only code discussions that would fall
> under the JCP NDA is if you are discussing Sun's TCK code. It doesn't
> apply to ASF code of course. So lets not confuse the issue.
Uhm - of course in 20/20 hindsite, the details of a security issue are
public. In general the original report is made plain and public after
a chance to remedy the bug. (Sometimes, before).
We don't do a good job, and we aught to, of republishing the details of
the security discussion once the security issue has been resolved.
> I take it then, Bill, that if the ASF asked every PMC member to sign an
> NDA to join the PMC's private@*.apache.org lists, that would be ok with
> you?
No
> For example, if you took
>
> http://www.apache.org/jcp/ApacheNDA.pdf
>
> and tweaked it so that it wasn't only about "confidential materials"
> from "third parties", wouldn't it represent the state of affairs that we
> hope exists for private@*, members@*, board@*, etc?
Perhaps, and again, no, ApacheNDA.pdf is superfluous.
> I imagine that under the right circumstances, someone could do quite a
> bit of damage with some of the info floating around on various private
> lists...
And they have, in the past. The point is, we are unlikely to sue. We are
more likely to remove the individual from participation on such forums.
But once they are informed of the confidential nature of private@ pmc lists
we use to discuss **people issues**, and once they know the license that
binds them for TCK usage terms, we need to give our participants a *little*
credit that they will follow such policies. I'm totally against having them
sign an NDA to that effect.
Bill
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 15, 2007, at 12:29 AM, William A. Rowe, Jr. wrote:
> Geir Magnusson Jr. wrote:
>>
>> The point I'm trying to make is that the basic notions of an NDA - to
>> agree not to disclose information given to you in a specific context
>> except to those who have agreed to the same conditions - are the same
>> basic notions of a private list, which we accept.
>
> With respect to technical or code discussions? That would come as
> a huge
> surprise and shock to me.
We do for security lists. And the only code discussions that would
fall under the JCP NDA is if you are discussing Sun's TCK code. It
doesn't apply to ASF code of course. So lets not confuse the issue.
I take it then, Bill, that if the ASF asked every PMC member to sign
an NDA to join the PMC's private@*.apache.org lists, that would be ok
with you?
For example, if you took
http://www.apache.org/jcp/ApacheNDA.pdf
and tweaked it so that it wasn't only about "confidential materials"
from "third parties", wouldn't it represent the state of affairs that
we hope exists for private@*, members@*, board@*, etc?
I imagine that under the right circumstances, someone could do quite
a bit of damage with some of the info floating around on various
private lists...
geir
Re: TSFKAJ
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Geir Magnusson Jr. wrote:
>
> The point I'm trying to make is that the basic notions of an NDA - to
> agree not to disclose information given to you in a specific context
> except to those who have agreed to the same conditions - are the same
> basic notions of a private list, which we accept.
With respect to technical or code discussions? That would come as a huge
surprise and shock to me.
Bill
Re: TSFKAJ
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Andrew C. Oliver wrote:
> I understand your point. I simply do not accept it or the basis of your
> argument. Also I resigned (unofficially) from Apache 90% over the
> propagation of private lists (though I've increasingly gotten my way on
> this in the various places I care about @ Apache). Whose judgment is
> relied upon as to who and when to let someone in on the secret in the
> case of a private list?
>
> An NDA?
Andrew, I think the biggest arguement for your position of eliminating NDA's
from the ASF would come down to the JSPA 2.0 section 9. Read the entire thing,
but I find this one particularly interesting.
C. Residuals. This Agreement is not intended to prevent the receiving party from
using Residual Knowledge, subject to any valid patents and copyrights of the
disclosing party. Residual Knowledge means Information that is retained in the
unaided memories of the receiving party’s employees who have had access to
Information. Further, both parties recognize that their receipt of Information
under this Agreement shall not create an obligation in any way limiting or
restricting the work assignments of employees within either party’s organization.
In short, section 9 ensures that unless you *choose* to be part of the EG of
a spec and receive confidential information, but instead you choose to stand
/outside/ using only the published information, you should find that you are
entirely fine developing to that spec with no confidentiality issues at all
to entangle you.
It really only makes life complicated for Geir (on the EC) and participants
of the EG.
Bill
Re: TSFKAJ
Posted by "Andrew C. Oliver" <ac...@buni.org>.
I really hate this particular method of "persuasion"...
Yeah I'm for the "weird" idea of open standards being open in that
"global community" "weird" way. (Color me a free software song singing
clapping Gnu Stallmaniac, as seen ironically on YouTube, if that is so
weird and it makes you happy...). Otherwise they aren't IMO "open" and
if the terms are under NDA then I cannot verify that they are
"standards" per se (rather than just some company's proprietary royalty
pipe dream). Per your insistence of "not knowing what I mean" and
taking what I'm saying out of context... Yes, I REGULARLY sign NDAs
when financially compensated and doing consulting specific to that
company's business practices. Generally open source software is applied
as a result but not developed (occasionally there are useful pieces that
end up back in open source). However I do this in my own name or the
name of a client (I no longer work for AN employer per se). I do not do
it in the name of Apache. I do not call the result "community", "open"
or "standard". I call it "consulting".
Sun's NDAs are bad because they purportedly have a "community process"
that is developing "open standards" and Apache signing them is bad
because then Apache is purportedly a non profit engaged in
community-based open source development but in actuality is doing free
(and actually most of you I would bet would not do it if you did not
benefit financially as a result) consulting for Sun. I don't know what
you guys are doing because I refuse to sign NDAs to find out :-). I can
say what you're doing ISN'T the development of "open standard" or "open
source" -- in Apache's name :-)....it is consulting :-)
-Andy
Wade Chandler wrote:
> Maybe I misunderstood what you wrote, but I'm saying
> when one sees constant "Sun NDAs" are bad, Sun this
> Sun that in a tone which reflects on common business
> practices such as NDAs then it does no good and makes
> people tune out. Most companies will have you sign an
> NDA...even very small companies when you do consulting
> or are just an employee.
>
> In certain contexts they will always be expected. In a
> context of openness and working together it is going
> to be a little weird if the idea is to have everyone
> involved (global community sense), but if the idea is
> so someone at say, Apache, can review some code which
> someone wants to give them yet does not want to give
> everything they can see when reviewing the code they
> will be expected and is common and normal and is the
> only way certain things will be given to an
> open-source organization or project or be able to be
> pulled out by some other person outside the company. I
> bet you all Sun employees have already signed NDAs
> just to have a job.
>
> Wade
>
> --- "Andrew C. Oliver" <ac...@buni.org> wrote:
>
>> So asking the inverse of the question to illustrate
>> an opposing point
>> you disagree with is impragmatic and immature and
>> not real world? I'm
>> either with you or an idiot? Cool!
>>
>> -Andy
>>
>> Wade Chandler wrote:
>>
>>> --- "Andrew C. Oliver" <ac...@buni.org> wrote:
>>>
>>>
>>> Is Sun the only company which uses NDAs? I don't
>>>
>> think
>>
>>> so. Just to be fair ;-). It is perfectly feasible
>>>
>> for
>>
>>> companies to worry about IP. It just matters when
>>>
>> they
>>
>>> do it and in what context. I don't know about you,
>>>
>> but
>>
>>> I'm not rich or live with my parents or off their
>>> money, so I have to have an employer, and without
>>> them...my family doesn't eat or have a roof over
>>>
>> their
>>
>>> head. I think when conversations start taking
>>>
>> these
>>
>>> type directions people tend to tune out as
>>>
>> opinions
>>
>>> versus the real world often differ.
>>>
>>> Wade
>>>
>>>
>> --
>> Buni Meldware Communication Suite
>> http://buni.org
>> Multi-platform and extensible Email,
>> Calendaring (including freebusy),
>> Rich Webmail, Web-calendaring, ease
>> of installation/administration.
>>
>>
>>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: TSFKAJ
Posted by Wade Chandler <hw...@yahoo.com>.
Maybe I misunderstood what you wrote, but I'm saying
when one sees constant "Sun NDAs" are bad, Sun this
Sun that in a tone which reflects on common business
practices such as NDAs then it does no good and makes
people tune out. Most companies will have you sign an
NDA...even very small companies when you do consulting
or are just an employee.
In certain contexts they will always be expected. In a
context of openness and working together it is going
to be a little weird if the idea is to have everyone
involved (global community sense), but if the idea is
so someone at say, Apache, can review some code which
someone wants to give them yet does not want to give
everything they can see when reviewing the code they
will be expected and is common and normal and is the
only way certain things will be given to an
open-source organization or project or be able to be
pulled out by some other person outside the company. I
bet you all Sun employees have already signed NDAs
just to have a job.
Wade
--- "Andrew C. Oliver" <ac...@buni.org> wrote:
> So asking the inverse of the question to illustrate
> an opposing point
> you disagree with is impragmatic and immature and
> not real world? I'm
> either with you or an idiot? Cool!
>
> -Andy
>
> Wade Chandler wrote:
> > --- "Andrew C. Oliver" <ac...@buni.org> wrote:
> >
> >
> > Is Sun the only company which uses NDAs? I don't
> think
> > so. Just to be fair ;-). It is perfectly feasible
> for
> > companies to worry about IP. It just matters when
> they
> > do it and in what context. I don't know about you,
> but
> > I'm not rich or live with my parents or off their
> > money, so I have to have an employer, and without
> > them...my family doesn't eat or have a roof over
> their
> > head. I think when conversations start taking
> these
> > type directions people tend to tune out as
> opinions
> > versus the real world often differ.
> >
> > Wade
> >
>
>
> --
> Buni Meldware Communication Suite
> http://buni.org
> Multi-platform and extensible Email,
> Calendaring (including freebusy),
> Rich Webmail, Web-calendaring, ease
> of installation/administration.
>
>
Re: TSFKAJ
Posted by "Andrew C. Oliver" <ac...@buni.org>.
So asking the inverse of the question to illustrate an opposing point
you disagree with is impragmatic and immature and not real world? I'm
either with you or an idiot? Cool!
-Andy
Wade Chandler wrote:
> --- "Andrew C. Oliver" <ac...@buni.org> wrote:
>
>
> Is Sun the only company which uses NDAs? I don't think
> so. Just to be fair ;-). It is perfectly feasible for
> companies to worry about IP. It just matters when they
> do it and in what context. I don't know about you, but
> I'm not rich or live with my parents or off their
> money, so I have to have an employer, and without
> them...my family doesn't eat or have a roof over their
> head. I think when conversations start taking these
> type directions people tend to tune out as opinions
> versus the real world often differ.
>
> Wade
>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: TSFKAJ
Posted by Wade Chandler <hw...@yahoo.com>.
--- "Andrew C. Oliver" <ac...@buni.org> wrote:
> What is the scope of what is normally covered by
> Sun's NDAs?
>
Is Sun the only company which uses NDAs? I don't think
so. Just to be fair ;-). It is perfectly feasible for
companies to worry about IP. It just matters when they
do it and in what context. I don't know about you, but
I'm not rich or live with my parents or off their
money, so I have to have an employer, and without
them...my family doesn't eat or have a roof over their
head. I think when conversations start taking these
type directions people tend to tune out as opinions
versus the real world often differ.
Wade
Re: TSFKAJ
Posted by "Andrew C. Oliver" <ac...@buni.org>.
I understand your point. I simply do not accept it or the basis of your
argument. Also I resigned (unofficially) from Apache 90% over the
propagation of private lists (though I've increasingly gotten my way on
this in the various places I care about @ Apache). Whose judgment is
relied upon as to who and when to let someone in on the secret in the
case of a private list?
An NDA?
What is the scope of what SHOULD be on a private list?
What is the scope of what is normally covered by Sun's NDAs?
There is a BIG CLIFF between an NDA and a private list. I agree they
have their place...outside open source software development.
-Andy
Geir Magnusson Jr. wrote:
> If the neighbor doesn't agree to not disclose the contents of the
> private list, isn't that as divisive?
>
> The point I'm trying to make is that the basic notions of an NDA - to
> agree not to disclose information given to you in a specific context
> except to those who have agreed to the same conditions - are the same
> basic notions of a private list, which we accept.
>
> This isn't an attempt to defend NDAs (I do think they have their
> place), but simply explore our sometimes violent reactions to NDAs.
> Is it because it's a "legal" document that we sign, and the other is
> generally a vague promise at best? (but ethically as binding as if
> you signed a piece of paper, IMO...)
>
> geir
>
>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 14, 2007, at 2:58 PM, Andrew C. Oliver wrote:
>
>>> accepting
>>> NDAs was something most GNU hackers would never agree to)
>>
>> Serious question - does the FSF have any private lists?
> There is a massive leap from having a private list to accepting an
> NDA. Private lists sometimes keep out unwanted slashdot (the
> casually interested troll is never a contributive presence) from
> otherwise healthy communities and sometime deal with sensitive
> legal matters as they come up. Though they are overused at the
> ASF. NDAs split the community and make free software developers
> unfree to share with their neighbor and that's not good ;-).
If the neighbor doesn't agree to not disclose the contents of the
private list, isn't that as divisive?
The point I'm trying to make is that the basic notions of an NDA - to
agree not to disclose information given to you in a specific context
except to those who have agreed to the same conditions - are the same
basic notions of a private list, which we accept.
This isn't an attempt to defend NDAs (I do think they have their
place), but simply explore our sometimes violent reactions to NDAs.
Is it because it's a "legal" document that we sign, and the other is
generally a vague promise at best? (but ethically as binding as if
you signed a piece of paper, IMO...)
geir
Re: TSFKAJ
Posted by "Andrew C. Oliver" <ac...@buni.org>.
>> accepting
>> NDAs was something most GNU hackers would never agree to)
>
> Serious question - does the FSF have any private lists?
There is a massive leap from having a private list to accepting an NDA.
Private lists sometimes keep out unwanted slashdot (the casually
interested troll is never a contributive presence) from otherwise
healthy communities and sometime deal with sensitive legal matters as
they come up. Though they are overused at the ASF. NDAs split the
community and make free software developers unfree to share with their
neighbor and that's not good ;-).
-Andy
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: TSFKAJ
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 13, 2007, at 8:06 AM, Mark Wielaard wrote:
> Hi Steve,
>
> Steve Loughran <st...@...> writes:
>> Mark Wielaard wrote:
>>> http://www.infoq.com/news/2007/06/openjdk-hybrids
>>
>> Interesting. Now, if you want to keep maintenance costs down you
>> want to
>> get your fixes back in to the main branch, and no doubt sun would
>> like
>> to take on the bugfixes that get proxy support working on kde
>> desktops,
>> etc. But nobody likes to take patches from random developers. Patches
>> that say "Here's my fix to the proxy code, it passes all tests"
>> you'd be
>> much happier. Having a completely open test suite makes it much
>> easier,
>> especially if it comes with a set of VMware images to emulate
>> reference
>> platforms (or the OSS ones, anyway)
>>
>> Looking at the IcedTea release, it appears they are stubbing out the
>> stuff that is restricted: sound, snmp and bits of AWT.
>
> And some crypto stuff. But that was just phase 1. Getting a
> completely free
> setup without any proprietary encumbrances buildable and
> bootstrappable with
> only free software on GNU/Linux systems. Which is what IcedTea 1.0
> was.
I think this is cool. It's a shame Sun didn't do this.
>
> For 1.1 (hopefully out today or this weekend) the stubbed out bits
> are slowly
> replaced with full free versions. Crypto (and in particular https
> ssl support)
> is now done http://mail.openjdk.java.net/pipermail/discuss/2007-
> July/000103.html
> for graphics various efforts are underway either replacing it
> wholesale with the
> GNU Classpath awt peers
> http://kennke.org/blog/2007/07/11/swing-on-gtk-peers-again/ or
> replacing the
> encumbered low level graphics and font rasterizers with free versions
> http://fkung.wordpress.com/2007/06/25/icedtea-graphics/ and
> http://fkung.wordpress.com/2007/07/06/more-fonts/ there is also a
> summary of the
> efforts on java.net
> http://weblogs.java.net/blog/editors/archives/2007/07/
> just_out_of_rea.html
This is cool too. Do you have any plan to re-sync w/ openJPA?
>
>> For server-side
>> JREs, you probably dont need a functional sound subsystem, and its
>> pretty hard to test too -I suspect that the TCK doesn't, not
>> unless it
>> requires you to connect audio out to audio in so that it can verify
>> round tripping, and even then you can't easily distinguish between a
>> loopback in software, a noisy loopback in software and real sound
>> hardware. AWT is testable, and the TCK may have something there,
>> but you
>> are up against the problem of verifying acceptability of different
>> rendering algorithms. Bit-for-bit image comparision works for
>> regression
>> testing on identical hardware, but not for testing different
>> renderers,
>> which, on windows, can mean different display drivers.
>
> Yes, testing is very, very hard, especially for the things you
> mention. But
> there is actually a free testsuite available, Mauve
> http://www.sourceware.org/mauve/ which is already used by gcj, gnu
> classpath,
> kaffe, ikvm, harmony, etc. This of course isn't the official TCK
> but it is a
> very nice thing to have anyway for all the reasons you give.
> Interestingly
> enough now that the java reference implementation is available
> under the GPL
> people have started using it more with the official JDK and
> actually found
> various bugs with it which are now filed and being worked on for
> openjdk.
> Although to be fair, there were a lot more bugs found in the mauve
> testsuite
> itself than there were bugs found in the reference implementation.
> But it is a
> nice testsuite and a good alternative to the currently proprietary
> JCK.
>
> BTW. For sound we do actually have a google summer of code project
> http://code.google.com/soc/2007/gnu/appinfo.html?
> csaid=FDB6DFFB07FE351C the
> student doing that is also creating Mauve tests to verify his work.
>
> So if no solution is found for the JCK (openjdk also doesn't have
> access to it
> yet, GNU Classpath, kaffe, gcj have asked years ago but never got
> through all
> the red tap - this was one of the reasons for starting harmony btw
> since we
> hoped Apache would have a lot more experience with that - although
> accepting
> NDAs was something most GNU hackers would never agree to)
Serious question - does the FSF have any private lists?
> then it might be a
> good idea to bundle forces and push Mauve forward as the shared
> testsuite to use
> for all the TSFKAJs.
Yes - also, in Harmony, we have a lot of good tests too. (I remember
you guys using the GUI tests that Intel contributed.)
We should find a way to make it easy to bring together. Some sort of
packaging convention or something...
geir
>
> Cheers,
>
> Mark
>
Re: TSFKAJ
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Steve,
Steve Loughran <st...@...> writes:
> Mark Wielaard wrote:
> > http://www.infoq.com/news/2007/06/openjdk-hybrids
>
> Interesting. Now, if you want to keep maintenance costs down you want to
> get your fixes back in to the main branch, and no doubt sun would like
> to take on the bugfixes that get proxy support working on kde desktops,
> etc. But nobody likes to take patches from random developers. Patches
> that say "Here's my fix to the proxy code, it passes all tests" you'd be
> much happier. Having a completely open test suite makes it much easier,
> especially if it comes with a set of VMware images to emulate reference
> platforms (or the OSS ones, anyway)
>
> Looking at the IcedTea release, it appears they are stubbing out the
> stuff that is restricted: sound, snmp and bits of AWT.
And some crypto stuff. But that was just phase 1. Getting a completely free
setup without any proprietary encumbrances buildable and bootstrappable with
only free software on GNU/Linux systems. Which is what IcedTea 1.0 was.
For 1.1 (hopefully out today or this weekend) the stubbed out bits are slowly
replaced with full free versions. Crypto (and in particular https ssl support)
is now done http://mail.openjdk.java.net/pipermail/discuss/2007-July/000103.html
for graphics various efforts are underway either replacing it wholesale with the
GNU Classpath awt peers
http://kennke.org/blog/2007/07/11/swing-on-gtk-peers-again/ or replacing the
encumbered low level graphics and font rasterizers with free versions
http://fkung.wordpress.com/2007/06/25/icedtea-graphics/ and
http://fkung.wordpress.com/2007/07/06/more-fonts/ there is also a summary of the
efforts on java.net
http://weblogs.java.net/blog/editors/archives/2007/07/just_out_of_rea.html
> For server-side
> JREs, you probably dont need a functional sound subsystem, and its
> pretty hard to test too -I suspect that the TCK doesn't, not unless it
> requires you to connect audio out to audio in so that it can verify
> round tripping, and even then you can't easily distinguish between a
> loopback in software, a noisy loopback in software and real sound
> hardware. AWT is testable, and the TCK may have something there, but you
> are up against the problem of verifying acceptability of different
> rendering algorithms. Bit-for-bit image comparision works for regression
> testing on identical hardware, but not for testing different renderers,
> which, on windows, can mean different display drivers.
Yes, testing is very, very hard, especially for the things you mention. But
there is actually a free testsuite available, Mauve
http://www.sourceware.org/mauve/ which is already used by gcj, gnu classpath,
kaffe, ikvm, harmony, etc. This of course isn't the official TCK but it is a
very nice thing to have anyway for all the reasons you give. Interestingly
enough now that the java reference implementation is available under the GPL
people have started using it more with the official JDK and actually found
various bugs with it which are now filed and being worked on for openjdk.
Although to be fair, there were a lot more bugs found in the mauve testsuite
itself than there were bugs found in the reference implementation. But it is a
nice testsuite and a good alternative to the currently proprietary JCK.
BTW. For sound we do actually have a google summer of code project
http://code.google.com/soc/2007/gnu/appinfo.html?csaid=FDB6DFFB07FE351C the
student doing that is also creating Mauve tests to verify his work.
So if no solution is found for the JCK (openjdk also doesn't have access to it
yet, GNU Classpath, kaffe, gcj have asked years ago but never got through all
the red tap - this was one of the reasons for starting harmony btw since we
hoped Apache would have a lot more experience with that - although accepting
NDAs was something most GNU hackers would never agree to) then it might be a
good idea to bundle forces and push Mauve forward as the shared testsuite to use
for all the TSFKAJs.
Cheers,
Mark
Re: TSFKAJ
Posted by Steve Loughran <st...@apache.org>.
Mark Wielaard wrote:
> Tim Bray <Ti...@...> writes:
>> I had always assumed that
>> once SE was GPL'ed, there'd be lots of people shipping interesting
>> and useful deltas that aren't called Java. "TSFKAJ, Toshiba
>> Satellite U205-S5068 version". -Tim
>
> There are a couple of those out there now, but most need to replace some of the
> encumbrances, make it work on some non-ported architecture or scale it down for
> embedded use first:
>
> http://www.infoq.com/news/2007/06/openjdk-hybrids
>
>
Interesting. Now, if you want to keep maintenance costs down you want to
get your fixes back in to the main branch, and no doubt sun would like
to take on the bugfixes that get proxy support working on kde desktops,
etc. But nobody likes to take patches from random developers. Patches
that say "Here's my fix to the proxy code, it passes all tests" you'd be
much happier. Having a completely open test suite makes it much easier,
especially if it comes with a set of VMware images to emulate reference
platforms (or the OSS ones, anyway)
Looking at the IcedTea release, it appears they are stubbing out the
stuff that is restricted: sound, snmp and bits of AWT. For server-side
JREs, you probably dont need a functional sound subsystem, and its
pretty hard to test too -I suspect that the TCK doesn't, not unless it
requires you to connect audio out to audio in so that it can verify
round tripping, and even then you can't easily distinguish between a
loopback in software, a noisy loopback in software and real sound
hardware. AWT is testable, and the TCK may have something there, but you
are up against the problem of verifying acceptability of different
rendering algorithms. Bit-for-bit image comparision works for regression
testing on identical hardware, but not for testing different renderers,
which, on windows, can mean different display drivers.
-steve
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
Re: TSFKAJ
Posted by Mark Wielaard <ma...@klomp.org>.
Tim Bray <Ti...@...> writes:
> I had always assumed that
> once SE was GPL'ed, there'd be lots of people shipping interesting
> and useful deltas that aren't called Java. "TSFKAJ, Toshiba
> Satellite U205-S5068 version". -Tim
There are a couple of those out there now, but most need to replace some of the
encumbrances, make it work on some non-ported architecture or scale it down for
embedded use first:
http://www.infoq.com/news/2007/06/openjdk-hybrids
Re: TSFKAJ
Posted by Wade Chandler <hw...@yahoo.com>.
--- Tim Bray <Ti...@Sun.COM> wrote:
> On Jul 12, 2007, at 3:31 AM, Steve Loughran wrote:
>
> > thinking about this, I can see that Sun's Java SE
> stack is also
> > going to have some fun here. If I were to take
> their stack, fix
> > their networking to be laptop-aware and build it,
> how can I,
> > myself, release that build without verifying that
> it passes the TCK?
>
> That's the downside of defining Java as "the binary
> that passed the
> TCK". (Of course, there are upsides too.) I had
> always assumed that
> once SE was GPL'ed, there'd be lots of people
> shipping interesting
> and useful deltas that aren't called Java.
> "TSFKAJ, Toshiba
> Satellite U205-S5068 version". -Tim
>
> PS: TSFKAJ = 'The Software Formerly Known As..."
>
>
According to the 176 specification as long as the
independent implementation doesn't modify the
specification specifics other value adds can be
included in someones II JRE. I would figure it would
have already been happening. I suppose it semi-sort of
has though not really legit.
I know there are some issues with what SuperWaba did
for instance. They have not implemented a J2ME
specification yet they implement much (not all) of the
JVM and some of the classes and interfaces from
different packages. It would be nice if subsets were
allowed to be created as long as they were not
distributed as Java runtimes so different innovations
could take place in different areas, but I certainly
don't want to have to try to support my Java
application on someone else's Java (yet it is not
really Java) installation for my applications as that
could get hairy real quick and customers would not
understand it, so I really love having the JCP protect
the specification and the base.
Wade