On Nov 7, 2006, at 12:40 PM, robert burrell donkin wrote:

On 11/7/06, David E Jones <[EMAIL PROTECTED]> wrote:

On Nov 5, 2006, at 3:52 AM, robert burrell donkin wrote:

> On 11/2/06, David E Jones <[EMAIL PROTECTED]> wrote:

<snip>

I read through the stuff on the 3party.html page you referenced and I
think if this does become the case there is an easy way we can handle
it. While it may be a little inconvenient we can remove these files
and refer to them in locations publicly available via the internet.
This way we can refer to them, but not include them.

Would that solve the problem?

probably

IMHO it's worth considering creating clean room implementations in the
medium term (or lobbying for an open source compatible license)

> ofbiz.jar does not contain LICENSE and NOTICE in it's META-INF. so
> this jar cannot be distributed as a bare artifact. for example, this
> means that it cannot be distributed through the maven repository.
>
> do you intend to ban distribution by maven?

I'm not sure what this would/should look like, and honestly hadn't
considered the distribution of these jars through a Maven repository/
server. The ofbiz.jar isn't really of any use on its own and is just
an executable place holder that loads other stuff in OFBiz.

For distribution in Maven would every jar in OFBiz have to include
the NOTICE and LICENSE files? We could certainly do this by just
changing the ant scripts.

yes - every apache jar that is released by itself would need NOTICE
and LICENSE files

Thanks for the feedback. The OFBiz build files now all copy the NOTICE and LICENSE files into the META-INF directory for each jar. So, from now on all OFBiz jar files will include the NOTICE and LICENSE files to make their (re)distribution more flexible.

On a side note, is this getting in the way of the voting process for
this Test Snapshot release?

possibly

AFAIC the substantive issue is the xsd's without open source licenses
but IMHO this is a marginal case. the license is missing from the
LICENSE file.

apache has traditionally issued aggregate binary releases containing
redistributable binary components which are not open source but does
not include source under restrictive licenses. xsd's are a difficult
corner case. much better to create clean room implementations.

since this is an incubator release and there seems no substantial
legal risk i'm going to +1 but i trust that the mentors will see that
this issue is resolved before graduation.

In the case of all of these DTD/XSD files they are not frequently used in OFBiz and after a bit of research I was able to get all existing XML files pointing to files available over the internet instead of from/though OFBiz. I don't think this will become much of an issue in terms of inconvenience or making things inflexible, and in a way it is nice to have one less thing to keep track of in the resources we manage and host. So yes, these files are now removed from SVN and there are README files in place to describe where the files can be obtained, and the XML files that use them point to the public locations.

I've notice that no one else has really
voted on it yet.

that's not unusual. unfortunately, checking releases takes IPMC energy
which is in limited supply. i run RAT (which is quicker) but there's
still quite a deal of time talen by offering explanations.

From my own experience I totally understand and there is certainly no hurry on this. We'd all like to see this finished up of course and will be happy to do whatever we can to smooth out the process. I know that OFBiz is fairly large will require a good bit of time from anyone who reviews it.

I think this wraps up these new issues that Robert identified so that once this or another Test Snapshot is approved we won't have these delaying the OFBiz graduation.

-David



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to