OpenSign cho văn phòng luật: ký điện tử tự lưu trữ và giới hạn cần biết
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
OpenSign trong văn phòng luật: thay lượt in, ký, quét bằng một liên kết ký, nhưng đừng vội tin vào hiệu lực pháp lý
OpenSign là phần mềm ký tài liệu PDF điện tử mã nguồn mở, tự giới thiệu là lựa chọn thay thế miễn phí cho DocuSign [1]. Người dùng tải PDF lên, đặt vị trí ký, mời người ký qua email hoặc liên kết, rồi nhận bản đã ký kèm chứng nhận hoàn tất [1]. Bài này đặt câu hỏi hẹp: một văn phòng luật ở Việt Nam có nên thử nó cho hợp đồng dịch vụ, giấy ủy quyền và biên bản nội bộ không.
Câu trả lời thận trọng là có, nhưng chỉ cho tài liệu có rủi ro thấp và sau khi luật sư phụ trách đánh giá giá trị pháp lý. Nguồn tôi đọc mô tả tính năng kỹ thuật như nhiều người ký, mã OTP qua email, thời hạn hiệu lực và nhật ký hoạt động [1], nhưng không nói gì về việc chữ ký tạo ra có được chấp nhận theo pháp luật Việt Nam hay không. Đó là câu hỏi pháp lý, không phải kỹ thuật.
Không nên dùng khi văn bản bắt buộc có chữ ký số theo chuẩn riêng, cần công chứng, chứng thực, hoặc khi văn phòng không có người đủ năng lực vận hành máy chủ. Giấy phép AGPL-3 cũng đòi hỏi cân nhắc nếu văn phòng muốn sửa mã và cung cấp dịch vụ cho người khác [2].
Vòng lặp in, ký tay, chụp ảnh gửi lại làm chậm hồ sơ vụ việc
Trong một văn phòng luật nhỏ, chữ ký thường là khâu nghẽn thầm lặng. Khách hàng ở tỉnh khác phải in bản hợp đồng dịch vụ, ký, chụp bằng điện thoại và gửi qua ứng dụng chat; luật sư phải kiểm tra từng ảnh có đủ trang, có ký đúng chỗ không, rồi in lại để lưu hồ sơ. Mỗi vòng như vậy tốn vài ngày và để lại nhiều bản không đồng nhất.
Phần mềm ký điện tử xử lý một phần vấn đề này: một tài liệu gốc, một danh sách người ký, một thứ tự ký và một bản lưu cuối. OpenSign mô tả mô hình đó qua hỗ trợ nhiều người ký, mời bằng liên kết và ép ký theo thứ tự [1]. Nhưng nó chỉ giải quyết phần quy trình, không giải quyết câu hỏi tài liệu nào được phép ký điện tử.
Vì vậy bài toán thực sự có hai lớp. Lớp kỹ thuật là biến vòng lặp thủ công thành luồng có dấu vết. Lớp nghề nghiệp là xác định loại văn bản nào văn phòng chấp nhận ký bằng phương thức này, người nào chịu trách nhiệm kiểm tra danh tính người ký, và bản nào được coi là bản gốc lưu hồ sơ. Lớp thứ hai không do phần mềm quyết định.
Ba khối của OpenSign: giao diện React, máy chủ ứng dụng và MongoDB
Các nguồn cho thấy OpenSign gồm ít nhất một ứng dụng giao diện web viết bằng React, nằm trong thư mục apps/OpenSign, với lệnh npm start để chạy chế độ phát triển và npm run build để đóng gói bản sản xuất [5]. Cấu trúc kho còn có thư mục apps/OpenSignServer, nhưng tôi chỉ thấy tên thư mục trong danh sách tệp tài liệu và các tệp mẫu email, chưa đọc mã máy chủ, nên không mô tả chi tiết bên trong.
Về lưu trữ, README ghi rõ cơ sở dữ liệu MongoDB: bản triển khai mặc định dùng một MongoDB không bền vững, bị xóa sau mỗi lần khởi động lại, nên muốn giữ dữ liệu phải cung cấp chuỗi kết nối MongoDB riêng [1]. Đây là chi tiết vận hành quan trọng hơn mọi mô tả kiến trúc: ai chạy lệnh Docker mẫu mà quên cấu hình MongoDB riêng sẽ mất toàn bộ tài liệu đã ký khi container khởi động lại.
Lệnh Docker trong README tải ba tệp là docker-compose.yml, Caddyfile và .env.local_dev rồi đổi tên thành .env.prod, với biến HOST_URL là địa chỉ công khai [1]. Sự có mặt của Caddyfile gợi ý một máy chủ web đứng trước để lo HTTPS, nhưng bài không đọc nội dung các tệp đó nên chỉ nêu như suy luận.
Đường đi của một hợp đồng dịch vụ: từ PDF gốc đến chứng nhận hoàn tất
Giả sử luật sư tải lên hợp đồng PDF. README mô tả hai cách khởi đầu là tự ký hoặc yêu cầu người khác ký, cùng khả năng dựng mẫu (template) để dùng lại nhiều lần [1]. Với mẫu hợp đồng dịch vụ pháp lý, vị trí ô chữ ký, ngày ký và họ tên được đặt một lần, sau đó mỗi khách hàng mới chỉ cần điền thông tin.
Khi gửi, hệ thống gửi thư mời hoặc liên kết ký. Người ký khách không có tài khoản vẫn ký được nhưng phải nhập mã duy nhất gửi tới email trước [1]. Người ký có thể vẽ chữ ký, tải ảnh, gõ chữ hoặc dùng chữ ký đã lưu; họ cũng có thể từ chối ký kèm lý do được báo cho người gửi, và tài liệu có thể được đặt hết hạn sau số ngày nhất định [1].
Khi mọi bên hoàn tất, README nói hệ thống sinh chứng nhận hoàn tất chứa nhật ký hoạt động có dấu thời gian, địa chỉ IP, email và số điện thoại [1]. Bản đã ký và chứng nhận nên được lưu vào kho hồ sơ vụ việc của văn phòng. Nguồn không nói chữ ký có được niêm phong bằng chứng thư số hay không, nên không được hiểu chứng nhận này là chữ ký số theo nghĩa pháp lý.
Danh mục tính năng được README xác nhận, tách khỏi phần quảng bá
Danh mục trong README gồm: ký PDF, bảng ký cho phép vẽ tay, tải ảnh, gõ hoặc dùng chữ ký lưu sẵn, các chức năng ký cho chính mình, mẫu, ký một chạm và OpenSign Drive, nhiều người ký có thể mời bằng liên kết và ép thứ tự, xác thực OTP qua email cho khách ký, hết hạn và từ chối, mẫu email tùy biến, nhật ký kiểm tra cùng chứng nhận hoàn tất, API với khóa tạo trong ứng dụng, và tích hợp lưu trữ đám mây, CRM, Zapier [1].
Cần phân biệt tuyên bố tiếp thị với tính năng có thể kiểm chứng. Những cụm như mã hóa mạnh, trải nghiệm ký tốt nhất hệ sinh thái mã nguồn mở, hay hơn nhiều đối thủ lâu năm là cách nói của chủ dự án [1]; bài không dùng chúng làm bằng chứng. Phần mô tả quy trình ký, OTP, hết hạn và nhật ký đáng tin hơn vì có thể thử và đối chiếu khi triển khai.
Một điểm nữa: README nhắc đến phiên bản đám mây miễn phí cho phép ký không giới hạn tài liệu [1]. Đó là dịch vụ do chủ dự án vận hành, khác với bản tự lưu trữ. Các nguồn tôi đọc không có bảng so sánh tính năng giữa bản đám mây và bản tự lưu trữ, vì vậy chưa thể khẳng định mọi tính năng ở trên có mặt như nhau ở cả hai.
Văn phòng luật nhỏ có người lo công nghệ, và các nghề cần chữ ký từ xa
Đối tượng phù hợp nhất là văn phòng luật hoặc công ty tư vấn từ năm đến ba mươi người, có khách hàng ở xa và ít nhất một người chịu trách nhiệm công nghệ. Họ cần cải thiện quy trình ký cho tài liệu như hợp đồng dịch vụ, thỏa thuận bảo mật, giấy xác nhận nội bộ. Tính năng mẫu và API giúp quy trình lặp lại, còn việc tự lưu trữ cho phép giữ hồ sơ trên hạ tầng do văn phòng kiểm soát [1].
Các nghề tương tự như kế toán thuế, bất động sản hay nhân sự có thể dùng cùng cơ chế, nhưng mỗi nghề có loại văn bản và yêu cầu pháp lý riêng. Bài này không mở rộng sang họ vì không có nguồn kỹ thuật nào trả lời thay cho quy định ngành.
Nhóm không nên dùng gồm văn phòng không có ai quản trị máy chủ, nơi cần chữ ký số có chứng thư từ tổ chức được cấp phép, và tổ chức không chấp nhận AGPL. Nếu chỉ muốn dùng thử, phiên bản đám mây của chủ dự án là đường vào dễ hơn, nhưng khi đó tài liệu khách hàng nằm ở dịch vụ bên ngoài và cần cân nhắc nghĩa vụ bảo mật nghề nghiệp [1].
Tình huống giả định: văn phòng luật ở Hà Nội ký thư thỏa thuận dịch vụ với khách ở nhiều tỉnh
Đây là kịch bản đề xuất, không phải trường hợp có thật. Một văn phòng luật tám người ở Hà Nội thường nhận tư vấn doanh nghiệp từ khách ở Đà Nẵng, Cần Thơ, Hải Phòng. Mỗi vụ việc mới bắt đầu bằng một thư thỏa thuận dịch vụ và một bản cam kết bảo mật. Hiện việc ký diễn ra qua chuyển phát nhanh hoặc ảnh chụp, tốn trung bình vài ngày chưa được đo.
Đề xuất: văn phòng chạy OpenSign trên một máy chủ riêng ở Việt Nam, đặt tên miền riêng, và chỉ dùng cho hai loại tài liệu ban đầu là thư thỏa thuận và cam kết bảo mật. Hai mẫu được dựng sẵn; khách ký với mã OTP gửi qua email [1]. Bản hoàn tất cùng chứng nhận được xuất và nộp vào hồ sơ vụ việc, bản giấy chỉ in khi khách hoặc cơ quan yêu cầu.
Điều kiện đi kèm: luật sư điều hành phải xác nhận bằng văn bản loại ký điện tử này có đủ giá trị cho từng loại tài liệu và chấp nhận rủi ro còn lại. Văn bản có chữ ký cần giá trị cao hơn vẫn đi qua kênh hiện có. Bài này không đánh giá luật Việt Nam và các nguồn kỹ thuật không bàn đến việc đó. Nếu người ký là cá nhân có thể bị mạo danh email, cần thêm cách xác minh danh tính ngoài OTP, chẳng hạn gọi điện xác nhận.
Dựng bằng Docker, giữ MongoDB bền vững và đừng chạy bản mẫu như bản thật
Cách cài tự lưu trữ chính thức trong README là các lệnh Docker tải ba tệp cấu hình rồi chạy docker compose up với HOST_URL do người dùng đặt; cũng có nút triển khai lên DigitalOcean [1]. Bước đáng nhấn mạnh nhất là ghi chú về MongoDB: bản mặc định không bền vững, dữ liệu mất mỗi lần khởi động lại, nên môi trường thật phải trỏ tới MongoDB do văn phòng quản lý [1].
Tệp INSTALLATION.md tại commit đã ghim cho biết hướng dẫn cài đặt đã chuyển sang cổng tài liệu riêng của dự án và tách thành phần dành cho quản trị hệ thống với phần dành cho người đóng góp [3]. Tệp USAGE.md chỉ chuyển người đọc tới tài liệu chính thức [4]. Vì vậy chi tiết như cấu hình email gửi đi, lưu trữ tệp, sao lưu hay nâng cấp phiên bản chưa được kiểm chứng trong bài này.
Đề xuất vận hành: dùng môi trường thử riêng, đặt sau HTTPS, sao lưu MongoDB và tệp PDF theo lịch, kiểm tra khôi phục mỗi quý, và ghi lại phiên bản đang chạy. Với văn phòng luật, thời gian lưu hồ sơ thường dài; kế hoạch dữ liệu cần xét cả trường hợp OpenSign ngừng phát triển, nghĩa là bản đã ký phải đọc được bằng trình xem PDF thông thường.
OTP email, nhật ký và những điều README chưa chứng minh
README nêu một số cơ chế bảo vệ cụ thể: khách ký phải nhập mã duy nhất gửi tới email, tài liệu có thể hết hạn, và nhật ký ghi lại hoạt động kèm dấu thời gian, địa chỉ IP, email và số điện thoại [1]. Với văn phòng luật, nhật ký là bằng chứng quy trình hữu ích khi có tranh chấp rằng người ký đã mở và ký tài liệu. Tuy vậy, mã OTP chỉ chứng minh người ký kiểm soát hộp thư, không chứng minh họ đúng là người được giao ký.
Dữ liệu trong hệ thống rất nhạy cảm: hợp đồng, thông tin cá nhân khách hàng, đôi khi chi tiết vụ việc. Việc tự lưu trữ đưa trách nhiệm bảo vệ về phía văn phòng gồm vá lỗi, mã hóa ổ đĩa, kiểm soát truy cập máy chủ và quản lý khóa API. README nhắc API key có thể tạo trong ứng dụng [1]; khóa nên được coi như mật khẩu và thu hồi khi nhân sự rời đi.
Các nguồn đã đọc không có chính sách báo cáo lỗ hổng, chứng nhận kiểm toán độc lập hay mô tả mã hóa tài liệu ở trạng thái lưu. Cụm secure PDF e-signing với thuật toán mã hóa mạnh trong README là lời giới thiệu [1], chưa phải đặc tả để dựa vào. Trước khi dùng cho hồ sơ thật, nên nhờ chuyên gia an ninh rà soát cấu hình thực tế.
AGPL-3 ở phần lớn kho, thêm ngoại lệ cho thư mục customRoute
Tệp LICENSE ở commit đã ghim mở đầu bằng ba quy tắc. Nội dung nằm trong thư mục apps/OpenSignServer/cloud/customRoute, nếu thư mục ấy tồn tại, theo giấy phép riêng của thư mục đó; các thành phần bên thứ ba giữ giấy phép gốc; phần còn lại thuộc GNU Affero General Public License phiên bản 3 [2]. README và CONTRIBUTING cũng nói dự án theo AGPL-3, và đóng góp được cấp phép theo AGPL-V3 [1][6].
Bước kiểm tra phạm vi giấy phép khi thu thập đã thử đọc tệp LICENSE bên trong customRoute tại commit này và nhận lỗi không tìm thấy. Vì vậy tôi không biết thư mục đó có tồn tại không, và nếu có thì điều khoản là gì. Đây là điểm chưa xác minh, và ai muốn phân phối lại hay tích hợp sâu nên kiểm tra trực tiếp trong bản mã thực tế.
Điều khoản AGPL quan trọng cho dịch vụ mạng là mục 13: nếu bạn sửa chương trình, bản đã sửa phải cung cấp cho mọi người dùng tương tác từ xa cơ hội nhận mã nguồn tương ứng của bản đó [2]. Văn phòng chỉ dùng nội bộ không sửa mã thường ít bị ảnh hưởng; nếu tùy biến rồi mở cho khách hàng ký thì nên xin ý kiến pháp lý. Giấy phép không bao phủ dữ liệu, mô hình, dịch vụ đám mây của chủ dự án hay nhãn hiệu OpenSign; tôi không thấy chính sách nhãn hiệu trong nguồn đã đọc.
Chi phí: hạ tầng nhỏ, công vận hành và trách nhiệm pháp lý là phần lớn
Chi phí cấp phép bằng không, nhưng cần liệt kê các loại nguồn lực. Hạ tầng gồm một máy chủ hoặc máy ảo chạy Docker, cơ sở dữ liệu MongoDB, dung lượng lưu PDF và bản sao lưu, tên miền và chứng chỉ HTTPS. Gửi email mời ký cần dịch vụ email hoạt động tốt; nguồn đã đọc không cho biết cấu hình mặc định, nên khoản này cần xác định khi triển khai.
Về người, cần một quản trị viên có kinh nghiệm Docker và cơ sở dữ liệu, một luật sư giữ vai trò chủ quy trình, và thời gian đào tạo nhân viên. Giả định cho dự toán: một đến hai ngày công cài đặt thử, vài giờ mỗi tháng cho vá lỗi và sao lưu. Đây là giả định lập kế hoạch, không phải số đo.
Chi phí bị đánh giá thấp nhất thường là rà soát pháp lý và xử lý sự cố: nếu một chữ ký bị phản đối, chi phí có thể lớn hơn nhiều so với tiền máy chủ. Nếu chọn bản đám mây của chủ dự án, README nói có phiên bản miễn phí [1], nhưng tôi không có thông tin về gói trả phí hay điều khoản, nên không so sánh được giá.
Ký điện tử tự lưu trữ so với dịch vụ SaaS, chữ ký số có chứng thư và quy trình giấy
So với dịch vụ ký điện tử thương mại như DocuSign, README đặt OpenSign vào vị trí thay thế mã nguồn mở [1]. Khác biệt cốt lõi ở mô hình vận hành: SaaS giao việc hạ tầng và bảo mật cho nhà cung cấp, còn tự lưu trữ đưa dữ liệu về văn phòng nhưng cũng đưa trách nhiệm đi cùng. Bài không so sánh giá hay tính năng cụ thể vì không có nguồn đã đọc cho các dịch vụ đó.
Chữ ký số có chứng thư do tổ chức cung cấp là một loại phương án khác về cơ chế bảo đảm danh tính. Những gì README mô tả là bảng ký, OTP email và nhật ký [1], và chưa thấy nói đến chứng thư số. Nếu hợp đồng cần mức bảo đảm này, ký điện tử kiểu OpenSign có thể không đủ.
Quy trình giấy vẫn là phương án nền để đối chiếu. Nó chậm nhưng quen thuộc với tòa án, cơ quan nhà nước và khách hàng lớn tuổi. Gợi ý lựa chọn theo tiêu chí: giá trị pháp lý cần có, độ nhạy cảm của tài liệu, năng lực vận hành nội bộ và khả năng chấp nhận AGPL.
Khi nào nên dừng trước khi bắt đầu
Giới hạn đáng kể nhất là nguồn thông tin. README có tính quảng bá, INSTALLATION và USAGE chỉ trỏ sang tài liệu ngoài [1][3][4], còn mã máy chủ chưa được đọc. Mọi nhận xét về hành vi thực tế của phần mềm, như cách lưu tệp hay độ bền của nhật ký, đều cần thử nghiệm.
Giới hạn thứ hai là chuyện pháp lý. Phần mềm không tự bảo đảm một chữ ký có thể dùng để chứng minh trước tòa hay cơ quan nhà nước ở Việt Nam. Văn phòng nên coi chức năng này như công cụ quy trình và ghi nhận, chờ luật sư kết luận cho từng loại văn bản.
Giới hạn thứ ba là vận hành: README cảnh báo dữ liệu mặc định mất khi khởi động lại [1], và dự án nhận đóng góp cộng đồng theo quy trình duyệt của nhóm [6]. Dừng nếu không có người quản trị hệ thống, nếu dữ liệu không thể sao lưu và khôi phục thành công, hoặc nếu nhu cầu sửa mã mâu thuẫn với nghĩa vụ AGPL.
Thử trong tám tuần, chỉ với hai mẫu tài liệu rủi ro thấp
Tuần một đến hai: dựng môi trường thử với MongoDB bền vững, HTTPS, mật khẩu mạnh và sao lưu; đồng thời luật sư xác định danh sách tài liệu được phép. Tiêu chí qua: khởi động lại toàn bộ hệ thống mà dữ liệu mẫu còn nguyên, và khôi phục từ bản sao lưu thành công.
Tuần ba đến sáu: dùng hai mẫu thật với năm đến mười khách đồng ý tham gia, song song với bản giấy. Đo tỷ lệ tài liệu hoàn tất không cần hỗ trợ, thời gian từ lúc gửi đến lúc hoàn tất so với quy trình cũ, số lần khách không nhận được thư mời hoặc mã OTP, và số tài liệu bị từ chối vì lý do kỹ thuật. Ngưỡng do văn phòng tự đặt, chẳng hạn chín phần mười hoàn tất không cần hỗ trợ.
Tuần bảy đến tám: rà soát hồ sơ nhật ký và chứng nhận hoàn tất, thử xác minh đối chiếu với bản giấy, chốt quyết định. Tiêu chí dừng: có sự cố mất dữ liệu, có khách phản đối giá trị chữ ký, hoặc chi phí quản trị vượt mức văn phòng chấp nhận. Tiêu chí tiếp tục: lợi ích thời gian đo được và luật sư bảo lãnh phạm vi loại tài liệu.
Kết luận: công cụ quy trình hữu ích khi đi cùng một chính sách pháp lý rõ ràng
OpenSign cho thấy một đường đi thực tế để một văn phòng luật giảm vòng lặp ký giấy: mẫu tài liệu, mời nhiều người ký, OTP email, hết hạn và nhật ký hoàn tất [1]. Tự lưu trữ giữ hồ sơ trong tầm tay văn phòng, đổi lại là trách nhiệm vận hành, sao lưu và bảo mật.
Điều cần xác minh nhiều nhất không nằm trong kho mã: giá trị pháp lý theo từng loại văn bản ở Việt Nam, phương án xác minh danh tính người ký, và tác động của AGPL nếu có tùy biến. Đó là việc của luật sư và chuyên gia an ninh.
Khuyến nghị cuối cùng là thử nhỏ, có điều kiện dừng, và giữ nguyên kênh giấy cho văn bản giá trị cao cho đến khi có kết luận. Nghiên cứu tại bàn này giúp đặt đúng câu hỏi, chưa thay cho bước chạy thử thật.
Nguồn, mốc kiểm tra và những gì chưa đọc
OpenSign được chọn từ kho lưu trữ GitHub Trending có sẵn: 5 lần xuất hiện trong danh sách JavaScript, lần đầu ngày 2026-01-02 ở vị trí 5, lần cuối ngày 2026-08-16 [7]. Kho lưu trữ chỉ gồm các danh sách Python, Go, JavaScript và Swift, thiếu hai ngày 2026-09-03 và 2026-10-12, và không phải top 100 chính thức. Trang được trích dẫn là trang ngày đầu tiên [7].
Mã được cố định tại commit e5f2c5c0a9f65ec01d8a53e4bf3a390c7ade7bcd, ngày 2026-08-21, kiểm tra ngày 2026-10-12. Các tệp đã đọc: README, LICENSE, INSTALLATION, USAGE, README của ứng dụng giao diện và CONTRIBUTING [1][2][3][4][5][6]. Siêu dữ liệu GitHub ghi bản phát hành v2.41.3 lúc thu thập, không nằm trong nguồn trích dẫn.
Đây là nghiên cứu tại bàn: không cài, không chạy, không đo. Tình huống tại Việt Nam là đề xuất giả định. Bài không phải công trình khoa học bình duyệt, không phải tư vấn pháp lý, và mọi nội dung trong kho mã được xem là dữ liệu tham khảo, không phải chỉ dẫn.
Xem mã nguồn OpenSign trên GitHub