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 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 be helpful, even if
> > sometimes a little slow in helping others.
> >
> > Meritocracy
> >
> > JSPWiki has always tried to grant commit access to people who have
> > proven themselves as willing and capable of contributing to the code
> > base, UI design, documentation, etc. We will certainly continue this
> > practice, as it has proven to be very useful. We hope that the Apache
> > process will make it even more practical.
> >
> > Community
> >
> > JSPWiki has existed since 2001, and during its life, the community
> > has been growing steadily. Currently there is some 200-odd members on
> > the jspwiki-users mailing list, and 34 members on the jspwiki-dev-
> > users mailing list.
> >
> > JSPWiki has also been a subject of some scientific papers, and is
> > used as a development platform.
> >
> > Core Developers
> >
> > The core developers consist of Janne Jalkanen (Finnish, the original
> > lead developer and still the person with the most commits), Andrew
> > Jaquith (USA, a security guru), Dirk Frederickx (Belgium, our user
> > experience specialist), Christoph Sauer (Germany, the maintainer of
> > the WikiWizard editor), and Juan Pablo Santos Rodríguez (Spain, the
> > i18n specialist).
> >
> > We are a diverse group, though concentrated mostly in the Western
> > countries.
> >
> > Alignment
> >
> > We use Tomcat as our main development platform, and we are already
> > using a large number of Apache components from Log4j and regexps to
> > Commons Lang.
> >
> > In the future, we are planning to turn our backend to use JSR-170,
> > which makes Apache Jackrabbit an obvious bit of the future, though
> > the migration from our current repository model is still unclear.
> >
> > Our coding rules are also based on Apache Avalon coding rules.
> >
> > Known Risks
> >
> > Changing a large code base from one license to another always entails
> > risks. There may be users who might object to moving from GNU to
> > Apache on idealistic grounds, but most of the users will probably
> > take a pragmatic approach.
> >
> > Another problem may be if we cannot locate suitable non-GPL options
> > for our components. This may mean long delays, as we may need to
> > develop alternatives ourselves.
> >
> > Also, the move is likely – at least initially – to divert resources
> > from development to bureucracy. This is likely to strain a nerve or
> > two. This can hopefully be mitigated by the Mentors by providing
> > clear guidance.
> >
> > To be fully blunt, I (Janne Jalkanen) also feel a bit queasy on
> > giving control of JSPWiki – my pet, which I have groomed for many
> > years – away to a foundation. However, this is something which is
> > better in long term for JSPWiki, and therefore it is worth the
> > sacrifices.
> >
> > JSPWiki 2.8 is designed to be a low-risk, low-hanging-fruit type of a
> > release, assuming that ASF is fine with the package not being in the
> > "org.apache" hierarchy. If not, we have no choice but to wait until
> > 3.0 since breaking the binary compatibility twice in a row would mean
> > problems for all developers.
> > Orphaned products
> >
> > Since JSPWiki has been lead using a "benevolent dictator" –model, the
> > largest knowledge of the code base rests on Janne Jalkanen. Janne has
> > no plans to leave JSPWiki development, but certainly there is a need
> > to get more people who have an intimate knowledge of the code base
> > (and the decisions thereof).
> >
> > Inexperience with Open Source
> >
> > JSPWiki was started as an open source project in June 2001, and has
> > remained an open source project since. Issue tracking and mailing
> > lists have been open to everyone from day one.
> >
> > Homogenous Developers
> >
> > The current list of committers includes people from five countries,
> > four timezones and two continents. Regular patches come in also from
> > other countries.
> >
> > Reliance on Salaried Developers
> >
> > There are currently no people on the committer list who get paid to
> > work on JSPWiki. However, we do get patches from a number of
> > companies with a vested interest in JSPWiki.
> >
> > JSPWiki is in no way reliant on salaried coders.
> >
> > Relationships with Other Apache Products
> >
> > JSPWiki uses quite a few different Apache projects already, and, of
> > course, runs on top of Tomcat (though it has been developed to be
> > pure J2EE only and in no way relies on any specific functionality).
> >
> > In the future, we expect to integrate somewhat with Jackrabbit.
> >
> > A Excessive Fascination with the Apache Brand
> >
> > JSPWiki could continue on its own, no worries. However, we do feel
> > that our customers and users would feel more comfortable if there was
> > a "name" attached to it – because it lessens the risk of JSPWiki just
> > going away some day.
> >
> > To be frank, we are more interested in the Apache processes and the
> > stability Apache would bring to the project than the actual name. We
> > also hope that Apache will adopt us as their wiki solution ;-)
> >
> > Documentation
> >
> > The chief JSPWiki resource is the http://www.jspwiki.org/ web site.
> > It is further amended by the JSPWiki documentation site (http://
> > doc.jspwiki.org/2.4) as well as the JSPWiki-users and JSPWiki-dev
> > mailing list archives at http://ecyrd.com/pipermail/jspwiki-users/
> > and http://ecyrd.com/pipermail/jspwiki-dev/.
> >
> > Initial Source
> >
> > There is an initial source base of approximately 70,000 lines of
> > code. (According to an estimate by the Ohloh code search engine, this
> > amounts to roughly 17 person years).
> >
> > Source and Intellectual Property Submission Plan
> >
> >      * jspwiki.org domain from Janne Jalkanen
> >      * JSPWiki source code from all contributors (CLAs need to be done)
> >
> > External Dependencies
> >
> > JSPWiki is relying already extensively on a number of Apache-licensed
> > libraries. However, we are also using some LGPL-based libraries,
> > which will either need to be replaced or rewritten. The current list
> > of dependencies and the migration plan is available here:
> >
> > http://www.jspwiki.org/wiki/ApacheRelicensing
> >
> > Cryptography
> >
> > JSPWiki uses only cryptography methods (hash codes) available in the
> > J2SE itself. There is one exception to this rule, however: we use a
> > slightly modified version of the Apache Tomcat's HexUtils for
> > converting byte arrays into hexadecimal digits.
> > (org.apache.catalina.util.HexUtils).
> >
> > Required Resources
> >
> > Mailing lists
> >
> > JSPWiki currently operates on two mailing lists - jspwiki-
> > [EMAIL PROTECTED], and [EMAIL PROTECTED] It would be good to
> > continue these both also under Apache Incubation, with the addition
> > of the mandatory jspwiki-private. A jspwiki-commits -list might also
> > be useful.
> >
> >      * jspwiki-users (contains the existing members of the jspwiki-
> > users)
> >      * jspwiki-dev (the members of the existing jspwiki-dev)
> >      * jspwiki-commits (new list for announcing commits to the svn
> > repository)
> >      * jspwiki-private (for the PPMC, with moderated subscriptions)
> >
> > Subversion Directory
> >
> > JSPWiki code base should be named "jspwiki", as in
> >
> > https://svn.apache.org/repos/asf/incubator/jspwiki
> >
> > Issue Tracking
> >
> > Current JSPWiki bug tracking is done at http://bugs.jspwiki.org/,
> > using Bugzilla 3.0. It would be good to be able to move the current
> > bug list to the Apache Bugzilla. The project name should be "JSPWiki".
> >
> > If the bug list cannot be moved, then we can continue to use the
> > JSPWiki bug tracker.
> > Other Resources
> >
> >      * www.jspwiki.org website
> >      * doc.jspwiki.org
> >      * blog.jspwiki.org
> >      * sandbox.jspwiki.org (wiped at noon GMT with a custom script).
> >      * bugs.jspwiki.org
> >
> > Some or all of these can be moved to Apache. However, deeper
> > discussions need to be made on which ones Apache is willing to host.
> >
> > Initial Committers
> >
> >      * Janne Jalkanen ([EMAIL PROTECTED])
> >      * Andrew Jaquith ([EMAIL PROTECTED])
> >      * Dirk Frederickx ([EMAIL PROTECTED])
> >      * Christoph Sauer ([EMAIL PROTECTED])
> >      * Juan Pablo Santos Rodríquez ([EMAIL PROTECTED])
> >      * Murray Altheim ([EMAIL PROTECTED])
> >
> > None of the initial committers have yet submitted a CLA.
> >
> > Affiliations
> >
> > Janne Jalkanen works as a Project Manager in Nokia, but his work has
> > nothing to do with JSPWiki.
> >
> > Andrew Jaquith is a senior analyst at Yankee Group, an ICT research
> > and consulting firm. He covers security for Yankee. Nokia, curiously,
> > is one of Yankee's customers, but apparently not the part that Janne
> > works for. :)
> >
> > Christoph Sauer is a researcher at the Heilbronn University, Germany.
> > He is a Project Manager at the Heilbronn Universities i3G Institute,
> > which offers business services for small and medium sized companies.
> >
> > Juan Pablo Santos works as a Software Engineer in Secuenzia, an IT
> > consulting firm in Madrid.
> >
> > Sponsors
> >
> > Champion
> >
> > Champion: Dave Johnson
> > Nominated Mentors
> >
> > People who have announced their willingness to be Mentors are
> >
> >      * Dave Johnson
> >      * Sam Ruby
> >      * Henning Schmiedehausen
> >
> > Sponsoring Entity
> >
> > Sponsoring entity should be the Incubator.
> > PPMC
> >
> > The PPMC shall consist of initial committers and the Mentors.
> > ---------------------------------------------------------------------
> > 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]

Reply via email to