Matthew Burgess wrote: > 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.
It is true that TLDP triggered this issue, but the motivations are a bit more than that. If we wanted, we could get a lawyer and write our own with proper legal advice, but that is expensive and unnecessary when recognized open source licenses are available. I think the real motivation is that we want the books used in a certain way and not allow someone to use our work in a way we don't approve, > 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. IMO, the requirements are: 1. Only publish commercially with permission. 2. Provide appropriate acknowledgment if the book or portions of the book are used in other non-commercial works. 3. The result of following the book is unrestricted by us. The restrictions of the packages used remain with the authors of the specific packages used. 4. The extraction of scripts and configuration files should be permitted for any purpose. >> 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. What protection do you think our code needs? IIRC, many of our init scripts are based on other distros. Most of what we do is CMMI, sometimes with modifications to the code with patches and seds. Most of the scripts and config files come from the packages. For the most part we just customize the switches and configuration files so that everything works together properly. I think its a stretch to say that we copyright these chunks. What can be copyrighted is the way everything is put together, i.e. the books themselves. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
