<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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. <br>
<br>
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 (<i><b>including
proprietary or legacy binary formats</b></i>) 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.<br>
<br>
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<i> </i>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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Pam<br>
<br>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
<a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
<br>
</div>
<br>
<div class="moz-cite-prefix">On 2/12/2026 4:15 PM, Bauti el cyerborg
Shitpost wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAP0kKs9Cfk5VXHxLgOxkAg=W_5Jnpm7zaTyRQE8cnBKAKfcqDQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Dear OSI License-Review Committee,<br>
<br>
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. <br>
<br>
Below is the updated text of the license, followed by a summary
of how this version resolves the previous issues:<br>
<br>
============================================================<br>
Free Archive License (FARCL-1.0)<br>
============================================================<br>
<br>
Copyright (c) <YEAR>, <USERNAME><br>
<br>
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:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
============================================================<br>
<br>
Summary of Changes & Clarifications:<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
I believe this revision is now fully aligned with the Open
Source Definition. I look forward to further discussion.<br>
<br>
Best regards,<br>
<br>
B4uti4GD<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</body>
</html>