Bruno Haible <[EMAIL PROTECTED]> writes:
> a) Add another option to gnulib that avoids the license changes altogether.
> You would use this option; Jim when making release tarballs would not.
> Drawback: Jim needs a special directory for making release tarballs.
>
> b) Push back the
Paul Eggert wrote:
> > The practical drawback would be that the --symlink option, in the
> > coreutils situation, will copy more files and symlink less files.
>
> That's a serious drawback, at least for the way I work. When I
> develop, I commonly edit the gnulib copies and expect coreutils to
>
Simon Josefsson wrote:
> What about the issue of copying code
> between test code and the library? Then we'd have to talk to the FSF
> every time we want to do that. This is a minor issue though, it
> hasn't occured in practice yet, as far as I know...
It is rare indeed. And when it occurs, ofte
[EMAIL PROTECTED] (Karl Berry) writes:
> Is there a problem with having the LGPL'd files in coreutils?
It's longstanding practice to distribute code in GNU applications like
coreutils under the GPL only, replacing references to the LGPL with
references to the GPL in files taken from LGPLed distri
[EMAIL PROTECTED] (Karl Berry) writes:
> the --symlink option, in the coreutils situation,
> will copy more files and symlink less files.
>
> Is there a problem with having the LGPL'd files in coreutils? Does it
> make any practical difference?
How about adding a --gpl parameter to gnuli
Why not? If we ensure that every user of the gnulib CVS understands it,
If someone comes across a file for whatever reason (eg, casually
browsing savannah cvs), and they see a license statement in that file,
it is obvious that they will assume that that is the license of the
file. When a lice
If we say "look yourself in each individual file", how can the
user trust gnulib?
I agree that an overall statement of what licenses gnulib uses is
desirable, including for the doc files. It's only that I think the
documentation should document the licenses, and (must) not *be* the
licens
Bruno Haible <[EMAIL PROTECTED]> writes:
> Fine with me (although I had a slight preference for putting test modules
> under the same license as the source modules).
I have the same preference. What about the issue of copying code
between test code and the library? Then we'd have to talk to the
Bruno Haible <[EMAIL PROTECTED]> writes:
> But I agree that it can be confusing.
True.
> The practical drawback would be that the --symlink option, in the
> coreutils situation, will copy more files and symlink less files.
That's a serious drawback, at least for the way I work. When I
develop,
Karl Berry wrote:
> Meanwhile, I'd like to ask about this unchanged sentence:
>
> The source files always say "GPL", but the real license
> specification is in the module description file.
>
> I don't understand.
The README and the .texi documentation of gnulib say that the license
state
Karl Berry wrote:
> + @item doc/
> + Documentation files are under this copyright:
> +
> + @quotation
> + Copyright @copyright{} 2002-2007 Free Software Foundation, [EMAIL
> PROTECTED]
>
> I think it would be better not to state the exact license of the doc
> files here, but
Meanwhile, I'd like to ask about this unchanged sentence:
The source files always say "GPL", but the real license
specification is in the module description file.
I don't understand. Legally, what counts is the license in the actual
source file. You can't point to some other file and sa
+ @item doc/
+ Documentation files are under this copyright:
+
+ @quotation
+ Copyright @copyright{} 2002-2007 Free Software Foundation, [EMAIL
PROTECTED]
I think it would be better not to state the exact license of the doc
files here, but rather give general information, bec
> Shouldn't that be 1.2 at least?
Is GFDL 1.1 with no invariant sections accepted by Debian?
Is GFDL 1.2 with no invariant sections accepted by Debian?
As far as I know, yes. More important for a GNU project (seems to me),
the GNU standards say to use 1.2.
(Of course the GNU standar
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ralf Wildenhues wrote:
>> > + @quotation
>> > + Copyright @copyright{} 2002-2007 Free Software Foundation, [EMAIL
>> > PROTECTED]
>>
>> The minimum copyright year surely would have to be adjusted.
>
> For the documentation purpose here, I think this is
Ralf Wildenhues wrote:
> s/ is //
Done, thanks.
> BTW, was there some convention whether to write directory names with a
> trailing slash? It looks a bit unnatural to me in normal text.
It makes clear that the text is talking about a directory. (*)
> Hmm, standards.texi seems silent about this
Hello Bruno,
* Bruno Haible wrote on Mon, Jan 15, 2007 at 12:19:48PM CET:
>
>
> + More precisely, the license specification is in the module description
> + file applies to the files in @file{lib/} and @file{build-aux/}. Different
> + licenses apply to files in special directories:
s/ is //
Paul Eggert wrote:
> > The argument for making it LGPL is that an LGPLed package can include
> > them without making a complicated license statement like "the library
> > source is under LGPL, the testsuite under GPL, and the doc under GFDL".
>
> I'm afraid we've already lost that battle as far as
Bruno Haible <[EMAIL PROTECTED]> writes:
> The argument for making it LGPL is that an LGPLed package can include
> them without making a complicated license statement like "the library
> source is under LGPL, the testsuite under GPL, and the doc under GFDL".
I'm afraid we've already lost that bat
Under which license should tests module be?
If I have an LGPLed module, should its -tests module be LGPL or GPL?
The argument for making it LGPL is that an LGPLed package can include
them without making a complicated license statement like "the library
source is under LGPL, the testsuite under GP
20 matches
Mail list logo
