Re: Portfile license attribute with CC0-1.0 license
Ryan Schmidt writes: > On Aug 23, 2021, at 11:39, Frank Dean wrote: >> >> >> I am creating a Portfile for a project that uses the Creative Commons >> CC0 licence [1]. I have specified the licence in the Portfile as: >> >>license CC0-1.0 >> >> [1]: https://creativecommons.org/publicdomain/zero/1.0/ >> >> Note that the first character after CC is a zero. >> >> When I run `port lint`, I get the following error: >> >>Error: invalid license 'CC0-1.0': missing hyphen before version >>---> 1 errors and 0 warnings found. >> >> The validation logic in `portlint.tcl` is to split the string on the >> hyphen and treat it as invalid, if the last character of the first part >> is a digit. >> >> Should I represent the CC0 licence in another way, ignore the error, or >> is a fix needed to `portlint.tcl`? > > This is a portfile development question so the macports-dev mailing list > would be a better place to ask. > > MacPorts license checking code (port_binary_distributable.tcl) does not > recognize the license name "CC0" but the license is a formalization of public > domain, so just write "license public-domain". You can add a comment line > above that mentioning that it's really CC0, like some other ports > (mypaint-brushes, libb2) already do. > > Some day we may overhaul our license handling to use SPDX identifiers but we > don't use them as of this time. Many thanks. I'll use macports-dev next time.
Re: why no /opt/local/libexec/gnubin links for inetutils binaries?
On Aug 18, 2021, at 23:44, Richard L. Hamilton wrote: > At least ftp and telnet still have their occasional uses, and being without > encryption, have been removed on reasonably new macOS versions. So inetutils > is useful. But the compulsory "g" prefix is annoying, whereas putting > /opt/local/libexec/gnubin at the end of one's PATH so that at least SOME > version of telnet, ftp, etc is found, is a simple way to keep scripts > working, etc*. I guess the problem with /opt/local/libexec/gnubin is that several different ports put their symlinks there. If you add that to your PATH, then you're getting all of those binaries in your path, which might not be what you expect. If you put the gnubin path *after* your system paths (PATH=/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/libexec/gnubin) then that's not so bad: if a binary like telnet isn't in the OS, you'll get the one in gnubin. However the original intention of this directory is to let you override your system binaries with GNU ones if you want that. The coreutils port for example tells the user they can put the gnubin path *before* the other paths (PATH=/opt/local/libexec/gnubin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin). In that case, "cp" would no longer refer to /usr/bin/cp; it would refer to /opt/local/libexec/gnubin/cp. If you have the gsed port installed, "sed" would no longer refer to /usr/bin/sed but to /opt/local/libexec/gnubin/sed. This could break scripts that expect cp and sed to be the macOS versions, but presumably the user electing to do this is aware of that risk. So I guess there isn't technically a problem. A user wanting cp, sed, telnet, et al to override the system versions can put the gnubin path first, and a user just wanting a fallback in case OS versions don't exist can put the gnubin path last. This distinction would just be something the user should be aware of, and I'm not sure we adequately inform them of this at present. There isn't even consistency at present: coreutils prints notes telling the user about gnubin but gsed doesn't. A different solution could be for inetutils not to use the g prefix at all, however the port was deliberately changed to use the g prefix years ago so I assume there was a good reason. Maybe some of the other utilities the port installs would shadow system-provided utilities in an undesirable way. Another fix users could do themselves is to create their own telnet and ftp symlinks in any other directory that is in their PATH. Another fix could be for the inetutils port to install ftp and telnet both with and without the g prefix on those OS versions that don't include those utilities anymore.
Re: Portfile license attribute with CC0-1.0 license
On Aug 23, 2021, at 11:39, Frank Dean wrote: > > > I am creating a Portfile for a project that uses the Creative Commons > CC0 licence [1]. I have specified the licence in the Portfile as: > >license CC0-1.0 > > [1]: https://creativecommons.org/publicdomain/zero/1.0/ > > Note that the first character after CC is a zero. > > When I run `port lint`, I get the following error: > >Error: invalid license 'CC0-1.0': missing hyphen before version >---> 1 errors and 0 warnings found. > > The validation logic in `portlint.tcl` is to split the string on the > hyphen and treat it as invalid, if the last character of the first part > is a digit. > > Should I represent the CC0 licence in another way, ignore the error, or > is a fix needed to `portlint.tcl`? This is a portfile development question so the macports-dev mailing list would be a better place to ask. MacPorts license checking code (port_binary_distributable.tcl) does not recognize the license name "CC0" but the license is a formalization of public domain, so just write "license public-domain". You can add a comment line above that mentioning that it's really CC0, like some other ports (mypaint-brushes, libb2) already do. Some day we may overhaul our license handling to use SPDX identifiers but we don't use them as of this time.
Portfile license attribute with CC0-1.0 license
I am creating a Portfile for a project that uses the Creative Commons CC0 licence [1]. I have specified the licence in the Portfile as: license CC0-1.0 [1]: https://creativecommons.org/publicdomain/zero/1.0/ Note that the first character after CC is a zero. When I run `port lint`, I get the following error: Error: invalid license 'CC0-1.0': missing hyphen before version ---> 1 errors and 0 warnings found. The validation logic in `portlint.tcl` is to split the string on the hyphen and treat it as invalid, if the last character of the first part is a digit. Should I represent the CC0 licence in another way, ignore the error, or is a fix needed to `portlint.tcl`? Many thanks, Frank
