Hi Jeremy,
I'm afraid this doesn't make it very clear to me,
what parts are/ or will be released under a recognised Open Source
Licence. Does "preparing the code to become available to everybody"
mean this or not? Prehaps you can get this clarified?
Incidentally I don't buy the "we won't share because someone
might fork" argument.
cheers,
Alex
On Tue, 28 Jun 2005, Coles, J (Jeremy) wrote:
> Dear All
>
> I indicated earlier that I would post any reply I received from the core
> dCache developers on the issue of making the code open source. I am sure
> that this will generate more discussion but will hopefully also clarify
> their current more formal position is:
>
> "We are preparing the code to become available to everybody. And we are
> making good progress.
>
> i) srm , dcap , pnfs are already freely available.
> ii) the upcoming replacement for pnfs (chimera) will be available as
> soon as it will be rolled out.
> iii) the rest is available for sites which can prove that they
> contribute serious work to the dCache collaboration. (Already
> CERN,BNL,RAL and some individuals which add well defined features in a
> well defined timeframe) ...
>
> And we will proceed in this direction.
>
> But two consequences should be pretty clear to those people which are so
> much excited about not having access to the dCache code.
>
> i) there is no guarantee that we will include any patches people will
> provide in case the full dCache becomes available.
>
> ii) There will be no support from us for any non standard dcache
> software.
>
> This all might sound a little bit overcautious. And I hope
> it doesn't sound too harsh. At least it's not at all meant so."
>
>
> In the lead in to this more formal statement it was explained that the
> present caution is an attempt to mitigate against too much local
> customization which will split support efforts. This is why they are
> more than happy to share the code with those who can and will contribute
> to the full solution but have concern about locally added features which
> may break the codebase and then require significant support effort or
> divide development efforts.
>
> I hope this helps.
>
> Jeremy
>
|