Re: [Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
On 05/01/2010 9:22 AM, David R. Morrison wrote: 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. Right, but this currently covers both no-binary-distribution and no-binary-or-source-distribution licenses. Which is why I suggested having a new Restrictive subvariant to allow the former license to be have source mirroring by Fink. This also comes back to the first suggestion in my original post: let the package search in mirrors for the source, even if it's marked restrictive. If it really is restricted, the distfiles backends will not mirror it and the package fetch will 404 anyway. If it is available because of a non-restricted variant (or say upstream gave permission to have it mirrored), then it works. (this assumes distfiles is set up correctly vis a vis license restrictions, and that distfiles and fink don't use the same code to fetch sources) I realize that this takes coding, and I don't know Perl so I am in no position to provide patches (or expect/demand immediate fixes from others) so I'm looking at this more from a user experience point of view, where sources can and frequently do disappear, usually through download server reorganization, and that it can be frustrating for the user (there's also a bug on having MirrorLast set, but I'm still writing that up with clear situations). The OpenSSL/GPL 'conflict' is probably the main source of this issue, but given the response rate I get when I pass on my buildworld results to maintainers (even for simple crashes like missing symbols from the .la cleanup), I don't forsee much of a migration from the 'holdout' maintainers to system-openssl happening. Hanspeter -- ___ 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
Re: [Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
On Mon, May 03, 2010 at 08:20:25AM -0400, Hanspeter Niederstrasser wrote: On 05/01/2010 9:22 AM, David R. Morrison wrote: 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. Right, but this currently covers both no-binary-distribution and no-binary-or-source-distribution licenses. Which is why I suggested having a new Restrictive subvariant to allow the former license to be have source mirroring by Fink. This also comes back to the first suggestion in my original post: let the package search in mirrors for the source, even if it's marked restrictive. If it really is restricted, the distfiles backends will not mirror it and the package fetch will 404 anyway. If it is available because of a non-restricted variant (or say upstream gave permission to have it mirrored), then it works. (this assumes distfiles is set up correctly vis a vis license restrictions, and that distfiles and fink don't use the same code to fetch sources) I realize that this takes coding, and I don't know Perl so I am in no position to provide patches (or expect/demand immediate fixes from others) so I'm looking at this more from a user experience point of view, where sources can and frequently do disappear, usually through download server reorganization, and that it can be frustrating for the user For known cases where we have a source mirrored for some other reason than the package itself (i.e., some other package, or we somehow else picked in sometime in the past) and the proper upstream source goes away, can just change the .info Source to mirror:master: and it will go directly there. Not automatic (requires being told of problem and committing a fix), but solves the specific case. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ 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
[Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
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? 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 -- ___ 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
Re: [Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
-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. 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 believe that the Restrictive license explicitly makes fink only look in the original source URL(s), so I think we'd need some new scripting even to do option 1), so it'd probably be worth looking at both. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvcKPsACgkQB8UpO3rKjQ9pzQCcDyELEl5V6NzrUHdCAZ/ov4JM N2sAninkB80MCa4GcAxwfWZ1SXrdRQcr =idMq -END PGP SIGNATURE- -- ___ 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
Re: [Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
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
Re: [Fink-devel] distfiles mirrors and License: Restrictive (and SSL linking as Restrictive)
David R. Morrison wrote: [] 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. A healthier option would be to simply ignore that silly pissing contest between gnu and openssl and declare gpl packages as gpl, full stop. To any non-American at least it is clear that we are splitting hairs here that don't even exist, since Fink has stopped distributing binaries long ago. -- Martin -- ___ 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
