operations-puppet VS operations-mediawiki-config

Some of Wikimedia's basic Kafka broker alerts are defined here: https://github.com/wikimedia/puppet/blob/production/modules/profile/manifests/kafka/broker/monitoring.pp

> Configuration is just a short artifact. It's not a creative work and is therefore not copyrightable at all, whether by AGPL or otherwise.

I'm doubtful. For example https://github.com/wikimedia/operations-mediawiki-config is wikipedia's config. It is not short, and much of it is complex enough i think it would be copyrightable (ianal)

I agree though a very traditional list of key value pairs that are simple facts like where to find the db, might lack creativity to be copyrighted (ianal). But how many real deployed systems have that simple a config. More generally i would prefer that the license was less ambigious about this especially in an international context (e.g. rules are totally different in uk over what can be copyrighted)

> I'm not convinced obscurity helps against spam at all. DKIM and blocklists have done much more against email spam than any form of "security by obscurity" corporate scheme has.

Gmail et al use techniques beyond dkim that are secret. However i meant more like web spam where you can't just rely on source vouching for users. For example on wikipedia there is a feature where admins can write "code" that block patterns in edits. When used against persistent vandals, they are often secret lest they use the info to adjust behaviour. That's the type of thing i mean.

> if you are coordinating with the developers, then you have their explicit permission to temporarily withhold those changes (AGPL copyright holders can still grant exceptions to the license)

That only works if one entity holds all the copyright. Even then, does that mean forks cannot have coordinated disclosure?