On 2015-11-29 08:17, John Layt via KDE Bugzilla wrote:

> https://bugs.kde.org/show_bug.cgi?id=356051
> John Layt <jlayt@kde.org> changed:
> What |Removed |Added
> ----------------------------------------------------------------------------
> Resolution|--- |INVALID
> Status|UNCONFIRMED |RESOLVED
> CC| |jlayt@kde.org
> --- Comment #2 from John Layt <jlayt@kde.org> ---
> We don't allow Artistic licensed code in our core libraries (see
> https://techbase.kde.org/Policies/Licensing_Policy). I believe all but one to
> be false positives, and that one is not in kdelibs.
> In general, we would need to check first if we can legally relicense from
> Artistic 1.0 to (L)GPL. All code in KDE is copyright to the individual authors
> and they must be contacted first to seek permission. Some authors may have
> signed the FLA which would allow us to relicense, but I'd prefer we try contact
> them first to ask.
> All hits under kdoctools/customisation are translation strings in template
> files. KDocTools is a tool for working with Docbook files, so I believe this is
> all just template boilerplate for reading/writing docs that use the Artistic
> license, a bit like KDevelop say including templates for users to write code
> under other licences. There are also templates under kdoctools/customisation
> for the FDL, GPL, X11 and BSD licences. No code is actually stated to be under
> Artistic.
> The KAboutData hits appear to be the same thing, template code for devs who
> write an app under Artistic and want that to show in the 'About' dialog.
> The doc/common hits again appear to be just a copy of the licence for
> displaying when our doc tools display docs that are Artistic licensed.
> kopete/protocols/irc/ksparser.h is licensed under Artistic by Simon Hausmann
> who should be contactable. However it is not part of kdelibs and so shouldn't
> be in this bug report, please file that separately.
> In short, all the hits found in kdelibs are simply templates for developers
> using kdelibs who want to write documentation under the Artistic licence. No
> code or documentation in kdelibs is licensed under Artistic. Closing as
> invalid, but thanks for checking. You may wish to subscribe to the KDE
> licensing mailing list (https://mail.kde.org/mailman/listinfo/kde-licensing)
> and send all future queries there.

Thanks for the response, I will go to the licensing mailing list in the future.

I would like to make a couple of points.

1. It may be that kde4libs code is nowhere licensed with Artistic License 1.0 but you are providing an infrastructure to help use it.

It seems that it would be worthwhile to add supporting the use of Artistic License 2.0 to help encourage use of free licenses.

Also consider in /licenses/ARTISTIC kde4libs provides the text of the Artistic License 1.0, so it is indirectly at least encouraging the use of non-free licenses.

2. Also consider how kdepasswd uses the KAboutData class from kde4libs in kdepasswd.cpp:

int main(int argc, char **argv)
{
KAboutData aboutData("kdepasswd", 0, ki18n("KDE passwd"),
KDE_VERSION_STRING, ki18n("Changes a UNIX password."),
KAboutData::License_Artistic, ki18n("Copyright (c) 2000 Geert Jansen"));
aboutData.addAuthor(ki18n("Geert Jansen"), ki18n("Maintainer"),
"jansen@kde.org");
aboutData.setProgramIconName( "preferences-desktop-user-password" );

This code uses the KAboutData::License_Artistic enum value form kde4libs to declare that it is licensed under Artistic License 1.0. There is no other reference I can find in kdebase-apps where anything is explictly licensed under this license. So it seem that it would be worthwhile to make the addition in 1. above to make use of a free license easy for the developer and have to provide all the localized translations separately.

3. Also I noticed on at least Debian system the Artistic License 1.0 text is placed in /usr/share/common-licenses/Artistic.

It would seem that an Artistic2.0 file should be there as well. But I guess I would have to raise that issue with the Debian org.

4. I will file a bug about Kopete.

Thanks

Dennis