[kde-guidelines] Licenses

[Frans Englich]

On Friday 01 October 2004 10:25, Lauri Watts wrote:
> Hi folks,
>
> We need to discuss the licensing of the new guides.   I guess I'll lay out
> the issues roughly and the authors and maintainers should probably decide
> for the best.
>
> First, here's the rundown on the current licensing policy for KDE
> documentation (note, some of the concerns noted here are not relevant,
> since these guides are not to be distributed with the project sources. 
> Also note I'm no lawyer, that's just something I wrote and is as yet rather
> unreviewed to explain our choice of FDL.  In particular, the explanation of
> invariant sections is missing a chunk - that you only need to change our
> license text to the "with invariant sections" bit if you *use* the text
> marked as invariant)
>
> Further points:
> * It is possible to license each *section* of documentation differently, if
> necessary.  It's much easier, from a managing your assets point of view, if
> everything is in fact licensed the same though.

Hopefully we shouldn't need that -- the FDL should be fine(and otherwise the 
maintainers surely will make some noise).

> * It would be extremely useful to have a list of things we might want to
> quote from, and the license terms they are available under, since this
> could influence the decision here.

Quoting and referencing is no problem because it's allowed. I don't know the 
exact legal details, but it's cool, AFAIK.

However, if we decide to do straight of copies, that requires legal notices as 
per the FDL, of course. I checked the legal notice of Apple's HIG once, and 
IIRC it was the usual corporate "our army of lawyers will hunt you down" 
notice.

As I've expressed in the early threads on kde-usability, I am skeptic about 
putting rationales in the HIG. In short: We got much to write; it's 
impossible to do a complete discussion, and that means it won't cover certain 
areas; it's guidelines, not teach-HCI; rationales/motivation opens up for 
questioning; it easily becomes verbose(I know about the CSSs); we shouldn't 
need rationales, because it's a rule book. For example, I don't see where 
quoting Apple's HIG would be useful -- nobody cares, it's about what the 
crazy KDE Usability Team have decided is law, that then Apple's HIG perhaps 
says the same is irrelevant.

I've heard one argument I found reasonable, and that was on the Gnome 
usability list: When people know why something should be in a certain way, 
they can better determine when to diverge from the guidelines. But I still 
don't think it's worth the negative sides I claim there is.

For editing-guidelines I started to write, it said:
"Don't discuss rationales behind a guideline or /why/ it is there because it's 
impossible to do completely, and inappropriate to do it in it's full length, 
which on top is necessary in order to avoid confusion."

We obviously have some disagreement here :) The maintainers disagree, so 
there's not much to do about it, and it's also a bit subjective since it's 
about vision -- what one wants to achieve and aim for. 

I don't expect this to be discussed, or followed up.


Cheers,

		Frans