gnewsense-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gNewSense-users] KFV: how to handle COPYING?


From: Bake Timmons
Subject: Re: [gNewSense-users] KFV: how to handle COPYING?
Date: Wed, 25 Jun 2008 17:01:25 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

> My point is that:
>
> 1) according to KFV Flow (as found in
> http://wiki.gnewsense.org/Kernel/DocumentingYourWork) this file is
> non-free and a bug should be raised for it. Most of know that this
> doesn't apply to COPYING, but it might confuse newbies wanting to
> help.
>
> 2) kfv.el doesn't provide for these kinds of files. COPYING is
> non-free [1] and the script doesn't distinguish between software and
> the rest. So technically the column "Percentage of section certified
> free" would be 0%. There should probably be an option to mark it as
> "N/A" or something.
>
> 3) the summary script might have problems handling values for that
> column other than those we have used up to this point.
>
> So I'm not saying there's a problem with freedom. I'm saying that
> there are (possibly) problems with the tools we use to verify the
> freedom of files and I would like to help solve those problems or find
> a temporary workaround for them.
>
> [1] "... this license document, but changing it is not allowed." So
> those terms do apply to the the file, not only to the license.

This concern touches on our table format, of course.  My feeling is
that we can already address it with footnotes.  Mark COPYING as 0%
free and as reported ("Y") -- thanks to Sam.  Ideally, a footnote
should point to a web page that explains why non-free materials would
remain in the distribution and not be put into the BTS.  I think this
issue goes beyond the typical footnote just because it is so
confusing--at least to some newcomers.

Thus, summary scripts would be OK, since COPYING would appear as any
other non-free item--except having a comment "waiver" (footnote).
This would be less ambitious than what Sam suggests, since scripts
would still be "ignorant" about non-free exceptions.  However, there
is nothing preventing footnotes from being analyzed to provide such
"knowledge" in the future.  Indeed, there might be additional bits of
knowledge in footnotes that contribute to automated uses.

The new version of kfv.el coming out already has a revised
"license choices" file and, in the spirit of Sam's suggestion, I will
make an explicit accomodation for non-free docs.  (Granted, it is
understood that we would treat non-free license text differently from
a non-free manual.)  Regarding changes, I have tried to be careful to
make changes to those choices not too distruptive to our "muscle
memories" (habits).

kfv.el does nothing special regarding footnotes, since I have assumed
they are rare and easy enough to just type in the generated markup.
(Of course, we can add features related to it, especially given a
clear motivation and interface.)

What do you think?

BTW, here is the latest version of the license choices string in
kfv.el:

0: GPLv3
1: GPLv2 or later
2: GPLv2
3: GPLv1
4: LGPLv3
5: LGPLv2.1
6: LGPLv2.0
7: GFDL v1.2
8: GFDL v1.1
9: Modified BSD license (3-clause)
a: FreeBSD license (2-clause)
b: OpenIB.org BSD license
c: GPL / Modified BSD license
d: GPL / FreeBSD license
e: GPL w/in kernel; otherwise Modified BSD license
f: GPL / MPL
g: GPL / FreeBSD license
h: X11 (aka MIT) License
i: CPL 1.0 / Modified BSD license / GPL
j: GPL + FreeBSD license w/in kernel; otherwise FreeBSD license
k: Public Domain
l: No license, so assumed to be GPLv2.
m: GPL (no version specified)
n: GPL / X11 (aka MIT)
o: GPL and additional rights
p: Other software license (free)
q: *CUSTOM LICENSE TEXT INSIDE ASTERISKS*
r: Other software license (non-free)
s: Other documentation license (free)
t: Other documentation license (non-free)


This tries to accommodate our habits and typical choices.  I am for
whatever most people prefer--please make your wishes known.  (These
preferences and many others are already much easier to customize in
the upcoming kfv.el file.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]