On Sat, Jul 24, 2010 at 5:14 PM, Bernd Zeimetz <[email protected]> wrote: > On 07/24/2010 04:48 PM, Bernd Zeimetz wrote: >> Hi Pascal! >> >> On 07/24/2010 12:25 PM, Pascal de Bruijn wrote: >>> I think most licensing issues have been resolved upstream. >> >> I'll have a look :) > > So basically the only thing that makes my head ache is the embedded copy of > libraw: > - it is an embedded source copy, such things are always bad, especially when > it > comes to security issues. Also the license information for files like > ahd_interpolate_mod.c/ahd_partial_interpolate.c was lost as the libraw > project's > license information is not available.
Ok, I assumed the copyright issue was about the icc files, I'll ask the developers to look into the .c files. But, embedding LibRaw is quite important... Using a external copy entail too much practical issues: 1. When people report raw reading bugs about Darktable 0.6 (for example), we have no easy way to know which LibRaw version was linked against. 2. We sometimes have local patches to LibRaw, which can be quite important... In the past the very important Green Channel Equibrilation was locally patched (which took a few month's to go upstream to LibRaw (now in 0.10)), and now we have a Canon EOS 40D Rotation patch locally applied. Which is important as well, since the 40D is a _very_ popular camera, and we already have multiple 40D users. So linking against a system LibRaw copy, will in general frustrate development and troubleshooting. Please also note, others RAW converters like UFRaw also have their own dcraw copy embedded, they libified it themselves. So in all regards we are no worse or better than UFRaw in this respect. > - it comes with automatically generated files without any way to recreate them > (guess that is in the original libraw source, but you can't assume that > somebody > who receives the darktable source also receives the libraw source). I'm not sure I understand... I think we have a full copy of LibRaw in a source tree, so this shouldn't be a problem? > Uploading the source as it is now would clearly give a REJECT from the > ftp-masters. The best way for me would be to modify the autotools stuff in a > way > that it will only use the embdeeded copy of libraw if the folder is there, > otherwise use the version which is installed in the system. Then we could just > remove that folder and use libraw from Debian. Ensuring that libraw in Debian > is > uptodate is no problem at all. Again, I disagree that we should use a system libraw copy... I'd like to emphasize rejecting Darktable for this, and allowing UFRaw would be very silly at best. And with regards to keeping LibRaw up to date, this isn't per-se the issue, since Darktable may require a specific version of LibRaw, and other raw converter might require a different version, which means that one would need multiple system (packaged) copies of LibRaw. Please don't get me wrong, in general I do agree with the policy that keeping local copies of library is a very bad idea. I just think this policy applies poorly to LibRaw at this point. I think there are some changes planned regarding LibRaw for after 0.6, that would make using a system copy of libraw a bit more viable, so this can be rediscussed in the future. Regards, Pascal de Bruijn _______________________________________________ Pkg-phototools-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-phototools-devel
