On May 1, 2010, at 6:13 AM, Alexander Hansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 5/1/10 7:07 AM, Hanspeter Niederstrasser wrote: >> libnessus3-ssl is marked as Restrictive (links to OpenSSL) and the >> source is now unavailable upstream (license change for newer versions >> and dead FTP server). fink fetch libnessus3-ssl then fails to build, >> only checking Source: defined in the .info file. >> >> However, the tarball _is_ available from >> <http://distfiles.master.finkmirrors.net/>, probably because of >> libnessus3 (non-ssl). This brings up some questions: >> >> 1) Should packages marked as Restrictive be able to check mirrors if >> they can't find the source upstream? >> > > If the sources are legally redistributable and therefore mirror-able, > that sounds reasonable.
There are definitely cases in which no permission to distribute source has been given. That's why, when we set up distfiles, we extended the policy on non-distribution to include "not mirrored on our distfiles servers". > >> 2) Should a new license option be used for packages marked as >> restrictive because of OpenSSL linkage (or other similar situation)? >> Fink policy says "will not distribute binaries", but in practice this >> also means that the source tarball is not distributed/mirrored. Most >> packages that fall into this category are GPL, so the source alone >> can >> be distributed. Having a new License option, Restrictive/ >> SourceOnly for >> example, to complement Restrictive/Distributable would take care of >> these packages. >> >> Hanspeter >> > > Sounds reasonable to me. Code it up. ;-) I'm not sure that "Restrictive/SourceOnly" conveys the correct intent. Perhaps "Restrictive/SourceDistributableOnly". However, I can't think of a case other than the openssl nonsense where this would apply. And many openssl packages have been converted to use the openssl which ships with os x (rather than fink's) which makes it ok to distribute. So I'm thinking that it might be better to spend energy in revising those packages, rather than in writing fink code (and distfiles code) to handle a new special case. -- Dave ------------------------------------------------------------------------------ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
