http://ofbiz.116.s1.nabble.com/Disabling-the-Shark-component-tp173572p173575.html
flow. If it worked, of course it's better to have a workflow engine
>
> It really isn't correct to say that the license is incompatible,
> only that we can't distribute the jar files because of the license.
>
> If we decide on this, we should decide based on goals for the
> framework. Right now nothing outside of the shark component uses
> Shark, so disabling it would be fine, but if we want to use
> workflow in the future in OFBiz it isn't going to be based on the
> OFBiz workflow engine (unless someone has a few thousand hours I
> don't know about that they want to invest in this...).
>
> So, do I understand from this that the direction we want to go is
> to just not have a workflow engine in OFBiz?
>
> Personally, I'd rather see the OFBiz workflow component go before
> the Shark component, though it would certainly be nice if there was
> another alternative with a friendlier license. Or perhaps the Shark
> community would consider a change to the Apache license, or if they
> still like the copy-left style stuff for code changes, then perhaps
> the Mozilla license?
>
> -David
>
>
> On Oct 24, 2006, at 2:36 PM, Si Chen wrote:
>
>> I agree. How about we just move into that specialized/ SVN that
>> David has? Even if it worked, it still wouldn't make sense to
>> have it in the ASF SVN because the actual Shark is not license
>> compatible.
>>
>> On Oct 24, 2006, at 1:12 PM, Jacopo Cappellato wrote:
>>
>>> What about disabling the Shark component?
>>> It is a component that has never been completed, we have moved
>>> outside of OFBiz the Shark jars (for license issues) and its user
>>> interface is clearly not maintained updated with the rest of the
>>> project: the Shark component is the only component, together with
>>> the Content component :-( that still hosts JPublish pages.
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>
>> Best Regards,
>>
>> Si
>>
[hidden email]
>>
>>
>>