[License-review] Berkeley Artistic License V5

Tue Dec 17 06:37:06 UTC 2024

I agree with the others' views that using "Berkeley" and "Artistic," 
when the license is neither, isn't acceptable.

I also don't believe the interpretation of the license is sufficiently 
predictable for the license to be approved.

Section 3 says "You may otherwise modify your copy of this Software in 
any way, provided that your modifications use this same license or do 
not distribute the resulting code." However, the concept is that if I 
make change beyond "bug fixes, portability fixes and ... modifications 
... to enable this software to work with modern tools, new hardware, new 
operating systems, etc.," I am supposed to change the Metadata section 
of the license to reflect that this is a Modified Version rather than 
the Standard Version. But when I make that change it becomes a different 
license, so how can it be under the "same license"? Listing 
"Contributors" as part of the license creates the same problem - if 
someone's name was added, is that the "same license"?

As Carlo mentioned, having a Standard Version and Modified Version with 
different terms is confusing, hard to follow, and seems to create more 
work for the person creating the Modified Version.

The only difference in treatment I could find is the obligation to 
"provide a method to obtain both the source of the Standard Version and 
the source of your Modified Version." This appears to create an 
obligation to maintain a separation between the Standard Version and the 
Modified Version and provide them separately. Making it more difficult, 
there is a lot of ambiguity around what could be considered the Standard 
Version, since it can also include "bug fixes, portability fixes and ... 
modifications ... to enable this software to work with modern tools, new 
hardware, new operating systems, etc." The scope of these changes is 
both imprecise and broad, making it difficult for someone to know 
whether they created a Standard Version or Modified Version.

It also creates a cascading problem. Suppose I create a Modified 
Version. I change the Project name - but what do I change it to? May I 
refer to it as a derivative work of the Standard Version? If the Project 
Name is AuroraForge, my inclination would be to name my version 
NewAuroraForge. Is that ok?

Now suppose I make a Modified Version of the Modified Version. This 
license says that the Original Project was Project AuroraForge and the 
name of the Project is BorealisForge. I name my project CelestialForge 
so I need to change the license. I now say that the Original Project 
name is BorealisForge and use Celestial Forge as the Project name. But 
what is the status of AuroraForge, which is the actual origin of 
everything? Is that now lost as the original version of the software?

Now I, CelestialForge have contributed my changes to AuroraForge but not 
all of them were accepted. The accepted changes become part of the 
Standard Version and are now called AuroraForge, but the unaccepted ones 
aren't part of AuroraForge. So how do I comply with the obligation to 
provide the two different codebases? Do I have to now modify my 
codebases to match what is now the current version of AuroraForge?

The also creates difficulty with Section 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." The way 
this is worded suggests that one can advertise the Modified Version as 
your own product. But how do you distinguish the two? If I have called 
my version NewAuroraForge, is that advertising the Standard Version 
because the name is incorporated into my name?

You use the term "origin point" without defining it. It's not a standard 
term of art in software, which means that there can be a great deal of 
argument about what an "origin point" is.

Because of the unintended complexity of this license, I do not believe 
that it should be approved.

Pam

Pamela S. Chestek (in my personal capacity)
Chestek Legal
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela at chesteklegal
www.chesteklegal.com

On 10/10/2024 1:48 AM, Carlo Piana wrote:
> Lucy,
>
> I will echo Josh's and Kevin's remarks, and add that I am never entirely fine with having one single "original" and treat the derivatives differently, not allowing them being "original" to other downstream project. I understand that this may fit under the general umbrella of #4, but I would regard #4 as an exception, rather than a rule as it refers only to retain the integrity of the source code, not to granting special rights or status to the originating work beyond that.
>
> Coming to a more technical analysis, the language of Section 5 seems a bit nontechnical, hard to parse and with some typos (like version "as a the project" -- last word non capitalized). While the first sentence seems an effort to comply with #4 by expressly allowing distribution of modified binary originating from patched software, not particularly problematic, the second part does not provide clear guidance to the reader as to what they are supposed to do.
>
> I note that the obligation/condition to provide a method to receive the Standard Version does not clarify whether it is the code from which the Modified Version has been forked or the current version, since Standard Version refers to a project, not to an identified codebase.  If the interpretation is the latter one, I think the license violates the OSD #1 at least. If it's the first, it should be stated more clearly (Artistic v2 here is different and the rationale for requiring keeping source of the Original Version current is more clear, since it refers to object code distributed /without/ the source, and not two separate codebases for one artifact, one not being the actual source of the distributed artifact).
>
> All in all the license does not seem to have been checked by a lawyer, nor that there is any mention of a legal review. Could you please clarify?
>
> https://opensource.org/licenses/review-process.
>
> All the best,
>
> Carlo (in his personal capacity)
>
> PS: as a generic remark, not specific to the submission, I take exception any time people bash on GPLv* for being complex. It certainly has some rough spots and verbosity, but creating an elegant copyleft license and avoid many loopholes in few words is no easy feat (or even possible).  Many who have attempted have simply removed guardrails and allowed loopholes. Others simply ignored they existed, and the result is often buggy, messy, ineffective and delusional.
>
>
>
>
> ----- Messaggio originale -----
>> Da: "Kevin P. Fleming" <lists.osi-license-review at kevin.km6g.us>
>> A: "License-review" <license-review at lists.opensource.org>
>> Inviato: Martedì, 8 ottobre 2024 13:21:26
>> Oggetto: Re: [License-review] Berkeley Artistic License V5
>> On Sat, Oct 5, 2024, at 06: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. It differs from GPL in that it's short, Clear,
>>> and accessible and it contains Metadata to credit developers within the
>>> license.
>> I understand that you've chosen to name this license 'Berkeley Artistic' because
>> you followed the style of the BSD licenses, but those licenses use that name
>> because they originated at Berkeley, not because someone liked that name :-)
>> If this license is not associated with UC Berkeley then it seems unwise to use
>> their name for the license, given that their name is a well-known 'brand' in
>> the context of software licenses.
>> _______________________________________________
>> The opinions expressed in this email are those of the sender and not necessarily
>> those of the Open Source Initiative. Communication from the Open Source
>> Initiative will be sent from an opensource.org email address.
>> License-review mailing list
>> License-review at lists.opensource.org
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org