Charles Wilson wrote:
On 8/31/2011 9:43 PM, Luke Kendall wrote:
I'm asking because I'm finding Cygwin packages that contain no license
information, at least in the compiled form (e.g. gawk, libiconv2).
None of the "dll" packages contain license files; they are supposed to
only contain the dll itself. Usually the license files wind up in the
"main" package, or a "-doc" package.
Thanks, I'll bear that in mind. Though gawk didn't have one. But I'll
have a bit more of a look around inside the tarballs, manually.
However I think your BEST bet would be to do the following...get
setup.ini from $favorite_mirror. Every record beginning with
'@ package'
will have one or more 'source:' entries -- except for some _obsolete
packages, but we don't care about those because they will just be empty
tarballs, so no source necessary. Multiple '@ package' will refer to
the same 'source:'
So, basically I think you're saying I should look inside the "source:"
instead of the "install:" (which is where I've *been* looking).
Because I have to use a mix of algorithm and *heuristics* to find the
license files, I'd prefer to try the heuristics on the "install:" tar
file, just because the search space (no. of files) is much smaller.
Thanks for the suggestion, though, it sounds sensible - I'll have a
manual look inside gawk's at least and see if that looks promising, and
if so I'll modify the script to look inside the "source:" as a fallback.
With some judicious coding (*), you should be able to flip that around,
and create a database that represents the information the other way:
<some source entry>-<VER-N>
@ package <1>-<VER-N>
@ package <2>-<VER-N>
@ package <3>-<VER-N>
<some source entry>-<VER-M> [same "package", different version]
@ package <1>-<VER-M>
@ package <2>-<VER-M>
@ package <3>-<VER-M>
<another source entry>-<VER-P>
@ package <4>-<VER-P>
@ package <5>-<VER-P>
I don't think I need to do that inversion - currently if I find the
source licenses in package 1, and it's also used for package 2, then the
script will automatically find the licenses for package 2.
I doubt the license would often change between versions of the same
package, but it HAS been known to happen.
Sure. At the moment, I'm only looking in the most recent version, too.
I think looking in the source is more likely to find it if there's no
license in the "install:" tarball. I can't imagine someone deliberately
stripping the license files out of a package. That'd be just weird.
Now, you can find the <package>s for which you can't identify the
license, and either (a) find another package in the same "family" --
e.g. derived from the same source -- for which you DO know the license.
WIN!
If *all* of the "child" packages of a given source have an unknown
license, well -- then you can get the -src package itself and troll
around in it, or check freshmeat. Usually the -src packages are named
pretty simply:
<upstream name>-<upstream ver>-<cygwin release>-src.tar.*
Watch out for this: some packages have different licenses for different
pieces. The "libiconv" group of packages specifies that the *libraries*
are LGPL, but the *app* is GPL. This means:
libcharset1: LGPL
libiconv2: LGPL
libiconv: GPL
Also, gettext group is similar; some of the libs and apps are GPL, and
some of the apps and libs are LGPL. Fortunately, they are segregated in
the cygwin packages:
libasprintf0: LGPL
libintl8: LGPL
libgettextpo0: GPL
gettext: LGPL
gettext-devel GPL
Tell me about it. "base-files" and "cygwin" are two good examples. :-)
Fortunately, that sort of structure is rare.
(*) Maybe borrow from genini, or upset?
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Thanks for all that!
Regards,
luke
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
