xLFS Book Licenses
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!]
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.
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
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.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
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