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

Re: is igmpproxy dfsg compliant?



On Friday 02 December 2016 17:46:40 Roberto wrote:
> 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.

I'm already in contact with old/original maintainers of igmpproxy hosted 
on sourceforge who maintained it until release of version 0.1.

Those maintainers are not interested in maintaining igmpproxy anymore 
and they agreed that I can take over whole igmpproxy project. Currently 
I have new repository on github (on old sourceforge project is written 
by original maintainers that project was moved to my github repository), 
but there is no new released version.

So last version is 0.1 -- that one from sourceforge. And this version I 
packed for debian (on mentors).

> 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.

Situation is: Original authors took some parts of mrouted code, modified 
it and on top of it was created igmpproxy. So it is hard to tell which 
parts of igmpproxy 0.1 comes from mrouted and in which form...

> 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.

Copyright © 2002 The Board of Trustees of the Leland Stanford Junior
University
Permission is hereby granted to STANFORD's rights, free of charge, to 
any person obtaining a copy of this Software and associated 
documentation files ( "MROUTED"), to deal in MROUTED without 
restriction, including without limitation the rights to use, copy, 
modify, merge, publish, distribute, sublicense, and/or sell copies of 
MROUTED , and to permit persons to whom MROUTED is furnished to do so, 
subject to the following conditions:
1)      The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the MROUTED .
2)      Neither the STANFORD name nor the names of its contributors may 
be used in any promotional advertising or other promotional materials to 
be disseminated to the public or any portion thereof nor to use the name 
of any STANFORD faculty member, employee, or student, or any trademark,
service mark, trade name, or symbol of STANFORD or Stanford Hospitals 
and Clinics, nor any that is associated with any of them, without 
STANFORD's prior written consent.  Any use of STANFORD's name shall be 
limited to statements of fact and shall not imply endorsement of any 
products or services.

3)      MROUTED IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, 
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH MROUTED OR 
THE USE OR OTHER DEALINGS IN THE MROUTED .

> 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?

No idea if that new Stanford BSD license is locked to some specific 
version of mrouted. In whole license is no information about version. 
Just generic "MROUTED" name.

As original authors heavy modified original mrouted source and on top of 
it created igmpproxy, I doubt that any "upgrade" is possible...

Theo de Raadt wrote about that license:

After 2 years, and more than 350 pieces of mail exchanged with "the
right people" at Stanford, we finally succeed at getting the parts of
the code they wrote to be released under a BSD license.  The other
components were written by USC and Xerox (who were quick at helping, 5
days and 6 weeks if I recall).  Of the ~200 authors we have contacted
regarding license issues, this institution has been THE WORST to deal
with, and to think -- this is an American University.  How far the 
edifice of educational freedom has fallen.... shame on you Stanford.

> 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.

I will fix all licensing problems in my github repository (as this is 
new "upstream"). But first I will try to make commonly used igmpproxy 
version 0.1 to be GPLv2+ compatible.

> 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.

Ok.

List of contributors to version 0.1 is not so long. But contributors to 
my github repository is bigger, so first step is to make original 0.1 
version compatible. Next step would be other patches which are not part 
of version 0.1.

-- 
Pali Rohár
pali.rohar@gmail.com

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: