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