On Thursday, February 1, the Free Software Foundation Europe (FSFE) is
releasing a new license and with it an
offer to help FOSS projects deal with copyright issues.
The license is called the Fiduciary License Agreement (FLA), and it's a new
type of copyright assignment agreement, designed to be effective
internationally, whereby a project with many authors can designate FSFE or
a single organization or individual as the copyright holder, while
maintaining complete autonomy as far as project management otherwise.
Projects may apply to be accepted by FSFE's Fiduciary Project, whereby
copyrights and the responsibility to protect and enforce them are turned
over to FSFE. Bacula.org and OpenSwarm are examples of projects already
accepted into the program. You can see that version of the FLA
Alternatively, projects can use the newly released license, choosing
another entity - such as a foundation it sets up itself - or designating one
individual to hold the copyrights. FSFE's Freedom Task Force is
willing to help projects with that too as far as sharing insights and their
What need does the FLA license fill? I see several. First, it's
international, not US-centric.
Second, maybe you don't have a lawyer on call. Maybe
you are among those who just don't want to think about legal things and or
realize you are not equipped financially or legally to handle that task
yourself. Then you may wish to apply for the FSFE's Fiduciary Project.
You retain rights to the management of the project. But they have the
headache of license compliance enforcement.
Third, it's of interest to projects that have more than one author and are
concerned about the future (what happens if one of the authors dies,
leaves the project, etc.?) but for any number of reasons the authors
don't want to assign copyright to the Free Software Foundation or don't
want to be a GNU project under that umbrella. In countries where such
terms are allowed, it's designed to "be
temporally unlimited" so once the agreement is signed, future
contributions, such as patches, are covered.
An important purpose of the license is to ensure project survival. Shane
Coughan, coordinator of the Freedom Task Force confirms that one goal is to
make sure people think about and plan for the possibility that a project
might have to withstand a legal attack, but as to which of the two ways to
use the license a project should choose, he says that FSFE is neutral:
Deciding which approach is best for a project depends on many different
factors and always boils down to individual circumstances. Ideally,
organsations handling these issues should be non-profit and have a clear
primary focus on Free Software.
Do you have to choose the GPL or LGPL to make use of the license? Coughan:
The FLA allows fiduciary activity with all types of Free Software
licenses, though naturally the GNU GPL is our preferred license.
There is a list of Free Software licenses here.
Some issues you may wish to consider: The FLA is a one-time copyright
assignment (or in countries where that isn't possible, like in Germany,
Austria, Slovenia and Hungary, an exclusive license grant) worldwide.
The grant reads that the beneficiary assigns the following rights:
a) the right to reproduce in original or modified form;
b) the right to redistribute in original or modified form;
c) the right of making available on data networks, in particular via the
Internet, as well as by providing downloads, in original or modified
d) the right to authorize third parties to make derivative works or to work
on and commit changes or perform this conduct themselves.
There are countries where you can't assign copyright in a future work,
France, for example. In such a country, I'm told a project would need to
work out a strategy to deal with that restriction. As just one example,
authors might assign each patch as it is contributed.
The authors' "moral or personal rights remain unaffected" by the agreement.
Also, "modifications that are not derived from the subject matter and that
have to be regarded as independent and original software" are excluded from
the agreement. In some countries, an employer is deemed
to be the owner of the rights on materials developed by an employee in
the course of his or her employment, unless the parties have agreed
otherwise, so there is language that authors acknowledge that he or she is
aware of that and
"warrants, represents and guarantees" that the materials are "free of
any of his or her employer's exclusive exploitation rights."
What FSFE, or the designated entity, gets is the authority to "enjoin third
parties form using the software and forbid any unlawful or copyright
infringing use of the Software, and shall be entitled to enforce all its
rights in its own name in and out of court." The authors keep a
"non-exclusive, worldwide, perpetual and unrestricted license in the
Software," which includes all the rights, listed above, and FSFE or the
entity grants the authors "additional nonexclusive, transferable license
to use, reproduce, redistribute and make available" the software "as needed
for releases of the Software under other licenses."
Some may not feel comfortable with any copyright assignment, but with
projects with many authors, it's a matter of deciding which kinds of
problems you'd rather deal with. The Linux kernel specifies "GPLv2 only" to
keep control over licensing decisions. The same kinds of concerns that
might come to mind with regard to a license will likely also be considered
when it comes to a copyright assignment to another entity. On the other
hand, that same restriction is what left the kernel in a position where it
would be a great deal more difficult to upgrade the license even if desired.
itself says this:
FSFE shall only exercise the granted rights and licences in
with the principles of Free Software. FSFE guarantees to use the rights
and licences transferred in strict accordance with the regulations
imposed by Free Software licences, including, but not limited to, the
GNU General Public Licence (GPL) or the GNU Lesser General Public
Licence (LGPL) respectively. In the event FSFE violates the principles
of Free Software, all granted rights and licences shall automatically
return to the Beneficiary and the licences granted hereunder shall be
terminated and expire.
Some questions come to mind. What principles, precisely? How would you
know when they are violated if they are not listed? We certainly have some
guidance. The Free Software Foundation Europe is committed to following
principles. The Free
Software Foundation Europe (FSFE) is a non-profit and (in some
countries) a charitable non-governmental organization dedicated to Free
Software as in freedom, so that restricts what it can and can't do. Their
principles are listed here and
in a longer version here.
I would assume, then, that a violation of the principles of Free Software
would be any action undertaken with the intent to violate one of the famous
four software freedoms. But if one has concerns about assigning copyright,
then it's something to factor in to the decision. Legally, FSFE could do
things it almost certainly never would, such as relicense. If you have
control issues, the best thing would be to seek legal advice. That's
always good advice anyway. And some may choose to set up their own
foundation, to establish certain ground rules of their own, for that very
reason. The choice is yours.
Finally, if you choose to assign copyrights to FSFE, German law applies to
the agreement as the default, unless otherwise negotiated, and any
conflicts would have to be settled in Munich.
The license is being released under the GNU Free Documentation License
(GFDL) and the Creative Commons Attribution/Share-alike (CC by-sa)
licenses. The FLA was written by Dr. Axel Metzger (ifrOSS) and FSFE in
consultation with other international legal and technical experts, and the
final version was then compiled by Georg Greve, president of the Free
Software Foundation Europe (FSFE) and Shane M Coughlan based on feedback
provided by Dr. Lucie Guibault of the Institute for Information Law in the
Netherlands. The final text of the license is expected to be released on
Comments (1 posted)
This series is all about making small systems, from the kernel on up. In
the first part
I covered the
TinyLinux project and its eventual
integration into the kernel to help reduce kernel sizes for small systems.
In the second part
, I looked
at the use of the Initramfs and its role in
providing a root file system (directly or indirectly) for an embedded
Now it's time to look at getting applications and utilities into the
system, still keeping an eye on size. The most direct approach is to use
as few utilities as possible, even replacing /sbin/init with a single
application. This is possible in very small systems but, generally speaking,
if you only have a single application to run you probably didn't need the
complexity of a multitasking system like Linux to run it anyway. There are
other, smaller operating systems that might be better suited in that case.
There are a number of ways to keep application layer tools small.
If you have multiple applications and/or require the facilities in Linux,
then you can (and should, for production systems) consider stripping your
binaries of all symbols. The symbols are useful for debugging purposes but
won't be of much value to your users. Additionally, using compile-time
features to reduce size is another option, and will be the focus of the
final article in this series. For now, we'll consider yet another option:
using a compressed file system.
Compressed File Systems
File systems provide the structure for managing files on storage media,
such as disks or tapes. While a device driver knows how to get data to and
from those devices, file system provide the logical structure of that data.
There are a huge number of file systems types, ranging from the standard
ext3 you'll find on many Linux systems to parallel and clustered
file systems, to steganographic file systems that can both encrypt and hide
data on the media.
(Note that Wikipedia has a nice long list
of file systems).
A compressed file system is one that uncompresses data as it is retrieved
and may or may not compresses data as it goes into the storage media.
Working with compressed files is an obvious benefit for saving space on
small systems. The decision to use a compressed file system is usually
based on the storage media you'll use in your system. A ram-disk based
system, for example, might copy data from flash into the ramdisk. Since
RAM is essential for system operation the size of the ram disk would
probably be best kept small. Compact flash or hard disk based systems, on
the other hand, offer more storage but may still be too small to fit all
the required files without some sort of compression.
While compressed file systems offer you more space for files, they also may
affect performance. There may be unacceptable overhead in managing the
decompression of large files at run time. And compressing files on the fly is
computationally expensive; random writes of compressed data is
difficult to achieve. Therefore it is far more common for compressed
file systems to be read-only.
Compressing data is a common practice for live CD distributions, which use
compression to squeeze a more complete distribution onto the limited size
of a CD or DVD. But many of the live CD distributions don't actually use a
compressed file system, instead using an conventional file system image made
up of compressed blocks which are uncompressed when read using the "cloop",
or compressed loopback, device. But this isn't a compressed file system. It's a
block level device handling compressed data.
The Knoppix distribution popularized the use of cloop
when its author, Klaus Knopper, picked up support of the driver. Many
other live CDs followed suit. One advantage of using this kind of
compressed image is that, since the blocks are compressed independently, it
is possible to seek to specific blocks without uncompressing all the
blocks. The disadvantage of such a device is that the entire image must
fit into memory in order to be uncompressed.
An example of a real compressed file system is CramFS, a file system popular
with embedded users of the 2.4 kernel for use with the initrd image. This
file system actually has compressed files with uncompressed metadata. The
files are placed in the file system from a standard directory using the
mkcramfs program, which compresses the files one page at a time. This is
done, for example, when creating an initrd image.
Another example of a compressed file system is e2compr. This is actually a
set of patches to make the well known EXT2 file system handle on-the-fly
compression and decompression. It supports both 2.4 and 2.6 kernels, but
has not been submitted for inclusion in either because of the complexity of
the patches. As with CramFS, metadata in e2compr is not compressed.
A more recent (and more actively supported, the last updates coming in mid
January 2007) compressed file system is SquashFS. SquashFS is a kind
successor to CramFS because it aims at the same target audience while
providing a similar process for creation and use of the file system.
What makes SquashFS an improvement over CramFS is best stated by Phillip
Lougher in a linux-kernel mailing list post:
"SquashFS basically gives better compression, bigger files/file system
support, and more inode information."
Both SquashFS and CramFS use zlib compression. However, CramFS uses a
fixed size 4KB block while SquashFS supports from 0.5KB to 64KB. This
variable block size allows for much larger file systems under SquashFS,
something desirable for complex embedded systems like digital video
recorders. Also SquashFS
supports compression of both the metadata and block fragments while CramFS
does not. And, while CramFS is integrated with the kernel source, SquashFS
is not. It comes as a set of kernel patches and the driver module.
The CELinux Forum provides some
comparisons of SquashFS against other file systems (compressed
Another compressed file system is JFFS2, the Journaling Flash
version 2. It was designed specifically for use with both NOR and NAND
flash devices, and recently received an update via David Woodhouse for the
NAND flash memory being used in the OLPC project. JFFS2 is actually a bit
more sophisticated than SquashFS because it provides mechanisms for
plugging in different compression algorithms, including not using any
compression at all. But unlike SquashFS, JFFS2 is integrated into the
So if you're building an embedded system with flash storage, wouldn't you
be better with JFFS2? Not necessarily.
to the OpenWRT project, which uses both SquashFS and JFFS2,
SquashFS provides better performance than JFFS2. Additionally, at least
in the case of the few files that need to be updated for a production
version of the project, there is little advantage to using a read/write
JFFS2 compressed root file system with respect to the performance hit it incurs
vs a read-only SquashFS root file system used with a writable JFFS2 file system
for stored files.
JFFS2 is a read/write file system while SquashFS is a read-only file system.
A runtime system very often needs to write to its root file system.
Imagine making updates to /etc/hosts, for example, as you might with a
embedded video recorder client trying to access a server backend on a local network.
If writing to the file system is required for an embedded system, how could
you use SquashFS at all?
Some projects, like OpenWRT, use a hybrid system that uses a read-only root
file system mixed with a read/write file system for saving files. In such a
hybrid you might use special configurations or modified applications to
access read/write file systems, but that doesn't help if you need write
access to /etc/hosts on a read-only file system. What you need is a method
of having parts of the directory structure writable while other parts are
read-only. What you need is a stackable file system like UnionFS.
Using UnionFS: BusyBox and SquashFS together
UnionFS is a mechanism for mounting two directories from different
file systems under the same name. For example, I could have a read-only
SquashFS file system and a read/write JFFS2 file system mounted together
under the root directory so that the JFFS2 would be /tmp and
/etc while the SquashFS might be everything else.
So how might you use this with a compressed file system and our BusyBox
based utilities we created in the last article? First, we build our kernel
with SquashFS patches and then build the UnionFS driver as a loadable module.
Next, we build BusyBox with all the runtime utilities we need and install
the result to a local directory on the build machine, let's call it
"/tmp/busybox". Next, we package those files into a compressed SquashFS
mksquashfs /tmp/busybox /tmp/busybox.sqfs -info
This command takes the contents of /tmp/busybox and compresses it into a file system
image in /tmp called busybox.sqfs. The -info option
increases verbosity, printing the filenames, original size and compression
ratio as they are processed.
We then create an initramfs with another build of BusyBox that has only
minimal utilities - enough to do mounting of the loopback device and loading
kernel modules, plus the UnionFS module we built previously (which we
manually copy into the directory after we rebuild BusyBox). We might add
support for other devices like a CDROM if we store the SquashFS file there
or JFFS2 and support for flash memory if we store the SquashFS file there.
At runtime, I need a writable file system to go with my read-only SquashFS
file system. I'll use the tmpfs file system which puts all the files I'll
write at runtime in virtual memory. In my init script for my initramfs, I
mount -w -t tmpfs -o size=90% tmpfs /.tmpfs
The overlay directory will be used to store data written by my embedded
When you boot your 2.6 kernel, you'll have a BusyBox based initramfs with
an init script and your SquashFS file system (or a way to get to that
file system via commands in your init script). I'm mounting
the busybox.sqfs file from the root directory of a CD over the loopback
device onto a directory in my initramfs, so I add the following to the init
mount -r -t iso9660 /dev/cdrom /.tmpfs/.cdrom
losetup /dev/loop0 /.tmpfs/.cdrom/root.sqfs
Then I can mount the loopback device as a SquashFS file system to another
directory I've created in my tmpfs:
mount -r -t squashfs /dev/loop0 /.tmpfs/.sqfs
UnionFS mounts multiple directories, in either read-only or read-write
mode, onto a single directory. In the init script, I place three
directories side by side under a single UnionFS directory:
mount -w -t unionfs -o \
What this does is place all three directory structures, which are referred
to as branches under UnionFS, under /.union; any conflicting directory
names are resolved by taking the first one found, searching the branches left to
right. So if there is an /.tmpfs/.overlay/etc/hosts (a file we've
created at runtime, for example), it takes precedence over
With this command, when you write to /.union (which later becomes the root
directory due to a switch_root in the init script), the writes go to the
read/write directory which is on the tmpfs file system. But this writable
space is in memory and won't survive reboots. If you need to save data
between boots, you could mount a compact flash drive under /.tmpfs/cf and
use that instead of /.tmpfs/.overlay in the previous mount command.
Which directory gets the write if there are two read-write branches?
UnionFS uses "copy-up", which causes any attempt to write to a read-only
branch to be written to the next read-write branch on its left. Imagine
creating a SquashFS for /etc, one for /var and one for everything else in
your root partition. Then if you had 2 compact flashes you could use one
for writes to /etc and one for writes to /var simply by ordering these
correctly when you mounted them under the UnionFS file system.
UnionFS is considered by some to be too buggy for production use, though
I've never had much trouble with it when building live CDs. If you
experience problems using UnionFS, you might consider AuFS
as an alternative. AuFS started out as a
rewrite of UnionFS but has since evolved into its own file system. SLAX, a
Slackware based live CD that originally used UnionFS, has migrated to AuFS.
In fact, a bug bounty was offered by SLAX for a bug and the winner of that
bounty, Junjiro Okajima, is the author of AuFS.
Next in the series: uClibc
This long running series (it's taken me awhile to write each of the three
articles so far) has one piece left: using uClibc to reduce program size.
This is a reduced size version of the standard glibc library, specifically
built for small footprint systems.
Comments (18 posted)
The first announced LWN Weekly Edition was published on January 29, 1998 -
though we had quietly put out a test
the week before. So, it seems, we just had our ninth birthday.
We could never have imagined we would still be at it after this many years
- but we have no intention of stopping now. Thanks to all of you for
keeping us going for so long.
Every now and then, an LWN reader notes that there have been no "state of
LWN" postings in recent times. There is a reason for that: LWN is supposed
to be about the Linux and free software community. LWN talking about
itself just seems less interesting, somehow.
There is another reason, however: things simply have not changed that much.
The number of subscribers grows very slowly; subscription counts still have
not reached a level where LWN can truly be said to be paying for itself.
We would like to change that, and make LWN better in the process. To that
end, we would like to get a better handle on what our subscribers think of
For our subscribers: if you could please take a few minutes and give us your input on the ups and downs of
LWN, we would more than appreciate it. The survey will remain open until
February 8. For those coming after that date, you can see what
answers we got by going directly to the results page.
Thank you for helping us to make LWN better.
Comments (4 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Who owns your domain?; New vulnerabilities in bind, cvstrac, rmake, and ulogd.
- Kernel: A summary of 2.6.20 API changes; Network namespaces; Fibrils and asynchronous system calls.
- Distributions: gNewSense makes sense; Foresight Linux 1.0, LFS LiveCD 6.2-5, openSUSE 10.2 Live DVD; Ubuntu Live: Call for Participation; openSUSE-community.org; Metisse; Congratulations and thank you from Red Hat; NimbleX
- Development: The release of KDE 3.5.6,
new versions of SQLite, dbtoy, oyepa, Samba 4, Bogofilter, Sussen,
Drake CMS, Midgard, eSpeak, Azureus, Kicad, RRDtool, GARNOME,
Eris, MaNGOS, K-3D, wxPython, Wine, Christine, Goggles Music Manager,
PiTiVi, Qexo, KDevelop, NetBeans, Valgrind.
- Press: The GPLv3 debate, Effects of Fedora user data collection, PR pit bull takes on
open access, regional Ruby conferences, PDF to become ISO standard, Diebold
Linux PCs for Brazil, Click and Run for more distributions, state of the Linux desktop, SourceKibitzer tracks open-source Java, Microsoft dominates South Korea, visual timeline of Microsoft-Novell.
- Announcements: OSS student lab in Vietnam, Blackboard and EpicRealm patents reviewed,
LiMo Foundation, MyTellyHD Media Center, Novell open-source identity services,
SugarCRM for Ubuntu, Sun and Intel partner, LPIC-1 training online,
KDE PIM coverage, 2007, GCC Dev Summit CFP, International PHP Conf CFP,
TiE Open Source Summit.