incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: [PROPOSAL] JSPWiki
Date Thu, 06 Sep 2007 17:02:51 GMT
On 9/6/07, Gwyn Evans <gwyn.evans@gmail.com> 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 <martinc@apache.org>
> 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 <Janne.Jalkanen@ecyrd.com> 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-
> >> users@jspwiki.org, and jspwiki-dev@jspwiki.org. 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 (jalkanen@ecyrd.com)
> >>      * Andrew Jaquith (andrew@freshcookies.org)
> >>      * Dirk Frederickx (dirk.frederickx@gmail.com)
> >>      * Christoph Sauer (sauer@hs-heilbronn.de)
> >>      * Juan Pablo Santos Rodríquez (juanpablo.santos@gmail.com)
> >>      * Murray Altheim (murray07@altheim.com)
> >>
> >> 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: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
>
>
> /Gwyn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message