[License-review] Berkeley Artistic License V5

[Josh Berkus]

On 10/5/24 03:43, Lucy Brown via License-review wrote:
> This is a submission of Berkeley Artistic License v5.
> This is a “New” License that was made as a means of creating a more 
> legible, correct, and up to date variation of Artistic License V1, that 
> has been conformed to my personal interpretation of the BSD, (Berkeley), 
> style. It differs from BSD-4 and Artistic v2 in that it is not re- 
> licensable and it is copyleft rather than permissive. 

Hey, Lucy.  I thought I'd give you some direct feedback on your license 
draft, which you appear to have devoted some thought to.   Note that I 
am not an attorney, and my feedback is as a developer member of License 
Review, and constitutes neither approval nor a requirement that you 
follow it.  It's just that you seem to have a fairly clear idea of what 
you want to achieve and I have tweaks to suggest.

> It differs from 
> GPL in that it's short, Clear, and accessible and it contains Metadata 
> to credit developers within the license.

Are you aware of the history of the Artistic license?  1.0 was replaced 
by 2.0 because of several problems with 1.0 -- particularly 
compatibility with other OSS licenses.  That was why so much Perl was 
dual licensed Artistic1.0/GPLv2.

> 2. You may apply bug fixes, portability fixes and other modifications 
> from the Project Developer or other developers (including yourself) to 
> enable this software to work with modern tools, new hardware, new 
> operating systems, etc. A Software modified in such a way may still be 
> considered the Standard Version.

I realize you took this paragraph from Artistic1.0, but I'll point out 
this language was, in my opinion, one of the problems with the Artistic 
license.  It gives downstream modifiers a loophole to not re-distribute 
changes they've made for platform compatibility.  This is not an OSD 
violation, but it may not have the effect you want with the license.  It 
was written at a time when distributing modified code was high-effort 
(think usenet and FTP), but is really not applicable now.

> 4. You may choose to add your name to the contributors list, to allow 
> the Project Developer to credit you for your modifications in the 
> Standard Version of the Software.

This is a strange clause, can you explain the intent of it?  It's just 
an odd thing to include in a license, period.  Shouldn't it be part of 
the project's Contributing Guide?

> 5. You may distribute your modified copy of this Software in executable 
> form, provided that you make it clear that your distribution of this 
> code is modified, provide a copy of this license, and provide a method 
> to obtain both the source of the Standard Version and the source of your 
> Modified Version. You must also modify your license to point to this 
> project as the origin point, labeling your modified version as a the 
> project, moving any prior origin point to be the primary contributor.

Am I reading correctly that you want downstream distributors of modified 
versions to remove all reference to the upstream version?

> 6. You may distribute this Software, with or without fee, provided that 
> you do not advertise the Standard Version of this Software as a product 
> of your own.

You might want to include the aggregation language from Artistic1.0 in this:

However, you may distribute this Package in aggregate with other 
(possibly commercial) programs as part of a larger (possibly commercial) 
software distribution provided that you do not advertise this Package as 
a product of your own.

... because otherwise it leaves things like Linux Distributions or 
developer stacks in a grey area.

-- 
Josh Berkus