<div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 7, 2024 at 17:14 Josh Berkus <josh_at_berkus_org_c4q6k8zbc046g9_w4sd8035@icloud.com> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; padding-left: 1ex; border-left-color: rgb(204, 204, 204);" dir="auto"><span>Are you aware of the history of the Artistic license?  1.0 was replaced </span><span>by 2.0 because of several problems with 1.0 -- particularly </span><span>compatibility with other OSS licenses.  That was why so much Perl was </span><span>dual licensed Artistic1.0/GPLv2.</span><p></p></blockquote><div dir="auto">Yes. I’m aware of the history of Artistic V1 and its GPL incompatibility. There is a reason why I want to keep that functionality as I don’t particularly enjoy the idea that GPL must be the only Copyleft license. I do not view GPL incompatible as a bug.</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; padding-left: 1ex; border-left-color: rgb(204, 204, 204);" dir="auto"><p dir="auto">> 2. You may apply bug fixes, portability fixes and other modifications <br>> from the Project Developer or other developers (including yourself) to <br>> enable this software to work with modern tools, new hardware, new <br>> operating systems, etc. A Software modified in such a way may still be <br>> considered the Standard Version.</p><p dir="auto">I realize you took this paragraph from Artistic1.0, but I'll point out <br>this language was, in my opinion, one of the problems with the Artistic <br>license.  It gives downstream modifiers a loophole to not re-distribute <br>changes they've made for platform compatibility.  This is not an OSD <br>violation, but it may not have the effect you want with the license.  It <br>was written at a time when distributing modified code was high-effort <br>(think usenet and FTP), but is really not applicable now.</p></blockquote><div dir="auto">The intent is to allow people who make updates to the software to retain the same functionality as other distributions of the standard version in future versions if the original creator is unable to approve of their modifications. I’ve been dealing with AEE, (a project still licensed under Artistic 1.0) and that particular project has been a rather interesting one. The actual clause which provides this loop hole is paragraph 3 section B of artistic. Which says outright: <div dir="auto">3. You may otherwise modify this package if you:</div><div>b) use the modified Package only within your corporation or organization.</div></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; padding-left: 1ex; border-left-color: rgb(204, 204, 204);" dir="auto"><p>This is a strange clause, can you explain the intent of it?  It's just <br>an odd thing to include in a license, period.  Shouldn't it be part of <br>the project's Contributing Guide?</p></blockquote><div dir="auto">The metadata subsection is intended to track contributions from previous projects and other contributors. This license acts as a reference in case of the destruction of git or any other VCS and/or their tracking history.</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; padding-left: 1ex; border-left-color: rgb(204, 204, 204);" dir="auto"><p dir="auto"></p><p>> 5. You may distribute your modified copy of this Software in executable <br>> form, provided that you make it clear that your distribution of this <br>> code is modified, provide a copy of this license, and provide a method <br>> to obtain both the source of the Standard Version and the source of your <br>> Modified Version. You must also modify your license to point to this <br>> project as the origin point, labeling your modified version as a the <br>> project, moving any prior origin point to be the primary contributor.</p><p>Am I reading correctly that you want downstream distributors of modified <br>versions to remove all reference to the upstream version?</p></blockquote><div dir="auto">No, it’s requesting that if you become a 2nd generation or higher hard fork, (see the history of Prism Launcher or Xorg), that you move the original project’s information from the “Original Project:/Original Project Developer:” section to the contributor section. The project which was forked from will be erased if this method is not followed. An example of the metadata section is included in the template. Here’s an example using Prism Launcher’s history, as I’m aware of it. </div><div dir="auto">“Project: Prism Launcher</div><div dir="auto">Project Developer: Prism Launcher Community</div><div dir="auto">Original Project: PolyMC</div><div dir="auto">Original Project Developer: PolyMC Community</div><div dir="auto">Contributors: MultiMC Community (MultiMC);”</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; padding-left: 1ex; border-left-color: rgb(204, 204, 204);" dir="auto"><p dir="auto"></p><p>> 6. You may distribute this Software, with or without fee, provided that <br>> you do not advertise the Standard Version of this Software as a product <br>> of your own.</p><p>You might want to include the aggregation language from Artistic1.0 in this:</p><p>However, you may distribute this Package in aggregate with other <br>(possibly commercial) programs as part of a larger (possibly commercial) <br>software distribution provided that you do not advertise this Package as <br>a product of your own.</p><p>... because otherwise it leaves things like Linux Distributions or <br>developer stacks in a grey area.</p></blockquote><div dir="auto"><br></div><div dir="auto">If the license was as originally written, the whole paragraph which contained that clause would be included. The removal of the  “You may not charge a fee for this software itself”, causes that paragraph to instead be  compressible to a simple “You may distribute this software, with or without fee, provided that you do not advertise this Package as a
product of your own.” I do understand that it can be more explicit about the </div><div dir="auto"><br></div><div dir="auto">Your concerns about paragraph two are valid but I believe that only requires an alteration of paragraph 1  or 2 to enforce that any distribution in executable form of the standard version is accompanied by a means to receive the source code of the standard version with those modifications. I am more than willing to encourage people to create a pull request on the license’s GitHub repository with changes to that effect. Currently, however, I am a bit tired and tomorrow I will be working on getting my certification as a Linux sysadmin. The GitHub  can be found at anoraktrend/Berkeley-Artistic. The license is under CC0 but you can edit the example license to include credit to yourself for your modifications.</div><div dir="auto"><br></div><div dir="auto">Lucy Brown.</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; padding-left: 1ex; border-left-color: rgb(204, 204, 204);" dir="auto"><p dir="auto"></p></blockquote></div></div></div>