Brett Smith <[EMAIL PROTECTED]> writes:
> I'll go ahead and take that to RMS, then, so we can hammer out
> something final.
Thanks.
> if you all would prefer, I can just send the final text back to this
> list once the dust settles.
That would be fine. If some interaction is needed please feel
On Thu, Oct 18, 2007 at 12:45:03AM -0700, Paul Eggert wrote:
> That won't work well, because it's common for developers to use
> symbolic links to gnulib source files, not munged copies of the source
> files.
Understood. Thanks for clearing that up for me.
> The proposed permissions wording in
>
Brett Smith <[EMAIL PROTECTED]> writes:
> simply put the standard LGPL license header notice on the files that
> are LGPLed, and give gnulib-tool a --gpl switch to convert the
> files' headers to a GPL license notice on request.
That won't work well, because it's common for developers to use
symb
On Tue, Oct 16, 2007 at 09:44:37AM -0700, Paul Eggert wrote:
> > The confusion comes up because the headers in the individual files
> > say something else: they say it's GPLed, period. Given this
> > discrepancy, which source of information should users believe?
>
> They should believe the licens
Brett Smith <[EMAIL PROTECTED]> writes:
> The confusion comes up because the headers in the individual files
> say something else: they say it's GPLed, period. Given this
> discrepancy, which source of information should users believe?
They should believe the license information on the files tha
On Mon, Oct 15, 2007 at 09:52:01AM -0700, Paul Eggert wrote:
> The gnulib README file says the following. If this isn't clear enough,
> perhaps you or your correspondent could suggest a clearer wording?
There's nothing wrong with the README in isolation. The confusion comes up
because the header
Brett,
> an LGPLed project was using gnulib files
> without changing the license headers, and so this person was concerned that
> they might be bound by the GPL instead
Is this project using gnulib-tool? If yes, did they pass the option --lgpl
to gnulib-tool?
Bruno
Brett Smith <[EMAIL PROTECTED]> wrote:
...
> If the solution has already been implemented and the problem this user
> stumbled upon is historical cruft, then that's great; I just wanted to
> check.
[Brett, this doesn't address the copyright issue. I'm hoping
the "License" section in README is su
Brett Smith <[EMAIL PROTECTED]> writes:
> there wasn't any gnulib documentation or other information in the
> project tarball to suggest otherwise, after all.
The gnulib README file says the following. If this isn't clear enough,
perhaps you or your correspondent could suggest a clearer wording?
On Mon, Jul 16, 2007 at 09:00:32AM +0200, Jim Meyering wrote:
> > importing gnulib), see [1]. Look at the variable 'gnulib_version': If you
> > set
> > it to a date in the past, you eliminate this sort of trouble. And if you
> > set it to 'HEAD', you track all changes like you currently do. If the
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> consider what it means:
>> You prepare everything for a release, test to your heart's content,
>> and then at release time you rerun gnulib-tool to update copyright
>> notices. Unfortunately, that might also pull in other (untested)
Jim Meyering wrote:
> consider what it means:
> You prepare everything for a release, test to your heart's content,
> and then at release time you rerun gnulib-tool to update copyright
> notices. Unfortunately, that might also pull in other (untested)
> changes. Of course, we can control that, bu
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul,
>
>> If this sort of bootstrap were changed to make copies rather than
>> symbolic links, it would be much more of a pain to develop when
>> changes to both gnulib and an application are being debugged. It
>> would be far too easy to mistakenly e
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Eric Blake wrote:
>> Would it still be possible to keep symlink development (yes, that means
>> during development, the linked files bear a looser license than necessary,
>> but only on the developer's machine), so long as a maintainer-check
>> guarantees
Hi Paul,
> If this sort of bootstrap were changed to make copies rather than
> symbolic links, it would be much more of a pain to develop when
> changes to both gnulib and an application are being debugged. It
> would be far too easy to mistakenly edit the coreutils copy of a
> gnulib file rather
Eric Blake wrote:
> Would it still be possible to keep symlink development (yes, that means
> during development, the linked files bear a looser license than necessary,
> but only on the developer's machine), so long as a maintainer-check
> guarantees a fresh gnulib checkout with proper licenses at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 7/13/2007 12:41 PM:
>
> Going back to using copies (instead of symbolic links) when
> bootstrapping would not merely be a minor annoyance for me; it would
> be a real hassle and would make the resulting programs less reliab
[EMAIL PROTECTED] (Karl Berry) writes:
> But nowadays my understanding is that coreutils, and
> every other project, uses gnulib-tool.
The problem occurs even when gnulib-tool is being used. A common way
for developers to use gnulib-tool, which I use in many projects (not
just coreutils), is som
If I remember correctly, the initial reason why gnulib used the GPL
template for some LGPL file was because CoreUtils didn't yet use
gnulib-tool at the time. The CoreUtils maintainers didn't want to
manually change the files every time they were imported from gnulib.
I suggest we revert that deci
gnulib tries to support the typical case better
As I said: my recollection is that the original reason to have GPL in
the gnulib repo was because coreutils copied files directly instead of
using gnulib-tool. But nowadays my understanding is that coreutils, and
every other project, uses gnulib
[EMAIL PROTECTED] (Karl Berry) writes:
> Most projects want to use the files as GPL, not LGPL, since the projects
> are otherwise GPL, and it's just complication to have them as LGPL.
Yes, that's basically it. The preferred and more-typical case is an
application distributed under the GPL, and g
Karl Berry wrote:
> I haven't heard specifically about anything besides glibc and gnutls
> staying at v2.
As mentioned in
http://lists.gnu.org/archive/html/bug-gnulib/2007-07/msg00077.html,
libintl and libiconv will also stay under LGPLv2+ for some time.
Brett Smith explained to me that essentia
Yoann Vandoorselaere wrote:
> There are an undefined number of application out there which are GPLv2
> only. Whatever being the reason for their choice, I can understand that
> some people want to review the new license before applying it to their
> software.
> ...
>
> I'd like to empathize that
To me, this is the same concern as with software development: you don't
change a public API with every release of your library. Rather, you make
They don't seem the same to me. Unlike API's, there are non-technical
reasons to change licenses.
Anyway, I guess it'll be up to rms.
k
I think it would be useful to keep some modules GPLv2, at least for some
time.
Which ones?
I have no problems with changing to (L)GPLv3-only
(L)GPLv3 or later, actually.
for possibly the majority of modules, unless there are GNU projects
under (L)GPLv2 using a particular mo
Le vendredi 06 juillet 2007 à 17:33 -0500, Karl Berry a écrit :
> Some library using GnuLib are "GPLv2 or later", but some of the
> application using these library are "GPLv2 only".
>
> Um, not to point out the obvious, but
> our goal is not maximize popularity.
> Our goal is to maximize freed
[EMAIL PROTECTED] (Karl Berry) writes:
> Are you saying that gnulib be released under GPLv2+ indefinitely? If
> so, the other gnulib maintainers should have a say (I don't include
> myself, since I hardly contribute anything much these days), and, most
> importantly, rms should be asked.
I think
IMO we have no right to pressure them regarding the copyright of their code
Of course, the copyright on their code is up to them.
Equally, the copyright on our code is up to us.
already enough suffering from the split into a BSD-license camp and
a GPL-license camp,
I know of basical
situation at hand
Here is my nutshell on what we've got now:
1. The files in the gnulib repository have GPL license statements.
2. The gnulib module descriptions state that certain packages are LGPL.
(Most gnulib functionality is packaged as several files => module.)
3. When a gnulib user
On Fri, Jul 06, 2007 at 07:39:45PM -0500, Karl Berry wrote:
> I hope Brett will comment.
I'll admit up-front that I'm still not entirely sure I understand the
situation at hand, which is why I was holding off. But perhaps if I
describe the issues as I see them, hopefully that will be helpful.
Sp
Yes, I know what gnulib-tool does. It just doesn't seem legal to me. I
don't buy the existence of an "inside group" with special knowledge as a
rationale for making changes in basic legalisms. I hope Brett will
comment.
always sign his paintings on the painting itself, rather than on a labe
Karl Berry wrote:
> It's the conversion from GPL to LGPL by gnulib-tool that worries me.
gnulib-tool has this code, to verify that such relabelling is only done
when granted by the module description. (Paul suggested this check.)
# If --lgpl, verify that the licenses of modules are compatible.
http://lists.gnu.org/archive/html/bug-gnulib/2004-09/msg00131.html
I can only say that I sympathize with those issues.
> On the face of it, it does not seem legal.
Why not?
In the specific case: because you can't relicense something from GPL to
LGPL.
In the general case: because th
Simon Josefsson wrote:
> Idea: Have the current 'GPL' and 'LGPL' refer to 'GPL 2.0' and 'LGPL
> 2.1'. For new modules that is only available under GPL 3.0 or LGPL 3.0,
> add as license 'GPL-3' or 'LGPL-3'. gnulib-tool should refuse to apply
> gplv2-license changing on such modules, and refuse to
Some library using GnuLib are "GPLv2 or later", but some of the
application using these library are "GPLv2 only".
Um, not to point out the obvious, but
our goal is not maximize popularity.
Our goal is to maximize freedom.
That's why GNU exists.
So far, no one I have talked to has had obje
Yoann Vandoorselaere wrote:
> That sound incorrect, as stated in this mail:
> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/10668/focus=10722
>
> Some library using GnuLib are "GPLv2 or later", but some of the
> application using these library are "GPLv2 only".
Oops, you're right. I had not
Le vendredi 06 juillet 2007 à 01:40 +0200, Bruno Haible a écrit :
> Karl Berry wrote:
> > The Net::CDP author already replied saying he is
> > willing to relicense libcdp under GPLv3. ...
> > Werner has already updated the gnupg source repository to GPLv3.
>
> Good! To summarize: All GPLed (non-LG
Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> We can implement a --gplv3 parameter om gnulib if you
>> don't want to have GPLv2 mentioned in your sources.
>
> That sounds like a good idea, thanks. The default, though, should be
> GPLv3, and we can impl
Bruno Haible <[EMAIL PROTECTED]> writes:
> Karl Berry wrote:
>> The Net::CDP author already replied saying he is
>> willing to relicense libcdp under GPLv3. ...
>> Werner has already updated the gnupg source repository to GPLv3.
>
> Good! To summarize: All GPLed (non-LGPLed) packages that use gnul
Karl Berry wrote:
> I've never understood that "trick" (even though you've explained it to
> me before, sorry).
It is documented in the README, in more detail in doc/gnulib-intro.texi, and
you find the motivation in
http://lists.gnu.org/archive/html/bug-gnulib/2004-09/msg00131.html
> On the fac
You mean we extend the GPL/LGPL trick, where the actual copyright
of the files is different from the copyright notice in the files?
I've never understood that "trick" (even though you've explained it to
me before, sorry). On the face of it, it does not seem legal.
Brett asked to be inclu
Paul Eggert wrote:
> > We can implement a --gplv3 parameter om gnulib if you
> > don't want to have GPLv2 mentioned in your sources.
>
> That sounds like a good idea, thanks. The default, though, should be
> GPLv3, and we can implement a --gplv2 for the old-fashioned projects.
> Any objections to
is necessary to s/unnumbered/appendixsec/ if including the GPLv3 in an
Yeah, the discrepancy between the FDL and the GPL seems like a bug.
I'll ask about that change.
or if texinfo could support some other subsectioning keyword that
works regardless of whether the parent is a main bod
Btw, I don't follow what would give me the right to "reformat" the
license though, the copying information seems pretty clear to me:
I don't have a policy document I can point to, but I know that is the
accepted practice. Our web pages are also usually "verbatim only", but
verbatim doesn'
Karl Berry wrote:
> The Net::CDP author already replied saying he is
> willing to relicense libcdp under GPLv3. ...
> Werner has already updated the gnupg source repository to GPLv3.
Good! To summarize: All GPLed (non-LGPLed) packages that use gnulib are
fine with GPLv3.
Bruno
Patrice Dumas wrote:
> It is specified in all the source files! Did you had a look at
> http://www.opendap.org/pub/source/libdap-3.7.8.tar.gz
Glad to see this see. I had thought it was LGPLv2.1 because the README says
"COPYRIGHT INFORMATION
The OPeNDAP DAP library is copyrighted using the
On Thu, Jul 05, 2007 at 05:04:43PM -0500, Karl Berry wrote:
> OPeNDAP is under the LGPL, not GPL.
>
> Right, but the same issue arises.
>
> And if I remember well it is under LGPL 2 or above.
>
> I could not find any obvious statement. The source files I looked at
> didn't have any cop
OPeNDAP is under the LGPL, not GPL.
Right, but the same issue arises.
And if I remember well it is under LGPL 2 or above.
I could not find any obvious statement. The source files I looked at
didn't have any copyright/license info at all. Sigh.
On Thu, Jul 05, 2007 at 04:38:13PM -0500, Karl Berry wrote:
> OPeNDAP libdap http://scm.opendap.org:8090/svn/trunk/
>
> I wrote these two. The Net::CDP author already replied saying he is
> willing to relicense libcdp under GPLv3. No word from the OPeNDAP
> people.
OPeNDAP is under the L
Net::CDPhttp://search.cpan.org/src/MCHAPMAN/Net-CDP-0.09/libcdp/
OPeNDAP libdap http://scm.opendap.org:8090/svn/trunk/
I wrote these two. The Net::CDP author already replied saying he is
willing to relicense libcdp under GPLv3. No word from the OPeNDAP
people.
gpg
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Karl Berry on 6/30/2007 12:02 PM:
>> Since modification of these files is not allowed by the consumer,
>>
>> It's always been allowed to "reformat" the licenses. What's not allowed
>> is to change the words.
>
> So, just like had to be d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Karl Berry on 6/30/2007 12:02 PM:
> Since modification of these files is not allowed by the consumer,
>
> It's always been allowed to "reformat" the licenses. What's not allowed
> is to change the words.
So, just like had to be don
Le mercredi 04 juillet 2007 à 03:12 +0200, Simon Josefsson a écrit :
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > Bruno Haible <[EMAIL PROTECTED]> writes:
> >
> >> The sequence of events that I'm hoping for is this:
> >> - First, get agreement that all projects that use gnulib are OK with
>
Simon Josefsson <[EMAIL PROTECTED]> writes:
> We can implement a --gplv3 parameter om gnulib if you
> don't want to have GPLv2 mentioned in your sources.
That sounds like a good idea, thanks. The default, though, should be
GPLv3, and we can implement a --gplv2 for the old-fashioned projects.
Any
Patrice Dumas <[EMAIL PROTECTED]> writes:
> libdap use LGPL code from gnulib (regex), but I guess this question is
> for GPLv2 against GPLv3?
Yes, we're talking about GPLv2 -> GPLv3, and also ablut LGPLv2.1 -> LPGLv3.
So it's not a GPL vs LGPL issue; it's a license version issue.
(The GFDL hasn't
Paul Eggert <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> The sequence of events that I'm hoping for is this:
>> - First, get agreement that all projects that use gnulib are OK with GPLv3.
>
> I don't hear any objection, so let's assume there's agreement on that top
Hi Paul,
> > - First, get agreement that all projects that use gnulib are OK with
> > GPLv3.
>
> I don't hear any objection, so let's assume there's agreement on that topic.
You must have missed Karl's mail [1]: He promised to ask the maintainers of
three packages that use gnulib, whether the
On Tue, Jul 03, 2007 at 01:22:05PM -0700, Paul Eggert wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
> > The sequence of events that I'm hoping for is this:
> > - First, get agreement that all projects that use gnulib are OK with
> > GPLv3.
>
> I don't hear any objection, so let's assume
Bruno Haible <[EMAIL PROTECTED]> writes:
> The sequence of events that I'm hoping for is this:
> - First, get agreement that all projects that use gnulib are OK with GPLv3.
I don't hear any objection, so let's assume there's agreement on that topic.
> - Then, over a few weeks, let these proj
may I ask for three kinds of whitespace modifications?
rms accepted untabification and removal of trailing whitespace, but
preferred to keep the headings as they are.
I've checked in the change.
Thanks,
Karl
Since modification of these files is not allowed by the consumer,
It's always been allowed to "reformat" the licenses. What's not allowed
is to change the words.
may I ask for three kinds of whitespace modifications?
I can't imagine it being a problem, but I feel I should ask rms a
James Youngman wrote:
> I enclose a patch which adds an option to gnulib-tool to modify the
> copyright banners of the Gnulib code to say "version 3". This allows
> projects which treat Gnulib files as generated code to import and
> reimport without reverting part of the source to GPL version 2.
On 6/30/07, James Youngman <[EMAIL PROTECTED]> wrote:
I enclose a patch which adds an option to gnulib-tool to modify the
copyright banners of the Gnulib code to say "version 3".
Findutils also builds the gnulib tests and runs the tests when the
user says "make check". Unfortunately, my previo
On 6/29/07, Karl Berry <[EMAIL PROTECTED]> wrote:
OTOH, Mr. Licensing (AKA, Brett Smith) has said that they are incompatible,
so you cannot mix them up in the same program.
What Brett has said as far as I've seen is that GPLv2 and GPLv3 are
incompatible, but "GPLv2 or later" code can be
Hi Karl,
> My only change was to make the v3 license files *available* in gnulib
> for those projects which are able to switch now.
Thanks; this is useful, of course.
Since modification of these files is not allowed by the consumer, may I ask
for three kinds of whitespace modifications?
- Rep
>Can you please wait a bit with it?
I'm sorry, I guess I wasn't clear. I wasn't proposing to change the
licensing terms of gnulib so quickly (I would never have gone ahead with
that without hearing you and Paul and Jim, at least); I agree that needs
more discussion, with rms among others.
M
Karl Berry wrote:
> What Brett has said as far as I've seen is that GPLv2 and GPLv3 are
> incompatible, but "GPLv2 or later" code can be distributed (as GPLv3)
> with GPLv3 (or later) code. It is the distributions without the "or
> later" that are problematic.
OK. What are the consequences?
-
Yes. gnulib will also need to update doc/gpl.texi and doc/gpl.txt.
Similarly for doc/lgpl.texi and doc/lgpl.txt.
I wasn't sure why gpl.txt and lgpl.txt were needed given
COPYING{,.LESSER}, so I removed them. If for some reason it is useful
to have these copies, fine, we can set them up.
OTOH, Mr. Licensing (AKA, Brett Smith) has said that they are incompatible,
so you cannot mix them up in the same program.
What Brett has said as far as I've seen is that GPLv2 and GPLv3 are
incompatible, but "GPLv2 or later" code can be distributed (as GPLv3)
with GPLv3 (or later) code.
On 6/29/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
"James Youngman" <[EMAIL PROTECTED]> writes:
>> Maybe we should have doc/COPYINGv2 and doc/COPYINGv3 (ditto
>> COPYING.LESSER) in gnulib, with no doc/COPYING at all, so the choice is
>> explicit? Other ideas?
>
> That seems reasonable to me
"James Youngman" <[EMAIL PROTECTED]> writes:
>> Maybe we should have doc/COPYINGv2 and doc/COPYINGv3 (ditto
>> COPYING.LESSER) in gnulib, with no doc/COPYING at all, so the choice is
>> explicit? Other ideas?
>
> That seems reasonable to me at first. Projects which include gnulib
> code will nee
On 6/29/07, Karl Berry <[EMAIL PROTECTED]> wrote:
I am not sure how best to put GPLv3 and LGPLv3 into gnulib.
I think that when projects update to GPLv3, the "COPYING" file should be
GPLv3. But of course until the update, COPYING remains GPLv2.
Yes. gnulib will also need to update doc/gpl.tex
I am not sure how best to put GPLv3 and LGPLv3 into gnulib.
I think that when projects update to GPLv3, the "COPYING" file should be
GPLv3. But of course until the update, COPYING remains GPLv2.
Maybe we should have doc/COPYINGv2 and doc/COPYINGv3 (ditto
COPYING.LESSER) in gnulib, with no doc/COP
73 matches
Mail list logo
