Yes, from the FSF side of things, having the FSF own the copyright is
handy for upgrading licenses;
Probably everyone here knows, but for the archives: FSF holding
copyright is about more than being handy for license changes. It's
about defending the program's copyright in court. This i
On 05/04/2010 09:53 AM, Peter Seebach wrote:
> In message , "Alfred M. Szmidt" writes:
>> If the FSF is the copyright holder, then there is no (legal) need to
>> ask the original author about permission to relicense the work. It
>> might be a nice thing to do, but if the original author says no fo
On 05/04/2010 05:53 PM, Peter Seebach wrote:
In message, "Alfred M. Szmidt" writes:
If the FSF is the copyright holder, then there is no (legal) need to
ask the original author about permission to relicense the work. It
might be a nice thing to do, but if the original author says no for
some re
Peter Seebach wrote:
> In message , "Alfred M. Szmidt" writes:
>>If the FSF is the copyright holder, then there is no (legal) need to
>>ask the original author about permission to relicense the work. It
>>might be a nice thing to do, but if the original author says no for
>>some reason, the FSF ca
Hello Peter,
* Peter Seebach wrote on Tue, May 04, 2010 at 05:53:56PM CEST:
> In message , "Alfred M. Szmidt" writes:
> >If the FSF is the copyright holder, then there is no (legal) need to
> >ask the original author about permission to relicense the work. It
> >might be a nice thing to do, but i
nicely.
My proposal is this: I will provide an implementation of setproctitle()
which works on Linux/glibc systems, as well as another implementation
which simply does nothing and is suitable for use on any system to
allow programs to compile and execute, even if no one knows how to
implement set
Hi Peter,
if the FSF needs a copyright assignment, does that not imply that I
no longer get to choose the copyright?
As the author, your desire/recommendation would carry a lot of weight :).
If you want it released under LGPLv2+, I can't imagine there being a
problem with that.
Aside fro
In message <4be03f2d.7090...@redhat.com>, Eric Blake writes:
>As original author, you get to choose the license that will be used
>within gnulib. I see nothing wrong with you declaring that the
>setproctitle module is LGPLv2+.
Ahh, okay.
That said, the more I look at this, the
In message , "Alfred M. Szmidt" writes:
>If the FSF is the copyright holder, then there is no (legal) need to
>ask the original author about permission to relicense the work. It
>might be a nice thing to do, but if the original author says no for
>some reason, the FSF can still relicense the work;
to choose the copyright?
As original author, you get to choose the license that will be used
within gnulib. I see nothing wrong with you declaring that the
setproctitle module is LGPLv2+.
If the FSF is the copyright holder, then there is no (legal) need to
ask the original author about per
f, but if the FSF needs
> a copyright assignment, does that not imply that I no longer get to
> choose the copyright?
As original author, you get to choose the license that will be used
within gnulib. I see nothing wrong with you declaring that the
setproctitle module is LGPLv2+.
--
Eric Bl
In message <87r5lr51hh@meyering.net>, Jim Meyering writes:
>Can you simply declare the copyright to be LGPLv2+?
>Many modules are already LGPLv2+ (see modules/*).
I could if I were just releasing the code myself, but if the FSF needs
a copyright assignment, does that not imply that I no longer
F?
>
> I think I can. There is some ambiguity about the IP agreement at $dayjob,
> but we do in general contribute some stuff to the FSF, so I can probably
> route it through the open source contribution mechanism.
>
> My thought is that the first step towards a setproctitle() imple
Peter Seebach wrote:
> Is there any interest in attempting to provide a moderately portable
> setproctitle()?
Yes, because it looks like a portable implementation will have to use
different approaches on different platforms. [1] has the following:
- use the function setproctitle.
- use
IP agreement at $dayjob,
but we do in general contribute some stuff to the FSF, so I can probably
route it through the open source contribution mechanism.
My thought is that the first step towards a setproctitle() implementation
is a pure stub. The function returns void anyway, and I'm not awar
Peter Seebach wrote:
> Is there any interest in attempting to provide a moderately portable
> setproctitle()? (I think it would be reasonable for it to, on some
> systems, simply fail to do anything...)
>
> Apparently, this functionality exists in "util-linux-ng&quo
Is there any interest in attempting to provide a moderately portable
setproctitle()? (I think it would be reasonable for it to, on some
systems, simply fail to do anything...)
Apparently, this functionality exists in "util-linux-ng", and sendmail has
an implementation that works on Lin
17 matches
Mail list logo
