[Committee-d] System libraries exception and unpopular languages

[Brett Smith]

The current draft of GPLv3 says that the Corresponding Source need not
include the source code for System Libraries, which are defined thus:

  The "System Libraries" of an executable work include every subunit such
  that (a) the identical subunit is normally included as an adjunct in the
  distribution of either a major essential component (kernel, window
  system, and so on) of the specific operating system (if any) on which the
  object code runs, or a compiler used to produce the object code, or an
  object code interpreter used to run it, and (b) the subunit (aside from
  possible incidental extensions) serves only to enable use of the work
  with that system component or compiler or interpreter, or to implement a
  widely used or standard interface for which an implementation is
  available to the public in source code form.

There is some concern about the part that requires that the code "implement
a widely used or standard interface."  This language is meant to include
different programming languages standard libraries.  However, it's not
clear that it works for unpopular languages.

Here's an example Dave gave.  (He wrote this before the second draft was
released, so it uses some old language.)

  The problem is that nobody uses Smalltalk, so the interface isn't "widely
  used", and the standard doesn't specify enough, so the interface isn't
  "standard".  So the Smalltalk standard libraries don't fall under the
  major components exception (note: as soon as draft2 is released, I'll use
  the draft2 term instead).

It could be understood that "widely used" means "widely used by programmers
of a given language," but if that's the case, it should probably say so.
So Dave proposed the following solution:

  So, I propose changing it [the language in the exception] to "a Standard
  Interface," and defining a Standard Interface as "an interface that is a
  de jure standard (ANSI, ISO, ECMA, etc) or is used by a majority of
  developers working in the programming language".  It doesn't have to be
  this precise language, of course, but something to include that the class
  libraries of even unpopular languages would be good.

We discussed this proposal during the meeting last night.  Generally we
liked it (Mako and I did, at least), but were concerned that it could be
exploited to avoid the GPL's obligations.  For example, consider
Rattlesnake, a hypothetical language that's just Python with some patches
to add a case statement, and a number of additions to the standard library
that all have proprietary implementations.  Someone who writes Rattlesnake
can modify GPLed Python programs to make use of its "value-added" standard
libraries, and can honestly claim that those libraries are used by a
majority of developers working in the programming language -- since they're
the only user and they're using the libraries in question.

Obviously pulling this stunt takes some effort.  But it could be worth it
if you're interested enough in using GPL-incompatible libraries to modify a
GPLed program.  It's not *that* hard to do.  We discussed possible ways of
avoiding this problem last night, and didn't come to any final
conclusions.

Now that I'm writing this e-mail, I see that we may have a solution in the
current draft's language, by requiring that the source for an
implementation be available to the public.  So, the language could look
like this:

  1. Source Code.

  The "source code" for a work means the preferred form of the work for
  making modifications to it. "Object code" means any non-source version of
  a work.

  A "Standard Interface" means an interface that is either a de jure
  standard (defined by a widely recognized standards body such as ANSI,
  ISO, or ECMA) or used by a majority of developers working in the
  programming language, for which an implementation is available to the
  public in source code form.

  The "System Libraries" of an executable work include every subunit such
  that (a) the identical subunit is normally included as an adjunct in the
  distribution of either a major essential component (kernel, window
  system, and so on) of the specific operating system (if any) on which the
  object code runs, or a compiler used to produce the object code, or an
  object code interpreter used to run it, and (b) the subunit (aside from
  possible incidental extensions) serves only to enable use of the work
  with that system component or compiler or interpreter, or to implement a
  Standard Interface.

  [This paragraph is unchanged, but inclued here for your reference:] The
  "Corresponding Source" for a work in object code form means all the
  source code needed to generate, install, and (for an executable work) run
  the object code and to modify the work, except its System Libraries, and
  except general-purpose tools or generally available free programs which
  are used unmodified in performing those activities but which are not part
  of the work. For example, Corresponding Source includes scripts used to
  control those activities, interface definition files associated with the
  program source files, and the source code for shared libraries and
  dynamically linked subprograms that the work is specifically designed to
  require, such as by complex data communication or control flow between
  those subprograms and other parts of the work.

  [... and so on...]

Here are my immediate concerns with this:

* Should source be required in the case of a de jure standard, a de facto
  standard, or both?  (I think both.) Whatever we decide, is it possible to
  make this clearer in the language?

* Is it okay to talk about a "widely recognized standard body?"  My biggest
  concern here is that proprietary software developers may have their own
  standards bodies which they care about a lot but I've never even heard
  of.  Even if they exist, though, so long as we require that a source
  implementation be available for de jure standards, the worst they can do
  is cause less source to be distributed.

  Also, this definition may not include groups like the Web Standards
  Project or Web Standards Group; that may be unfortunate, but all it does
  is require that more source be distributed with programs, which doesn't
  seem like a big deal to me.

However, I think this proposal both (a) allows in the standard libraries of
unpopular languages, and (b) avoids exploitation through the creation of
vanity languages.  Your thoughts?

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation