Разуменне юрыдычных наступстваў адкрытага зыходнага кода

Падзяліцца сваёй творчасцю з усім светам можа быць захапляльным і карысным вопытам. Гэта таксама можа азначаць мноства юрыдычных аспектаў, пра якія вы нават не падазравалі. На шчасце, вам не трэба пачынаць з нуля. Мы паклапаціліся пра вашы юрыдычныя патрэбы. (Перш чым паглыбляцца, абавязкова прачытайце нашу адмову ад адказнасці.

Чаму людзей так хвалюе прававы бок адкрытага кода?

Рады, што вы спыталі! Калі вы выконваеце творчую працу (напрыклад, тэкст, графіку ці код), гэтая праца па змаўчанні знаходзіцца пад выключным аўтарскім правам. Гэта значыць, што закон мяркуе, што як аўтар сваёй працы вы маеце права голасу адносна таго, што іншыя могуць з ёй рабіць.

Увогуле, гэта азначае, што ніхто іншы не можа выкарыстоўваць, капіяваць, распаўсюджваць ці змяняць вашу працу, не падвяргаючыся рызыцы разбору, канфіскацыі ці судовага працэсу.

Аднак адкрыты зыходны код — гэта незвычайная сітуацыя, паколькі аўтар чакае, што іншыя будуць выкарыстоўваць, змяняць і дзяліцца працай. Але паколькі юрыдычна законным па змаўчанні па-ранейшаму застаецца выключнае аўтарскае права, вам патрэбна ліцэнзія, у якой відавочна пазначаны гэтыя дазволы.

Калі вы не прыменіце ліцэнзію для адкрытага зыходнага кода, кожны, хто ўносіць свой уклад у ваш праект, таксама становіцца эксклюзіўным праваўладальнікам сваёй працы. Гэта азначае, што ніхто не можа выкарыстоўваць, капіяваць, распаўсюджваць ці змяняць іх матэрыялы — і гэты «ніхто» ўключае вас.

Нарэшце, ваш праект можа мець залежнасці ад ліцэнзійных патрабаванняў, пра якія вы не ведалі. Супольнасць вашага праекта або палітыка вашага працадаўцы таксама могуць патрабаваць ад вашага праекта выкарыстання пэўных ліцэнзій адкрытага зыходнага кода. Мы разгледзім гэтыя сітуацыі ніжэй.

Ці з’яўляюцца адкрытымі публічныя праекты GitHub?

Калі вы ствараеце новы праект на GitHub, у вас ёсць магчымасць зрабіць рэпазітар прыватным (прыватным) або публічным (агульнадаступным).

Стварыць рэпазітар

Зрабіць ваш праект GitHub публічным — гэта не тое самае, што ліцэнзаваць ваш праект. На агульнадаступныя праекты распаўсюджваюцца Умовы выкарыстання GitHub, якія дазваляюць іншым праглядаць і рабіць адгалінаванне (fork) вашага праекта. Але ў астатнім ваша праца не мае дазволаў.

Калі вы хочаце, каб іншыя маглі выкарыстоўваць, распаўсюджваць, змяняць ці ўносіць свой уклад у ваш праект, вам неабходна ўключыць ліцэнзію адкрытага зыходнага кода. Напрыклад, нехта не можа законна выкарыстоўваць якую-небудзь частку вашага праекта GitHub у сваім кодзе, нават калі ён агульнадаступны, калі вы відавочна не дадзіце яму на гэта права.

Проста дайце мне што заўгодна, што трэба для абароны майго праекта.

Вам пашанцавала, таму што сёння ліцэнзіі адкрытага зыходнага кода стандартызаваны і простыя ў выкарыстанні. Вы можаце скапіяваць і ўставіць існуючую ліцэнзію прама ў свой праект.

MIT, Apache 2.0 і GPLv3 — самыя папулярныя ліцэнзіі адкрытага зыходнага кода, але на выбар ёсць і іншыя варыянты. Вы можаце знайсці поўны тэкст гэтых ліцэнзій і інструкцыі па іх выкарыстанні на сайце choosealicense.com.

Калі вы ствараеце новы праект на GitHub, вас папросяць дадаць ліцэнзію.

Якая ліцэнзія адкрытага зыходнага кода падыходзіць для майго праекта?

Калі вы пачынаеце з чыстага ліста, цяжка памыліцца з ліцэнзіяй MIT. Яна кароткая, вельмі простая для разумення і дазваляе любому рабіць што заўгодна, калі ў яго ёсць копія ліцэнзіі і згадка вашага аўтарскага права. Вы зможаце выпусціць праект пад іншай ліцэнзіяй, калі спатрэбіцца.

У адваротным выпадку выбар правільнай ліцэнзіі для адкрытага зыходнага кода вашага праекта залежыць ад вашых мэтаў.

Ваш праект, хутчэй за ўсё, мае (або будзе мець) залежнасці. Напрыклад, калі вы адкрыеце зыходны код праекта Node.js, вы, верагодна, будзеце выкарыстоўваць бібліятэкі з Node Package Manager (npm). Кожная з гэтых бібліятэк, ад якіх вы залежыце, будзе мець уласную ліцэнзію адкрытага зыходнага кода. Калі кожная з іх ліцэнзій з’яўляецца «дазваляльнай» (дае агульнадаступны дазвол на выкарыстанне, змяненне і сумеснае выкарыстанне без якіх-небудзь умоў для наступнага ліцэнзавання), вы можаце выкарыстоўваць любую ліцэнзію, якую хочаце. Агульныя дазваляльныя ліцэнзіі ўключаюць MIT, Apache 2.0, ISC і BSD.

З іншага боку, калі якая-небудзь з ліцэнзій вашых залежнасцей з’яўляецца «строгім аўтарскім левам» (strong copyleft) (таксама дае такія ж агульнадаступныя дазволы пры ўмове выкарыстання той жа ліцэнзіі ў далейшым), тады ваш праект павінен будзе выкарыстоўваць тую ж ліцэнзію. Агульныя ліцэнзіі са строгім аўтарскім левам уключаюць GPLv2, GPLv3 і AGPLv3.

Вы таксама можаце разгледзець супольнасці, якія, як вы спадзецеся, будуць выкарыстоўваць і ўносіць свой уклад у ваш праект:

  • Вы хочаце, каб ваш праект выкарыстоўваўся ў якасці залежнасці іншымі праектамі? Верагодна, лепш за ўсё выкарыстоўваць самую папулярную ліцэнзію ў вашай адпаведнай супольнасці. Напрыклад, MIT — самая папулярная ліцэнзія для бібліятэк npm.
  • Вы хочаце, каб ваш праект спадабаўся буйным прадпрыемствам? Буйнаму бізнесу, хутчэй за ўсё, спатрэбіцца відавочная патэнтная ліцэнзія ад усіх удзельнікаў. У гэтым выпадку Apache 2.0 дапаможа вам (і ім).
  • Вы хочаце, каб ваш праект прыцягнуў удзельнікаў, якія не хочуць, каб іх уклад выкарыстоўваўся ў праграмным забеспячэнні з закрытым зыходным кодам? GPLv3 або (калі яны таксама не хочуць удзельнічаць у службах з закрытым зыходным кодам) AGPLv3 падыдзе.

Ваша кампанія можа мець асаблівыя ліцэнзійныя патрабаванні для праектаў з адкрытым зыходным кодам. Напрыклад, можа спатрэбіцца дазваляльная ліцэнзія, каб кампанія магла выкарыстоўваць ваш праект у прадукце кампаніі з закрытым зыходным кодам. Або ваша кампанія можа запатрабаваць строгую ліцэнзію з аўтарскім левам і дадатковае пагадненне з удзельнікамі (гл. ніжэй), каб толькі ваша кампанія і ніхто іншы маглі выкарыстоўваць ваш праект у праграмным забеспячэнні з закрытым зыходным кодам. Або ў вашай кампаніі могуць быць пэўныя патрэбы, звязаныя са стандартамі, сацыяльнай адказнасцю ці празрыстасцю, любая з якіх можа запатрабаваць пэўнай стратэгіі ліцэнзавання. Пагаворыце з юрыдычным аддзелам вашай кампаніі.

Калі вы ствараеце новы праект на GitHub, вам даецца магчымасць выбраць ліцэнзію. Уключэнне адной з згаданых вышэй ліцэнзій зробіць ваш праект на GitHub адкрытым. Калі вы хочаце ўбачыць іншыя варыянты, наведайце choosealicense.com, каб знайсці прыдатную ліцэнзію для свайго праекта, нават калі гэта не праграмнае забеспячэнне.

Што, калі я хачу змяніць ліцэнзію свайго праекта?

Большасці праектаў не спатрэбіцца мяняць ліцэнзіі. Але часам абставіны мяняюцца.

Напрыклад, па меры росту вашага праекта ён дадае залежнасці або карыстальнікаў, або ваша кампанія змяняе стратэгіі, для любой з якіх можа спатрэбіцца іншая ліцэнзія. Акрамя таго, калі вы грэбавалі ліцэнзаваннем свайго праекта з самага пачатку, дадаванне ліцэнзіі фактычна аналагічна змене ліцэнзій. Пры дадаванні або змене ліцэнзіі на праект неабходна ўлічваць тры асноўныя моманты:

Гэта складана. Вызначэнне сумяшчальнасці і адпаведнасці ліцэнзій, а таксама ўладальнікаў аўтарскіх правоў можа вельмі хутка стаць складаным і заблытаным. Пераход на новую, але сумяшчальную ліцэнзію для новых выпускаў і дапаўненняў адрозніваецца ад пераліцэнзавання ўсіх існуючых дапаўненняў. Прыцягвайце сваю каманду юрыстаў пры першым намеку на жаданне змяніць ліцэнзію. Нават калі ў вас ёсць або вы можаце атрымаць дазвол ад праваўладальнікаў вашага праекта на змяненне ліцэнзіі, улічвайце ўплыў гэтага змянення на іншых карыстальнікаў і ўдзельнікаў вашага праекта. Думайце аб змене ліцэнзіі як аб «кіраўнічай падзеі» для вашага праекта, якая, хутчэй за ўсё, пройдзе гладка пры выразнай камунікацыі і кансультацыях з зацікаўленымі бакамі вашага праекта. Яшчэ адна прычына выбраць і выкарыстоўваць адпаведную ліцэнзію для вашага праекта з самага пачатку!

Існуючая ліцэнзія вашага праекта. Калі існуючая ліцэнзія вашага праекта сумяшчальная з ліцэнзіяй, на якую вы хочаце перайсці, вы можаце проста пачаць выкарыстоўваць новую ліцэнзію. Гэта таму, што калі ліцэнзія A сумяшчальная з ліцэнзіяй B, вы будзеце выконваць умовы A, выконваючы умовы B (але не абавязкова наадварот). Таму, калі вы ў цяперашні час выкарыстоўваеце дазваляльную ліцэнзію (напрыклад, MIT), вы можаце перайсці на ліцэнзію з дадатковымі ўмовамі, пры ўмове, што вы захоўваеце копію ліцэнзіі MIT і любыя звязаныя паведамленні аб аўтарскіх правах (г.зн. працягваеце выконваць мінімальныя ўмовы ліцэнзіі MIT). Але калі ваша бягучая ліцэнзія не дазваляльная (напрыклад, аўтарскае лева або ў вас няма ліцэнзіі) і вы не з’яўляецеся адзіным уладальнікам аўтарскіх правоў, вы не можаце проста змяніць ліцэнзію вашага праекта на MIT. Па сутнасці, з дазваляльнай ліцэнзіяй праваўладальнікі праекта загадзя далі дазвол на змяненне ліцэнзій.

Існуючыя праваўладальнікі вашага праекта. Калі вы з’яўляецеся адзіным удзельнікам свайго праекта, то вы ці ваша кампанія з’яўляецеся адзіным праваўладальнікам праекта. Вы можаце дадаць ці змяніць любую ліцэнзію, якую захочаце вы ці ваша кампанія. У адваротным выпадку могуць быць іншыя праваўладальнікі, з якімі вам спатрэбіцца згода для змены ліцэнзій. Хто яны? Людзі, у якіх ёсць каміты ў вашым праекце, — добрае месца для пачатку. Але ў некаторых выпадках аўтарскія правы належаць працадаўцам гэтых людзей. У некаторых выпадках людзі будуць уносіць толькі мінімальны ўклад, але не існуе жорсткага правіла, паводле якога ўклады з выкарыстаннем пэўнай колькасці радкоў кода не падлягаюць аўтарскаму праву. Што рабіць? Гэта залежыць. Для адносна невялікага і маладога праекта можа аказацца мэтазгодным пераканаць усіх існуючых удзельнікаў пагадзіцца на змяненне ліцэнзіі ў іш’ю або пул-рэквесце. Для буйных і доўгажывучых праектаў вам, магчыма, прыйдзецца шукаць мноства ўдзельнікаў і нават іх спадчыннікаў. Mozilla спатрэбіліся гады (2001-2006), каб пераліцэнзаваць Firefox, Thunderbird і спадарожнае праграмнае забеспячэнне.

У якасці альтэрнатывы вы можаце папрасіць удзельнікаў загадзя пагадзіцца (пасродкам дадатковага пагаднення з удзельнікамі — гл. ніжэй) на пэўныя змяненні ліцэнзіі пры пэўных умовах, акрамя тых, якія дазволены вашай існуючай ліцэнзіяй з адкрытым зыходным кодам. Гэта крыху змяняе складанасць змены ліцэнзій. Вам загадзя спатрэбіцца дадатковая дапамога юрыстаў, і вы ўсё роўна захочаце выразна камунікаваць з зацікаўленымі бакамі вашага праекта пры змене ліцэнзіі.

Ці патрабуецца для майго праекта дадатковае пагадненне з удзельнікамі?

Магчыма, не. Для пераважнай большасці праектаў ліцэнзія для адкрытага зыходнага кода неяўна служыць як уваходнай (ад удзельнікаў), так і выходнай (для іншых удзельнікаў і карыстальнікаў) ліцэнзіяй. Калі ваш праект размешчаны на GitHub, то Умовы выкарыстання GitHub робяць “inbound = outbound” відавочным значэннем па змаўчанні.

Дадатковае пагадненне з удзельнікам, якое часта называюць ліцэнзійным пагадненнем удзельніка (CLA), можа ствараць адміністрацыйную працу для суправаджаючых праект. Колькі працы дадае пагадненне, залежыць ад праекта і рэалізацыі. Простае пагадненне можа патрабаваць, каб удзельнікі пацвердзілі адным пстрычкай мышы, што ў іх ёсць правы, неабходныя для ўнясення ўкладу ў адпаведнасці з ліцэнзіяй праекта з адкрытым зыходным кодам. Больш складанае пагадненне можа запатрабаваць юрыдычнай праверкі і подпісу з боку працадаўцаў удзельнікаў.

Акрамя таго, дадаванне «папяровай працы», якая, на думку некаторых, з’яўляецца непатрэбнай, цяжкай для разумення або несправядлівай (калі атрымальнік пагаднення атрымлівае больш правоў, чым удзельнікі або грамадскасць праз ліцэнзію праекта з адкрытым зыходным кодам), дадатковае пагадненне з удзельнікамі можа быць успрынята як недружалюбнае да супольнасці праекта.

Вось некаторыя сітуацыі, калі вы можаце захацець разгледзець пытанне аб дадатковым пагадненні з удзельнікамі для вашага праекта:

  • Вашы юрысты хочуць, каб усе ўдзельнікі відавочным чынам прынялі (падпісаць, онлайн або афлайн) умовы ўкладу, магчыма, таму, што яны лічаць, што самой ліцэнзіі з адкрытым зыходным кодам недастаткова (нават калі гэта так!). Калі гэта адзіная праблема, павінна быць дастаткова пагаднення з удзельнікам, якое пацвярджае ліцэнзію праекта з адкрытым зыходным кодам. Ліцэнзійнае пагадненне з індывідуальным удзельнікам jQuery з’яўляецца добрым прыкладам палегчанага пагаднення з дадатковым удзельнікам.
  • Вы або вашы юрысты хочаце, каб распрацоўшчыкі даказалі, што кожнае дзеянне, якое яны здзяйсняюць, санкцыянавана. Патрабаванне Сертыфіката распрацоўшчыка — гэта колькасць праектаў, якія гэта забяспечваюць. Напрыклад, супольнасць Node.js выкарыстоўвае DCO замест іх папярэдняга CLA. Простым варыянтам аўтаматызацыі прымусовага прымянення DCO ў вашым рэпазітары з’яўляецца DCO Probot.
  • У вашым праекце выкарыстоўваецца ліцэнзія з адкрытым зыходным кодам, якая не ўключае прамую выдачу патэнта (напрыклад, MIT), і вам патрэбен патэнт ад усіх удзельнікаў, некаторыя з якіх могуць працаваць у кампаніях з вялікімі партфелямі патэнтаў, якія могуць быць выкарыстаны для вашага таргетынгу або іншых удзельнікаў і карыстальнікаў праекта. Ліцэнзійнае пагадненне з індывідуальным удзельнікам Apache з’яўляецца часта выкарыстоўваным пагадненнем з дадатковым удзельнікам, у якім выдача патэнта з’яўляецца копіяй той, якая змяшчаецца ў ліцэнзіі Apache License 2.0.
  • Ваш праект знаходзіцца пад ліцэнзіяй з аўтарскім левам, але вам таксама неабходна распаўсюджваць прапрыетарную версію праекта. Вам спатрэбіцца, каб кожны ўдзельнік прызначыў вам аўтарскія правы або прадаставіў вам (але не грамадскасці) дазваляльную ліцэнзію. Пагадненне з удзельнікам MongoDB з’яўляецца прыкладам такога тыпу пагаднення.
  • Вы думаеце, што вашаму праекту можа спатрэбіцца змяніць ліцэнзіі на працягу яго тэрміну службы, і хочаце, каб удзельнікі загадзя пагадзіліся на такія змяненні.

Калі вам сапраўды трэба заключыць з вашым праектам дадатковае пагадненне з удзельнікамі, разгледзьце магчымасць выкарыстання такой інтэграцыі, як памочнік CLA, каб звесці да мінімуму адцягненне ўдзельнікаў.

Што трэба ведаць юрыдычнаму аддзелу маёй кампаніі?

Калі вы выпускаеце праект з адкрытым зыходным кодам у якасці супрацоўніка кампаніі, па-першае, ваша юрыдычная група павінна ведаць, што вы адкрываеце зыходны код праекта.

Добра гэта ці дрэнна, няхай яны ведаюць, нават калі гэта асабісты праект. У вас, верагодна, ёсць «пагадненне аб інтэлектуальнай уласнасці супрацоўнікаў» з вашай кампаніяй, якое дае ім некаторы кантроль над вашымі праектамі, асабліва калі яны наогул звязаны з бізнесам кампаніі або вы выкарыстоўваеце якія-небудзь рэсурсы кампаніі для распрацоўкі праекта. Ваша кампанія павінна лёгка даць вам дазвол, і, магчыма, яно ўжо было атрымана ў рамках спрыяльнага для супрацоўнікаў пагаднення аб інтэлектуальнай уласнасці або палітыкі кампаніі. У адваротным выпадку вы можаце весці перамовы (напрыклад, патлумачыць, што ваш праект служыць мэтам прафесійнага навучання і вашага развіцця ў мэтах кампаніі) або не працаваць над сваім праектам, пакуль не знойдзеце лепшую кампанію.

Калі вы адкрываеце зыходны код праекта сваёй кампаніі, абавязкова паведаміце ім пра гэта. У вашай юрыдычнай групы, верагодна, ужо ёсць палітыка ў дачыненні да таго, якую ліцэнзію з адкрытым зыходным кодам (і, магчыма, дадатковае пагадненне з удзельнікам) выкарыстоўваць, у залежнасці ад бізнес-патрабаванняў і вопыту кампаніі ў дачыненні да забеспячэння адпаведнасці вашага праекта ліцэнзіям залежнасцей. Калі не, то вам з імі пашанцавала! Ваша юрыдычная каманда павінна быць гатовая працаваць з вамі, каб разабрацца ў гэтым пытанні. Некаторыя рэчы для разважання:

  • Староннія матэрыялы: Ці змяшчае ваш праект залежнасці, створаныя іншымі, ці іншым чынам уключае або выкарыстоўвае чужы код? Калі гэта адкрыты зыходны код, вам неабходна выконваць ліцэнзіі на адкрыты зыходны код матэрыялаў. Гэта пачынаецца з выбару ліцэнзіі, якая працуе са староннімі ліцэнзіямі з адкрытым зыходным кодам (гл. вышэй). Калі ваш праект змяняе або распаўсюджвае староннія матэрыялы з адкрытым зыходным кодам, то ваша юрыдычная група таксама захоча ведаць, што вы выконваеце іншыя ўмовы старонніх ліцэнзій з адкрытым зыходным кодам, такія як захаванне паведамленняў аб аўтарскіх правах. Калі ў вашым праекце выкарыстоўваецца чужы код, які не мае ліцэнзіі з адкрытым зыходным кодам, вам, верагодна, прыйдзецца папрасіць старонніх распрацоўшчыкаў дадаць ліцэнзію з адкрытым зыходным кодам, а калі вы не можаце яго атрымаць, спыніце выкарыстоўваць іх код у сваім праекце.

  • Камерцыйная таямніца: Падумайце, ці ёсць у праекце нешта, што кампанія не хоча рабіць даступным для шырокай публікі. Калі гэта так, вы можаце адкрыць зыходны код астатняй часткі вашага праекта пасля вымання матэрыялу, які хочаце захаваць канфідэнцыяльным.

  • Патэнты: Ці падае ваша кампанія заяўку на патэнт, адкрыты зыходны код якога ваш праект будзе ўяўляць сабой публічнае раскрыццё? На жаль, вас могуць папрасіць пачакаць (або, магчыма, кампанія перагледзіць мудрасць заяўкі). Калі вы чакаеце ўдзелу ў сваім праекце з боку супрацоўнікаў кампаній з вялікімі патэнтнымі партфелямі, ваша юрыдычная каманда можа захацець, каб вы выкарыстоўвалі ліцэнзію з відавочнай выдачай патэнта ад удзельнікаў (напрыклад, Apache 2.0 або GPLv3), або дадатковае пагадненне з удзельнікам (гл. вышэй).

  • Гандлёвыя маркі: Двойчы праверце, што назва вашага праекта не канфліктуе з існуючымі гандлёвымі маркамі. Калі вы выкарыстоўваеце ў праекце ўласныя гандлёвыя маркі сваёй кампаніі, праверце, што гэта не выклікае канфліктаў. FOSSmarks — гэта практычнае кіраўніцтва па разуменні гандлёвых марак у кантэксце вольных і адкрытых праектаў.

  • Прыватнасць: Ці збірае ваш праект дадзеныя аб карыстальніках? Ці «звоніць дадому» на серверы кампаніі? Ваша юрыдычная каманда можа дапамагчы вам выконваць палітыкі кампаніі і знешнія рэгламенты.

  • ШІ: Паколькі мадэлі і функцыянальнасць штучнага інтэлекту становяцца неад’емнай часткай праграмнага забеспячэння, важна разумець ліцэнзійныя пагадненні і адпаведнае заканадаўства, якое кантралюе іх выкарыстанне. Нават калі мадэль або сэрвіс заяўляе, што знаходзіцца пад стандартнай ліцэнзіяй з адкрытым зыходным кодам, дадатковыя ўмовы могуць накладваць абмежаванні, такія як прадухіленне злоўжыванняў або махлярства. Новае заканадаўства таксама ўводзіць абмежаванні на тыпы сістэм або дзеянняў, якія могуць выконвацца праграмным забеспячэннем на аснове ШІ.
  • Software Bill of Materials: Software Bill of Materials (SBOM) — гэта ўсебаковы спіс старонніх залежнасцяў, версій, звязаных ліцэнзій і іншых метададзеных. SBOM з’яўляюцца юрыдычна абавязковымі ў пэўных краінах, галінах або з-за кантрактных абавязацельстваў. Запыт на SBOM часта пачынае шлях арганізацыі да адпаведнасці ліцэнзіям.

Калі вы выпускаеце першы праект з адкрытым зыходным кодам вашай кампаніі, вышэйпералічанага больш чым дастаткова (але не хвалюйцеся, большасць праектаў не павінна выклікаць сур’ёзных праблем).

У больш доўгатэрміновай перспектыве ваша юрыдычная каманда можа зрабіць больш, каб дапамагчы кампаніі атрымаць больш карысці ад удзелу ў адкрытым зыходным кодзе і заставацца ў бяспецы:

  • Палітыкі ўдзелу супрацоўнікаў: Разгледзьце магчымасць распрацоўкі карпаратыўнай палітыкі, якая вызначае, як вашы супрацоўнікі ўдзельнічаюць у праектах з адкрытым зыходным кодам. Выразная палітыка зменшыць блытаніну сярод вашых супрацоўнікаў і дапаможа ім уносіць уклад у праекты з адкрытым зыходным кодам у найлепшых інтарэсах кампаніі, як у рамках сваёй працы, так і ў вольны час. Добры прыклад — Model IP and Open Source Contribution Policy ад Rackspace.
  • Што выпускаць: (Амаль) усё? Калі ваша юрыдычная каманда разумее і інвестуе ў стратэгію адкрытага зыходнага кода вашай кампаніі, яна будзе найлепш здольная дапамагаць, а не перашкаджаць вашым намаганням.
  • Адпаведнасць: Нават калі ваша кампанія не выпускае ніякіх праектаў з адкрытым зыходным кодам, яна выкарыстоўвае праграмнае забеспячэнне з адкрытым зыходным кодам ад іншых. Усведамленне і працэс могуць прадухіліць галаўны боль, затрымкі прадуктаў і судовыя пазовы.