Publish the ARL Form - 266.pdf as a plaintext based format

[marctjones]

Can the ARL Form - 266 be published in a plain text format such as markdown. It looks like now the PDF in GitHub is not the correct one. Not sure if it is GitHub displaying PDF problem or the wrong PDF was uploaded. But a place holder pdf is also present when you down the repository as a ZIP.

[ckaran]

Try downloading the PDF and opening it in Acrobat; the form opens correctly with Reader, but not on the web, nor does it open correctly with Apple Preview. As near as I can tell, this is because the form is using PDF 1.7 instead of an earlier version. We can't downgrade because it supports digital signatures, which is something we'd really like to keep doing if we can. If that doesn't work for most people, then we'll downgrade.

Please let me know if this works for you, if it does I'll close this issue, otherwise I'll keep researching how to fix things for you.

[andrewgdunn]

I'd be willing to take a swag at transitioning the agreement to LaTeX or markdown. I think that being a PDF is going to be a barrier to entry for people contributing to the repository.

[ckaran]

The original was in LaTeX, but had to be translated into a form that could be digitally signed. Do you know how to get digital signatures to work under LaTeX? I never figured it out...

Beyond that, it probably has to be a PDF; Army mandate, which ARL has to comply with.

[andrewgdunn]

Can we restructure the repository and place the PDF in an archival folder, then introduce the LaTex source and use a tag to indicate this introduction was the actual signed edition. Then we can work on a developmental version in plaintext where tracking everything becomes possible, and when you need to seek an update set of signatures we tag again.

If you're open to this idea I'd nominate @enckse for assisting in repository management. You've got both of our DoD in band communication and we're happy to assist.

[ckaran]

I'm actually planning on doing something like that already! :) My plan yesterday (before the code.mil stuff hit) was to slightly update the policy to state that the master branch is always the official policy, and that other branches are solely for discussion and development. At that point, we can move the real work to the develop branch and do what we need to there. Once we get everything to the point that we're happy and I think the Director will sign off on it, I'll get his approval and we can do the merge back into master.

The only other things I'm planning on doing to master are hotfixes. I got a bug report that the email address on Form 266 is broken, so I need to investigate what the problem is. If it's a problem with the form itself, then I'll fix that on the master branch, along with any other issues that crop up (spelling/grammar errors, minor tweaks to make things clearer, etc.)

For what it's worth, Form 266 is a temporary fix; our long-term solution is to develop a web service hosted at ARL that collects the information on Form 266. Although now that I think of it... if you can figure out a way to use LaTeX to created a fully digitally signed form, it may be possible for the server to fill out the form, sign it with ARL's keys, and email that to the contributor. That way the contributor has a strong acknowledgement from ARL that we received their form; this could be useful to the contributor because there are clauses in there that protect them as well as the Government. Do you and @enckse want to give that a shot?

[marctjones]

@ckaran Thanks for the follow up. I guess I should have done a little bit more research before reporting the "bug."

At your suggestion I cloned the repo to my Linux machine. Does not display with any of my PDF readers on Linux. I booted up my Windows VM and it did not display in any of the default PDF readers that come with Windows, Office or Chrome. So I finally Installed Adobe Acrobat Reader on Windows. And, yup, that works. So I think you are right it is the certificates that prevent any other PDF reader besides Acrobat Reader from working. Seems a shame, but the dangers of using proprietary extensions I guess. ;)

If the original is from a Latex file, I would suggest including the latex source along with a script to build to a PDF to meet the ARL requirements. If ARL requires a digitally signed PDF, I would suggest it would be friendlier to people if the text of the form were visible without having to download the whole repo and open the PDF in Acrobat Reader. Maybe include a non-signed version of the PDF. Or if it is Latex, ask pandoc to make you a PDF and a markdown version of the Latex document as part of the build process. Then make it clear (and enforce the rule) that people need to digitally sign the contributor agreement before it is submitted.

If ARL is interested in signatures (but not bound to Adobe certificates) I think a more FOSS-y way would be to embrace PGP signatures rather than Adobe certificates. One of the nice things about PGP is that you can include signature blocks in plaintext documents. Enigmail and newer services like Keybase.io do a pretty good job of making PGP usable for the average human.

• Git & PGP
• Slightly dated article on using PGP signatures

But using PGP instead might be a bigger policy question then is appropriate for an issue here if Adobe certificates are specifically required currently.

[andrewgdunn]

If the entire hang up is on signing then I'd suggest reconsidering how we achieve the signed/released form of the manuscript. Ultimately I think you are using a physically signed cover letter? If necessary to have a signature page we could consider using the LaTeX exam package, or something else like that, and have a specific document separate from the primary manuscript just for signoff. We can then track that when we do a tag/release...

I'd suggest updating the policy to state that the most modern tagged release is the official policy. Tagging allows you to run master as an aggregation of the currently accepted changes that have not yet been signed off on the necessary stakeholders. So when you aggregate from master into a "release", you tag and take it to the director, it has a running change-log of all accepted merges, easier to review. The primary benefit is it shows people what the intent is for the next release, the features of the agreement to be used in the future.

As we both know there is sometimes out of band resistance to pushing something through all the required signoffs, but it would be easier for an organization like ARL or the White House to know that signing off on a new release is important if there were other agencies that were able to say that they couldn't get the code to the public until the signed approval of tag X. For example, if we had an internal codebase and wanted to release with an upcoming version of this agreement, we could have our internal leadership reach out to ARL to let them know the import of signing for a specific feature.

As @marctjones suggests there are other ways to do signing that are more accepted by the upstream community. I don't know that we'll get your director to publish his GPG keys though :laughing:. Likely the best way to approach this is to start breaking up this thing into several tex files and doing builds/tags for release.

As @marctjones points out, if you're on a Linux machine you're not even able to read this. I have an internally sneaker'ed copy, otherwise I'd have no idea what was going on inside this repo.

[seanenck]

I do think, regardless of changes, having the raw source (and a way to build it per what @marctjones suggests) would be a good way to get people (without requiring adobe + windows) to at least be able to see what is (or is not) in this repository at any point.

[ckaran]

@marctjones I'm sorry, I was unclear. The way back in the dim dark past version was in LaTeX. The current version is owned and maintained by personnel within ARL that are tasked with maintaining ARL's forms. They don't use LaTeX; they use some other Adobe program whose name I forget (LiveCycle? I honestly can't remember) to create and maintain the forms. That isn't going to change. The only possible solution I can see is if there is a way to make LaTeX:

1. Create a form that looks exactly like what has been downloaded.
2. Create a form that supports digital signatures.

All that said, the form is actually not that important. It was always intended to be a temporary fix while we figure out how to stand up a secure web service that people can be pointed to. Once that problem is solved, the form will be deprecated. That said, nobody has the time or budget right now to stand up such a server, and until and unless the policy gets a lot of positive exposure, no-one is going to allocate budget for it in the future.

As for PGP, etc., the problem is that the form MUST follow Army regs, which for right now are PDF with the extensions that Adobe chose. If you know of different regs that I can point to that let me use PGP, etc., then please tell me where I can find them!

@storrgie Actually, the goal is to get away from paper as far as possible. I hope that goal will be accomplished sooner rather than later.

As for the tagging process, I see where you're coming from, but as far as I know GitHub always lands you on the branch (defaults to master) when you search for a project, correct? Do you know of a way of setting the landing to a tag instead? I poked around a bit, but can't find it. My concern is that people will assume that master is the current policy, even if we clearly mark that the tag is the current policy (The whole 'no-one ever reads the manual' problem).

[seanenck]

As far as I know/can tell you can only set branches as the "default" for a repo and not tags. I agree that is master is not what you want people to see by default marking it as such isn't enough.

You could switch to a "master", "release" (or "stable" or some other similar term) and actually set that as the default landing page that only gets "approved" changes merged from other branches into it (after whatever review is necessary). If you wanted to with that, at least, you could have the default be "release" and have it point to an artifact/tag pdf that you only update on an actual release (which would still generate a tag) under the releases tab.

[ckaran]

@enckse If I do that, will the new default branch become the landing page and the branch against which pull requests are automatically made?

[seanenck]

it will become the "default" for those actions in general. basically if you had a "release" branch when people forked they would default to "release" as well which means that pull requests would also be in the same boat and hit "release" if done against it. Summarized: if you changed from master to something else it seems likely that the problem would just be "renamed" from "master" => (I'm guessing this isn't what is desired). I guess at some point you could then mark "release" as protected and/or something similar. It seems likely that "development" can be harder but when people come to look/find the form(s) that it should be really easy/quick.

Given that - I could probably play with it more thoroughly at some point but it seems like there would be unintended consequences that might be a net loss to trying to make sure what the default page is and where development is done and what artifact is up-to-date for consuming entities.

[ckaran]

OK, in that case I'm going to leave master as the default, but protect it. All work will be on other branches, which will eventually be accepted or rejected and merged into master.

Going back to the original discussion, if any of you know how to make a form in LaTeX that can be digitally signed like the current Form 266, please let me know, and we can work on putting together a LaTeX version of the form. Otherwise we're stuck with what we currently have due to Army regs.

[seanenck]

instructions here using the digsig method I was able to create a signable field in a pdf in Arch Linux

Edit: to see the signing field you still have to use Adobe on Windows (fyi)

[ckaran]

@enckse Have you been able to test to see if it locks the other fields after you sign it? The fact that it can only be seen in Windows is lamentable...

Just to double check, will this form be useful to people outside of ARL? If so, I can ask if OMB will create and circulate its own version. As far as I'm concerned, it is just a temporary hack until we've got the web service up and running, which is why I'm not putting as much effort into converting it as you guys are.

[ckaran]

@marctjones @storrgie @enckse @fulldecent last night I realized that this issue is more important than I was giving it credit for; this project (the ARL policy) is now an open source project[1]. That means that if I accept your work on this, I actually need all of you to execute and return a copy of a Form 266. Could each of you go ahead and sign and email back a copy of it? I'm on the mailing list that is on the form, so as soon as you email it, I'll get a copy.

In the meantime, I'll talk with the people that maintain the form and see if they'll accept our generating a LaTeX version back for maintenance; even if they don't, if they accept the PDF form back, that will be good enough on ARL's end (I think).

[1] There are projects that are getting open sourced internally, but the process is pretty long, so I was hoping that the efforts on the server would be completed before Form 266 ever saw any real use. However, it looks like I was wrong about the timing of it!

[fulldecent]

@ckaran I have executed and emailed the form to the address listed in the form.

[seanenck]

@ckaran - did submit my 266 to the email box for you.

In regards to this ticket, I created a simple form with a textbox, checkbox, and signing field (just to see) it latex and unless (I had to do this in adobe when signing) I manually marked the "Lock fields" checkbox when applying my signature in adobe, the fields did not lock :/

[ckaran]

@enckse That sounds like the problems I had before as well. The issue is that we need to prove that we didn't tamper with the form after it was signed, which is why locking is important, as are proper digital signatures. If you're able to figure out a way, that would be perfect, otherwise we might need to wait until the server is up and running (which may take a significant period of time).

[fulldecent]

Here is a markdown version of ARL form 266. Adobe Acrobat is preferred way to open this document and Adobe disables copy/paste, print to PDF and copy to MS Word features. To copy the text out I used Inkscape and manually formatted to Markdown using Textmate. I am pasting here to save others the trouble if they were trying to do the same thing.

---

ARL CONTRIBUTOR LICENSE AGREEMENT

(For use of this form, see ARL Memo 25-88; Form Proponent: RDRL-CII-A)

PURPOSE:

In order for the United States Government (USG), as represented by the U.S Army Research Laboratory (ARL), to accept Contributions from non-Federal Contributors into any projects that it controls, it must assure itself that any necessary permissions to use certain intellectual property (IP) rights are granted.

PRIVACY ACT NOTIFICATION

AUTHORITY: 10 U.S.C. 3013, Secretary of the Army; 5 U.S.C. 301, Departmental Regulations, Department of Defense Instruction 5535.8, DoD Technology Transfer Program and Army Regulation 27-60, Intellectual Property.

ROUTINE USES: In addition to those disclosures generally permitted under 5 U.S.C 552a(b) of the Privacy Act, these records or informationcontained therein may specifically be disclosed outside the DoD as a routine use pursuant to 5 U.S.C 552a(b)(3) as follows: The U.S. Patentand Trademark Office, Department of Commerce, and/or to the Copyright Office, Library of Congress. In the event of legal proceedings andlitigation, information may be disclosed to the Civil Division, Department of Justice. Parties to a licensing arrangement have access to thespecific files involved. The 'Blanket Routine Uses' set forth at the beginning of the Army's compilation of systems of records notices alsoapply to this system.

DISCLOSURE: Your disclosure of the requested information is voluntary. However failure to furnish the requested information will prevent ARL from considering your contributions.

INSTRUCTIONS

Fill out each of the fields below as appropriate, and return to ARL via one of the following methods:

E-mail (Preferred):

usarmy.adelphi.rdecom-arl.list.usarmy-adelphi-md-rdecom-arl-list@mail.mil

Postal Address:

U.S Army Research Laboratory ATTN: RDRL-DPT 2800 Powder Mill Road Adelphi, MD 20783-1138 USA

If the CLA is signed with pen and is being returned by e-mail, then it must be scanned so that the USG has a copy of the Contributor's signature. Contributors that have certificates from a recognized Certificate Authority may choose to sign their forms electronically, and e-mail the signed form to ARL. In general, ARL prefers that the CLA be digitally signed and e-mailed to ARL.

Please read this document carefully before signing, and keep a copy for your records.

AGREEMENT

The terms of the following agreement are for Contributions to the Project:

Project Name: [[ENTER THE PROJECT NAME HERE]]

You accept and agree to the following terms and conditions for Your present and future Contributions to the Project submitted to the USG, as represented by the U.S. Army Research Laboratory. Except for the license granted herein to the USG and recipients of software distributed by the USG, You reserve all right, title, and interest in and to Your Contributions.

1. Definitions. "You" (or "Your") shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with the USG. For authorized legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownershipof fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the USG for inclusion in, or documentation of, any of the products owned or managed by the USG (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the USG or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the USG for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the USG and to recipients of software distributed by the USG a perpetual, world-wide, non-exclusive, paid-up, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to the USG and to recipientsof software distributed by the USG a perpetual, worldwide, non-exclusive, paid-up, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or anyother entity (including a cross-claim or counterclaim in a lawsuit) alleging that Your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
4. You represent that you are legally entitled to grant the above licenses. If your employer(s) has rights to intellectual property that you create that includes Your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for Your Contributions to the USG, or that your employer has executed a separate CLA with the USG.
5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
7. Should You wish to submit work that is not Your original creation, You may submit it to the USG separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as "Submitted on behalf of a third-party: [named here]."
8. You agree to notify the USG of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
9. You acknowledge that you are providing Your Contribution to the USG on a gratuitous basis and that this does not create an obligation on the part of the USG of any kind, including, but not limited to: remuneration, incorporation of Your Contribution into a Government work, or any other obligation.
10. You agree that any CLA you submit to the USG may become part of the public record should the USG be ordered to release it by a valid court order, or other legal means. The USG is not under any obligation to inform you of this action before, during, or after it occurs.

CONTACT INFORMATION

Full Name: [[ENTER YOUR FULL NAME HERE]]

E-mail: [[ENTER YOUR EMAIL HERE]]

Postal Address: [[ENTER YOUR POSTAL ADDRESS HERE]]

Telephone Number: [[ENTER YOUR TELEPHONE NUMBER HERE]]

Fax Number: [[ENTER YOUR FAX NUMBER HERE]]

Signature: [[SIGN HERE]]

[ckaran]

@fulldecent Nice! Yeah, the software they used to create the original PDF is not what I would have chosen.

[ckaran]

@fulldecent With your permission, I'm going to copy that as markdown file in the form266 branch.

[fulldecent]

@ckaran Yes, please do.

[ckaran]

@fulldecent Done. My suggestion is that in the future you do this as a pull request so that you can get proper credit for it on GitHub, etc. I don't know if you work for an organization that tracks that kind of thing, but ARL is slowly moving towards that, so I want to make sure that credit is given where credit is due.

[fulldecent]

Thanks for the note. I am contributing in my capacity as a private citizen, I'm much more motivated by the project's mission than any credit. However, I will use PRs in the future since that is the preferred mechanism :-)

[ckaran]

I appreciate that you're willing to contribute without credit, but ARL is modeled as an academic organization; not giving credit where it's due is practically sociopathic!

[seanenck]

clearly opened the PR that shows the example of how to get this signing/locking as we would want it to be. If anyone can convert the form to tex (that is going to be out of my immediate area of expertise), that will get us to the next phase and I can actually see about making it sign-able.

[fulldecent]

\section{ARL CONTRIBUTOR LICENSE
AGREEMENT}\label{arl-contributor-license-agreement}

(For use of this form, see ARL Memo 25-88; Form Proponent: RDRL-CII-A)

\subsection{PURPOSE:}\label{purpose}

In order for the United States Government (USG), as represented by the
U.S Army Research Laboratory (ARL), to accept Contributions from
non-Federal Contributors into any projects that it controls, it must
assure itself that any necessary permissions to use certain intellectual
property (IP) rights are granted.

\subsection{PRIVACY ACT NOTIFICATION}\label{privacy-act-notification}

\emph{AUTHORITY}: 10 U.S.C. 3013, Secretary of the Army; 5 U.S.C. 301,
Departmental Regulations, Department of Defense Instruction 5535.8, DoD
Technology Transfer Program and Army Regulation 27-60, Intellectual
Property.

\emph{ROUTINE USES}: In addition to those disclosures generally
permitted under 5 U.S.C 552a(b) of the Privacy Act, these records or
informationcontained therein may specifically be disclosed outside the
DoD as a routine use pursuant to 5 U.S.C 552a(b)(3) as follows: The U.S.
Patentand Trademark Office, Department of Commerce, and/or to the
Copyright Office, Library of Congress. In the event of legal proceedings
andlitigation, information may be disclosed to the Civil Division,
Department of Justice. Parties to a licensing arrangement have access to
thespecific files involved. The `Blanket Routine Uses' set forth at the
beginning of the Army's compilation of systems of records notices
alsoapply to this system.

\emph{DISCLOSURE}: Your disclosure of the requested information is
voluntary. However failure to furnish the requested information will
prevent ARL from considering your contributions.

\subsection{INSTRUCTIONS}\label{instructions}

Fill out each of the fields below as appropriate, and return to ARL via
one of the following methods:

E-mail (Preferred):

usarmy.adelphi.rdecom-arl.list.usarmy-adelphi-md-rdecom-arl-list@mail.mil

Postal Address:

U.S Army Research Laboratory ATTN: RDRL-DPT 2800 Powder Mill Road
Adelphi, MD 20783-1138 USA

If the CLA is signed with pen and is being returned by e-mail, then it
must be scanned so that the USG has a copy of the Contributor's
signature. Contributors that have certificates from a recognized
Certificate Authority may choose to sign their forms electronically, and
e-mail the signed form to ARL. In general, ARL prefers that the CLA be
digitally signed and e-mailed to ARL.

Please read this document carefully before signing, and keep a copy for
your records.

\subsection{AGREEMENT}\label{agreement}

The terms of the following agreement are for Contributions to the
Project:

Project Name: {[}{[}ENTER THE PROJECT NAME HERE{]}{]}

You accept and agree to the following terms and conditions for Your
present and future Contributions to the Project submitted to the USG, as
represented by the U.S. Army Research Laboratory. Except for the license
granted herein to the USG and recipients of software distributed by the
USG, You reserve all right, title, and interest in and to Your
Contributions.

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
  \textbf{Definitions}. ``You'' (or ``Your'') shall mean the copyright
  owner or legal entity authorized by the copyright owner that is making
  this Agreement with the USG. For authorized legal entities, the entity
  making a Contribution and all other entities that control, are
  controlled by, or are under common control with that entity are
  considered to be a single Contributor. For the purposes of this
  definition, ``control'' means (i) the power, direct or indirect, to
  cause the direction or management of such entity, whether by contract
  or otherwise, or (ii) ownershipof fifty percent (50\%) or more of the
  outstanding shares, or (iii) beneficial ownership of such entity.
  ``Contribution'' shall mean any original work of authorship, including
  any modifications or additions to an existing work, that is
  intentionally submitted by You to the USG for inclusion in, or
  documentation of, any of the products owned or managed by the USG (the
  ``Work''). For the purposes of this definition, ``submitted'' means
  any form of electronic, verbal, or written communication sent to the
  USG or its representatives, including but not limited to communication
  on electronic mailing lists, source code control systems, and issue
  tracking systems that are managed by, or on behalf of, the USG for the
  purpose of discussing and improving the Work, but excluding
  communication that is conspicuously marked or otherwise designated in
  writing by You as ``Not a Contribution.''
\item
  \textbf{Grant of Copyright License}. Subject to the terms and
  conditions of this Agreement, You hereby grant to the USG and to
  recipients of software distributed by the USG a perpetual, world-wide,
  non-exclusive, paid-up, irrevocable copyright license to reproduce,
  prepare derivative works of, publicly display, publicly perform,
  sublicense, and distribute Your Contributions and such derivative
  works.
\item
  \textbf{Grant of Patent License}. Subject to the terms and conditions
  of this Agreement, You hereby grant to the USG and to recipientsof
  software distributed by the USG a perpetual, worldwide, non-exclusive,
  paid-up, irrevocable (except as stated in this section) patent license
  to make, have made, use, offer to sell, sell, import, and otherwise
  transfer the Work, where such license applies only to those patent
  claims licensable by You that are necessarily infringed by Your
  Contribution(s) alone or by combination of Your Contribution(s) with
  the Work to which such Contribution(s) was submitted. If any entity
  institutes patent litigation against You or anyother entity (including
  a cross-claim or counterclaim in a lawsuit) alleging that Your
  Contribution, or the Work to which you have contributed, constitutes
  direct or contributory patent infringement, then any patent licenses
  granted to that entity under this Agreement for that Contribution or
  Work shall terminate as of the date such litigation is filed.
\item
  You represent that you are legally entitled to grant the above
  licenses. If your employer(s) has rights to intellectual property that
  you create that includes Your Contributions, you represent that you
  have received permission to make Contributions on behalf of that
  employer, that your employer has waived such rights for Your
  Contributions to the USG, or that your employer has executed a
  separate CLA with the USG.
\item
  You represent that each of Your Contributions is Your original
  creation (see section 7 for submissions on behalf of others). You
  represent that Your Contribution submissions include complete details
  of any third-party license or other restriction (including, but not
  limited to, related patents and trademarks) of which you are
  personally aware and which are associated with any part of Your
  Contributions.
\item
  You are not expected to provide support for Your Contributions, except
  to the extent You desire to provide support. You may provide support
  for free, for a fee, or not at all. Unless required by applicable law
  or agreed to in writing, You provide Your Contributions on an ``AS
  IS'' BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
  express or implied, including, without limitation, any warranties or
  conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR
  A PARTICULAR PURPOSE.
\item
  Should You wish to submit work that is not Your original creation, You
  may submit it to the USG separately from any Contribution, identifying
  the complete details of its source and of any license or other
  restriction (including, but not limited to, related patents,
  trademarks, and license agreements) of which you are personally aware,
  and conspicuously marking the work as ``Submitted on behalf of a
  third-party: {[}named here{]}.''
\item
  You agree to notify the USG of any facts or circumstances of which you
  become aware that would make these representations inaccurate in any
  respect.
\item
  You acknowledge that you are providing Your Contribution to the USG on
  a gratuitous basis and that this does not create an obligation on the
  part of the USG of any kind, including, but not limited to:
  remuneration, incorporation of Your Contribution into a Government
  work, or any other obligation.
\item
  You agree that any CLA you submit to the USG may become part of the
  public record should the USG be ordered to release it by a valid court
  order, or other legal means. The USG is not under any obligation to
  inform you of this action before, during, or after it occurs.
\end{enumerate}

\subsection{CONTACT INFORMATION}\label{contact-information}

Full Name: {[}{[}ENTER YOUR FULL NAME HERE{]}{]}

E-mail: {[}{[}ENTER YOUR EMAIL HERE{]}{]}

Postal Address: {[}{[}ENTER YOUR POSTAL ADDRESS HERE{]}{]}

Telephone Number: {[}{[}ENTER YOUR TELEPHONE NUMBER HERE{]}{]}

Fax Number: {[}{[}ENTER YOUR FAX NUMBER HERE{]}{]}

Signature: {[}{[}SIGN HERE{]}{]}

[ckaran]

@fulldecent Can you make that a PR?

[seanenck]

Definitely want that converted to a PR (it's not my work, I won't take it as such), I also (from glancing) believe that it will probably need some work to get it to match the current PDF (depending on how much matching we'll want as well) - @storrgie would have a good chance at cleaning up the form/matching current and general styling

[fulldecent]

https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions/pull/10

[ckaran]

@storrgie @enckse @fulldecent I've merged it in, so everyone should be able to pull it at this point. The ARL Forms people are VERY particular about the template of their forms; the only thing they won't complain about is if we fix the word wrapping. Everything else is non-negotiable.

[fulldecent]

OK, trying to make progress here so we can close this issue. Is this work plan acceptable:

• [ ] Update ARL Form - 266.md to note this is NOT the official form, it is for informational purposes only
• [ ] Create a flattened PDF, "ARL Form - 266 - flattened.pdf"
  • [ ] Remove email and print buttons
  • [ ] Make it work on non-Adobe software
  • [ ] Do not change anything else

Then when you mention the form 266 you can also say

You can read the text of the file at ARL Form - 266.md. However we require contributors to execute the form by either using Adobe Acrobat Reader with our ARL Form - 266.pdf or by physically signing and mailing in ARL Form - 266 - flattened.pdf.

The mail-in process is already described in the form. So this solution seems to meet ARL legal requirements and also help people that don't want to (OR CANT) install software on their computer.

[seanenck]

I think we're getting ahead of ourselves with that plan (though the willingness is awesome)

1. We need to make sure the pdf can be created the way we need (formatting, signing, locking)
2. I do not think we should have a tex and markdown file for this. If we keep having the same text everywhere it is a bad code smell situation (which would eliminate the md and flattened pdf)
3. I'm not chasing making the output PDF work in non-Adobe software (and being sign-able) but it will probably be viewable.

A properly formatted and ready PDF will be cleaner as it is so we don't have to call out "removing email and print buttons" that will just happen. Even if we generate the PDF we then have to figure out workflow around that.

Let's get the tex version cleaned up and formatted for ARL people first and go from there

[ckaran]

@enckse I agree with what you say, but the email and print buttons, along with any other buttons, are actually a part of the form template that the ARL forms people use. They will reject a form that doesn't have them as being out of spec.

Like I said before, the only thing we can change is the word wrap. Everything else must be identical to the current Form 266 for them to accept it.

So, my suggestion is that we do the following:

1. See if we can get digital signing working. That is:
   • The form is visible on Linux, OS X, and Windows at the very least, and anything else we get it on if possible.
   • The form can be digitally signed on each platform.
   • Signing the form locks the various fields so they can't be modified after signing.
2. See if there is a way of getting pandoc or some other tool to generate the markdown files from the LaTeX.
3. Get the formatting right.
   • The box around the text, etc.
   • All the buttons, which need to work.

Before we do anything on the second point, let's just try to get everything working under the first two points. @enckse did a good job getting to work on this with his sample file arl-form-266.tex; let's make sure locking works on there completely on that first, and then move forwards.