"Forking" should not be confused with "Editing". Simply editing a concept follows the rules/permissions I described in my message above.
"Forking" is when you want to create a copy of a concept, usually because you want to update it without affecting the original concept. There are definitely reasons when a user may want to create a copy of a concept to a different source within the same organization. There are other reasons a user may want to create a copy to a source in a different organization.
I agree with @darius: Let's use a concept-level attribute to store which version of a concept it was forked from, rather than a mapping. And we definitely do want to store the original concept version, not just the concept, so that we can do conflict resolution and merging in the future (like Darius said).
Also, agree that we should use a source-level attribute to control permissions for forking.
Finally, API should allow forking from any version of a concept. UI encourages use of the latest version of a concept, but I don't see any reason for us to prevent forking of a previous version if the user has already navigated to an older version of a concept.
@hao555sky: Could you write a short proposal for how you want to approach concept forking and post here so that we can review? Thanks!