Licensing/Structure

Mark Stone mstone at valinux.com
Tue Sep 5 13:38:37 PDT 2000


On licensing, you have a big choice to make right at the start, and then
some smaller choices. The big choice is this: are you concerned that
someone might take your code and put it to proprietary use in a way that
would damage your project or other open source projects? If the answer is
"No", you're not worried about that, then you want a BSD style license. If
the answer is "Yes", you are worried about that, then you want a GPL style
license.

If you opt for a BSD style license, then the particular choice matters
little. All such licenses will mark the project as open source, none will
restrict proprietary derivations, and you have no headaches to worry about
if you want to build a profile that has options for proprietary code.

If you opt for a GPL style license, you're going to have to work: "You are
in a maze of twisty little licenses, all alike."

GPL, LGPL, and MPL are your main choices. The only area of possible
concern is if you want a profile that will add in proprietary code. 
MPL makes life fairly easy. It marks a body of work by file, and each file
is either open source or proprietary. If you start with an open source
file and modify it, then your modifications must also be open. This
coexists pretty nicely with proprietary code when necessary.

The LGPL is probably the best choice _if_ it will suit your purposes. With
the LGPL you have total buy-in from the open source community, and you get
some peaceful coexistence between open and proprietary, depending on
circumstances.

So let's consider the circumstances. If a profile only works from source
code, then worries about proprietary software are probably irrelevant.
Suppose, for example, that someone is interested in building an Oracle
server profile. I think this would have to work thus:
Oracle source code + Linux source code -> ALFS Oracle profile -> LFS
system

All open source licenses are about distribution. Since Oracle doesn't
distribute its source code Open Source, anyone possessing the Oracle
source code could not possess it for purposes of distribution, and hence
the license of the profiler is a non-issue.

This might be somewhat limiting for ALFS, though. Not many people will
have access to proprietary source code. Is ALFS, then, going to be
limited, for all practical purposes, to open source code? That might be
the right answer. But note that that's a technical decision, not a
licensing decision (yet). In other words, technically, does ALFS support
only builds from source, or will it support builds including some
precompiled binaries as well?

If one can start with, say, an Oracle binary and pump it through an ALFS
profile, then you do end up with a bit of a licensing issue. ALFS is a
front end to a compiler, among other things, and so the result is a
"derived work". This puts you right smack in the middle of the demarkation
between GPL and LGPL. I'd favor LGPL in this case to avoid problems. Even
safer would be just to stick with MPL.

So, in summary, you need to figure out two questions:
(1) Are we worried about a proprietary hijack of ALFS code?
(2) Does ALFS build only from source code, or can it build from some
binaries?

Here's the licensing grid I'd recommend depending on your answers:

               Worried about hijacking   |   Not worried about hijacking
Building from 
source only          GPL, LGPL or MPL                BSD

Allow build from 
some binaries        LGPL or MPL                     BSD

Personally, I'd just go with the BSD license. It's less complicated, more
flexible, and I don't think you're really worried about someone stealing
your code and forking off a proprietary project.

The more interesting question is what to do about source code versus
binary. I've always thought that what makes LFS different from a
distribution is that everything must start from source code. A
distribution can and often does include binary only, even where the source
code is available. Working strictly from source code keeps LFS at its
purest. Furthermore, if LFS sticks to official standards like LSB, a
precompiled binary should just work, right? All the libraries are where
the should be, all the directories are where they should be. If something
breaks with a binary like that, then it has to be because of a problem
with the binary program itself. I note that Netscape and all the games
from Loki -- good examples of popular binary-only code -- come with their
own installers. If LFS builds a clean base system, then those installers
should just work. No need for special profiling on the part of ALFS.

That's my .02 worth.


Mark

---------------------------------------------------------------------
 Mark Stone                                            O | S | D | N
 mstone at valinux.com                  Open Source Development Network
 (408)542-5745                        Director of Developer Services







More information about the alfs-discuss mailing list