xLFS Book Licenses

Matthew Burgess matthew at linuxfromscratch.org
Tue Aug 22 11:25:21 PDT 2006

Bruce Dubbs wrote:
> Currently, LFS ticket 1765,
> http://wiki.linuxfromscratch.org/lfs/ticket/1765, suggests that LFS use
> the licenses that are currently in the BLFS book.  Jim, Ryan, and I have
> had some off-line conversations about this and feel it is time to open
> up this discussion to the community.

[This is going to be long...please bear with me!]

OK, before this discussion can be of any use, I really think we need to 
decide on a couple of things.

1) What are the motivations behind the license change?

So far, I can only think of one, which is the fact that TLDP won't 
accept documents that aren't covered by a recognized license.

2) What licensing requirements do xLFS books have?

This is primarily based on the answer to question 1) although xLFS 
developers, editors and the community may wish to have additional 
constraints written into whatever license we choose.

> Jim has pointed out that there are problems with the CC:

[I've reordered the links so the easiest ones to deal with are at the top!]

 > http://zesty.ca/cc.html

I don't see any concerns here that are particular to xLFS.  If Jim, Ryan 
or anyone else has specific issues that are highlighted above it'll be 
easier to comment on them if you could point them out.

 > http://www.satn.org/archive/2003_04_27_archive.html

This argues that the warranties of the CC license are too onerous for 
content authors' because they force them to check everything, including 
quotes, trademarks, etc. to ensure they're not infringing copyrights and 
patents (including those on software, if your jurisdiction happens to 
recognise such ridiculous things).  However, these warranties have been 
removed in more recent versions of the CC license (see clauses 5 & 6 at 

> http://people.debian.org/~evan/ccsummary

This details concerns with CC-2.0, specifically in relation to its 
compatibility with the Debian Free Software Guidelines (DFSG).  To this 
I'll make two general points:

1) Is complying with the DFSG an important criteria for xLFS?  If so, why?

2) CC-2.5 was released in June, 2005.  (As a hopefully useful aside, 
plain text versions of both licenses can be found at 
http://evan.prodromou.name/ccpl/ccpl-by-sa-2.0.txt and 
http://evan.prodromou.name/ccpl/ccpl-by-sa-2.5.txt which allows for easy 

As far as Evan's specific issues with CC go:

- Removing references: Clause 4a. has been reworded.  IANAL so can't 
immediately tell whether Evan's concerns have been addressed or not
- Any Other Comparable Authorship Credit: Clause 4b. remains unchanged 
(save for the version number), so this point remains.
- Anti-DRM clause: The relevant part of clause 4a is unchanged.  I don't 
quite understand Evan's argument here though, considering clause 2 of 
GFDL (http://www.gnu.org/copyleft/fdl.html), which was recently 
considered Debian-Free (http://www.debian.org/News/2006/20060316), 
contains an Anti-DRM clause.  Again, IANAL, so there may well be a 
reasonable difference between the two clauses that makes the GFDL free 
and the CC non-free.  Also note that work on the Anti-DRM is still 
ongoing in CC land 
so CC-3.0 might yet get the Debian seal of approval.
- Trademark Restrictions: Unchanged between CC-2.0 and CC-2.5.  This 
particular concern is not valid for the xLFS books though.  As per
http://www.tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html, "the 
full text of the license must be included in your document".  Therefore, 
the non-license text that Evan has a problem with wouldn't be in our books.
- I've not countered any of the arguments relating to the 
"Non-Commercial" variation of the CC license as it directly conflicts 
with the TLDP manifesto.
- I've not countered any of the "No Derivatives" variation of the CC 
license as I don't think it is in the spirit of the Free Software 
Community that we are a part of and take so much from.

> Ryan suggested the GPL for the code, but that has a lot of overhead that
> I don't feel is necessary.  For instance, there would be a need to put
> relatively long GPL statements in each file in the bootscripts and the
> need to include extra copyright files with the jhalfs output.

That's a really trivial hurdle to overcome, and well worth it 
considering the protection it gives our code, IMO.



More information about the blfs-dev mailing list