Bugzilla Bug 198762

with USE="-avahi", kdelibs deps on mDNSresponder.  mDNSresponder has an
incompatible license for binary distrobution.  Setting USE=avahi removes the
dep on mDNSresponder, which is good, but there is a policy out there somewhere
that says you should use the bindist useflag.

This is blocking app-emulation/emul-linux-x86-qtlibs and any livecds/dvds that
contain KDE.

Created an attachment (id=135716) [details]
kdelibs-3.5.8-r1.ebuild.diff

USE=bindist completely sucks for describing funtionality, policy or not... How
does this look?

thanks jakub, is 3.5.8-r1 going stable real soon or should I backport it to
3.5.7-r3?

Created an attachment (id=135722) [details]
kdelibs-3.5.7-r3-bindist.patch

patch for 3.5.7-r3.  both patches work on their versions.  will know in the
morning if it works as intended.

check is complete, no linkage to mDNSresponder with USE=bindist.  all systems
go

Thanks, Mike! Fixed in CVS.

This bug is invalid as the ebuild stating the license is. The shared lib is
under BSD license, the rest of the code is provided under Apache 2, not APSL-2.
At least this is what I found having a look at the source code of version
107.6.

(In reply to comment #6)
> This bug is invalid as the ebuild stating the license is. The shared lib is
> under BSD license, the rest of the code is provided under Apache 2, not APSL-2.
> At least this is what I found having a look at the source code of version
> 107.6.
> 

The mDNSResponder daemon source code is licensed under the terms of the Apache
License, Version 2.0. To accommodate compatibility with the widest possible
range of client source code licenses, the DNS-SD shared library source code is
licensed under the "Three-Clause BSD License".

So the question becomes is the "Three-Clause BSD License" GPL-COMPATIBLE or
not.
The orig BSD license is not. But the modified version is.

The ASPL* is for sure not compat in any such way..

References:
http://www.fsf.org/licensing/licenses/index_html
http://developer.apple.com/opensource/internet/bonjour.html

(In reply to comment #7)
> So the question becomes is the "Three-Clause BSD License" GPL-COMPATIBLE or
> not.

The Three-Clause BSD license _is_ the modified BSD license (given the correct
clause was stripped) as you can read here¹.


btw.: There is actually a bindist relevant issue. Shipping binaries linked
against newer Samba versions is not fine as GPL 2 & 3 clash. One possible way
to solve this would be issue an ewarn and ship and link KDE with its own
libsmbclient.so in this case. Ugly to maintain, though.


[1] http://www.gnu.org/philosophy/license-list.html

(In reply to comment #8)
> btw.: There is actually a bindist relevant issue. Shipping binaries linked
> against newer Samba versions is not fine as GPL 2 & 3 clash.

Uhm? Really fail to see what you are talking about here. Even the latest samba
(3.0.26a) is GPL-2, ditto for kdelibs.

(In reply to comment #9)
> Uhm? Really fail to see what you are talking about here. Even the latest samba
> (3.0.26a) is GPL-2, ditto for kdelibs.

Samba 3.2 and above are under GPL 3

(In reply to comment #10)
> Samba 3.2 and above are under GPL 3

Cool, and how's that exactly relevant to current ebuilds? Can we bring this bug
back on topic please?

(In reply to comment #11)
> Cool, and how's that exactly relevant to current ebuilds? Can we bring this bug
> back on topic please?

Not removing an added use flag that we need rather sooner than later anyways,
having users to rebuild constantly when using --newuse. Needlessly adding,
removing and changing use flags means work and is therefore a nuisance for our
user base and should be done only when necessary and if possible only when
adding new versions.


And Jakub: Please spare me your insolent tone in future. This isn't a chat room
and while you deal with bugs as you feel like, too often I have the idea you
don't have a clue.

This bug is about existing ebuilds (and stable ones as far as release media is
concerned) - not about nonexistent ones. So, potential issues with samba-3.2
(which is in _pre1 and totally not ready for any production use) do not belong
here, not to mention that samba is shipped w/ emul-linux-x86-medialibs, not
emul-linux-x86-qtlibs.

(On a side note, this bug also wouldn't exist if the zeroconf bloat wasn't made
mandatory in the first place.)

Carlo, this is not about Samba 3.2 but about stuff *now* blocking the release.
Feel free to open another bug for any further issues (or work on relevant open
bugs, we still have enough of those).

As for now, the current bindist solution stays as it is to be on the safe side
for the release. It's not like it's much of a problem for our users even if it
should be overkill.

*sigh* - feels like talking with a wall... The bindist flag because of
mDNSresponder _is_and_remains_still_wrong_, if you actually cared to look at
the licenses.

My point about the >= Samba 3.2 license clash is that the use flag (unused)
could stay in the ebuild.

(In reply to comment #15)
> My point about the >= Samba 3.2 license clash is that the use flag (unused)
> could stay in the ebuild.

Which is *exactly* as wrong as using it for mDNSresponder since there's no
samba-3.2 ebuild anywhere and there's no license clash with samba anywhere. On
that note, unused use flags in IUSE are a QA violation.

Will take care of it.

I'm cleaning amd64 bugs - amd64 is CC'ed on this bug, but I'm not quite sure
why.  Is this even still an open issue (neither of these kdelibs versions are
still in portage)?

Seems that there's nothing to do here for the release.  If I'm wrong, add us
back with some kind of explanation on what we should be doing.

Thanks

Hum, KDE is GPL2+ actually so there wouldn't be any incompatibility with
GPL-3. ( http://www.kdedevelopers.org/node/2881 )
However Qt are still GPL actually. 

BUT them are planned to move to to GPL-3 (or at least to GPL2+), see:
http://arstechnica.com/journals/linux.ars/2008/01/18/trolltech-to-adopt-gpl-3-for-qt

IMO this bug should be marked invalid.

(In reply to comment #18)
> I'm cleaning amd64 bugs - amd64 is CC'ed on this bug, but I'm not quite sure
> why.  Is this even still an open issue (neither of these kdelibs versions are
> still in portage)?
> 

Ditto.

KDE team: add us (amd64) back with a plan if we need to do/test something.

This bug was about a kdelibs version no longer in the tree so there's nothing
to do here.