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.
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.
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.
[1] https://github.com/dhatim/python-license-check
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.
Best,
Michael McMahon | Web Developer, Free Software Foundation
GPG Key: 4337 2794 C8AD D5CA 8FCF FA6C D037 59DA B600 E3C0
https://fsf.org
On 8/26/23 15:41, Denis 'GNUtoo' Carikli wrote:
On Tue, 15 Aug 2023 23:30:42 -0400
Michael McMahon <mich...@fsf.org> wrote:
Hi, Denis!
Hi,
I also want to highlight that helping upstream to fix issues or
improve should be the first step as many workflows including version
managers involve installing third-party package managers in isolation
that may bypass a system-level third-party package manager. Working
with upstream, also has a scope that is greater than the FSDG
distributions.
I've read that article long time ago.
I think that managing to "convince upstream" is often too optimistic,
and it can be counter productive too depending on how it's done (if the
upstream feels we are trying to aggressively force a decision on them,
while not already being part of their maintainer community, it could
produce the inverse effect).
So what has more chance to work is probably to explain upstream what our
goals are and see if we can work with them to solve our problem. This
can still manage to convince upstream as we can explain why we need
this, and why FSDG compliance is important for us and that maybe they
could also be interested but if they aren't we also need to show
them that we have other options as well as we are not trying to force a
solution on them, instead we are just trying to solve our problem.
If this type of convincing fails, it makes sure that we have at least a
way to understand each other goals, and it also keeps the conversation
open for the next strategy which would be to find a way to make
everybody happy and avoid extra maintenance ourselves by collaborating
with upstream.
This brings up the question of what exactly to ask for and how to know
if the solution we propose is really FSDG compliant. Usually it would
also be up to us to implement the solution by sending patches but
sometimes the upstream is very friendly to our cause and can do the
work.
For instance to be FSDG compliant we need to not refer to nonfree
repositories and so as you pointed out, if there is a configuration for
that, the configuration mechanism need to be designed to be used by
FSDG distros in a way that complies with the FSDG, and that reduces
maintenance.
That leaves some options that need to be "activated" during the
packaging like:
- Replacing the default configuration file with an FSDG compliant one.
An example here would be a configuration like /etc/apt/sources.list.
- Building the package with other build options (--without-nonfree
--fsdg-compliant, etc).
But for instance a hard-coded option like (apt install
--without-nonfree or --with-nonfree or some button that the user clicks)
to enable/disable nonfree software won't work even if upstream disables
nonfree software by default as there is still an option to re-enable
nonfree software.
A better way would be to have the configuration done at build/packaging
time, so that the program (like pip) being packaged is FSDG compliant.
Another issue is that upstream often have different notions
of free / nonfree than the FSDG distributions. So we usually need
something specific for FSDG and to label it in a way that makes people
understand that.
For instance if we try to convince pip to add an option that can be
activated at packaging time, there is a problem with the pip pip package
itself.
For instance if someone does 'pip install pip' in an FSDG compliant
distro, that person would have installed a non-compliant pip (because
it comes with a configuration that (can) enable nonfree software).
The issue here is that the pip project would consider the pip installed
with 'pip install pip' as free while FSDG distros won't. So we also need
something specific like an FSDG option to make sure that upstream and
distros could consider that pip is not FSDG compliant and filter it out.
At this point users would need to help tag software as being FSDG
compliant or not FSDG compliant in some way. For instance most software
could be free or nonfree with pip being "free" and not FSDG compliant
and because of that would be filtered out.
The Free Software Directory teams use FOSSology, Licenseutils, and
ScanCode Toolkit to help scan repositories for license compliance.
These tools do not make licensing distinctions by themselves and
require manual interpretation. Developing interpretative automation
for these free software tools would help the licensing community.
A good idea would also be to somehow package these tools to make it
easy for users to use them. I wanted to do that for Replicant at some
point but I never found the time.
For the record I was involved in a discussion with F-Droid to solve
this problem, and I also followed some discussions with
phoronix-test-suite, so part of what I wrote above is based on
experience with these two cases. But other people might have different
experiences and so they could probably complete and/or criticize what I
wrote.
Denis.
