Bruce Dubbs wrote:
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.
Agreed. I'd really like us to use an existing license, if at all
possible. It reduces the legal costs on both our side and our readers side.
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,
OK, so we just need to agree on what we'd approve and what we'd
disallow. Easy, eh? :-)
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.
This goes against the spirit of Free Software, IMO. I *do* understand
the reasons for wanting to do so, but GPL and BSD packages have survived
without such restrictions so far, why shouldn't LFS? Maybe books are
different from software, but at the moment I'd be in agreement with Dan
Nicholson; we should aim for as free a license as possible. The LFS
project hasn't made much money at all from the sale of hard copy books,
as far as I'm aware. There is no reason, therefore, to believe that
someone else could make much money from it either. So, what do we lose?
The ability to publish via TLDP for one.
This reminds me of a recent post by Alan Cox at
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.2/0882.html - '.If
your product differentiator is "used a different ten cent ethernet chip"
then remind me not to buy your stock 8)'. If someone takes the LFS
book, and publishes it as-is, there is *no* product differentiator, save
for it being in hard-copy. Why would someone choose to buy that book
rather than one published by LFS? What I'm getting at is ascertaining
a) the risk of someone publishing the book with a commercial motive and
b) the probability of them actually profiting out of it.
If there's no commercial value to it, then there is nothing to protect,
commercially speaking.
2. Provide appropriate acknowledgment if the book or portions of the
book are used in other non-commercial works.
Yep, that's a requirement of the CC license. Note that, although we've
improved recently, we have historically had a pretty poor record on
acknowledging our own contributors! We need to work out who our
licensees have to acknowledge though, is it Gerard, each individual
contributor, the LFS project itself? I'd imagine it'd be the copyright
holder, which at the moment is Gerard.
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.
Sounds sane enough, though I don't think we need a specific clause in
the license to stipulate this - the upstream packages' license should be
enough, no?
4. The extraction of scripts and configuration files should be
permitted for any purpose.
Again, no argument here.
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.
Well, maybe "protection" was the wrong word, maybe not. It needs a
legally enforceable license applied to it to ensure our users have the
same freedoms as they come to expect from Open Source software. As with
the book, applying a widely recognized license, such as the GPL, to our
code will help us avoid any potential ambiguities or confusion on the
part of our readers.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
