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 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] >> >> /Gwyn --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
