Đăng ký bản quyền phần mềm tại Hà Nội bảo vệ chương trình máy tính toàn diện

Đăng ký bản quyền phần mềm tại Hà Nội giúp chủ sở hữu chương trình máy tính củng cố căn cứ pháp lý đối với sản phẩm công nghệ đã đầu tư phát triển, đặc biệt trong môi trường phần mềm dễ bị sao chép hoặc khai thác trái phép. Hồ sơ cần được chuẩn hóa từ thông tin tác giả đến tài liệu thể hiện nội dung chương trình.

Phần mềm không chỉ là “một đoạn code” – hãy dựng bản đồ tài sản trước khi đăng ký

Khi chuẩn bị đăng ký bản quyền phần mềm tại Hà Nội, sai lầm phổ biến là xem toàn bộ sản phẩm công nghệ như một khối duy nhất mang tên “source code”. Trên thực tế, một sản phẩm phần mềm có thể đồng thời chứa mã nguồn, mã máy, kiến trúc chương trình, giao diện, cơ sở dữ liệu, tài liệu kỹ thuật, tài liệu hướng dẫn, hình ảnh, biểu tượng, âm thanh và nhiều thành phần do những chủ thể khác nhau sáng tạo.

Việc dựng “bản đồ tài sản” trước khi lập hồ sơ giúp doanh nghiệp biết chính xác mình đang đăng ký đối tượng nào, ai là tác giả, công ty sở hữu phần nào và phần nào đang sử dụng từ bên thứ ba. Đây cũng là bước chuẩn bị quan trọng khi doanh nghiệp gọi vốn, bán phần mềm, cấp phép sử dụng hoặc thực hiện due diligence sở hữu trí tuệ.

Mã nguồn, mã máy và cấu trúc chương trình có vai trò khác nhau thế nào?

Mã nguồn là phần lệnh mà lập trình viên viết bằng ngôn ngữ lập trình; mã máy là dạng chương trình sau khi được biên dịch hoặc chuyển đổi để thiết bị có thể thực thi. Pháp luật sở hữu trí tuệ xác định chương trình máy tính được bảo hộ như tác phẩm văn học, bất kể chương trình được thể hiện dưới dạng mã nguồn hay mã máy.

Cấu trúc chương trình lại rộng hơn một tập hợp dòng code. Nó có thể bao gồm cách tổ chức module, luồng xử lý, quan hệ giữa các thành phần và kiến trúc triển khai. Khi chuẩn bị hồ sơ, doanh nghiệp nên tách rõ nội dung nào thực sự được thể hiện thành tác phẩm và nội dung nào mới chỉ là ý tưởng hoặc nguyên lý vận hành, bởi quyền tác giả chủ yếu bảo vệ hình thức thể hiện cụ thể chứ không tạo độc quyền đối với mọi ý tưởng đứng phía sau phần mềm.

Giao diện phần mềm có nằm trong cùng lớp bảo hộ với chương trình máy tính không?

Giao diện không nên bị xem đơn giản là “ảnh chụp màn hình đính kèm source”. Theo quy định hiện hành về bản sao chương trình máy tính, hồ sơ còn phải thể hiện giao diện của chương trình; bản điện tử phải chứa code và giao diện của chương trình có thể cài đặt để chạy. Điều đó cho thấy giao diện là một phần quan trọng khi xác định phiên bản chương trình được đưa vào hồ sơ.

Tuy nhiên, các thành phần đồ họa của giao diện như bộ icon, hình minh họa, layout, bộ hình nhận diện hoặc thiết kế màn hình có thể cần được đánh giá độc lập nếu chúng có tính sáng tạo riêng. Vì vậy, doanh nghiệp công nghệ tại Hà Nội nên phân biệt giữa đăng ký chương trình máy tính và chiến lược bảo hộ riêng đối với những tài sản thiết kế quan trọng của sản phẩm.

Tài liệu hướng dẫn và thiết kế hệ thống có thể phát sinh quyền riêng ra sao?

User manual, đặc tả chức năng, tài liệu API, sơ đồ hệ thống, tài liệu kiến trúc hoặc bộ tài liệu onboarding không mặc nhiên “biến mất” vào quyền của source code. Nếu chúng chứa nội dung sáng tạo và được thể hiện dưới một hình thức cụ thể, từng tài liệu có thể phát sinh quyền tác giả tương ứng với chính nội dung được sáng tạo.

Điều này đặc biệt đáng chú ý khi startup thuê một đơn vị viết tài liệu nhưng một đơn vị khác lập trình. Công ty có thể sở hữu code nhưng chưa chắc đã có đầy đủ quyền đối với hình minh họa, tài liệu hướng dẫn hoặc một số sơ đồ hệ thống nếu hợp đồng chưa xác định rõ phạm vi giao việc và quyền được chuyển giao.

Checklist 15 phút xác định phần mềm đã đủ điều kiện chuẩn bị hồ sơ hay chưa

Không cần chờ sản phẩm “hoàn hảo” mới bắt đầu chuẩn bị đăng ký. Doanh nghiệp chỉ cần xác định được một phiên bản đủ rõ ràng, tác giả của phiên bản đó và căn cứ xác lập quyền sở hữu. Ba câu hỏi dưới đây thường giúp phát hiện rất nhanh những điểm còn thiếu trước khi đi sâu vào bộ hồ sơ.

Phần mềm đã có phiên bản tương đối ổn định để chốt nội dung đăng ký chưa?

“Ổn định” không có nghĩa là phần mềm phải ngừng nâng cấp. Điều quan trọng là doanh nghiệp có thể đóng băng một mốc cụ thể, chẳng hạn version 2.3.1 hoặc release ngày 15/8/2026, và xác định chính xác source code, giao diện cùng các tài liệu đi kèm thuộc phiên bản đó.

Nếu hôm nay tài liệu ghi version 2.1 nhưng repository đã chuyển sang 3.0 và bản thương mại đang chạy 3.2, việc xác định tác phẩm đăng ký sẽ trở nên khó giải thích. Một bản release, commit hoặc tag rõ ràng sẽ giúp hồ sơ kỹ thuật và hồ sơ pháp lý nói cùng một ngôn ngữ.

Danh sách lập trình viên tham gia phát triển đã được xác định đầy đủ chưa?

Doanh nghiệp nên xuất danh sách người từng trực tiếp tham gia phát triển rồi phân loại: ai thực sự sáng tạo code hoặc tài liệu thiết kế; ai chỉ kiểm thử; ai quản lý tiến độ; ai cung cấp yêu cầu nghiệp vụ; ai tham gia trong thời gian rất ngắn.

Pháp luật hiện hành xác định tác giả là người trực tiếp sáng tạo tác phẩm; người chỉ hỗ trợ, góp ý hoặc cung cấp tư liệu không phải vì thế mà trở thành tác giả. Với nhiều người cùng trực tiếp sáng tạo để các phần đóng góp hợp thành một tổng thể hoàn chỉnh, họ có thể là đồng tác giả.

Công ty có tài liệu chứng minh mình sở hữu sản phẩm hay không?

Nếu công ty đứng tên chủ sở hữu, cần trả lời được câu hỏi: quyền đó đến từ đâu? Có thể từ việc giao nhiệm vụ sáng tạo cho nhân viên, giao kết hợp đồng sáng tạo, nhận chuyển giao quyền hoặc một căn cứ hợp pháp khác.

Đối với hồ sơ hiện hành, tài liệu chứng minh quyền sở hữu do giao nhiệm vụ có thể là quyết định hoặc xác nhận giao nhiệm vụ; trường hợp giao kết hợp đồng sáng tạo thì căn cứ có thể là hợp đồng. Đây là lý do một bộ hồ sơ nhân sự được lưu tốt đôi khi quan trọng không kém source code.

Phần mềm do cả team phát triển – xác định tác giả không thể chỉ ghi tên giám đốc

Chức danh quản lý và tư cách tác giả là hai vấn đề khác nhau. Giám đốc có thể là người đại diện pháp luật của công ty, người phê duyệt dự án hoặc người đầu tư tài chính nhưng điều đó không tự động khiến giám đốc trở thành tác giả của chương trình máy tính.

Ai thực sự trực tiếp tham gia sáng tạo chương trình máy tính?

Cần xem xét công việc thực tế chứ không chỉ xem chức danh trên hợp đồng lao động. Developer trực tiếp viết code, người xây dựng một phần thiết kế kỹ thuật có tính sáng tạo hoặc thành viên khác thực sự tham gia tạo nên hình thức thể hiện của chương trình là những người cần được rà soát về tư cách tác giả.

Ngược lại, kế toán thanh toán chi phí dự án, nhân viên kinh doanh đề xuất tính năng hoặc người hỗ trợ nhập dữ liệu không vì tham gia dự án mà trở thành tác giả. Luật hiện hành phân biệt khá rõ người trực tiếp sáng tạo với người chỉ hỗ trợ, góp ý hoặc cung cấp tư liệu.

Project manager có mặc nhiên được xác định là tác giả không?

Không. Nếu project manager chỉ chia task, theo dõi sprint, họp khách hàng và điều phối nguồn lực thì chức danh quản lý dự án chưa đủ để kết luận người đó trực tiếp sáng tạo chương trình.

Tuy nhiên, không nên loại project manager chỉ dựa vào tên chức danh. Nếu người này đồng thời trực tiếp thiết kế giải pháp, xây dựng tài liệu thiết kế có tính sáng tạo hoặc lập trình một phần sản phẩm thì phần đóng góp thực tế vẫn phải được xem xét. Cách an toàn nhất là đối chiếu task, commit, tài liệu thiết kế và lịch sử dự án.

Nhiều lập trình viên cùng tham gia thì kê khai hồ sơ thế nào?

Không nên đưa toàn bộ danh sách nhân sự dự án vào mục tác giả một cách máy móc. Doanh nghiệp cần lập bảng xác định từng người, khoảng thời gian tham gia, phần việc sáng tạo và căn cứ chứng minh. Sau đó mới xác định ai là tác giả hoặc đồng tác giả của phiên bản được đăng ký.

Nếu có đồng tác giả, hồ sơ hiện hành còn đặt ra yêu cầu về văn bản đồng ý của các đồng tác giả, trừ trường hợp tất cả đồng tác giả cùng ký tên trên tờ khai. Việc phân loại đúng từ đầu giúp tránh tình trạng phải quay lại xin chữ ký của nhân sự đã nghỉ việc hoặc freelancer đã mất liên hệ.

Công ty trả lương cho developer chưa chắc đã đủ để hồ sơ quyền sở hữu “đẹp”

Tiền lương chứng minh quan hệ trả công nhưng không phải lúc nào cũng mô tả đầy đủ nhiệm vụ sáng tạo cụ thể. Khi hồ sơ sở hữu trí tuệ được kiểm tra kỹ, chuỗi chứng cứ nên thể hiện được mối liên hệ từ quan hệ lao động đến nhiệm vụ phát triển phần mềm và sản phẩm thực tế được tạo ra.

Hợp đồng lao động cần liên kết với nhiệm vụ phát triển phần mềm ra sao?

Một hợp đồng chỉ ghi “nhân viên kỹ thuật” hoặc “nhân viên IT” có thể quá rộng nếu doanh nghiệp muốn chứng minh người đó được giao sáng tạo chương trình cụ thể. Nên có thêm mô tả công việc, quyết định giao nhiệm vụ, kế hoạch dự án, tài liệu phân công hoặc bằng chứng tương tự.

Luật quy định tổ chức giao nhiệm vụ sáng tạo tác phẩm cho tác giả là người thuộc tổ chức mình về nguyên tắc là chủ sở hữu các quyền tài sản và quyền công bố theo phạm vi luật định, trừ trường hợp có thỏa thuận khác. Vì vậy, chứng minh được việc “giao nhiệm vụ sáng tạo” là mắt xích rất quan trọng.

Freelancer cần ký tài liệu chuyển giao quyền sở hữu thế nào?

Với freelancer, hợp đồng nên nói rõ đối tượng được tạo ra, phạm vi công việc, sản phẩm bàn giao, quyền sở hữu trí tuệ, quyền sửa đổi – phát triển tiếp, nghĩa vụ cung cấp source và trách nhiệm đối với thành phần của bên thứ ba.

Không nên chỉ có biên nhận thanh toán hoặc tin nhắn “đã bàn giao code”. Nếu căn cứ sở hữu dựa vào hợp đồng sáng tạo hoặc chuyển giao quyền, hồ sơ pháp lý phải thể hiện được chính mối quan hệ đó. Hợp đồng chuyển nhượng quyền tác giả cũng phải được lập thành văn bản và xác định các nội dung chủ yếu theo luật.

Outsource một module bên ngoài làm phát sinh rủi ro gì?

Module outsource có thể tạo một “lỗ hổng quyền” bên trong sản phẩm tưởng như công ty sở hữu 100%. Rủi ro thường xuất hiện khi nhà thầu chỉ cấp quyền sử dụng nhưng không chuyển quyền sở hữu, sử dụng nhân sự phụ không rõ quyền hoặc đưa thư viện, template, code của bên thứ ba vào sản phẩm.

Doanh nghiệp nên lập danh sách module outsource và kiểm tra riêng từng hợp đồng. Với module quan trọng như thanh toán, recommendation engine, hệ thống CRM hoặc backend lõi, việc không xác định rõ quyền sở hữu có thể ảnh hưởng trực tiếp đến quá trình đăng ký, chuyển nhượng công nghệ hoặc gọi vốn.

Một repository phần mềm nên được “đóng gói pháp lý” trước ngày nộp hồ sơ

Repository phục vụ phát triển liên tục; hồ sơ bản quyền lại cần một đối tượng đủ rõ để xác định. Vì vậy, trước ngày nộp hồ sơ nên tạo một “legal snapshot” của phần mềm thay vì lấy ngẫu nhiên source đang nằm trên branch phát triển.

Chốt phiên bản source code nào để làm căn cứ đăng ký?

Có thể lựa chọn release đang thương mại hóa hoặc phiên bản ổn định gần nhất mà doanh nghiệp có thể xác định đầy đủ tác giả và quyền sở hữu. Nên ghi nhận version, ngày release, commit hash hoặc tag, thời điểm xuất source và người chịu trách nhiệm xác nhận.

Không nên tự động chọn bản mới nhất nếu bản đó đang chứa những module chưa hoàn thiện hoặc quyền sở hữu chưa được làm sạch. Một phiên bản cũ hơn nhưng rõ quyền đôi khi phù hợp hơn để đăng ký trước; các nâng cấp đáng kể có thể được đánh giá tiếp ở giai đoạn sau.

Nội dung cần in hoặc thể hiện trong bộ tài liệu tác phẩm nên chuẩn bị ra sao?

Quy định năm 2026 yêu cầu bản sao chương trình máy tính bao gồm bản điện tử chứa code, giao diện của chương trình có thể cài đặt để chạy và bản in A4 chứa giao diện cùng mã code. Nếu phần code in ra có từ 100 trang trở lên thì phần code được in 25 trang đầu, 25 trang giữa và 25 trang cuối. Với phần mềm trò chơi còn phải có kịch bản trò chơi.

Do đó, doanh nghiệp không nên tự áp dụng các hướng dẫn cũ được sao chép trên Internet mà cần chuẩn bị theo quy định hiện hành tại thời điểm nộp. File điện tử, bản in, tên chương trình, phiên bản và giao diện phải được rà soát như một bộ tài liệu thống nhất.

Thông tin phiên bản cần thống nhất giữa hồ sơ kỹ thuật và tờ khai thế nào?

Tên chương trình trên tờ khai phải thống nhất với tài liệu tác phẩm. Nếu doanh nghiệp muốn thể hiện version, cách ghi version cũng nên thống nhất tại các tài liệu liên quan, tránh chỗ ghi “GM ERP”, chỗ khác “Gia Minh ERP Pro” và source lại thể hiện “ERP Core 4”.

Ngày hoàn thành, tình trạng công bố và thông tin tác giả cũng phải được kiểm tra cùng một mốc phiên bản. Hồ sơ càng nhiều người tham gia thì việc lập một bảng master data trước khi điền biểu mẫu càng hữu ích.

Hồ sơ đăng ký bản quyền phần mềm tại Hà Nội theo mô hình 5 lớp

Thay vì nhìn hồ sơ như một danh sách giấy tờ rời rạc, có thể chia thành năm lớp. Cách này giúp doanh nghiệp dễ xác định lớp nào đã đủ và lớp nào đang thiếu chứng cứ.

Lớp 1 – tờ khai và thông tin chương trình máy tính

Năm 2026, chương trình máy tính sử dụng mẫu tờ khai tương ứng theo Thông tư 08/2026/TT-BVHTTDL. Tờ khai cần thống nhất các thông tin như tên chương trình, tác giả, chủ sở hữu, thời gian hoàn thành, tình trạng công bố và các thông tin khác theo biểu mẫu hiện hành.

Đây không phải bước “điền form trước rồi tìm giấy tờ sau”. Các dữ liệu trên tờ khai nên được chốt sau khi đã xác định tác giả, chủ sở hữu và phiên bản phần mềm.

Lớp 2 – bản sao tác phẩm và tài liệu mô tả

Đây là lớp giúp xác định phần mềm cụ thể nào đang được đăng ký. Đối với bản giấy, quy định về hồ sơ xác định hai bản sao tác phẩm; chương trình máy tính đồng thời phải đáp ứng yêu cầu riêng về bản điện tử, code, giao diện và bản in theo quy định hiện hành.

Doanh nghiệp nên kiểm tra các thành phần bí mật hoặc thông tin nội bộ trước khi đóng gói, nhưng không nên tùy tiện cắt bỏ đến mức tác phẩm đưa vào hồ sơ không còn khớp với đối tượng muốn đăng ký.

Lớp 3 – giấy tờ của tác giả, chủ sở hữu và tổ chức

Tùy chủ thể là cá nhân hay tổ chức, hồ sơ cần các tài liệu chứng minh nhân thân hoặc tư cách pháp lý theo trường hợp áp dụng. Quy định hiện hành cũng cho phép khai thác một số dữ liệu từ cơ sở dữ liệu nhà nước trong những trường hợp đáp ứng điều kiện.

Đối với doanh nghiệp tại Hà Nội, nên kiểm tra đặc biệt tên pháp lý, mã số doanh nghiệp và thông tin chủ sở hữu trên toàn bộ tài liệu để tránh việc dùng tên thương mại thay cho tên pháp nhân.

Lớp 4 – căn cứ giao nhiệm vụ, thuê sáng tạo hoặc chuyển giao

Nếu tác giả và chủ sở hữu không phải cùng một chủ thể, đây thường là lớp quan trọng nhất. Hồ sơ có thể cần quyết định hoặc xác nhận giao nhiệm vụ, hợp đồng sáng tạo, hợp đồng chuyển nhượng hoặc tài liệu khác tương ứng với căn cứ hình thành quyền.

Nghị định 134/2026/NĐ-CP đã quy định khá cụ thể các nhóm tài liệu chứng minh chủ sở hữu do giao nhiệm vụ, giao kết hợp đồng, thừa kế hoặc chuyển giao. Vì vậy, việc chuẩn hóa hồ sơ quyền sở hữu trước khi nộp có ý nghĩa lớn hơn việc chỉ chuẩn bị một bản source đẹp.

Lớp 5 – giấy ủy quyền và tài liệu bổ sung theo từng tình huống

Nếu đăng ký thông qua đại diện thì hồ sơ có văn bản ủy quyền theo quy định. Trường hợp cả bên ủy quyền và bên được ủy quyền đều là cá nhân, quy định hiện hành yêu cầu văn bản ủy quyền được công chứng hoặc chứng thực; các trường hợp khác phải thể hiện sự thống nhất ý chí của các bên.

Ngoài ra có thể phát sinh văn bản đồng ý của đồng tác giả, đồng chủ sở hữu hoặc tài liệu liên quan đến quyền của bên thứ ba. Vì vậy, không có một bộ hồ sơ “copy – paste” phù hợp cho mọi dự án phần mềm.

Phần mềm đang chạy SaaS có thể đăng ký mà không phải dừng phát triển

Một nền tảng SaaS có thể deploy nhiều lần mỗi tuần. Điều này không cản trở doanh nghiệp xác định một phiên bản cụ thể để đăng ký. Quyền tác giả cũng không chỉ phát sinh khi có giấy chứng nhận; việc đăng ký không phải điều kiện bắt buộc để quyền tác giả tồn tại.

Chọn mốc phiên bản nào khi sản phẩm cập nhật liên tục?

Doanh nghiệp có thể chọn một release đủ quan trọng, chẳng hạn phiên bản đang thương mại hóa, phiên bản trước vòng gọi vốn hoặc mốc hoàn thành một nhóm tính năng cốt lõi. Tại thời điểm đó nên tạo tag, xuất source, lưu release note và xác định người tham gia.

Cách làm này biến dòng phát triển liên tục thành các “mốc pháp lý”. Khi cần chứng minh lịch sử sản phẩm, doanh nghiệp có thể kết nối giấy chứng nhận với repository thay vì để hai hệ thống tồn tại độc lập.

Tính năng mới bổ sung sau đăng ký được xử lý ra sao?

Giấy chứng nhận của một phiên bản không khiến mọi nội dung được viết trong tương lai tự động trở thành chính tác phẩm đã đăng ký trước đó. Tuy nhiên, quyền tác giả đối với phần sáng tạo mới vẫn có thể phát sinh khi đáp ứng điều kiện pháp luật mà không phụ thuộc vào việc đã đăng ký hay chưa.

Doanh nghiệp nên đánh giá mức độ thay đổi. Một vài bug fix hoặc điều chỉnh nhỏ không nhất thiết dẫn đến chiến lược hồ sơ mới giống như trường hợp sản phẩm được bổ sung cả một module độc lập có giá trị lớn.

Khi thay đổi lớn về cấu trúc chương trình nên cân nhắc đăng ký phiên bản mới thế nào?

Nếu phần mềm thay đổi mạnh về kiến trúc, thay backend, phát triển lại engine chính hoặc bổ sung một hệ thống mới chiếm phần lớn giá trị sản phẩm, doanh nghiệp nên thực hiện một cuộc “IP review” để xác định có cần lập mốc đăng ký mới hay không.

Quyết định không nên dựa đơn thuần vào số version. Version 2.0 có thể chỉ đổi giao diện, trong khi version 1.8 lại thay toàn bộ thuật toán và kiến trúc. Cần nhìn vào mức độ sáng tạo mới và giá trị thương mại của phần thay đổi.

Case study – startup Hà Nội phát triển app 18 tháng bằng nhân viên và freelancer

Giả sử một startup tại Hà Nội phát triển ứng dụng trong 18 tháng. Hồ sơ Git ghi nhận 12 tài khoản từng commit; trong đó có 6 developer nhân viên, 3 freelancer, 1 CTO, 1 tester và 1 designer. Công ty chuẩn bị gọi vốn nên muốn đăng ký bản quyền phần mềm.

Vì sao danh sách 12 người tham gia chưa đồng nghĩa 12 người đều là tác giả?

Tester có thể chỉ kiểm thử, một số tài khoản có thể chỉ chỉnh cấu hình và designer có thể tạo một lớp tài sản khác. CTO có thể là tác giả nếu trực tiếp sáng tạo nhưng chức danh CTO không tự tạo tư cách tác giả.

Startup cần dựng contribution matrix để xác định ai trực tiếp tạo ra chương trình được đăng ký. Đây là cách tiếp cận phù hợp với nguyên tắc tác giả là người trực tiếp sáng tạo, thay vì coi mọi thành viên của project là đồng tác giả.

Thiếu hợp đồng chuyển giao của freelancer khiến hồ sơ vướng ở đâu?

Giả sử freelancer A viết module thanh toán và freelancer B xây engine thông báo nhưng hợp đồng chỉ ghi “thuê lập trình theo tháng”. Công ty có hóa đơn thanh toán nhưng không có điều khoản rõ về sản phẩm sáng tạo và quyền sở hữu.

Khi đó, câu hỏi không còn là “code có chạy không?” mà là “công ty dựa vào căn cứ nào để đứng tên chủ sở hữu?”. Startup có thể phải rà lại hợp đồng, biên bản giao việc, biên bản bàn giao và thỏa thuận về quyền trước khi hoàn thiện chuỗi hồ sơ.

Cách tái cấu trúc hồ sơ sở hữu trí tuệ trước vòng gọi vốn

Bước đầu tiên là lập IP register gồm phần mềm, module, giao diện, tên thương hiệu, domain, tài liệu kỹ thuật và dữ liệu quan trọng. Tiếp theo là map mỗi tài sản với tác giả, chủ sở hữu, hợp đồng và bằng chứng quá trình tạo ra.

Sau đó startup nên xử lý các khoảng trống: repository cá nhân, freelancer chưa bàn giao, license bên thứ ba chưa kiểm tra, nhân viên nghỉ việc còn quyền truy cập và module không có tài liệu giao nhiệm vụ. Khi giấy chứng nhận được đặt vào hệ thống hồ sơ này, giá trị pháp lý của nó sẽ rõ ràng hơn nhiều.

Nhà đầu tư hỏi “công ty có sở hữu code không?” – giấy chứng nhận chỉ là một phần câu trả lời

Giấy chứng nhận đăng ký quyền tác giả là chứng cứ pháp lý quan trọng. Theo Luật Sở hữu trí tuệ, chủ thể đã được cấp giấy chứng nhận về nguyên tắc không phải chứng minh quyền thuộc về mình khi có tranh chấp, trừ trường hợp có chứng cứ ngược lại.

Nhưng trong một thương vụ đầu tư, nhà đầu tư thường không dừng ở việc nhìn giấy chứng nhận. Họ còn muốn biết chuỗi hình thành quyền có sạch và có khả năng chuyển giao hay không.

Due diligence phần mềm thường nhìn thêm hợp đồng và lịch sử phát triển nào?

Nhà đầu tư có thể kiểm tra hợp đồng lao động, hợp đồng freelancer, hợp đồng outsource, văn bản chuyển giao quyền, lịch sử repository, license mã nguồn mở, thỏa thuận với đồng sáng lập và các hợp đồng đã cấp quyền sử dụng phần mềm cho khách hàng.

Mục tiêu là xác định công ty có thực sự kiểm soát tài sản đang tạo ra doanh thu hay không. Một giấy chứng nhận đẹp nhưng hợp đồng với nhà phát triển lõi lại chưa giải quyết quyền sở hữu có thể vẫn tạo ra vấn đề trong due diligence.

Source code trên tài khoản cá nhân của developer tạo rủi ro ra sao?

Rủi ro đầu tiên là kiểm soát. Nếu repository chính nằm trên tài khoản GitHub cá nhân của trưởng nhóm kỹ thuật, khi người đó nghỉ việc công ty có thể gặp khó khăn về truy cập, lịch sử phát triển hoặc bằng chứng điện tử.

Doanh nghiệp nên quản lý repository bằng tài khoản tổ chức, phân quyền theo vai trò, bật xác thực nhiều lớp, định kỳ sao lưu và quy định rõ quyền sở hữu dữ liệu kỹ thuật. Đây vừa là quản trị an toàn thông tin, vừa hỗ trợ xây dựng chứng cứ sở hữu trí tuệ.

Doanh nghiệp nên xây kho tài liệu IP ngay từ giai đoạn đầu như thế nào?

Kho IP có thể tổ chức theo từng tài sản. Mỗi phần mềm nên có thư mục pháp lý, phiên bản, tác giả, hợp đồng, quyết định giao việc, biên bản bàn giao, release note, giấy chứng nhận và tài liệu license.

Việc này không cần đợi công ty có hàng trăm nhân sự. Một startup năm người nếu thiết lập ngay từ đầu sẽ tiết kiệm rất nhiều thời gian khi gọi vốn, chuyển nhượng công nghệ hoặc xử lý tranh chấp.

Đăng ký bản quyền phần mềm khác gì đăng ký sáng chế cho giải pháp công nghệ?

Hai cơ chế không nên bị đánh đồng. Đăng ký quyền tác giả đối với chương trình máy tính tập trung vào tác phẩm và hình thức thể hiện, trong khi sáng chế là cơ chế bảo hộ giải pháp kỹ thuật đáp ứng các điều kiện tương ứng.

Bản quyền tập trung vào hình thức thể hiện của chương trình ra sao?

Đối với chương trình máy tính, Luật Sở hữu trí tuệ ghi nhận bảo hộ dù chương trình được thể hiện dưới dạng mã nguồn hay mã máy. Do đó, một người khác không mặc nhiên bị cấm phát triển mọi phần mềm có cùng mục tiêu kinh doanh chỉ vì doanh nghiệp đã đăng ký source của mình.

Đây là điểm rất quan trọng đối với app đặt lịch, CRM, ERP, marketplace hoặc SaaS. Chức năng tương tự không đồng nghĩa đương nhiên với sao chép tác phẩm; khi xảy ra tranh chấp phải đánh giá đối tượng và hành vi cụ thể.

Giải pháp kỹ thuật có thể cần đánh giá bằng cơ chế bảo hộ khác thế nào?

Luật Việt Nam liệt kê “chương trình máy tính” trong nhóm đối tượng không được bảo hộ với danh nghĩa sáng chế. Tuy vậy, với một sản phẩm công nghệ có giải pháp kỹ thuật thực sự, doanh nghiệp nên đánh giá bản chất của giải pháp thay vì chỉ gọi toàn bộ đối tượng là “phần mềm”. Cục Sở hữu trí tuệ định nghĩa sáng chế là giải pháp kỹ thuật dưới dạng sản phẩm hoặc quy trình nhằm giải quyết một vấn đề bằng việc ứng dụng các quy luật tự nhiên.

Vì vậy, nếu sản phẩm liên quan đến thiết bị, quy trình kỹ thuật, IoT, điều khiển, xử lý tín hiệu hoặc giải pháp công nghệ phức tạp, nên thực hiện đánh giá riêng về khả năng bảo hộ sáng chế thay vì mặc định hồ sơ bản quyền phần mềm đã giải quyết mọi vấn đề.

Trường hợp nào doanh nghiệp công nghệ nên xây chiến lược bảo hộ nhiều lớp?

Một sản phẩm có thể có code cần bảo hộ quyền tác giả, tên và logo cần chiến lược nhãn hiệu, thiết kế giao diện cần đánh giá riêng, bí mật thuật toán cần cơ chế bảo mật và một giải pháp kỹ thuật có thể cần xem xét khả năng bảo hộ sở hữu công nghiệp.

Chiến lược nhiều lớp đặc biệt cần thiết đối với startup chuẩn bị gọi vốn, nền tảng có giá trị công nghệ lớn, doanh nghiệp nhượng quyền phần mềm hoặc công ty dự kiến mở rộng ra nước ngoài.

12 lỗi thường gặp trong hồ sơ bản quyền phần mềm

Nhiều hồ sơ không vướng vì phần mềm “không đủ hay” mà vì dữ liệu pháp lý của sản phẩm không nhất quán. Mười hai lỗi dưới đây thường tập trung vào ba nhóm: nhận diện tác phẩm, xác định chủ thể và lựa chọn phiên bản.

Tên chương trình không thống nhất giữa tờ khai và tài liệu tác phẩm

Bốn lỗi đầu tiên thường là: (1) tên trên tờ khai khác tên trên giao diện; (2) tài liệu dùng cả tên thương mại và tên nội bộ mà không giải thích; (3) version xuất hiện không thống nhất; (4) ngày hoàn thành hoặc ngày công bố không khớp với lịch sử phát triển.

Cách xử lý là tạo một bảng dữ liệu chuẩn trước khi hoàn thiện hồ sơ. Chỉ một người chịu trách nhiệm kiểm soát tên tác phẩm, phiên bản, ngày hoàn thành, tác giả và chủ sở hữu trên toàn bộ bộ tài liệu.

Không chứng minh được quan hệ giữa công ty và nhóm phát triển

Bốn lỗi tiếp theo gồm: (5) chỉ có hợp đồng lao động chung chung; (6) freelancer không có hợp đồng rõ về quyền; (7) outsource qua nhiều tầng nhưng không kiểm soát nhà thầu phụ; (8) kê khai giám đốc hoặc CTO làm tác giả chỉ vì chức danh.

Các lỗi này đều liên quan đến chuỗi quyền sở hữu. Trong khi đó, quy định hiện hành yêu cầu tài liệu chứng minh quyền do giao nhiệm vụ, giao kết hợp đồng hoặc được chuyển giao tương ứng với từng trường hợp.

Dùng bản source quá cũ so với phiên bản sản phẩm đang thương mại hóa

Bốn lỗi cuối gồm: (9) đăng ký bản đã ngừng sử dụng nhiều năm; (10) không lưu được bản source đúng với hồ sơ đã nộp; (11) trộn code từ nhiều version vào một bộ tài liệu; (12) đăng ký xong nhưng không lưu tag, release hoặc snapshot để xác định đối tượng sau này.

Không phải bản cũ luôn vô giá trị. Vấn đề nằm ở việc doanh nghiệp không giải thích được mối quan hệ giữa bản đã đăng ký và sản phẩm đang kinh doanh. Một hệ thống quản lý version tốt sẽ giải quyết phần lớn rủi ro này.

Thời gian đăng ký phần mềm tại Hà Nội nên tính từ lúc “gom hồ sơ”, không chỉ ngày nộp

Một doanh nghiệp hỏi “đăng ký mất bao lâu?” thường chỉ tính thời gian cơ quan nhà nước xử lý. Nhưng với dự án công nghệ phức tạp, phần tốn thời gian nhất đôi khi lại diễn ra trước ngày nộp.

Theo quy định được sửa đổi năm 2026, cơ quan có thẩm quyền thực hiện rà soát, phân loại và xem xét tính hợp lệ đối với hồ sơ đề nghị cấp giấy chứng nhận trong thời hạn 22 ngày làm việc kể từ ngày nhận hồ sơ. Do đó không nên tiếp tục sử dụng máy móc các bài hướng dẫn cũ nói về mốc xử lý trước khi pháp luật năm 2026 thay đổi.

Khâu xác định tác giả thường mất thời gian hơn dự kiến thế nào?

Một app phát triển ba năm có thể đã trải qua bốn CTO, hàng chục developer và nhiều đợt outsource. Đến khi đăng ký, công ty mới bắt đầu hỏi ai thực sự viết phiên bản hiện tại thì việc xác minh có thể kéo dài.

Giải pháp tốt nhất là xác định tác giả theo từng release ngay trong quá trình phát triển. Khi nhân sự nghỉ việc, hồ sơ contribution vẫn được lưu lại thay vì phụ thuộc vào trí nhớ của người quản lý.

Khâu rà soát hợp đồng outsource có thể làm chậm timeline ra sao?

Hợp đồng outsource thường được phòng mua hàng hoặc vận hành ký vì mục tiêu triển khai dự án, không phải vì mục tiêu đăng ký quyền tác giả. Do đó có thể thiếu điều khoản về source, quyền chỉnh sửa, quyền chuyển giao hoặc nhà thầu phụ.

Nếu phát hiện vấn đề một tuần trước ngày dự kiến nộp hồ sơ, doanh nghiệp có thể phải quay lại đàm phán với đối tác. Đây là lý do nên review IP ngay từ giai đoạn ký hợp đồng thay vì đợi tới ngày đăng ký.

Doanh nghiệp chuẩn bị trước dữ liệu gì để hạn chế sửa đổi?

Nên chuẩn bị một bảng dữ liệu gồm tên chương trình, version, ngày hoàn thành, ngày công bố nếu có, tác giả, chủ sở hữu, căn cứ sở hữu, repository, release tương ứng và danh sách tài liệu chứng minh.

Sau khi bảng này được khóa, mới tiến hành điền tờ khai và đóng gói tác phẩm. Trình tự đó giúp hạn chế trường hợp sửa một thông tin ở năm tài liệu khác nhau.

Chi phí đăng ký bản quyền phần mềm nên được đọc theo độ phức tạp của quyền sở hữu

Chi phí thực tế của một dự án đăng ký không chỉ nằm ở khoản phí, lệ phí nhà nước. Phần đáng kể có thể nằm ở thời gian rà soát quyền sở hữu, chỉnh hợp đồng, xác định tác giả và chuẩn hóa hàng nghìn trang dữ liệu kỹ thuật.

Hồ sơ một tác giả – một chủ sở hữu khác gì dự án nhiều bên?

Một lập trình viên tự viết chương trình và tự đứng tên thường có cấu trúc quyền đơn giản hơn dự án do công ty phát triển với 15 developer, 2 freelancer và 3 nhà thầu ngoài.

Càng nhiều chủ thể, càng phải kiểm tra nhiều mối quan hệ quyền. Vì vậy, khi so sánh chi phí dịch vụ đăng ký bản quyền phần mềm tại Hà Nội, doanh nghiệp nên so sánh phạm vi công việc chứ không chỉ so một con số cuối cùng.

Chi phí xử lý tài liệu chuyển giao nên dự tính từ đầu ra sao?

Nếu hồ sơ đang thiếu hợp đồng chuyển giao, chi phí xử lý không chỉ là việc soạn thêm một văn bản. Có thể phải rà lại lịch sử dự án, xác định chính xác đối tượng chuyển giao, liên hệ tác giả cũ và đàm phán điều khoản.

Đối với startup có kế hoạch gọi vốn, việc dành ngân sách cho “IP clean-up” trước due diligence thường hiệu quả hơn việc xử lý từng vấn đề sau khi nhà đầu tư phát hiện.

Khi nào dịch vụ trọn gói có lợi hơn việc tự chuẩn bị hồ sơ?

Dịch vụ trọn gói có giá trị nhất khi hồ sơ có nhiều tác giả, freelancer, outsource, nhiều phiên bản hoặc quyền sở hữu chưa rõ. Khi đó phần công việc quan trọng không nằm ở việc điền tờ khai mà ở việc cấu trúc lại bằng chứng.

Ngược lại, dự án đơn giản, một tác giả và quyền sở hữu rõ ràng có thể tự chuẩn bị dễ hơn. Doanh nghiệp nên lựa chọn theo độ phức tạp của tài sản thay vì mặc định mọi hồ sơ phần mềm đều giống nhau.

Sau đăng ký – quản lý phiên bản phần mềm để giấy chứng nhận không trở thành hồ sơ “đóng tủ”

Đăng ký chỉ là một mốc trong vòng đời tài sản trí tuệ. Nếu giấy chứng nhận nằm trong tủ còn source tiếp tục thay đổi mà không có hệ thống lưu dấu, sau vài năm khoảng cách giữa “tài sản pháp lý” và “sản phẩm thực tế” sẽ ngày càng lớn.

Git, nhật ký cập nhật và tài liệu release hỗ trợ chứng minh quá trình phát triển thế nào?

Git có thể lưu lại tác giả commit, thời gian, branch và lịch sử thay đổi. Release note cho biết tính năng nào được thêm ở phiên bản nào. Ticket và tài liệu sprint lại giúp giải thích bối cảnh phát triển.

Các nguồn dữ liệu này nên được quản trị như chứng cứ kinh doanh quan trọng. Không phải mọi commit đều tự động chứng minh quyền tác giả, nhưng tổng hợp nhiều nguồn bằng chứng có thể hỗ trợ tái dựng lịch sử sáng tạo khi xảy ra tranh chấp.

Module mới nên được phân loại và lưu bằng chứng sáng tạo ra sao?

Khi thêm một module lớn, doanh nghiệp nên ghi nhận ai phát triển, theo quyết định hoặc hợp đồng nào, source nằm ở repository nào và release nào đưa module vào production.

Nếu module được mua hoặc outsource, tài liệu quyền sở hữu nên nằm cùng hồ sơ kỹ thuật. Khi đó mỗi tài sản có một “legal trail” có thể truy ngược thay vì chỉ còn code.

Khi xảy ra tranh chấp cần bảo toàn chứng cứ điện tử như thế nào?

Không nên vội xóa tài khoản của người đã nghỉ việc trước khi sao lưu dữ liệu cần thiết. Repository, email công việc, ticket, tài liệu thiết kế, log hệ thống, release, biên bản bàn giao và hợp đồng có thể trở thành nguồn chứng cứ quan trọng.

Doanh nghiệp cũng cần bảo toàn tính toàn vẹn của dữ liệu, phân quyền truy cập và ghi nhận quá trình sao lưu. Với tranh chấp lớn, việc thu thập và bảo toàn chứng cứ nên được thực hiện theo chiến lược pháp lý cụ thể thay vì tự ý chỉnh sửa dữ liệu gốc.

Checklist 20 điểm trước khi nộp đăng ký bản quyền phần mềm tại Hà Nội

Trước khi nộp, doanh nghiệp có thể thực hiện kiểm tra 20 điểm theo ba lớp: con người, tác phẩm và quyền sở hữu. Nếu một điểm quan trọng chưa có câu trả lời rõ, nên xử lý trước thay vì hy vọng giải trình sau.

Kiểm tra tác giả, developer, freelancer và nhà thầu outsource

Điểm 1: xác định người trực tiếp sáng tạo. Điểm 2: phân biệt tác giả với người hỗ trợ. Điểm 3: kiểm tra đồng tác giả. Điểm 4: kiểm tra developer đã nghỉ việc. Điểm 5: kiểm tra freelancer. Điểm 6: kiểm tra nhà thầu outsource. Điểm 7: kiểm tra nhà thầu phụ nếu có.

Kết quả cuối cùng phải trả lời được ba câu hỏi cho từng người: họ tạo ra phần nào, vào thời điểm nào và quyền đối với kết quả đó hiện thuộc về ai.

Kiểm tra phiên bản source code và thông tin tác phẩm

Điểm 8: khóa version. Điểm 9: lưu commit hoặc tag. Điểm 10: thống nhất tên chương trình. Điểm 11: xác định ngày hoàn thành. Điểm 12: xác định tình trạng công bố. Điểm 13: kiểm tra giao diện. Điểm 14: chuẩn bị bản điện tử. Điểm 15: chuẩn bị bản in code và giao diện theo yêu cầu hiện hành.

Sau khi khóa tám điểm này, không nên tiếp tục sửa source nằm trong bộ hồ sơ. Nếu development vẫn chạy, hãy tách snapshot pháp lý khỏi branch đang phát triển.

Kiểm tra quyền sở hữu trước khi gọi vốn, chuyển nhượng hoặc cấp phép phần mềm

Điểm 16: kiểm tra quyết định giao nhiệm vụ. Điểm 17: kiểm tra hợp đồng lao động và hợp đồng sáng tạo. Điểm 18: kiểm tra hợp đồng chuyển giao quyền. Điểm 19: kiểm tra code, thư viện và tài sản của bên thứ ba. Điểm 20: lưu toàn bộ hồ sơ vào kho IP nội bộ.

Một bộ hồ sơ đăng ký bản quyền phần mềm tại Hà Nội tốt không chỉ nhằm lấy giấy chứng nhận. Mục tiêu lớn hơn là tạo được một chuỗi chứng cứ cho thấy rõ ai sáng tạo – công ty sở hữu bằng căn cứ nào – phiên bản nào được đăng ký – phần mềm đã thay đổi ra sao sau đăng ký. Khi bốn câu hỏi này luôn có câu trả lời, tài sản phần mềm mới thực sự sẵn sàng cho thương mại hóa, gọi vốn, cấp phép hoặc chuyển nhượng.

Đăng ký bản quyền phần mềm tại Hà Nội là giải pháp cần thiết đối với doanh nghiệp công nghệ, startup và cá nhân phát triển phần mềm muốn bảo vệ giá trị sản phẩm lâu dài. Chuẩn bị đúng tài liệu từ giai đoạn đầu sẽ giúp thủ tục thuận lợi và tạo nền tảng cho hoạt động khai thác, chuyển giao hoặc xử lý tranh chấp sau này.