incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: What are the JIRA issues to fix before a release?
Date Fri, 04 Nov 2011 18:07:28 GMT
<orcmid comments="inline" />

-----Original Message-----
From: Andy Seaborne [] On Behalf Of Andy 
Sent: Friday, November 04, 2011 10:52
Subject: Re: What are the JIRA issues to fix before a release?

On 04/11/11 17:11, Dennis E. Hamilton wrote:
[ ... ]
> I gather that you have not done your first release as a podling.  I am 
> curious
> about one thing: Looking over the SVN that I have managed to check out, it
> does not appear that IP Clearance has been done.
> Is that correct or have I missed it?  (I assume there is no statement to be
> made about encryption and such, so it is just the IP clearance/cleanup that 
> is
> essential prior to your first incubating release?)

This is the module jena/Jena2/jena?

There is a magic script that rewrites the head and tail /** */ comments
(in JenaTop) to Apache form.

Of the code we might release first time, only jena itself has not been
converted - there is two outstanding things to chase down and I've not
run the conversion script on that module.  It reminds me at least there
is still something to check on.

The outstanding items are BSD-style and so not a block to release. I've
written twice to TopQuadrant about them now and am still awaiting any reply.

I don't know the status is the Eyeball module.  It's a separate
standalone tool.  We can release that separately.

So the bottom line on code cleaning is we can run the script anytime and
then finalize NOTICE and LICENSE files.

Is that what you meant?

  Yes, that sort of thing.  I saw the BSD licenses at the foot of some
  files and the retention of copyright notices, and the absence of workup
  of LICENSE and NOTICE[.txt].  This makes this look like a lot of 3rd
  party code, and any updates that have been made are now, of course,
  under those licenses still.

We have nothing special for encryption [*], the nearest we get is
standard Java library use of SHA*.  We should register on

  I don't think digest algorithms count. They are not considered encryption
     You should check that and satisfy yourselves.  Also, beside registering
  on /licenses/exports/ if you find it necessary, check to see if that also
  requires a letter to the gov.


[*] project - SPARQL will not require SHA224 so no need to add a Bouncy
Castle dependent jar.

>   - Dennis E. Hamilton
>     tools for document interoperability,<>
>  gsm: +1-206-779-9430  @orcmid

View raw message