KSP-SpaceDock / SpaceDock

Current Codebase (Python /Flask)
https://spacedock.info
Other
73 stars 33 forks source link

CKAN #49

Closed StollD closed 8 years ago

StollD commented 8 years ago

Well, we need to think of a way to handle CKAN Integration of SpaceDock. CKAN was an important part of KerbalStuff, and we certainly want to archive the same, but we seriously need to overthink the concept KerbalStuff used.

If a mod got added to CKAN on KerbalStuff, there was no way to remove it, unless you had it licensed as All Rights Reserved, due to CKAN's policy on mod-deindexing. Even thought I respect their decision, I do not agree with it. The modmaker should have the absolute control over where his mod is distributed. We are allowed to do it, but we shouldn't - to respect the wishes of the guys who make so great mods for KSP. :+1:

My idea is that we should run our own CKAN metadata repository (at least for NetKAN, CKAN needs some more infrastructure, which we would have to set up first, which is not the problem though). That would give us and our users the ability to remove mods from CKAN, and it avoids spamming the CKAN team with merge requests from SpaceDock mods. Also, the mod makers would have to blame us for bad written auto generated metafiles, not the folks over at CKAN :stuck_out_tongue:

What do you think?

Olympic1 commented 8 years ago

Including @Dazpoet, @dbent, @Olympic1, @pjf, @plague006, @politas, @Postremus and @techman83 so they can discuss here about this feature

ghost commented 8 years ago

And we can setup redirects / mirroring / CDN purely on our side, since we can add the proper URLs into NetKAN metadata.

A secondary benefit is that a CKAN repository hosted by SpaceDock can be added to the CKAN client.

I like the idea.

On Wed, Feb 17, 2016, 11:31 AM Arne notifications@github.com wrote:

Including @KSP-CKAN/contributors so they can discuss here about this feature

— Reply to this email directly or view it on GitHub https://github.com/KSP-SpaceDock/KerbalStuff/issues/49#issuecomment-185285284 .

godarklight commented 8 years ago

I prefer that we don't get involved with CKAN at all and leave being CKAN to the CKAN project :P

Dazpoet commented 8 years ago

Just poking about to mention that CKAN loves handling multiple upstreams (metadata repositories) and that the functionality has been around and working since pretty early versions. I'm sure many users would love a spacedock repository to complement the current one, or replace it for that matter.

mheguy commented 8 years ago

If you decide on hosting your own metadata I wish you the best of luck (it's a slog). If you decide on establishing something akin to KerbalStuffBot, I have plenty of suggestions to streamline the task of adding mods to CKAN.

inigmatus commented 8 years ago

even though CKAN is separate, I don't see why we can't have CKAN involved in helping us maintain metadata. I think more automation, the better.

pjf commented 8 years ago

The CKAN project was founded with strong freedom-oriented ideals. In particular:

  1. The source code is entirely MIT licensed, specifically so anyone can make their own forks of the CKAN and CKAN technology, including integrating into closed-source software if they so please.
  2. The metadata is entirely CC-0 licensed, so anyone can use it for any purpose.
  3. While the client comes with a default metadata repo that it pulls from, we intentionally have support for multiple repos so users can choose their metadata subscriptions, and aren't forced into using one single list.

All the means you can and should use the technology in whatever way best aligns with your values.

Personally, I think it makes perfect sense for mod hosting environments like SpaceDock to provide their own metadata feeds, especially if that means a better experience for your users, such as being able to provide updated mods immediately instead of waiting for our indexer¹.

As for choosing to de-index mods, that's already been the topic of voluminous discussions elsewhere, but I would love to encourage a drop-down of license choices for new mod uploads. This would let us do two things:

  1. License selection is done in a standard way. The CKAN spec has strict requirements on how licenses are encoded in metadata, as it's the license which clearly signals what can and cannot be done with each mod.
  2. We can warn authors when they're about to grant global and irrevocable licenses to others to use, modify, and redistribute their work.

As for removing mods from the CKAN, there's not much anyone can do to prevent users from subscribing to additional repos in addition to the data provided by Spacedock. I'm happy to assist authors (as far as my time allows) in flipping new releases of their mods back to restrictive licensing if they've discovered that FOSS licensing is not their thing. (Either by getting assignment of copyright from co-authors, or by rewriting co-authors' sections so that they have an unencumbered code-base.)

¹ We'd also be delighted getting callbacks from SpaceDock, which would let us also provide faster updates with existing infrastructure

godarklight commented 8 years ago

I'd still prefer we not do an automatic CKAN repo for everything in spacedock as then maintaining the metadata would become our responsibility (and it's not simple either - there's dependancies and things to track), and as before I'd rather leave that to the NetKAN/CKAN-meta repos.

That being said, I would love to setup push notifications eventually - it will allow near instantaneous CKAN updating when someone pushes an update to spacedock.

techman83 commented 8 years ago

@godarklight as of KSP-CKAN/CKAN#1593 automated indexing of spacedock mods is supported. Not quite instantaneous, but within 4 hours it'll make it into CKAN-meta.