Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] initial CQ dependencies

We'll need to identify the source code for those DLLs. The ini file is probably just configuration, and is probably not interesting from an IP due diligence point of view. I assume that the generated installer is an EXE; there might be some other code buried in that that we'd need to review.

FWIW, the Apache due diligence process is not as in-depth as ours. As a general rule, stuff that's generated by Apache is relatively easy to do IP due diligence on because they keep good records of contribution.

Wayne

On 04/26/2013 10:47 PM, Jody Garnett wrote:

For "build only" dependencies, the PMC needs to have a transparent discussion. This is generally held on the PMC mailing list (since the IPZilla system is visible to committers only). Normally, this would be a list named "technology-pmc@xxxxxxxxxxxxxxxx"; it doesn't appear that this this has been created, so I'll ask Webmaster to make that happen.

In the meantime...

The Nullsoft Scriptable Installer System builder itself seems like a reasonable "build and test only" dependency, but what do you intend to do with the generated output? I assume that the intent is to distribute it from locationtech.org? In this case, while the builder itself may be exempt from the due diligence process, any code that ends up in the distributed bits (e.g. installer runtime) is subject to the full wrath of the process.
Yeah this is one of the reasons I used it to try out the CQ process. It is an amusing case as compilers (for example) produce binary output, but the individual sequences of x86 instructions are not subject to review.
I think that we can treat these separately. I recommend that we keep this CQ is for the builder technology, and open a second one for whatever runtime bits need to be distributed.
I am going to do a bit of research and see if we can figure out what is put into an NSIS installer, if they are just making win32 library calls then we should be good right?

Okay some details provided here - looks like NSIS works with plugins written C / C++ (or Delphi <-- it is that old!).  So we would either need to review all of the out of the box plugins, or determine which subset we actually use and submit those.

And we can "unzip" an installer to see what is actually shipped.
For our most recent uDig 1.4.0 release I will focus on just the binaries:

/NSIS Plugins Directory/InstallOptions.dll
/NSIS Plugins Directory/ioSpecial.ini
/NSIS Plugins Directory/StartMenu.dll
/WIndows Temporary Directory/NSIS Plugins Directory/AdvSplash.dll

So how would we submit that?

Update
It looks like there is fork with Unicode support that we could look into used by Firefox, Picasa, OpenOffice.org and so on. The fork looks to have a steady stream of updates. 

So if OpenOffice is using it the Apache crew must of checked out the background of this UNSIS fork.




_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon
          France 2013

Back to the top