Submitted for Approval: OSL 3.0 and AFL 3.0

[Alex Bligh]

Larry,

This whole subject comes up because people are trying to square computer
science formulations with legal formulations. In the end, I suppose
the answer is "it's a question of fact", but I shall comment a little
below.

> Linking to a library is essential for its use; a library serves no other
> purpose. The owners of such libraries must intend for their licensees to
> link to them (however the term "link" is defined technically), and their
> licenses should make that point clear.

Well true, to a point. However, let's say I produce a software suite which
consists of executables A, B, C. They share code in common, so I put that
in a (shared, dynamic) library D. The reason for putting the code in a
library is a technical one to do with reducing memory requirement when
more than one of A, B, C is loaded at once. It has nothing to do with
code reuse. Let us presume A, B, C are executables that fundamentally
rely upon eachother, are deeply interwoven, and share data. In this
instance, there is a library, but it would be hard to argue A, B, C, D
are anything but part of the same work. They are not a collective work
just because of the on-disk format. I would argue that in this instance,
if A, B, C, D are licensed under a reciprocal license, the owner of D
did intend for things to link to it, but quite possibly not anything
other than A, B, C (and other parts of a derived work).

A library, developed as a separate work, with clear interfaces to external
users, is clearly a different case. Even here it could be argued though
that the licensor's intent was to allow linking TO OTHER APPLICATIONS WITH
THE SAME LICENSE.

But I do not think you can always assume that a licensor intends a library
which is part of a work licensed under a reciprocal license is always
intended to be permitted (by the licensor) to be linked to other works
under different licenses.

> The LGPL specifies how libraries work in practice using rather complicated
> technical terms of computer art that have proven difficult to extrapolate
> into modern applications.

And indeed no-one has yet conclusively demonstrated the correctness of the
FSF's interpretation of the GPL, which prohibits linking of GPL'd libraries
to non-GPL works under all circumstances (apart from, obviously, where a
license exception is made).

I believe that if the facts support it (as per the example you were
thinking of), i.e. where there is a single GPL'd library clearly designed
to link to other things, there is a good case that linking does not
create a derived work.

> I prefer to view mere linking as the creation of a collective work, "in
> which a number of contributions, constituting separate and independent
> works in themselves, are assembled into a collective whole." 17 USC 101.

That's as fine as far as it goes, but it is in a sense a cop-out, not
least because the user then has to determine whether or not his application
plus library is a collective work or not. I think there is a case for
some endogenous guidance from the license itself on interpretation.

Actually, to be more precise, in the case of a library executable plus
application executable, there is little doubt that the pair together form a
collective work in the sense of 17 USC 101. The pertinent questions are:
1. whether the application itself is also a derived work of the library
   SOURCE (for instance by inclusion of code-containing headers).
2. whether the obligation to provide source code for an executable
   licensed under an open-source reciprocal license includes the obligation
   to provide library headers - these are necessary for compilation,
   so you would have thought that it was necessary. Is it allowable
   to provide these separately (presumably yes, so long as they are
   in fact provided). What about where they are under a different license
   which contains additional restrictions (even if it's "just" the GPL)?
   (this is prohibited under some licenses, but not seemingly the OSL.
   What if the headers are for a closed-source library? (i.e. that the
   source code can be used to build the executable, but it can never
   run without a closed-source library) - this seems possible under
   the OSL 3.0 too, as only the headers form part of the "Source Code"
   if one accepts that the library itself is a separate work.

Alex