Re: [PROPOSAL] Heraldry Identity Project
On 6/20/06, Drummond Reed <[EMAIL PROTECTED]> wrote: My co-chair Gabe Wachob and I have been one of a set of OASIS TC chairs that have been arguing hard for OASIS to adopt a more explicit "open source compatible" IPR mode, and we would be happy to work with you and ASF to continue to champion it. But at the same time we don't want that to slow FWIW, I'd be interested in hearing more about this. Cliff, Dims, and I have had some past discussions with key OASIS folks about their IPR policies that largely went nowhere. In general, most folks here in the ASF would love to see OASIS adopt saner (and more descriptive!) IPR policies. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Heraldry Identity Project
At the Berkman Identity Mashup Conference (http://www.identitymash-up.org/) last week, there was a joint announcement by Microsoft, Novell, IBM, SXIP, XRI, and VeriSign around the future of OSIS (http://blogs.zdnet.com/BTL/?p=3229). OSIS will morph into a working group under Identity Commons with two goals: 1) To enable those projects to work independently, but aligned, so overlap of work is avoided, and the parts developed by different projects can fit 2) To deliver an open-source identity selector as a joint effort of multiple projects, which is intended to be at least as functional, and fully compatible, with Microsoft's CardSpace (formerly known as InfoCard) identity selector that will be shipped with Windows Vista. >From the OSIS agreement (http://osis.netmesh.org/wiki/OSIS_Agreement), the Heraldry project would focus, as far as its interaction with OSIS, on developing relying party code, a light-weight identity provider, and a STS for managed i-cards to integrate with Higgins. The Eclipse Higgins project will then focus on client code for both a browser based and rich client identity selector as well as a STS for self-issued cards. In the end, this means that OpenID will integrate with Higgins which will/does integrate with Microsoft's CardSpace technology. This obviously has an impact on the original Heraldry project proposal since one of the goals was a desktop component to this technology, with the idea of working with the OSIS effort to produce it. In the end, all of this is good news. It shows convergence within the space, Higgins working with CardSpace, OpenID working with Higgins, and a working group to provide a way to help all of these projects to work independently, but aligned. I've updated the Heraldry proposal on the wiki (http://wiki.apache.org/incubator/HeraldryIdentityProposal) to reflect this and look forward to meeting all of you in Dublin next week! --David -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 4:04 AM To: general@incubator.apache.org Subject: [PROPOSAL] Heraldry Identity Project Proposal -- This is a proposal to create a project within the Apache Software Foundation to develop technologies around the emerging user-centric identity space. The project would start with Yadis [1] for URL/XRI-based service discovery, OpenID [2] for web based single-sign-on and the basis of exchanging profile data, and to create a desktop component with a standard look and feel, ideally working with the Open Source Identity Selector (OSIS) [3] project. We are currently working with those involved in the OSIS project to determine if it would be possible, and they willing, to integrate their effort as a part of this one. If not, we still see the value of having a desktop component of this infrastructure. The project would be tasked with the further development of these technologies as well as creating a bridge between the light-weight URL/XRI based identity technologies and the desktop. Yadis is currently being standardized within OASIS as part of the XRI effort, OpenID has emerged as a de-facto specification, and OSIS does not depend on a specification although the further development of its architecture document would ideally be part of this project. Rationale -- While identity systems such as X.509 have existed for many years, and more recently SAML and the Liberty Alliance framework, only within the past two years has there been a true emergence of user-centric technologies. Pursuant to Kim Cameron's laws of identity, technologies such as LID, Yadis, OpenID, and Sxip were defined to put control of a person's digital identity back into their own hands. Both Yadis and OpenID have reached a point where they have millions of users and a strong community backing. On May 28th 2006, Brion Vibber of WikiMedia announced in a Google Tech Talk that WikiPedia would support both of them within the following month. This sort of broad adoption and traction has not been seen with other technologies of this kind in this space. By bringing these technologies and ideally the OSIS effort to one place, these communities will have a place to fully converge and continue the development of interoperable implementations. Additionally, by not just focusing on light-weight URL/XRI based identity systems, ASF will be able to provide a foundation where a person can use one or more digital identities consistently across blogs, eCommerce sites, and portals as well as even high-risk transactions via their desktop computer. Currently Apache does not offer any project such as the one being proposed. Integration with projects such as Lenya would definitely be encouraged. Initial Goals -- - Expansion of Yadis and OpenID libraries into additional languages beyond the existing Python, Ruby, Perl, and PHP libraries - OpenID authentication specification revision to fix known security considerations,
Re: primary email, balanced use of IRC
Martin Cooper wrote: > David Crossley wrote: > > > >The committer who is operator does a regular commit of > >the logfile to our SVN. This keeps good track and allows > >us to refer to the log during the meeting. It could > >also enable people not on IRC to still be involved > >because they could reply to the svn commit email. > > Wading through 24 hours of IRC logs is not something many people are going > to do, though, especially if they weren't part of the original discussion, > and so don't know what they're looking for. I agree. Forrest is still a small project, so it is manageable. Average log size is 1000 lines. As we all know, reading IRC logs is very difficult. Being there in real time is also difficult. That is why the summary is so important. > >We have said that we will also create a summary text > >of the days events. This latter task has not been > >carried out very well. > > This is one of my main concerns. More times than not, I've seen claims that > a summary will be posted that are not followed up. I agree. Forrest is on thin ice. > >Personally i reckon that the events have been very > >beneficial. > > Have you participated in them? I'm sure people who participate feel they go > well, but I'd be more concerned about how the people who have > _not_participated feel about them. All but one. And i was keen to read the whole log. Yes, i agree we need to see other points-of-view. > >I am still wary of using IRC more often than that. I am very glad that this topic is happening in a wider forum. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary email, balanced use of IRC
On 6/23/06, David Crossley <[EMAIL PROTECTED]> wrote: Cliff Schmidt wrote: > Noel J. Bergman wrote: > > >The use of e-mail as the primary means for communication is part of ASF > >policy and philosophy, and we can certainly learn lessons from projects > >that > >have gone against it. IRC tends to breed a more closed, albeit arguably > >more integrated, community. > > > >That said, if IRC can be used as a learning tool to rapidly bring new > >people > >up to speed, and if the information gathered from those sessions is > >preserved for others to follow up via web-site and e-mail, how do people > >perceive that? > > I've never done that on a project, but I think it could be a > reasonable thing for a project to try. I believe the Synapse folks > have been doing regular IRC meetings from early on. I'd be interested > in their perspective on the pros and cons, particularly as an > incubating project. > > As a XAP mentor, I know that the committers already understand that no > decisions will be made over IRC, that logs of each IRC will be > immediately made available to the entire community, and that they need > to be sensitive to any concerns from people wishing but unable to > participate. But, are there other thoughts from the Synapse folks or > anyone else who has used regular IRC meetings? At Apache Forrest we strive to have all communication via the mailing lists. We have a deliberate IRC session once per month. It goes for 24 hours so that everyone can be involved. It is the second Friday of the month starting at a specific time. We use a different channel name, chosen by the operator. That prevents the channel from being constantly available and turning into either a club or a support forum. http://forrest.apache.org/forrest-friday.html We simultaneously use the dev@ mailing list. Some issues are better dealt with there. The committer who is operator does a regular commit of the logfile to our SVN. This keeps good track and allows us to refer to the log during the meeting. It could also enable people not on IRC to still be involved because they could reply to the svn commit email. Wading through 24 hours of IRC logs is not something many people are going to do, though, especially if they weren't part of the original discussion, and so don't know what they're looking for. We have said that we will also create a summary text of the days events. This latter task has not been carried out very well. This is one of my main concerns. More times than not, I've seen claims that a summary will be posted that are not followed up. Personally i reckon that the events have been very beneficial. Have you participated in them? I'm sure people who participate feel they go well, but I'd be more concerned about how the people who have _not_participated feel about them. -- Martin Cooper I am still wary of using IRC more often than that. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
primary email, balanced use of IRC
Cliff Schmidt wrote: > Noel J. Bergman wrote: > > >The use of e-mail as the primary means for communication is part of ASF > >policy and philosophy, and we can certainly learn lessons from projects > >that > >have gone against it. IRC tends to breed a more closed, albeit arguably > >more integrated, community. > > > >That said, if IRC can be used as a learning tool to rapidly bring new > >people > >up to speed, and if the information gathered from those sessions is > >preserved for others to follow up via web-site and e-mail, how do people > >perceive that? > > I've never done that on a project, but I think it could be a > reasonable thing for a project to try. I believe the Synapse folks > have been doing regular IRC meetings from early on. I'd be interested > in their perspective on the pros and cons, particularly as an > incubating project. > > As a XAP mentor, I know that the committers already understand that no > decisions will be made over IRC, that logs of each IRC will be > immediately made available to the entire community, and that they need > to be sensitive to any concerns from people wishing but unable to > participate. But, are there other thoughts from the Synapse folks or > anyone else who has used regular IRC meetings? At Apache Forrest we strive to have all communication via the mailing lists. We have a deliberate IRC session once per month. It goes for 24 hours so that everyone can be involved. It is the second Friday of the month starting at a specific time. We use a different channel name, chosen by the operator. That prevents the channel from being constantly available and turning into either a club or a support forum. http://forrest.apache.org/forrest-friday.html We simultaneously use the dev@ mailing list. Some issues are better dealt with there. The committer who is operator does a regular commit of the logfile to our SVN. This keeps good track and allows us to refer to the log during the meeting. It could also enable people not on IRC to still be involved because they could reply to the svn commit email. We have said that we will also create a summary text of the days events. This latter task has not been carried out very well. Personally i reckon that the events have been very beneficial. I am still wary of using IRC more often than that. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
On Jun 22, 2006, at 9:52 PM, Hani Suleiman wrote: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. I'm astonished that you didn't expect it. Apache is a social organization that depends on trust, and one of the easiest ways to lose trust is to take on a persona that doesn't accept responsibility for your own actions. It is interesting to note that all the people who have objected are those who feel personally offended by some of my writing (specifically, the tomcat and axis2 rants...ironically my tomcat DefaultServlet rant was purely technical and did not degenerate into my usual personal insult comfort zone). I don't find your blog to be technical at all. It is mostly just childish whining, even when everything you say is accurate. It is not constructive criticism. I'm sorry that you can't take a little criticism, and while I will happily admit that yes, I did insult you in ways that you probably didn't quite expect, I fully stand by everything I said, and will still insist that Axis2 and Tomcat are awful projects, that are badly written and have only gotten where they are today due to marketing forces, instead of technical merit. Then fix them or write a replacement. If you have time to entertain yourself on your blog, then you have time to fix the open source that you dislike. I am perplexed that you feel that a dislike of an Apache project merits a membership rejection though. Does everyone at Apache love every project there? If that were the case, then the whole ecosystem is in a far unhealthier state than anyone on the outside might suspect. We live on criticism -- constructive criticism, that is. You don't seriously think your blog is constructive, do you? No, we don't all love each other's projects and we encourage participants to rethink entire architectures on a regular basis. Anyone who actually participated in a project, instead of just whining from a distance, would know that. If Apache people feel that my technical abilities are not relevant, and that what should matter in whether I am allowed in as a cxfire committer is how willing I am to tow the party line, then I shouldn't be on that list. Apache would be the first organisation I've joined (or might have joined) that did not judge me on technical merit; quite an irony considering the whole meritocracy approach that Apache claims. This is, astoundingly, my first experience of being judged not on technical merit, but on random blathering that serves no particular purpose than ranting for ranting's sake. Meritocracy is based on what you have earned, not on your potential ability. Right now you are one of the few individuals in the world with negative Apache merit -- IMO, you cause more damage by your whining personal insults than you have contributed in your critiques as a user or developer. In fact, the only person I can think of at the moment with more negative Apache merit than you is Marc Fleury. Are you happy now? That doesn't mean you can't turn that situation around, start contributing in a meaningful manner, and have a huge impact on future Apache projects. It just means you are in a hole right now and should expect to dig your way out before getting much respect here. That is what asking to be a committer is about -- gaining our respect so that we trust you to use our infrastructure for good purpose without damaging any of our projects. Just to set expectations, I will not stop saying things like 'Apache sucks', because I still do think that many of the processes and members have some terrible flaws. Why don't you just suggest a patch to the process? Most of our documentation needs improvement. Saying "Apache sucks" without actually contributing just means you are too lame to do better. Members, however, are human. If you think they have terrible flaws, then find ways to work around those flaws (or find a nice way to fix those flaws, if possible). Apache is a collaboration and our processes are designed to enable decisions to be made in spite of disagreement, because there will always be disagreement when faced with design trade-offs. Learning that is part of being a contributor. If you want to be a whiny little prick, then you don't need collaborators and we don't need you. I am not aware of any Apache membership requirements that state that one's freedom of speech and expression are curtailed in any way; it is after all an alleged meritocracy, all that matters is how good the code I check in is, and how well I play within the team I'm a member of. If the cxfire team at any point feels I'm a liability rather than an asset, I would gladly leave. In fact I'd like to think that I'm self-aware enough to leave way before they feel the need to ask me to. Again, you seem to have no clue what meritocracy means at Apache. People who have bee
Re: [Proposal] Jini Project
On Jun 23, 2006, at 4:46 PM, Bob Scheifler wrote: Having written that, I guess I've just explained to myself why the ASF project should not be merely "Jini", and should either have a different name or an additional qualifier. (As for trademark issues, I'll defer to Jim Hurley to chime in.) I agree with Bob's reasoning, and a different or qualified name might be a better choice after reflection. As Geir had mentioned... Sun's original intent (with the proposed "Jini" name of the project) was to donate the TM to the ASF. I'm not sure how that would work now (TM use -wise) with other Jini -related work and sites (for example, the jini.dev.java.net Community project area (for work around the Apache Jini project core), and the new informational Jini.org project site being worked). -Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] CeltiXfire Project
I'd sat let Hani in perhaps he has some better ideas of how things should be done. If not, then he can wax eloquent about what went wrong. Either way...it will be a win and most entertaining. Sanjiva Weerawarana wrote: On Tue, 2006-06-20 at 13:52 -0400, Sakala, Adinarayana wrote: == Initial Committers == ... * Hani Suileman Wow. Interesting. Never imagined Hani'd come our way. See for example his latest masterpiece from http://www.jroller.com/page/fate/?anchor=defecating_on_a_jdk: "In a rather perplexing move, it's announced that the Java 6 JDK will include Derby, the turdy little unwanted IBM poop plopped onto Apache (about par for the course, since large swathes of Apache seem to exit solely as an IBM marketing tool.)" And also from http://www.jroller.com/page/fate/?anchor=javaone_bea_keynote: "Someone must have given him the wrong suppository to make him say such horrible things, come on, of all people, surely he'd know that Apache does NOT have 'cool software'?" And also from (my personal favorite of course) http://www.jroller.com/page/fate/?anchor=axis2_why_bother: "Swing development requires people with at least a double digit IQ, which (with maybe two exceptions) nobody at the Java side of Apache has managed to evolve to." and "As much as I hate Apache, one thing one could always count on is their moralistic holier than thou good behaviour." Is Hani seriously going to participate in an Apache meritocracy or is this some kind of joke? Sanjiva. - 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: Extensible Ajax Platform (XAP) Project Update
On 6/23/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: The use of e-mail as the primary means for communication is part of ASF policy and philosophy, and we can certainly learn lessons from projects that have gone against it. IRC tends to breed a more closed, albeit arguably more integrated, community. That said, if IRC can be used as a learning tool to rapidly bring new people up to speed, and if the information gathered from those sessions is preserved for others to follow up via web-site and e-mail, how do people perceive that? I've never done that on a project, but I think it could be a reasonable thing for a project to try. I believe the Synapse folks have been doing regular IRC meetings from early on. I'd be interested in their perspective on the pros and cons, particularly as an incubating project. As a XAP mentor, I know that the committers already understand that no decisions will be made over IRC, that logs of each IRC will be immediately made available to the entire community, and that they need to be sensitive to any concerns from people wishing but unable to participate. But, are there other thoughts from the Synapse folks or anyone else who has used regular IRC meetings? Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Extensible Ajax Platform (XAP) Project Update
Matthias Wessendorf wrote: > > IMHO, all of the discussions, especially this early on, should be happening > > on the mailing lists, to encourage more people to participate, and thus help > > grow the community. > +1 on that. The use of e-mail as the primary means for communication is part of ASF policy and philosophy, and we can certainly learn lessons from projects that have gone against it. IRC tends to breed a more closed, albeit arguably more integrated, community. That said, if IRC can be used as a learning tool to rapidly bring new people up to speed, and if the information gathered from those sessions is preserved for others to follow up via web-site and e-mail, how do people perceive that? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Heraldry Identity Project
Just to follow up, I just ran into this announcement by SUN w/r/t Non-assertion Covenants, which is exactly the sort of mechanism I've been advocating to make Open Source implementation and adoption more frictionless: http://xml.coverpages.org/ni2006-06-15-a.html I'd suggest all the interested parties review this page - including some of the background info on the bottom of the page. -Gabe > -Original Message- > From: Wachob, Gabe > Sent: Tuesday, June 20, 2006 12:05 PM > To: 'Drummond Reed'; [EMAIL PROTECTED]; general@incubator.apache.org > Cc: 'Peter Davis'; 'Graves, Michael' > Subject: RE: [PROPOSAL] Heraldry Identity Project > > Hello folks- > I read this thread with a *ton* of sympathy. I think > Drummond characterizes the situation correctly. I have > (several times) raised exactly these concerns to the OASIS > community (see [1] in particular and followups on [2] and > [3]). There is actually a lot of sympathy and even some > action (see [4] - which relates to SAML and RSA > specifically!) - the action that is most helpful are > statements of non-action covenants by patent owners (in > OASIS, particpants are required to disclose the fact that > they have relevant patents). > I personally have done (and continue to do) anything I > can to make XRI (and any other useful OASIS spec) > implementable within the constraints of the ASF's mode of > operation. I think its good practice for the community at > large, open source or not. > If one of you folks from Apache could make these concerns > very obvious to the OASIS community (perhaps just a summary > of this thread from one of the ASF folks that I could forward > to the relevant OASIS lists), I think that would go a long > way towards pushing the issue forward. > > -Gabe > > [1] http://www.oasis-open.org/archives/chairs/200604/msg00013.html > [2] http://www.oasis-open.org/archives/chairs/200604/maillist.html > [3] http://www.oasis-open.org/archives/chairs/200605/maillist.html) > [4] http://www.oasis-open.org/archives/chairs/200605/msg00018.html > > > -Original Message- > > From: Drummond Reed [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 20, 2006 9:55 AM > > To: [EMAIL PROTECTED]; general@incubator.apache.org > > Cc: Wachob, Gabe; 'Peter Davis'; 'Graves, Michael' > > Subject: RE: [PROPOSAL] Heraldry Identity Project > > > > Dims, > > > > I am very familiar with the SAML and OpenSAML problems; on > > this message I'm > > cc'ing Peter Davis of NeuStar who has been helping to try to > > overcome those > > for several years (with some recent progress). > > > > Thankfully Peter and Gabe and others who were founding > > members of the XRI TC > > said, "No way we're going down that road -- any and all XRI > > specs will be > > 100% royalty-free and open source-compatible, i.e., not require any > > licensing". > > > > We have stayed true to that. Although XRI Resolution 2.0 does > > offer both > > HTTPS-based resolution and SAML 2.0 signed assertions as > > trust options, both > > are OPTIONAL and not in any way required. > > > > So I can provide you with a very strong assurance on behalf > > of the OASIS XRI > > TC members that the XRI specifications and any code that > > implements them > > will meet the Apache IPR requirements. > > > > My co-chair Gabe Wachob and I have been one of a set of OASIS > > TC chairs that > > have been arguing hard for OASIS to adopt a more explicit > "open source > > compatible" IPR mode, and we would be happy to work with you > > and ASF to > > continue to champion it. But at the same time we don't want > > that to slow > > down any existing OASIS work such as XRI and XDI which has > > always been 100% > > committed to open, royalty-free, open-source compatible specs. > > > > In other words, we don't want our TC's penalized for the sins > > of other large > > OASIS members who may not be as supportive of open source. > > > > Please let us know how else we can assist this effort. > > > > =Drummond (http://xri.net/=drummond.reed) > > > > -Original Message- > > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 20, 2006 6:26 AM > > To: general@incubator.apache.org > > Cc: Drummond Reed; [EMAIL PROTECTED] > > Subject: Re: [PROPOSAL] Heraldry Identity Project > > > > Drummond, > > > > Here's some background history of things that we have faced. > > > > OpenSAML folks were interested in making OpenSAML an > Apache project. > > So we did a bit of research and realized that RSA Security > has put up > > a page asking folks to sign a patent licensing aggrement [1]. AFAIK, > > SAML is also under "open, public, and royalty-free". Apache > could even > > sign something with them, BUT for a clause that says that we have to > > inform people who use our binaries to go talk to RSA > Security. For us, > > this was not acceptable. So we ended up not incubating OpenSAML. > > Please see the following threads for
RE: Lucene.NET Jira Emails?
: If this is the case, who ever has the karma to fix this, can you take care : of it? I think the proper way to deal with this is to file a Jira request with the Infrastructure Project in the JIRA component, but I'm not 100% sure. : Also, I can't figure out how to assign, close or even edit a JIRA issue : opened against Lucene.Net. For example, take a look at: : http://issues.apache.org/jira/browse/LUCENENET-6 and I can't see anything : there to edit this issue. Yes, I am logged in. That's the Permission Scheme thing I mentioned -- it seems that members of the "lucene-developers" Jira Group (the Java Lucene Developers that is) eare the ones who can modify LUCENENET issues. : : I don't think this is intentional. Something is broken in the JIRA setup. : : I have posted this email on general@incubator.apache.org to see if folks : : there may know what's the problem and fix it. : : It looks like when the LUCENENET Jira project was setup, the "Permission : Scheme" and "Notification Scheme" wre set to "Lucene Permissions" and : "Lucene Notification Scheme" instead of making new ones specific to : LUCENENET (perhaps someone assumed the "Lucene *" Schemes were generic for : all projects, not specific to the Lucene Java project) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Heraldry Identity Project
Dims, I am very familiar with the SAML and OpenSAML problems; on this message I'm cc'ing Peter Davis of NeuStar who has been helping to try to overcome those for several years (with some recent progress). Thankfully Peter and Gabe and others who were founding members of the XRI TC said, "No way we're going down that road -- any and all XRI specs will be 100% royalty-free and open source-compatible, i.e., not require any licensing". We have stayed true to that. Although XRI Resolution 2.0 does offer both HTTPS-based resolution and SAML 2.0 signed assertions as trust options, both are OPTIONAL and not in any way required. So I can provide you with a very strong assurance on behalf of the OASIS XRI TC members that the XRI specifications and any code that implements them will meet the Apache IPR requirements. My co-chair Gabe Wachob and I have been one of a set of OASIS TC chairs that have been arguing hard for OASIS to adopt a more explicit "open source compatible" IPR mode, and we would be happy to work with you and ASF to continue to champion it. But at the same time we don't want that to slow down any existing OASIS work such as XRI and XDI which has always been 100% committed to open, royalty-free, open-source compatible specs. In other words, we don't want our TC's penalized for the sins of other large OASIS members who may not be as supportive of open source. Please let us know how else we can assist this effort. =Drummond (http://xri.net/=drummond.reed) -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 6:26 AM To: general@incubator.apache.org Cc: Drummond Reed; [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Heraldry Identity Project Drummond, Here's some background history of things that we have faced. OpenSAML folks were interested in making OpenSAML an Apache project. So we did a bit of research and realized that RSA Security has put up a page asking folks to sign a patent licensing aggrement [1]. AFAIK, SAML is also under "open, public, and royalty-free". Apache could even sign something with them, BUT for a clause that says that we have to inform people who use our binaries to go talk to RSA Security. For us, this was not acceptable. So we ended up not incubating OpenSAML. Please see the following threads for additional info [2] We've also had a follow up interaction with MSFT and IBM legal teams on OASIS WS-Security when we started TSIK incubation. FWIW, Verisign has an aggrement that they give out to people BUT not which is not public. MSFT and IBM ended up saying that they don't have any patents that affect WS-Security and Versign was covered using CCLA and Software Grant. For us here, we want to make sure that *anyone* can download our stuff and use it in whichever fashion they want to. Both code and binaries. Right now OASIS does not have a mechanism to make that happen (Verisign has a non-public agreement for WS-Security, RSA Security has clauses that make it impossible for us to do a SAML impl). Both the old legacy regime and the new IPR regime in OASIS have holes IMHO. How can we prevent these kinds of situation from happening? thanks, dims [1] http://www.rsasecurity.com/node.asp?id=2530 [2] http://marc.theaimsgroup.com/?l=incubator-general&w=2&r=1&s=OpenSAML&q=b On 6/20/06, Recordon, David <[EMAIL PROTECTED]> wrote: > This has obviously been something we've been looking at in order to do > our own due diligence on XRI IPR before being willing to contribute the > Yadis spec to be incorporated into XRI Resolution 2.0. Drummond Reed > sent me the following email further explaining this issue and asked me > to forward it along to the list for him since he had not yet subscribed. > > David, > As we discussed with you in drafting the proposal, all members of the > OASIS XRI TC are fully prepared to sign the CCLA and any necessary > software grants required by the ASF. In fact the OASIS XRI TC is one of > the few OASIS TCs to have written the requirement into its charter for > its specifications to be 100% open, public, and royalty-free. Following > is the exact language from the XRI TC charter at > http://www.oasis-open.org/committees/xri/charter.php. > > > In no event shall this Technical Committee finalize or approve any > technical > > specification if it believes that the use, distribution, or > implementation of > > such specification would necessarily require the unauthorized > infringement of > > any third party rights known to the Technical Committee, and such > third party > > has not agreed to provide necessary license rights on perpetual, > royalty-free, > > non-discriminatory terms. > > As you know, I was personally involved not just in creating the patents > involved, but in subsequently seeing that they were contributed to a > non-profit public trust organization, XDI.org, so that they could become > open, public, royalty-free standards. Complete details of the > contribution from XDI.org to the OASIS XRI TC
Re: [PROPOSAL] Heraldry Identity Project
On 6/20/2006 12:55 PM, "Drummond Reed" <[EMAIL PROTECTED]> wrote: > Dims, > > I am very familiar with the SAML and OpenSAML problems; on this message I'm > cc'ing Peter Davis of NeuStar who has been helping to try to overcome those > for several years (with some recent progress). I'll point out that SAML no longer has the IPR concerns. Both RSA and Fidelity have dropped their licensing requirements, and Sun also made recent announcements on this. [1] Wrt XRI, as drummond pointed out, the TC was chartered explicitly with the intent of performing as a unencumbered specification committee. =peterd ( http://xri.net/=peterd ) [1] http://www.oasis-open.org/committees/security/ipr.php - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Heraldry Identity Project
Hello folks- I read this thread with a *ton* of sympathy. I think Drummond characterizes the situation correctly. I have (several times) raised exactly these concerns to the OASIS community (see [1] in particular and followups on [2] and [3]). There is actually a lot of sympathy and even some action (see [4] - which relates to SAML and RSA specifically!) - the action that is most helpful are statements of non-action covenants by patent owners (in OASIS, particpants are required to disclose the fact that they have relevant patents). I personally have done (and continue to do) anything I can to make XRI (and any other useful OASIS spec) implementable within the constraints of the ASF's mode of operation. I think its good practice for the community at large, open source or not. If one of you folks from Apache could make these concerns very obvious to the OASIS community (perhaps just a summary of this thread from one of the ASF folks that I could forward to the relevant OASIS lists), I think that would go a long way towards pushing the issue forward. -Gabe [1] http://www.oasis-open.org/archives/chairs/200604/msg00013.html [2] http://www.oasis-open.org/archives/chairs/200604/maillist.html [3] http://www.oasis-open.org/archives/chairs/200605/maillist.html) [4] http://www.oasis-open.org/archives/chairs/200605/msg00018.html > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 9:55 AM > To: [EMAIL PROTECTED]; general@incubator.apache.org > Cc: Wachob, Gabe; 'Peter Davis'; 'Graves, Michael' > Subject: RE: [PROPOSAL] Heraldry Identity Project > > Dims, > > I am very familiar with the SAML and OpenSAML problems; on > this message I'm > cc'ing Peter Davis of NeuStar who has been helping to try to > overcome those > for several years (with some recent progress). > > Thankfully Peter and Gabe and others who were founding > members of the XRI TC > said, "No way we're going down that road -- any and all XRI > specs will be > 100% royalty-free and open source-compatible, i.e., not require any > licensing". > > We have stayed true to that. Although XRI Resolution 2.0 does > offer both > HTTPS-based resolution and SAML 2.0 signed assertions as > trust options, both > are OPTIONAL and not in any way required. > > So I can provide you with a very strong assurance on behalf > of the OASIS XRI > TC members that the XRI specifications and any code that > implements them > will meet the Apache IPR requirements. > > My co-chair Gabe Wachob and I have been one of a set of OASIS > TC chairs that > have been arguing hard for OASIS to adopt a more explicit "open source > compatible" IPR mode, and we would be happy to work with you > and ASF to > continue to champion it. But at the same time we don't want > that to slow > down any existing OASIS work such as XRI and XDI which has > always been 100% > committed to open, royalty-free, open-source compatible specs. > > In other words, we don't want our TC's penalized for the sins > of other large > OASIS members who may not be as supportive of open source. > > Please let us know how else we can assist this effort. > > =Drummond (http://xri.net/=drummond.reed) > > -Original Message- > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 6:26 AM > To: general@incubator.apache.org > Cc: Drummond Reed; [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Heraldry Identity Project > > Drummond, > > Here's some background history of things that we have faced. > > OpenSAML folks were interested in making OpenSAML an Apache project. > So we did a bit of research and realized that RSA Security has put up > a page asking folks to sign a patent licensing aggrement [1]. AFAIK, > SAML is also under "open, public, and royalty-free". Apache could even > sign something with them, BUT for a clause that says that we have to > inform people who use our binaries to go talk to RSA Security. For us, > this was not acceptable. So we ended up not incubating OpenSAML. > Please see the following threads for additional info [2] > > We've also had a follow up interaction with MSFT and IBM legal teams > on OASIS WS-Security when we started TSIK incubation. FWIW, Verisign > has an aggrement that they give out to people BUT not which is not > public. MSFT and IBM ended up saying that they don't have any patents > that affect WS-Security and Versign was covered using CCLA and > Software Grant. > > For us here, we want to make sure that *anyone* can download our stuff > and use it in whichever fashion they want to. Both code and binaries. > Right now OASIS does not have a mechanism to make that happen > (Verisign has a non-public agreement for WS-Security, RSA Security has > clauses that make it impossible for us to do a SAML impl). Both the > old legacy regime and the new IPR regime in OASIS have holes IMHO. > > How can we prevent these kinds of situation from happening? > > thanks
Fw: [VOTE] Declare Woden 1.0.0 M5
So far the candidate Woden M5 release has received one +1 binding vote from Dims but requires two more +1 votes from Incubator PMC members before it can be released. There have been no +0 or -1 votes. I'd like to ask the Incubator PMC again to review this request and vote on it. thanks in advance, John Kaputin - Forwarded by John Kaputin/UK/IBM on 20/06/2006 23:24 - John Kaputin/UK/[EMAIL PROTECTED] MGBTo general@incubator.apache.org 16/06/2006 18:08 cc woden-dev@ws.apache.org, [EMAIL PROTECTED], Please respond to [EMAIL PROTECTED] [EMAIL PROTECTED] Subject he.org [VOTE] Declare Woden 1.0.0 M5 Following the release process for projects in incubation, I'd like to request approval for the Woden incubator project [1] to declare its Milestone 5 release. A vote was held on the woden-dev list [2] where M5 received 5 +1 votes and no negative votes. The votes collected are as follows: John Kaputin +1 Lawrence Mandel +1 Chathura Herath +1 Jeremy Hughes +1 Arthur Ryman +1 As required of releases from projects in incubation, the distributable archives contain 'incubating' in their names. The M5 archives can be found at http://cvs.apache.org/dist/ws/woden/milestones/1.0.0M5-incubating/. My original post summarizing Woden 1.0.0 M5 can be found at [2]. Please vote by 5pm EST, Monday, June 19, 2006. Thanks, John Kaputin [1] http://incubator.apache.org/woden/ [2] http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200606.mbox/[EMAIL PROTECTED] - 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]
Woden Milestone 5 declared
June 21, 2006 - Woden milestone 5 declared! Congratulations to the Woden team. Download the milestone and view the release notes at http://people.apache.org/dist/ws/woden/milestones/1.0.0M5-incubating/ More information can be found on the Woden website - http://incubator.apache.org/woden John Kaputin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Celtixfire project
Hiya. I would like to become a committer on the celtixfire project. I work on the JBossESB project and would like to make sure that the two projects work closely together. Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jini Project
> The community is developing the software, no? The software that's being proposed as the initial source for the ASF project has not been under open source development to date. Almost all of it is code that has been developed and controlled by one group at Sun. There's been active and ongoing community input and feedback, but not community-based development. A critial part of incubation will be evolving to open source development. Jini.org today hosts many different projects, all developed by different sets of people under various development practices. Many of those projects are now moving to java.net, some to other sites. All of those projects are and will continue to be, to my mind, part of the Jini community. So I see the proposed ASF project as being (a key) part of the larger Jini community (vs the Jini community "moving" to ASF). Having written that, I guess I've just explained to myself why the ASF project should not be merely "Jini", and should either have a different name or an additional qualifier. (As for trademark issues, I'll defer to Jim Hurley to chime in.) - Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committers
Leo et al. thanks for you valid input. The PPMC list has been created. (Before this thread started). Brett told us that, after I created a jira ticket for that. Now we use the PPMC for *private* discussions. Regards, Matthias On 6/23/06, Leo Simons <[EMAIL PROTECTED]> wrote: On Thu, Jun 22, 2006 at 12:55:54PM -0700, Matthias Wessendorf wrote: > >What do you *want* to do? What makes most sense? > > well, MyFaces PMC is faster; but adffaces-ppmc has it's charme too. > But... after adf is a subproject we'll need to delete this list. ^^^ archive/disable > So, what is easier for you guys? Creating a mailing list is about 2-3 minutes of work, archiving it perhaps just a little more. Infrastructure is chronically lacking volunteers, but this kind of thing is nevertheless something that's ok to ask for :) > I think we should take the time for creating a PPMC list. > Should I bring it up to the INCUBATOR jira? Or the IPMC? Or Craig? > who is our mentor. What's most important is that there's agreement before there's a request for resources. Get agreement somewhere ([EMAIL PROTECTED] is probably the wrong forum for that :) ), *then* file a jira issue as documented on www.apache.org/dev/. Craig can do that, but others can as well. As long as its clear the request is inline with policy and after a PMC agreed on it. The incubator PMC is on this list and some individuals have offered opinions; I don't think you need to ask for formal approval from us. The use of PPMC lists is established practice :) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jini Project
It's my impression that the trademark would be donated to the ASF to avoid this problem. I'm not sure though. geir Leo Simons wrote: > On Thu, Jun 22, 2006 at 03:43:13PM -0400, Bob Scheifler wrote: >> Leo Simons wrote: >>> I guess this means keeping jini.org around for a long time to come, and I >>> think >>> this means you need a name for "[EMAIL PROTECTED]" which is not "jini" :) >> Could you expand on why you think that? Thanks. > > IANAL and not an expert but I can try. > > More concretely, "jini" is a name/brand/trademark which seens to > be governed by eg > > http://www.sunsource.net/TUPPCP.html > http://www.sun.com/suntrademarks/ > > And is owned by sun for which there are rather strict guidelines: > > http://www.sun.com/policies/trademarks/ > > Similarly, terms like "apache", "jakarta", "tomcat" are also marks > (even if not registered) which are somehow "owned" by the ASF (and > we have a PRC committee to protect them). > > When "SpamAssassin" entered incubation the trademark (which was > registered) ownership was transferred to the ASF, so the name was > kept for the new project. > > If the "jini" name is not "owned" by the ASF (not just legally, also > morally), we shouldn't name our software directly after it, for a > variety of reasons, like > > * its less confusing for users > * it avoids potential legal worries > * it avoids a whole lot of discussion, hurt feelings, etc. > * if a project ever outgrows its original boundaries a bit > (happens quite often, for example lucene had a C port while > it was still at jakarta) its not a problem > > This is why there is no java.apache.org but instead there is > jakarta.apache.org, there is no j2se.apache.org but there is harmony, > there is no j2ee.apache.org but there is geronimo, etc. > > There was, in fact, at some point, a java.apache.org, and IIUC the ASF > got a lot of flak about that from sun legal (and rightly so). > > While its quite possible to change names halfway through incubation, > in general IMHO its just easier to "bite the bullet" up front because > various resources (jira projects, svn repositories, mailing lists, etc) > are coupled to the name. > > To answer another question, yes, I believe this also means that there > should be no "jini" in the name. There's a variety of creative ways > most open source projects deal with that, like putting lots of extra > letters in and around a word, naming by association (so you end up > with "Apache Aladdin" since that's about genies too), or naming through > acronyms (so you end up with "Apache JiKit" for "JIni Kit"). > > I hope the above is clear. I'm really no expert. If there's need for > further details, I would suggest talking to a trademark/branding lawyer > or two. But usually its just a lot easier to pick a new name, so that's > what we tend to do :) > > LSD > > - > 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: Various
Craig McClanahan wrote: > On 6/22/06, Hani Suleiman <[EMAIL PROTECTED]> wrote: >> >> I'm fairly astounded by the amount of email generated due to my name >> being on the initial committer list. > > > PS: Hani, will you *please* someday, just once, spell my name correctly so > that Google can find your pearls of wisdom about me? :-) > Just for the record, here's the list I've accumulated : Craig McLanalanahamabanahan Craig Mcflanabanawanaflafla Craig Mclanaflanapoopoo Craig Mclanafanablahblahhan Craig Mclalaflahwibble Craig Mcflafla Craig Mcclalalanasomethingortheother Craig McBlahblah Craig McFlaBlahlan Craig McThingy Craig Mcflaflaweewomjibberploppy I'd be flattered, Craig :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
Hi Leo, On Jun 23, 2006, at 10:41 AM, Leo Simons wrote: "The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users." Some of the keywords there relevant to this thread are "collaborative" and "community". We expect many simple things from each other such as * showing respect for your peers * making sure your e-mails to apache mailing lists are PG-13 and preferably suitable for all ages * not making unfounded assertions * never "flaming" other people, especially not in public * no trolling or flaming in general Yep, and I think in every technical context (and by that I mean any community I'm part of, whether it be the JCP, Opensymphony, a bunch of java.net projects, and so on) I've always adhered to every single one of these rules, or promptly apologised if I'd ever stepped over the line. The only venue that's an exception to these rules of good behaviour is my blog, and that will remain an exception. I apologise if my email came off to harshly, that was certainly not my intent. It was bourne out of frustration from (for the first time) seeing people judge me based on a blog I write for fun, that is it in any way tied or or relevant to what I do *professionally*. Perhaps I should have been clearer when I said 'technical', and made it obvious that it's not just about the code, or how good (or bad) of a developer I am, it's about how I function in mailing lists, how I am towards people asking for help, and whether I play nice in whatever ecosystem I'm in. ALL those to me count as professional environments, where unprofessional behaviour will be weeded out very quickly. The bileblog is what it is, and will remain what it is. My behavior in other situations similar to the current one (ie, being part of a community) is what should be under scrutiny, not what I choose to do in my spare time. Anyway, as flattering it is to be the subject of so much attention, I think it's more worthwhile to instead focus on cxfire and question its merit, than on some random committer who does weird things in his spare time! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
You clearly have no clue! Just as an example. - Daniel Kulp from IONA is a Tuscany Committer. Which is a WS PMC sponsored Incubator project - Daniel Diephouse from Envoi working on XFire is a WS Committer as he earned karma on the XmlSchema project. FWW, Thanks for letting people see your true colors. Geir has always told me that your blog is a Literary device. It's just abundantly clear that it is a farce. I'll let my actions speak for themselves rather than stoop to your level. thanks, dims On 6/23/06, Hani Suleiman <[EMAIL PROTECTED]> wrote: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. It is interesting to note that all the people who have objected are those who feel personally offended by some of my writing (specifically, the tomcat and axis2 rants...ironically my tomcat DefaultServlet rant was purely technical and did not degenerate into my usual personal insult comfort zone). I'm sorry that you can't take a little criticism, and while I will happily admit that yes, I did insult you in ways that you probably didn't quite expect, I fully stand by everything I said, and will still insist that Axis2 and Tomcat are awful projects, that are badly written and have only gotten where they are today due to marketing forces, instead of technical merit. I am perplexed that you feel that a dislike of an Apache project merits a membership rejection though. Does everyone at Apache love every project there? If that were the case, then the whole ecosystem is in a far unhealthier state than anyone on the outside might suspect. If Apache people feel that my technical abilities are not relevant, and that what should matter in whether I am allowed in as a cxfire committer is how willing I am to tow the party line, then I shouldn't be on that list. Apache would be the first organisation I've joined (or might have joined) that did not judge me on technical merit; quite an irony considering the whole meritocracy approach that Apache claims. This is, astoundingly, my first experience of being judged not on technical merit, but on random blathering that serves no particular purpose than ranting for ranting's sake. Just to set expectations, I will not stop saying things like 'Apache sucks', because I still do think that many of the processes and members have some terrible flaws. I am not aware of any Apache membership requirements that state that one's freedom of speech and expression are curtailed in any way; it is after all an alleged meritocracy, all that matters is how good the code I check in is, and how well I play within the team I'm a member of. If the cxfire team at any point feels I'm a liability rather than an asset, I would gladly leave. In fact I'd like to think that I'm self-aware enough to leave way before they feel the need to ask me to. I know plenty of Apache members who find many of the processes cumbersome and onerous, yet are still active participants; nobody seems to threaten them with being kicked out. I believe in cxfire, and think it's a superb project. I think competition in this space is healthy, and think it's rather lame that people like dims and sanjiva keep trying to cast doubts on the validity of the project, just because it happens to eat into their projected revenues. It does feel like there's a small amount of hypocrisy going around, where people express concern that cxfire has many IONA people involved, without noticing that most of the objectors are WSO2 people, who (quite rationally) put WSO2 priorities ahead of Apache ones. If there's a policy of only endorsing one technology for any given field within Apache, then sure, cxfire does not belong. If there is space for allowing competing technologies, then I fail to see why xfire choosing to ignore axis2 or not support it has any relevant at all as to whether it can live in Apache or not. I always thought that despite all its flaws, Apache was a great ground for the 'let a thousand flowers bloom' approach, and I am frankly disturbed by how much say commercial interests seem to have in whether projects get accepted or not. In many ways this thread has left me with an even worse impression of Apache than I already had, which is, believe or not, a very sad thing. I'd like to think that Apache is a meritocracy, driven by technology, with no allegiance to commercial interests. It is driven by the concept of open source for the sake of open source; not open source that we can now build a company around and get funding and piss around with in order to make a living to avoid having a real job. Certainly not the latter to the exclusion of the former! On that basis, I cannot conceive of a single good reason for rejecting cxfire. By all criteria that count, it's a successful project, it is widely deployed, it has an active developer base, and an interested and participatory community. So what if it happens to be technically superior to Axis2 (at least, in most people's opinions
Re: Various
Hani, (I'm a big BileBlog fan. I'm ever so upset that Geir always gets named when it comes to Harmony while I and more importantly quite a few others also pour lots of effort in too. I did a lightning talk at ApacheCon Las Vegas titled "The ASF sucks". I had 5 minutes, I could've gone on for 30. Lots of fun. I think most people liked it. I'm a committer and member and things like that around here. Most people around here appreciate some good roasting or bile as much as the next person.) On Fri, Jun 23, 2006 at 05:52:51AM +0100, Hani Suleiman wrote: > I'm fairly astounded by the amount of email generated due to my name > being on the initial committer list. I would say I was a little surprised. This e-mail of yours is also a bit of a surprise though. Nevertheless. To respond to this actual email. www.apache.org says "The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users." Some of the keywords there relevant to this thread are "collaborative" and "community". We expect many simple things from each other such as * showing respect for your peers * making sure your e-mails to apache mailing lists are PG-13 and preferably suitable for all ages * not making unfounded assertions * never "flaming" other people, especially not in public * no trolling or flaming in general Being frank and undiplomatic is fine. I'm frank and undiplomatic all the time. Saying some piece of software is bad is fine (if backed up by technical argument or reference). For example if I mention that I think that SOAP is a bad idea in the first place (I do) and that I think that all implementations of it today all have rather serious problems (for example, scalability is simply still a joke. 50 than 3 requests per second is still abonimable. I want 5000, and mind you, when running on my laptop), that is fine. But e-mails like this one basically do fit the 20-year-old textbook definitions of "trolling" and "flaming" that the usenet people invented way back. I won't bother picking it apart to point this out, I'm rather confident you know exactly what I mean. Being frank and undiplomatic again, we don't have all that many people around here who repeatedly display that kind of behaviour on apache mailing lists, and that's not about to change. Now, could we please get back to more interesting things? LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
On Fri, 2006-06-23 at 05:52 +0100, Hani Suleiman wrote: > It is interesting to note that all the people who have objected are > those who feel personally offended by some of my writing > (specifically, the tomcat and axis2 rants...ironically my tomcat I was never personally offended by your rants. However, I was very impressed by what it shows about you as a person. > I'm sorry that you can't take > a little criticism, and while I will happily admit that yes, I did > insult you in ways that you probably didn't quite expect, I fully > stand by everything I said, and will still insist that Axis2 and > Tomcat are awful projects, that are badly written and have only > gotten where they are today due to marketing forces, instead of > technical merit. Thanks for clarifying this- several people have said on this list that your blog is simply a public persona and that you don't really believe in what you write there. Your statement shows that they don't know you as well as they thought they did! > I am perplexed that you feel that a dislike of an > Apache project merits a membership rejection though. Does everyone at > Apache love every project there? If that were the case, then the > whole ecosystem is in a far unhealthier state than anyone on the > outside might suspect. Who said anything about loving every project? Apache is fundamentally about communities and not about code. It doesn't matter whether I or any other ASF person likes the technical rationale/motivation/aspects of the project or not- as long as a healthy community exists for it then its a great project from ASF's perspective. That project may produce software for underwater basketweaving, but the ASF doesn't worry about the technical merits of such software. > I believe in cxfire, and think it's a superb project. I think > competition in this space is healthy, and think it's rather lame that > people like dims and sanjiva keep trying to cast doubts on the > validity of the project, just because it happens to eat into their > projected revenues. Coming from a guy who loves to dish out criticism, how come you can't take a bit of it? The "casting doubt" was to understand what it is .. the proposal talks about SOA etc. etc. and James, one of the mentors, says "SOA means nothing" (paraphrased) and the different people give different explanations of what it is. If the people who proposed the project don't quite agree what it is, how do you expect to form a healthy community? Here's what I wrote to James' explanation of what it is: On Thu, 2006-06-22 at 17:30 +0200, James Strachan wrote: > > CeltixFire is aimed at implementing the JAX-WS/JAX-WSA/JSR-181 > standards which are the newer standards for working with SOAP & > WS-Addressing on the Java platform Thanks for the clarification. So its basically an alternate to Axis2 as we are working on all these specs there too; which of course is cool .. alternates are a good way to figure out different ways of skinning a cat and eventually we'll find the right way (hopefully before the cat dies ;-)). Where is there anything there saying Apache doesn't accept alternatives? Or where does it say that I objected to it? If its an alternate to Axis2, then I'm glad to +1 it. > It does feel like there's a small amount of > hypocrisy going around, where people express concern that cxfire has > many IONA people involved, without noticing that most of the > objectors are WSO2 people, who (quite rationally) put WSO2 priorities > ahead of Apache ones. Instead of looking at where people are employed why don't you look at what we do in Apache and why that gives us the credibility to ask these questions? I've been contributing to Apache since 1998, when I wrote the extension code for Xalan, using then IBM BSF, which also I created. BSF is of course now an Apache project. I was the one who created Apache SOAP originally (along with Matt Duftler from my group in IBM). I've participated in numerous WS projects and created the Axis2 effort long before WSO2 was even conceived. I doubt you can find a *single* place where I've let WSO2 priorities come in front of ASF ones. Paul has been involved since about 2001, when the WSIF project was donated to Apache by IBM. Paul is now a leading contributor to Synapse. Dims has been around since I don't know when .. before me too I believe (in Cocoon) and he is of course chair of the WS PMC, which is a position he earned by his long and solid contributions to WS projects. Again, he got to that position before WSO2 was ever conceived. We have all *earned* the right to question what these new projects are how they should or should not be brought into the ASF. > If there's a policy of only endorsing one technology for any given > field within Apache, then sure, cxfire does not belong. If there is > space for allowing competing technologies, then I fail to see why > xfire choosing to ignore axis2 or not support it h
Re: New committers
On Thu, Jun 22, 2006 at 12:55:54PM -0700, Matthias Wessendorf wrote: > >What do you *want* to do? What makes most sense? > > well, MyFaces PMC is faster; but adffaces-ppmc has it's charme too. > But... after adf is a subproject we'll need to delete this list. ^^^ archive/disable > So, what is easier for you guys? Creating a mailing list is about 2-3 minutes of work, archiving it perhaps just a little more. Infrastructure is chronically lacking volunteers, but this kind of thing is nevertheless something that's ok to ask for :) > I think we should take the time for creating a PPMC list. > Should I bring it up to the INCUBATOR jira? Or the IPMC? Or Craig? > who is our mentor. What's most important is that there's agreement before there's a request for resources. Get agreement somewhere ([EMAIL PROTECTED] is probably the wrong forum for that :) ), *then* file a jira issue as documented on www.apache.org/dev/. Craig can do that, but others can as well. As long as its clear the request is inline with policy and after a PMC agreed on it. The incubator PMC is on this list and some individuals have offered opinions; I don't think you need to ask for formal approval from us. The use of PPMC lists is established practice :) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jini Project
On Thu, Jun 22, 2006 at 03:43:13PM -0400, Bob Scheifler wrote: > Leo Simons wrote: > > I guess this means keeping jini.org around for a long time to come, and I > > think > > this means you need a name for "[EMAIL PROTECTED]" which is not "jini" :) > > Could you expand on why you think that? Thanks. IANAL and not an expert but I can try. More concretely, "jini" is a name/brand/trademark which seens to be governed by eg http://www.sunsource.net/TUPPCP.html http://www.sun.com/suntrademarks/ And is owned by sun for which there are rather strict guidelines: http://www.sun.com/policies/trademarks/ Similarly, terms like "apache", "jakarta", "tomcat" are also marks (even if not registered) which are somehow "owned" by the ASF (and we have a PRC committee to protect them). When "SpamAssassin" entered incubation the trademark (which was registered) ownership was transferred to the ASF, so the name was kept for the new project. If the "jini" name is not "owned" by the ASF (not just legally, also morally), we shouldn't name our software directly after it, for a variety of reasons, like * its less confusing for users * it avoids potential legal worries * it avoids a whole lot of discussion, hurt feelings, etc. * if a project ever outgrows its original boundaries a bit (happens quite often, for example lucene had a C port while it was still at jakarta) its not a problem This is why there is no java.apache.org but instead there is jakarta.apache.org, there is no j2se.apache.org but there is harmony, there is no j2ee.apache.org but there is geronimo, etc. There was, in fact, at some point, a java.apache.org, and IIUC the ASF got a lot of flak about that from sun legal (and rightly so). While its quite possible to change names halfway through incubation, in general IMHO its just easier to "bite the bullet" up front because various resources (jira projects, svn repositories, mailing lists, etc) are coupled to the name. To answer another question, yes, I believe this also means that there should be no "jini" in the name. There's a variety of creative ways most open source projects deal with that, like putting lots of extra letters in and around a word, naming by association (so you end up with "Apache Aladdin" since that's about genies too), or naming through acronyms (so you end up with "Apache JiKit" for "JIni Kit"). I hope the above is clear. I'm really no expert. If there's need for further details, I would suggest talking to a trademark/branding lawyer or two. But usually its just a lot easier to pick a new name, so that's what we tend to do :) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
Hani Suleiman wrote: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. [...] I'm sorry that you can't take a little criticism, and while I will happily admit that yes, I did insult you in ways that you probably didn't quite expect, I fully stand by everything I said, and will still insist that Axis2 and Tomcat are awful projects And I strongly believe that if that's what you had blogged, there really would be no [legitimate] objections in this discussion. Apache would be the first organisation I've joined (or might have joined) that did not judge me on technical merit; And technical merit, or debate on technical issues (like you identified in your rants) is *entirely* the appropriate consideration. But you have reread your blog entries a few times to recognize that you -far- exceeded technical objections and ranting? If your blog entries are any indication, you have no issue with lowering the conversation to the level of personal assualts and attacks on individuals, instead of being *appropriately* hot and bothered over technical issues and the resulting code. Your flowerful adjectives aside, if you spoke to the code, and not the coders, nobody would point to your blog and suggest 'hey, this really wouldn't be a very good person to have participate here'. We have had participants in the past who focus on persons instead of issues. And these participants have consistently caused more damage to the code by fracturing the community than they put out in effective LoC. If rather than defending your right to say "Apache FOO Sucks" (which you have, within or outside of the ASF) - if your email addresses the issue of this apparent inability to decouple the code from the coders (who you effectively slam), then perhaps some on this list will be reassured you can work within a community and debate the message without killing the messenger? This is not an issue of towing party lines, consistently nodding your head yes like a robot, or even the ability to play nice. It is about a fundamental respect for your fellow coders, even when you detest what they create. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]