Programme Forking

Title: Programme Forking
DRACC: 0008
Category: Regulatory
Scope: Global
Authors: Leenaars, M.A.G.J.; Šuklje, M.
Date: January 2017
Copyright: The Commons Conservancy

This doc­u­ment is part of the DRACC se­ries, see DRACC “In­tro­duc­tion to ­DRACC Se­ries” for an ex­pla­na­tion. You can re­use it un­der a “Cre­ative ­Com­mons At­tri­bu­tion 4.0 In­ter­na­tion­al” li­cense.

The Pro­grammes with­in [The Com­mons Con­ser­van­cy] each serve a di­ver­si­ty of user­s with dif­fer­ent back­grounds and re­quire­ments, and these are like­ly to be­come ­more het­ero­ge­neous and di­ver­gent over time as us­age spread­s. Dif­fer­ences in­ opin­ion re­gard­ing the vi­sion, fo­cus and strat­e­gy with­in a Pro­gramme may oc­cur, and in gen­er­al are vi­tal to al­low for cre­ativ­i­ty, di­ver­si­ty, spe­cial­i­sa­tion and ­may help ma­tur­ing.

Rather than let­ting in­ter­nal dif­fer­ences get in the way of ac­tu­al de­vel­op­men­t, with a strong de­pen­den­cy on the same re­source es­sen­tial­ly lock­ing di­verg­ing in­ter­ests in­to a sin­gle Pro­gram­me, Pro­grammes are en­cour­aged to al­low Shared As­set Fork­ing. In the con­text of this doc­u­men­t, the terms Shared As­set Fork­ing and Shared As­set Fork will mean that a Pro­gramme is split in­to mul­ti­ple Pro­grammes, and each such de­scen­dant SHALL be en­ti­tled to in­de­pen­dent­ly use shared in­tan­gi­ble as­sets — such as copy­right, trade mark­s, patents, databas­es, in­te­grat­ed cir­cuit lay­out de­sign and the like — (or a sub­set of the­se) of the o­rig­i­nal Pro­gramme.

It bares not­ing that all Free/Open li­cens­es al­low cre­at­ing mod­i­fi­ca­tion­s, ­com­pos­ite/deriva­tive works and sim­i­lar re-us­es of the as­sets — in­clud­ing ­fork­ing. Noth­ing in this doc­u­ment pre­cludes any­body from fork­ing the Pro­gram­me based sole­ly on the Pro­gram­me’s out­bound li­cense(s).

Shared As­set Fork­ing is es­pe­cial­ly rel­e­vant in the case of soft­ware patents, s­ince one or more of the de­scen­dants of a Pro­gramme may at a lat­er stage ­Grad­u­ate (see DRACC “Grad­u­a­tion”) in­to a sep­a­rate le­gal en­ti­ty while oth­er­s re­main in­side [The Com­mons Con­ser­van­cy]. There are a num­ber of oth­er sit­u­a­tion­s where shar­ing as­sets through a Shared As­set Fork can be the most rea­son­able and prac­ti­cal so­lu­tion, e.g. for re­solv­ing sig­nif­i­cant in­ter­nal dif­fer­ences of opin­ion or “in­com­pat­i­bil­ité d’humeur”.

For some types of as­sets (such as trade mark­s) the choic­es to be made dur­ing Shared As­set Fork­ing may be more com­plex, but not im­pos­si­ble pro­vid­ed that there is a shared will to move for­ward. Unique to [The Com­mons Con­ser­van­cy]’s Shared As­set Fork­ing, and in con­trast to nor­mal li­cense-based fork­ing, is that the dif­fer­ent de­scen­dants of a Pro­gramme can agree to con­tin­ue to share as­set­s after the Shared As­set Fork is ef­fec­tu­at­ed — es­sen­tial­ly re­mov­ing bar­ri­ers for ­con­tin­ued col­lab­o­ra­tion across Shared As­set Fork­s.

The ac­tu­al pro­ce­dure for de­cid­ing when and how to Shared As­set Fork is de­fined ­by each in­di­vid­u­al Pro­gramme it­self in its statutes and reg­u­la­tion­s. A Pro­gramme MAY for in­stance del­e­gate the Shared As­set Fork­ing pro­ce­dure to it­s ­gov­er­nance body, or de­fine a bot­tom up pro­ce­dure (pos­si­bly in­volv­ing trust­ed third par­ties act­ing as ar­biter) to al­low its com­mu­ni­ty to ini­ti­ate a Shared As­set Fork pend­ing cer­tain con­di­tion­s, or even dis­al­low Shared As­set Fork­ing. There may al­so be pro­vi­sions on how to deal with in­di­vis­i­ble as­sets such as ­do­main names, such as a shared land­ing page ex­plain­ing the dif­fer­ences. [The ­Com­mons Con­ser­van­cy] aims to have pro­vi­sions in all its com­mon pro­ce­dures to al­low for mu­tu­al own­er­ship of as­sets across Shared As­set Fork­s. This doc­u­men­t de­scribes the process which MUST be fol­lowed in a Shared As­set Fork­ing sce­nar­i­o (in this pre­cise or­der):

  1. When a Pro­gramme wants to al­low a Shared As­set Fork it SHALL ini­tate the Pub­lic Con­sul­ta­tion (see DRACC “Pub­lic Con­sul­ta­tion”).
  2. As soon as the Board of [The Com­mons Con­ser­van­cy] re­ceives the re­quest for Pub­lic Con­sul­ta­tion, a copy of any and all on­line or oth­er archiev­able in­tan­gi­ble as­sets from the orig­i­nal Pro­gramme SHALL be archived by [The ­Com­mons Con­ser­van­cy] with the help of the orig­i­nal Pro­gramme to mark the s­tart­ing state of the post-Shared As­set Fork Pro­grammes. Where pos­si­ble, ­soft­ware nec­es­sary to main­tain said as­sets SHOULD be in­clud­ed.
  3. If the Pub­lic Con­sul­ta­tion is favourable the Shared As­set Fork is for­mal­ly ­ef­fec­tu­at­ed.

For the pur­pose of con­tri­bu­tion of as­sets to the new Pro­grammes, ex­ist­ing a­gree­ments with con­trib­u­tors ref­er­enc­ing on­ly the orig­i­nal Pro­gramme SHALL be in­ter­pret­ed as ex­tend­ing to all Shared As­set Forks (giv­en that these are al­l ­pos­si­ble “fu­tures” of the orig­i­nal Pro­gramme as ref­er­enced in those a­gree­ments, and in ac­cor­dance with the statutes and reg­u­la­tions of that Pro­gram­me) un­til these are re­placed by new agree­ments with difer­ent con­di­tion­s.