On Sun, 27 Aug 2023 11:17:34 -0400 Michael McMahon <mich...@fsf.org> wrote:
> Maybe working with upstream is optimistic, but it should be the first > step regardless. The workflow of many third-party package managers > involves pulling in the upstream version which would bypass any > distribution specific-changes. What I meant was that convincing upstream to be FSDG compliant or at least 100% free is probably too optimistic for most cases. But I didn't suggest not to work with upstream, because even if convincing them to be FSDG compliant fails, relying on upstream for maintenance of licensing information is a really good strategy. Though maybe I'm not that optimistic for convincing upstream to become FSDG compliant because I had bad luck with that, so maybe we only need good examples that contradict what I'm assuming here. Recently I found that R was a GNU project, so maybe the safest approach here would be to have people that have some time for that and that know R well and are good at negotiation (just to make sure this doesn't get the opposite effect) to approach the R project to understand their relationship with CRAN and/or how to adjust it slightly to make it FSDG compliant and check with them if our strategies are good and what kind of issues could arise when discussing with other projects than R/CRAN. > When approaching upstream, it would be beneficial to look at a bigger > picture of what their users want from licensing beyond the scope of > what FSDG distributions want. I think it's the key issue here. The easiest is of course when designing such repositories, to not to bring in nonfree software from the start. The issue we had with F-Droid at the time was that they had existing applications with existing users. Though at the same time unmaintained software gets moved in other repositories, so maybe we should restart the discussions when we'll be able to build F-Droid and when we' the issue of nonfree dependencies to the nonfree Android SDK would be solved again. > Some third-party tooling for third-party package managers already > exist to check license compliance. One that stands out to me is > python-license-check [1] which seems to be built with the opposite > intention as this thread. The goal of python-license-check seems to > be for a way to reassure a corporation's legal team that no copyleft > software is present in their product. While the tool's example is the > opposite, it could still be a useful tool for the goal of this > thread. Understanding, this tools purpose also helps with > strategizing for ways to approach upstream. If it works reliably, adding options to check for 100% free software would indeed be a good idea. > Upstream likely may not care whether a package is FSDG compliant, but > they probably would care whether a package is compliant with various > licensing strategies such as only including FSF approved licenses, > only including OSI approved licenses, excluding licenses that are not > compatible with the licenses that the license that they use (BSD or > copyleft or something more specific), or indifferent to licensing. Right. Companies can be at big legal risk if they don't follow the licenses from other companies. So maybe having collaboration about that directly in the upstream project and in some tools as well would be beneficial indeed. Even if it doesn't solve the whole problem (as FSDG has requirements that go beyond licensing), it would probably cover most cases. Maybe contacting Bradley Kuhn would also be a good idea as he seems to have some very good insights into the licensing compliance industry. So maybe he also know where to find allies that could contribute to solutions that also work for us for FSDG compliance. Denis.
pgpjn7riyHmhk.pgp
Description: OpenPGP digital signature
