[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] FSDG processes

From: Jason Self
Subject: Re: [GNU-linux-libre] FSDG processes
Date: Mon, 18 Feb 2019 04:45:28 -0800

Gábor Boskovits asked:
> 1. If there is a free software, how do we ensure that it remains
> free, or that it gets into the list of software with freedom issues?
> Do we supervise each commit?

My understanding is that each distro should be doing their own due
diligence to only include FSDG-compliant free software but from what I
read in the FSDG that doesn't necessarily have to be an "exhaustive"
process. The FSDG has a part regarding that under "Commitment to
Correct Mistakes":

> Most distribution development teams don't have the resources to 
> exhaustively check that their distribution meet all these criteria. 
> Neither do we. So we expect distros to occasionally contain mistakes:
> nonfree software that slipped through, etc. We don't reject a 
> distribution over mistakes. Our requirement is for the distribution 
> developers to have a firm commitment to promptly correct any mistakes
> that are reported to them.

> Do we have a central place, where freedom related bugs can be
> reported?

This mailing list is supposed to be a centralized place for discussion
of things common to endorsed distros. Freedom issues should fall under
there, unless it's something that is somehow exclusive to one distro.

> 2. If there is a claim, that a given software has freedom issues, do
> we accept that without any investigation? How do we protect ourselves
> from a malicious actor faking these reports to hurt the reputation or
> market share of a software?

I don't think it would make any sense to do that. If someone reports
that a freedom problem exists, and if it's not immediately obvious
where the problem is, it seems perfectly reasonable to ask the person
to point to the specific freedom problem that they're seeing.

> On the contrary, if we get a report that the freedom issues don't
> exist any more, then we have to investigate that?

This is probably folded up into the distro's own due diligence that
they should already be doing.

> 3. If we have to investigate that a freedom issue does not exist any
> more, how is that done? Where can we track the progress of such an
> investigation? What is needed to take part in that?

I imagine that depends on the scenario and if a distro using their own
internal resources or if it's some sort of cross-distro collaboration.

> 4. What does 'files with unclear licenses' mean?
> 5. There is a whole bunch of licenses listed as acceptable by FSDG,
> including for example the 'modified BSD license', that do not mandate
> to put anything your source file, just drop the LICENSE file in the
> root folder of the project. The only thing I have seen why you would
> include anything license related in your files, is that the licensing
> remains clear in the case the file is copied out of the source tree.
> It seems to me there is a contradiction here: there is a license
> approved by the FSDG, but it is not approved at the same time, as
> software gets rejected, stating that the license is unclear, however
> the author did everything the license required. To me the only
> resolution to this would be:
> either to accept that files without the license notice, for licenses
> that don't mandate their inclusion is really under the license;
> or to declare all licenses not mandating the inclusion of a license
> notice incompatible to the FSDG. What is your opinion on this?

I'm combining 4 and 5 since they seem similar. Broadly-speaking there
are two ways to handling copyright and licensing information with a
free software project: File-scope notices and centralized notices.
These are discussed more fully in [0]. My take is that whether a given
program uses either method shouldn't have any bearing on being suitable
for inclusion; because I see nothing in the GNU FSDG that would require
distros to only include programs that use file-scope notices. Indeed,
that would unnecessarily limit the number of free software programs
available. For programs that use centralized notices that should apply
to the entire program unless there is some notice to the contrary.

So; a file without a license header isn't necessarily a problem. It
needs to be evaluated within the context of that program (i.e., it
might lack a license header because the project uses centralized

Even programs like Linux-libre don't have copyright and licensing
information inside each and every file. The standard in the kernel
community is that things without specific license headers in the kernel
are treated as being under the project's default license of GPLv2-only.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]