[License-review] Subject: Re: License Approval: FARCL-1.0

[Pamela Chestek]

The problem I have with this license is that it's very context-specific 
-- there seems to be a particular problem that has arisen, and the 
license an attempt to solve the problem, but it's so specific in its 
drafting that the license won't make sense outside of this specific 
context.

You mention the license "explicitly addresses the legal 'grey area' of 
decompiling End-of-Life (EOL) formats (like .FLA) for the purpose of 
source code reconstruction." I'm not quite sure what that means. If an 
EOL format is under the MIT license, then without a doubt a use can 
"decompile, transpile, or convert archived assets into human-readable 
source code." So this license, applied at the time of development in 
contemplation of a later EOL, doesn't allow anything that an existing 
license would not also allow. You also say "decompile, transpile, or 
convert archived assets (/*including proprietary or legacy binary 
formats*/) into human-readable source code." But if the licenses on 
those existing proprietary or legacy binary formats don't permit the 
decompiling, etc., you can't change that by slapping a different license 
on the reverse-engineered work and you will still have breached the 
original license on the binary. Perhaps I've misunderstood what you're 
trying to do, but that goes back to my point that this appears to be a 
very context-specific license but without enough context to make it 
understandable.

It also has drafting problems that IMO mean it should not be approved. 
Section 1 is unclear because I read it as stating that attribution might 
have to be//moved around into new files, versus simply not altering 
existing files. The word "maintained" doesn't clarify the point; in 
contrast the Apache license says that you have to "retain" existing 
information and the GPLv3 says you have to "keep intact" the notices, 
both of which much more clearly state that you don't have to change 
anything, not that you have to create new files. However your sentence 
"This replaces the requirement for mandatory inline legal notices within 
every source file to facilitate interoperability between different 
technical formats" suggests that it is instead a duty to move them 
around based on the technical format. So I'm not sure what is meant here.

There are other interpretative problems. Some of your paragraphs have an 
explanatory sentence, but these are going to create more problems than 
they solve. For example, in the second paragraph you say "This is 
recognized as a necessary process for digital preservation, technical 
study, and long-term interoperability." Is that a list limiting the 
decompiling, etc. to only those purposes? I promise you that, if this 
license was the subject of a legal claim (say for example the software 
was decompiled to use for AI training), whether this list is exemplary 
or comprehensive would be disputed and litigated.

What is the value of the word "digital" before "works" in the license 
grant? That is another example of a word that would be litigated because 
of its mere presence. Under our rules of contract interpretation every 
word is there because it has meaning, so a court may assign it meaning 
even if it's really just a throwaway (I doubt this license would be used 
for anything but digital works). For example, a court may decide that 
"digital " is there to distinguish "code" from "illustrations," and so 
the license doesn't apply to illustrations contained in the work.

Contract drafting is not a creative writing exercise; there are very 
specific rules of construction and interpretation that need to be 
followed. If the drafter is not versed in those rules, then the legal 
interpretation of the license is not going to be what the drafter thinks 
it is, even if they believe that the plain language is clear.

Pam

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


On 2/12/2026 4:15 PM, Bauti el cyerborg Shitpost wrote:
> Dear OSI License-Review Committee,
>
> Thank you for the detailed feedback. I have significantly revised the 
> FARCL-1.0 to address the concerns regarding OSD compliance, undefined 
> roles, and legal terminology.
>
> Below is the updated text of the license, followed by a summary of how 
> this version resolves the previous issues:
>
> ============================================================
> Free Archive License (FARCL-1.0)
> ============================================================
>
> Copyright (c) <YEAR>, <USERNAME>
>
> Permission is hereby granted, free of charge, to any person obtaining 
> a copy of this digital work, to use, copy, modify, merge, and 
> distribute the work, subject to the following conditions:
>
> 1. FLEXIBLE ACCREDITATION: Attribution must be maintained in a 
> dedicated CREDITS file, project README, or within the work's metadata. 
> This replaces the requirement for mandatory inline legal notices 
> within every source file to facilitate interoperability between 
> different technical formats.
>
> 2. OPEN CONVERSION: Users are explicitly authorized to decompile, 
> transpile, or convert archived assets (including proprietary or legacy 
> binary formats) into human-readable source code. This is recognized as 
> a necessary process for digital preservation, technical study, and 
> long-term interoperability.
>
> 3. REDISTRIBUTION: Any public fork or redistribution of this work, in 
> its original or converted form, must retain the original copyright 
> notice and identify the work as a FARCL-licensed archive to ensure the 
> integrity of its origin.
>
> 4. SOURCE PERSISTENCE: Source code derived from the conversion of 
> assets under this license shall inherit these same permissions. This 
> ensures that data recovered from closed formats remains accessible and 
> cannot be re-restricted under more hardware-limited or proprietary terms.
>
> DISCLAIMER: THIS WORK IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY 
> KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES 
> OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
> NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE 
> LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION 
> OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION 
> WITH THE WORK OR THE USE OR OTHER DEALINGS IN THE WORK.
>
> ============================================================
>
> Summary of Changes & Clarifications:
>
> - Elimination of Undefined Roles: The term "Archivist" has been 
> removed. The license now uses standard legal subjects ("Person", 
> "User") and "Username", which is the de facto identity standard in 
> communities like GitHub/GitLab.
>
> - Compliance with OSD 6 (No Discrimination): The prohibition of binary 
> distribution has been removed. The license now grants an explicit 
> additional right for conversion/decompilation, ensuring it does not 
> restrict fields of endeavor but empowers preservation.
>
> - Justification over Existing Licenses: Unlike MIT or BSD, the 
> FARCL-1.0 explicitly addresses the legal "grey area" of decompiling 
> End-of-Life (EOL) formats (like .FLA) for the purpose of source code 
> reconstruction. This provides a specific legal shield for 
> preservationists that general-purpose licenses lack.
>
> - Expected Adopters: This license is aimed at the Flashpoint Archive 
> community, the Software Preservation Network, and developers using 
> tools like Ruffle or OpenFL to migrate legacy assets into open standards.
>
> I believe this revision is now fully aligned with the Open Source 
> Definition. I look forward to further discussion.
>
> Best regards,
>
> B4uti4GD
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260216/2a8aa6b3/attachment.htm>