lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878x8g5mkc.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Date:	Mon, 13 Aug 2007 02:02:11 +0200
From:	Marcus Brinkmann <marcus.brinkmann@...r-uni-bochum.de>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	bug-hurd@....org, linux-ext4@...r.kernel.org
Subject: Re: Future of ext2 support in the Hurd?

At Sun, 12 Aug 2007 17:40:00 -0400,
"Theodore Ts'o" <tytso@....edu> wrote:
> There is definitely still code in the ext2
> filesystem translator which is GPLv2 only, since it is derived from
> Linux.  And as we all know, GPLv2 and GPLv3 code are licensing
> incompatible, and that the FSF has claimed that the GPL will infect
> across a wide variety of linking mechanisms, up to and including dynamic
> linking.

Yes.  To my understanding, the GPL is not about technical methods, but
seeks for maximum protection available under law, irregardless of
technical methods to create a derived work.

The files you are referring to, ext2_fs.h and ext2_fs_i.h, can easily
be replaced by clean-room implementations, if relicensing the ext2fs
translator is desired.  However, we have other parts in the Hurd where
that is not possible (drivers in the kernel, network stack in our
network server).  So the questions you raise are still interesting.

In fact, I just searched for your name, and it pops up in the network
stack, but not in the ext2fs translator (the above files are copyright
Remy Card and Linus Torvald).

> Indeed, in the case of GCC, RMS has made the claim (when
> pursuading NeXT to release the Objective C front-end under the GPL),
> that the GPL infects across a Unix pipe!

I don't know any details about that case, but I can easily imagine
that being true, so I will just take your word for it.  The GPL FAQ
states that

  "We believe that a proper criterion depends both on the mechanism of
  communication (exec, pipes, rpc, function calls within a shared
  address space, etc.)  and the semantics of the communication (what
  kinds of information are interchanged).

  If the modules are included in the same executable file, they are
  definitely combined in one program. If modules are designed to run
  linked together in a shared address space, that almost surely means
  combining them into one program.

  By contrast, pipes, sockets and command-line arguments are
  communication mechanisms normally used between two separate
  programs. So when they are used for communication, the modules
  normally are separate programs. But if the semantics of the
  communication are intimate enough, exchanging complex internal data
  structures, that too could be a basis to consider the two parts as
  combined into a larger program."

This matches my best understanding of the issues involved.  Beyond
that, I can not say anything that applies particularly to the Hurd or
its RPC interfaces.

> The reason why I ask this
> question is it seems extremely important whether or not the FSF has made
> a determination if the GPL infects across HURD IPC calls.  If the GPLv2
> does in fact infect across Hurd calls, and the Hurd is going GPLv3, it
> seems that will be a need to either drop the ext2 filesystem, or rewrite
> those portions of the ext2 filesystem which are derived from Linux code.

That is an important question, but for now the Hurd is GPLv2, for
exactly that reason.  There are other significant parts of the Hurd
taken from Linux, so we can't do a complete switch at this time.  To
make a partial switch, we would have to address the issues you raised.

Beside the FSF' position, your position (and Remy Cards', Linus
Torvalds' etc) matters as well, of course.

As a side not, personally I am confident that most of these cases can
be resolved quickly and amicably, and will have exactly the outcome
that common sense suggests.  The other cases I will happily leave to
the lawyers to sort out.

Thanks,
Marcus

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ