ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ವಾಣಿಜ್ಯ ಸಾಫ್ಟ್ವೇರ್ ಉತ್ಪನ್ನವು ಓಪನ್ ಸೋರ್ಸ್ ಘಟಕಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ನೂರಾರು, ವಕೀಲರ ಬದಲು ಡೆವಲಪರ್ಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡಲ್ಪಟ್ಟಿದೆ. ಯಾವ ಪರವಾನಗಿಗಳು ಅನ್ವಯಿಸುತ್ತವೆ, ಅವುಗಳಿಗೆ ಏನು ಅಗತ್ಯವಿದೆ ಮತ್ತು ಉತ್ಪನ್ನವು ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂದು ಯಾರೂ ಹೇಳಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಅದು ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ. ಡಚ್ ಮತ್ತು EU ಕಾನೂನಿನ ಅಡಿಯಲ್ಲಿ ಓಪನ್ ಸೋರ್ಸ್ ಪರವಾನಗಿಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಅಪಾಯ ಎಲ್ಲಿದೆ ಮತ್ತು ಏನು ಸ್ಥಳದಲ್ಲಿರಬೇಕು ಎಂಬುದನ್ನು ಈ ಲೇಖನವು ವಿವರಿಸುತ್ತದೆ.
ಕಾನೂನು ಪರಿಭಾಷೆಯಲ್ಲಿ ಓಪನ್ ಸೋರ್ಸ್ ಪರವಾನಗಿ ಎಂದರೇನು
ಓಪನ್ ಸೋರ್ಸ್ ಪರವಾನಗಿ ಎಂದರೆ ಷರತ್ತುಗಳಿಗೆ ಒಳಪಟ್ಟು ನೀಡಲಾಗುವ ಹಕ್ಕುಸ್ವಾಮ್ಯ ಪರವಾನಗಿ. ಇದು ಮನ್ನಾ ಅಲ್ಲ, ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್ಗೆ ಸಮರ್ಪಣೆ ಅಲ್ಲ, ಹಕ್ಕುಗಳನ್ನು ತ್ಯಜಿಸುವುದಲ್ಲ, ಮತ್ತು ಆ ವಿಷಯದಲ್ಲಿ ಇದು ಡಚ್ ಕಾನೂನಿನ ಅಡಿಯಲ್ಲಿ ಯಾವುದೇ ಇತರ ಸಾಫ್ಟ್ವೇರ್ ಪರವಾನಗಿಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ . ಲೇಖಕರು ಆರ್ಟ್ ಅಡಿಯಲ್ಲಿ ಹಕ್ಕುಸ್ವಾಮ್ಯವನ್ನು ಉಳಿಸಿಕೊಂಡಿದ್ದಾರೆ. 1 ಆವ್ ಮತ್ತು ಕಲೆ. 10 ಆವ್, ಇದು ಕಂಪ್ಯೂಟರ್ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಕೃತಿಗಳಾಗಿ ರಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಪರವಾನಗಿಯು ಆರ್ಟ್ ಅಡಿಯಲ್ಲಿ ವಿಶೇಷ ಹಕ್ಕುಗಳನ್ನು ಉಲ್ಲಂಘಿಸುವ ಕೃತ್ಯಗಳಿಗೆ ಅನುಮತಿಸುತ್ತದೆ. 12 ಆವ್ ಮತ್ತು ಕಲೆ. 13 ಆವ್.
ವ್ಯಾಖ್ಯಾನಕ್ಕಿಂತ ಪರಿಣಾಮವು ಮುಖ್ಯವಾಗಿದೆ. ಪಾಲಿಸಿ, ಮತ್ತು ನಿಮ್ಮ ನಕಲು ಮತ್ತು ವಿತರಣೆ ಕಾನೂನುಬದ್ಧವಾಗಿದೆ. ಅನುಸರಿಸಲು ವಿಫಲವಾದರೆ, ಮತ್ತು ಅನುಮತಿಯು ನೀವು ಮಾಡಿದ್ದನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ: ನಿಮ್ಮ ಬಳಕೆಯು ಹಕ್ಕುಸ್ವಾಮ್ಯ ಉಲ್ಲಂಘನೆಯಾಗಿದೆ, ಒಪ್ಪಂದದ ಉಲ್ಲಂಘನೆಯಲ್ಲ. ಹೆಚ್ಚಿನ ಕಾಪಿಲೆಫ್ಟ್ ಪರವಾನಗಿಗಳು ಉಲ್ಲಂಘನೆಯ ಮೇಲೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮುಕ್ತಾಯಗೊಳಿಸುವ ಮೂಲಕ ಇದನ್ನು ಬಲಪಡಿಸುತ್ತವೆ - ಯಾವುದೇ ಗುಣಪಡಿಸುವ ಅವಧಿಯಿಲ್ಲದೆ GPLv2, ಆದರೆ ಸೂಚನೆಯ ನಂತರ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವಿಂಡೋದೊಳಗೆ ಉಲ್ಲಂಘನೆಯನ್ನು ಗುಣಪಡಿಸಿದರೆ GPLv3 ಮತ್ತು AGPLv3 ಹಕ್ಕುಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತವೆ.
ಡಚ್ ನ್ಯಾಯಾಲಯಗಳು ಈ ತಾರ್ಕಿಕತೆಯನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ. Rb ನಲ್ಲಿ. Amsterdam 22 ಸೆಪ್ಟೆಂಬರ್ 2020, ECLI:NL:RBAMS:2020:4717, ಫೋರ್ಕ್ಡ್ ಕೋಡ್ಬೇಸ್ನಿಂದ ಪರವಾನಗಿ ಪಠ್ಯ ಮತ್ತು ಹಕ್ಕುಸ್ವಾಮ್ಯ ಸೂಚನೆಯನ್ನು ತೆಗೆದುಹಾಕಿದ ವಿತರಕರನ್ನು ಅದರ ಅನುಮತಿಯನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದಾರೆ ಮತ್ತು ಉಲ್ಲಂಘಿಸುತ್ತಿದ್ದಾರೆ ಎಂದು ಪರಿಗಣಿಸಲಾಯಿತು. ಹೊಸ ಕೋಡ್ನ ದೊಡ್ಡ ಪ್ರಮಾಣವನ್ನು ಸೇರಿಸುವುದರಿಂದ ಸ್ವತಂತ್ರ ಕೃತಿ ಸೃಷ್ಟಿಯಾಗಲಿಲ್ಲ: ಮೂಲವು ಗುರುತಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಉಳಿದಿದೆ, ಆದ್ದರಿಂದ ಬಾಧ್ಯತೆಗಳು ಅದರೊಂದಿಗೆ ಪ್ರಯಾಣಿಸಿದವು.
ಎರಡು ಕುಟುಂಬಗಳು: ಪರವಾನಿಗೆ ಮತ್ತು ಕಾಪಿಲೆಫ್ಟ್
ಅನುಮತಿ ಪರವಾನಗಿಗಳು - MIT, BSD ಪರವಾನಗಿಗಳು, Apache 2.0 - ನೀವು ಹಕ್ಕುಸ್ವಾಮ್ಯ ಸೂಚನೆಗಳು ಮತ್ತು ಪರವಾನಗಿ ಪಠ್ಯವನ್ನು ಸಂರಕ್ಷಿಸಿದರೆ, ಮುಚ್ಚಿದ-ಮೂಲ ಉತ್ಪನ್ನಗಳ ಒಳಗೆ ಸೇರಿದಂತೆ ಬಳಕೆ, ಮಾರ್ಪಾಡು ಮತ್ತು ಮರುಹಂಚಿಕೆಯನ್ನು ಅನುಮತಿಸುತ್ತವೆ.
ಕಾಪಿಲೆಫ್ಟ್ ಪರವಾನಗಿಗಳು ನೀವು ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ವಿತರಿಸುವಾಗ ಅಥವಾ ಅದರ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಏನನ್ನಾದರೂ ವಿತರಿಸುವಾಗ, ನೀವು ಅದೇ ಪರವಾನಗಿಯ ಅಡಿಯಲ್ಲಿ ಹಾಗೆ ಮಾಡಬೇಕು ಮತ್ತು ಅನುಗುಣವಾದ ಮೂಲವನ್ನು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಬೇಕು. ಅವುಗಳು ತಲುಪುವಲ್ಲಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ.
| ಕುಟುಂಬ | ವಿಶಿಷ್ಟ ಪರವಾನಗಿಗಳು | ಪ್ರಮುಖ ಬಾಧ್ಯತೆ | ನಿಂದ ಪ್ರಚೋದಿಸಲ್ಪಟ್ಟಿದೆ | ಸ್ವಾಮ್ಯದ ಸಂಯೋಜನೆ |
|---|---|---|---|---|
| ಅನುಮತಿ | ಎಂಐಟಿ, ಬಿಎಸ್ಡಿ-2/3, ಅಪಾಚೆ 2.0 | ಸೂಚನೆಗಳು, ಪರವಾನಗಿ ಪಠ್ಯ, ಹಕ್ಕು ನಿರಾಕರಣೆಗಳನ್ನು ಸಂರಕ್ಷಿಸಿ; ಅಪಾಚೆ ಬದಲಾವಣೆ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ | ಮೂಲ ಅಥವಾ ಬೈನರಿ ರೂಪದಲ್ಲಿ ವಿತರಣೆ | ಹೌದು |
| ದುರ್ಬಲ ಕಾಪಿಲೆಫ್ಟ್ | ಎಂಪಿಎಲ್ 2.0, ಎಲ್ಜಿಪಿಎಲ್ 2.1/3, ಇಪಿಎಲ್ 2.0 | ಮುಚ್ಚಿದ ಫೈಲ್ಗಳು ಅಥವಾ ಲೈಬ್ರರಿಗಾಗಿ ಮೂಲ; LGPL ಬದಲಾಯಿಸುವಿಕೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ | ಒಳಗೊಂಡಿರುವ ಫೈಲ್ಗಳು ಅಥವಾ ಲೈಬ್ರರಿಯ ವಿತರಣೆ | ಹೌದು, ಗಡಿಯ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸಿ |
| ಬಲವಾದ ಕಾಪಿಲೆಫ್ಟ್ | ಜಿಪಿಎಲ್ವಿ2, ಜಿಪಿಎಲ್ವಿ3, ಇಯುಪಿಎಲ್ 1.2 | ಸಂಪೂರ್ಣ ಸಂಯೋಜಿತ ಕೆಲಸಕ್ಕೆ ಒಂದೇ ಪರವಾನಗಿ; ಸಂಪೂರ್ಣ ಸಂಬಂಧಿತ ಮೂಲ. | ವಿತರಣೆ; EUPL ಅಗತ್ಯ ಕಾರ್ಯಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಸಹ ಹೊಂದಿದೆ. | ಇಲ್ಲ, ನಿಜವಾಗಿಯೂ ಬೇರ್ಪಡಿಸದ ಹೊರತು |
| ನೆಟ್ವರ್ಕ್ ಕಾಪಿಲೆಫ್ಟ್ | AGPLv3 | GPLv3 ಆಗಿ, ಜೊತೆಗೆ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ದೂರಸ್ಥ ಬಳಕೆದಾರರಿಗೆ ಮೂಲ | ವಿತರಣೆ, ಅಥವಾ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಯನ್ನು ಸೇವೆಯಾಗಿ ನಡೆಸುವುದು | ಇಲ್ಲ |
ಕಾಪಿಲೆಫ್ಟ್ ಟ್ರಿಗ್ಗರ್ ಮತ್ತು ಲಿಂಕ್ ಮಾಡುವ ಪ್ರಶ್ನೆ
ಕಾಪಿಲೆಫ್ಟ್ ಕಟ್ಟುಪಾಡುಗಳು ವಿತರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ, ಬಳಕೆಯ ಮೇಲೆ ಅಲ್ಲ. ಆಂತರಿಕವಾಗಿ ಜಿಪಿಎಲ್ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವ ಕಂಪನಿಯು, ಎಷ್ಟೇ ಹೆಚ್ಚು ಮಾರ್ಪಡಿಸಿದ್ದರೂ, ಏನನ್ನೂ ವಿತರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಏನನ್ನೂ ನೀಡಬೇಕಾಗಿಲ್ಲ. "ನಾವು ವಿತರಿಸಿದ್ದೇವೆಯೇ?" ಎಂಬುದು ಯಾವಾಗಲೂ ಮೊದಲ ಪ್ರಶ್ನೆಯಾಗಿದೆ, ಮತ್ತು ಕಂಟೇನರ್ಗಳು, ಉಪಕರಣಗಳು, ಫರ್ಮ್ವೇರ್ ಮತ್ತು SDK ಗಳು ಆಂತರಿಕ ಪರಿಕರಗಳಿಗಿಂತ ಏಕೆ ಹೆಚ್ಚು ಮುಖ್ಯ ಎಂಬುದು.
ಎರಡನೆಯ ಪ್ರಶ್ನೆ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ. ಜಿಪಿಎಲ್ "ಕಾರ್ಯಕ್ರಮವನ್ನು ಆಧರಿಸಿದ ಕೆಲಸ" ಎಂದು ಹೇಳುತ್ತದೆ, ಇದು ಅಮೇರಿಕನ್ ವ್ಯುತ್ಪನ್ನ ಕೆಲಸದ ಪರಿಕಲ್ಪನೆಯನ್ನು ಎರವಲು ಪಡೆಯುತ್ತದೆ. ಡಚ್ ಕಾನೂನಿಗೆ ಅಂತಹ ಯಾವುದೇ ಪದವಿಲ್ಲ: ವಿಶ್ಲೇಷಣೆಯು ಸಂತಾನೋತ್ಪತ್ತಿ ಮತ್ತು ರೂಪಾಂತರ ಹಕ್ಕುಗಳ ಮೂಲಕ ಸಾಗುತ್ತದೆ, ಮೂಲದಿಂದ ಸಂರಕ್ಷಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲಾಗಿದೆಯೇ ಎಂದು ಕೇಳುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕ ಪ್ರಕರಣವೆಂದರೆ ಲಿಂಕ್ ಮಾಡುವುದು. ಸ್ವಾಮ್ಯದ ಮಾಡ್ಯೂಲ್ ಅನ್ನು GPL ಲೈಬ್ರರಿಗೆ ಲಿಂಕ್ ಮಾಡುವುದರಿಂದ ಕಾಪಿಲೆಫ್ಟ್ಗೆ ಒಳಪಟ್ಟು ಒಂದು ಕೆಲಸ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಡಚ್ ನ್ಯಾಯಾಲಯ ಎಂದಿಗೂ ನಿರ್ಧರಿಸಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಬದ್ಧ EU ಅಧಿಕಾರವಿಲ್ಲ. ಲಿಂಕ್ ಮಾಡುವುದರಿಂದ ಸಂಯೋಜಿತ ಕೆಲಸ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ ಎಂಬ ಫ್ರೀ ಸಾಫ್ಟ್ವೇರ್ ಫೌಂಡೇಶನ್ನ ದೃಷ್ಟಿಕೋನವು ಪರವಾನಗಿ ಸ್ಟೀವರ್ಡ್ನ ವ್ಯಾಖ್ಯಾನವಾಗಿದೆ, ಕಾನೂನಲ್ಲ, ಮತ್ತು ವಿರುದ್ಧ ದೃಷ್ಟಿಕೋನವು ಅಷ್ಟೇ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟಿಲ್ಲ. ಇಂಟರ್ನೆಟ್ನ ನೆಚ್ಚಿನ ಉತ್ತರ - ಡೈನಾಮಿಕ್ ಲಿಂಕಿಂಗ್ ಸುರಕ್ಷಿತ, ಸ್ಟ್ಯಾಟಿಕ್ ಲಿಂಕಿಂಗ್ ಅಲ್ಲ - ಡಚ್ ಹಕ್ಕುಸ್ವಾಮ್ಯ ಕಾನೂನಿನಲ್ಲಿ ಯಾವುದೇ ಆಧಾರವನ್ನು ಹೊಂದಿಲ್ಲ, ಅದು ಕಂಪೈಲರ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಕೇಳುವುದಿಲ್ಲ. ಹೆಚ್ಚು ಸಮರ್ಥನೀಯ ವಿಶ್ಲೇಷಣೆಯು ಘಟಕಗಳನ್ನು ಎಷ್ಟು ನಿಕಟವಾಗಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಕೇಳುತ್ತದೆ: ಅವು ವಿಳಾಸ ಸ್ಥಳ ಮತ್ತು ಡೇಟಾ ರಚನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆಯೇ, ಸಂಯೋಜನೆಯನ್ನು ಒಂದು ಉತ್ಪನ್ನವಾಗಿ ರವಾನಿಸಲಾಗಿದೆಯೇ, ಏಕಾಂಗಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದೇ, ಸ್ವಾಮ್ಯದ ಭಾಗವು ಕಾಪಿಲೆಫ್ಟ್ ಬದಿಯಿಂದ ಹೆಡರ್ಗಳು, ಮ್ಯಾಕ್ರೋಗಳು ಅಥವಾ ಇನ್ಲೈನ್ ಕೋಡ್ ಅನ್ನು ಪುನರುತ್ಪಾದಿಸುತ್ತದೆಯೇ? ಆ ಪ್ರಶ್ನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅಪಾಯವನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಅವರು ಹಾಗೆ ಮಾಡದಿದ್ದರೆ, ಪ್ರಕ್ರಿಯೆಯ ಗಡಿಯ ಹಿಂದೆ ಘಟಕವನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ, ಅದನ್ನು ಬದಲಾಯಿಸಿ ಅಥವಾ ವಾಣಿಜ್ಯ ಪರವಾನಗಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.
AGPL ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಬಳಕೆ
AGPL ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಏಕೆಂದರೆ ಕಾಪಿಲೆಫ್ಟ್ ವಿತರಣೆಯಿಂದ ಪ್ರಚೋದಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು SaaS ಪೂರೈಕೆದಾರರು ವಿತರಿಸುವುದಿಲ್ಲ. ಅದರ ನೆಟ್ವರ್ಕ್ ಷರತ್ತು ನೀವು ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಿದರೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ದೂರದಿಂದಲೇ ಸಂವಹನ ನಡೆಸುವ ಬಳಕೆದಾರರಿಗೆ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಿದರೆ, ನೀವು ಅವರಿಗೆ ನಿಮ್ಮ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಯ ಅನುಗುಣವಾದ ಮೂಲವನ್ನು ನೀಡಬೇಕೆಂದು ಬಯಸುತ್ತದೆ.
ಮೂರು ಅಂಶಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ. ಈ ಬಾಧ್ಯತೆಯು ಸೇವೆಯ ಬಳಕೆದಾರರಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, ಇದು ಮುಕ್ತ-ಸೈನ್ ಅಪ್ ಉತ್ಪನ್ನದಲ್ಲಿ ಕಡಿಮೆ ಸೌಕರ್ಯವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಮಾರ್ಪಾಡು ಮೂಲಕ ಪ್ರಚೋದಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮಾರ್ಪಡಿಸದ ಘಟಕವು ಅದನ್ನು ತೊಡಗಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ ಆದರೆ ಪ್ಯಾಚ್ ಮಾಡಿದ ನಿರ್ಮಾಣವು ಅದನ್ನು ತೊಡಗಿಸಿಕೊಳ್ಳಬಹುದು. ಮತ್ತು ಇದು ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ನ ಉಳಿದ ಭಾಗಕ್ಕೆ GPL ನಂತೆಯೇ ಸಂಯೋಜಿತ-ಕೆಲಸದ ಪ್ರಶ್ನೆಯನ್ನು ಹುಟ್ಟುಹಾಕುತ್ತದೆ - ಅದಕ್ಕಾಗಿಯೇ ಅನೇಕ ಕಂಪನಿಗಳು ಉತ್ಪಾದನಾ ಕೋಡ್ನಲ್ಲಿ AGPL ಅನ್ನು ನಿಷೇಧಿಸುತ್ತವೆ.
ಪರವಾನಗಿ ಹೊಂದಾಣಿಕೆ
ಹೊಂದಾಣಿಕೆಯು ಒಂದು ವಿತರಣೆಯಲ್ಲಿ ಪೂರೈಸಲಾಗದ ಬಾಧ್ಯತೆಗಳನ್ನು ವಿಧಿಸುವ ಘಟಕಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಸಮಸ್ಯೆಯಾಗಿದೆ: ಅನುಮತಿ ಪರವಾನಗಿಗಳು ಬಹುತೇಕ ಎಲ್ಲದಕ್ಕೂ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ, ಕಾಪಿಲೆಫ್ಟ್ ಪರವಾನಗಿಗಳು ತಮ್ಮದೇ ಆದ ನಿಯಮಗಳು ಅನುಮತಿಸುವದರೊಂದಿಗೆ ಮಾತ್ರ. ಪ್ರಮಾಣಿತ ಪ್ರಕರಣವೆಂದರೆ ಅಪಾಚೆ 2.0 ಮತ್ತು GPLv2. ಅಪಾಚೆ ಸಾಫ್ಟ್ವೇರ್ ಫೌಂಡೇಶನ್ ಮತ್ತು ಫ್ರೀ ಸಾಫ್ಟ್ವೇರ್ ಫೌಂಡೇಶನ್ ಸಂಯೋಜನೆಯನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ ಎಂದು ಒಪ್ಪುತ್ತವೆ, ಏಕೆಂದರೆ ಅಪಾಚೆ 2.0 ರ ಪೇಟೆಂಟ್ ಮುಕ್ತಾಯ ಮತ್ತು ಪರಿಹಾರ ನಿಬಂಧನೆಗಳು GPLv2 ಅನುಮತಿಸದ ಹೆಚ್ಚುವರಿ ನಿರ್ಬಂಧಗಳಾಗಿವೆ. GPLv3 ಅನ್ನು ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ರಚಿಸಲಾಗಿದೆ. ಹೊಂದಾಣಿಕೆಯು ಸಹ ನಿರ್ದೇಶನಾತ್ಮಕವಾಗಿದೆ: ಅಪಾಚೆ ಕೋಡ್ ಅನ್ನು GPLv3 ಯೋಜನೆಗೆ ಹೀರಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ವಿರುದ್ಧವಾಗಿ ಅಲ್ಲ. ತಪ್ಪಾದ ಸ್ಥಳದಲ್ಲಿ ಒಂದು GPL ಘಟಕವು ಮರು ಪರವಾನಗಿ ನೀಡುವಿಕೆ, ಮರು-ಎಂಜಿನಿಯರಿಂಗ್ ಅಥವಾ ತೆಗೆದುಹಾಕುವಿಕೆಯ ನಡುವಿನ ಆಯ್ಕೆಯನ್ನು ಒತ್ತಾಯಿಸಬಹುದು - ಬಿಡುಗಡೆಯ ಮೊದಲು ನಂತರಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಗ್ಗವಾಗಿದೆ.
ಗುಣಲಕ್ಷಣ ಮತ್ತು ಸೂಚನೆ ಬಾಧ್ಯತೆಗಳು
ಹೆಚ್ಚಾಗಿ ಉಲ್ಲಂಘಿಸಲ್ಪಡುವ ಬಾಧ್ಯತೆಗಳು ಕಡಿಮೆ ನಾಟಕೀಯವಾಗಿವೆ: ಹಕ್ಕುಸ್ವಾಮ್ಯ ಸೂಚನೆಗಳು, ಪರವಾನಗಿ ಪಠ್ಯಗಳು, ಹಕ್ಕು ನಿರಾಕರಣೆಗಳು ಮತ್ತು ಅಪಾಚೆ 2.0 ಅಡಿಯಲ್ಲಿ, ವಿತರಣೆಯ ಜೊತೆಗಿನ ಸಾಮಗ್ರಿಗಳಲ್ಲಿ NOTICE ವಿಷಯಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸುವುದು. ಪ್ರತಿಯೊಂದು ಕುಟುಂಬವು ಅವುಗಳನ್ನು ವಿಧಿಸುತ್ತದೆ, MIT ಮತ್ತು BSD ಸೇರಿದಂತೆ. ಯಾರೂ ಅವುಗಳ ಮಾಲೀಕರಲ್ಲದ ಕಾರಣ ಅವುಗಳನ್ನು ಉಲ್ಲಂಘಿಸಲಾಗಿದೆ ಮತ್ತು ಸರಿಪಡಿಸಲು ಸುಲಭವಾಗಿದೆ - ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ಪನ್ನದೊಂದಿಗೆ ರವಾನೆಯಾಗುವ ರಚಿತವಾದ ಗುಣಲಕ್ಷಣ ಫೈಲ್. ಮೇಲಿನ ಡಚ್ ಪ್ರಕರಣವು ನಿಖರವಾಗಿ ಈ ವೈಫಲ್ಯವನ್ನು ಆನ್ ಮಾಡಿತು.
ಪೇಟೆಂಟ್ ಅನುದಾನಗಳು ಮತ್ತು ಪೇಟೆಂಟ್ ಪ್ರತೀಕಾರ
MIT ಮತ್ತು BSD ಪೇಟೆಂಟ್ಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಪೇಟೆಂಟ್ ಪರವಾನಗಿಯನ್ನು ಸೂಚಿಸಬಹುದೇ ಎಂಬುದು ಬಗೆಹರಿಯುವುದಿಲ್ಲ. ಅಪಾಚೆ 2.0 ಪ್ರತಿ ಕೊಡುಗೆದಾರರಿಂದ ಎಕ್ಸ್ಪ್ರೆಸ್, ರಾಯಲ್ಟಿ-ಮುಕ್ತ ಪೇಟೆಂಟ್ ಪರವಾನಗಿಯನ್ನು ಸೇರಿಸಿದೆ, ಪ್ರತೀಕಾರದ ಷರತ್ತಿನೊಂದಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ: ಕೆಲಸವು ಉಲ್ಲಂಘಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಪೇಟೆಂಟ್ ಪರವಾನಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಆರೋಪಿಸಿ ಪೇಟೆಂಟ್ ಮೊಕದ್ದಮೆ ಹೂಡಿ. GPLv3 ಹೋಲಿಸಬಹುದಾದ ಅನುದಾನ ಮತ್ತು ತನ್ನದೇ ಆದ ಪೇಟೆಂಟ್ ನಿಬಂಧನೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ಪೇಟೆಂಟ್ ಪೋರ್ಟ್ಫೋಲಿಯೊ ಹೊಂದಿರುವ ಕಂಪನಿಗಳಿಗೆ ಎರಡು ಪರಿಣಾಮಗಳು. ನಿಮ್ಮ ಎಂಜಿನಿಯರ್ಗಳು ಅಪಾಚೆ- ಅಥವಾ GPLv3-ಪರವಾನಗಿ ಪಡೆದ ಯೋಜನೆಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡಿದರೆ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಪೇಟೆಂಟ್ಗಳ ಅಡಿಯಲ್ಲಿ ಪರವಾನಗಿಗಳನ್ನು ನೀಡುತ್ತಿದ್ದೀರಿ. ಮತ್ತು ನೀವು ಬಳಸುವ ಅದೇ ಅಪಾಚೆ-ಪರವಾನಗಿ ಪಡೆದ ಘಟಕಗಳನ್ನು ಅವಲಂಬಿಸಿ ಕಂಪನಿಯ ವಿರುದ್ಧ ನೀವು ಎಂದಾದರೂ ಪೇಟೆಂಟ್ಗಳನ್ನು ಪ್ರತಿಪಾದಿಸಿದರೆ, ಪ್ರತೀಕಾರವು ನೀವು ಅವಲಂಬಿಸಿರುವ ಪರವಾನಗಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು.
EUPL ಮತ್ತು ಡಚ್ ಸಾರ್ವಜನಿಕ ವಲಯ
ಯುರೋಪಿಯನ್ ಯೂನಿಯನ್ ಪಬ್ಲಿಕ್ ಲೈಸೆನ್ಸ್ ಆವೃತ್ತಿ 1.2, ಯುರೋಪಿಯನ್ ಕಮಿಷನ್ ಮೇ 2017 ರಲ್ಲಿ ನಿರ್ಧಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ ಅನುಮೋದಿಸಿದೆ, ಇದು ಮೂರು ವಿಶಿಷ್ಟ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿರುವ OSI-ಅನುಮೋದಿತ ಕಾಪಿಲೆಫ್ಟ್ ಪರವಾನಗಿಯಾಗಿದೆ.
- ಭಾಷೆ. ಇದು ಅಧಿಕೃತ EU ಭಾಷೆಗಳಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ, ಎಲ್ಲಾ ಅನುಮೋದಿತ ಆವೃತ್ತಿಗಳು ಒಂದೇ ರೀತಿಯ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿವೆ, ಆದ್ದರಿಂದ ಡಚ್ ಪ್ರಾಧಿಕಾರವು ಡಚ್ ಭಾಷೆಯಲ್ಲಿ ಒಪ್ಪಂದ ಮಾಡಿಕೊಳ್ಳಬಹುದು.
- ಹೊಂದಾಣಿಕೆ. ಅನುಬಂಧವು ಹೊಂದಾಣಿಕೆಯ ಪರವಾನಗಿಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ - GPLv2 ಮತ್ತು v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL ಮತ್ತು CeCILL - ಮತ್ತು EUPL ಕೋಡ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಲಾದ ಪರವಾನಗಿಯ ಅಡಿಯಲ್ಲಿ ಕೋಡ್ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಉತ್ಪನ್ನ ಕೆಲಸವನ್ನು ಆ ಪರವಾನಗಿಯ ಅಡಿಯಲ್ಲಿ ವಿತರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
- ತಲುಪಿ. ಇದರ ವಿತರಣೆಯ ವ್ಯಾಖ್ಯಾನವು ಕೆಲಸವನ್ನು ಆನ್ಲೈನ್ ಅಥವಾ ಆಫ್ಲೈನ್ನಲ್ಲಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ. ಅಥವಾ ಅದರ ಅಗತ್ಯ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುವುದು, ಮತ್ತು ಕಲೆ. 5 EUPL ಅದೇ ಕಾರ್ಯವನ್ನು ನೀಡುವ ರಿಮೋಟ್ ಸಂವಹನದ ಮೂಲಕ ಕಾಪಿಲೆಫ್ಟ್ ಬಾಧ್ಯತೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಇದು ಸೇವೆಯಾಗಿ ವಿತರಿಸಲಾದ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ತಲುಪುತ್ತದೆ, ಒಂದು ರೀತಿಯಲ್ಲಿ GPL ತಲುಪುವುದಿಲ್ಲ.
ಡಚ್ ಸಾರ್ವಜನಿಕ ವಲಯದ ಗ್ರಾಹಕರು EUPL ಅನ್ನು ಕಾನೂನಿನ ವಿಷಯವಾಗಿ ಅಲ್ಲ, ನೀತಿಯ ವಿಷಯವಾಗಿ ಕೇಳಬಹುದು. ಇಂಟರ್ಆಪರೇಬಲ್ ಯುರೋಪ್ ಆಕ್ಟ್, ರೆಗ್ಯುಲೇಷನ್ (EU) 2024/903, ಸಾರ್ವಜನಿಕ ವಲಯದ ಸಂಸ್ಥೆಗಳಿಗೆ ಮುಕ್ತ ಮೂಲದಂತಹ ನಿರ್ಬಂಧಿತ ಪರವಾನಗಿ ನಿಯಮಗಳಿಲ್ಲದೆ ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆಯ ಪರಿಹಾರಗಳನ್ನು ಆದ್ಯತೆ ನೀಡುವಂತೆ ನಿರ್ದೇಶಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಸಮಾನವಾಗಿರುತ್ತದೆ; ರಾಷ್ಟ್ರೀಯವಾಗಿ, ಮುಕ್ತ ಮೂಲದ ತತ್ವ, ಟೆನ್ಸಿಜ್ ಕ್ಯಾಬಿನೆಟ್ ನಿರ್ಧಾರಗಳು ಮತ್ತು ನೀತಿ ಮಾರ್ಗಗಳ ಮೇಲೆ ನಿಂತಿದೆ, ಕಾನೂನಿನ ಮೇಲೆ ಅಲ್ಲ: ವೆಟ್ ಡಿಜಿಟೇಲ್ ಓವರ್ಹೀಡ್ ಡಿಜಿಟಲ್ ಗುರುತಿನ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ ಆದರೆ ಎಲ್ಲಾ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪ್ರಕಟಿಸಲು ಯಾವುದೇ ಜಾರಿಗೊಳಿಸಬಹುದಾದ ಬಾಧ್ಯತೆಯನ್ನು ವಿಧಿಸುವುದಿಲ್ಲ. ಟೆಂಡರ್ ದಾಖಲೆಗಳನ್ನು ಓದಿ: EUPL ಅವಶ್ಯಕತೆಯು ನಿಮ್ಮ ವಿತರಣೆಯನ್ನು ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಮರುಬಳಕೆ ಮಾಡಲು ಉದ್ದೇಶಿಸಿರುವ ಸ್ವಾಮ್ಯದ ಕೋಡ್ನೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿರಬಹುದು.
ಆಚರಣೆಯಲ್ಲಿ ಜಾರಿ
ಯಾರು ಮೊಕದ್ದಮೆ ಹೂಡಬಹುದು. ಹಕ್ಕುದಾರರು - ವೈಯಕ್ತಿಕ ಕೊಡುಗೆದಾರರು, ಅಥವಾ ನಿಯೋಜಿತ ಹಕ್ಕುಸ್ವಾಮ್ಯವನ್ನು ಹೊಂದಿರುವ ಪ್ರತಿಷ್ಠಾನ ಅಥವಾ ಕಂಪನಿ. ವಿಘಟಿತ ಕರ್ತೃತ್ವವು ಪ್ರಾಯೋಗಿಕ ತಡೆಗೋಡೆಯಾಗಿದೆ: ಹಕ್ಕುದಾರರು ಸಮಸ್ಯೆಯಲ್ಲಿರುವ ಕೋಡ್ನ ಮಾಲೀಕತ್ವವನ್ನು ಸಾಬೀತುಪಡಿಸಬೇಕು. ಕರ್ತೃತ್ವದ ಪುರಾವೆಯ ಕೊರತೆಯಿಂದಾಗಿ ವರ್ಚುವಲೈಸೇಶನ್ ಮಾರಾಟಗಾರರ ವಿರುದ್ಧ ಕರ್ನಲ್ ಡೆವಲಪರ್ನ ಹಕ್ಕು ವಿಫಲವಾದ ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧ ಯುರೋಪಿಯನ್ GPL ಪ್ರಕರಣವನ್ನು ಅದು ಸೋಲಿಸಿತು (LG ಹ್ಯಾಂಬರ್ಗ್ 8 ಜುಲೈ 2016, 310 O 89/15; OLG ಹ್ಯಾಂಬರ್ಗ್ 28 ಫೆಬ್ರವರಿ 2019, 5 U 146/16 ಅನ್ನು ಎತ್ತಿಹಿಡಿಯಲಾಗಿದೆ).
ಪ್ರಕರಣ ಕಾನೂನು ಏನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಜರ್ಮನ್ ನ್ಯಾಯಾಲಯಗಳು ಓಪನ್ ಸೋರ್ಸ್ ಪರವಾನಗಿಗಳು ಮಾನ್ಯವಾಗಿವೆ ಮತ್ತು ಆ ಉಲ್ಲಂಘನೆಯು ವಿತರಣೆಯನ್ನು ಕಾನೂನುಬಾಹಿರಗೊಳಿಸುತ್ತದೆ ಎಂದು ಪದೇ ಪದೇ ಒಪ್ಪಿಕೊಂಡಿವೆ, ಇದು ಮೊದಲ GPL ತಡೆಯಾಜ್ಞೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ (LG München I 19 ಮೇ 2004, 21 O 6123/04). ಜಾಕೋಬ್ಸೆನ್ ವಿ ಕ್ಯಾಟ್ಜರ್ , 535 F.3d 1373 (ಫೆಡ್. ಸರ್. 2008) ನಲ್ಲಿ US ಫೆಡರಲ್ ಸರ್ಕ್ಯೂಟ್ ಅದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿತು: ಪರವಾನಗಿ ನಿಯಮಗಳು ಅನುದಾನದ ವ್ಯಾಪ್ತಿಯ ಷರತ್ತುಗಳಾಗಿವೆ, ಕೇವಲ ಒಪ್ಪಂದಗಳಲ್ಲ, ಆದ್ದರಿಂದ ಉಲ್ಲಂಘನೆಯು ಹಕ್ಕುಸ್ವಾಮ್ಯ ಹಕ್ಕು ಮತ್ತು ತಡೆಯಾಜ್ಞೆ ಪರಿಹಾರವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. US ಮೊಕದ್ದಮೆಯು ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸ್ವೀಕರಿಸುವವರು GPL ಅನ್ನು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಫಲಾನುಭವಿಯಾಗಿ ಜಾರಿಗೊಳಿಸಬಹುದೇ ಎಂದು ಅನ್ವೇಷಿಸುತ್ತಿದೆ. ಕ್ಯಾಲಿಫೋರ್ನಿಯಾದ ಸುಪೀರಿಯರ್ ಕೋರ್ಟ್ ಮುಂದೆ ಸಾಫ್ಟ್ವೇರ್ ಫ್ರೀಡಂ ಕನ್ಸರ್ವೆನ್ಸಿ ವಿ ವಿಜಿಯೊದಲ್ಲಿನ ಕೇಂದ್ರ ಪ್ರಶ್ನೆ ಅದು : ಗ್ರಾಹಕರು, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಫಲಾನುಭವಿಗಳಾಗಿ, GPLv2 ಅಡಿಯಲ್ಲಿ ಮೂಲ ಕೋಡ್ ಬಿಡುಗಡೆಯನ್ನು ಒತ್ತಾಯಿಸಬಹುದೇ. ಡಿಸೆಂಬರ್ 23, 2025 ರಂದು ನ್ಯಾಯಾಲಯವು ಸಾರಾಂಶದ ತೀರ್ಪಿನ ಕುರಿತು ಒಂದು ಅಂಶವನ್ನು ನಿರ್ಧರಿಸಿತು, GPLv2 ಮತ್ತು LGPLv2.1 ಸಾಧನದಲ್ಲಿ ಅದರ ಕಾರ್ಯವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರುಸ್ಥಾಪಿಸಬಹುದಾದ ಮೂಲದ ಬದಲು ಬೇರೆಡೆ ಬಳಸಲು ಪಡೆಯಬಹುದಾದ ಮತ್ತು ಮರುನಿರ್ಮಾಣ ಮಾಡಬಹುದಾದ ಮೂಲದ ಅಗತ್ಯವಿದೆ ಎಂದು ತೀರ್ಪು ನೀಡಿತು. ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಫಲಾನುಭವಿ ಪ್ರಶ್ನೆಯನ್ನು ಸ್ವತಃ ಬೆಂಚ್ ವಿಚಾರಣೆಗೆ ಬಿಡಲಾಯಿತು, ಇದನ್ನು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಮುಂದೂಡಲಾಗಿದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಕ್ಯಾಲಿಫೋರ್ನಿಯಾದ ಒಪ್ಪಂದ ಕಾನೂನು ಪ್ರಶ್ನೆಯಾಗಿದೆ, ಆದ್ದರಿಂದ ಇದು ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ ಏನನ್ನೂ ಬಂಧಿಸುವುದಿಲ್ಲ; ಅದು ಬದಲಾಗುವುದು ದೂರು ನೀಡಲು ಸಾಧ್ಯವಾಗುವ ಜನರ ಸಂಖ್ಯೆ.
ಡಚ್ ನ್ಯಾಯಾಲಯವು ಅದನ್ನು ಹೇಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. Auteurswet ಅಡಿಯಲ್ಲಿ ಹಕ್ಕುಸ್ವಾಮ್ಯ ಉಲ್ಲಂಘನೆಯಾಗಿ: ಹಕ್ಕುದಾರನು ಮಾಲೀಕತ್ವ ಮತ್ತು ಸಂತಾನೋತ್ಪತ್ತಿ ಅಥವಾ ಸಂವಹನವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತಾನೆ; ಪ್ರತಿವಾದಿಯು ಪರವಾನಗಿಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತಾನೆ; ಹಕ್ಕುದಾರನು ಅದರ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಲಾಗಿಲ್ಲ ಎಂದು ಉತ್ತರಿಸುತ್ತಾನೆ, ಆದ್ದರಿಂದ ಪ್ರತಿವಾದ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಆರ್ಟ್ ಅಡಿಯಲ್ಲಿ ಒಪ್ಪಂದದ ಪರಿಹಾರಗಳು. 6:265 BW ಸಮಾನಾಂತರವಾಗಿ ಚಲಿಸುತ್ತದೆ, ಆದರೆ ಹಕ್ಕುಸ್ವಾಮ್ಯವು ಬಲವಾದ ಮಾರ್ಗವಾಗಿದೆ.
ಪರಿಹಾರಗಳು. ಕಲೆಯ ಅಡಿಯಲ್ಲಿ ತಡೆಯಾಜ್ಞೆ. 3:296 BW, ಸಾಮಾನ್ಯವಾಗಿ ದಂಡ ಪಾವತಿಯೊಂದಿಗೆ ಮತ್ತು ಸಾರಾಂಶ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಲಭ್ಯವಿದೆ; ಕಲೆಯ ಅಡಿಯಲ್ಲಿ ಹಾನಿಗಳು. 27 Aw ಮತ್ತು ಕಲೆಯ ಅಡಿಯಲ್ಲಿ ಲಾಭದ ಖಾತೆ. 27a Aw; ಕಲೆಯ ಅಡಿಯಲ್ಲಿ ಮರುಪಡೆಯುವಿಕೆ, ಶರಣಾಗತಿ ಅಥವಾ ನಾಶ. 28 Aw; ಮತ್ತು ಕಲೆಯ ಅಡಿಯಲ್ಲಿ ಸಮಂಜಸವಾದ ಮತ್ತು ಅನುಪಾತದ ಕಾನೂನು ವೆಚ್ಚಗಳ ಸಂಪೂರ್ಣ ಮರುಪಡೆಯುವಿಕೆ. 1019h Rv. ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಉಚಿತವಾಗಿ ವಿತರಿಸಿದಾಗ, ನಷ್ಟವನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವುದು ಕಷ್ಟ, ಮತ್ತು ಜರ್ಮನ್ ಮೇಲ್ಮನವಿ ನ್ಯಾಯಾಲಯವು ತಡೆಯಾಜ್ಞೆಯನ್ನು ಎತ್ತಿಹಿಡಿಯುವಾಗ ಹಾನಿಗಳನ್ನು ನೀಡಲು ನಿರಾಕರಿಸಿತು (OLG ಹ್ಯಾಮ್ 13 ಜೂನ್ 2017, 4 U 72/16). ಅಪರೂಪಕ್ಕೆ ಹಾನಿಗಳನ್ನು ಕಚ್ಚುವುದು: ಇದು ತಡೆಯಾಜ್ಞೆ, ಮರುಸ್ಥಾಪನೆ, ವೆಚ್ಚಗಳ ಆದೇಶ ಮತ್ತು ನೀವು ಎಂದಿಗೂ ಪ್ರಕಟಿಸಲು ಉದ್ದೇಶಿಸದ ಮೂಲವನ್ನು ಪ್ರಕಟಿಸಬೇಕಾಗಿರುವುದು.
ನೀವು ಅನುಸರಣೆ ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಕೊಂಡಾಗ
ಸಾಮಾನ್ಯವಾಗಿ ಅನ್ವೇಷಣೆಯು ಗ್ರಾಹಕರ ಭದ್ರತಾ ಪ್ರಶ್ನಾವಳಿ, ಡ್ಯೂ ಡಿಲಿಜೆನ್ಸ್ ಸಮಯದಲ್ಲಿ ಸ್ಕ್ಯಾನ್ ಅಥವಾ ಹಕ್ಕುದಾರರಿಂದ ಪತ್ರದಿಂದ ಬರುತ್ತದೆ. ನಂತರ ಪರಿಹಾರವು ಈ ಕೆಳಗಿನಂತೆ ನಡೆಯುತ್ತದೆ. ಮಾನ್ಯತೆ ಗಂಭೀರವಾಗಿದ್ದರೆ ಪೀಡಿತ ನಿರ್ಮಾಣದ ವಿತರಣೆಯನ್ನು ನಿಲ್ಲಿಸಿ. ಯಾವ ಘಟಕ, ಯಾವ ಆವೃತ್ತಿ, ಯಾವ ಪರವಾನಗಿ, ಯಾವ ಉತ್ಪನ್ನಗಳು ಮತ್ತು ಬಿಡುಗಡೆಗಳನ್ನು ಯಾವ ಅವಧಿಯಲ್ಲಿ ಸ್ಥಾಪಿಸಿ. ಪರವಾನಗಿಗೆ ನಿಜವಾಗಿ ಏನು ಬೇಕು ಎಂಬುದನ್ನು ಕೆಲಸ ಮಾಡಿ - ಸಾಮಾನ್ಯವಾಗಿ ಮೂಲ ಬಿಡುಗಡೆಯ ಬದಲು ಗುಣಲಕ್ಷಣ ಫೈಲ್. ಕಲಾಕೃತಿಗಳನ್ನು ತಯಾರಿಸಿ: ಸೂಚನೆಗಳು, ಪರವಾನಗಿ ಪಠ್ಯಗಳು, ಬಿಲ್ಡ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಸೇರಿದಂತೆ ಸಂಪೂರ್ಣ ಅನುಗುಣವಾದ ಮೂಲ ಮತ್ತು ಬಳಸಿದಲ್ಲಿ ಲಿಖಿತ ಕೊಡುಗೆ. ಕಂಪ್ಲೈಂಟ್ ಬಿಡುಗಡೆಯನ್ನು ರವಾನಿಸಿ, ನಂತರ ನೀವು ಮಾಡಬೇಕೇ ಅಥವಾ ಬೇಡವೇ ಎಂಬುದರ ಕುರಿತು ವಾದಿಸುವ ಬದಲು ನೀವು ಏನು ಮಾಡಿದ್ದೀರಿ ಎಂದು ಹಕ್ಕುದಾರರಿಗೆ ತಿಳಿಸಿ.
GPLv3 ಮತ್ತು AGPLv3 ಅಡಿಯಲ್ಲಿ ಕ್ಯೂರ್ ವಿಂಡೋ ವೇಗ ಕಾನೂನು ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ; GPLv2 ಅಡಿಯಲ್ಲಿ ಯಾವುದೇ ಕ್ಯೂರ್ ಹಕ್ಕು ಇರುವುದಿಲ್ಲ, ಅದಕ್ಕಾಗಿಯೇ ಹೆಚ್ಚಿನ ಜಾರಿಯು ಮಾತುಕತೆಯ ಅನುಸರಣೆ ಒಪ್ಪಂದದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಆಂತರಿಕ ಎಂಜಿನಿಯರಿಂಗ್ ವರದಿಗೆ ಅಲ್ಲ, ನಿಮ್ಮ ವಕೀಲರ ಸಲಹೆಗೆ ಸವಲತ್ತು ಲಗತ್ತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.
M&A ನಲ್ಲಿ ಮುಕ್ತ ಮೂಲ ಮತ್ತು ಸರಿಯಾದ ಪರಿಶ್ರಮ
ಸಾಫ್ಟ್ವೇರ್ ಸ್ವಾಧೀನದಲ್ಲಿ, ಓಪನ್ ಸೋರ್ಸ್ ಒಂದು ಪ್ರಮಾಣಿತ ಶ್ರದ್ಧೆ ಕಾರ್ಯಪ್ರವಾಹವಾಗಿದೆ, ಮತ್ತು ಕೋರ್ ಉತ್ಪನ್ನದಲ್ಲಿನ ಬಹಿರಂಗಪಡಿಸದ ಕಾಪಿಲೆಫ್ಟ್ ಘಟಕವು ಒಪ್ಪಂದವನ್ನು ನಿಜವಾಗಿಯೂ ಚಲಿಸುವ ಕೆಲವೇ ಸಂಶೋಧನೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ: ಉತ್ಪನ್ನವನ್ನು ಅದರ ಮೂಲವನ್ನು ಬಿಡುಗಡೆ ಮಾಡದೆ ವಿತರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಖರೀದಿದಾರನು ಬೆಲೆ ನಿಗದಿಪಡಿಸಿದ ಆಸ್ತಿಗಿಂತ ಭಿನ್ನವಾದ ಆಸ್ತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಿದ್ದಾನೆ.
ಕೋಡ್ಬೇಸ್ ಸ್ಕ್ಯಾನ್, ಪರವಾನಗಿಗಳೊಂದಿಗೆ ಘಟಕ ದಾಸ್ತಾನು ಮತ್ತು ಕೊಡುಗೆದಾರ ಮತ್ತು ಗುತ್ತಿಗೆದಾರರ ವ್ಯವಸ್ಥೆಗಳ ಕುರಿತು ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿ. ವಿಶಿಷ್ಟ ಫಲಿತಾಂಶಗಳೆಂದರೆ ನಿರ್ದಿಷ್ಟ ಪರಿಹಾರ, ಪರಿಹಾರಕ್ಕಾಗಿ ಬಾಕಿ ಇರುವ ಧಾರಣ, ತೆಗೆದುಹಾಕುವ ಅಗತ್ಯವಿರುವ ಷರತ್ತು ಪೂರ್ವನಿದರ್ಶನ ಅಥವಾ ಬೆಸ್ಪೋಕ್ ಓಪನ್ ಸೋರ್ಸ್ ಖಾತರಿ. ಮಾರಾಟಗಾರರು ಮೊದಲು ಸ್ಕ್ಯಾನ್ ಮಾಡಬೇಕು: ನೀವು ಬಹಿರಂಗಪಡಿಸುವ ಸಂಶೋಧನೆಗಳು ಮಾತುಕತೆ, ಖರೀದಿದಾರರ ಸಲಹೆಗಾರರು ಮಾಡುವ ಸಂಶೋಧನೆಗಳು ಹತೋಟಿ. ಖರೀದಿದಾರರು "ಕಂಪನಿಯು ತನ್ನ ಐಪಿಯನ್ನು ಹೊಂದಿದೆ" ಎಂದು ಬಯಸಬಾರದು, ಆದರೆ ಸ್ವಾಮ್ಯದ ಮೂಲ ಕೋಡ್ನ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಉತ್ಪನ್ನವು ಮುಕ್ತ ಮೂಲವನ್ನು ಒಳಗೊಂಡಿಲ್ಲ ಎಂಬ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಪಡೆಯಬೇಕು.
ಸಾಮಗ್ರಿಗಳ ಬಿಲ್, ಸ್ಕ್ಯಾನಿಂಗ್ ಮತ್ತು ಸೈಬರ್ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಕಾಯ್ದೆ
ಸಾಫ್ಟ್ವೇರ್ ಸಾಮಗ್ರಿಗಳ ಬಿಲ್ ಎಂದರೆ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಪರವಾನಗಿಗಳನ್ನು ಹೊಂದಿರುವ ಉತ್ಪನ್ನದ ಘಟಕಗಳ ದಾಸ್ತಾನು. ಇತ್ತೀಚಿನವರೆಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಒಪ್ಪಂದದ ರೂಪದಲ್ಲಿದ್ದ ಇದು ಈಗ ನಿಯಂತ್ರಕವೂ ಆಗಿದೆ.
ಸೈಬರ್ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಕಾಯ್ದೆ, ನಿಯಂತ್ರಣ (EU) 2024/2847, ಡಿಸೆಂಬರ್ 10, 2024 ರಂದು ಜಾರಿಗೆ ಬಂದಿತು ಮತ್ತು ಹಂತ ಹಂತವಾಗಿ ಜಾರಿಗೆ ಬಂದಿತು. ಇದು ಡಚ್ ಸೈಬರ್ ಸೆಕ್ಯುರಿಟಿ ಕಾಯ್ದೆಯ ಜೊತೆಗೆ ಇರುತ್ತದೆ , ಇದು ಉತ್ಪನ್ನಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಸಂಸ್ಥೆಯನ್ನು ಉದ್ದೇಶಿಸುತ್ತದೆ. ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿಕೊಳ್ಳಲಾದ ದುರ್ಬಲತೆಗಳು ಮತ್ತು ಕಲೆಯಲ್ಲಿ ತೀವ್ರ ಘಟನೆಗಳಿಗೆ ವರದಿ ಮಾಡುವ ಬಾಧ್ಯತೆಗಳು. 14 CRA ಸೆಪ್ಟೆಂಬರ್ 11, 2026 ರಿಂದ ಅನ್ವಯಿಸುತ್ತದೆ; ಅನುಸರಣಾ ಮೌಲ್ಯಮಾಪನ ಸಂಸ್ಥೆಗಳ ಅಧಿಸೂಚನೆಯ ಮೇಲಿನ ನಿಬಂಧನೆಗಳು 11 ಜೂನ್ 2026 ರಿಂದ; ಪೂರ್ಣವಾಗಿ ನಿಯಂತ್ರಣ ಡಿಸೆಂಬರ್ 11, 2027 ರಿಂದ (ಕಲೆ. 71 CRA). ಅನೆಕ್ಸ್ I CRA ತಯಾರಕರು ಉತ್ಪನ್ನದಲ್ಲಿನ ಘಟಕಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ದಾಖಲಿಸಲು ಅಗತ್ಯವಿದೆ, ಇದರಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಮತ್ತು ಯಂತ್ರ-ಓದಬಲ್ಲ ಸ್ವರೂಪದಲ್ಲಿ ಕನಿಷ್ಠ ಉನ್ನತ ಮಟ್ಟದ ಅವಲಂಬನೆಗಳನ್ನು ಒಳಗೊಂಡ ಸಾಫ್ಟ್ವೇರ್ ಬಿಲ್ ಅನ್ನು ರಚಿಸುವುದು ಸೇರಿದೆ. ಇದನ್ನು ಪ್ರಕಟಿಸಬೇಕಾಗಿಲ್ಲ; ಮಾರುಕಟ್ಟೆ ಕಣ್ಗಾವಲು ಅಧಿಕಾರಿಗಳು ಇದನ್ನು ವಿನಂತಿಸಬಹುದು.
ವಾಣಿಜ್ಯ ಚಟುವಟಿಕೆಯ ಹೊರಗೆ ಸರಬರಾಜು ಮಾಡಲಾದ ಉಚಿತ ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಸಾಫ್ಟ್ವೇರ್ CRA ಯ ಹೊರಗೆ ಬರುತ್ತದೆ. ನಿಯಂತ್ರಣವು ಓಪನ್-ಸೋರ್ಸ್ ಸಾಫ್ಟ್ವೇರ್ ಸ್ಟೀವರ್ಡ್ ಅನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ - ವಾಣಿಜ್ಯ ಚಟುವಟಿಕೆಗಳಿಗೆ ಉದ್ದೇಶಿಸಲಾದ ಓಪನ್ ಸೋರ್ಸ್ ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಗೆ ನಿರಂತರ ಬೆಂಬಲ ನೀಡುವ ಕಾನೂನುಬದ್ಧ ವ್ಯಕ್ತಿ - ಕಲೆಯಲ್ಲಿ ಹಗುರವಾದ ಬಾಧ್ಯತೆಗಳೊಂದಿಗೆ. 24 CRA: ದಾಖಲಿತ ಸೈಬರ್ ಭದ್ರತಾ ನೀತಿ, ಮಾರುಕಟ್ಟೆ ಕಣ್ಗಾವಲು ಅಧಿಕಾರಿಗಳೊಂದಿಗೆ ಸಹಕಾರ ಮತ್ತು ವರದಿ ಮಾಡುವಿಕೆ. ನೀವು ಓಪನ್ ಸೋರ್ಸ್ ಅನ್ನು ವಾಣಿಜ್ಯೀಕರಿಸಿದರೆ ಅಥವಾ ಇತರರು ವಾಣಿಜ್ಯೀಕರಿಸುವ ಯೋಜನೆಗೆ ಹಣಕಾಸು ಒದಗಿಸಿದರೆ, ನೀವು ಯಾವ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಸ್ಥಾಪಿಸಿ. ಆಯೋಗವು ಜುಲೈ 27, 2026 ರಂದು ತನ್ನ ಮೊದಲ ಮಾರ್ಗದರ್ಶನವನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿತು: ಸೈಬರ್ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಕಾಯ್ದೆ (CRA) ಅನ್ವಯದ ಕುರಿತು ಆಯೋಗದ ಮಾರ್ಗದರ್ಶನ, ಇದನ್ನು ಸಂವಹನ C(2026) 5252 ಗೆ ಲಗತ್ತಿಸಲಾಗಿದೆ, ಇದು ಉಚಿತ ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಸಾಫ್ಟ್ವೇರ್ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಬಂದಾಗ ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ ಪರಿಹರಿಸುತ್ತದೆ. ಸಾಫ್ಟ್ವೇರ್ ಬಿಲ್ನ ಸಾಮಗ್ರಿಗಳಿಗೆ ಸ್ವರೂಪವನ್ನು ಸೂಚಿಸುವ ಯಾವುದೇ ಅನುಷ್ಠಾನ ಕಾಯ್ದೆಯನ್ನು ಅಳವಡಿಸಲಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಯಂತ್ರಣದ ಸ್ವಂತ ಮಾನದಂಡ - ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ, ಯಂತ್ರ-ಓದಬಲ್ಲ ಸ್ವರೂಪ - ಸದ್ಯಕ್ಕೆ ಅಳತೆಯಾಗಿ ಉಳಿದಿದೆ.
CI ನಲ್ಲಿ ನಡೆಸಲಾಗುವ ಸಾಫ್ಟ್ವೇರ್ ಸಂಯೋಜನೆ ವಿಶ್ಲೇಷಣೆಯು ಅನುಸರಣೆ, ಪರವಾನಗಿ ಪರಿಶೀಲನೆ ಮತ್ತು ಶ್ರದ್ಧೆಯನ್ನು ಪೂರೈಸುವ ದಾಸ್ತಾನುಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಉತ್ಪಾದಿಸುತ್ತದೆ. ಅಂತಹ ಪರಿಕರಗಳು ಮಾರಾಟಗಾರರ ಕೋಡ್ ಅನ್ನು ತಪ್ಪಿಸುತ್ತವೆ, ಡ್ಯುಯಲ್-ಪರವಾನಗಿ ಪಡೆದ ಯೋಜನೆಗಳನ್ನು ತಪ್ಪಾಗಿ ಗುರುತಿಸುತ್ತವೆ ಮತ್ತು ಪರವಾನಗಿಯ ಷರತ್ತುಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಿಲ್ಲ: ಔಟ್ಪುಟ್ ಅನ್ನು ವಿಮರ್ಶೆಯ ಪ್ರಾರಂಭವೆಂದು ಪರಿಗಣಿಸಿ, ವಿಮರ್ಶೆಯಲ್ಲ.
ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಕೋಡ್ ಅನ್ನು ಪ್ರಕಟಿಸಿದರೆ: CLA ಗಳು ಮತ್ತು DCO
ಕೋಡ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮತ್ತು ಹೊರಗಿನ ಕೊಡುಗೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಕಂಪನಿಯು ತಾನು ವಿಲೀನಗೊಳ್ಳುವ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ತಿಳಿದಿರಬೇಕು. ಕೊಡುಗೆದಾರರ ಪರವಾನಗಿ ಒಪ್ಪಂದವು ಯೋಜನೆ ಮತ್ತು ಕೊಡುಗೆದಾರರ ನಡುವಿನ ಒಪ್ಪಂದವಾಗಿದ್ದು, ಸಾಮಾನ್ಯವಾಗಿ ವಿಶಾಲವಾದ ಹಕ್ಕುಸ್ವಾಮ್ಯ ಪರವಾನಗಿ ಮತ್ತು ಎಕ್ಸ್ಪ್ರೆಸ್ ಪೇಟೆಂಟ್ ಪರವಾನಗಿಯನ್ನು ನೀಡುತ್ತದೆ, ಇದರೊಂದಿಗೆ ಸ್ವಂತಿಕೆ ಮತ್ತು ಅಧಿಕಾರದ ಬಗ್ಗೆ ಖಾತರಿಗಳಿವೆ. ಇದು ಕಂಪನಿಯು ತನ್ನ ಯೋಜನೆಗೆ ನಂತರ ಮರು ಪರವಾನಗಿ ನೀಡಲು ಅಥವಾ ಮುಕ್ತ ಮೂಲದೊಂದಿಗೆ ವಾಣಿಜ್ಯ ಪರವಾನಗಿಗಳನ್ನು ನೀಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದರ ವೆಚ್ಚವು ಘರ್ಷಣೆಯಾಗಿದೆ.
ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಮತ್ತು ಇತರ ಹಲವು ಯೋಜನೆಗಳು ಬಳಸುವ ಡೆವಲಪರ್ ಸರ್ಟಿಫಿಕೇಟ್ ಆಫ್ ಆರಿಜಿನ್ , ಪರವಾನಗಿ ಅನುದಾನವಲ್ಲ ಬದಲಾಗಿ ಹಗುರವಾದ ದೃಢೀಕರಣವಾಗಿದ್ದು, ಪ್ರತಿ ಕಮಿಟ್ಗೆ ಸೈನ್-ಆಫ್ ಲೈನ್ ಆಗಿ ಸೇರಿಸಲ್ಪಟ್ಟಿದೆ, ಇದರಿಂದ ಕೊಡುಗೆದಾರರು ಯೋಜನೆಯ ಪರವಾನಗಿ ಅಡಿಯಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಸಲ್ಲಿಸಬಹುದು. ಕಡಿಮೆ ಹೊರೆ ಮತ್ತು ಕಡಿಮೆ ರಕ್ಷಣಾತ್ಮಕ: ಪೇಟೆಂಟ್ ಪರವಾನಗಿ ಇಲ್ಲ, ಮರು ಪರವಾನಗಿ ಇಲ್ಲ.
ಡ್ಯುಯಲ್ ಲೈಸೆನ್ಸಿಂಗ್ ಅಥವಾ ಭವಿಷ್ಯದ ಅವಶೇಷವು ಸಾಧ್ಯವಾದರೆ, CLA ಬಳಸಿ; ಯೋಜನೆಯು ನಿಜವಾದ ಕಾಮನ್ಸ್ ಆಗಿದ್ದರೆ, DCO ಸಾಮಾನ್ಯವಾಗಿ ಸಾಕು. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ, ನಿಮ್ಮ ಉದ್ಯೋಗ ಮತ್ತು ಗುತ್ತಿಗೆದಾರ ಒಪ್ಪಂದಗಳು ನಿಮ್ಮ ಜನರು ಬರೆಯುವ ಕೋಡ್ನಲ್ಲಿ ಹಕ್ಕುಸ್ವಾಮ್ಯವನ್ನು ನಿಯೋಜಿಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಪ್ರಾಯೋಗಿಕ ನೀತಿ ಪರಿಶೀಲನಾಪಟ್ಟಿ
- ಪ್ರತಿ ಉತ್ಪನ್ನಕ್ಕೆ ಘಟಕ ದಾಸ್ತಾನು ರಚಿಸಿ ಮತ್ತು ಬಿಲ್ಡ್ ಪೈಪ್ಲೈನ್ನಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಿ, ಕೈಯಿಂದ ಅಲ್ಲ.
- ಆಂತರಿಕ ನೀತಿಯನ್ನು ಪ್ರಕಟಿಸಿ: ಅನುಮತಿಸಲಾದ ಪಟ್ಟಿ, ನಿಷೇಧಿತ ಪಟ್ಟಿ ಮತ್ತು ಉಳಿದೆಲ್ಲದಕ್ಕೂ ಅನುಮೋದನೆ ಮಾರ್ಗ.
- ವಿತರಣೆಯಾಗಿ ಏನನ್ನು ಪರಿಗಣಿಸಬೇಕು ಎಂಬುದನ್ನು ಲಿಖಿತವಾಗಿ ವಿವರಿಸಿ — ಆನ್-ಪ್ರಿಮೈಸ್ ಇನ್ಸ್ಟಾಲ್ಗಳು, ಉಪಕರಣಗಳು, ಕಂಟೇನರ್ಗಳು, SDK ಗಳು, ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು, ಫರ್ಮ್ವೇರ್.
- ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನದೊಂದಿಗೆ ರಚಿಸಲಾದ ಗುಣಲಕ್ಷಣ ಫೈಲ್ ಅನ್ನು ರವಾನಿಸಿ.
- ಘಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಮಯದಲ್ಲಿ, ಬಿಡುಗಡೆಯ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ, ವಿನ್ಯಾಸದ ಸಮಯದಲ್ಲಿ ಪರವಾನಗಿ ಆಯ್ಕೆಗಳನ್ನು ಅನುಮೋದಿಸಿ.
- ಒಳಗೊಂಡಿರುವ ಪೇಟೆಂಟ್ ಅನುದಾನಗಳನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು, ಬಾಹ್ಯ ಯೋಜನೆಗಳಿಗೆ ಕೊಡುಗೆಗಳಿಗೆ ಅನುಮೋದನೆ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ ಮತ್ತು ಮೊದಲ ಹೊರಗಿನ ಕೊಡುಗೆಗೆ ಮೊದಲು CLA ಅಥವಾ DCO ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.
- ಐಪಿ ವಾರಂಟಿಗಳು, ಪರಿಹಾರಗಳು ಮತ್ತು ಎಸ್ಕ್ರೊ ನಿಯಮಗಳನ್ನು ಉತ್ಪನ್ನದಲ್ಲಿರುವ ಓಪನ್ ಸೋರ್ಸ್ನೊಂದಿಗೆ ಹೊಂದಿಸಿ.
- ನಿಧಿಸಂಗ್ರಹಣೆ ಅಥವಾ ಮಾರಾಟ ಪ್ರಕ್ರಿಯೆಯ ಮೊದಲು ವಿಮರ್ಶೆಯನ್ನು ನಡೆಸಿ, ಒಂದರ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ.
Law & More ಸಾಫ್ಟ್ವೇರ್ ಕಂಪನಿಗಳು ಮತ್ತು ಅವುಗಳ ಹೂಡಿಕೆದಾರರಿಗೆ ಸಲಹೆ ನೀಡುತ್ತದೆ Eindhoven ಮತ್ತು Amsterdam ಓಪನ್ ಸೋರ್ಸ್ ಅನುಸರಣೆ, ಪರವಾನಗಿ ಪರಿಶೀಲನೆ, ಕೊಡುಗೆದಾರರ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ವಹಿವಾಟಿನಲ್ಲಿ ಓಪನ್ ಸೋರ್ಸ್ ಕಾರ್ಯಪ್ರವಾಹದ ಕುರಿತು.
ಓಪನ್ ಸೋರ್ಸ್ ಸಾಫ್ಟ್ವೇರ್ ಬಳಸುವುದರಿಂದ ನಾವು ನಮ್ಮದೇ ಆದ ಸೋರ್ಸ್ ಕೋಡ್ ಅನ್ನು ಪ್ರಕಟಿಸಬೇಕೇ?
ಕಾಪಿಲೆಫ್ಟ್ ಪರವಾನಗಿ ಅನ್ವಯಿಸಿದರೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಟ್ರಿಗರ್ ಮಾಡಿದರೆ ಮಾತ್ರ. ಅನುಮತಿ ಪರವಾನಗಿಗಳು ಎಂದಿಗೂ ಅದನ್ನು ಕೇಳುವುದಿಲ್ಲ. ಕಾಪಿಲೆಫ್ಟ್ ಕೋಡ್ ಹೊಂದಿರುವ ಕೆಲಸವನ್ನು ನೀವು ವಿತರಿಸಿದಾಗ ಕಾಪಿಲೆಫ್ಟ್ ಪರವಾನಗಿಗಳು ಅದನ್ನು ಕೇಳುತ್ತವೆ ಮತ್ತು AGPL ಅದನ್ನು ನೆಟ್ವರ್ಕ್ ಸೇವೆಯಾಗಿ ನೀಡಲಾಗುವ ಮಾರ್ಪಡಿಸಿದ ಸಾಫ್ಟ್ವೇರ್ಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ. ವಿತರಣೆಯಿಲ್ಲದೆ ಆಂತರಿಕ ಬಳಕೆಯು ಯಾವುದೇ ಬಾಧ್ಯತೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.
MIT ಪರವಾನಗಿಯಂತಹ ಪರವಾನಗಿಯನ್ನು ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ ಸಹಿ ಇಲ್ಲದೆ ಜಾರಿಗೊಳಿಸಬಹುದೇ?
ಹೌದು. ಇದು ವಿಶೇಷವಲ್ಲದ ಹಕ್ಕುಸ್ವಾಮ್ಯ ಪರವಾನಗಿ, ಆದ್ದರಿಂದ ಕಲೆಯಲ್ಲಿನ ಪತ್ರದ ಅವಶ್ಯಕತೆ. 2 Aw ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ನಡವಳಿಕೆಯ ಮೂಲಕ ಸ್ವೀಕಾರ ಸಾಕು. ಡಚ್ ನ್ಯಾಯಾಲಯವು ಷರತ್ತುಗಳನ್ನು ಪಾಲಿಸದಿರುವುದನ್ನು ನೀಡಲಾದ ಅನುಮತಿಯ ಹೊರಗೆ ಬಳಸುವುದಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ, ಇದು ಹಕ್ಕುಸ್ವಾಮ್ಯ ಉಲ್ಲಂಘನೆಯಾಗುತ್ತದೆ.
ಡೈನಾಮಿಕ್ ಲಿಂಕ್ ಮಾಡುವುದು GPL ಅನ್ನು ತಪ್ಪಿಸುತ್ತದೆಯೇ?
ಅದು ಹಾಗೆ ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ವಿಶ್ವಾಸಾರ್ಹ ಅಧಿಕಾರವಿಲ್ಲ. ಯಾವುದೇ ಡಚ್ ಅಥವಾ EU ನ್ಯಾಯಾಲಯವು ಈ ಅಂಶವನ್ನು ನಿರ್ಧರಿಸಿಲ್ಲ, ಮತ್ತು ಸ್ಟ್ಯಾಟಿಕ್-ವರ್ಸಸ್-ಡೈನಾಮಿಕ್ ವ್ಯತ್ಯಾಸವು ಡಚ್ ಹಕ್ಕುಸ್ವಾಮ್ಯ ಕಾನೂನಿನಲ್ಲಿ ಯಾವುದೇ ಆಧಾರವನ್ನು ಹೊಂದಿಲ್ಲ, ಅದು ಸಂರಕ್ಷಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲಾಗಿದೆಯೇ ಎಂದು ಕೇಳುತ್ತದೆ. ಸುರಕ್ಷಿತ ವಿಶ್ಲೇಷಣೆಯು ಘಟಕಗಳನ್ನು ಎಷ್ಟು ನಿಕಟವಾಗಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡುತ್ತದೆ; ಅದು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಘಟಕವನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ ಅಥವಾ ಬದಲಾಯಿಸಿ.
ನಾವು SaaS ವ್ಯವಹಾರ: ಕಾಪಿಲೆಫ್ಟ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದೇ?
ಸಂಪೂರ್ಣವಾಗಿ ಅಲ್ಲ. ಹೆಚ್ಚಿನ GPL ವಿತರಣಾ ಬಾಧ್ಯತೆಗಳು ಬಿದ್ದು ಹೋಗುತ್ತವೆ, ಏಕೆಂದರೆ ಹೋಸ್ಟಿಂಗ್ ವಿತರಣೆಯಲ್ಲ. ಆದರೆ AGPL ದೂರಸ್ಥ ಬಳಕೆದಾರರಿಗೆ ಲಭ್ಯವಾಗುವಂತೆ ಮಾರ್ಪಡಿಸಿದ ಸಾಫ್ಟ್ವೇರ್ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, EUPL ನ ಸಂವಹನದ ವ್ಯಾಖ್ಯಾನವು ಕೆಲಸದ ಅಗತ್ಯ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ತಲುಪುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಆನ್-ಪ್ರಿಮೈಸ್ ಏಜೆಂಟ್ ಅಥವಾ ಡೌನ್ಲೋಡ್ ಮಾಡಬಹುದಾದ ಕ್ಲೈಂಟ್ ವಿತರಣೆಯಾಗಿದೆ.
ನಾವು ವರ್ಷಗಳಿಂದ ನಿಯಮಗಳಿಗೆ ಬದ್ಧರಾಗಿಲ್ಲ ಎಂದು ಕಂಡುಕೊಂಡರೆ ಏನಾಗುತ್ತದೆ?
ಅದನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ದಾಖಲಿಸಿ. GPLv3 ಮತ್ತು AGPLv3 ಅಡಿಯಲ್ಲಿ, ಸೂಚನೆಯ ನಂತರ ಪರಿಹಾರ ವಿಂಡೋ ಹಕ್ಕುಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ. GPLv2 ಮರುಸ್ಥಾಪನೆ ಅಡಿಯಲ್ಲಿ, ಹಕ್ಕುದಾರರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಜಾರಿಯು ಅನುಸರಣಾ ಕಾರ್ಯದಲ್ಲಿ ಪರಿಹರಿಸುತ್ತದೆ. ಮುಖ್ಯವಾದ ಮಾನ್ಯತೆಯು ಆರ್ಟ್ ಅಡಿಯಲ್ಲಿ ತಡೆಯಾಜ್ಞೆಯಾಗಿದೆ, ಮರುಸ್ಥಾಪನೆ. 28 Aw ಮತ್ತು ಆರ್ಟ್ ಅಡಿಯಲ್ಲಿ ವೆಚ್ಚದ ಆದೇಶ. 1019h Rv, ಸಾಮಾನ್ಯವಾಗಿ ಹಾನಿಗಳಲ್ಲ.
ಸೈಬರ್ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಕಾಯ್ದೆಯು ನಮ್ಮ SBOM ಅನ್ನು ಪ್ರಕಟಿಸುವ ಅಗತ್ಯವಿದೆಯೇ?
ಇಲ್ಲ. ಅನೆಕ್ಸ್ I CRA ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ, ಯಂತ್ರ-ಓದಬಲ್ಲ ಸ್ವರೂಪದಲ್ಲಿ ಕನಿಷ್ಠ ಉನ್ನತ ಮಟ್ಟದ ಅವಲಂಬನೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ವಸ್ತುಗಳ ಸಾಫ್ಟ್ವೇರ್ ಬಿಲ್ ಅನ್ನು ಬಯಸುತ್ತದೆ ಮತ್ತು ಮಾರುಕಟ್ಟೆ ಕಣ್ಗಾವಲು ಅಧಿಕಾರಿಗಳು ಅದನ್ನು ವಿನಂತಿಸಬಹುದು. ಅದನ್ನು ಪ್ರಕಟಿಸಲು ಯಾವುದೇ ಬಾಧ್ಯತೆಯಿಲ್ಲ. ಈ ನಿಯಂತ್ರಣವು ಡಿಸೆಂಬರ್ 11, 2027 ರಿಂದ ಪೂರ್ಣವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ; ಕಲೆಯಲ್ಲಿ ವರದಿ ಮಾಡುವ ಬಾಧ್ಯತೆಗಳು. 14 CRA 11 ಸೆಪ್ಟೆಂಬರ್ 2026 ರಿಂದ.
