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

Re: Full Licence field



Kevin Kofler wrote:
Simon Schampijer wrote:
So, the point to ship a license per package is fine. I actually did not
want to relax that. I had the technical problem to need to access the
license field to be able to display it in a dialog inside Sugar.

http://shell.sugarlabs.org/~erikos/licence_field.png

And since - the file is placed in different places on each distro I
wanted to see if a common place would be possible, makes sense. On
Fedora this could have been in addition to the per package license
field. Not very economic of course.

FWIW, KDE does exactly that.

/usr/share/kde4/apps/LICENSES/ (where /usr/share/kde4/apps is the KDE 4
application data directory, it can vary from distribution to distribution)
contains the following files (owned by kdelibs):
ARTISTIC  BSD       GPL_V2    GPL_V3    LGPL_V2   LGPL_V3   QPL_V1.0
The KAboutData class in kdelibs provides an enum which allows you to pick
one of these licenses. If the license is not one of those, the application
is responsible for loading the exact text of the license explicitly.

Anyhow - while thinking about it, I was not even sure the displaying of
the full license is correct/needed - or matches the guidelines. For
example I have not seen something similar in GNOME.

KDE does it. (Try "Help / About (application name)" in a KDE application.
The name of the license is a link, clicking that link opens a dialog box
with the full text of the license.)

It's not a bad idea, but it isn't strictly needed either. (There are plenty
of GPLed applications which don't display the full text of the GPL in the
UI.)

        Kevin Kofler

Ok, I have placed it now to the sugar data dir so it is accessible on each platform/distribution the same way. As Sugar is likely getting into areas where people are not that familiar with open source software it is maybe a good thing to strengthen it out in the UI as well. I think that was part of the idea behind it when done by OLPC.

Thanks for your thoughts,
   Simon


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