Academic Free License 2.1 ?

Markus Laire malaire at
Mon Dec 4 06:23:54 PST 2006

after reading the Academic Free License 2.1, which is used by BLFS,
and also checking the debian-legal thread[1] about it,
I don't quite understand why it's used in BLFS.

Two relevant quotes from a message[2] on debian-legal:

> > 3) Grant of Source Code License. The term "Source Code" means the
> > preferred form of the Original Work for making modifications to it
> > and all available documentation describing how to modify the
> > Original Work.
> This is problematic, IMHO: if I want to distribute "Source Code",
> have I to ship *every* single piece of available documentation that
> describes how to modify the Original Work? Even independently written
> documentation?

That seems really strange.

> > 9) Acceptance and Termination. If You distribute copies of the
> > Original Work or a Derivative Work, You must make a reasonable
> > effort under the circumstances to obtain the express assent of
> > recipients to the terms of this License.
> This is my main concern: distributors must obtain express license
> acceptance assent from recipients.

Here the AFL seems to be far more restrictive than
the "Attribution-NonCommercial-ShareAlike 2.0" license also used by
BLFS. That license doesn't require me to get express license acceptance
from recipients, which IMHO is quite a hurdle.

The recent message[3] in this list said that:
> In addition to the main license, I also feel that the books should
> dual license the code (scripts and config files) in the the books
> with a very open license such as the AFL currently in BLFS or a BSD
> type of license. The reason is to basically leave the instructions
> unencumbered.

IMHO the AFL clearly IS NOT a "very open license". If the intent is to
leave the instructions unencumbered, some other license should be
chosen instead of the AFL.

Currently the instructions seems to be more encumbered than
the descriptive text, which seems to be exactly the opposite of what
was recommended in that message[3].


Markus Laire

More information about the blfs-dev mailing list