Your AMS vendor has an AI feature on its roadmap. Your CMS has one in the release notes. The events platform mentioned one on a webinar. Nobody at your association has asked which model any of them runs, because the answer has always sounded like a question for the vendor's engineers rather than for the people signing the contract.
On August 10 that question got easier to ask and more useful to have answered. Meta released a model called Muse Glimmer under the Apache 2.0 license, the same license that governs a great deal of ordinary open-source software, rather than under the custom license that governed the Llama models before it. The technical release is interesting. The license change is the part that reaches your association.
What Was Actually Released
Muse Glimmer is a roughly 30-billion-parameter model, including a vision encoder of about 1.8 billion parameters, so it takes both text and images as input and produces text. It handles a context of more than 131,000 tokens, and Meta describes it as built for what it calls always-on local agent workflows: calling tools, working through several steps, checking its own output and recovering when a step fails.
The number that matters more than the parameter count is the memory requirement. At full precision it wants 64GB of video memory. Compressed, Meta publishes configurations that run in 32GB and in 24GB, with a stated quality loss of about one percent at the smallest one. A 24GB card is a workstation part, not a data center. That is the difference between a project and a purchase.
Why the License Is the Story
Previous Llama releases came with Meta's own license rather than a standard open-source one. It permitted a great deal, but it carried conditions, the best known being a clause requiring a separate agreement for companies above 700 million monthly active users, along with naming and use restrictions. None of those clauses ever constrained an association. They constrained the vendors who build the software associations buy, because every one of those conditions is something a legal team has to read, interpret and accept before shipping.
Apache 2.0 removes that step. It permits commercial use, modification and redistribution without a negotiation, which means a small AMS vendor, a chapter management tool or your web partner can embed the model in a product without a lawyer's sign-off. The practical consequence for you is not that you will run this model. It is that you will encounter it, inside things you already pay for, sooner than you would have otherwise.
Where a Local Model Genuinely Fits an Association
The honest list is short, and it is short because the value of running a model yourself comes almost entirely from one property: the data never leaves your control. That matters for a small number of tasks and is irrelevant for the rest:
- Anything touching member records. Summarizing case notes, drafting a first response to a member inquiry, tagging or routing submissions. These are the tasks where a general counsel's objection to a cloud service is reasonable rather than reflexive.
- Work under a confidentiality obligation. Committee materials, draft standards, salary survey inputs, anything a member supplied on the understanding it stays inside the association.
- Volume that makes per-token pricing awkward. Bulk classification of an archive, for instance. Rare, but it is the one place the economics rather than the privacy argument does the work.
Everything else, writing marketing copy, summarizing a public document, answering a question about publicly available material, has no privacy argument behind it, and a hosted service will be better and cheaper at it than anything you operate yourself.
The Part the Announcements Leave Out
An agentic model is one you give tools to, which means the interesting risk is not what it says but what it does. Coverage of the release noted that on published benchmarks the model showed a higher rate of privacy-related failures than a comparable smaller model, and that roughly a quarter to a third of prompt-injection attempts succeeded against it. Those figures come from the reporting rather than from Meta's own announcement page, and benchmark numbers deserve skepticism in either direction, but the shape of the finding matches what everyone testing agentic systems is currently finding.
Prompt injection is the practical version of that risk, and it is worth stating plainly because it is unintuitive. If a model reads a document, an email or a web page, whatever is written in that content is text the model has now processed. A malicious instruction placed inside a member submission is not a hypothetical attack on a system that reads member submissions and has been given the ability to act. It is the expected one.
That does not argue against local models. It argues against giving any model, local, hosted, yours, or your vendor's, the ability to take actions on data that arrives from outside, without someone having thought about what the worst instruction in that data could ask for.
The Four Questions for Your Vendors
This release makes vendor answers more likely to be interesting, because the license no longer stands between a vendor and a capable model. Four questions, and they fit in an email:
- Which model does the feature use, and where does it run? A vendor who cannot name it is describing a roadmap, not a product. Where it runs decides everything else.
- What leaves our tenancy, and is it retained or used for training? Ask for the answer in the contract rather than in the sales deck. The two are frequently different documents with different levels of commitment.
- What can the feature do on its own? Drafting text for a human to approve is one product. Sending, publishing, updating a record or issuing a refund is a different product with a different risk profile, and the same marketing page often covers both.
- Can we turn it off, per feature and per user? The answer tells you whether this was designed for organizations with governance obligations or bolted on for a release announcement.
What Not to Do With This
The thing to resist is treating a free model as a free capability. The weights cost nothing. The hardware, the person who maintains it, the evaluation work to find out whether the output is good enough for your purpose, and the ongoing attention when a better model appears three months later. Those are the costs, and they are the same costs whether the license is permissive or not. An association that would not staff a small internal application should not staff a model.
The useful move for most associations is smaller and cheaper: know that this class of tool is now trivially embeddable, expect it to appear in the products you already buy, and have the four questions ready before it does.
Have Us Review Your Vendors' AI Features
Send us the list of platforms your association runs, AMS, CMS, email, events, community, and we will go through what each vendor has actually shipped rather than announced. You will get back a written page: which products have AI features live today, what each one does with your data, which of them can take an action rather than draft one, which can be switched off, and where the contract language and the marketing language differ. If everything you run is conservative and well documented, the page will say that, which is a useful thing to hand a board that has started asking about AI.