我實際上已經做到了。有一次，我在工作中編寫了一些代碼，我意識到它通常是有用的，遠遠超出了我正在從事的特定項目的範圍。因此，我問我的老闆（也是CEO，這是一家非常小的公司）是否可以將其作為開源發布，他說可以，這很好。

注意： 最後一點非常重要。 。作為一名員工，我為公司編寫的代碼是“為租用而製”，這意味著我的創意產品不是我的財產，但我老闆的。因此，未經法定所有人的許可，將其發布至少是處以解僱罪，也很可能是犯罪。

（IANAL，但這是一個相當容易理解且廣泛理解的接受的適用美國法律解釋。）

您為工作而編寫的代碼是公司的財產。以開源或其他方式發布它會侵犯版權，並被解僱。假設該代碼是開源的，而實際上卻歸您的公司所有，這也會給使用此代碼的任何人帶來法律上的噩夢。

“修改”代碼對您沒有幫助。您正在創建衍生作品。在復制您的衍生作品之前，這就是侵犯版權。

我不同意這裡的多數意見。顯然，大多數人都說您不應該這樣做。我不一定對此表示不同意見，但是在很多情況下，潛台詞和明顯的信息是您在法律上不能這樣做，而不僅僅是您不應該這樣做。在您的情況和一般情況下，該消息的法律正確性還很遙​​遠。

很高興看到，儘管我是少數派，但並不是那麼晦澀，沒有其他答案與我的觀點相符，或者所有與我的觀點一致的答案都被否定了。我同意 @ Kittoes0124信息的精神。

作為少數派，我們當然應該從謹慎的多數中學到一些東西：許多開發人員因侵犯版權或其他原因而被解僱，甚至更糟。侵犯知識產權。不幸的是，結果導致社區的防禦能力過高，結果是開源社區和整個社會受到損害，這得益於強大的OS社區。

一個apropos評論引用了“潔淨室設計”，它是一種法律上受人尊敬且經過實踐檢驗的功能複制方法，不會侵犯版權。請注意鏈接的文章中有關潔淨室設計的內容，並帶有特定的法律案例支持：

潔淨室設計通常是最佳做法，但法律並不嚴格要求。在NEC Corp.訴Intel Corp.（1990年）一案中，NEC尋求針對英特爾指控NEC的工程師只是在其NEC V20克隆中復制8086處理器微代碼的聲明性判決。一名美國法官裁定，雖然NEC的內部代碼的早期內部修訂確實侵犯了版權，但實際上進入NEC產品的後一個版本雖然是前者的衍生版本，卻與Intel的微代碼有很大不同，因此可以認為該版本不包含以下內容：侵犯版權。

這是美國的正確標準。它基於判例法，而不是開發人員的意見或軼事。您可以參考專有代碼和個人經驗作為參考，甚至可以將文字代碼用作具體的起點，但是最終代碼必須“足夠不同”。

這似乎是模棱兩可的和任意標準，因為事實就是如此。法官對規則的解釋寬大，但規則很明確。普遍的看法是“安全勝於遺憾”，這就是為什麼許多專業人員遺憾地避免公開顯示任何代碼的原因。通常，尋求內部公司的批准更為明智，風險也較小，但這在法律上通常不是必需的。如果您簽署了一些其他文件，或者您所在的管轄區有特殊法律，則可能在法律上是必不可少的。

在您的特定情況下，重要的一點是，您提議的代碼與以下代碼之間存在重要差異。原始代碼。您聲明原始代碼是特定於平台的，並且建議提供獨立於平台的代碼。這意味著遺留代碼無法支持某些用例。這是證明明顯差異的一種方法。您可以通過使解決方案有意與舊平台不兼容來進一步增強這種差異。這將意味著根本沒有用例重疊。

我不是律師，這也不是法律建議。我確實建議您決定是否要這樣做，請諮詢律師。我看到美國有很多法律先例可以支持這樣一個事實，那就是在您編寫代碼時，您自然會汲取先前的經驗和知識，包括參考具體的代碼示例，但這並不意味著開源是非法的。

不必擔心使用相同的語法。許多語言和庫僅提供一種完成某件事的語法方法，並且對於函數，變量等存在最佳實踐，因此對於功能複製而言，即使使用相同的變量名也不可避免。在這種情況下，可能不會出現重大差異，因此不是合理的要求。

請記住，如果您簽署了特定的NDA或某些其他文檔，則這些一般性概念將是完全不可抗拒的。 p>另外兩個相關說明。首先，在美國，侵犯知識產權的行為受到限制（來源）：

侵犯版權可能導致民事和/或刑事責任。刑事訴訟時效為五年，而民事訴訟時效為三年。

第二點是，知識產權只有4種（AFAIK / IANAL） （源）：

1. 版權
2. 商標
3. 專利
4. 商業秘密
ol>

如果您要處理的IP不屬於1-3類，那麼修改代碼供自己使用的法律問題就更少了。在我看來，如果X是其他軟件中的常見模式或功能，特別是如果它已存在於開源項目中，那麼任何人都可能認為X是商業秘密。

簡短的回答是未經明確許可。

您需要問問上級。您的經理很可能需要將問題向上傳遞。

如果您很幸運，公司將為此提供處理程序。如果不是這樣，找出以前是否做過這可能會有所幫助。問你的同事。先前發布代碼的示例是一個非常有用的先例。來自另一家公司的示例也可能會有所幫助，來自自由軟件和開放源代碼社區的資源也將對流程和含義進行解釋。

在發布任何代碼之前，公司需要對其進行審核，以確保代碼完全歸公司所有。

對於更詳細的法律含義和資源以幫助簡化流程，您可能會在 https://opensource.stackexchange.com/

儘管到目前為止提供的答案是很好的建議，但我認為它們走得太遠了。您編寫的代碼屬於您的雇主，但他們通常不擁有在實施過程中獲得的知識和技能。

讓我們假設您的任務是使用提供給以下用戶的專有API來實現隨機數生成器您由第三方；為簡單起見，此API由單個簽名 public byte [] GetRandomBytes（int length）組成。您需要使用您選擇的開放源代碼算法（例如PCG或Xoroshiro）實現一個新類 RandomNumberGenerator ，該類公開了APIs public long GetNextInt64（）和 public long GetNextInt64（long lowerBound，long upperBound）。

您的雇主將擁有您編寫的特定代碼，但這幾乎就結束了。沒有任何事情可以阻止您以後實現自己的RNG版本，該版本依賴於 / dev / random 作為隨機字節的源。使用不同的算法和函數簽名（在這種情況下有意義）可能是一種明智的防禦措施，但是越來越重要的是，這取決於開放源材料。

肯定有很多到目前為止，大多數情況下應該遵循不要做！的建議，但要求美國程序員做的絕大多數事情屬於常識類別。

在我的公司中，我們有一個開源政策。

要使用開放源代碼，必須清除許可證才能使用，並規定所有限制。

要對開放源代碼做出貢獻，必須準備並提交代碼以供審核並獲得批准。

您需要在公司中查找政策。

我是否可以改編我為工作而編寫的代碼，並將其作為開放源代碼發布

永遠不要未經知識產權所有人（可能是您的雇主）的明確授權，您的客戶或雇主的客戶。

程序員不是代碼猴子，程序中的價值不僅在代碼中，而且在實現邏輯中，即代碼背後的原始思想。

如果您使用現有代碼的任何部分來生成新代碼，甚至使用代碼背後的任何原始想法，那麼您正在生成的衍生作品都必須經過原始所有者的授權工作。

如果您既不重複使用代碼，也不重複使用最初的想法，那麼您一開始便無所事事，除非您僅使用技能來製作與之無關的新作品。

如果您希望代碼成為開放源代碼，則需要合法獲取許可證。使用無效的源代碼許可證發布代碼以便可用，這是為真誠使用代碼的人設置合法的定時炸彈。他們可能被起訴要求賠償損失，並可能獲得禁止使用受版權保護的材料的禁令。您不想這樣做。您需要使發行版明確合法。這必須由具有足夠權限的人員來完成，而您需要確定是誰。這應該被書面和簽字。口頭協議從技術上講已經足夠，但是很難證明這種口頭協議，而且容易讓人說可以否認他或她說了這樣的話或意思是這樣，因此提起訴訟是很可能的。

我很高興看到有人試圖以開放源代碼許可證發佈軟件，但是以無效許可證發佈軟件是一個壞主意。

我不是律師。但是，我是一名軟件開發人員（在法國），並且確實（專業地）為開源項目做出了貢獻，甚至有時還專門開發開源軟件。

您需要獲得雇主的許可。

請記住，源代碼通常受版權或商業秘密保護，並且您在工作場所編寫的源代碼屬於（除非某些合同有書面規定）。在某些工作合同中，您編寫的每個代碼（甚至在家中）都屬於雇主。您是在辦公室用C語言編寫的）。但是，即使是這種情況，您也最好（至少通過電子郵件）詢問老闆，並徵得他/她的許可。

在歐洲，算法通常無法得到保護（但是其源代碼實現可以並且通常是）。在美國，我聽說甚至算法都可以申請專利。

順便說一句，您不希望老闆遇到麻煩。因此，無論如何，您應該告知並詢問他。他可以決定幫助您正式將該代碼作為開放源代碼，或者他可以提醒您可能給自己帶來麻煩。如果您獲得了老闆的（至少是電子郵件）書面批准，那麼至少您是真誠的行事。