Message-ID: <orob66ewrf.fsf@livre.home>
Date:	Wed, 30 Oct 2013 11:03:32 -0200
From:	Alexandre Oliva <oliva@....org>
To:	Rob Clark <robdclark@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: missing sources for generated files in drivers/gpu/drm/msm

Hi,

Before getting to $SUBJECT, some context and a request for information:
drivers/gpu/drm/msm/ got my attention while preparing the upcoming
3.12-gnu release of GNU Linux-libre.  It names some firmware files that
I couldn't locate to determine whether or not they're Free Software.  I
failed to find links to them in the documentation or even in comments,
and the files don't seem to be present in the linux-firmware git
repository either.  I'd appreciate some information about a300_pm4.fw,
a300_pfp.fw, a330_pm4.fw and a330_pfp.fw, such as where they can be
obtained, how they're licensed, and whether their sources are available.


While looking for the info above in the 3.12-rc7 source tree, I noticed
a number of *.xml.h files in drivers/gpu/drm/msm/*/ that claim to be
generated files (i.e., they're not sources per the GPL), and that point
to a git repository that seems to have moved:

  This file was generated by the rules-ng-ng headergen tool in this git repository:
  http://0x04.net/cgit/index.cgi/rules-ng-ng
  git clone git://0x04.net/rules-ng-ng

In the commit message, I could find a note pointing at
  https://github.com/freedreno/envytools

I suppose that's where the repo mentioned in comments moved to.

It would surely be desirable to adjust the links so that people who get
the linux tarball can find the tool.  AFAICT, rerunning the headergen
program, as it is in the envytools repo above, will generated them with
the updated URLs.


However, the more serious concern in my mind is that, as the Linux
tarballs stand, they are not compliant with the GPL, and they induce
others to fail to comply with it in other ways, detailed below.

The direct non-compliance is the lack of corresponding sources for these
*.xml.h (because the links to them are broken) and of scripts to control
the compilation of the original xml files into *.xml.h (I don't see them
even after locating the moved repository; I'm not even sure it's
headergen program that should be used to convert the .xml files into
.xml.h).

The inducement problem is that, because generated files are included in
what most people presume to be the source tarball, without their
corresponding sources, anyone who wishes to distribute binary versions
of Linux under §3a of the GPL, so as to immediately satisfy all of their
obligations under the GPL, will fail to do if they just accompany the
binary with the Linux “source” tarball.  In order to satisfy the
requirements of GPLv2 under §3a, they'd have to distribute, along with
the Linux “source” tree, the xml files from the envytool repository, as
they were when the *.xml.h files were generated.

Failure to do so could be quite inconvenient, or even construed as
copyright infringement, should a distributor be unwilling or unable to
satisfy their obligations under §3b or §3c of the GPL when prompted to
provide the corresponding sources (the xml files and scripts used to
turn them into xml.h files), for example, because the repository
containing them moved again or became inaccessible.

In order to avoid this problem, it would be ideal if the xml files, and
a script that runs the conversion program to .xml.h, could be included
in the Linux repository proper.

I realize that neither the xml.h files nor the xml files they're
generated from are licensed under the GPL, but rather under a far more
permissive license.  While this could alleviate some of the concern if
the files were distributed separately, once the files are distributed as
part of Linux, as they are, they are distributed under the GPL, and so
distributors must satisfy the requirements of the GPL when
redistributing them.


I hope you'll agree these are real and serious problems, that they're
trivial to fix, and so that they can be fixed in time for 3.12.


Does anyone know of other such cases of generated files without
corresponding sources in the Linux repository, aside from the various
well-known blobs within the firmware/ subtree and the assorted
blobs-disguised-as-sources that still often pop up in drivers/staging?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists