New Version of Artistic License

[Chris Gehlker]

On 11/5/01 7:46 PM, "David Johnson" <david at usermode.org> wrote:

> On Monday 05 November 2001 01:43 pm, Chris Gehlker wrote:
> 
>> For those of you who aren't ObjC hackers, should there be any such, they
>> way you modify a program about 80% of the time is to declare and implement
>> a new category on some existing class. In most of the remaining cases, you
>> just derive a new class from an existing class. It's very rare to modify
>> the actual implementation of a class.
> 
> *Ideally* that's the way C++ works as well :-)

I have a love/hate relationship with C++ as well (really more love than
hate). There is a difference though. Consider an inheritance tree like this:

                            A
                    |-------|----|
                    B            C
                            |----|----|
                            D         E
                              |-------|------|
                              F       G      H

In C++ if Jane finds that Bill's code was deficient somehow at Class C,
(maybe she just found a bug or came up with a clever optimization) she
pretty much has to modify the original code at C. In ObjC she just declares
a category on C and the dynamic linker makes sure the change is inherited by
D, E, F, G and H. What's relevant here is that ObjC projects tend to more
and smaller files with there own author and copyright notice.
> 
>> Anyway, I edited the Artistic License and developed something I'm calling
>> the Objective-C Artistic License. Mostly I changed "Package" to "Framework"
>> to fit ObjC usage but I also changed to wording a little to fit the
>> practice in the ObjC community. I also copied the last clause from one of
>> the newer licenses under the assumption that the lawyers have learned
>> something.
> 
> What exactly are you looking for in a license? Perhaps we can give you
> pointers to an existing license that you can use as-is. A LOT of people don't
> like the current Artistic License, and it's typically used as part of a
> AL/GPL dual license, and rarely by itself.

Darn good question!

I have no objection at all to dual license with GPL. But what I was looking
for was something that says "You must give back where you take but not
more." Or maybe I should say that I'm trying to make a distinction between
using and appropriating the project.

I think a concrete example will help. The project itself is a multimedia
Framework with some apps that are really just demos of the Framework. One of
the messages in the Framework is transcode and if the recipient of that
message happens to be an image file it puts up a dialog box asking for some
basic parameters like output file path, color depth, output format, etc. and
then clones itself in the preferred format.

Now let's suppose some programmer writing "Greeting Card Maker", a closed
source program which works internally with Photoshop format. Suppose further
she wants to support scanned images. Transcode already supports conversion
from TIFF to Photoshop so it could be what she needs. I would like this
programmer to feel as comfortable using the Framework as if it were under a
BSD license. Now suppose that she discovers some optimization that makes
transcode twice as fast. I'm really trying to encourage her to give this new
version of transcode back so it can be incorporated in the next version of
the Framework.

The reason I find the Artistic License appealing is simply that it tries to
draw a similar distinction and it seems to have been successful. People
understand that they can use Perl to write programs and do whatever they
want with the program. They cannot extend Perl, call it Opal, and take it
closed source. And if they come up with a neat extension  to Perl while
writing a proprietary program, the program is theirs but the extension to
Perl belongs to the community. The other licenses I looked at were jut too
either/or.

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3