ProGet does not have the concept of "public" or "private" feeds, you can instead grant the "Anonymous" user certain permissions, including viewing and publishing packages. ProGet Free Edition does not allow feed-level permissions, only system-level permissions. So you can grant "Anonymous" whatever rights you want, just not at a feed-level.

Licenses are activated against a particular machine, but they are not attached to that machine. If you transfer the license in the manner you describe (install on new server, uninstall on old server), then it's in compliance.

I'm not sure why that response says that (I believe it was written when ProGet was still in Beta), but it is in fact inaccurate. The rules for closed testing or DR instances is that a separate license is required as per the licensing agreement: https://inedo.com/proget/license-agreement In order to clarify this with some examples, I've added the following documentation that will release when 5.2 goes live: https://github.com/Inedo/inedo-docs/blob/proget-5.2/ProGet/administration/license.md#examples

Here are the features by edition: https://inedo.com/support/documentation/proget/administration/license ProGet Free is allowed for companies, however that edition only receives "community support" (i.e. this forum).

Jonathan's correct, there won't be an issue; you can just replace the license key as needed. Of course if you're using paid features like LDAP or retention policy, those will no longer function.

A 2nd server license is required for this: https://inedo.com/support/documentation/various/licensing/management

I'm afraid I don't really understand the requirements for what you're trying to accomplish... Here are the differences between the two extensibility points: A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic. A Package Access Rule Allows for rules to block downloads of packages based on additional logic. The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

Yes, it's available. You will need to associate the licenses with a "known" license type that is allowed. Many NuGet packages ship with proprietary licenses, or licenses that point to "random" URLS (like GitHub.org/project-name/license.txt) instead of a "known" OSI URL. This is why they are considered "unknown" to ProGet.

Hi, i'm running into this now in Version 5.3.17 (Build 19). All of our packages are internal use only and i don't want to bother with setting up license rules. Can i disable the license checking?

Hi Tod That is great news +1 Thanks for the very fast reply and hotfix release, which i look forward to. For now we have stabilised by loading a backup of our Proget server, rolling back to 4.6.7 so we are good for now :-D Regards Thomas

You can use your same license key in this case, it's no problem! The licensing agreement for BuildMaster and Otter explicitly permit dedicated dev/test instances. ProGet requires a separate server... but if it's just a temporary migration then it's also OK too.

Excellent. Thanks for letting me know, Alana.

The person who initiated the executions is would be recorded in both versions (if not, a bug for sure), but in the free version, since everyone is effectively the same user, it's all recorded under "Admin" user (by design).

Please see the ProGet feature comparison. There are no limits to the number of feeds.a

You can just use the license key on the new server.

Just enter the license key in Admin > License. You can request a key at my.inedo.com

You will need to reactivate ProGet from the Admin UI. there will be instructions on how to do so within the software.

Currently, only NuGet feeds use the license filter, it shouldn't be displayed on npm feeds... We do plan on adding support for better licensing filtering in a future version, as the current implemention is a bit limiting.