Re: Mentor vs. Shepherd

[Roy T. Fielding]

The ASF loves the Greek Myth :-) Mentor was Odysseus's good teacher and
mental supporter. I prefer Mentor to Shepherd.
Er, the ASF rarely speaks with one voice -- Stefano loves the Greek 
Myth,
and the rest of us just tolerate it because we like Stefano.  ;-)

Personally, I prefer Shepherd, since occasionally you have to take a
stick to the little bastards, or send the dogs to bring in a stray.
Anyway, my ultimate preference is the same as whatever person is willing
to learn how to update our silly site, or just delete the damn thing
and move the content over the www.apache.org/dev where I can edit it
myself.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting and tracking project tasks )

[Roy T. Fielding]

The STATUS file is passive.  Jira is active.  The STATUS file requires 
the
submitter to have CVS commit access to that module, and CVS knowledge. 
 Jira
has its own access control, and a built-in UI.  The STATUS file 
requires
human parsing to understand the priorities.  Jira has a prioritization
model.  Updating the STATUS file requires a checkout/update, edit, 
commit.
Jira would be simply filing an issue via the webapp.
AFAIK, Jira does not authenticate that the person entering the status
information has the authority to do so, which is what we get with the
cvs process.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: STATUS file compared/contrasted with an issue tracker

[Roy T. Fielding]

I have checked in the incubator CVS a new version of the Incubator 
site, with a proposed new layout.

I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be effectively 
used for identifying action items in order?

We could use a status.xml file that contains information about who 
does things, todos, and changes. The less nice side is that it's XML.
I don't mind xml, but I am somewhat concerned about placing the STATUS
information where end-users are expected to look.  A project's detailed
status within incubator should only be of interest to the developers and
incubator pmc.  In particular, I wouldn't want people to feel the need
to dumb-down or generalize its content for the sake of user 
documentation,
as is often done with website content.  OTOH, it would be really nice
to replace the big text checklist with a table-formatted list, and I'd
like to reduce the number of redundant directories in the incubator
module so that people won't have to search all over for relevant bits.

BTW, having to dig way down to src/documentation/content/xdocs
just to get to the top of the website source seems a bit ridiculous.
Why are the site sources in both incubator and incubator-site?
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: incubation requirements for axion at apache db?

[Roy T. Fielding]

Assuming the Apache DB PMC approves Axion as a new subproject:

1) Other than the attribution of copyright to the ASF, the switch to 
the
ASL, and the submission of a signed CLA for those that haven't already
done so, what specfic criteria/goals need to be met in order to
succesfully complete incubation?  I.e., how do we know when it is time 
to
call for a vote on "graduation"?
You can call a vote for it at any time after it enters incubation,
but I suggest you avoid doing so until the questions in STATUS are
answered.
The vote will pass when the people responsible for incubation are
reasonably satisfied that the task is complete and recorded for
posterity.  The rate at which that happens is largely determined
by the willingness of the new project volunteers and/or mentor to
update the documents that record the podling's progress.
2) What timeframe can we expect this to happen in?
There is no timeframe.  Some take longer than others; some are ready
before they even begin; and some never manage to begin.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: projects "in" versus "entering" versus "affiliated with" the incubator

[Roy T. Fielding]

The page is obsolete and does not reflect reality, the distinction is 
really not there.
Right, the existing web site is nothing more than a draft.  That is why
it is a bit silly to create all these other "draft" and "whiteboard" and
"wiki" places for other drafts.  Please move all relevant content to the
website ASAP, delete all old content and "draft" sections, and let us
know when the new content is in place so that we can all edit *one*
source.  I almost did that yesterday but found that none of the real
content was in CVS HEAD -- that is bad, since it gets in the way
of part-time collaboration.
BTW, things like the CLA form do not belong in incubator.  I'll start
moving them to the www.apache.org/dev site.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Common naming accross policy/process/roles

[Roy T. Fielding]

Cannot open /home/cvs/CVSROOT/commitlogs/incubator: Permission denied
The group permissions on that file are wrong -- I've asked root to
fix it.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Restoring project web sites

[Roy T. Fielding]

One of the things that happened when we updated the main incubator 
site is
that it blew away the project site(s).  What do we want to tell a 
project to
do about its site.  How should Geronimo link a project site into what 
is now
their STATUS page?

Obviously, they can just "do it", but is there a normative approach 
that you
want them to take?
Figure out how it can be done and just do it.  That will be the 
normative
approach until we figure out a better one.  Anyone working on an 
incubated
project who asks for karma on the incubator site will get it as soon as
I get a chance to edit avail.  In most cases, they already have karma.

In the mean time, we need to set some ground rules: it is only okay to
update the site if the result does not lose information that was
available prior to the update, unless that information is no longer
applicable.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Possible Incubation] Apache Repo

[Roy T. Fielding]

I think that producing a single repository, or at least a set of
mechanisms that allow a single storage facility to look like a
repository with multiple interfaces, is a task for infrastructure
and commons to work out (meaning that the people who have interest
in such a thing will work together to minimize the cost to the ASF,
both in terms of bandwidth and volunteer time, under the auspices
of the people responsible for keeping us on the net).  We don't
need a separate group for that because it is an internal task,
and there are no IP issues that require a trip through incubator.
If there are additional software tools that might make useful
Apache products and people to stoke the engines, then we should
incubate those here as new projects.  We just need a clear proposal.
I cannot say this enough: umbrella projects are the bane of Apache.
The sooner we get away from the concept of "everybody has to be
concerned with everyone else's projects" and back to each project
governing itself under collaborative principles, the better and
stronger we will be in the long run.  Consensus is a good way to
make decisions, not a good way to explore alternative designs.
We need to welcome as many offshoots as possible, albeit with
different names to avoid confusion, and we must always be willing
to learn from each other's mistakes and successes.  The essence
Apache philosophy is that we want people to copy what we do,
regardless of why they choose to do so.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Possible Incubation] Apache Repo

[Roy T. Fielding]

So if I understand this correctly the discussions on [EMAIL PROTECTED]
should now be conducted on infrastructure where we are talking about 
the
physical layout of the repository in a file system that is accessible
via http.
It is my understanding that repository is a topic-specific mailing list
on behalf of infrastructure.  I haven't looked at the mail, though I 
know
that is why it was created.

While software that may operate on this physical structure is a matter
for the various projects whether it be existing code in places like
Ant/Maven or new code that is brought to the incubator?
Right.  Naturally, it doesn't do us any good to provide a repository
that simply won't work with the tools that are supposed to use it, so
it is a feedback loop by nature.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Possible Incubation] Apache Repo

[Roy T. Fielding]

Small note - some of the participants on the [EMAIL PROTECTED] are
discussing the actual requirements - which from my (and other) point(s)
of view go beyond a file-system http protocol cut-and-dried 
implementation
solution.  Some consider this area to be much more than an HTTP 
download
handler. In fact - if the scope of a repository model were limited to
that then would would be missing a really big opportunity to do this in
a way is of real value to multiple projects.  Yes - you can assume some
simplistic models down low - but hopefully this is not just about
plumbing but also about addressing the requirements across different
abstractions that will ultimately ensure that semantic assumptions are
consistent across multiple repository-enabled applications.
The requirement is that ASF-owned software be distributed in an 
efficient
(for our costs), reliable (for our maintainers), and user-friendly way.
Feel free to consider any number of designs that may accomplish that
requirement, but don't mistake a design opinion for a requirement.
In particular, do not under any circumstances hold up implementation
of the repository in pursuit of perfection -- a current implementation
can be replaced at any time we see fit.

Just trying to clarify, is this correct?

I hope not - it would not meet Avalon project requirements relative to
repository-aware applications. I much prefer Roy's terminology "a 
single
storage facility to look like a repository with multiple interfaces".
Roy's statement *does* encompass the scope of requirements that I see 
as
relevant.
Hello?  Avalon project requirements do not encompass repository needs,
and certainly do not define them.  Avalon users might prefer a given
interface to the repository, which I assume the Avalon community is more
than capable of defining and developing on their own.  The commonality
that is required by repository is determining the easiest way for all
of our projects to provide artifacts and their authenticity-proving
signatures such that the general public can get what they want, when
they want, at a minimum cost to us.  The tools that retrieve from the
repository are not within its scope.
Anything (and I do mean anything) beyond that is a software project
that the ASF has not authorized, and certainly won't be developed here
unless it is within a PMC.  People are certainly welcome to propose
such a project on incubator, but that is not the repository project.
Repository is a task to be accomplished!
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Possible Incubation] Apache Repo

[Roy T. Fielding]

It is usually unwise to mix insults with requests.  However,
the point of collaboration is not to obtain the civility of a
collegial discussion over tea; the point is to accomplish the
task.  Continual discussion of issues that are not relevant to
the task being collaborated upon is not collaboration -- it is
being a pain in the ass.
Folks, you don't have to respond to every comment, and especially
not this one.  If it isn't relevant, you'll get more done by just
ignoring it and moving on.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Possible Incubation] Apache Repo

[Roy T. Fielding]

I would add one more requirement to above statement - namely 
"machine-friendly".  There is an emerging requirement for application 
driven downloading that has the potential to significantly exceed the 
classic browser driven requirements that the ASF is addressing today.  
This has a direct impact on ASF costs, reliability, and utility.
Machines don't have friends and application-driven downloading is
just an application performing a download (UI is not a design issue
for a repository).  The requirement is user-friendly, with the
expectation being that user needs will evolve over time just as
the interfaces will resolve over time.  The immediate needs are
file-based, because that is what users need right now.
Hello?  Avalon project requirements do not encompass repository needs,
and certainly do not define them.
I don't think that I have suggested this. Avalon requirements deal 
with at least three layers of abstraction with respect to server side 
facilities.
Whoa, you have abstract requirements?  Now that's a good way to drive
yourself insane.
  At the lowest level these requirements are rather close to the 
requirements you have outlined above.
Good, then we are settled.  Let's get this beast out the door with the
lowest level of requirements and fulfill the others via an appropriate
software development effort.
  As far as second and third level requirements are concerned - these 
place functional requirements on the respective underlying facilities. 
 My objective are rather simple - the basic facility should be a 
platform on which higher level facilities can be established without 
resorting to inefficiencies or workarounds.
Well, then they aren't higher levels, are they?  And that would be an
inferior design for collaboration, wouldn't it, since inter-layer
processing places application requirements before those of the
infrastructure.  -1.
I should also point out that Avalon is not alone is this respect. 
Other projects are evolving towards repository-awareness. Identifying 
and collecting those requirements (many of which are 
project/application specific) are central to the delivery of a basic 
repository that is extendible to meet the needs of a significant usage 
model (in terms of ASF near-term impact).
No, that isn't central -- it isn't even a good idea.  Please see, for
example, every single "standard" for repositories that has ever been
"designed", including those for ANSA's ODP, CORBA, and the JSR
something-or-other that takes a simple content management problem
and defines it as an ass-backwards indirect query monstrosity that
nobody will ever use.  We don't need that.  We need CPAN, or apt-get,
or fink, or something slightly more dependency aware but not so much
so that we sit on our thumbs waiting for it to happen.
Avalon users might prefer a given
interface to the repository, which I assume the Avalon community is 
more
than capable of defining and developing on their own.
Clearly yes.  The work within Avalon has *done* exactly this and as a 
result - issues with current approaches have discovered and near term 
requirements have been identified.  These aspects are the things that 
Avalon has to contribute to general model.  I'll restate my earlier 
comment - the simplistic http + file layout assumptions "do not meet 
Avalon project requirements relative to repository-aware > applications".

In fact this is probably the key point - is this initiative about 
dealing with ASF download requirements, or, does this initiative 
address the emerging and potentially much larger repository aware 
application scenario?  If this is simply about safe downloading then 
my assertions are clearly inappropriate.
It is about safe downloading of dependencies from a virtual
repository that extends across mirrored systems on a heterogeneous,
multi-organizational network.  The underlying infrastructure is
going to be file based because it will be replicated with rsync.
I sure as hell don't want anything more complex than that at
the base level.  Building interfaces on top of that is trivial
and not in the least impacted in terms of efficiency -- there are
no methods of storing large objects more efficient than a modern
filesystem.  Start simple and layer on top of that.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

incubator website is hosed

[Roy T. Fielding]

The /www/incubator.apache.org/ directory tree on minotaur contains
both a checked-out incubator-site *and* the generated output of a
forrestbot via incubator.  It obviously can't be both.
Personally, I've had my fill of this kind of crap being left on
our public infrastructure.  I shouldn't have to wait days to update
a trivial website.  If someone doesn't beat me to it, I am going to
replace it with Anakia tomorrow.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Add 'practice' PMC structure to projects in incubation

[Roy T. Fielding]

[Moved from the PMC list -- folks have got to stop proposing such
things on the wrong list.]
A long time ago, the name PMC was created in an attempt to genericize
the way that the Apache Group operated, using terminology that would be
easily understood by a judge or IRS inspector.  Unfortunately, the
name seems to have overwhelmed its history.  I described that in a
message to the members on March 12, 2003, which I'll include below.
However, I've been so overwhelmed with issues/fires this past year
that I never got around to fixing it.
Geir has proposed that we create practice PMCs (a.k.a. subprojects)
as part of incubation, and that we call them "Project Committers"
lists rather than PMCs.  I am +1 on the notion in general, but I
would prefer to call them core groups instead.  My rationale is that
"committer" privilege is a mechanism that we frequently give to
people on the basis of what they are planning to do, whereas the
core group are those people who have earned long-term voting rights
whether or not they happen to code.  Jakarta got into a weird state
wherein committer == voter and commit-access was given out like candy,
thus leading to the notion that committers run ASF projects.  I don't
believe it is appropriate to link voting with cvs access.
The key thing to note is that voting is a decision-making process
and we want that decision to be an ASF decision.  Furthermore, we want
the decision to be made as close to the volunteers doing the work as
possible, preferably by the volunteers themselves, whatever that work
may be.
The ability to make ASF decisions starts with the board and is
delegated to officers and their associated committees.  Anyone casting
binding votes (meaning votes that are counted toward making a decision)
must be listed as a member of the committee on which they are voting,
even if their votes are limited to a subcommittee.  Therefore, my
preference is for a fluid structure of incubating subprojects wherein
every voter is listed as being in one or more core groups and the
entire set of voters is listed as the incubator pmc.
I am aware that this would mean incubating projects would be able to
vote themselves out of incubation.  I think that if such a project had
their shit together to the extent that they could run such a vote and
get it past the majority of incubator members, then they no longer
need to be incubated.
....Roy

===
From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Date: Wed Mar 12, 2003  9:46:04  PM America/Los_Angeles
To: members   at  apache.org
Subject: PMCs gone wild
I am getting a bit frustrated at what appears to be a serious attitude
problem within the Apache projects.  A lot of people seem to wait around
until "the man" makes a decision, sometimes doing nothing other than
gripe about the lack of concern that "the man" has for their pet issue,
or simply believing that they are not allowed to do anything until
"the man" says it's okay to start.  I am not just talking about the
newer Jakarta projects: this attitude has become endemic throughout
the ASF, and folks are far-too-frequently suggesting that decisions
should be relegated to "subprojects" or that projects should be
"managed" by only a subset of the voters.
"the man" is usually their perception of a PMC as some other-worldly
land where benevolent beings ponder deep issues and create solutions.
[Sometimes "the man" is the ASF board, but that is very rare -- most
people have the sense to realize that the board's solution to a
squeeky wheel is to yank it off, throw it away, and install a new
wheel -- which usually isn't the effect desired by most wheels.]
I think I know what is causing this attitude, and sadly it points
back to one of the decisions I thought was a good idea when we were
crafting the ASF bylaws.  You have to understand some background
on that first...
The ASF bylaws were crafted by Drew Wright using a Delaware
nonprofit template and a ton of input from more than a year of
discussion amongst the Apache Group (circa 1998), discussion at
the post-ApacheCon'98 group meeting, and yet more discussion on the
old apache-core mailing list.  Our goal was to create a legitimate
corporate infrastructure around Apache without changing how Apache
decisions were made or the volunteer nature of the foundation.
By legitimate, I mean something that would be defensible in a court
of law if some asswipe were to sue the foundation for something we
did as a group.
The concept of a Project Management Committee was created in the
bylaws to be analogous to the Apache httpd core.  A PMC is the
legally sanctioned body authorized by the Board of Directors to do
things (e.g., approve changes, release code, etc.) on behalf of the
ASF for a given project.  Why?  Because it means that when the PMC
votes to do something, they are "doing" on behalf of the AS

Re: Add 'practice' PMC structure to projects in incubation

[Roy T. Fielding]

Secondly, given the original intent of the concept of a PMC, I am 
curious as to why the board permitted umbrella PMCs such as XML and 
Jakarta.
The board did not create umbrella PMCs -- XML was Xerces and Jakarta
was Tomcat/Watchdog.  They grew beyond that because their names implied
more, and nobody wanted to slow them down just because they had moved
beyond their original scope.  In fact, I had to threaten to shut them
down before the groups were even willing to restate their charters to
reflect what they had grown into.
Ultimately, it is very difficult (and often unreasonable) to insist that
a group of volunteers adopt a more rational set of self-management
principles, even when they run smack into the problems caused by their
own disorganization.  Status quo is such a warm and fuzzy place, and
most people just want to code on their own projects.  Besides, everyone
likes growth, and very few people like restructuring.
What some folks fail to understand is that a hierarchical structure,
like XML and Jakarta, does not reduce the workload of the board at all.
In fact, in my entire history on the board, I never once had to deal
directly with an issue on any of the single-level projects -- those
projects have always been self-governing because everyone in them
knows *they* are responsible for making the decision, not some other
group in "management".
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Incubate Apache Repo

[Roy T. Fielding]

-1: Repo is an American colloquialism that is short for "Repossession",
which is not something you want in a distribution tool.  You need
to find a neutral name.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Generated sites

[Roy T. Fielding]

Why do we need grand site publications schemes? Geronimo is using Maven
and it's trivial to site:deploy.
Umm, it took three weeks to find someone capable of running site:deploy
for Geronimo.  I think I was the third person who tried (and failed).
I think it would be better to build from CVS, but for that to happen
all of the site publishing groups need to cooperate and produce a
single build script (either on minotaur or some staging machine) and
have the complete set of publishing tools installed on that machine
so that we can regenerate the site.
 Why is it strictly the duty of
infrastructure to restore the site in the case of disaster? I'm sure
someone from a project would gladly work with infrastructure to restore
their site in case of a problem. Why does there need to be these grand
schemes for infrastructure and site publication?
Because of grand failures on the part of some projects to do exactly
what you assume above.  Sometimes we get a security-related problem
crop up that requires an immediate posting of information on the
relevant site, and it is truly amazing how often that coincides with
people going on vacation or simply not reading their e-mail.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Forwarding sf.net email to Apache Directory

[Roy T. Fielding]

We're going take Sander's advice here and would like to
make sure that all the following users are added to the
[EMAIL PROTECTED] list.  We will shutdown
the sf.net mail lists once we have confirmation that all
users have been added.
Why don't you simply ask those people to subscribe to the new list?
There are several reasons why we prefer that individuals ask to be
on our list rather than subbing them ourselves, which I don't want
to get into right now.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Official Name for "Geronimo" Project

[Roy T. Fielding]

Apache was named after the Apache tribes -- "a patchy" server was an
afterthought.  We've generally avoided any discussion of the topic
because involvement of a native american "activist" will only result
in trouble for us.  Those people are not Apache -- they don't even have
a clue.  The various tribes that are called Apache (by their enemies)
have more specific names for themselves.  Thus, we don't have any
complaints from the Apache people (only from white folks who think
they know better).
However, Geronimo is a real person.  He has descendants -- relatives
who are very much concerned about abuse of his name.  Moreover, I think
it is unethical to use such a name without permission, and I said so
when the Geronimo name was first suggested.  We have already received
more complaints specifically about the Geronimo name than we ever have
for using Apache, and it hasn't even been released yet.
To a certain extent, we can defend ourselves by how respectfully we use
these names.  However, I'd rather just use a name that is more 
suggestive
of technology rather than history.

Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Official Name for "Geronimo" Project

[Roy T. Fielding]

I honestly didn't think the use of the name in this context was an
abuse.
I don't think it is abuse -- he is a historical figure and he died
over 100 years ago, so there is no real fear of being sued for it.
I just think it is wrong.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Official Name for "Geronimo" Project

[Roy T. Fielding]

The project was initiated on condition that the name would be
reconsidered prior to becoming a TLP.  I don't really care at this
point, except to note that if we do get an objection regarding the
name from folks who have a right to object, then the project will
have to change its name and everyone who has coded to the geronimo
class names will be hosed (not that it matters much for a J2EE
container).  That objection is more likely to come from the other
companies using it as a trademark.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Official Name for "Geronimo" Project

[Roy T. Fielding]

Roy made a comment that a condition for leaving the incubator is that 
the
name be changed.  I hadn't heard that before, but those are two 
incompatible
views.
I said that the condition was that it would be reconsidered; basically,
that any comments to the effect that it is now "too late" or the name is
vested with too much press must be set aside -- eventually, either the
PMC or the members or the board (or perhaps all three) will vote on the
name and if any one of those mandates a change, the change will be put
in place whether the developers like it or not.  That is the condition
they were willing to accept, and I will hold them to it.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: projects incubated by the incubator PMC

[Roy T. Fielding]

There is no reason for a project to have a final destination until
it has to go somewhere other than incubator, at which point it can
decide whether it wants to be a TLP (calling for a board vote) or
part of an existing project (calling for that project's pmc to vote).
Maybe we should have a six month limit on incubation, where the
result is promote or punt.
We have no way to measure the worthiness of a project before it has
even started, and generally speaking we are MUCH MUCH MUCH better off
if a project gets started in Apache rather than on sourceforge.
I don't care if there is some overlap with Wagon, nor do I care for
any further discussion about which one is better -- if I can't find
some objective criteria for evaluating software, then I obviously
don't need that software. Once I need it, I can figure out for myself
which one is better -- I don't need someone to assume that for me.
It is easier for Apache to support both projects than to arbitrarily
choose between the two.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: projects incubated by the incubator PMC

[Roy T. Fielding]

I also don't think it's really that much work on the behalf of a 
project
trying to enter Apache to do a little leg work in resolving that before
entering.
I didn't say they shouldn't try -- I said it wasn't necessary.
As far as I am concerned, no existing project should be allowed
to create autonomous subprojects.  That means code which is not
destined for an existing project needs a temporary home until such
a time when the board feels it is ready to be autonomous.  Hence,
incubator was created to be a halfway house in addition to documenting
the transition of IP.
Clearly there should be some interest within Apache for the code to be
accepted. Either at the board level where things like Geronimo and Eve
have been discussed where upon successful incubation the project moves
to its designated TLP location. The other case being where some contact
has been made with one of the TLPs to accept the code upon successful
incubation.
It already requires participation of a member and a vote within the
incubator PMC, which is supposed to consist of all of the Apache members
who are interested in new project incubation.  The board tries to avoid
making technical decisions on behalf of the members.
I would propose those documents be changed to state that what is
outlined above is a prerequisite for entry into the incubator.
-1.  If the TLPs were supposed to be divisions of technology then
Maven would not be a TLP.  The only thing that distinguishes a TLP
from a piece of code adrift in cyberspace is that there exists a set
of people capable of governing themselves while collaborating on
development of that code.  Once that point is reached, the project
should be released from whatever bounds it happens to be within.
Your suggestion would require the board to do what it has already
assigned to the incubator, which the board specifically decided to
delegate in order to get more members interested in the process.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Re: request for incubation: axion database project

[Roy T. Fielding]

We need to finish voting here, but in the meantime go ahead and fill 
out a
new copy as axion.cwiki.  When the vote passes, we will make sure that 
you
and/or the DB PMC Chair has karma for the CVS module to check it in.  
Then
the PPMC can review it, and if there are no issues, we can probably 
hold a
consensus vote to clear it.

Work for you?  Anyone have any problem with the above?
Yeah, we already agreed that incubator does not vote on projects that
have been accepted by a PMC.  They are just "here" and need the stuff
set up for them.
Jason, incubator does not DO things for the project when it is destined
for an existing PMC.  The people who are working on the project are 
supposed
to record their own status, answer the status questions to the extent 
they
can do so, ask about any issues that have not been addressed, and 
finally
call a vote to exit incubation.  This is not a nanny service -- it is a
record-keeping gateway.

Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Re: request for incubation: axion database project

[Roy T. Fielding]

If this isn't constructive criticism, I don't know
what is.  Axion was told one thing, and now that
incubation time has arrive, they're being told
another.  That's the critical part.  I think we should
honor the original plan of incubation.  That's the
constructive part.
I don't believe for a second that your interpretation of Noel's
message is even remotely accurate, let alone an opinion of the
incubator PMC.  Please drop this argument NOW!
I have absolutely no tolerance for the whiny-ass bullshit that
has been descriptive of Axion so far.  Please concentrate on
filling-out the documentation of the IP transfer so that the
project can become part of the DB project.  IT IS NOT PART OF DB
AT THIS POINT IN TIME, AND WILL NOT BECOME PART OF DB UNTIL THE
DOCUMENTATION IS PRESENT IN THE INCUBATOR CVS.  If you don't like
the web site restriction, then don't publish a website until the
incubator has transferred Axion to DB.
The reason for this policy is because prior incubated groups
violated the trust we gave them.  Feel free to delete their sites
if you feel the need for ancestral equality.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] graduate MerlinDeveloper from incubation

[Roy T. Fielding]

+1

Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: incubator/site/projects gump.cwiki

[Roy T. Fielding]

Normative material seems to indicate otherwise. Reference?
Moving an Apache project to TLP is a decision by the board.  They
might ask incubator to help do something, but they haven't yet.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RESULT] JaxMe has now graduated (Fwd: Re: [VOTE] Graduate JaxMe from incubation)

[Roy T. Fielding]

There was a VOTE on [EMAIL PROTECTED] and we are VOTE'd to graduate JaxMe. 
Please go ahead and adjust
the web site and wish you all best of luck :)

thanks,
dims
Dims, as I have mentioned before, we cannot vote on such things
on a private list, which is why I did not vote and why you did not
receive sufficient +1s to graduate from incubator.  I have no
objection to moving ahead, but right now the only vote you have
is my +1.  Please record the votes by incubator PMC members on the
public list.
Private voting is only allowed for personnel issues, NDA-covered
issues, and security-related issues prior to their public release.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Patents & ASF policy

[Roy T. Fielding]

what happens if a ASF sponsored project (lets take jakarta for example)
is the subject of a patent dispute say 2-3 years from inception.
We either ask the patent owner for a license or wait until the patent
owner demands we have one, depending on the nature of the patent.
and lets say that the patent is valid, enforcable, and the patent 
holder
decides he wants to do something.

what happens to jakarta then?
Most likely, the project in question is placed on hold until the
matter is resolved.
what risk/options does the ASF have in this case?
The ASF's only risk is that of willful infringement.  Basically,
if the ASF has been informed that a patent is applicable to ASF 
software,
the ASF is responsible for obtaining a license.  Failure to do so places
the ASF at risk of litigation for the owner's lost revenue, and the
ASF's users at risk if they are using our software to generate revenue.

Most companies reduce that risk by forbidding their own employees
from performing patent searches.  That prevents them from being
subject to any form of damages for use up until the time when the
patent owner formally notifies the company of a covered patent.
That is why it is generally a bad idea to look for patents that
might be applicable, and an even worse idea to inform the board
of your opinion of such applicability, at least until the patent
owner begins to publicly seek licensing from the ASF or its users.
Very few patents are ever enforced, aside from cross-licensing deals.
FYI, almost every aspect of computing is claimed by multiple US
patents.  The only saving grace is that patent claims are written
in such an obscure way that only a court can determine their
applicability. As a result, a substantive patent defense requires
millions of dollars in legal fees.  The ASF's ability to win such
a defense will largely depend on the nature of the patent and the
tactics used by the owner for licensing.  Patent owners, however,
are unlikely to target the ASF itself -- instead, they sue the
companies that redistribute ASF software as part of a larger,
revenue-generating product.  Therefore, our primary concern regarding
patents, on behalf of the ASF community, has been the prevention of
deliberate contribution of patented algorithms that the contributor
could later use to collect a fee from all of the users.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Pluto

[Roy T. Fielding]

+1

Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: contributions and CLAs

[Roy T. Fielding]

It's also interesting to note that the current ASF license,
"Apache License 2.0" (http://apache.org/licenses/LICENSE-2.0),
includes text (see paragraph 5) that basically says that any
time someone makes a contribution to Apache, they are implicitly
agreeing to license their contribution under the Apache License.
It's not completely clear to me how enforceable this is, especially
relative to a CLA or Software Grant, but it's in there.
It isn't "enforceable" at all (nothing less than a signed contract
is ever truly enforceable, and even then only if there is a clear
agreement that benefits both parties).  It is, however, defensible:
a bad person cannot legitimately claim that they read and
understood the license (a condition necessary for legal redistribution),
submitted contributions, and then expected Apache or its customers
to pay for a copyright or patent license for those contributions.
It sets an expectation on contributions for the community as a whole,
rather than relying only on CLAs from the relatively small subset
of the community that are committers.  In other words, it reduces
our liability, or at least that is the hope.
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Beehive

[Roy T. Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Beehive

[Roy T. Fielding]

I would like to get personally involved in this project.  I'll add
myself to the ppmc and dev lists when they are created, but whether
or not I am listed as an initial committer I'll leave up to the
folks proposing the project [OTOH, if I am, that will pretty much
obligate me to stay involved, at least through incubation].
Regardless, it will take some time for me to get up to speed before
I'd be able to make any significant code changes, and I'm not shy
about sending in patches until I've proven myself.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Geronimo from Incubator and recommend as top-level project

[Roy T. Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

stop CCing the pmc lists

[Roy T. Fielding]

Under no circumstance is it ever appropriate to cc the pmc list
when talking on a public list.  Just don't do it.  The only reason
we have that list is to talk about things that cannot be discussed
in public.  It is not "where the PMC lives".  It is not necessary
to get the "PMC's attention".  The PMC are the people paying
attention to the general/dev list *and* recognized as having binding
votes -- anyone not paying attention to general is considered absent
from the project until they have more time to get involved.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Request creation of new mailing lists

[Roy T. Fielding]

On Monday, May 24, 2004, at 02:47  PM, Cliff Schmidt wrote:
Based on the Incubator's approval* of the Beehive project, please
create the following public mailing lists and enable them to be
viewable through Eyebrowse:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Done.  I have sub'd Cliff to both lists, as well as the beehive-ppmc
list.  This would be a good time to ask all the committers to subscribe
themselves to the lists.
I have set up the archive on /www/incubator.apache.org/mail/
but someone else will have to enable eyebrowse.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release

[Roy T. Fielding]

On Friday, June 11, 2004, at 04:01  AM, Leo Simons wrote:
[is the rule that a project just needs 3 independent committers, or is 
there an additional rule that no more than 50% of the committers must 
be part of a single company?]

IIRC that 50% rule applies, but IANAL. Roy, Nicola?
I have no idea where that 50% stuff came from.  The goal of having at
least three independent members of the project PMC (*committers* has no
decison-making role in the foundation, even when committers == PMC)
is to make sure someone is able to veto stuff that would get
us in trouble.  50% would be nice, but not necessary unless we are
talking about the ASF board.
I don't know if this should even apply to code that is being
inserted into an existing project.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The 50% Rule (was RE: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release)

[Roy T. Fielding]

Personally, I'd like to see one or two quantitative rules (such as one
about independent committers to allow for vetoes) and then leave the 
rest
up to a voting body that will evaluate graduation against some general
guidelines.  I also think the voting body should be the PPMC, which is
made up of the project's committers, the PMC members of the destination
TLP (or the Board if destined to be a TLP itself), and interested 
members
of the Incubator PMC.  This means that after meeting some minimum
requirements, the project members along with experienced members of the
Apache community, who have been watching and participating in the
developing project, would evaluate the overall health of the community
and vote accordingly.  Before Roy says anything ;-), I realize that the
PPMC isn't part of the Bylaws and therefore wouldn't mean anything
official on its own, but maybe that's where the Incubator PMC would
ratify the PPMC's decision with a vote in favor, assuming the basic
process was observed.
Not quite. The PPMC is a subgroup officially established by the
incubator PMC, containing a named list of individuals who have agreed
to participate on the PPMC.  As such, they are covered by the PMC
clauses of the bylaws as far as decision-making goes.  The only
difference is that the PPMC does not have the authority to release
software on behalf of the ASF, whereas the PMC does.  Other than that,
we want the PPMC to make its own decisions, including when to recommend
a snapshot release and when to request exit from the incubator.
The incubator PMC makes its own decisions based on that input, which
isn't the same as ratifying someone else's decision.
Before someone starts complaining about bureaucracy, please understand
that the only reason a "corporation" differs from a sack of individuals,
and thus individual liability, is because there is active group
oversight of decisions made on behalf of the corporation for the sake
of the corporation.  That applies for a nonprofit even more so than a
for-profit, since our process has to be valid for both the Delaware
corporate laws and the IRS guidelines.  The safest way to do that is
to assign responsibilities to specific committees and keep records
of their decisions (and how those decisions were reached).
Personally, the only quantitative rule I want to see is at least
three independent committers capable and willing to become the
destination PMC.  The reason is because people tend to change jobs
fairly frequently, especially when a new company decides they want
to make a project part of their revenue stream *while* contributing
to the open source side.  Companies should not face artificial
barriers against hiring the developers who work on our projects.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate SpamAssassin from Incubator, recommend TLP

[Roy T. Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate XMLBeans from Incubator and recommend as top-level project

[Roy T. Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept MyFaces for Incubation

[Roy T . Fielding]

+1 (never been much for voting templates)
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: summary on Lenya vote?

[Roy T . Fielding]

On Tuesday, August 10, 2004, at 12:52  PM, Michael Wechner wrote:
Noel J. Bergman wrote:
I assumed that no votes would be counted as positive silent votes
Nope.  There is a notion of "Lazy Consenus", but silence is not a  
vote.

Please apologize if I don't fully understand, but how
do you define "lazy consensus"? Does it make sense if I try
to encourage the PMC members
http://incubator.apache.org/ 
whoweare.html#PMC+%28Project+Management+Commitee%29

to cast their vote?
It means that a minimum number of PMC members must vote to indicate
that sufficient peer review has taken place.  That means three
binding +1.
I abstain (+0) because of the potential for a perceived conflict
of interest.  I have not reviewed the status of Lenya as a project.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Accept JCR for Incubation

[Roy T . Fielding]

ied developers
   JSR 170 is supported by over 22 independent companies. It is hoped
   that they will all want to participate in this project as well once
   incubation is under way. The initial committers include individuals
   from seven independent organizations.
1.1.2.5. No ties to other Apache products
   This work has been envisioned from its beginning to become an Apache
   project, within the constraints imposed by the Java Community Process
   (argh!). We have kept the RI development visible through parallel
   commits to the Slide CVS. As described above, we expect this
   implementation to be used by several existing Apache projects.
   A software grant will be signed to allow Apache to distribute the
   entire code base under the Apache License 2.0.
1.1.2.6. A fascination with the Apache brand
   The committers are intent on developing a strong open source  
community
   around JCR. Apache was chosen because of the people involved and the
   emphasis on collaboration. Day Software is committed to supporting  
the
   future open source development of JCR and to distributing the result  
of
   that development as the official RI and TCK for JSR-170.

1.2. Scope of the subprojects
   RI, TCK, related tools, and website.
1.3. Identify the initial source from which the subproject
 is to be populated
   All code is currently licensed under the Day RI License 2.0, the same
   addendums to the Apache License 2.0 that have been discussed on  
Apache
   licensing lists. The code base will be licensed to the ASF using a
   software grant from Day, allowing Apache to relicense as pure Apache
   License 2.0 code. A factual notice should be added to the  
distribution
   to indicate that only the official version of the TCK can be used to
   "pass the TCK", but that will not be a condition on the software  
grant.

1.4. Identify the ASF resources to be created
  1.4.1. mailing list(s)
 * jcr-ppmc via incubator.apache.org (with moderated subscriptions)
 * jcr-dev via incubator.apache.org
 * jcr-commits via incubator.apache.org
  1.4.2. CVS repositories
 * incubator-jcr
  1.4.3. Jira
 * JCR project with categories for RI, TCK, Tools, Docs
1.5. Identify the initial set of committers
 +---------+
 |Roy T. Fielding  |Day |ASF, httpd, APR, incubator|
 |-++--|
 |Stefan Guggisberg|Day |Slide |
 |-++--|
 |Stefano Mazzocchi|MIT |ASF, Board, Cocoon, Gump  |
 |-++--|
 |David Nuescheler |Day |  |
 |-++--|
 |Peeter Piegaze   |Day |  |
 |-++--|
 |Gianugo Rabellino|Pro-netics  |ASF, Cocoon, Xindice  |
 |-++--|
 |Tim Reilly   |Independent |Jakarta-Commons   |
 |-++--|
 |Marcel Reutegger |Day |  |
 |-++--|
 |Paul Russell |Independent |Cocoon|
 |-++--|
 |Andrew Savory|Luminas |Cocoon|
 |-++--|
 |Tobias Strasser  |Day |  |
 |-++--|
 |Sylvain Wallez   |Anyware Technologies|ASF, Cocoon, Avalon   |
 +---------+
1.6. Identify Apache sponsoring individual
 * Roy T. Fielding, champion and mentor for the project,
  (as defined in
  
<http://incubator.apache.org/incubation/ 
Roles_and_Responsibilities.html>)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept iBATIS for Incubation

[Roy T . Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept JCR for Incubation

[Roy T . Fielding]

What are the chances that you would consider Subversion instead of CVS?
We are already using cvs.  Subversion would be an added distraction,
and I am not yet convinced that it is adequately protected against
database corruption and password guessing.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: MyFaces?

[Roy T . Fielding]

Could someone aware of its status please add MyFaces to the
incubator projects section, like the other incubating podlings:
  http://incubator.apache.org/projects/index.html
  http://incubator.apache.org/howtoparticipate.html#Updating+the+site
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] Accept JCR for Incubation

[Roy T. Fielding]

With nine binding +1 votes [*] (plus two non-binding +1s) and
no negative votes, the JCR proposal
   http://wiki.apache.org/incubator/JcrProposal
has been accepted by the incubator PMC for the creation of a
new incubator-jcr podling.
Once I find where the templates have been stashed, I'll start
creating the status files, mailing lists, etc.  In order to save
infrastructure some work, the developers have decided to start
with SVN instead of CVS.
Roy
[*] binding +1s from Roy T. Fielding, Noel J. Bergman,
Nicola Ken Barozzi, Berin Lautenbach, Leo Simons, Greg Stein,
Cliff Schmidt, Geir Magnusson Jr., and Jim Jagielski.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: assist with Incubator website

[Roy T . Fielding]

On Sep 6, 2004, at 5:37 AM, David Crossley wrote:
As i have said in other threads i would like to assist more
with the Incubator website. This would be the case no matter
what documentation system is going to be used. So would i have
karma to commit to the Incubator CVS.
Karma is granted.  Thanks for your help,
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RESULT] Accept JCR for Incubation

[Roy T. Fielding]

I was working on the initial docs and mailing lists over the weekend
and got stuck on making a distinction between the JCR API (JSR 170)
and the Apache podling creating an implementation of it.  As Gianugo
said on the Slide mailing list
   ...my first proposal would be rethink the name: jcr or jcrri
   aren't "product" names, and they smell bad of "just" RI
and we actually came up with a better name internally at Day:
Jackrabbit 
I am going to be lazy and just create the initial lists under that name
and will change it if the PPMC objects.  I already did the nameprotect
search and it is clean, and "Lepus californicus" (not kidding) happens
to reside in the same lands as the Apache tribes.
In other news, Jim ack'd receipt of the CCLA/grant from Day and most
of the initial committers already have CLAs on file, so we are ready
to get started.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby code copyright question

[Roy T . Fielding]

That is correct. 2 main issues with any codebase
that the ASF develops is that (1) it be under the
Apache License and (2) that the Copyright be assigned
to the ASF.
So it must be licensed "by" the ASF (via the AL) and
"owned" by the ASF.
That is not correct: CLAs and software grants are licenses,
not assignments.  Larry Lessig says that the code should retain
each contributor's copyright.  Apache has traditionally used the
Apache copyright alone to make it clear that everyone is contributing
to a joint work, and to avoid issues with ego and territory building.
Nevertheless, copyright remains with the original contributor and
only the copyright owner can change the notice.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby code copyright question

[Roy T. Fielding]

On Sep 15, 2004, at 2:55 PM, Jennifer B Machovec wrote:
I think the short-term (and maybe even long-term) resolution to the
copyright notice issue may be having the ASF copyright notice in each 
main
file clearly apply to the whole project.  This could read, for example:
"Apache Derby is (c) Copyright The Apache Software Foundation 2004. All
rights reserved. "  Then there's no implication of copyright ownership 
of
individual components.  The third-party copyright attributions can be
included in the NOTICE file.
We need to limit NOTICE to acknowledging major contributions and
fulfilling the advertising clause of third-party code.  It would
be a disaster if everyone with a copyright wanted to be in there.
As Roy notes, if any contributor has
included copyright attributions in a main file, and you don't want to
retain those notices in that location for policy reasons, then ASF 
needs
to ask the contributor/copyright owner to either remove them or 
authorize
ASF to do so on their behalf.
Larry Rosen (I mentioned the wrong Larry in the previous note)
suggested that we place something like
 Collective work Copyright 2004 The Apache Software Foundation.
 [AL 2.0 Template]
 Derivative work Copyright 2004 Some Other Contributor.
 Licensed to the ASF under a contributor agreement.
 Copyright 2004 Contributor Company, Inc.
 Licensed to the ASF under a contributor agreement.
The alternative being that we start asking for copyright assignments.
BTW, I don't claim that my workaround of having the copyright owner
change the copyright notice to the ASF is necessarily the right
solution; it just happens to be the one we've used in the past
and actually predates forming the ASF as a legal entity.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby code copyright question

[Roy T. Fielding]

 Collective work Copyright 2004 The Apache Software Foundation.
 [AL 2.0 Template]
 Derivative work Copyright 2004 Some Other Contributor.
 Licensed to the ASF under a contributor agreement.
 Copyright 2004 Contributor Company, Inc.
 Licensed to the ASF under a contributor agreement.
So Corporate entities get special handling (i.e., all I have to do is
form an LLC and I can get my self listed in the notice file)?
No, those copyright notices would be for every legitimate copyright
owner of the contents of each source file -- an owner is necessarily
an individual or legal entity.  That means each individual or legal
entity that contributes something copyrightable on its own that ends
up in a given file would be listed within that file.
Note that this was only a suggestion offered as a possible solution.
It was not given as advice, legal or otherwise, nor was it offered
as the best solution.
The problem with such a scheme is that, to be fair, we would have
to go back through the archives of each project, determine the
actual copyright holders, and ask if they want to be named by
a copyright notice.  Some will, some won't, and this will inevitably
lead to an ego war over the fact that some of the least-contributing
individuals will be more prominently named throughout the source
code than those who contributed 80% or more of the code.  Furthermore,
contributions that came from employed individuals will most likely
need to acknowledge both the individual and their employer(s).
Even worse, some of the lawyers for some of those companies will
erroneously claim that they own all IP generated by their employees,
and will therefore object if we do try to name them as individuals.
This is a lose-lose situation, which is why we spent so much time
and effort trying to avoid it.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby code copyright question

[Roy T . Fielding]

On Sep 24, 2004, at 4:27 AM, Rodent of Unusual Size wrote:
okey, after discussing this in seven different directions, we
have a clear conclusion, which i'll summarise here:
A conclusion by whom?  The board?  Robyn?  IBM?
1. the NOTICE file (or NOTICE.txt) gets created if it doesn't
   already exist, and this gets added to it:
Portions of Apache Derby are © Copyright 2004 International
Business Machines Corporation.  All rights reserved.
-1  The NOTICE file cannot contain restrictions on the license.
"All rights reserved" is a restriction -- it is contradicting
the irrevocable copyright license.
   if there are earlier copyright years in any any of the main files,
   the earliest one of all should be taken and used to change the 
notice
   to 'Copyright , 2004 International ..'.  in other 
words,
   the range of copyright years in the NOTICE file should be the 
earliest
   one with IBM's name on it in the sources, followed by ', 2004'.

2. the ibm copyright in the individual files gets replaced with
Apache Derby © Copyright 2004 The Apache Software Foundation.
All rights reserved.
   and reference to the apache licence added as described in
   http://www.apache.org/licenses/LICENSE-2.0.html#apply
et vóilà!  that item can then get checked off the incubation goal list
and we can focus on *real* code issues. :-)
No, it does not.  It means the code in the individual files is not
licensed under the AL2.  It means that if someone wants to take an
individual function out of an individual file and add it to their
wizz-bang programmable dog, they have to ask permission from IBM.
In short, their is no F*ing way this is going into code at the ASF.
The copyright notice in the file has to say THIS FILE MAY BE COPIED
under the terms of the Apache License.  It cannot just say "Apache
Derby" may be copied, since that name is not bound to any specific
expression, and copyright notices that are not bound to an expression
are null and void.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] How to prevent abusing Apache priviliges

[Roy T. Fielding]

Never cross-post to community.
what if incubating mentors would abuse their powers to interfer with 
the
normal evolution of Apache incubation projects.
What is "normal evolution"?  For that matter, what are the mentor powers
that you are speaking of here?  Mentoring is a burden, not a power.
I think that mentors could write off-list mails to possible committers
and discourage them to committ to a incubating projects. On the end 
this
mentor could recommend to the possible incubating committer to work on 
a
*NON* apache project instead of the incubating project.

THAT WOULD BE A VIOLATION TO THE APACHE WAY TO DO THINGS!!!
Well, it might be -- it really depends on why the mentor is suggesting
such a thing.  For example, if someone were to try to contribute GPL
code to an Apache project, my response would be along those lines.
Is this a rhetorical question, or do you have some specific example
in mind that you want corrected?  Keep in mind that mentors are human
too and they sometimes make mistakes.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: http://incubator.apache.org/projects/agila/

[Roy T. Fielding]

We should create https://svn.apache.org/repos/asf/incubator/agila, and  
move
https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/ 
project
s/agila to wherever under the agila project's structure you want to  
keep
your site sources.  The same is true of the generated artifacts, which  
you
will want to check out under /www/incubator.apache.org/agila/, so that  
the
URL is incubator.apache.org/agila/.
I did that with Jackrabbit and it turns out to be a mistake -- the
generated website is five times larger than the source due to the
exponential effect of maven automation.
It is better to have incubator/agila/trunk
  ../tags
  ../branches
  ../site-publish
so that non-site developers don't need to update that baggage.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby code copyright question

[Roy T. Fielding]

On Oct 4, 2004, at 7:23 AM, Rodent of Unusual Size wrote:
Jennifer B Machovec wrote:
I thought it might be helpful to give some background on the "all 
rights
reserved" phrase.  The requirement for this phrase originated in the
Buenos Aires Convention of 1910, which provided that a copyright 
owner had
to make an express statement of the reservation of property rights in
order to have copyright protection in all countries that were party 
to the
convention.  Because of subsequent changes in copyright law that I 
won't
bore you with (but can if you really want), this phrase 
essentially
became useless for works first published in the United States and most
other North and South American countries.  However, there are still a 
few
countries in which this is a meaningful declaration, and for that 
reason
IBM (and many other copyright owners, including ASF in its standard
notice) retain this phrase to avoid such an exposure.  It does not in 
any
way change or restrict license grants that are made by the copyright
owner.
The phrase, "All rights reserved", is a formal notice that all
rights granted under existing copyright law are retained by
the copyright holder and that legal action may be taken against
copyright infringement.  It means the same thing now as it did
in 1910, even though the Berne Convention made it a default.
Among other things, it places the recipient on notice that the
copyright owner may exclude others from copying the work in
the future, regardless of how this copy was obtained.
It is the default. Stating it explicitly just reaffirms the
default.  Stating it in combination with "... licensed under
the terms of the Apache License 2.0" is a contradiction, which
is generally a bad thing and especially so when we are talking
about rights that are already difficult to give away.
That is why it is not in any of the "notice templates" given by
modern open source licenses.
As far as the copyright notice in the individual files, while I'm not
certain that there is a problem regarding the Apache Derby reference, 
it
would be consistent with the ASL v.2.0 instructions to add a notice
stating: "Licensed under the Apache License, Version 2.0 (the 
"License");
you may not use this file except in compliance with the License."  
That
should remove any ambiguity.
roy, does that answer your concerns or not?
Well, those are the words that our template uses, but they don't
belong in the NOTICE file.  The NOTICE file contains only those phrases
that we insist must be displayed in places like the About box of a
binary-only release.  It is not a list of copyright notices.
In any case, the licensing work on 2.0 was done with the assumption
that ASF works would be under Copyright The Apache Software Foundation.
Failing to have that in the code at the beginning of the project means
that later Contributions to the project are implicitly made to IBM,
not the Apache Software Foundation, and we in fact have no rights to
that code other than those granted explicitly in CLAs.  In short, there
is no end to the grief caused by this "oversight", and it won't be
solved short of getting a copyright assignment, or at least behaving
as if such an assignment exists.
The only notice other than the simple ASF copyright that makes sense
is the explicit notice list that I forwarded to the board, which
lists the ASF and all copyright owners and explicitly states that
each copyright owner has licensed their work to the ASF under a
contributor's agreement.  It is messy, but at least it is both factual
and consistent with the Contributor definitions in AL 2.0.
That is my opinion.  I asked the board to get Robyn's opinion on
any other alternatives, so that is where you should pursue some
kind of resolution.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

STATUS: Jackrabbit

[Roy T . Fielding]

The Jackrabbit project has completed all of the Incubator checklist
items in terms of moving to Apache and getting the IP transfer done.
With the help of Maven, we have a full website set up at
   http://incubator.apache.org/jackrabbit/
with a few link bugs due to the svn/viewcvs integration.  Our big
task from now to graduation is to get the community more involved
in development, planning features, integrating with some of the DB
projects, and scoping out interesting applications to build on top
of the interface.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Proposal for Castle

[Roy T . Fielding]

Please vote on the Castle incubation proposal:
   http://wiki.apache.org/incubator/CastleProposal
-1.  Find more people interested in the project.
Sorry, but I have nothing positive to say about containers in terms
of engendering useful communities, let alone CLI containers.
And I am not going to vote for another "project" with 3 committers.
So, I think you need to find enough people to form a critical mass,
since we don't have the resources to start up projects that don't
have a reasonable plan of supporting themselves in the future.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Idea of JCMS

[Roy T . Fielding]

There is no problem.  There is no reason at all for any one project
to "own" the CMS space at Apache.  It makes sense for Slide to replace
its back-end with Jackrabbit for one and only one reason: such an
architecture will enable substitutability of its back-end and simplify
Slide's implementation.  If that does not turn out to be the case,
then none of us would want Slide to use Jackrabbit and I see no
reason to badger them into doing so.  Likewise for Lenya, JCMS,
and whatever else may come next.
What we would like to see is all of the folks who think they might
need a JVM storage management interface to get involved in the
Jackrabbit project, try to use it to build useful things, tell us
all when problems are encountered (preferably right now, while the
JCR specification is still easy to change), and through that
interaction make Jackrabbit something more useful than just another
JSR interface.  That is a heck of a lot more useful than just waiting
to see what code the current project developers turn out.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Directory project releases

[Roy T . Fielding]

-1  The incubator status file does not reflect any progress towards
clearing the IP (you MUST update that file).
Furthermore, the release artifacts use names that are trademarked and in
use by other projects.  Some questions need to be answered, while others
require a rename:
  1) Has Matt Walsh approved transfer of the SEDA name?  Is that library
 a direct descendant of , in
 which case the version numbering should be 4.0, or does it merely  
use
 his architecture (in which case it is wrong to use the name)?

  2) Eve is a trademark of CCP Ltd. for use in on-line software.  We  
cannot
 legally distribute software under that name.

  3) Janus is a trademark of Janus International Holding Co, which has
 actively defended it in other contexts:
  
.
 Janus is also the name of several software projects and at least  
one
 software company.  I do not consider it sufficiently free of risk  
to
 be used as the name of an Apache product.

  4) Snickers is a trademark of MARS, Inc.  It is actively defended and
 used on-line, and thus unlikely to be usable by the ASF for more  
than
 a few months before they send us a Cease & Desist.

  5) Kerberos is a trademark of MIT.  We cannot legally distribute  
software
 under that name.

It is the responsibility of all Apache projects to search for and verify
compliance with trademark law prior to release of products that might be
considered an infringement.
Roy
On Dec 27, 2004, at 10:33 AM, Alex Karasulu wrote:
Hello,
We at the Directory Project (under incubation here,  
http://incubator.apache.org/directory) have been preparing to release  
from the incubator.  The major subprojects that shall release  
artifacts if this vote passes are listed below with a release version,  
a short description, and a link if more information is needed to  
partake in this vote:

eve (0.8)
  - a pure Java LDAP directory server and LDAP JNDI provider
  - http://incubator.apache.org/directory/subprojects/eve/index.html
ldap (0.8)
 - common LDAP libraries
 -  
http://incubator.apache.org/directory/subprojects/directory-ldap/ 
index.html

naming (0.8)
 - a lightweight, in-memory JNDI service provider
 -  
http://incubator.apache.org/directory/subprojects/directory-naming/ 
index.html

janus (0.2)
 - an Authentication, Authorization and Accounting (AAA) framework
 - http://incubator.apache.org/directory/subprojects/janus/index.html
snickers (0.2)
 - high performance non-blocking replacement for the Snacc4J runtime  
(ASN.1 runtime)
 -  
http://incubator.apache.org/directory/subprojects/snickers/index.html

kerberos (0.4)
 - a pure Java kerberos server implementation
 -  
http://incubator.apache.org/directory/subprojects/kerberos/index.html

seda (0.2)
 - a networking framework used by Kerberos and LDAP servers
 - http://incubator.apache.org/directory/subprojects/seda/index.html
We have prepared all jar artifacts so they contain 100% ASF owned  
code, the incubator disclaimer, the ASL 2.0 and the standard  
NOTICE.txt in accordance with incubation policies regarding releases.   
All release artifacts also are maven generated artifacts whose group  
IDs are set to incubator-directory to clearly show the code's  
incubation status.
On behalf of the Directory Project Team, I would like to initiate a  
vote to release these versions of the artifacts in projects under the  
the Directory  umbrella:

[ ] +1 Approve the request to release
[ ] -1 Reject the request to release
[ ] +0 Abstain
Wishing you and yours a Happy New Year!
The Directory Project Team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduating log4cxx

[Roy T . Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Directory project releases

[Roy T . Fielding]

Niclas Hedhman wrote:
Janus is "God of Gates and Doorways" and a moon of Saturn was named 
after him in 1966.
http://solarsystem.nasa.gov/planets/profile.cfm?Object=Sat_Janus

The sited web page is about arbitration of a domain name and to 
regain control of such domain name. Janus Capital Group does not seem 
to go after every use of Janus, so it is not a matter of trademark 
issue;
http://www.janus-software.com/
http://www-odp.tamu.edu/database/
http://www.janus-eu.org/Temp2/index-f.htm
http://www.janusassociates.com/
http://www.janusdevelopment.com/
No, that is not how trademark law works. It doesn't matter how common 
the
name may be -- what matters is whether the name is distinctive within a
given category of use (keeping in mind that these folks are on the 
Internet
as well) such that they may have grounds for filing suit on the basis 
of us
confusing their consumers.  I didn't say that they would need to win 
that suit.

My point was that the Janus name, like those of all Greek/Roman gods,
is already being used by a dozen or so software projects, including some
open source ones, in addition to there being a wealthy litigation firm
concerned about use of the name on the Internet.
Using Janus as a name for a new product is therefore unwise.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Directory project releases

[Roy T . Fielding]

On Dec 27, 2004, at 8:16 PM, Alex Karasulu wrote:
Before discussing each specific item below I'd like to point out a few 
things.  The ASF had through the incubator given us a link to an 
online service for looking up trademarks.  We were told this service 
should be used to determine if there were any infringements with 
project names.  I personally used the service for two of the names 
cited in the items below.
We normally start with that and also do a Google search.
According to the ASF the existance of any trademark alone was not an 
issue.  For there to be an infringement the trademark would have to 
fall within the same field and domain where the names also match 
exactly.  In the case of the Eve Directory Server for example, the 
presence of a trademark for "Eve Online", an online game would not be 
an infringement.  I understand your concern but this is not the same 
name. BTW note that "Eve Online" did not exist in 2002 when we first 
started using the name Eve Directory Server for this project.
Apparently, the same company has a trademark on "EVE" in Europe and 
they have
already used it to force a hardware company in the UK to rename their 
product.
Here is their Icelandic registration
http://www.els.stjr.is/focal/webguard.nsf/key2/br103-2001.html

From the language and terms on the incubator site I was completely 
under the impression that this kind of name use would not present any 
legal issues.
Goal #1 is "do the right thing".  Goal #2 is "protect our assets".
  1) Has Matt Walsh approved transfer of the SEDA name?  Is that 
library
 a direct descendant of , 
in
 which case the version numbering should be 4.0, or does it 
merely  use
 his architecture (in which case it is wrong to use the name)?

No there is no relation between our seda package and the SEDA project 
on Sourceforge.  We just named this thing, seda because we had no name 
for it at the time.  SEDA is what it is as far as the architecture 
used.  It's like naming a cat, cat.  I think the SEDA project on 
Sourceforge actually calls the respective code with the same fuction 
Sandstorm.  SEDA is an acronym used for Staged Event Driven 
Architecture as you probably already know.  It was part of Matt 
Welsh's doctoral thesis and hence the name and the technology is not 
something that can hold a trademark.  At least this is my 
understanding - perhaps this can be clarified by legal.
Sorry, software products are not named "product" -- they are given 
names to
distinguish them from other software.  We do not use other people's 
existing
names without their permission because it would confuse everyone, 
including me.
[We learned that the hard way with httpd, even though we had 
permission.]

Matt's toolkit may be code-named Sandstorm, but it is distributed as 
seda on
Sourceforge.  You should name it something like "sedakit" (which 
probably means
something in another language) or "apseda" (which may be Latin, for all 
I know).

Furthermore the concept of Threads for example was invented by some OS 
manufacturer but there are threads implementations all over like 
pthreads.  When does it become an infringement?  If we call a SEDA 
implementation seda?  See what I mean? Its kind of nebulous here.  I'd 
like some clarification myself. Regardless I'm totally fine with 
changing the name here.
I doubt that Matt trademarked the name -- we should simply "do the 
right thing"
and avoid confusion.

  2) Eve is a trademark of CCP Ltd. for use in on-line software.  We  
cannot
 legally distribute software under that name.

At a closer glance I noticed the trademark is "Eve Online" and not 
really Eve.  "Eve Directory Server" is not the same name and it does 
not infringe on this trademark.  I do understand your concern though 
but where do we draw the line.  Also for the record we had the name 
Eve before they did.  Sounds silly but true.  We've been under 
incubation for a long time now 14 months and when I checked in the 
begining they where not even on the map.
Not according to their registration in EU -- it is 2001.
  4) Snickers is a trademark of MARS, Inc.  It is actively defended 
and
 used on-line, and thus unlikely to be usable by the ASF for more 
 than
 a few months before they send us a Cease & Desist.
Snickers is an ASN.1 software library which is a Snacc4J replacement.  
It's obviously not a candy bar.  Do they really have the right to 
enforce a Cease and Desist?  This is definately trademarked by MARS as 
you say no doubt about that.  We need to rename this as well but just 
for clarification how do companies like this get away with it?
They don't need the "right" -- they merely need to avoid a countersuit 
for
obstruction.  Because it is a well-established mark and that mark is 
used on the
Internet, they can reasonably constrain use of it on websites.  Since 
the
name is being used because the real Snickers is a snack, we are 
actually using
the trademarked nam

Re: Question about project names.

[Roy T . Fielding]

On Dec 28, 2004, at 6:22 PM, Trustin Lee wrote:
I'm the author of MINA (Multipurpose Infrastructure for Network
Applications) subproject in Apache Directory project.  We are checking
our project names before releasing them.  I checked the name 'MINA',
and I found three trademark holders.  None of them are software or IT
companies.
I found two non-US companis whose names are 'Mina software' and 'MINA
systems' and Forth language interpreter called 'Mina.com'.
The language interpreter is Mina.  Mina.com appears to be a search site
for music.  Neither one seems to be well-known.
This is a gray area because you are using it as an acronym.  OTOH,
your name behind the acronym isn't very descriptive -- is it another
container kit?
I want to know it would be OK if I use the name MINA.  I've been
thinking it is OK ecause MINA is just a girl's name and means 'south'
in Japanese.  It is also just a girl's name in South Korea.
That doesn't matter.  Common names can be used as trade names provided
they are distinct within a given market.  Would our product be the only
one named Mina in the software market?
Google doesn't see anyone claiming it as a trademark.  If you really 
like
that name, I doubt it will be a problem, but keep in mind that we will
have to change it if one of those pre-existing companies complains.

FYI, I really don't like this trend of independent projects being 
created
within umbrella projects.  If you are creating a generic toolkit then
it should be incubated as a separate project.  IMO there are too many
single-developer products being masked under the Directory umbrella,
rather than a coherent group of individuals working together on a
single product (and thus having sufficient voters to make collaborative
decisions about that product).  This is just my concern, but please
understand that we didn't create Directory in order for it to become
another Jakarta or Avalon.

Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Directory Project structure (was: Question about project names)

[Roy T . Fielding]

On Dec 30, 2004, at 10:26 PM, Noel J. Bergman wrote:
I believe that there are some misunderstandings.  There is an 
architecture
for a unified Directory Server.  That server is made from a number of
components: the core JNDI backend, the local JNDI code, the network 
support,
ASN.1 encoding support, the wire-level protocol handlers, all of whom 
fit
together to build a unified project.  LDAP (present), Kerberos 
(present),
DNS (pending), DHCP (pending), CosNaming (proposed) and other
directory-dependent wire-level protocols are built to the code JNDI 
backend,
sharing all of the network and backend plumbing, and adding just the 
pieces
for implementing their protocol.  All of these services are 
represented by
directory schema on the backend, and common network plumbing on the 
front.
Okay, but just to mention one of my pet peeves: "refactoring" projects
into independent components within an open source project is like 
polishing
rocks: the result may be a bunch of really cool stones, but that will 
still
suck if what the user actually wants is a stone wall.  Build the 
bricks, but
be sure their design goals are determined by the larger, user-driven 
project
rather than abstract notions of the perfect component.  That's why I say
that it is better to distribute the whole thing as one product, at least
until the component interfaces are truly stable -- open source people 
know
how to cut and paste.  [Just my opinion -- feel free to ignore.]

The term "sub-projects" should also be dropped in favor of
"components."
Please do that -- it gave me the willies.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

voting on new projects (not via some other pmc)

[Roy T. Fielding]

On Jan 4, 2005, at 7:30 PM, Doug Cutting wrote:
I'm unclear on whether the votes for Nutch (3 plus, no minus) are yet 
sufficient for it to join the Incubator.  If they are, then requested 
resources are listed in the proposal at:

http://wiki.apache.org/incubator/NutchProposal
Assuming that Noel recognized the vote, you need three +1s from the
following group of people (the incubator pmc):
Aaron Bannert
Noel Bergman
Nicola Ken Barozzi
Ken Coar
Morgan Delegrange
    Roy T. Fielding
Ceki Gulcu
Paul Hammant
James Holmes
Ted Husted
Jim Jagielski
Berin Lautenbach
Ted Leung
Geir Magnusson Jr.
Stefano Mazzocchi
Craig McClanahan
Steven Noels
Sam Ruby
Cliff Schmidt
Leo Simons
Greg Stein
Davanum Srinivas
James Strachan
Sander Striker
You can count me as +1, though you really do need to get the
chair's attention to indicate that the vote was valid.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Please check/post your PROJECT RESOURCE REQUESTS

[Roy T. Fielding]

On Jan 5, 2005, at 1:24 AM, Raphaël Luta wrote:
I have the following requests pending for Graffito:
Mailing-lists:
--
Name: [EMAIL PROTECTED]
Archives: public, Eyebrowse
Moderator:
[EMAIL PROTECTED]
done except for eyebrowse
Name: [EMAIL PROTECTED]
Archives: public, Eyebrowse
Moderator:
[EMAIL PROTECTED]
done except for eyebrowse
I don't believe we need a ppmc list since gaffito
will be part of Apache Portals and is monitored
by Portals PMC.
done anyway -- graffito-private
Repository:
---
It's set up and authorization is configured in SVN
but not in live file.
Commit mails need to be configured.
done
JIRA:
-
Creation of a Graffito module (id: GRFT)
Module administrator: David Sean Taylor ([EMAIL PROTECTED])
done.  You are now a jira administrator so that you can associate
additional developers to the Graffito group as needed.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 'Stable' URL for podlings (Derby in particular)

[Roy T . Fielding]

The update system Eclipse uses requires stable (unchanging) URLs
for the plugins.  We'd like to get the Derby plugin for Eclipse
into that system, which means we'd like to see about getting a
URL which won't change when/if Derby graduates.
In what address space?
In any persistent address a.o space at all.
If this is something that many projects will use, then I suggest
   http://apache.org/epi/derby
which can then redirect to the Derby project's current location.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Nutch

[Roy T . Fielding]

On Jan 17, 2005, at 2:25 PM, Doug Cutting wrote:
I don't appear to yet have the Karma to do this, so I've attached a 
diff.  Since I'll expect to update this frequently, I should probably 
get the required Karma.  How do I do that?
You now have karma, mailing lists, and a subversion repository.
Please go ahead and commit the project status to incubator site-author.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Roberto Rabe as iBATIS Committer/PMC Member

[Roy T . Fielding]

+1, have fun.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] add Jukka Zitting to Jackrabbit committers

[Roy T. Fielding]

Hello everyone, it is time to consider adding our first new
contributor to commit status for Jackrabbit.
I hereby nominate Jukka Zitting ([EMAIL PROTECTED]) on the
basis of his sustained interest, quality of work, and desire
to contribute to the project on a long-term basis. Please vote
with your +1 for yes, +0 for abstain, or -1 (not at this time).
Naturally, only the votes coming from the incubator PMC and
Jackrabbit committers currently listed on our project status
page will be counted as binding.
Jukka, this nomination is conditional on your desire to be
part of the Jackrabbit project and you willingness/ability
to sign and submit a Contributor License Agreement found at
   http://www.apache.org/licenses/#clas
Feel free to decline the nomination if you do not desire
commit access at this time, or if you are unable to sign the
CLA for any reason.
Cheers,
Roy T. Fielding<http://roy.gbiv.com/>
mentor, Apache Jackrabbit
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] add Jukka Zitting to Jackrabbit committers

[Roy T. Fielding]

I hereby nominate Jukka Zitting ([EMAIL PROTECTED]) on the
basis of his sustained interest, quality of work, and desire
to contribute to the project on a long-term basis. Please vote
with your +1 for yes, +0 for abstain, or -1 (not at this time).
+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

please be more careful when updating the incubator site

[Roy T . Fielding]

jackrabbit site was offline for about 24 hours before it was noticed
by the developers.
Begin forwarded message:
From: Roy T. Fielding <[EMAIL PROTECTED]>
Date: February 8, 2005 1:17:20 PM PST
To: [EMAIL PROTECTED]
Subject: Re: is http://incubator.apache.org/jackrabbit/ down?
Reply-To: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
On Feb 8, 2005, at 11:24 AM, David Nuescheler wrote:
am i missing something...
i get a 404 from http://incubator.apache.org/jackrabbit/
Somebody blew it away when they updated the incubator site. :(
I just recreated it.
Roy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: please be more careful when updating the incubator site

[Roy T . Fielding]

On Feb 8, 2005, at 1:58 PM, David Crossley wrote:
Do you have a clue as to how this would have happened?
Do you mean that it disappeared when the top-level Incubator
site was generated? It should not, because the project sites
are separate from the top-level site.
I have no idea -- the entire directory tree was removed.
There is no indication that subversion knows about it at
the top-level, so my guess is an accidental rm -rf
unless it is some new feature of forrest.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] add Jukka Zitting to Jackrabbit committers

[Roy T . Fielding]

With no objections and plenty of +1s, the Jackrabbit PPMC and
Incubator PMC hereby approve the addition of Jukka Zitting as
a committer on the Jackrabbit project.
Jackrabbit PPMC:
  +1  Roy Fielding
  +1  Stefan Guggisberg
  +1  Stefano Mazzocchi
  +1  David Nuescheler
  +1  Peeter Piegaze
  +1  Gianugo Rabellino
  +1  Tim Reilly
  +1  Marcel Reutegger
  Paul Russell
  +1  Andrew Savory
  +1  Tobias Strasser
  +1  Sylvain Wallez
Incubator PMC:
  +1  Roy Fielding
  +1  Jim Jagielski
  +1  Stefano Mazzocchi
Since his CLA is already on file, I'll start generating the account.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Directory exiting Incubator

[Roy T . Fielding]

+1
Personally, I needed to see the PPMC make a decision first.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Advice Needed: What do we do about autoresponders? (Fwd: Autoreply: Re: What are the valid jdbcTypes and their default values.)

[Roy T . Fielding]

On Feb 13, 2005, at 6:50 PM, Clinton Begin wrote:
How do you all deal with autoresponders when they're responding to
mailing list posts?
Do you kick the user?  Is there a filter?
kick them
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] [EMAIL PROTECTED]

[Roy T . Fielding]

On Feb 28, 2005, at 7:25 PM, Sam Ruby wrote:
Dave Johnson wrote:
Proposal for [EMAIL PROTECTED] (prepared by Dave Johnson - Feb 28, 2005)
We the committers and friends of the open source Roller Weblogger 
project propose that the project become part of the Apache Software 
Foundation. The rest of this document explains the rationale behind 
this proposal, how Roller meets the Apache project scope, initial 
source, resources required, and initial committer criteria.
All incubator projects need a champion.  I worked with the submitters 
offlist prior to the submission, and plan to mentor this project 
through incubation.

It is my recommendation that the incubator PMC itself be the sponsor.
+1 (please note, however, that we are currently short on
infrastructure volunteers and it may take some time to set up)
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] add Dominique Pfister to Jackrabbit committers

[Roy T . Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: log4net 1.2.9 beta release

[Roy T . Fielding]

On Mar 7, 2005, at 8:05 AM, Ceki Gülcü wrote:
Is there any opposition or reservations in relation to the log4net 
snapshot release mentioned by Nicko and myself a few days ago?

If not could we allow log4net to move forward?
If the subproject has cleared its IP issues sufficient to make
a release, then it really should be graduated from incubator first.
After all, the logging PMC is already established and should take
custody of the code before we make a release (unlike TLP incubating
projects that may be waiting for a community to be established).
I will note, however, that
   http://incubator.apache.org/projects/log4net.html
indicates that none of the IP issues have been cleared, and thus
we cannot release the code.  -1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: log4net 1.2.9 beta release

[Roy T . Fielding]

On Mar 9, 2005, at 3:00 AM, Ceki Gülcü wrote:
At 01:39 AM 3/9/2005, Noel J. Bergman wrote:
See Roy's message about the need to update the status file.  One would
expect that this is simply an oversight, and that the Logging PMC did 
not
vote for a release with IP issues still open.
Indeed, the software grant was sent to Jim sometime in January 2004 
[1], that is over a year ago. However, I could not find Jim's 
acknowledgement in my records.
I see it in foundation/grants.txt.
As for the log4net committers, they all have signed CLAs on record. I 
am going to double check on both aspects and report back.

I am fairly certain taht the IP clearance work was done over a year 
ago. For various technical reasons, I failed to put them in the 
log4net cwiki file.
Please make the changes to the status file in
  svn incubator/site-author/projects/log4net.cwiki
but don't worry about the site publish.  Or just send in a patch.
Anyone in that project should also have subversion rights to edit
the status (the intention is that it be edited by some person who
can confirm the task has been accomplished).
I am not concerned about the .NET platform issue.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: log4net 1.2.9 beta release

[Roy T . Fielding]

On Mar 10, 2005, at 2:20 AM, Ceki Gülcü wrote:
Roy et al.,
Done. I committed the updates yesterday as shown by the SVN 
notification message below. I now go on and update the section about 
3rd party libraries.

I would say that all IP concerns related to log4net have been 
addressed. Would you concur?
Yes.  Assuming you can also confirm that
| -..-.. | Add all active committers in the STATUS file.
is done and the logging PMC is ready to accept responsibility,
then I think log4net should graduate from incubator.  +1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is a healthy community? WAS: log4net 1.2.9 beta release

[Roy T . Fielding]

On the contrary, the rule is that you must have at least three
binding +1 votes from the PMC in order to make a release of anything.
I don't believe in umbrella projects, so from my perspective log4net
is just one subdirectory in logging.  If logging wants to take
responsibility for it and logging has at least 3 people willing
to +1 its releases, then I don't see how keeping it in incubator
will help.  If logging later loses interest in the project, then
there won't be 3 +1s to do a release, the code will remain static,
and we are no worse off than if that code had died within incubator.
In any case, it is far more likely to gain community once it
leaves incubator, so making "community" a requirement for graduating
a subdirectory of an existing project is self-defeating.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is a healthy community? WAS: log4net 1.2.9 beta release

[Roy T . Fielding]

On Mar 14, 2005, at 3:08 AM, Ceki Gülcü wrote:
At 07:53 PM 3/12/2005, Roy T.Fielding wrote:
On the contrary, the rule is that you must have at least three
binding +1 votes from the PMC in order to make a release of anything.
Roy,
For me, the accepting responsibility over a project, say X, translates 
into an engagement to take over  project X if and when the existing 
committers stop working on it.
No, that is not what accepting responsibility means.  What it means is
that the PMC is responsible for ensuring that it is either run as an
Apache project (open to new contributors, advancing people to greater
responsibility, etc.) or shut down as soon as that proves not to be
the case.  A one-person project must be encouraged to be a three-plus
person project or it simply does not belong at Apache, period.  That
is a minimum.
When PMC members cast a binding vote on a given release of project X, 
they are approving the release, in the sense that the release is "OK". 
Their binding vote does *not* mean that they are able to take over the 
project in terms of development resources. Thus, accepting 
responsibility and casting binding votes do not have exactly the same 
meaning. Would you agree?
No.  Binding votes are binding because they have been given 
responsibility
by the ASF to determine whether it is safe to release the software.

If taking responsibility means exercising oversight over the 
sub-projects in Logging Services, then I think the LS PMC can only 
accede to your and Noel's request. That much seems pretty obvious.

However, if taking responsibility means providing the development 
resources in case a sub-project  lacks development resources, we 
cannot collectively make such a pledge. I also have to say that 
insisting on such a pledge strikes me as unreasonable. How can a PMC 
pledge resources it does not have or control? The only development 
resource the PMC "controls" are the individuals composing the PMC. To 
be precise, each voting PMC member controls one resource: himself.
Exactly, which is why umbrella projects never work and thus it is
better for a project to be forced into growing their own community.
Designers are resistant to give up personal control over a project,
and the veto allows them to retain enough technical control while
still opening up participation.  When a subproject only has one or
two developers active, we require that the PMC be involved in all
release decisions until such time as it successfully encourages
additional people to get involved.  The only difference between my
and Noel's opinion is that I think the logging PMC can take over
the community-building role from the incubator PMC once the legal
obstacles have been cleared, whereas he seems to believe that the
incubator should not graduate a podling until it is ready to be
independent.
I would agree with Noel if it weren't for the fact that the
incubator PMC does not build communities either -- that role has
been entirely left to the mentors, who are typically from the
destination PMC.  Graduating subprojects earlier would let us
focus on the podlings that are destined to be TLPs.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Incubator representative?

[Roy T . Fielding]

Ceki, the incubator was created because some well-meaning people
at Apache were making themselves busy helping a thousand projects
bloom without noticing that some were weeds.  It only requires one
bad project to destroy most of what the foundation has accomplished.
The incubator weeds out the single-developer fiefdoms because we
know they are at high risk, regardless of the current intentions
of the developers.  Apache was founded to support *collaborative*
development of open source software.  There is nothing wrong with
requiring a community exist before something becomes an Apache
project, even if it is a chicken-and-egg problem for the incubator.
Other projects can and should be hosted elsewhere.
Of course the incubation process is coercive -- all process is.
The question to ask is whether our process achieves our goals,
not whether our process is representative of the lowest common
denominator of project success.
Cheers,
Roy T. Fielding<http://roy.gbiv.com/>
Chief Scientist, Day Software  <http://www.day.com/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Incubator mailing list archives not up to date

[Roy T . Fielding]

On Mar 21, 2005, at 2:57 AM, Jukka Zitting wrote:
Hi,
The Incubator mailing list archives at 
http://incubator.apache.org/mail/
seem to be last updated about a month ago at 2005-02-22. Is there
something wrong, or have I missed something?

(Cross-posting to incubator-general and infrastructure, as I'm not sure
who is in charge of the archives.)
That is because we are moving machines and you are actually looking
at an old rsync on ajax.apache.org which probably doesn't have the
links to the new archive location.  It'll be right tomorrow.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate iBATIS and recommend as TLP

[Roy T . Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Derby from the incubator

[Roy T . Fielding]

Sorry, I'd like to vote for this, but someone was being cute
and removed a lot of relevant questions from the template at
  http://incubator.apache.org/projects/derby.html
and thus I don't have the answers that the ASF needs.  For
comparison, see the tables in
  http://incubator.apache.org/projects/ibatis.html
Also, the list of committers is incomplete.
-1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Prepping for Derby graduation vote

[Roy T . Fielding]

There are more important issues with graduation as Roy just pointed 
out with his veto.  I think once these technicalities are settled this 
project is ready.
Er, just a vote -- there is no veto for this type of decision.
I will change my vote to +1 as soon as the documentation is fixed.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Derby from the incubator

[Roy T . Fielding]

Pardon my ignorance but where does this file live and do I have karma 
to update it?
Any committer on an incubator project has karma
Information on how to make incubator site changes can be found at
  http://incubator.apache.org/howtoparticipate.html
The incubator site uses Forrest, not Maven; most people just edit the
content under site-author and let someone else generate the real site.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: nutch graduation?

[Roy T . Fielding]

On Apr 18, 2005, at 3:16 PM, Doug Cutting wrote:
http://www.apache.org/licenses/software-grant.txt
Is that what I should file?
Yes, at least for now.
I suppose we could also transfer the Nutch copyright, trademark, logo, 
etc. if desired.  Nutch does not have a registered trademark.  I don't 
know whether any of this is worthwhile.  The Nutch non-profit 
corporation will be disbanded once Nutch graduates.
You should definitely perform a complete transfer (assign all rights
and interest to those things) to the ASF *before* disbanding.  In most
states that is a legal requirement for nonprofit corporations and
you might get in trouble if you did not handle it formally.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Derby from the incubator

[Roy T. Fielding]

On Apr 22, 2005, at 2:22 PM, Daniel John Debrunner wrote:
I personally don't see this problem with Derby, all Derby design
decisions seem to be happening on the list. So I'm not sure if
Jackrabbit and Derby have the same problems.
How can you know?  I know the amount of progress that we are
making on Jackrabbit, and what we have left to do, because I can
see the communication dynamic behind the scenes.
The point is not that Derby or Jackrabbit have problems.
The point is that there is a minimum level of maturity that a
project reaches when it actively depends on participation
outside the original team.
The three independent committers rule is an absolute minimum
based on the legal fact that US employees are required to be
loyal to their full-time employer *even* when we know the people
involved are beyond question, independently minded, and dangerous
to approach with anything like a "command from the boss."
The project may be cruising along like a fully-formed Apache
community, but it doesn't actually become one until the
decisions are made by the community in fact (by virtue of
having the vote), not just in appearance.
I have no doubt that Derby can and will reach that level soon
while staying inside the incubator.  Meanwhile, continued moves
to give Derby special treatment are NOT APPROPRIATE.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Derby from the incubator

[Roy T. Fielding]

On Apr 22, 2005, at 8:55 AM, Brian Behlendorf wrote:
It's not so much "dissonance" as an exception.  In an incubating 
project, the developers are usually new to the ASF, and skipped the 
meritocracy step by virtue of association with the project before it 
entered Apache ("here's the list of committers"). Therefore it's 
reasonable to ask the incubating project to prove that not only can 
they write code, but they can build an active multi-participant 
community.  If there really is still just one outside committer, then 
in my opinion the community has not yet passed that test; and rather 
than coding, those who care about that project should be advocating 
its existance to others, giving presentations at conferences, getting 
the middleware projects to support it as a peer to mysql and postgres, 
that sort of thing - all in the name of getting more outside 
involvement.

This is actually not limited to incubator projects - we've had issues 
before with projects whose committership was overwhelmingly from one 
employer.  The issue wasn't the employer corrupting the decisions of 
the employees so much as the employees communicating privately with 
each other because they could, leaving out other developers; it also 
meant they were not incented to reduce the learning curve on the code 
or document internals, which would have increased outside involvement. 
 The solution there is to slow down the pace of coding and do more 
community development, and ask "why are there so few other 
developers?".  Even if the project is widely, you should ask "why are 
so few users of this software interested in becoming developers?".
Ditto (I am *so* lazy today).
As others have said, what the ASF cares about is healthy developer 
communities; good code is a resulting byproduct.
Right.  At the beginning of this thread, I asked that the status page
be updated because it clearly didn't reflect what I was hearing about
the community [which was all good].  It was updated, but I am surprised
that the update didn't change as much as I expected.  One new
developer is not a great sign of progress -- it is only a good start.
The hardest part of self-governance is the decision to give up some
control to a new person, and it isn't until a group has a legacy of
doing that, on the basis of merit instead of corporate negotiation,
that I am willing to vote them out of incubator.
 [side note: while I know this may not seem fair to the developers
  working on Derby, the fact of the matter is that IBM already burned
  us (the ASF) with false promises of community building in XML, and
  thus the cries of "Trust us, we'll get there soon" are not going
  to be heard.  This time, IBM has to go through the same process
  as all of the other groups who enter the ASF with a new project.]
We have the same problems as Derby within the Jackrabbit project,
though not only did we *start* with a far more diverse set of
committers, we actively encouraged new folks to take responsibility
for their own contributions.  Nevertheless, it is quite clear to me
that we haven't reached the point of graduation, and not just
because the JCR spec is unfinished.  There simply isn't enough
actively diverse participation to cause everyone to make all
design decisions on the list instead of in private mail or
hallway conversations.
Here's an idea -- how about encouraging a couple Derby developers
to participate in Jackrabbit (it is a database API after
all) and then convince some of the Jackrabbit developers to
participate on performance tuning Derby when used within a CMS.
Everyone wins and both communities become more diverse.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Jackrabbit status

[Roy T . Fielding]

[For the board report from Incubator]
http://incubator.apache.org/jackrabbit/
http://incubator.apache.org/projects/jackrabbit.html
Jackrabbit is doing well as a project and is attracting interest
both within other Apache projects (Lenya and Graffito in
particular) as well as from new folks in the Java community.
We added two new committers, Jukka Zitting and Dominique Pfister,
and have received sustained contributions from Serge Huber,
Edgar Poce, Angela Schreiber, Felix Meschberger, and others.
Jackrabbit's only problem right now is continued reliance on
JCP EG private discussions due to the unfinished nature of the
JSR 170 Content Repository for Java Technology API.  JSR 170 is
expected to be submitted for final draft status in early May,
after which all of the discussion can be moved to Apache lists.
We anticipate graduating from Incubator sometime soon after that.
Cheers,
Roy T. Fielding<http://roy.gbiv.com/>
Chief Scientist, Day Software  <http://www.day.com/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PROPOSAL : Apache Harmony - J2SE 5 Project

[Roy T. Fielding]

+1
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Harmony: project purpose

[Roy T . Fielding]

On May 6, 2005, at 9:20 PM, Noel J. Bergman wrote:
The aforementioned issues between GPL and AL aside, I am still trying 
to see
how the TCK licensing restrictions are compatible with the GPL.  
According
to the FSF licensing page, the Apache License is deemed by the FSF to 
be
"incompatible with the GPL because it has a specific requirement that 
is not
in the GPL."  So how much worse are the TCK licensing restrictions?  
For
examples, see the modified version of the AL that has been drafted for
dealing with JSR's:
http://www.apache.org/licenses/proposed/JSR-LICENSE-2.0.txt.  As I read
things, it really does not seem possible to meet the requirements of 
both
the GPL and the Java licenses.  And any bending necessary to accept 
the TCK
terms should help to address the AL issue as well.
Note that, although the JSR license above is a proposal that has since
been modified (it is working through the approval process right now as
part of Day's JSR 170), the reciprocal patent license is actually a
requirement of the JSPA.  So, even if Sun has some other terms in
mind for their own TCKs, they will have to include a patent termination
clause that is almost identical to the one that the FSF claims in
incompatible with the GPL.
Personally, I think the FSF should just create a Java-specific license
that says what they want.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Harmony: project purpose

[Roy T . Fielding]

On May 7, 2005, at 12:38 PM, Paul Hammant wrote:
Unless I am mistaken, Apache licensed code will never be able to 
'legally' import GPL code.
You are mistaken -- the copyright owner can do whatever they want,
as can users.  It is only redistributors that are constrained on
how they can combine and redistribute.
The logic behind this -
GPL code can can import BSD, MIT, X11, W3C (etc) code but cannot 
currently Apache licensed.  That may well be worked out with an 
revision to the Apache Software License 2.0.
It is only an opinion of the FSF.  It makes no difference to anyone
else and certainly isn't based on law.
BSD (etc) is not currently able to import GPL licensed code.
Sure it is.  It just can't turn around and redistribute the combination
as anything other than GPL.
Why would Apache licensed code be any different even if the current 
issue were worked thru?

Its the lack of a reciprocal arrangement on legal/allowed importing 
that is the long term blocker on ASF / FSF cooperation.
The FSF does not have reciprocal arrangements -- the GPL is all or
nothing.  The Apache License is already reciprocal in nature -- as
far as we are concerned, GPL projects are free to incorporate and
redistribute our code.
Roy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] add Edgar Poce to Jackrabbit committers

[Roy T . Fielding]

+1

Roy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] add Edgar Poce to Jackrabbit committers

[Roy T . Fielding]

On May 21, 2005, at 12:08 AM, Jukka Zitting wrote:

David Crossley wrote:

There is no need to Cc this to [EMAIL PROTECTED]
This stuff is a concern of the project.


OK, I'm sorry for that, just learning the correct procedures...


No need to be sorry -- David is confused.  Incubator is the project
right now and is responsible for the addition of new committers.
You did the right thing.

Based on previous committer votes I was under the impression that the 
Incubator PMC should participate in the vote. Am I wrong ([1] doesn't 
mention this) or should I have Cc:d pmc@ instead?


No, we never cc a private list.  general is where the incubator PMC
discusses and makes decisions.

Roy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]