Policy on mod de-indexing #1078
Comments
|
👍 It might be worth explicitly mentioning the case where different portions of a mod are covered under different licenses. I've unfortunately seen a few mods where the code of a mod is released under a permissive license, but the models and artwork under a restricted license. Presumably if any portion of the mod is restricted we'll pull the entire thing? |
|
I assume that mod licence is most restrictive licence of mod's components (code / models etc.) |
|
Yes, that's the policy as it stands now because the metadata isn't currently robust enough to handle per-file licensing. So a mod with permissive code/restricted assets will be |
|
#22 covers a proposal to have per-file licensing. It's something we'd like to have, although in the cases where a mod bundles permissive content with restrictive content the results are often pretty muddy, and the download as a whole at least needs to be considered restricted as far as our ability to reproduce and redistribute it are concerned ( #935 is relevant here). One thing I am trying to shape with this policy is to get mod authors to actually think about their licenses; namely that a restrictive license means they get to keep control, whereas a permissive license means that ultimately the community has control, or at least that they've made a promise they can't "take back" their work after release. While one could argue we're not redistributing, this policy gives mod authors a clear way to signal they don't want their works appearing on the CKAN (or can have it removed at their whim), and helps them to choose a license that's most compatible with that worldview. |
Read them for details. :) Closes KSP-CKAN#963. Closes KSP-CKAN#1078.
|
I just found this and I must say that I am quite disappointed. I am fine with using open licenses and letting others doing whatever they want with my code. However I don't see why it should bind me into having those mod distributed here if I don't want to. |
I struggle to see how these are not mutually exclusive statements. A free and open source (FOSS) license explicitly and irrevocably gives other people the ability to do "whatever they want" with a work, including things that the creator disapproves of. That's why FOSS licenses are such a big deal; they protect the consumer of the work, rather than the producer. They're a promise by the creator that they won't try to "take back" or restrict their work, no matter how it's used, including uses the author hasn't even thought of. There's no requirement that work be released under a FOSS license. Sure, the KSP forums require that source code be available, but one can state that users have no permission to modify or redistribute such work. Indeed, the default copyright position is that users have no rights at all, unless they're specifically granted them. Licensing provides very clear, legally binding rules on what can be done. A restricted license means the creator can hold the work "at ransom", a FOSS license means that work can be trusted to endure. A number of mods have been distributed with licenses that say "you can do anything you like with this mod except...", and we've marked those as restricted in our metadata. They're not free licenses, and we won't treat them as such. Of course, what we actually do needs to be considered on a case-by-case basis. If a work is obviously not ready for distribution (it's full of bugs, or worse still causes data corruption), then I would expect we'd remove it; that's absolutely in-line with our policy of acting in the interests of our users¹. However in the past whenever there's been controversy over de-indexing it's because a mod author has had an argument with someone else in the KSP community, and decided they wanted to screw their users as a result of that, by removing all their mods from distribution. ¹ Edit: We've had a number of cases in the past where we've de-indexed particular releases at the request of the authors, because it was found they had serious bugs. |
|
@pjf This isn't based of an authors question but do we have a policy on removing authors names at their request? |
|
I get where this comes from but I still disagree. But anyway the point is moot sine I found out that if I want to stop a mod distribution the current CKAN code make it easy : just set the mod max ksp version and the mod will never be seen anymore. |
|
I'm actually not seeing the logic behind the de-indexing for ARR licenses here. Based on my understanding, CKAN doesn't actually do any redistribution, it simply downloads from other sites that are doing redistribution; any situation where a client could be argued to be doing redistribution would also apply to, say, an instance of Firefox downloading a file as well, and in those cases it should fall under personal use anyway. The basic point I'm getting at is, if CKAN doesn't host its own copies of the mods, and so it's not redistributing them, why do ARR mod authors get additional courtesy privileges to de-index their mods, given that it isn't a right guaranteed by their licenses? Why is this courtesy not extended to all mod authors? I dislike the current policy, don't get me wrong, but I think it should apply equally and not give additional rights above and beyond what they already have to ARR mod authors. I would rather that every mod author gets this courtesy, but remember:
You only need to hit the legal points you need to and de-index a mod at the request of the mod author, except for bugs, will obviously be against CKAN's users' interests. I don't see how granting de-indexing powers to ARR mod authors advances the user interests, nor do I see how it could possibly violate the license, given that the mod will still be downloaded from a host that the mod author has given permission to to redistribute. |
@RichardLake : We don't, but this sounds like something we should always do. I can't think of any good reason why we wouldn't remove someone's name at their request, and plenty of reasons why we should.
For reasons of social balance. ARR licensing is a very clear indication from a mod author that they wish to retain control, and this gives us a very straightforward answer for people asking "how can I stop my mod from appearing on the CKAN" that is compatible with the author's intent. It lets control-centric authors keep that control, without burdening them by requiring they implement CAPTCHAs, user-agent checking, or other means of distribution control.
Because authors of FOSS software have explicitly, voluntarily, and irrevocably waived their rights to control distribution and re-use of their works. FOSS software also commonly has multiple authors; at last count FAR has seventeen and RealismOverhaul is nearing forty, and FOSS licenses make it clear that none of them have the right to prevent others from using or distributing their work. The policy as it stands encourages authors to make the right choices when it comes to licensing their works. An author who wants to retain control over the distribution and use of their work really doesn't want to release their work under a FOSS license. Of course, all of the CKAN is MIT licensed with CC-0 metadata, so people can and should make their own RebelKAN if they disagree with our way of doing things. |
But none of this gels with following the legal route, nor does it act in the interests of your users, who miss out on mods as a result. Ultimately, the argument you've set forward earlier is that the intent of the author, fully accepted or not isn't really relevant to CKAN, only that it follows what it must due to legal issues. And since you're not touching any of the mods directly, only metadata, there aren't any legal issues. We both know that getting around this is why CKAN doesn't re-host mods, why not take full advantage of it?
Is the metadata licensed by the authors? Then why do the ARR authors have control over it existing in CKAN? How is it in user interests for mods to come off of CKAN? Given that this current policy doesn't follow and seems to completely contradict CKAN acting in the interests of users, if it stays in place, how is an ARR author supposed to expect you to maintain the special privileges you've granted them?
But I thought that CKAN wasn't redistribution. If it is, then how do you allow ARR mods to be indexed at all? You're risking redistribution without permission in those cases. If CKAN isn't, then this is just irrelevant and a way to deflect from meeting the users' interests.
I think it's somewhat wrong to encourage this by giving ARR authors control over data that isn't licensed by them if you're going to stick to the principles you've set down so far. If you're going to do that, I think it would be worth amending the "two simple principles" to include a third: 1.The CKAN, like the legal system, takes licenses very seriously. And now, with that in place, you can make your policy consistent with your stated principles. All you have to is explicitly state what you're already working with. |
Because an ARR author can always just add the following term to their license:
Now end users are legally prohibited from using CKAN to install the mod. If CKAN left the metadata up it would be facilitating copyright infringement even though it's not performing any distribution itself (see: Napster), a legally intractable position. So since they have the power anyway, why not just give them the ability to effectively perform the equivalent of a takedown request? FOSS authors can do they same, they just won't have a FOSS license anymore. They'd have a restricted license with generous provisions and one oddly specific exception. |
We haven't gotten around to properly rehosting mods yet. There is http://master.ksp-ckan.org/ which tries to mirror as many mods as possible that have permissive licenses, but it's not very well known and isn't particularly user friendly. #935 is the more concrete plan to provide automatic failover if a permissively-licensed mod can't be downloaded, and will go a long way to protect us against websites being down, clients being throttled, or mod authors flouncing. To users, this means we can provide a strong guarantee that permissively licensed mods will be available.
Let's say we don't allow ARR authors to de-index their mods. The mod authors themselves can move them behind a CAPTCHA, or into a walled garden, or take any other action that prevent the CKAN client from downloading that content. The mod still becomes unavailable, but we've forced the author to do unnecessary work.
Not quite. A mod can re-license new releases under a more restrictive license if the license permits it (eg, MIT), or if all the copyright holders agree. A permissive license doesn't allow the license on existing works to be revoked. There are lots of software projects out there which have transitioned from permissive to restrictive licenses over their lifetime, but the older releases made under permissive licensing terms have remained available.
I'm happy to include this or a variant of it in the policy if it's felt necessary. I'm certainly not going to hide the fact I started the CKAN with some pretty strongly held ethical principles; it's why we have a strong code of conduct, and it's why we have very permissive licenses on the code and metadata (including the ability for anyone to make a closed-source or commercial fork). I'm absolutely fine with ethical principles mentioned in policy documents if they're not self-evident. |
But if ARR involves the author reserving all rights except those explicitly given, and those rights extend to the ability to restrict which methods the mod can be installed by, isn't that line (effectively) there by default? Wouldn't that imply that simply by indexing ARR mods that don't have a written exception from the creator somewhere in the data, CKAN is already facilitating copyright infringement? And if that's not the case, and ARR doesn't cover that everything until that little case is set up, then you can still index it; the earlier versions are still licensed without that, because licenses aren't retroactive.
In that case, that sounds like a good argument for not providing additional privileges towards ARR authors. You'll help encourage people towards ARR and away from that by giving them this amount of extra power, and I have trouble figuring how this helps your users.
Sure, if they're willing to. And you get to say that you did your best to help your users, and any that fought back get to have the fun of complaining from all the other users they have. You get what you want, the author is unlikely to do that because of users, and as a result, users get what they want. Why not? We all know that in a public relations way, you'll win here. The backlash will discourage other modders from doing that, and you'll get exactly what you want (more mods indexed).
I think it is, simply because it's more honest to say that other principles will be sacrificed for the greater good if that's the decision. Granted, it makes any policy based on those other principles somewhat less trustworthy, simply because everyone has to sit there and wonder if a greater good will come along to argue in favor of a different policy, but the open secret is that this principle is already in force here, it's just not openly acknowledged. If policy is going to be based on specific ethical, moral, or political inclinations, it should be stated openly, not have to be inferred from endless discussion and the resulting policy. |
|
Speaking only as a user, there's an obvious pragmatic consideration here. Let's consider someone writes a shim to detect CKAN and disable their mod, just like Win64. If the mod is FOSS, that's pointless. Disable the shim, recompile it. If the mod is ARR, that's that; there's no way to release a version installable with CKAN. It saves a bit of everyone's shim-writing time (and the prospect of mod authors and CKAN and recompiling users playing Core Wars) if it's recognised that since ARR mod authors could do that, it's quicker to just let them pull their mods. |
|
I think this is starting to get over-complicated, at least in terms of the original issue of defining how to de-index a mod. To satisfy the whole AAR thing, the AAR license also reserves the right to control distribution so (in theory) the fact that a mod is on the CKAN means the author has given permission to CKAN to redistribute the mod. For the issue of de-indexing mods, I think one of the conditions being "by mod authors request with technical justification" would work. Perhaps a better word then technical, but my intent with that is that it allows de-indexeing for purposes of a things such as a serious bug found in that version as well as a mod that is licensed AAR being pulled by the author as his license allows him. Note when I say pulled, I mean no new versions show on the CKAN. Having given permission to distribute a specific versions of a mod on CKAN, I do not believe a mod author can retroactively deny that permission to distribute so version of the mod on CKAN would be able to stay. The other half of making this work is that mods licensed under ARR can only be added to CKAN by the mod author. It would prevent mods with permissive distribution license from being pulled for no reason as without that "technical justification", the mod doesn't get de-indexed. |
You'd be surprised. Many mods that have win64 disabling on them have had this attempted, and all of those versions fail because the authors of those forks don't know what they're doing. Worse, this hurts the users really badly: now the original authors are refusing support from the unlocked build, because it's not their code, the forking author can't do anything because they don't know how the underlying code works, and the users get screwed because they were fooled into getting a mod that they couldn't get support for, simply because CKAN indexed a forked version. To be honest, no one wins here by forcing that issue, and it would have ended a lot better with de-indexing.
But, as noted before: many mods are on CKAN because it has been indexed by users, not the original author. In that case, one cannot assume that the author of an ARR mod gave permission for CKAN to do anything.
Which also implies that for the time being, every single restrictively licensed mod will need to be checked on or de-indexed to make sure that it being on CKAN is the author's intent.
A discussion elsewhere with pjf resulted in something similar, that mods could be de-indexed if their were issues with it that couldn't be "fixed immediately," but I couldn't nail him down on where the upper boundary of that was. With that in mind, I think it's a little disingenuous to present any clear method for de-indexing for anyone, because it seems like it's going to be a case-by-case basis where nothing can be predicted in advance. State that an appeal to the CKAN developers to ask for it can be done, but that it is unlikely to be allowed except for ARR mods. |
|
I suspect Win64-enabling forks tend to fail because, almost by definition, the forking author is foolish. The same would not necessarily be true of a CKAN-enabling fork - or less still so if the CKAN authors start playing Core Wars to evade the current shim du jour (and in that case there would be nothing in the output log to alert the mod author to the fact that the issue reporter was using CKAN). I don't think this is a desirable situation; I'm just saying, an ARR mod author can trivially pull their mod by such a shim if they choose (so just let them ask to pull it) - a FOSS mod author certainly can't do it trivially. I also am not convinced that the occasional [1] "is it on CKAN yet?" question is any worse than the occasional "I made a hash of unzipping manually" question - and at least the former can in principle be fixed once not per-user... [1] for example, I found one such question in the five pages of the FAR thread taken up by the speed-of-sound confused person. |
|
The "is it on CKAN yet" questions occur regardless of whether it's on CKAN, and ultimately aren't the main support issue. It's the install issues when CKAN screws up the metadata or at figuring out which version is most up-to-date, or god knows what else. Ultimately, the problem is that we have a situation where the support workload of modders is completely at the mercy of the judgment of CKAN contributors, who seem to be fairly explicit about telling modders that they can't get mods de-indexed if CKAN issues continue to crop up for them and their users unless they fit specific undefined requirements. Honestly though, the simplest solution for FOSS mods will be to include some ARR assets that are forbidden from redistribution on CKAN. While the functional code can still be redistributed, it does provide a method of marking the CKAN-sourced builds in such a way that CKAN users can be denied support. I'd rather not go about putting a scarlet C on the CKAN users, it's a lot of effort to deal with someone else's problem, but given that (for FAR) we're at a total of 4 separate installation issues caused by CKAN, none of which occurred with manual installs, and 3 of those just in the past month, it's the best way of separating this out for when CKAN causes more issues down the line. Ultimately, there are tools available that we can try to use to work around CKAN policy if it continues to cause issues for modders. It doesn't benefit users to go through the hoops or lose support, it doesn't benefit modders to have to take these steps, and it doesn't benefit CKAN to need to maintain unofficial knock-offs of the original mods, but it is always an option. I also think that this sort of stuff should be rather front-and-center for modders. You guys wield a lot of power and can throw a lot of grief towards modders that don't understand that not going ARR will risk CKAN issues overwhelming them. Which license modders choose is going to be heavily influenced by how CKAN behaves wrt them, and it should be somewhat up-front that ARR is the only option that gives modders any hope of dealing with issues caused by CKAN. |
|
I suppose (and I'm not one of "you guys", just a user) I feel the answer if a package has bogus metadata is to fix the metadata. I'm not being facetious there - I think in the long run the world where ~everyone uses the package manager and gets their packages installed correctly every time is best not just for users but for developers as well. A metadata problem needs fixed once, in one place; manual install problems have to be fixed one at a time. The thing I find odd about "putting a scarlet C on the CKAN users" is, well, as opposed to who else? FAR is one of very few mods I'd consider using if it wasn't in CKAN; for the majority of mods, if it ain't in CKAN it doesn't exist. I don't think I'm atypical, given the regular IRC conversation that goes "I have this problem with mod installation" "Use CKAN" "Wow, that's amazing". (Furthermore, I don't know how many people care about this, but I'm pretty unlikely to use a mod whose licence ensures that, sooner or later, it'll be unmaintainable.) The modder who goes ARR to keep the mod out of CKAN is effectively saying they don't want people to use their mod. Then why release it? |
Yet it seems to need a lot of fixing very often.
A single manual install problem creates one report that doesn't interfere with other issues. A single metadata issue creates hundreds or thousands of issues for users and double-digit numbers of reports that can bury attempts to get information. It's worth noting that you can't rely on github reports for all the bug reporting information. Sometimes it has to be divined from what people say on the forums, and lots of CKAN-generated noise interferes with that.
All the users that find that CKAN doesn't do what they want, or that it causes problems, or would rather not fight with a mod manager when dealing with tweaking their installs to their liking. I've noticed this from CKAN users and contributors; absolutely none of you can fathom that someone wouldn't want to use this thing.
Hence the power that CKAN has. I mean, this basically means that CKAN can make trouble for modders who are interested in getting their mod out there and then say, "don't like it? Too bad, we're in charge here."
Because they aren't saying they don't want people to use it, they're saying they don't want people getting faulty installs by no fault of their own? Because they'd rather have a reasonable and manageable support thread, not one filled with issues from someone else's project? Because they'd like to have some control over the workload that they'll have to maintain it, because they would rather not just blanket declare "no support" for all their users? Because they actually don't want that many users, just enough to provide a decent amount of feedback and only to the ones that care enough about the feature to want to install it manually? Essentially, to create a small barrier to entry to keep out the users that are ultimately not useful in improving the project? There are plenty of good reasons to keep a mod off of CKAN or to mark its users. |
|
I'd like to voice my support for allowing deindexing of any mod at the request of the author(s). |
Yeah |
|
I dunno, there's all the fixing there. There's also this that doesn't show up there because it was an error with dependencies. All issues that will affect hundreds of people that relied on CKAN rather than winzip. And the few that will screw something up with winzip? That's been handled for a long time. So yeah, compared to the manual method, you guys need a lot of fixing to stay on par. |
This only checks if mod was installed in correct directory. That's very rare bug in CKAN metadata. (I'v seen it once but it was quiet niche mod) I suppose it happens more often in manual installations and I suppose not every mod have that InstallChecker built-in.
:>
Personally I'm against deindexing any mod with licence that allows for free redistribution. |
Because that's the only install error I ever used to get from users. There are no other install errors, besides the new ones created by CKAN.
Yes, this is true so long as you work with the assumption that # CKAN users >> than # modders. It's a poor metric, because it inevitably concludes that the smallest, tiniest improvement to a user that causes a massive workload to a modder is worthwhile, simply because there are so many more users to benefit. You're not supposed to feed the utility monsters. Now, you can sit there and tell me that you don't believe that it's more trouble, but I haven't had to deal with install errors in the time between implementing InstallChecker and when CKAN showed up. But now, with CKAN here, I've got install errors to worry about again. Worse, it's not just one person that can't follow directions that's affected like with a manual error, it's everyone using CKAN and FAR. |
|
Well, the number of users is certainly > the number of modders. So if you want to argue from a utilitarian viewpoint, then there is that. But I'm no fan of Bentham and Mill, so count me out of that side of things. Perhaps you may want to consider, once you get past 5 or so mods, managing them becomes very labor intensive, and a tool like CKAN was inevitable. Look at WoW/Curse for example - love it or hate it (I hate it as a former addon author), you had to deal with it because the users want it. That is at least a minor part of being a developer, to respond to the needs of his users, at least as far as making a game addon goes? If not, then why publicize it and invite all that extra work of dealing with the public? There are private addons out there, I suppose, that have a userbase of just the developer, and possibly a friend or two. I've heard a major reason for doing this is the open-source mantra - you got an itch that needs scratching, so you write an addon, and maybe others might find it handy, so you share it. That's what I did a long time ago in WoW. And I got burned out quickly on upkeep even on a relatively limited and sparsely used one, so I simply quit and went back to spending that time gaming -- I think it eventually it got picked up then subsumed or obsoleted by added game functionality. It happens all the time, the lifecycle of an addon. One thing I am curious about, since I have never had it happen, what does CKAN do to break installs? All I have ever seen in my 85+ mods is that it basically saves me the trouble of tracking whats outdated/conflicted, and saves me the trouble of hunting down multiple sites for DL. I thought all it did was the same as DL's and unzip them for me. Is there something here other than that being done? (one of the CKAN folks please point me to the defect/bug issue). Anyway, perhaps you might decide to help your userbase that uses CKAN and point out to the CKAN folks what specific steps they can do to help you as a mod author of a fairly complex mod - it might be better for you and them in the long run to not be so adversarial. Attitudes do matter whether you realize it or not. After all, it is just a game, and from what I can see, both sides here want the same thing in the end - have fun in the game instead of managing development. Seems to me you can proceed from that common ground. |
Yes, I know, people somehow consider managing mods impossible. I don't understand the logic. The demand, I get, it's a classic appeal to laziness / convenience.
Because a get a slight amount of feedback that makes it worthwhile; some extra data to implement, some bug reports for actual bugs in FAR. Not from anyone brought in by CKAN though, only the core that would have installed it without CKAN in the first place. The group that demands CKAN... well, the ones that wouldn't have installed it without CKAN aren't useful to the project, and the ones that did but still want CKAN obviously care enough to do it manually. How do I benefit by CKAN? It was supposed to be guaranteed successful installs and compatibility, but the installation errors with FAR and the coming force-install options basically make all of those pointless. Don't appeal to my users, because they're not me. What's in it for me?
See, if it was just glorified winzip, it might work. But that fails with various different kinds of packaging standards. So instead CKAN runs to the metadata to find out what folders to copy and what ones to ignore, and then the other things that it needs to download. This would be fine, except for the metadata errors, like not listing all the dependencies, getting the wrong version of a dependency, or something like that. Not a problem with manual installs, because they're generally bundled and everything works out peachy, but CKAN tries to be clever to guarantee the most up-to-date versions and screws up every so often as a result. Too often, from what I can tell. Then there are the errors where it can't figure out the version ordering, as happened a few days ago. These have all been linked to here or in the forum thread. Yeah, it happens.
Tried that, that portion of my userbase doesn't listen to, "don't use CKAN." For some reason, that didn't work, even though that's the most specific and quick way to help with CKAN problems. The next attempt will be having them move all their problems into a common support thread so that I don't have to try and sort these issues myself. I don't have high hopes for that working. Frankly, I think expecting extra work out of a userbase that picked up a tool specifically so they could avoid what they perceive as work is rather silly.
Actually, I think that an adversarial attitude is the best one. We don't have aligning interests: CKAN and its users want the easiest installation method, regardless of workload for modders; I want the lowest support and development workload, while still making use of my core feedback group, regardless of barrier-to-entry for all my users. We aren't after the same thing, and trying to pretend that we are seems very odd. |
|
I have seen that from ferram before, but not really digested it until now. Fair point; if one basically wants dedicated users as a source of bug reports for the mod one wrote to scratch one's own itch, this is a reasonable position. |
|
Real talk incoming: I'm not proud, but I was someone who asked a mod author if they were going to add their mod to CKAN in the past. I didn't really know how mods were added to CKAN at the time, I thought it was something mod authors did. The mod author was annoyed which is a reasonable reaction: he put work into creating the mod and finding a hosting solution, why should he be asked to do more work for someone else's project. When I started looking into CKAN more and started contributing my perspective quickly changed. CKAN as a collective really hates when users pester mod devs about CKAN install problems. It's our fault, and we don't want our mistakes or inadequacies to fall on others. We want the github issues, we want the messages in our thread, we want mod authors to want us around and work with us. We don't want the project to be thought of an an inconvenience. Hopefully over time CKAN will generate less issues as the toolset for dealing with different installations expands. As far as CKAN wanting greater control over the modding scene or the ability to strong-arm mod devs: honestly it would be divine to get all mod authors to follow 3-4 basic principles (establish and maintain a folder structure, keep to a versioning scheme, exclude extraneous files from archives). But honestly overall the project actually just wants to be a tool between mod authors and end users and it wants to be as seamless as possible. While this doesn't help you: most mod authors never get a single issue due to CKAN. Due to the size and popularity of your mod, you've probably gotten more bug/issue reports than 95% of mod authors and that sucks. I could say "growing pains" or whatever else but none of that will change the reports you go, and the reports you might receive down the line. All CKAN really offers to modders is the ability to expand their audience via lowering the accessibility threshold. Someone who plays KSP but "isn't good with computers" will likely be intimidated at the idea of unzipping and dropping files in the right location but might be ok with a GUI like CKAN. And that's part of the problem: we lower the lowest common denominator. That's a problem endemic to increasing accessibility and I'm not sure how that can be resolved. Sorry if that's hard to read, it kinda came out as a stream of consciousness. Additionally while I use possessive pronouns while talking about the CKAN team I'm not really them, I'm speaking more of my impression of them from the time I've spend contributing and in their chat. |
|
Superseded by #3993. |
We've grown to the point where we need to start having some explicit policies, and so I'm in the process of putting together a policy manual. My proposed text regarding what we do when an author wishes to de-index a mod is below. Discussion is appreciated, and there's also some past discussion on reddit that's relevant.
From time to time mod authors ask their works be removed from the CKAN. Whether or not we should do this is a matter of licensing and public good. Our policy is based on two simple principles:
Restrictive licenses, including the default "All Rights Reserved", allow the content author absolute control over what happens to their work. If an All Rights Reserved or other restrictive license author asks for their mod to be de-indexed, we do so promptly and without question.
Permissive licenses—which includes every license the CKAN is aware of that's not marked
restrictedorunknown, and includes the popular Creative Commons family of licenses—provide explicit and irrevocable permission to use and redistribute the content. Such a license is a strong, legally binding promise that the author cannot stop others from reproducing their work. One of the primary purposes of such a license is protection against the mod author changing their mind, or imposing further restrictions at a later date.When an author gives us explicit and irrevocable permission via a legal document to redistribute their work, we cannot in good faith de-index the mod and still act in the interests of our users. Whenever possible, mods with permissive licenses will be preserved by the CKAN, especially when alternate downloads to such mods exist, including those cached by the CKAN's own automated systems.
The text was updated successfully, but these errors were encountered: