Build of MP4v2 library does not result in a binary under Mozilla Public License 1.1

[GoogleCodeExporter]

The project home page for the MP4v2 library indicates that the software is 
licensed under Mozilla Public License 1.1. However, a build of the MP4v2 
library results in a binary that is under additional licenses as a result of 
including the following files:

libutil/crc.cpp:  Modified (3-clause) BSD license
libplatform/prog/option.cpp:  Todd C. Miller license and Original (4-clause) 
BSD license

Having the MP4v2 library contain code under four different licenses adds 
unnecessary complication when including the library in another product. To 
distribute a binary of the MP4v2 library, I should just have to indicate that 
the library is under MPL, include a copy of the license, and where to find the 
exact source to the MP4v2 binary I am distributing. Instead, I have to indicate 
that the MP4v2 library is under four different licenses (which is not 
documented in an obvious way) and adhere to the additional conditions of those 
licenses.

A quick solution is to not include those files when building the MP4v2 library. 
This is not difficult since both of the files are used for the command-line 
utilities, which are an optional part of the build process. Adding the 
--disable-util  option when running configure leaves out the libutil/crc.cpp 
file.The libplatform/prog/option.cpp file can also be left out if the attached 
patch is applied to Gmakefile.am before running autoreconf.

Although including all the libplatform symbols is convenient, it may be a good 
idea to separate out those which are only used for the command-line utilities. 
Another idea is to detect if the system has a usable getopt_long and not use 
the included option.cpp if that is the case. A better solution may be to 
replace the files with alternatives that are licensed under MPL 1.1.

Original issue reported on code.google.com by wells.br...@gmail.com on 3 Feb 2011 at 1:58

Attachments:

• skip_option_cpp.diff

[GoogleCodeExporter]

I think there are 2 subjects here.

1) maintenance of crc.cpp and option.cpp.

- (crc.cpp + UCB/3-clause) looks up-to-date and accurate to me
- option.cpp derives from (getopt_long + NetBSD/4-clause) and (getopt_long + 
Todd.C.Miller). The NetBSD source can be trivially changed to NetBSD/2-clause). 
another course of action would be to drop Todd's changes (ie: branch from 
NetBSD/2-clause). it's probably a plus for something like getopt_long to behave 
100% consistent on all platforms so the idea of using OS's getopt_long if 
available has negative QA consequences.

2) the above does nothing to factor copyright boundaries in the build process. 
but I must say that by importanting BSD licensed software, this project has 
stayed true to its goals and has not been compromised. googlecode (at the time) 
did not permit multiple licenses in their hosted project definition, so maybe 
that's an issue. but from a project perspective, I really don't have any issue 
with people distributing binaries having to enumerate a handful of BSD and 
other licenses. as stated above, dropping down from (UCB,NetBSD,Todd.C.Miller) 
licenses to (UCB,NetBSD) would be a nice cleanup.

While technically it's doable, I really don't think separating out MPL vs. 
non-MPL licenses in the build is worth the complexity. That said, you're right, 
it would be nice if the project audited source code and provided an 
authoritative (but not liable!) list of which files were licensed differently 
from MPL.

disclaimer: i'm not driving this project anymore, but I occasionally respond to 
(my) bugs and subjects so bear in mind the above are just my opinions and not 
decisions for mp4v2.

Original comment by Kona8l...@gmail.com on 3 Feb 2011 at 6:31

[GoogleCodeExporter]

Not sure if this is feasible, but there are a number of CRC implementations in 
the public domain (example: http://csbruce.com/~csbruce/software/crc32.c - not 
saying we should use this implementation, just pointing out there's other 
options) that might be worth consideration?  

Seems sort of silly to have license smash over something as basic as CRC.

Original comment by jnor...@logitech.com on 8 Feb 2011 at 12:55

[GoogleCodeExporter]

I was looking for a crc replacement (there's numerous public domain 
implementations, so no need to go with something that has a license associated 
with it), but I'm finding I don't totally understand the code that's there.  It 
is purportedly the crc used in ISO/IEC 8802-3:1989, but from my understanding 
that standard uses crc16, not crc32.

Then I tested the code we currently use in crc32 with some standard strings 
(e.g. "123456789", and I'm really not getting the sort of results I'd expect, 
even for crc32.  Kona, you put that code in--do you remember any of the details?

Original comment by kid...@gmail.com on 27 Apr 2011 at 6:58

[GoogleCodeExporter]

Yeah looks like I did a function misnomer. Output is same as 'cksum' as found 
on MacOSX and *bsd distros. So it's not crc32, but rather a 32-bit posix 
checksum; according to source from Apple:

/*
 * Compute a POSIX 1003.2 checksum.
 */

This is near identical source code; just simplified to use a buffer instead of 
file descriptor.

--> http://www.opensource.apple.com/tarballs/file_cmds/file_cmds-202.2.tar.gz
--> cksum/crc.c

Original comment by Kona8l...@gmail.com on 28 Apr 2011 at 12:33