Subject: Re: ADOSFS and GPL

From: Frank "Crash" Edwards <[email-masked]>

Niklas Hallqvist sayeth:
>I've
>seen people ask for the ADOSFS, and I'll try to put together a package
>this week, really!!!  It'll be GPL'd and readonly though, as I've done
>nothing new for the last couple of months.

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...]

>Niklas Hallqvist	Phone: +46-(0)31-40 75 00

Sorry to bring this up again.  Please take it offline (ie, email) if
you think there's little or no interest in the rest of this group.
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...  ;-)

PS: I'm going out of town for a few days, but I'll make one last check
in my mailbox before I leave (Tuesday afternoon).  Thanks!
-- 
Frank "Crash" Edwards    Edwards & Edwards Consulting
Voice:    813/786-3675   Unix/AIX & OS/2: Training, Programming, and SysAdmin
Data/Fax: 813/787-3675   [email-masked]; inquiries to [email-masked]

---

From: [email-masked]

> someone could post the NetBSD version of the GPL?  Then I could

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.
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *

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.

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
the system.

> myself?  I've been thinking about trying out NetBSD...  ;-)

Grin, give it a try!

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...

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	[email-masked]
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH

---

From: David Jones <[email-masked]>

> remain GPLd without making the kernel itself GPL. Well, I'm no laywer...

Although no precedent has been set, the FSF takes a dim view of anyone using
techniques such as this to "work around" the GPL.  The FSF considers pretty
well ALL dynamic link libraries to be equivalent to statically linked libs.

This means that using a dynamic loading technique does not exempt you from
the GPL requirements.  And LKM is, after all, a sort of dynamic loader.

Consider this: If I write a library libgpled.a, then does it make sense to
have a statically linked foo forced under the GPL and to have a dynamically
linked foo (a separate binary) not under the GPL?

The best advice I can give is to ask someone at the FSF, by email, about
what you plan to do.  Be specific.  The FSF will not "rule" on general
cases, nor will they rule on gnu.misc.discuss.

-- 
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
email: [email-masked], finger for more info/PGP public key

---

From: [email-masked]

> cases, nor will they rule on gnu.misc.discuss.
	Or skip GPL altogether and just release the code as BSD type
	license. WHY go through all the bother to make sure it's given
	the FSF brand of approval/blessing? What a pain...

	Frank was the author of the SVR4 AMIX read-only driver. He chose
	to release the AMIX driver GPL. If he loads up NetBSD he has
	the option to release a NetBSD version non GPL'd, which I
	hope he does.

	The other individual did alot of work to adapt SVR4 VFS code to
	NetBSD's VFS. If he and Frank get together we could possibly have
	a non-GPL'd ADOS filesystem driver that could be put in to the
	main sun-lamp tree.

	Frank did ALOT of hard work in writing the original AMIX driver,
	the other gentleman did alot of hard work converting it to NetBSD.

	Hopefully both can be convinced that a BSD license and accolades
	from their Amiga peers/fans will be enough for all their hard work.

		-Rob

---

From: [email-masked] (Chris Hooper)

>From [email-masked] Mon Feb 14 18:15:17 1994
Subject: Re: ADOSFS and GPL
From: David Jones <[email-masked]>
To: [email-masked]
Date: 	Mon, 14 Feb 1994 17:04:55 -0500
Sender: [email-masked]
Status: R

>> be distributable seperately. That way, I think, the filesystem code could
                    ~~~~~~~~~~~
>the GPL requirements.  And LKM is, after all, a sort of dynamic loader.

I think you're missing the point that Markus made.  If you write a
driver and distribute it separately from the base NetBSD distribution,
there's no way it could be called "part" of NetBSD.

Otherwise, what would stop me from taking it a step further...
ie: I write an application with totally bogus copyright restrictions.
It happens to run under SunOS.  *Poof*  Suddenly all distributions
of SunOS are bound by my copyright because my program runs under SunOS?
I don't think so.  :)

- Chris Hooper     Computer Sciences Corporation - System Support Engineer at
  [email-masked]  General Dynamics  [Sterling Heights, MI]    (810) 825-5061

---

From: [email-masked]

> well ALL dynamic link libraries to be equivalent to statically linked libs.

Sorry, but in that case I'll have to read their COPYRIGHT file, and I can't
find that in our specific case of LKMs they'd have any right to reserve GPL
upon the kernel, just because someone had the idea of creating a completely
independant set of object files, linking them together (forming a GPLd
binary) and then - what an outrageous idea - to specifying them as argument
to modload. The way I understand it: the BSD kernel by itself is a standalone
product, it doesn't need any specific LKM modules to be operating, nor will
it ever be distributed TOGETHER with such (GPLd) LKMs. Distributing a 
separate thing, that just happens to work with this kernel, can't by all
means change the copyright status of that independant object!? Not even with
US laws :-)

> the GPL requirements.  And LKM is, after all, a sort of dynamic loader.

Yes and no.. dynamic loaders impose a stricter binding between the dynamic
library and the application. Furthermore, you can't usually run applications
linked dynamically without those dynamic libraries. You CAN run the kernel
without any LKMs just fine.

> linked foo (a separate binary) not under the GPL?

We get a bit down to hairy details here.. I'd say, a SunOS/BSD style dynamic
library would still be GPLd, an AmigaDOS shared library wouldn't. BTW: that's
exactly the reason I made ixemul.library a) shared, b) put it under GPL. I
explicitly explained in the docs that this does NOT cause any programs using
it to be GPLd, since I declared the glue-functions PD. There are no glue
functions needed for LKMs.

> cases, nor will they rule on gnu.misc.discuss.

Well, the GPL text is public, if it's not in there, it's irrelevant
what anyone at FSF thinks about it. I think the case is pretty clear
here.

-Markus

---

From: [email-masked] (Ty Sarna)

> the GPL requirements.  And LKM is, after all, a sort of dynamic loader.

By that logic, so is the kernel. I'm sure Sun/HP/DEC/etc will be rather
upset when the find out FSF is claiming their kernels are GPLed, since
folks have "dynamicly loaded" gcc into them. (assuming that you're
correct and they do take this stance)

> cases, nor will they rule on gnu.misc.discuss.

If this is actually true, it's more reason to avoid GPL code entirely. 
In practice, Berkeley-style licenses seem to really be much more free.

-- 
Ty Sarna                 "As you know, Joel, children have always looked
[email-masked]        up to cowboys as role models. And vice versa."

---

From: Frank "Crash" Edwards <[email-masked]>

[email-masked] sayeth:
>I said:
> [disclaimer of no warranty]
>

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."

Exactly.

    "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.

>for your commercial application FOOBAR you'd like to distribute with

Agreed.  This has been discussed quite a bit in gnu.* groups.

>> myself?  I've been thinking about trying out NetBSD...  ;-)

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.)

>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
recent copy.

>-Markus

Additional comments?

(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   [email-masked]; inquiries to [email-masked]

---

From: Olaf Seibert <[email-masked]>

> well ALL dynamic link libraries to be equivalent to statically linked libs.

It seems that not enough people are aware of the Library Public License,
called COPYING.LIB on most gnu ftp sites.

I quote from the preamble:

      For example, if you distribute copies of the library, whether gratis
    or for a fee, you must give the recipients all the rights that we gave
    you.  You must make sure that they, too, receive or can get the source
    code.  If you link a program with the library, you must provide
    complete object files to the recipients so that they can relink them
    with the library, after making changes to the library and recompiling
    it.  And you must show them these terms so they know their rights.

> the GPL requirements.  And LKM is, after all, a sort of dynamic loader.

It can be argued that a dynamically linked executable is in fact
exactly "complete object files", which can be "relink[ed] with the
library, after making changes to the library and recompiling it."

Which brings me to the question of whether it is possible to create a
statically linked executable from a dynamically linked one. I would
think so, but possibly not with current utilities. A quick try on
Linux on a pc didn't give any satisfactory results. And if this is
really impossible, you can distribute a binary pre-linked (ld -r),
and have the installation procedure link the final executable (static
or dynamic, per the user's choice).

And personally, I don't find the concept of the GPL that bad. Most of
my recent AmigaOS software is GPLed, just because it is (supposed to
be) a discouraging restriction for people who want to make money off my
personal efforts. And if I like, I can always re-release my software
with less severe restrictions. The other way around is impossible:  a
package with no distribution limitations will always remain
distributable without limitations, so re-releasing it more strictly
will only have the effect that people stick to using the older one.

-Olaf.
--
___ Olaf 'Rhialto' Seibert       D787B44DFC896063 4CBB95A5BD1DAA96
\X/ There are no lemurs in this post	      [email-masked]

---

From: [email-masked] (Niklas Hallqvist)

When it comes to LKMs, aren't they just for providing device drivers?
Loadable FSs, or even user-level ones (HURD's translators) is a nice
thought, but it isn't necessary unless you care for speed.  One can
always write a user level FS with a NFS server RPC interface (automounters
do this I believe).  Frank, I'll soon be uploading the NetBSD ADOSFS code
anyway, you can snatch it then and work away on r/w support if you want to.

Niklas

---

From: [email-masked] (Chris Hopps)

> library, after making changes to the library and recompiling it."

Hmm I don't know much about the GPL however I can tell you that LKM's
might as well be executables.  If LKM's are covered by the GPL then
the GPL is broke.  An LKM is loaded just like a binary, it passes some
stuff to the kernel to let the kernel know how to call it.  Sounds
like a executable with an exec header to me.

> personal efforts. And if I like, I can always re-release my software

The GPL does no such thing.  On the amiga where the practice of not
selling source abounds in the commercial market, the GPL happens to
seem to have this side affect.  However Many companies sell GNU software.

> -Olaf.

Chris.

---

From: [email-masked] (Ty Sarna)

> thought, but it isn't necessary unless you care for speed.  One can

The current LKM implementationallows for loadable device drivers,
filesystems, system calls, executable file formats, and "other".

There's no reason NOT to take advantage of the speed of LKM vs local NFS
server, and since ADOSFS is written for a vfs interface, it'd be a lot
of work to convert it to an NFS interface. However, it can be converted
to a LKM with very little effort -- look in /usr/share/misc/lkm (I
think), which includes an example conversionof an older version of
kernfs to a LKM.

---

From: Olaf Seibert <[email-masked]>

[email-masked] (Chris Hopps) wrote:
> [Olaf Rhialto Seibert, i.e., me, wrote:]

Note that I'm talking here about dynamically linked executables (which
need some LGPL-ed library), not about LKMs which are themselves covered
by the GPL. The cases may be somewhat similar, but aren't.

> seem to have this side affect.  However Many companies sell GNU software.

I suppose that those companies really sell the support and/or the media
on which the software comes, and throw in the actual software for free.
If not, their clients are rather stupid to pay for something that's can
be had for free. But for the support they certainly deserve to be paid.

-Olaf.