Isn't this the same old trade-off between static linking and dynamic linking or package vendoring vs. dependency that plagues all software?
A world in which data/functionality are only a link away is amazingly compressible and featureful, but if you are on a plane or otherwise disconnected then all you have is the link. If you 'remember' (cache) the meaning of that link you (the consumer) can at least pretend you know what it would have delivered (I don't need to actually go to <https://www.r-project.org/COPYING> if I think I already know what it says), but of course so many things like that have implicit semantics (what if the license there is changed to inform the reader that a court case invalidated some of it's terms? or there is a usage counter that must be incremented by the retrieval to comply with the full terms? Should such time-varying information even be allowed to be part of the package release?). The fact that CRAN cannot follow the link is a reminder that your users may not see the information that you intended to convey at the time of release when they need to look at it... and CRAN has a policy that if your contribution is incomplete that they don't want to accept it. There is a fundamental divide between the point of view that you have the right to put some of your content (license in this case) outside the package and their philosophy that you should be providing at the very least a link that is valid at the time they check it. But even that can never address the plight of the offline user with a local copy of CRAN not being able to evaluate the terms of usage. I am not clear how far CRAN should be bending for this issue... relying on Internet caching by some for-profit corporation doesn't really "solve" the fundamental issue that the package is incomplete as it stands... relying on the Internet is absolutely great for efficiency, but it is not really clear to me that doing so can consistently deliver a complete representation of the software and its terms of use. GPL2 allows separation of the deliverable and the source if there is a demonstrably reliable way to retrieve the complete source, but in this case the source is being delivered separately from the license and we seem to be finding that https links may not be passing a minimum bar set by CRAN. I don't happen to think moving that bar toward caching is a good idea... I have been offline before and probably will be again, and am also worried about the content at the end of that link changing the TOU later. So, IMO this is just another incarnation of dependency hell. On September 25, 2025 7:47:16 AM PDT, Dirk Eddelbuettel <e...@debian.org> wrote: > >Most of the README.md files for my package list the license I chose, and most >do so via a 'badge' showing the license and a link to the 'upstream' source >of the license. So far, so good. > >As I happen to prefer GPL licenses, I link to the fsf.org website. And >several recent package uploads of mine were upheld and moved to 'Inspect' >state forcing poor overworked Uwe Ligges to manually look at the log file >to conclude 'yep, spurious, all good here' because of a mere timeout. > >Same this morning: even after fiddling with the URL I use, testing several >times from here and noticing that 'oh dear this is apparently simply random' >I got one pass (Dortmund, Windows) and one fail (Vienna, Linux) so back to >'Inspect' and wasting Uwe's time it is. > >I would rather skip that step and take advantage of automation at CRAN and >not create extra work. I am not quite sure what the best way forward is. I >can think of saying 'ok, folks in Boston cannot run a server' and link to >the Wikipedia page of the GPL. Seems wrong though as we like to show the >original text. I notice that the R website does the same by providing GPL-2 >via a lopy copy: https://www.r-project.org/COPYING Now, for the package I >was working on this morning I actually needed GPL-3 and not GPL-2 so no luck >there. > >Short of giving up and creating a GitHub Pages hosted copy of the licenses I >may need, is there another good source ... without the server timing out? >https://choosealicense.com/licenses/ is pretty good but doesn't of course >provide GPL-2 so no luck for me there for most of my 'GPL (>= 2)' packages. > >Anybody have a better fix or idea? Maybe use the R sources (!!) and rely on >GitHub (most likely via a CDN) serving the licenses in > > https://github.com/r-devel/r-svn/tree/main/share/licenses > https://github.com/r-devel/r-svn/blob/main/share/licenses/license.db > >where via the .db (ascii text) file ones sees that all these licenses _are_ >in fact served via > > https://www.r-project.org/Licenses/ > >which even acts as a 'pretty' landing page (which I think I once knew >existed, looked for but could not locate via links from either the top-level >www.r-project.org or cran.r-project.org). > >So should we all link to that? > >Or not because it puts yet more load on the poor main r-project.org server >(or should we maybe CDN that or parts of it via cloudflare.com ?) > >Cheers, Dirk > -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
