Re: Must I resubscribe to all the list..

[Martin van den Bemt]

I am happy again.. I got my mails ;))

Mvgr,
Martin

On Wed, 2002-05-29 at 02:08, Martin van den Bemt wrote:
> (NOTE : just subsribed, hoping it will arrive on general this time..
> probably other mails are waiting to be moderated, you can decline ;)
> 
> Hi everyone,
> 
> I already mailed to Pier privately, but I am a bit lost here, and I want to
> know the consequences.
> Since a couple of days I don't receive any mails anymore on [EMAIL PROTECTED]
> Every request to the server, doesn't return a response (I can be mailed on
> that address, no problems on my site, just so you know).  I tried subsribing
> (without replying) from other mail addresses, which all seem to work fine.
> I subscribed to about 30 mailinglist on jakarta. So I want to know what I am
> up against
> So here are my questions :
> 
> 0) What is going on ?
> 1) Do I still get those e-mails from the last couple of days ?
> 2) Am I still subsribed ?
> 3) Do I have to subscribe under a different mail address ?
> 4) If 3 is true, can someone please unsubscribe [EMAIL PROTECTED], since I
> cannot seem to get anything done at that address.
> 
> If you have any other answers, I would love to hear them..
> Getting a bit frustrated by looking at the archives.. ;(
> 
> Mvgr,
> Martin
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Reorganizing to support mirroring

[Conor MacNeill]

Currently the Jakarta project's builds are not mirrored along with the 
rest of the Apache site. For example, check this out

ftp://mirror.aarnet.edu.au/pub/apache/dist/jakarta/README.txt

To support mirroring, Joshua Slive, who has been looking at the issue, 
believes the following changes will be required to the structure of the 
Jakarta download area and webpages

> 1. All the nightly builds need to be targeted someplace else.  I suggest 
>cvs.apache.org:/www/cvs.apache.org/builds/ but 
>www.apache.org:/www/jakarta.apache.org/nightly/ could also work.  This is just too 
>much stuff to be pushing out to the mirrors every night.
> 
> 1a. Remove all the nightly directories from 
>www.apache.org:/www/jakarta.apache.org/builds/
> 
> 2. Move www.apache.org:/www/jakarta.apache.org/builds/ to 
>www.apache.org:/www/www.apache.org/dist/jakarta/ and provide a redirect (either via 
>.htaccess or httpd.conf).
> 
> 3. Change the links from the jakarta webpages to point at
> http://www.apache.org/dyn/closer.cgi/jakarta/ (and subdirectories thereof).

Obviously this represents a fairly major change to all Jakarta sub 
projects in terms of nightly build processes, web page links etc.

I'd like to start a discussion about this here now. I think mirroring is 
obviously something we should support but we're going to need to go 
through some migration process to get from where we are today to the above.

Any thoughts on the best way to achieve this smoothly :-) ?

Cheers
Conor


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Mail list remote request thingy majig is broken

[Pier Fumagalli]

"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> Yeah, I can't remotely subscribe a user who is having trouble
> subscribing himself.  Furthermore, I'm unable to unsubscribe myself from
> a mailing list that I'd like to unsubscribe from.  (I
> subscribe/unsubscribe from lots of projects on a regular basis to manage
> volume)...  If I had to guess I think the little guy who listens for the
> subscribe/unsubscribe and remote admin requests has gone on vacation.
> As he is badly needed for service, I suggest those with sufficient karma
> should recall him.

No, the little "mail owner" is in _deep_shit_ with his mail server since
Saturday night (got around to fix barely minimal functionality just today),
and have to fix it before I can get around and do anything! :)

At least now I can read (and I didn't loose one single message)...

Keep 'em coming... I'll get around to finish off apache work (and the
interrupted flamewars) this week-end...

Sorry, but that's life when your servers do "kaboom" and you're the only
"man" who can fix them (and he's not paid to do it, since he has a nice
9-to-5 job to take care of as well)...

Thank god for Queen's Jubilee and the 2 extra days of vacation next weekend
:) (God save the queen!)

Pier (/var/qmail := rulez)

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Mail list remote request thingy majig is broken

[Andrew C. Oliver]

Yeah, I can't remotely subscribe a user who is having trouble
subscribing himself.  Furthermore, I'm unable to unsubscribe myself from
a mailing list that I'd like to unsubscribe from.  (I
subscribe/unsubscribe from lots of projects on a regular basis to manage
volume)...  If I had to guess I think the little guy who listens for the
subscribe/unsubscribe and remote admin requests has gone on vacation. 
As he is badly needed for service, I suggest those with sufficient karma
should recall him. 

Thanks,

Andy
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Andrew C. Oliver]

On Tue, 2002-05-28 at 17:36, Leo Simons wrote:
> On Tue, 2002-05-28 at 14:20, Andrew C. Oliver wrote:
> > I totally disagree with everything you just said.
> 
> Uhm, I think you disagree with the idea "we should have
> 'developers/contributors' with CVS access who are not committers". I'm
> not sure whether I support that idea yet.
> 
> You also disagree with the other stuff I said?
> 
> > I do NOT think developers should be granted CVS access without voting 
> > rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
> > want to give you the rights to control your work or give you any 
> > ownership in what you do".  If they are frequent enough committers to 
> > require CVS access...then they deserve the rights there under.
> 
> Missing the point I made that there might be people out there that want
> some of the rights that come with committer status, not caring about
> having all of them, while not wanting all of the duties that come with
> committer status.
> 

I want a million dollars with no responsibilities such as paying taxes
or any of that stuff.  With rights come responsibilities, such is life.

> Heck, I'll probably submit more than a few patches to centipede in the
> future; people will probably get tired of applying them and they might
> ask me to become a committer, to which I will say "no thanks" as I feel
> I have have no time to make that commitment. It'll still be easier for
> both the committers and me if I still get CVS access.
> 

Centipede is not a Jakarta project, and if the voting rules for
centipede are documented, I missed the link.  I think for the moment its
either common law or "understood" because nearly everyone there is a
committer on some Apache project somewhere.  

> I'm not saying we should allow it, just that there's two sides to the
> story.
> 

I'd in fact -1 the idea of giving you CVS access without agreeing to be
a committer.

Krysalis (from what I can tell) actually has a slightly different type
of committership.  One is a committer to all projects (meaning I get to
vote on Wings and Centipede both).

I think I may be (there) an excellent example of the type of "committer"
that Pier talks about.  I've actually committed 0 code to Wings or
Centipede.  All of my work has been in setup, publicising, cross
OS-testing, and well lots of little things that aren't code but that
well the project might not be where it is today had I not done them.  

> Case can be made that since putting something in CVS is putting
> something up for lazy majority vote (and I subscribe to that), this is
> not a good 'use case'. But what is wrong with a role for people that
> have the option to propose something for a lazy majority vote, and then
> no right/obligation to actually vote on that 'something' or anything
> else?
> 

I think with rights comes responsibility.  "Gee I'd like to dump my code
here and not bother with the community" I want a million dollars
without bothering with earning it or the taxes or jailtime or
whatever...

-Andy

> g'night,
> 
> - Leo
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Must I resubscribe to all the list..

[Martin van den Bemt]

(NOTE : just subsribed, hoping it will arrive on general this time..
probably other mails are waiting to be moderated, you can decline ;)

Hi everyone,

I already mailed to Pier privately, but I am a bit lost here, and I want to
know the consequences.
Since a couple of days I don't receive any mails anymore on [EMAIL PROTECTED]
Every request to the server, doesn't return a response (I can be mailed on
that address, no problems on my site, just so you know).  I tried subsribing
(without replying) from other mail addresses, which all seem to work fine.
I subscribed to about 30 mailinglist on jakarta. So I want to know what I am
up against
So here are my questions :

0) What is going on ?
1) Do I still get those e-mails from the last couple of days ?
2) Am I still subsribed ?
3) Do I have to subscribe under a different mail address ?
4) If 3 is true, can someone please unsubscribe [EMAIL PROTECTED], since I
cannot seem to get anything done at that address.

If you have any other answers, I would love to hear them..
Getting a bit frustrated by looking at the archives.. ;(

Mvgr,
Martin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Criteria for commit access

[Morgan Delagrange]

> Just one question, have you ever voted -1 on a committer? (and not just to
> you, but to every committer on this list).
>
> Pier
>

Yes I'm several days behind in email.  :)  Catching up now...

I voted -0 on a couple of committers once because I didn't feel that their
qualifications were well-specified.  They were nominated for Commons, but
they had made either insubsubstantial or nonexistent (can't recall which) to
the Commons mailing lists.

It was very similar circumstances.  I was uncomfortable with the credentials
supplied, Costin, Remy and Jean-frederic clarified the proposed committers'
status in Jakarta, and I retracted my objection.  You can see part of the
thread here:

  http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg03817.html

If I recall correctly, there was in my view a little unnecessary huffiness
in the discussion (like Pier, I just wanted clarification on who they were)
but I think it turned out satisfactorily in the end.

- Morgan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Jon Scott Stevens]

on 5/28/02 12:12 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Leo Simons wrote:
>> 
>>> Since committing is voting, what I think what some people want is a
>>> non-vetoing Committer.
>> 
>> I think 'some people' don't see/don't agree to the "committing is
>> voting", and then what they want is a Developer-with-CVS-access, which
>> is more or less what they said.
>> 
>> "Committing is voting" is not reflected in our guidelines (at least I
>> couldn't find such a notion).
> 
> In projects like , any
> impleementation of an idea (as opposed to a simple patch) must be
> review-then-comment.  In most Jakarta subprojects, the norm is lazy
> consensus as defined in .
> 
> So, think of a commit as the first (any typically only) +1 most changes get.
> 
>>> Someone to do the work without sharing in the
>>> responsibility.
>> 
>> sounds like what we call "developer" in our guidelines ;)
> 
> A "developer" can suggest a change.
> 
> A "committer" can make it happen.
> 
> - Sam Ruby

"Anyone" can suggest a change.

A "developer" can submit a patch.

A "committer" can make it happen.

;-)

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL] Committer access and responsibilities...

[Danny Angus]

I agree with andy to an extent here:


> I do NOT think developers should be granted CVS access without voting
> rights.


But do still believe that there ought to be a more restrictive set of
permissions, and responsibilities, for "entry level"  sub-project
membership, if entry level members buy-in to the project community they will
learn where to ask to be proposed for full membership.

I think its important, getting back to the cause of this discussion to
reconcile the two ideals of firstly letting sub-projects manage their own
entry criteria, and secondly still maintaining a real community amongst
those with a wider horizon.

The problem Pier raised can be summarised as the entrance criteria of Tomcat
being percieved as too low w.r.t. the benefits and responsibilities a
commiter has within the wider Jakarta community, while acknowleding that
raising the bar would be Jakarta unfairly restricting the freedom Tomcat
mambers have in running their own community.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Andrew C. Oliver]

I totally disagree with everything you just said.  I think "committer" 
status should be granted to folks who do *other* things outside of CVS. 
 But the key word is "Do".  So pretend for a second that Pier is *not 
otherwise* a comitter to Tomcat and wherever, he does a lot of other 
stuff like manage bugzilla.  And bugzilla...what a pain.  So I would say 
Pier should be granted some voting rights etc.  I think thats the goal 
here and I agree with to goal, but none of the proposals I've seen spell 
out tight enough constraints.  

I do NOT think developers should be granted CVS access without voting 
rights.  Thats a cop out.  That says "Gee we trust you in CVS but don't 
want to give you the rights to control your work or give you any 
ownership in what you do".  If they are frequent enough committers to 
require CVS access...then they deserve the rights there under.

-Andy

Leo Simons wrote:

>>Since this is a volunteer organization, and we all have other pressing
>>responsibilities, it is important that we do not encourage any systemic
>>bottlenecks.
>>
>>
>
>I wrote:
>"> > user: no rights, no responsibilities
>  
>
>>>developer: right to get quoted as author for authored pieces, no
>>>responsibility
>>>committer: right to vote as per voting guidelines, responsibility to
>>>sign and submit Contributor License Agreement
>>>pmc member: right and obligation to set overall project direction"
>>>  
>>>
>
>this is not quite reflective of our current situation. The term
>"developer" can sometimes be misleading ("contributor" would be better,
>perhaps), while "committer" perhaps should include some added guidelines
>wrt responsibilities.
>
>You might call the fact that these definitions are somewhat out of whack
>a "systemic bottleneck".
>
>  
>
>>Since committing is voting, what I think what some people want is a
>>non-vetoing Committer.
>>
>>
>
>I think 'some people' don't see/don't agree to the "committing is
>voting", and then what they want is a Developer-with-CVS-access, which
>is more or less what they said.
>
>"Committing is voting" is not reflected in our guidelines (at least I
>couldn't find such a notion).
>
>  
>
>>Someone to do the work without sharing in the
>>responsibility.
>>
>>
>
>sounds like what we call "developer" in our guidelines ;)
>
>  
>
>>Which is to say, we can reject what they do, but they
>>can't reject what we do. Personally, I would find that type of
>>master/slave relationship difficult to maintain in a volunteer 
>>organization like this. If you are working hard enough to need commit 
>>rights, you are working hard enough to have veto rights. 
>>
>>
>
>What if someone wants/needs commit rights but doesn't want the veto
>rights (and responsibilities)? The right to vote also means an
>obligation to vote/abstain. The implication of your statement is "if you
>are given cvs access, you should also take on the responsibility of
>voting".
>
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Ted Husted]

I changed "Developer" to "Contributer" throughout the guidelines, if 
for no other reason than to match the terminology of the "Contributor 
License" distributed by the ASF.

Personally, I feel that the current guidelines do express the concept
that committing is voting by lazy consensus. That's why there is a 
lazy consensus: so we can propose, vote, and make-it-so in one fell 
swoop. Volunteer time is a precious resource and we need to make 
the most of it. 

A substantial patch to the guidelines was proposed some time ago that
might help clarify this and other fine points. 

http://jakarta.apache.org/site/proposal.html


-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Leo Simons wrote:
> this is not quite reflective of our current situation. The term
> "developer" can sometimes be misleading ("contributor" would be better,
> perhaps), while "committer" perhaps should include some added guidelines
> wrt responsibilities.
> 
> You might call the fact that these definitions are somewhat out of whack
> a "systemic bottleneck".
> 
> > Since committing is voting, what I think what some people want is a
> > non-vetoing Committer.
> 
> I think 'some people' don't see/don't agree to the "committing is
> voting", and then what they want is a Developer-with-CVS-access, which
> is more or less what they said.
> 
> "Committing is voting" is not reflected in our guidelines (at least I
> couldn't find such a notion).
> 
> > Someone to do the work without sharing in the
> > responsibility.
> 
> sounds like what we call "developer" in our guidelines ;)
> 
> > Which is to say, we can reject what they do, but they
> > can't reject what we do. Personally, I would find that type of
> > master/slave relationship difficult to maintain in a volunteer
> > organization like this. If you are working hard enough to need commit
> > rights, you are working hard enough to have veto rights.
> 
> What if someone wants/needs commit rights but doesn't want the veto
> rights (and responsibilities)? The right to vote also means an
> obligation to vote/abstain. The implication of your statement is "if you
> are given cvs access, you should also take on the responsibility of
> voting".
> 
> cheers,
> 
> - Leo
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PROPOSAL] Committer access and responsibilities...

[Santiago Gala]

Sam Ruby wrote:

>Ted Husted wrote:
>  
>
>>Since committing is voting...
>>
>>
>
>+1
>  
>
You can look at it the other way round:

voting is (in a sense) committing (yourself) to the project. :-)

My itch is that I have been overwhelmed with work, to the point that I 
can barely follow the codebase or the dev list. I think that I will 
slowly find myself in a role in the project again, like:

- When the frenzy dies, I can review and debug (I'm quite good at 
debugging), and document things, and ask (and answer) nasty questions 
about product architecture or implementation.
- I can point to interesting ways to improve the project (functionality 
and/or architecture).
- I can have discussions on future changes, I keep global vision since 
I'm more detached, ...

I have been worried during this whole thread, because I feel that I'm 
losing grip of my involvements with Apache. I used to be able to track 
closely lists and codebases for cocoon, turbine, tomcat and jetspeed. 
Now I barely track Jetspeed. I felt like my involvement as committer was 
dying.

But thinking carefully after reading this thread, I think I agree with 
Andrew's comment: the system works, don't touch it.

If I am respectful and I don't touch the codebase without asking people 
(except obvious patches for typo/bug fixing or documentation), I can 
still be useful to the project. While my comments are good shaped and 
reasonable they will be taken into account and agreed. If I start doing 
unreasonable proposals or messing with code, -1s will appear, and a 
conflict will be raised.

I just wanted to point that, in addition to taking the 
developer/commiter role as something more than code shaping 
(documentation, proposals, design, etc.) tasks like teaching newbies in 
the lists or raising awareness about the projects, are valuable in 
themselves. But I would not mess with the current roles in Apache, 
except for raising awareness of the fact that there are things beyond 
code lines.

IMO, the key issues for having a working system are:

- openness
- openness
- openness

The only think that makes the system work is that all discussions (and 
the decision processes themselves) are held in the open, so that people 
can follow design intentions without needing to have explicit 
instructions, and so that proposals are kept in archives for future 
people to implement them. Also, only an open system enables us to build 
and maintain the trust and respect network for the project. Turning back 
to my itches, while I'm trusted and respected in the jetspeed team, my 
decisions will be heard and taken into account. Unless my contributions 
are really valuable, the trust will extinguish slowly as I fade. If my 
contributions are valuable, I will manage to keep a low profile and 
still be a respected developer/commiter/younameit (i.e. an active member 
of the community). I have seen this happening with other people, which 
have a varying involvement in terms of time, but always bring valuable 
material in, and they are respected even after disappearing during 
months from the list.

Pardon me for this kind of rant/public confession. ;)

Regards,
   Santiago (reading mail after weeks outside teaching java/Apache code)

>- Sam Ruby
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Objectbridge and JDO: Licensing issue

[Jason Hunter]

You basically have two choices.  (1) You can use the Sun JAR files and
comply with their license.  Tomcat does this for several Sun JARs.  Note
that sometimes the JARs have a "value add" clause that makes things a
little tricky, but it's doable.  (2) You could do a clean room
implementation.  It's the legal right to do #2 that was agreed to with
Sun recently.  Previously if you didn't like Sun's JAR license, you were
just stuck.  Now you have the ability to implement a JSR on your own and
get access to the TCK.

-jh-

Pier Fumagalli wrote:
> 
> Florian, I believe that this is more-or-less (or falls really close) to the
> issue that XML-Axis is having (but I might be wrong, Sam?)
> 
> Maybe Jason (our liaison with the JCP) can give us some light on this topic?
> 
> Pier
> 
> "Florian Bruckner" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> >
> > I am sending this to the jakarta-general list because I hope that some of
> > you can help us to resolve the following issue.
> >
> > As you might remember, Objectbridge was recently proposed as a
> > jakarta-subproject and accepted. This requires Objectbridge to change the
> > license to ASL, which is perfectly ok for everybody there.
> >
> > As far as I can see, a small problem arose a few days ago. Somebody added
> > two jar Files of Sun Microsystems related to JDO (Java Data Objects, an API
> > OJB plans to implement). One of those jars is of the reference
> > implementation of JDO, one is either from the reference implementation or
> > the specification.
> >
> > The following paragraphs is from an email I sent to the Objectbridge
> > Mailinglist, but unfortunately it didn't help to resolve our issue:
> >
> >> jdo.jar and jdori.jar are part of the reference implementation of JDO from
> >> Sun, and that is licensed unter the sun community source license. The
> >> paragraph in question says:
> >>
> >> "
> >> a) Research Use License:
> >>
> >> (i) use, reproduce and modify the Original Code,
> >> Upgraded Code and Specifications to create Modifications and
> >> Reformatted Specifications for Research Use by You, (ii)
> >> publish and display Original Code, Upgraded Code and
> >> Specifications with, or as part of Modifications, as
> >> permitted under Section 3.1 b) below, (iii) reproduce and
> >> distribute copies of Original Code and Upgraded Code to
> >> Licensees and students for Research Use by You, (iv)
> >> compile, reproduce and distribute Original Code and Upgraded
> >> Code in Executable form, and Reformatted Specifications to
> >> anyone for Research Use by You.
> >> "
> >>
> >> My understanding of this paragraph is, that we'd only be able the JDO part
> >> of OJB under these conditions and only for research. This implies that
> > we'll
> >> not be able to release a "production quality" version of OJB-JDO. What we
> >> jave to go for is a "clean-room" implementation, the requirements for this
> >> are stipulated in the license of the JDO specification:
> >>
> >> "
> >> Sun hereby grants you a fully-paid, non-exclusive,
> >> non-transferable, worldwide, limited license (without the
> >> right to sublicense), under Sun's intellectual property
> >> rights that are essential to practice the Specification, to
> >> internally practice the Specification for the purpose of
> >> designing and developing your Java applets and applications
> >> intended to run on the Java platform or creating a clean
> >> room implementation of the Specification that:  (i) includes
> >> a complete implementation of the current version of the
> >> Specification, without subsetting or supersetting; (ii)
> >> implements all of the interfaces and functionality of the
> >> Specification without subsetting or supersetting; (iii)
> >> includes a complete implementation of any optional
> >> components (as defined by the Specification) which you
> >> choose to implement, without subsetting or supersetting;
> >> (iv) implements all of the interfaces and functionality of
> >> such optional components, without subsetting or
> >> supersetting; (v) does not add any additional packages,
> >> classes or interfaces to the "java.*" or "javax.*" packages
> >> or subpackages or other packages defined by the
> >> Specification; (vi) satisfies all testing requirements
> >> available from Sun relating to the most recently published
> >> version of the Specification six (6) months prior to any
> >> release of the clean room implementation or upgrade thereto;
> >> (vii) does not derive from any Sun source code or binary
> >> code materials; and (viii) does not include any Sun source
> >> code or binary code materials without an appropriate and
> >> separate license from Sun.  The Specification contains the
> >> proprietary information of Sun and may only be used in
> >> accordance with the license terms set forth herein.  This
> >> license will terminate immediately without notice from Sun
> >> if you fail to comply with any provision of this license.
> >> Upon termination or expiration of this license, you