Re: is igmpproxy dfsg compliant?
On Fri, Dec 02, 2016 at 03:53:53PM +0000, Ian Jackson wrote:
> Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> > On Thursday 24 November 2016 19:29:21 Roberto wrote:
> > > On Thu, Nov 24, 2016 at 06:36:53PM +0100, Pali Rohár wrote:
> > > > And can be included igmpproxy package into Debian?
> > >
> > > Probably asking the authors if they can please switch the license, it
> > > will benefit not only Debian but anyone who downloads from upstream
> > > source as well.
> >
> > So... it is enough if all authors and contributors of igmpproxy agree
> > that their changes can be redistributed under GPLv2+?
>
> Yes.
>
> > Or do they need to "relicense" their changes also under new BSD Stanford
> > too?
>
> No.
>
> Ian.
I would prefer that the upstream does the license transition by
examining the situation and fixing all headers and documentation. They
(hopefully) know better about who modified the files and what licenses
the changes are in each case. Otherwise, even if they give you
permission to switch those files into the new license, each time a new
version of the upstream source is packaged it should be cleaned again by
the debian maintainer, or a notice should be included within
debian/copyright file saying all the references to the non-free license
scattered in the source code are not valid anymore. Neither of those
solutions seem the correct thing.
Two more things to notice:
1. As other have pointed, not all BSD licenses are compatible with the
GPL, it should be examined before assuming it is, if you can please
paste it to this list so other people can comment.
2. Is the change of license of mrouted effective from a specific
version, or are all older versions placed under the new license too? And
in the first case, what version forked igmpproxy from? Can those sources
be upgraded to the first BSD-licensed version?
Again, I think this should be fixed by upstream and only trying fo fix
it in the debian package if upstream does not want to cooperate.
In my experience, when a fork from a program (or library) is included
into another, it can be sometimes very difficult to fix things when the
original project switch to another (possibly better) license. igmpproxy
seems to be easier, but it should be done the correct way anyways.
As an example, it happend when idsoftware gave permission to relicense
Doom source into GPL. I was very active by then trying to sort all
things, but it was painful, with thousands of emails to all people who
modified the original sources. Many engines based on Doom were unable to
make the switch (zDoom, one of the more populars, it is still maintained
under the old non-free license because it will conflict with many other
pieces of code submitted under the older license), and many authors will
actually refuse to switch to the new license or prefer the older (yes,
some people explicitly refused to give permission to relicense their
changes into the new license).
So please, when code is touched by many different people, NEVER assume
that people will agree to a license change, even if the new license
seems clearly better.
Reply to: