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://creativecommons.org/licenses/by-sa/2.5/legalcode).
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
diff(1)ing.
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
(http://lists.ibiblio.org/pipermail/cc-licenses/2006-August/003855.html),
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.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
