[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-artists
Subject:    Re: K-ARTIST:Copyright
From:       ante <vitanova () softhome ! net>
Date:       2002-05-03 11:20:39
[Download RAW message or body]

On Monday 29 April 2002 12:08, Torsten Rahn wrote:
 > Again and again: how can you make such claims? Up to my best knowledge

Copyright laws are very strict, "up to my best knowledge" is not enough. If
you are not 100 % sure, you have to make a public announcement.

 > Ok, so we want to be attractive for commercial _and_ noncommercial
 > applications. The current licenses which are used in kdelibs are very
 > attractive in both cases for source code: You can use and distribute the
 > stuff - no matter if you want to use it for your opensource or your
 > closedsource application. Due to fact that there exists a mechanism which
 > is called "linking" and due to the nature of C++ it's effectively even
 > possible to use/distribute _and_ to modify the stuff in kdelibs for your
 > closed source application.

Exactly, this is what you want for the artwork too. Well, not exactly 
linking of course, but you want that companies can use the artwork in their 
apps under a license of their choise.

There are 2 ways to implement this.
1 Allow that the artwork becomes proprietary. This is the way you do it in 
your license, it is the BSD style
2 Make sure that the artwork is free and stays free, and allow, as a 
special exception, the use of the artwork in apps under a license of the 
apps author's choice. This is the way I do it, copyleft + exception. 

(copyleft: condition that the work stays free)

The second way works just as well. In the case of code, the LGPL provides 
this. There are advantages to this second way. You said you want to 
propagate free software (artwork included, I presume). Then the second way 
is the way. The second way acts against division, and most important in 
this case, I guess you will find this important, it enhances visual 
consistency. I will explain this below.

The second way strenghtens the goals KDE has, more than the first way 
does.  A "general" desktop needs a pool of free elements that stay free, so 
that everyone can use the same elements, none of the elements can become 
prorietary, so there can not be confusion.

With the first way elements can become prorietary, not everyone can use 
everything, confusion starts to take place, people may turn away because of 
this.

Now here is something you may find important. If you want visual consistency,
make sure the artwork stays free:

Suppose an icon made by KDE gets in an app under a closed license - the thing
that should be possible, also, it got changed a bit. Say, there is a free,
light version of the app, popular, many people get to know the icon. People
think, because of the visual consistency, it is free, but, no, because it was
not properly protected, it is now proprietary. Then it is needed in KDE
itself too, the action in the closed app gets supported in KDE proper too. Or
another app under whatever license wants the icon too. Without a copyleft
license it can not be used in KDE, even if it is 90 % work done
by a KDE artist. Because the icon is not properly protected, it is now
proprietary. There goes the visual consistency. If you want visual
consistency - I too belief that is something to do - you better make sure 
the icons stay free.

A GUI that wants visual consistency, needs a copyleft license, since you 
want control, the control that the icon stays free.

Look what happened with UNIX, it fell apart into proprietary systems. There
was an influential free UNIX, the BSD one, but elements of it were used in 
the proprietary UNICES. Linux on the other hand has a copyleft license, and 
it's elements can not become part of proprietary systems. Linux is uniting 
the UNIX world, it is the leveling ground. The license is essential. With a 
copyleft license you create a reservoir of free work, not divided sets of 
work.

I highly respect the BSD license, it is the most spiritual license around, 
but, it is also an old-school license that did not really deliver. It is a 
Californian hippy license, and we need to put our feet on the ground. 

If you want visual consistency, keep all the elements free. It can be done,
no problem, as long as use in an interface under other licenses is allowed.

So, the app can be proprietary, the icons stay free. That is what KDE needs.

First desicion to make: which way do we want to follow, accept the icons 
become proprietary, or keep them free with an exception for use in apps 
under licenses of choice.

I strongly recommand the second way.

After the first decision, the second. How to implement this.

Write a license yourself, or take an existing one.

Andreas Pour never said: write a license yourself. Of course he did not.
There are licenses out there made by special interest groups, with expert
back up. The most passionate group is the GNU, imho. It seems Andreas Pour
thinks so too. He pointed to the documentation license written by the GNU.

Before you ever try to write something yourself, take a look at the best
licenses out there. Pick the one most convincing and close to what you want.
If it does not work out of the box, add a little "paper", an add-on. You get
all the strenght of a well written license, and it is tailer-made at the same
time.

This is a standard operation. When you hire a house, there often is a
standard contract, with a short paper you sign. In the short paper are the
conditions that differ from the standard contract. The big advantage of this
operation is that the standard contract is made by special interest groups of
both sides, with a host of lawyers. So, the standard contract is well thought
out, and probably in balance. You especially have to read the short paper
carefully.

There is a PR side to this too. When we make the license ourselves, it will 
never look professional. OTOH, a solid license with an add-on in the license 
notice looks smart, state of the art. 

If you really want the glory of writing your own license, seek legal councel.
An real expert on licenses.

I strongly recommand taking a well written, existing license. If needed 
make it tailer-made with an add-on.

For the first way, a good license is the BSD license (a new version).

For the second way, licenses that come close are the LGPL, the Free
Documentation License, and the Design Science License ( I like the name of
the last one, it is a shame the name is not an argument).

Microsoft killed Netscape, partly with their license policy. At this moment 
they are on a campaign against UNIX. The day KDE really becomes succesfull, 
they will try to kill KDE. The licenses made by the GNU are actually 
enforced, they are battle-proven. 

I made a solution that keeps the artwork free, allows use under licenses of 
choice. It is based on the LGPL. OK, there is a case against the use of the 
LGPL for artwork, but, I will show that it can be repaired. Let's take a look.

 > is called "linking" and due to the nature of C++ it's effectively even
 > possible to use/distribute _and_ to modify the stuff in kdelibs for your
 > closed source application.
 >
 > This is something that the LGPL would _NOT_ allow for artwork.

You make this to absolute. The way you put it, it is not in the LGPL. Nothing
in the LGPL says: No, not with artwork. In fact, the LGPL also uses the word 
"data". 
The LGPL licenses "you" to modify the software lib. What Andreas Pour said 
was: artwork is not a software lib, so the "you" does not get the license to 
change the artwork, he only gets the license to change the software lib, and 
there is no software lib in the package. 

So, possibly the license is void? Well, the only only that can act is the one 
that gave the license, the author. And since he wants the icons to be used, 
changed, etc, and ships the icons himself under the LGPL, he hardly is in a 
position to say: I gave you this license, but I believe myself it is fake. 
Basically he then says: you should not have listened to me. Which from then 
on will happen, judges included. But, misunderstandings should be cleared 
out. It is the author that has the right to make the license valid. He can do 
this with an add-on in the license notice. What he does is more important 
than the license (the document). 

OK, we have to make sure the "you" also gets licensed to change the
artwork.

Normally when you give the babysitter permission to do something, and you
forget something else, well, you call him or her, and say: I forgot to say,
there is apple-pie in the fridge, you can take a piece. Licenses are just
like the real world, you can say: I forgot something, I want to add
something. Like the standard contract with little paper thing. 

The first sentence of my add-on reads:

"KDE Artwork is a special kind of software library, it is an art library,
it's elements can be used in a Graphical User Interface, or GUI. "

Here I bring artwork under the definition of a software library. From then
on, it can be changed like any other software library.


 > So the LGPL (if it would work at all) would work completely differently for
 > artwork than for source code: It would effectively allow the behaviour of
 > the code in kdelibs to be modified but not the artwork. And: can you
 > actually "link" to icons at all?


From the add-on:
"KDE Artwork is a special kind of software library, it is an art library,
it's elements can be used in a Graphical User Interface, or GUI. "
This is what you want to make possible, not? I substitute the linking with
using in an interface.
 >
 > To make sure that the artwork in kdelibs can be used as a good fundament
 > for your own applications (os and cs) it should be possible to modify the
 > icons: One of the most important reasons to use KDE as a platform is
 > consistency. If you develop your application then you want to make sure
 > that it looks and behaves consistent with the others. So even if you create
 > new actions in your app and you want to symbolize them in a way that they
 > look consistent with the existing icons then you have to modify existing
 > artwork. As far as i can see the LGPL doesn't allow that for commercial
 > closed source applications.

That would be a problem if it was true, indeed. Section 6 handles shipments
under an other license. With code it is about using the lib to make your
executables, and then ship under a license of your choice, fi, a closed
license. How would that work for icons? First the company changes them,
that is under Section 2, just like with code. Then they use them in their
interface, and ship them under their own license, that has to be brought
under Section 6. The last line of my add-on:

"The exception in section 6 of the GNU Lesser General Public License covers
the use of elements of this art library in a GUI of a program. "

With the last line I bring using the icons in this way under section 6. I
make it possible to use the icons, ship them in an app under any kind of
license. What is really brilliant of the LGPL, is that the lib can be used,
but stays free itself. It is a shame to give that up. Especially if it is not
needed. Andreas Pour never asked to give up the copyleft quality, so long as
there is the "library" quality. He recommanded the documentation license,
which is a very strong license too. 

Legal stuff is difficult. People might miss the point. OK, we can add an 
explanation too. Say we add to the add on, just above what we already have 
(like a preamble):

"In order to the artwork to be free, to stay free, to give you permission to 
change it under conditions, to license you to use it in your application 
under a license of your choice under conditions, to clarify possible 
misunderstandings:"

Well, any misconceptions left? With this extra explanation, it is clear where 
we want to go. People will get an idea what the sentences that follow are 
about, before they start reading them. That is helpfull. And also, it is now 
irrevocably clear the author wants the license to be valid. And he is the 
only one deciding, so when he is clear, it is clear. 

 >
 > In addition we have to face reality: I'd estimate that 99% of the people
 > out there think of the icons which are provided by MS Windows as sort of
 > "public domain": They modify them, use modified versions in their own apps,
 > use them on webpages etc. Still the license under which these icons are
 > published doesn't allow that at all. This is certainly the infringement
 > case which would happen most of the time if we would have stayed with the
 > LGPL.

You can do all these things with icons under the LGPL.

Are there any issues left to deal with? If not, we have a good solution. 

 > Ok, so what about this one for the icons in kdelibs:
 >
 > "Permission is hereby granted, free of charge, to any person obtaining a
 > copy of this artwork (the "Artwork") to deal in the Artwork without
 > restriction, including without limitation the rights to use, copy, modify,
 > merge, publish, distribute, sublicense, and/or sell copies of the Artwork,
 > and to permit persons to whom the Artwork is furnished to do so, subject to
 > the following conditions:
 >
 > The above copyright notice and this permission notice shall be included in
 > all copies or substantial portions of the Artwork.
 >
 > THE ARTWORK 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 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 THE ARTWORK OR THE USE OR OTHER DEALINGS IN THE ARTWORK."

Well, it looks more like a license at first sight. At second sight, you broke
it, there are problems. It is not an improvement, not over the LGPL and
hardly over the earlier version of your license. Even the disclaimer falls
away in some cases. 

Furthermore, the two main questions (BSD / copyleft + exception; homemade / 
existing) did not get answered in the best way. KDE deserves the best !

I strongly recommand NOT TO USE THIS LICENSE.

I'm fully pro using a well written, existing license. If needed with an 
add-on.

I already supplied one...

 >
 > Therefore I also appreciate your offer to help with this stuff. Due to the
 > fact that I'm not a lawyer myself I might have done some stuff unknowingly
 > wrong. But could you ask if something that you might have presumptions
 > about before doing wild guesses and accusations? Thank you.

I apologize for being harsh.

 >
 > Personally I want this stuff to be addressed much better. I'm very much
 > interested in this, so again: I'd really appreciate your help on this
 > topic.
 >
 > Therefore I'm trying to get the following features into KDE 3.1:
 >
 > - Extracting CREDITS and License information (or just plain comments) from
 > the images/wallpapers to display them in the wallpaper module.
 > - Showing the CREDITS and License information (or just plain comments) in
 > the properties dialog that you can get via RMB.

Interesting.

 > Greetings,
 > Tackat

Cordialemente,

Ante

_______________________________________________
kde-artists mailing list
kde-artists@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-artists
[prev in list] [next in list] [prev in thread] [next in thread]