Re: [tlug] JFS file system license

["Stephen J. Turnbull" <stephen@example.com>]

Nguyen Vu Hung writes:

 > LGPL applies for libraries,

This is a misstatement.  It applies to any work to which the copyright
holder applies it, and to no others.  It was intended for, and has
some language most applicable to, libraries, but is certainly useful
in something like, say, the GIMP which later birthed GTK+, and could
be used for any program, or even a manual or a newspaper.

 > and it deals with static linking and dynamic linking.

No, it doesn't.  Dynamic and static linking are not mentioned in any
license I know of, nor in Title 17 of the U.S. Code.  In fact the LGPL
doesn't deal with linking as a technical definition at all.  From V3,
Additional Definitions:

  A "Combined Work" is a work produced by combining or linking an
  Application with the Library.  The particular version of the Library
  with which the Combined Work was made is also called the "Linked
  Version".

This wording makes it clear that linking is generally a form of
combining, and that the LGPL will define its own applicability to
combined works in general.  However, nowhere in this license is
linking otherwise defined.  My guess is that a court would generalize
all references to "linking" in this document to other forms of
combination as well, and would restrict the meaning under copyright
law of linking in the license to only those cases that result in a
"combined work" (which is a term of art in copyright law, ie, it is in
some way defined either in legislation, case law, or the consensus of
judges---it is not defined with reference to computer technology).

It is known (tested in court, I believe) that both forms of linking
result in a derived work in memory, and that static linking results in
a derived work in a file.  However, what is further claimed by some
experts, and disputed by others, is that merely incorporating the API
calls creates a derived work of the program (library) implementing the
API, even if no copy is present.  However, there is no authority for
this claim in U.S. legislation or case law.  In other words, this
latter claim is folklore, backed up by the willingness of the FSF to
threaten (and presumably conduct) lawsuits against people who have to
pay their lawyers (and thus are always looking for a cheaper way out).

(There was a German case that people refer to as a "test of the GPL".
However I do not know if this particular point was involved in that
case.  Anyway non-European courts are not required to pay attention to
international precedents, though enlightened judges often find ways to
do so.  So it's not that relevant to U.S. or Japanese law.)

 > For the kernel and a filesystem( JFS - GPL licensed, which is a
 > part of the kernel), there is no "linking" to it, and the way we
 > use the kernel is different from using (i.e. linking) a library.

For the JFS, maybe it is mediated by the kernel, and so not linked to
the program.  But for programs that call kernel facilities, definitely
there is a link in the sense of an API with a well-known calling
sequence.  The law doesn't care whether that is implemented as a
subroutine call, a software interrupt, or an Intercal come from.

 > IMO

I hate to break it to you, but your opinion is not relevant.  If you
have authorities you can quote for your statements, that would be
different.  (You don't have to actually cite them; for example, I
usually don't.  But you should be able to list them, and where called
on it, provide accurate citations.)

And neither is mine.  What I post is information paraphrasing Title 17
of the U.S. Code (which paraphrase may or may not be accurate, caveat
lector), and information paraphrasing conversations with and reading
of various authorities, including Frank Bennett, Larry Rosen, Larry
Lessig, Eben Moglen, Richard Stallman, Eric Raymond, Larry McVoy, and
where necessary resorting to assorted less authoritative opinions
posted to various channels including lkml, djgpp, emacs-devel, and the
Free Software Business list (same caveat applies).

Besides U.S. law, occasionally I have cause to cite Japanese law and
various international treaties, especially the Berne Convention.  All
of these legal texts are available online, and you should check them
if you mistrust my paraphrases.  Among the human authorities, Larry
Lessig and Larry Rosen have published books (Larry Rosen's is
especially recommended, Larry Lessig's popular books are more about
ethical implications than about the workings of the law itself) and
articles you can read.  In the cases of personal conversations with
Frank Bennett and Larry Lessig alcohol was involved, so my memory may
not be reliable; other conversations took place in email.  Some email
was private and not available online, but the FSB archives are full of
useful discussions about law.  The other archives mentioned are not so
useful, since it's not all that easy to search them for specifically
legal discussion (although "IANAL" would probably do a pretty good
job! :-)

 > the approach (of calling open()) is quite similar to LKMs so if
 > Linus believes that LKMs are derivative work[1],

Ditto Linus's opinions.

However, Linus has objective reason to claim that LKMs are derivative,
because they call non-public interfaces of the kernel, and are loaded
into the same address space.  This is not true of the ordinary program
calling open(), which isn't even a Linux function, but POSIX standard,
with many implementations, some of which are very permissively licensed.

 > then the same conclusion should be applied

A reasonable thought in ordinary discourse, but completely false in
law, which has its own definitions which often conflict with those
useful in engineering, to the consternation of engineers and lawyers
alike.