>
>> * 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

Reply via email to