Re: [PROPOSAL] JSPWiki
Henning Schmiedehausen schrieb: > Huh, am I late? Me too ;-) I thought this was just the disussion and the vote would start afterwards. Anyway, as a long time JSPWiki user +1 -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Huh, am I late? +1 (mentoring JSPWiki... ;-) ) Best regards Henning On Tue, 2007-09-11 at 22:41 -0400, Dave wrote: > The proposal was posted Aug. 29, we're up to 4 or 5 binding +1 votes > now and no -1 vote have been cast. > > Binding: > +1 Craig Russell > +1 Noel Bergman > +1 Nicolas Hedman > +1 Ted Husted > > Other: > +1 Dave Johnson (retroactively binding?) > +1 Alexey Petrenko > +1 Martijn Dashorst > > Are we ready to incubate? > > - Dave > > - > 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: [PROPOSAL] JSPWiki
I'd count "Snoop" Dave Johnson as a binding vote, being Incubator PMC. Time's up. Go for't. Craig On Sep 11, 2007, at 7:41 PM, Dave wrote: The proposal was posted Aug. 29, we're up to 4 or 5 binding +1 votes now and no -1 vote have been cast. Binding: +1 Craig Russell +1 Noel Bergman +1 Nicolas Hedman +1 Ted Husted Other: +1 Dave Johnson (retroactively binding?) +1 Alexey Petrenko +1 Martijn Dashorst Are we ready to incubate? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL] JSPWiki
The proposal was posted Aug. 29, we're up to 4 or 5 binding +1 votes now and no -1 vote have been cast. Binding: +1 Craig Russell +1 Noel Bergman +1 Nicolas Hedman +1 Ted Husted Other: +1 Dave Johnson (retroactively binding?) +1 Alexey Petrenko +1 Martijn Dashorst Are we ready to incubate? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
+1 for incubation. It's clear to me from the discussion here that the prospective project is aware of most of the IP, licensing, and third party issues that we deal with at Apache, and I welcome the opportunity to have them continue work in Apache. I'll even volunteer to help mentor if that's needed. Craig On Aug 29, 2007, at 2:02 PM, Janne Jalkanen wrote: Hello all! I am Janne Jalkanen, the lead developer of the open source wiki engine called JSPWiki, and I have a proposal for your enjoyment. This proposal is available in the web at http://www.jspwiki.org/ wiki/ApacheJSPWikiProposal, should you wish to help us to make it better. /Janne - Abstract Apache JSPWiki will be a modular and user-extensible wiki-engine, based on the open source JSPWiki software. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL] JSPWiki
+1 for the overall proposal (binding) On 8/29/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > Hello all! > > I am Janne Jalkanen, the lead developer of the open source wiki > engine called JSPWiki, and I have a proposal for your enjoyment. > This proposal is available in the web at http://www.jspwiki.org/wiki/ > ApacheJSPWikiProposal, should you wish to help us to make it better. > > /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Joining the PMC (was: [PROPOSAL] JSPWiki)
On 9/8/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Dave Johnson wrote: > > > Yes! I'd like to sign up for the Incubator project and Infra to help out. > > OK, I want to be clear, and then I'll get the process done. You are asking > to join the Incubator PMC, and volunteering as a Mentor for JSPWiki? > > The infrastructure side of your offer is best addressed on that group's > lists, as I am sure you realize. :-) Yes. I would like to join the Incubator PMC. What do I need to do to make that happen? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Joining the PMC (was: [PROPOSAL] JSPWiki)
Dave Johnson wrote: > Yes! I'd like to sign up for the Incubator project and Infra to help out. OK, I want to be clear, and then I'll get the process done. You are asking to join the Incubator PMC, and volunteering as a Mentor for JSPWiki? The infrastructure side of your offer is best addressed on that group's lists, as I am sure you realize. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] JSPWiki
> We have all but one tracked down and all have already agreed. > The question is whether they need to sign CLAs or whether it > is just enough that they verbally in an email agree to the > license change. If they want to continue development, they must sign a CLA. If they just want to grant license, they can submit a Software Grant. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] JSPWiki
In general, if there are any questions about IP and/or licensing, you can check with the PMC, and we can go to the Legal Committee. > Also, things like JavaMail libraries are highly useful for our user > experience (e.g. sending email in case the user forgets his > password). If there is an Apache-compatible implementation > available, then fine. JAMES ships with a CDDL version of JavaMail, dropping the non-CDDL version. We wish there were a properly licensed JavaMail, but CDDL is as close as we come for JavaMail until/unless someone wants to work on the shell currently in Geronimo. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] JSPWiki
Henning Schmiedehausen wrote: > these concerns are very valid and good and Janne has demonstrated that > he is aware of this. > However, most of the vetting required is actually *part* of the > incubation process and happens after acceptance into the incubator. > So can we just postpone that discussion a bit and assimilate them > first? ;-) +1 Roller had to deal with this as well. I am not going to revisit all of the examples that have been posted as "But X did ..."; that would be a bit like pointing at the corpus of clueless CGI scripts as examples of how to use HTTP. No releases until dependencies are cleaned up. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
+1 2007/8/30, Janne Jalkanen <[EMAIL PROTECTED]>: > Hello all! > > I am Janne Jalkanen, the lead developer of the open source wiki > engine called JSPWiki, and I have a proposal for your enjoyment. > This proposal is available in the web at http://www.jspwiki.org/wiki/ > ApacheJSPWikiProposal, should you wish to help us to make it better. > > /Janne > > - > > Abstract > > Apache JSPWiki will be a modular and user-extensible wiki-engine, > based on the open source JSPWiki software. > > Proposal > > JSPWiki is a wiki engine available under the Lesser General Public > License. It has a very modular construction, and integrates > relatively nicely with a bunch of enterprise systems. It is also > inherently embeddable, and has been incorporated as a component in a > few different commercial and open source products. > > The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable > backends, pluggable editors, an expressive markup, a plugin > framework, a filter framework, and built-in URL rewriting. > > JSPWiki also has a nice unit test set of over 700 unit tests which > have been invaluable in keeping compatibility between releases. > Background > > In the past few years, wikis have become a common collaborative tool. > They are light-weight, open, and easy to deploy. The English > Wikipedia, currently the largest public wiki site, contains nearly > two million pages. > > Wikis were originally designed to be small group collaboration tools, > but they have proven to be scalable to a large number of users, as > evidenced by the Wikipedia example. However, their most common use is > still within companies and other entities which deploy them as > collaboration tools, augmenting and even replacing traditional CSCW > tools. > > JSPWiki was originally created to address the same group > collaboration tool needs as so many other wiki engines. Its goals > were from the start to provide extensibility and user power, while > keeping the core functionality clear. Since it's inception in 2001, > it has grown to be one of the more popular open source wikiengines, > at least in the Java arena. It currently ships with the Sun Portal > Server 7, and features as an integral part of the Intland Codebeamer > development environment. > > Rationale > > JSPWiki has grown nicely over the past few years, and currently > averages around 2000 downloads monthly. The users-list has at the > writing of this 207 members, and the developers mailing list has 34 > members. There are currently six people with commit access to the CVS > codebase. > > However, there is a chasm to how large an open source project can > grow under a "benevolent dictator" –model. Many corporations are > relying on the JSPWiki code base, and joining Apache would lessen the > risks involved in using it, thus giving more entities an opportunity > to use this advanced project. Joining Apache would make us less > dependent on individual developers and would strengthen our community. > > We also feel that the introduction of Apache processes would increase > the code quality, as well as bring more interested developers to this > project. > > Apache is also lacking a wiki engine. It is currently using either > commercial software (Confluence) or Python-based wiki software > (MoinMoin) as its own projects. As wikis are becoming the workhorse > of many projects, we feel that it would bring a good addition to the > Apache community. > > Initial Goals > > The initial goals of the project is to release JSPWiki 2.8 under the > Apache license: > > * Bring in the JSPWiki 2.6 stable code base into Apache and > apply Apache licensing and remove incompatible dependencies (see > ApacheRelicensing for more discussion.) > * Release JSPWiki 2.8 as a clone of JSPWiki 2.6 - with some bug > fixes and Apache licensing, however keeping compatibility with > JSPWiki 2.6. This means that we cannot e.g. change the package naming > from "com.ecyrd.jspwiki" or else all old plugins will fail. It is yet > unclear whether this will be acceptable to ASF. > > After that, we will start working on JSPWiki 3.0: > > * Clean up our metadata and backend support by adding JSR-170 > repository support > * Adoption of a more flexible web framework (Stripes, an Apache- > licensed project) > * Multi-wiki support (so-called WikiFarms, or WikiWebs or > WikiSpaces) > * Move to "org.apache.jspwiki" -structure, breaking > compatibility with 2.x series > * Cleanup of the APIs and some refactoring which has been due > for a long time > > Current Status > > JSPWiki code base is relatively stable, and even thoug
Re: [PROPOSAL] JSPWiki
On 9/8/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > +1. The fact that Janne pointed to a web page listing all the potential > hazards, is a VERY GOOD sign that he has at least as good grip of the > situation as the average Java project at Apache. And definitely good enough > for me to start incubation. +1 too. The list is very comprehensive, and even notified myself of an old product that somehow changed license (jwebunit) for the worse. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On Saturday 08 September 2007 17:41, Henning Schmiedehausen wrote: > these concerns are very valid and good and Janne has demonstrated that > he is aware of this. > > However, most of the vetting required is actually *part* of the > incubation process and happens after acceptance into the incubator. So > can we just postpone that discussion a bit and assimilate them > first? ;-) +1. The fact that Janne pointed to a web page listing all the potential hazards, is a VERY GOOD sign that he has at least as good grip of the situation as the average Java project at Apache. And definitely good enough for me to start incubation. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Folks, these concerns are very valid and good and Janne has demonstrated that he is aware of this. However, most of the vetting required is actually *part* of the incubation process and happens after acceptance into the incubator. So can we just postpone that discussion a bit and assimilate them first? ;-) Best regards Henning On Thu, 2007-09-06 at 07:49 -0700, Martin Cooper wrote: > I'm concerned about all of the 3rd party dependencies that use quite a > variety of other licenses. The relicensing page says "Category B: Keep" for > many of these. I'm not clear on where the "Category B" part comes from, but > I don't believe that some of these can be kept. Some of the licenses, such > as CPL, have IP provisions in them that are most likely incompatible with > the Apache License 2.0, so I believe those components would have to go as > well. Am with most folks here, IANAL, but this is something that would have > to be looked at closely to make sure that JSPWiki can in fact end up under > an Apache License. > > -- > Martin Cooper > > > On 8/29/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > > > Hello all! > > > > I am Janne Jalkanen, the lead developer of the open source wiki > > engine called JSPWiki, and I have a proposal for your enjoyment. > > This proposal is available in the web at http://www.jspwiki.org/wiki/ > > ApacheJSPWikiProposal, should you wish to help us to make it better. > > > > /Janne > > > > - > > > > Abstract > > > > Apache JSPWiki will be a modular and user-extensible wiki-engine, > > based on the open source JSPWiki software. > > > > Proposal > > > > JSPWiki is a wiki engine available under the Lesser General Public > > License. It has a very modular construction, and integrates > > relatively nicely with a bunch of enterprise systems. It is also > > inherently embeddable, and has been incorporated as a component in a > > few different commercial and open source products. > > > > The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable > > backends, pluggable editors, an expressive markup, a plugin > > framework, a filter framework, and built-in URL rewriting. > > > > JSPWiki also has a nice unit test set of over 700 unit tests which > > have been invaluable in keeping compatibility between releases. > > Background > > > > In the past few years, wikis have become a common collaborative tool. > > They are light-weight, open, and easy to deploy. The English > > Wikipedia, currently the largest public wiki site, contains nearly > > two million pages. > > > > Wikis were originally designed to be small group collaboration tools, > > but they have proven to be scalable to a large number of users, as > > evidenced by the Wikipedia example. However, their most common use is > > still within companies and other entities which deploy them as > > collaboration tools, augmenting and even replacing traditional CSCW > > tools. > > > > JSPWiki was originally created to address the same group > > collaboration tool needs as so many other wiki engines. Its goals > > were from the start to provide extensibility and user power, while > > keeping the core functionality clear. Since it's inception in 2001, > > it has grown to be one of the more popular open source wikiengines, > > at least in the Java arena. It currently ships with the Sun Portal > > Server 7, and features as an integral part of the Intland Codebeamer > > development environment. > > > > Rationale > > > > JSPWiki has grown nicely over the past few years, and currently > > averages around 2000 downloads monthly. The users-list has at the > > writing of this 207 members, and the developers mailing list has 34 > > members. There are currently six people with commit access to the CVS > > codebase. > > > > However, there is a chasm to how large an open source project can > > grow under a "benevolent dictator" –model. Many corporations are > > relying on the JSPWiki code base, and joining Apache would lessen the > > risks involved in using it, thus giving more entities an opportunity > > to use this advanced project. Joining Apache would make us less > > dependent on individual developers and would strengthen our community. > > > > We also feel that the introduction of Apache processes would increase > > the code quality, as well as bring more interested developers to this > > project. > > > > Apache is also lacking a wiki engine. It is cur
Re: [PROPOSAL] JSPWiki
Hi, On 9/6/07, Martin Cooper <[EMAIL PROTECTED]> wrote: > As a concrete example, look at Axis. At some point in its lifetime, WSDL4J > was added to the distribution, and that's licensed under the CPL. Someone > coming in and looking at Axis might reasonably assume that it's licensed > under the Apache License, and not be aware that there's another license > hiding in there. If that someone was a company (e.g. my employer) that > forbids the use of CPL-licensed software, that can have very serious > consequences, especially if the package was already in use before the > dependency was introduced. Exactly, see [1] for a real case where this dependency caused a problem. I personally don't see a problem in having CPL or other Class B dependencies, but it would be good to include prominent notices on projects that have them. Perhaps I'll follow up on legal-discuss on the details. In any case I'm with Garrett on not holding JSPWiki up to a standard that we don't properly document or even follow in all cases. [1] http://www.nabble.com/wsdl4j-license-inconsistency-tf3363493.html#a9373144 BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On Thursday, September 6, 2007, 6:18:42 PM, Janne <[EMAIL PROTECTED]> wrote: > On 6 Sep 2007, at 17:20, Gwyn Evans wrote: >> While agreeing that it's something that needs looking at closely, I'm >> not I'm not sure it's downbeat as I think you're suggesting. The >> 3rd-party licencing policy at http://www.apache.org/legal/3party.html >> redirects to the draft at http://people.apache.org/~rubys/3party.html, >> but that suggests that, especially for use in binary form, licences >> such as CDDL or CPL aren't necessarily incompatible... > That is exactly where the "category B" is coming from. Do we need to > wait until ASF gets the 3rd party license policy completed? I'd expect not, if for no other reason than we (Wicket) recently came out of incubation under that sort of policy, including using some libraries licensed under MIT, BSD and CDDL! > Please note that it would be *impossible* for us to work without some > of the category B libraries, such as the JUnit testing library. Well, IANAL, but it seems to me that JUnit specifically's not going to be a problem, as the focus is on things you deliver, as opposed to something that you just use during the build. > Also, things like JavaMail libraries are highly useful for our user > experience (e.g. sending email in case the user forgets his > password). If there is an Apache-compatible implementation > available, then fine. That's in the deliverables, but as long as you follow the draft, e.g. getting the NOTICE file correct, I can't see a problem. > There are some custom licenses out there where we would need help > from ASF's lawyers to check whether the licenses are really ok. > Having to reimplement e.g. a permissive HTML-parser or a caching > library would be a real PITA. Indeed. /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/6/07, Garrett Rooney <[EMAIL PROTECTED]> wrote: > > On 9/6/07, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 9/6/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > > > > > While agreeing that it's something that needs looking at closely, I'm > > > not I'm not sure it's downbeat as I think you're suggesting. The > > > 3rd-party licencing policy at http://www.apache.org/legal/3party.html > > > redirects to the draft at http://people.apache.org/~rubys/3party.html, > > > but that suggests that, especially for use in binary form, licences > > > such as CDDL or CPL aren't necessarily incompatible... > > > > > > Right. However, as you noted, that's a draft, so it may change. I hope > it > > does. > > So you're expecting JSPWIki to be held to a standard that doesn't > exist even in the draft documentation that we have for such things? Expecting? No. Hoping for? Yes. That seems rather extreme. I'd suggest that such discussion belongs > on the legal discuss mailing list, as opposed to on the incubator > list. It does. However, I brought it up here because I see a long list of non-AL dependencies for JSPWiki and that concerns me. I think it's fair enough to express those concerns here, no? The fact that it's part of a greater concern that I have for the integrity of the ASF seemed relevant to me, even if detailed discussion of that belongs elsewhere. -- Martin Cooper -garrett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] JSPWiki
Is there a roadmap for when JSPWiki will have all of the features and functionality of both Confluence and MoinMoin, including the Confluence macros we use, and the migration tools so that we can move all the existing data from these existing wikis to JSPWiki? Without that, I don't see us replacing our existing wikis with JSPWiki, and I'm absolutely not in favour of adding a third wiki flavour to our infrastructure. Is this the real reason JSPWiki wants to come to the ASF? To be the wiki that the ASF runs on? Well, frankly, I don't really care what other projects are running :-). It's up to each project to choose the kind of infrastructure they choose. And I certainly see the point of not complicating the infrastructure. But, over time, migration tools will certainly emerge. We have so far not really been working on such things, as it hasn't really been a priority. Whether then the decision is made by ASF to adopt JSPWiki as an official tool is pretty much out of my hands. I would certainly like to see it happen, and can offer help, but I'm not exactly holding my breath. It's certainly not a driving factor in this whole transition. The way I see it, it's a decision that ASF will do based on ASF's own needs :-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 6 Sep 2007, at 17:20, Gwyn Evans wrote: While agreeing that it's something that needs looking at closely, I'm not I'm not sure it's downbeat as I think you're suggesting. The 3rd-party licencing policy at http://www.apache.org/legal/3party.html redirects to the draft at http://people.apache.org/~rubys/3party.html, but that suggests that, especially for use in binary form, licences such as CDDL or CPL aren't necessarily incompatible... That is exactly where the "category B" is coming from. Do we need to wait until ASF gets the 3rd party license policy completed? Please note that it would be *impossible* for us to work without some of the category B libraries, such as the JUnit testing library. Also, things like JavaMail libraries are highly useful for our user experience (e.g. sending email in case the user forgets his password). If there is an Apache-compatible implementation available, then fine. There are some custom licenses out there where we would need help from ASF's lawyers to check whether the licenses are really ok. Having to reimplement e.g. a permissive HTML-parser or a caching library would be a real PITA. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/6/07, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 9/6/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > > > While agreeing that it's something that needs looking at closely, I'm > > not I'm not sure it's downbeat as I think you're suggesting. The > > 3rd-party licencing policy at http://www.apache.org/legal/3party.html > > redirects to the draft at http://people.apache.org/~rubys/3party.html, > > but that suggests that, especially for use in binary form, licences > > such as CDDL or CPL aren't necessarily incompatible... > > > Right. However, as you noted, that's a draft, so it may change. I hope it > does. > > My concern is that as soon as we bundle components with other licenses > into > distributions of ASF projects, we compromise the integrity of the ASF > itself > in the eyes of the outside world. For one thing, not all consumers of > those > projects see the different licenses in the same light. For another, many > many consumers of ASF projects assume that something coming out of the ASF > will be licensed under the Apache License *only*. There's best practices and there's policy. The predominant use of ASL license should definitely be best practice (and I believe it's properly emphasized in the "guiding Principles" of this document) but not policy, be it just for pragmatic reasons. Besides removing BSD or MIT dependencies just because they're not ASL doesn't make much sense. But as far as JSPWiki is concerned, my understanding of the incubator is that it's precisely meant as a transitional environment where projects can solve these issues. As a concrete example, look at Axis. At some point in its lifetime, WSDL4J > was added to the distribution, and that's licensed under the CPL. Someone > coming in and looking at Axis might reasonably assume that it's licensed > under the Apache License, and not be aware that there's another license > hiding in there. If that someone was a company (e.g. my employer) that > forbids the use of CPL-licensed software, that can have very serious > consequences, especially if the package was already in use before the > dependency was introduced. > > -- > Martin Cooper > > > /Gwyn > > > > On Thursday, September 6, 2007, 3:49:09 PM, Martin <[EMAIL PROTECTED]> > > wrote: > > > > > I'm concerned about all of the 3rd party dependencies that use quite a > > > variety of other licenses. The relicensing page says "Category B: > Keep" > > for > > > many of these. I'm not clear on where the "Category B" part comes > from, > > but > > > I don't believe that some of these can be kept. Some of the licenses, > > such > > > as CPL, have IP provisions in them that are most likely incompatible > > with > > > the Apache License 2.0, so I believe those components would have to go > > as > > > well. Am with most folks here, IANAL, but this is something that would > > have > > > to be looked at closely to make sure that JSPWiki can in fact end up > > under > > > an Apache License. > > > > > -- > > > Martin Cooper > > > > > > > On 8/29/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > >> > > >> Hello all! > > >> > > >> I am Janne Jalkanen, the lead developer of the open source wiki > > >> engine called JSPWiki, and I have a proposal for your enjoyment. > > >> This proposal is available in the web at http://www.jspwiki.org/wiki/ > > >> ApacheJSPWikiProposal, should you wish to help us to make it better. > > >> > > >> /Janne > > >> > > >> - > > >> > > >> Abstract > > >> > > >> Apache JSPWiki will be a modular and user-extensible wiki-engine, > > >> based on the open source JSPWiki software. > > >> > > >> Proposal > > >> > > >> JSPWiki is a wiki engine available under the Lesser General Public > > >> License. It has a very modular construction, and integrates > > >> relatively nicely with a bunch of enterprise systems. It is also > > >> inherently embeddable, and has been incorporated as a component in a > > >> few different commercial and open source products. > > >> > > >> The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable > > >> backends, pluggable editors, an expressive markup, a plugin > > >> framework, a filter framework, and built-in URL rewriting. &g
Re: [PROPOSAL] JSPWiki
On 9/6/07, Martin Cooper <[EMAIL PROTECTED]> wrote: > On 9/6/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > > > While agreeing that it's something that needs looking at closely, I'm > > not I'm not sure it's downbeat as I think you're suggesting. The > > 3rd-party licencing policy at http://www.apache.org/legal/3party.html > > redirects to the draft at http://people.apache.org/~rubys/3party.html, > > but that suggests that, especially for use in binary form, licences > > such as CDDL or CPL aren't necessarily incompatible... > > > Right. However, as you noted, that's a draft, so it may change. I hope it > does. So you're expecting JSPWIki to be held to a standard that doesn't exist even in the draft documentation that we have for such things? That seems rather extreme. I'd suggest that such discussion belongs on the legal discuss mailing list, as opposed to on the incubator list. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/6/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > While agreeing that it's something that needs looking at closely, I'm > not I'm not sure it's downbeat as I think you're suggesting. The > 3rd-party licencing policy at http://www.apache.org/legal/3party.html > redirects to the draft at http://people.apache.org/~rubys/3party.html, > but that suggests that, especially for use in binary form, licences > such as CDDL or CPL aren't necessarily incompatible... Right. However, as you noted, that's a draft, so it may change. I hope it does. My concern is that as soon as we bundle components with other licenses into distributions of ASF projects, we compromise the integrity of the ASF itself in the eyes of the outside world. For one thing, not all consumers of those projects see the different licenses in the same light. For another, many many consumers of ASF projects assume that something coming out of the ASF will be licensed under the Apache License *only*. As a concrete example, look at Axis. At some point in its lifetime, WSDL4J was added to the distribution, and that's licensed under the CPL. Someone coming in and looking at Axis might reasonably assume that it's licensed under the Apache License, and not be aware that there's another license hiding in there. If that someone was a company (e.g. my employer) that forbids the use of CPL-licensed software, that can have very serious consequences, especially if the package was already in use before the dependency was introduced. -- Martin Cooper /Gwyn > > On Thursday, September 6, 2007, 3:49:09 PM, Martin <[EMAIL PROTECTED]> > wrote: > > > I'm concerned about all of the 3rd party dependencies that use quite a > > variety of other licenses. The relicensing page says "Category B: Keep" > for > > many of these. I'm not clear on where the "Category B" part comes from, > but > > I don't believe that some of these can be kept. Some of the licenses, > such > > as CPL, have IP provisions in them that are most likely incompatible > with > > the Apache License 2.0, so I believe those components would have to go > as > > well. Am with most folks here, IANAL, but this is something that would > have > > to be looked at closely to make sure that JSPWiki can in fact end up > under > > an Apache License. > > > -- > > Martin Cooper > > > > On 8/29/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > >> > >> Hello all! > >> > >> I am Janne Jalkanen, the lead developer of the open source wiki > >> engine called JSPWiki, and I have a proposal for your enjoyment. > >> This proposal is available in the web at http://www.jspwiki.org/wiki/ > >> ApacheJSPWikiProposal, should you wish to help us to make it better. > >> > >> /Janne > >> > >> - > >> > >> Abstract > >> > >> Apache JSPWiki will be a modular and user-extensible wiki-engine, > >> based on the open source JSPWiki software. > >> > >> Proposal > >> > >> JSPWiki is a wiki engine available under the Lesser General Public > >> License. It has a very modular construction, and integrates > >> relatively nicely with a bunch of enterprise systems. It is also > >> inherently embeddable, and has been incorporated as a component in a > >> few different commercial and open source products. > >> > >> The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable > >> backends, pluggable editors, an expressive markup, a plugin > >> framework, a filter framework, and built-in URL rewriting. > >> > >> JSPWiki also has a nice unit test set of over 700 unit tests which > >> have been invaluable in keeping compatibility between releases. > >> Background > >> > >> In the past few years, wikis have become a common collaborative tool. > >> They are light-weight, open, and easy to deploy. The English > >> Wikipedia, currently the largest public wiki site, contains nearly > >> two million pages. > >> > >> Wikis were originally designed to be small group collaboration tools, > >> but they have proven to be scalable to a large number of users, as > >> evidenced by the Wikipedia example. However, their most common use is > >> still within companies and other entities which deploy them as > >> collaboration tools, augmenting and even replacing traditional CSCW > >> tools. > >> > >> JSPWiki was originally created to address the same group > >> collaboration tool needs as so many other wiki en
Re: [PROPOSAL] JSPWiki
Well, let me put it this way: it would be kinda dumb to run our public wiki site on another wiki engine. ;-) Dumb? So we must already be dumb, then, to be running other things like JVMs that don't come from the ASF, rather than our own. Nonono, what I meant was that it would be odd to have www.jspwiki.org running on Confluence or Moin Moin - it would look like we are not eating our own dog food. It's not at all clear from that list that those are wikis and not just regular web sites. Does JSPWiki have an auto-export capability, like Confluence does, so that pages can be offloaded to static resources, instead of hitting the wiki all the time? All of the resources listed are wikis (except, obviously, the mailing list. Even the blog is a wiki, though it is not open to the general public to edit). There is an external tool which allows a full or subset of files to be turned into static HTML resources, if necessary, but we do not currently provide one ourselves. You'll need a dedicated team of people, not just one person, that is committed to doing this on an ongoing basis. Very true. Being a "hobby project" has allowed us to be somewhat lenient towards things like web site availability (though having said that, we have two maintainers in two timezones, and in general our downtimes happen only when we upgrade something). This is one of the questions highlighted in our proposal, and help from the ASF is needed towards resolving these - I can't tell you how to run your services :-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
While agreeing that it's something that needs looking at closely, I'm not I'm not sure it's downbeat as I think you're suggesting. The 3rd-party licencing policy at http://www.apache.org/legal/3party.html redirects to the draft at http://people.apache.org/~rubys/3party.html, but that suggests that, especially for use in binary form, licences such as CDDL or CPL aren't necessarily incompatible... /Gwyn On Thursday, September 6, 2007, 3:49:09 PM, Martin <[EMAIL PROTECTED]> wrote: > I'm concerned about all of the 3rd party dependencies that use quite a > variety of other licenses. The relicensing page says "Category B: Keep" for > many of these. I'm not clear on where the "Category B" part comes from, but > I don't believe that some of these can be kept. Some of the licenses, such > as CPL, have IP provisions in them that are most likely incompatible with > the Apache License 2.0, so I believe those components would have to go as > well. Am with most folks here, IANAL, but this is something that would have > to be looked at closely to make sure that JSPWiki can in fact end up under > an Apache License. > -- > Martin Cooper > On 8/29/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: >> >> Hello all! >> >> I am Janne Jalkanen, the lead developer of the open source wiki >> engine called JSPWiki, and I have a proposal for your enjoyment. >> This proposal is available in the web at http://www.jspwiki.org/wiki/ >> ApacheJSPWikiProposal, should you wish to help us to make it better. >> >> /Janne >> >> - >> >> Abstract >> >> Apache JSPWiki will be a modular and user-extensible wiki-engine, >> based on the open source JSPWiki software. >> >> Proposal >> >> JSPWiki is a wiki engine available under the Lesser General Public >> License. It has a very modular construction, and integrates >> relatively nicely with a bunch of enterprise systems. It is also >> inherently embeddable, and has been incorporated as a component in a >> few different commercial and open source products. >> >> The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable >> backends, pluggable editors, an expressive markup, a plugin >> framework, a filter framework, and built-in URL rewriting. >> >> JSPWiki also has a nice unit test set of over 700 unit tests which >> have been invaluable in keeping compatibility between releases. >> Background >> >> In the past few years, wikis have become a common collaborative tool. >> They are light-weight, open, and easy to deploy. The English >> Wikipedia, currently the largest public wiki site, contains nearly >> two million pages. >> >> Wikis were originally designed to be small group collaboration tools, >> but they have proven to be scalable to a large number of users, as >> evidenced by the Wikipedia example. However, their most common use is >> still within companies and other entities which deploy them as >> collaboration tools, augmenting and even replacing traditional CSCW >> tools. >> >> JSPWiki was originally created to address the same group >> collaboration tool needs as so many other wiki engines. Its goals >> were from the start to provide extensibility and user power, while >> keeping the core functionality clear. Since it's inception in 2001, >> it has grown to be one of the more popular open source wikiengines, >> at least in the Java arena. It currently ships with the Sun Portal >> Server 7, and features as an integral part of the Intland Codebeamer >> development environment. >> >> Rationale >> >> JSPWiki has grown nicely over the past few years, and currently >> averages around 2000 downloads monthly. The users-list has at the >> writing of this 207 members, and the developers mailing list has 34 >> members. There are currently six people with commit access to the CVS >> codebase. >> >> However, there is a chasm to how large an open source project can >> grow under a "benevolent dictator" –model. Many corporations are >> relying on the JSPWiki code base, and joining Apache would lessen the >> risks involved in using it, thus giving more entities an opportunity >> to use this advanced project. Joining Apache would make us less >> dependent on individual developers and would strengthen our community. >> >> We also feel that the introduction of Apache processes would increase >> the code quality, as well as bring more interested developers to this >> project. >> >> Apache is also lacking a wiki engine. It is currently
Re: [PROPOSAL] JSPWiki
I'm concerned about all of the 3rd party dependencies that use quite a variety of other licenses. The relicensing page says "Category B: Keep" for many of these. I'm not clear on where the "Category B" part comes from, but I don't believe that some of these can be kept. Some of the licenses, such as CPL, have IP provisions in them that are most likely incompatible with the Apache License 2.0, so I believe those components would have to go as well. Am with most folks here, IANAL, but this is something that would have to be looked at closely to make sure that JSPWiki can in fact end up under an Apache License. -- Martin Cooper On 8/29/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > Hello all! > > I am Janne Jalkanen, the lead developer of the open source wiki > engine called JSPWiki, and I have a proposal for your enjoyment. > This proposal is available in the web at http://www.jspwiki.org/wiki/ > ApacheJSPWikiProposal, should you wish to help us to make it better. > > /Janne > > - > > Abstract > > Apache JSPWiki will be a modular and user-extensible wiki-engine, > based on the open source JSPWiki software. > > Proposal > > JSPWiki is a wiki engine available under the Lesser General Public > License. It has a very modular construction, and integrates > relatively nicely with a bunch of enterprise systems. It is also > inherently embeddable, and has been incorporated as a component in a > few different commercial and open source products. > > The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable > backends, pluggable editors, an expressive markup, a plugin > framework, a filter framework, and built-in URL rewriting. > > JSPWiki also has a nice unit test set of over 700 unit tests which > have been invaluable in keeping compatibility between releases. > Background > > In the past few years, wikis have become a common collaborative tool. > They are light-weight, open, and easy to deploy. The English > Wikipedia, currently the largest public wiki site, contains nearly > two million pages. > > Wikis were originally designed to be small group collaboration tools, > but they have proven to be scalable to a large number of users, as > evidenced by the Wikipedia example. However, their most common use is > still within companies and other entities which deploy them as > collaboration tools, augmenting and even replacing traditional CSCW > tools. > > JSPWiki was originally created to address the same group > collaboration tool needs as so many other wiki engines. Its goals > were from the start to provide extensibility and user power, while > keeping the core functionality clear. Since it's inception in 2001, > it has grown to be one of the more popular open source wikiengines, > at least in the Java arena. It currently ships with the Sun Portal > Server 7, and features as an integral part of the Intland Codebeamer > development environment. > > Rationale > > JSPWiki has grown nicely over the past few years, and currently > averages around 2000 downloads monthly. The users-list has at the > writing of this 207 members, and the developers mailing list has 34 > members. There are currently six people with commit access to the CVS > codebase. > > However, there is a chasm to how large an open source project can > grow under a "benevolent dictator" –model. Many corporations are > relying on the JSPWiki code base, and joining Apache would lessen the > risks involved in using it, thus giving more entities an opportunity > to use this advanced project. Joining Apache would make us less > dependent on individual developers and would strengthen our community. > > We also feel that the introduction of Apache processes would increase > the code quality, as well as bring more interested developers to this > project. > > Apache is also lacking a wiki engine. It is currently using either > commercial software (Confluence) or Python-based wiki software > (MoinMoin) as its own projects. As wikis are becoming the workhorse > of many projects, we feel that it would bring a good addition to the > Apache community. > > Initial Goals > > The initial goals of the project is to release JSPWiki 2.8 under the > Apache license: > > * Bring in the JSPWiki 2.6 stable code base into Apache and > apply Apache licensing and remove incompatible dependencies (see > ApacheRelicensing for more discussion.) > * Release JSPWiki 2.8 as a clone of JSPWiki 2.6 - with some bug > fixes and Apache licensing, however keeping compatibility with > JSPWiki 2.6. This means that we cannot e.g. change the package naming > from "com.ecyrd.jspwiki" or else all old plugins will fail. It is yet > uncle
Re: [PROPOSAL] JSPWiki
On 9/6/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > > What do you mean? Apache does not have needed lower level projects to > > run JSPWiki? > > How about Tomcat+Harmony? > > Well, let me put it this way: it would be kinda dumb to run our > public wiki site on another wiki engine. ;-) Dumb? So we must already be dumb, then, to be running other things like JVMs that don't come from the ASF, rather than our own. Is there a roadmap for when JSPWiki will have all of the features and functionality of both Confluence and MoinMoin, including the Confluence macros we use, and the migration tools so that we can move all the existing data from these existing wikis to JSPWiki? Without that, I don't see us replacing our existing wikis with JSPWiki, and I'm absolutely not in favour of adding a third wiki flavour to our infrastructure. Is this the real reason JSPWiki wants to come to the ASF? To be the wiki that the ASF runs on? We also have separate documentation and sandbox wikis. > > http://www.jspwiki.org/wiki/ApacheJSPWikiProposal#section- > ApacheJSPWikiProposal-RequiredResources It's not at all clear from that list that those are wikis and not just regular web sites. Does JSPWiki have an auto-export capability, like Confluence does, so that pages can be offloaded to static resources, instead of hitting the wiki all the time? A tomcat instance is fine (preferably non-shared; JSPWiki cannot be > deployed simply from a war file right now), and I can offer to run > some of the wiki sites (e.g. the sandbox, which is wiped out > regularly) myself. You'll need a dedicated team of people, not just one person, that is committed to doing this on an ongoing basis. -- Martin Cooper /Janne > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] JSPWiki
On Thursday 06 September 2007 17:56, Janne Jalkanen wrote: > We are tracking the progress here: > > http://www.jspwiki.org/wiki/ApacheRelicensing I think this is excellent and shows that you are on top of things. +1 to bring JSPWiki to incubation at ASF. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On Sep 6, 2007, at 11:52 AM, Bertrand Delacretaz wrote: On 9/6/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: ...So, any advice on this matter?... In my (totally non-lawyer) opinion, the cleanest way to change the JSPWiki code to the Apache License might be for the project to release an Apache License version of their code, before coming to the Incubator, using their existing release channels. This would mean that the existing community has agreed on this, with the release being a very public notice of the agreement. -Bertrand IMO this would not mean much and the code would still require IP clearance in the Incubator. E.g. the Cayenne project was under Apache license, and we still had to contact all contributors and collect all the CLA's. So no simplification of the procedure at all. Cheers, Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Yep, I got your point. I've personally thought about possibility for users to run JSPWiki on full Apache stack. This could be nice out-of-the-box bundle: JSPWiki+Tomcat+Harmony SY, Alexey 2007/9/6, Janne Jalkanen <[EMAIL PROTECTED]>: > > What do you mean? Apache does not have needed lower level projects to > > run JSPWiki? > > How about Tomcat+Harmony? > > Well, let me put it this way: it would be kinda dumb to run our > public wiki site on another wiki engine. ;-) > > We also have separate documentation and sandbox wikis. > > http://www.jspwiki.org/wiki/ApacheJSPWikiProposal#section- > ApacheJSPWikiProposal-RequiredResources > > A tomcat instance is fine (preferably non-shared; JSPWiki cannot be > deployed simply from a war file right now), and I can offer to run > some of the wiki sites (e.g. the sandbox, which is wiped out > regularly) myself. > > /Janne > > - > 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: [PROPOSAL] JSPWiki
In my (totally non-lawyer) opinion, the cleanest way to change the JSPWiki code to the Apache License might be for the project to release an Apache License version of their code, before coming to the Incubator, using their existing release channels. This would mean that the existing community has agreed on this, with the release being a very public notice of the agreement. There's just one catch: if we do the license change first, and then Apache says "nah, we're not interested", we have done all the work for nothing. Also, moving the development (and the mailing lists) to Apache Incubator would also be a very public notice of the agreement. We would, of course, make big noise about this on our web site as well. All of our current contributors are aware of this already and have agreed to the license change. The people who are no longer a part of the community would not notice it on the Apache website, nor on the JSPWiki web site - they are no longer using the software anyway. And, as I said, we have already tracked down everyone (save one, and I know his boss personally ;-) and received permission to do this. I don't know whether all of them need to sign a CLA though... We are tracking the progress here: http://www.jspwiki.org/wiki/ApacheRelicensing /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
What do you mean? Apache does not have needed lower level projects to run JSPWiki? How about Tomcat+Harmony? Well, let me put it this way: it would be kinda dumb to run our public wiki site on another wiki engine. ;-) We also have separate documentation and sandbox wikis. http://www.jspwiki.org/wiki/ApacheJSPWikiProposal#section- ApacheJSPWikiProposal-RequiredResources A tomcat instance is fine (preferably non-shared; JSPWiki cannot be deployed simply from a war file right now), and I can offer to run some of the wiki sites (e.g. the sandbox, which is wiped out regularly) myself. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
2007/9/4, Dave <[EMAIL PROTECTED]>: > Big +1 on JSPWiki. I've been a fan for years of the software and the > community that drives it forward. There may be some issues with > getting the JSPWiki web application up and running on Apache > infrastructure, which will be necessary for this effort What do you mean? Apache does not have needed lower level projects to run JSPWiki? How about Tomcat+Harmony? Have not review JSPWiki requirements yet actually. SY, Alexey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/6/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > ...So, any advice on this matter?... In my (totally non-lawyer) opinion, the cleanest way to change the JSPWiki code to the Apache License might be for the project to release an Apache License version of their code, before coming to the Incubator, using their existing release channels. This would mean that the existing community has agreed on this, with the release being a very public notice of the agreement. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
IANAL, but I am pretty sure you are right. However, I think there is an issue on "how simple is simple?". It seems common to talk about 10 lines of code are not infringements, but then noone give any hint of an upper limit. I think it would be good if it could be documented somehow, to get a better view. Well, you can't really say for sure how many lines constitutes an original work. Sometimes even long strips of code could be deemed non-copyrightable, due to e.g. heavy use of cut-n-paste, or e.g. a straightforward implementation of a well-known algorithm. And sometimes, a short piece of code, being brilliant and non-obvious might be considered an original body of work. This is a thorny subject and the conventions change from country to country. Finland has a copyright board for issuing recommendations on a case-by-case on whether something is an original enough body of work or not. Most often they are actually not. In addition, since many, many patches have over the years been changed, it's very difficult to say whether the original body of work still exists and how much of it still exists. These would need to be resolved case-by-case. Here's the crappy thing: I know Apache wants to have existing communities. But you can't have an existing community without some existing work. And if Apache is very stingy on the requirements that every single small patch author needs to have a CLA on file, then it's going to be really difficult - in certain cases even impossible - to get these works into Apache :-(. So, any advice on this matter? /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On Thursday 06 September 2007 00:45, Janne Jalkanen wrote: > simple patches do not cross the > boundary of an original work, and therefore cannot be claimed to be > copyrighted. IANAL, but I am pretty sure you are right. However, I think there is an issue on "how simple is simple?". It seems common to talk about 10 lines of code are not infringements, but then noone give any hint of an upper limit. I think it would be good if it could be documented somehow, to get a better view. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
I believe Janne has already looked into this and has a good list of all former contributors. Janne, can you comment on the difficulty of this challenge? Already ahead of you. We have all but one tracked down and all have already agreed. The question is whether they need to sign CLAs or whether it is just enough that they verbally in an email agree to the license change. I have discounted people who have just sent simple patches, since in my admittedly non-legal opinion, simple patches do not cross the boundary of an original work, and therefore cannot be claimed to be copyrighted. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/5/07, Bill Stoddard <[EMAIL PROTECTED]> wrote: > > > JSPWiki is a wiki engine available under the Lesser General Public > > License. > > > The initial goals of the project is to release JSPWiki 2.8 under the > > Apache license: > Successfully executing the license change could prove to be a > challenge. All past contributors to the project will need to agree to > the license change. Contributions from those who do not agree to the > license change (either because they cannot be tracked down or they just > simply disagree with the license change) will need to be reverted and > reimplemented. I believe Janne has already looked into this and has a good list of all former contributors. Janne, can you comment on the difficulty of this challenge? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
JSPWiki is a wiki engine available under the Lesser General Public License. The initial goals of the project is to release JSPWiki 2.8 under the Apache license: Successfully executing the license change could prove to be a challenge. All past contributors to the project will need to agree to the license change. Contributions from those who do not agree to the license change (either because they cannot be tracked down or they just simply disagree with the license change) will need to be reverted and reimplemented. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
On 9/5/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Dave Johnson wrote: > > > Big +1 on JSPWiki. > > > There may be some issues with getting [JSPWiki] up and running on Apache > > infrastructure, which will be necessary for this effort, but I think > > we can overcome those. > > Volunteering? ;-) Yes! I'd like to sign up for the Incubator project and Infra to help out. - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] JSPWiki
Dave Johnson wrote: > Big +1 on JSPWiki. > There may be some issues with getting [JSPWiki] up and running on Apache > infrastructure, which will be necessary for this effort, but I think > we can overcome those. Volunteering? ;-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Big +1 on JSPWiki. I've been a fan for years of the software and the community that drives it forward. There may be some issues with getting the JSPWiki web application up and running on Apache infrastructure, which will be necessary for this effort, but I think we can overcome those. - Dave On 8/30/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > This is interesting. Have you seen, that we are currently voting on > > the > > Jackrabbit list to enter Sling into the incubator. You may find more > > information at [1]. > > Yes, actually I did. I think it is something we can consider > later. JSPWiki needs to do quite a lot of things internally than > just render content, so it is yet unclear how that could possibly be > applied and whether it would fit our needs. I mean - at the moment > we don't really need Sling for anything, because we already have > everything in place, and we don't have any pressing needs to change it. > > But I'm certainly keeping my eyes open on that one. :-) > > /Janne > > > > - > 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: [PROPOSAL] JSPWiki
This is interesting. Have you seen, that we are currently voting on the Jackrabbit list to enter Sling into the incubator. You may find more information at [1]. Yes, actually I did. I think it is something we can consider later. JSPWiki needs to do quite a lot of things internally than just render content, so it is yet unclear how that could possibly be applied and whether it would fit our needs. I mean - at the moment we don't really need Sling for anything, because we already have everything in place, and we don't have any pressing needs to change it. But I'm certainly keeping my eyes open on that one. :-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Hi, On 8/30/07, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > I am Janne Jalkanen, the lead developer of the open source wiki > engine called JSPWiki, and I have a proposal for your enjoyment. Nice! > In the future, we expect to integrate somewhat with Jackrabbit. Having worked on wiki stuff before and now on Jackrabbit, I'd be happy to contribute something, though at least in near future I don't have too many spare cycles. I guess I'll at least lurk on the mailing list. :-) BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
Hi Janne, Am Donnerstag, den 30.08.2007, 00:02 +0300 schrieb Janne Jalkanen: > Abstract > > Apache JSPWiki will be a modular and user-extensible wiki-engine, > based on the open source JSPWiki software. > ... > * Clean up our metadata and backend support by adding JSR-170 > repository support > * Adoption of a more flexible web framework (Stripes, an Apache- > licensed project) This is interesting. Have you seen, that we are currently voting on the Jackrabbit list to enter Sling into the incubator. You may find more information at [1]. I could imagine, that this would probably be very helpful for your project. Regards Felix [1] http://wiki.apache.org/jackrabbit/ApacheSling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] JSPWiki
Hello all! I am Janne Jalkanen, the lead developer of the open source wiki engine called JSPWiki, and I have a proposal for your enjoyment. This proposal is available in the web at http://www.jspwiki.org/wiki/ ApacheJSPWikiProposal, should you wish to help us to make it better. /Janne - Abstract Apache JSPWiki will be a modular and user-extensible wiki-engine, based on the open source JSPWiki software. Proposal JSPWiki is a wiki engine available under the Lesser General Public License. It has a very modular construction, and integrates relatively nicely with a bunch of enterprise systems. It is also inherently embeddable, and has been incorporated as a component in a few different commercial and open source products. The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable backends, pluggable editors, an expressive markup, a plugin framework, a filter framework, and built-in URL rewriting. JSPWiki also has a nice unit test set of over 700 unit tests which have been invaluable in keeping compatibility between releases. Background In the past few years, wikis have become a common collaborative tool. They are light-weight, open, and easy to deploy. The English Wikipedia, currently the largest public wiki site, contains nearly two million pages. Wikis were originally designed to be small group collaboration tools, but they have proven to be scalable to a large number of users, as evidenced by the Wikipedia example. However, their most common use is still within companies and other entities which deploy them as collaboration tools, augmenting and even replacing traditional CSCW tools. JSPWiki was originally created to address the same group collaboration tool needs as so many other wiki engines. Its goals were from the start to provide extensibility and user power, while keeping the core functionality clear. Since it’s inception in 2001, it has grown to be one of the more popular open source wikiengines, at least in the Java arena. It currently ships with the Sun Portal Server 7, and features as an integral part of the Intland Codebeamer development environment. Rationale JSPWiki has grown nicely over the past few years, and currently averages around 2000 downloads monthly. The users-list has at the writing of this 207 members, and the developers mailing list has 34 members. There are currently six people with commit access to the CVS codebase. However, there is a chasm to how large an open source project can grow under a ”benevolent dictator” –model. Many corporations are relying on the JSPWiki code base, and joining Apache would lessen the risks involved in using it, thus giving more entities an opportunity to use this advanced project. Joining Apache would make us less dependent on individual developers and would strengthen our community. We also feel that the introduction of Apache processes would increase the code quality, as well as bring more interested developers to this project. Apache is also lacking a wiki engine. It is currently using either commercial software (Confluence) or Python-based wiki software (MoinMoin) as its own projects. As wikis are becoming the workhorse of many projects, we feel that it would bring a good addition to the Apache community. Initial Goals The initial goals of the project is to release JSPWiki 2.8 under the Apache license: * Bring in the JSPWiki 2.6 stable code base into Apache and apply Apache licensing and remove incompatible dependencies (see ApacheRelicensing for more discussion.) * Release JSPWiki 2.8 as a clone of JSPWiki 2.6 - with some bug fixes and Apache licensing, however keeping compatibility with JSPWiki 2.6. This means that we cannot e.g. change the package naming from "com.ecyrd.jspwiki" or else all old plugins will fail. It is yet unclear whether this will be acceptable to ASF. After that, we will start working on JSPWiki 3.0: * Clean up our metadata and backend support by adding JSR-170 repository support * Adoption of a more flexible web framework (Stripes, an Apache- licensed project) * Multi-wiki support (so-called WikiFarms, or WikiWebs or WikiSpaces) * Move to "org.apache.jspwiki" -structure, breaking compatibility with 2.x series * Cleanup of the APIs and some refactoring which has been due for a long time Current Status JSPWiki code base is relatively stable, and even though some parts are certainly showing their age, the code is clearly laid out (we originally used the Avalon coding conventions, but since then it has been slightly modified), and is often thanked for its clarity. We use the Facade and Adapter patterns extensively across JSPWiki. The current development practice has mostly been a Linux-like "benevolent dictator" -model. There have been no major clashes on the mailing lists, and the community tends to b
