RFC: "Artistic license" for Frontier scripting (repost)

[Samuel Reynolds]

Sorry--I meant this reply to go to the list, not just to Bruce.
 
bruce at perens.com wrote:
> 
> "Frontier" is most likely a registered trademark and your use of it in the
> name of a license probably needs authorization.
> 
> If you've modified the Artistic license, you should probably not call it
> "ARTISTIC" at all, so that you avoid confusion with the unmodified Artistic
> license.
 
Both good points, and both can be reasolved easily.
Although the Artistic License on opensource.org does differ
in some ways from perl's Artistic License.
Perhaps I could make it more general: call it the
"Scripting Open Source License (SOSL)," and restore
the reference to things "linked into" the Package
(which, although inappropriate to Frontier/Usertalk,
may be appropriate to other scripting languages).
 
> I consider the original Artistic license to be a somewhat "sloppy"
> license in that it makes restrictions and then provides ways to trivially
> circumvent them. For example, I can not sell your program separately,
> but I can sell it if I aggregate it with a 5-line "hello_world.c" . There's
> a bit more about that in http://perens.com/OSD.html , close to the end.
> 
> A short glance over it leads me to think that this license probably meets
> the OSD. I have one question you should consider:
> 
> Are your changes significant enough that they justify the creation of yet
> another license? Every time we get another license that's more confusion
> regarding the conflicts between them, and it's more load on the programmer
> and distribution creator who has to learn yet another license. Could you not
> make life easier for everyone by using an existing, pre-certified license?
 
There's the crux. I'd prefer to use one that's already approved
and in common use. And one of my goals is to provide an alternative
to the various not-quite-open-source licenses currently in use in
the Frontier scripting community. However...
 
All the OS licenses I've read refer to compiling, binding, linking,
and such--which do not apply to Frontier scripts and script packages
(referred to as suites in Frontier parlance). This includes the Artistic
License. That, and the fact that the Artistic license comes very close
to what I want otherwise, are what convinced me to write this modified
license.
 
GPL and LGPL appear to carry a lot of philosophical baggage. Worse,
they're verbose and turgid. IMO, GPL and LGPL impose an unacceptable
"load on the programmer and distribution creator". A lawyer might
love them, but I have yet to be able to wade through them.
And if I can't read and understand them, I'm not about to release
software using them.
 
What I want:
 
o  A license that the average software developer can read, understand,
   and, if necessary, clearly explain to his management.
o  Nobody can claim my package as their own.
o  Anyone can distribute my package without changes, provided
   it retains the original copyright statement.
o  Nobody can sell my package (unless they make separate
   arrangements with me).
o  In the event of my untimely demise, someone else can "adopt"
   my package to provide future development (i.e., I don't want
   it to die with me).
o  Anyone can modify my package, provided:
   o  It retains the original copyright statement.
   o  The modifications are clearly identified and described, and
      this information is included in the modified package.
   o  If they distribute the modified package (even as part of
      a larger program), the modifications must freely available.
   o  They provide a way for users to retrieve my original
      package for themselves.
o  Anyone can use my package in their own (freely-available
   or commercial) program at no cost, provided:
   o  They include in documentation/readme/splash screen
      a statement that the program uses my package, with
      my original copyright statement.
   o  They provide a way for users to retrieve my original
      package for themselves.
 
My intent is to use this license with script suites that
provide utility/support capabilities--the equivalent of
libraries in C/C++. If used with applications, it seems
to me that the requirement that modifications be freely
available would be sufficient to forbid the creation of
a 5-line hello-world wrapper and sale of the resultant
application.
 
- Sam
________________________________________
Samuel Reynolds
reynol at primenet.com
samuel_reynolds at csgsystems.com
Spinward Stars: http://www.spinwardstars.com/
Reynolds Virtual Workshop: http://www.primenet.com/~reynol/