Subject: [firstname.lastname@example.org: Re: ADOSFS and GPL]
To: None <email@example.com>
From: Niklas Hallqvist <firstname.lastname@example.org>
Date: 02/15/1994 11:25:55
[ Richard, would you like to make a ruling on a GPL matter for us?
As you well know, the BSD type of Copyright is very liberal, even
allowing hiding source as long as you give credits where they are
due. Currently the Amiga NetBSD porting group have a dispute.
Our problem is that we're sitting on a filesystem implementation
written under GPL protection and we don't know if it's possible to
incorporate this filesystem code into the main NetBSD repository at
Berkeley without applying GPL to all of the NetBSD kernel source.
One point being made below is that as it's installed by a compile
time option, NetBSD as a whole cannot be regarded as work based on
this code, thus the FS code cannot force GPL onto the other parts
of the kernel. Is this so? What if a binary kernel with the FS code
in it were to be distributed, would it be sufficient to provide the
FS code in source form and a pointer to where the rest of NetBSD can
be found? I suspect this is borderline. In the discussion below
there's also a dispute whether or not GPLd LKMs (loadable kernel
modules) would mean anything to the kernel copyright. I'd say no,
but if you would make a ruling, we'd appreciate it. Thanks.
- Niklas Hallqvist
Subject: Re: ADOSFS and GPL
Date: Mon, 14 Feb 1994 19:11:33 -0500 (EST)
From: Frank "Crash" Edwards <email@example.com>
In-Reply-To: <199402142135.WAA15556@eunet.ch> from "firstname.lastname@example.org" at Feb 14, 94 10:35:40 pm
Organization: Edwards & Edwards Consulting, Palm Harbor, FL
Content-Type: text/plain; charset=US-ASCII
>> Well, I've got a question. This has come up before, but I never
>> understood the rationale. Last time, I was told "NetBSD can't have
>> GPL'd code" but nobody said why.
>> I'd like to know why. It seems to me that the GPL guarantees that
>> source code will always be available. If NetBSD has this same
>> philosphy, what's the problem? If it doesn't, why not? [Perhaps
>> someone could post the NetBSD version of the GPL? Then I could
>> compare them myself...]
>Here's an example copyright header (sys/kern/tty.c):
> * Copyright (c) 1982, 1986, 1990 The Regents of the University of California.
> * Copyright (c) 1991 The Regents of the University of California.
> * All rights reserved.
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in the
> * documentation and/or other materials provided with the distribution.
> * 3. All advertising materials mentioning features or use of this software
> * must display the following acknowledgement:
> * This product includes software developed by the University of
> * California, Berkeley and its contributors.
> * 4. Neither the name of the University nor the names of its contributors
> * may be used to endorse or promote products derived from this software
> * without specific prior written permission.
> [disclaimer of no warranty]
>So, the most important difference is that you can do "almost anything" with
>the source as long as you give proper credit. Under GPL, you're *forced*
>to disclose any sources you develop based on GPL sources, if you'd like
>to distribute your product, possibly SELL your product. Introducing just
>one GPL source into the kernel would *force* you to distribute source
>to anything you develop on the kernel, even if you just plain include and
>don't change that GPL source. The BSD sources have a very liberal copyright,
>and I don't want to restrict them all of a sudden to GPL conditions.
That's not how I read the GPL. Quoted from Section 2:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not apply
to those sections when you distribute them as separate works. But
when you distribute the same sections as part of a whole which is a
work based on the Program, the distribution of the whole must be on
the terms of this License, whose permissions for other licensees
extend to the entire whole, and thus to each and every part
regardless of who wrote it."
The rest of the NetBSD kernel is most definately an "independent and
separate work" since the AmigaDOS VFS is merely an add-on; an option.
The rest of the kernel is not "part of a whole which is a work based on
the Program" since the kernel is a self-contained program in it's own
right and does not require nor even suggest the use of the ADOS VFS.
"Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Program."
"In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program) on a
volume of a storage or distribution medium does not bring the other
work under the scope of this License."
A little bit different from the first paragraph since this one is
limited strictly to distribution media, but this certainly spells out
that the kernel could not be considered covered by the GPL just
because the ADOS VFS was.
>Things look slightly different when talking about applications to go
>into the system. They're closed "objects" by themselves. Using for example
>gcc as the system compilier doesn't force you to also distribute sources
>for your commercial application FOOBAR you'd like to distribute with
Agreed. This has been discussed quite a bit in gnu.* groups.
>> Heck, if I knew that the NetBSD wasn't going to restrict the code
>> somewhere down the line, maybe I'd finish the read/write stuff
>> myself? I've been thinking about trying out NetBSD... ;-)
>Grin, give it a try!
Perhaps. How do I know that the source will be available tomorrow? I
don't. (I'm not suggesting that anyone currently developing NetBSD
would conspire to remove the source from the airwaves, merely that I
could get "hooked" into an OS that started out "free" and then changes
so that only binaries are available.)
>There could EVEN be an alternate solution to this problem! NetBSD knows
>about loadable kernel modules (LKM). Implementing this filesystem as an LKM
>file system, there wouldn't be a fixed link between the kernel and the
>object files. Both, the kernel and the object files of the filesystem would
>be distributable seperately. That way, I think, the filesystem code could
>remain GPLd without making the kernel itself GPL. Well, I'm no laywer...
Yes, this looks feasible also. In fact, since this solves two
problems at once, ie. the fear of the GPL and the memory consumption
of the kernel, it would seem the ideal solution. Then the ADOS VFS
could simply be appended to whatever distribution media was used.
Since the code is around 150K, its bulk is not a mitigating factor.
The biggest problem is the line in the GPL about "3 years". There's a
clause that says that source needs to be available for 3 years from
the time that a binary is offered. But what happens to an ftp machine
that goes offline, never to return? Is the company that supported
that machine liable for the GPL if they had gnu binaries on board?
I would probably change the wording of the GPL to state that the
source must be available during the same time frame that the binary
is. So if you decide you're running out of disk space, you delete the
binary first (users can always recompile). If you still need space,
you delete the source after arranging with a mirror site to pick up a
(Since my girlfriend has ftp access now, I think I'll graba copy of
NetBSD in the next week or two and see about helping on the ADOS VFS
work. Niklaus, what do you think about a collaboration? :-)
Frank "Crash" Edwards Edwards & Edwards Consulting
Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin
Data/Fax: 813/787-3675 crash@azhrei.EEC.COM; inquiries to info@azhrei.EEC.COM