Hi Stian, Thank you for very nice elaborations. I really liked your honest views on where things are and where you want to be. As you might have experiences with Jena and other projects, apache is about community. It will take significant work to get pass the current tone of "us vs them" to “we". But you are on a great start.
Also, Taverna with a long history will have to be ready for the challenge to build on the positives and overcome the “manchester - do it for me” inertia (from a core community building perspective). If you need a mentor, count me in. I actively contribute to Apache Airavata, and will be happy to bring our experiences from a similar journey. Infact Ross queried on airavata lists few years ago about potential taverna move to airavata/apache(Ross mentioned it further in this thread), good to see finally its happening. Integrating plugin community into the apache project (once its voted in) seems to be a low hanging fruit to diversify. David questions are right on. Two things you may want to consider addressing before you call for a vote are: listing of non-apache compatible license in the proposal and having adequate rights to change the license to Apache V2. Not a blocker for the proposal and voting, but a blocker for importing the code will be to have on file the University signed CCLA/SGA to donate the code. Echoing Chris, A hearty welcome!! Suresh On Sep 25, 2014, at 12:34 PM, David Nalley <da...@gnsa.us> wrote: >> >>> * Do you have any third party dependencies in the Taverna core that have >>> incompatible licenses (like GPL)? >> >> Unfortunately we do have a few of those, yes - the fact that we have >> to move away from those was one of the things that we discussed a lot >> in the Taverna community. >> > > Can you make sure a comprehensive list of those currently incompatible > list of dependencies is included in your proposal. > >> >> Taverna 2 is licensed as LGPL 2.1, which meant we could use several >> LGPL libraries like Hibernate and RShell. Hibernate can be replaced by >> other JPA providers (with some code update to remove Hibernate >> specific calls), while the RShell support would have to be moved out >> to an separately installable plugin. >> > > Do you have adequate rights to change the license wholesale? > >> >> The Astronomy edition of Taverna includes a plugin called >> AstroTaverna, which is GPL3 due to its inclusion of the Topcat and >> STILTS dependencies. >> >> The AstroTaverna community was therefore a bit sceptical about moving >> to Apache - but we concluded that as they would keep maintaining >> AstroTaverna as standalone plugins and instead of having multiple >> downloads for different editions, with Taverna 3 move to a "Start >> screen" that installs plugins from possibly third-party sites (Eclipse >> style). >> >> http://smtp.iaa.es/pipermail/astrotaverna-users/20140529/thread.html >> >> >> Here luckily our plugin system (OSGi) will help us out - so those bits >> that truly depend on GPL or LGPL would have to be maintained outside >> Apache. What perhaps we need to prepare a bit clearer is exactly >> which plugins will be in the Apache transfer, and which would stay >> outside. >> >> > > This sounds like fragmenting your existing community before you really > even get started. I believe the ASF is a great place, but I am not > convinced it's the best place for everyone. > >> The Taverna Workbench installers currently include platform-specific >> binaries of OpenJDK 7, which is licensed under GPL 2 with classpath >> exception. It is likely that under Apache we could not distribute >> OpenJDK - but perhaps it would instead be allowed to distribute the >> normal JDK binaries? (For Taverna 2 we did not distribute the normal >> JDK as it can be seen as incompatible with GPL, which LGPL can be >> upgraded to). Do you know of any Apache projects that do this, like >> perhaps OpenOffice? >> >> An alternative is for the installer to download JDK on demand - but >> would that require the installer itself (currently Install4j) to be >> replaced? >> >> >>> * Would you like developer-contributed plugins to be covered within a future >>> "Apache Taverna" project? >> >> As we've seen, keeping plugin developers on the "outside" of the >> project has isolated them from the core development. We would >> therefore like to encourage any new plugin developers to eventually >> make their plugin a part of an Apache Taverna project - as we have >> done historically with successful plugins. Apache's use of CLAs is I >> must admit a bit of a hindrance to this as opposed to the Github >> Laissez-faire style - - it has kept myself away from Apache projects >> earlier when my suggested patch was deemed "significant" - yet the >> legal department of the University spent 8 months reviewing that patch >> and Apache's CLA before finally signing. >> >> Yet we consider Taverna to be such a mature project that we want IP >> and licensing to be done correctly - and as you see our earlier >> insistence on keeping CLAs for all Taverna 2 development means that we >> are now in a position to relicense Taverna and change ownership to a >> foundation like Apache. >> >> > > I see two paragraphs here that don't answer the question posed. Where > will plugin development happen in an ideal world? > > One followup question - what kind of build/CI resources does the > University of Manchester provide? What manner of resources do you > believe you'll need if the project moves to the ASF? > > --David > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
