Simplified Artistic License [osd]

[Nathan Kelley]

To OSI License Discussion subscribers,

>> From: Robert Samuel White <webmaster at enetwizard.net>,
> From: Karsten M. Self <kmself at ix.netcom.com>,

>> Larry, I can't afford an attorney, as you already know.  And I cannot 
>> use one of the existing licenses because it does not feel right to me 
>> to do so.
>
> These are constraints imposed by you.  You're welcome to live with the 
> consequences.  Don't ask the rest of us to be particularly concerned.
>
> I'd strongly suggest relaxing one or more of your constraints.

Why?

I agree with the point about consulting a legal professional; this is 
something important to do to ensure that a license is legally worth the 
bytes its' transmitted on.

However, like Apple, IBM, and Sun, Robert has his own reasons for 
wanting to create a new license rather than use an existing one. What's 
good for big business has to be good for small business and even 
individual developers, otherwise we all look like hypocrites when we 
turn down licenses on the basis of "No Discrimination".

Yes, we don't need every single developer dreaming up their own 
license. Most won't go to the trouble unless they really need a new 
license, and where they have we've been able to call their attention to 
a suitable alternative that they have then adopted. Robert has cited 
legitimate reasons why he needs a new license...

...for the original Modified Artistic (eCAS) License:

>> My license is loosely based upon the Artistic License and the PHP 
>> License <http://www.php.net/license/3_0.txt>.
>>
>> The Artistic License is most suitable to my wishes because I wish to 
>> maintain some semblance of artistic control over the package while 
>> giving the users of the package the right to use and distribute the 
>> package in a more-or-less customary fashion, plus the right to make 
>> reasonable modifications.
>>
>> The Artistic License does not suffice because (A) I find it to be 
>> written in a very complicated fashion (I don't even understand some 
>> of the language contained within it); (B) it was largely designed for 
>> Perl and C programmers and my package is written entirely in PHP; and 
>> (C) it contains too many conditions that I do not feel are necessary.

...for the new Simplified Artistic License, created in response to the 
resistance to approving the license despite the license being OSD 
compliant, and promises to the author that it would happen:

>> I believe that there is a need for it, for several reasons: (1) the 
>> Artistic License has some archaic conditions within it, (2) it has 
>> too many restrictions that are unnecessary to modern day development, 
>> (3) it was designed for developers of Perl and artists develop in 
>> many different languages.

So far, the points behind the need for either of these licenses have 
not been answered by anyone citing a similar suitable license (only the 
AFL has been suggested, and Larry Rosen's post on that shows why it is 
unsuitable); instead, we've helped him adjust his licenses to become 
OSD compliant, and have then complained that him making these 
adjustments has formed a "moving target", and when accepted as OSD 
compliant rejected his license anyway on the grounds that he's not an 
open-source "Who's Who" personality.

Huh?

> The sense that you _are_ committed is in that your license sets the 
> tone for expectations of others.  If you license under a particular 
> set of terms, then change your mind down the road -- whether this is 
> toward more or less liberal terms -- you will almost certainly receive 
> much and harsh criticism. There are a number of examples of sole 
> authors of code who've had licensing terms of their own authorship, 
> who've created significant downstream issues for users of their 
> software by either changing terms or interpretation of their license.

That's why OSI certification is important; an OSI-certified license may 
not be compatible with all other OSI-certified licenses, but the fact 
that it is OSI-certified gives you an immediate idea of what to expect, 
and what options you know the license gives you. Everyone here would be 
rightly suspicious of a license that wasn't OSI-certified that claimed 
to be "open source", and rightly so.

If an author is silly enough to then significantly change the terms of 
their license, then that's their own lookout; it's not our problem. So 
far, the terms of either license has not changed in any significant way 
during the approval process...

> Both end-users and developers should be extremely averse to new 
> licenses, particularly those which emerge from sources or 
> organizations which have little prior visibility or track record.  
> Terms of the "major" software licenses are well established, well 
> understood, and would seem to be largely stable due to institutional 
> pressures.  While the licenses may not be ideal for all uses, they are 
> good enough for many uses, and a reasonable compromise of interests.

This is the discriminatory approach I was lamenting above. We can't 
take a one-size-fits-all approach to license approval, otherwise we 
begin to share the same lack of forward thinking that has kept many 
proprietary vendors in the dark ages.

Cheers, Nathan.

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