Κώδικας GitHub σε εμπορικό προϊόν: άδειες και τι να ελέγξετε

Χτίζετε ένα προϊόν και βρίσκετε ένα έτοιμο κομμάτι στο GitHub: μια βιβλιοθήκη, ένα πρότυπο, ένα ολόκληρο έργο που κάνει ακριβώς αυτό που χρειάζεστε. Ο Claude προτείνει να το ενσωματώσετε στο έργο σας. Και τότε σταματάτε: ο κώδικας φαίνεται δημόσια διαθέσιμος, αλλά μπορείτε πράγματι να τον χρησιμοποιήσετε, πόσο μάλλον να πουλήσετε ένα προϊόν που τον περιλαμβάνει; Θα μπορούσε ο δημιουργός να στραφεί εναντίον σας αργότερα;

Θα τα εξετάσω με τη σειρά: γιατί ο ανοιχτός κώδικας στο GitHub δεν αποτελεί από μόνος του άδεια, ποιες άδειες σάς επιτρέπουν να χρησιμοποιείτε κώδικα και να πουλάτε ένα προϊόν, ποιοι όροι copyleft μπορούν να απαιτούν αντίστοιχο πηγαίο κώδικα καλυπτόμενου έργου και πώς να ελέγξετε μια άδεια σε ένα λεπτό πριν χρησιμοποιήσετε τον κώδικα. Χωρίς «εξαρτάται από την περίπτωση».

Πρακτικές πληροφορίες για την εργασία με το Ailoot βρίσκονται στην τεκμηρίωση.

Ισχύει ότι αν ο κώδικας βρίσκεται στο GitHub, μπορείτε να τον χρησιμοποιείτε δωρεάν;#

Η βασική παγίδα εδώ είναι η λέξη «ανοιχτός». Μπορείτε να δείτε τον πηγαίο κώδικα, οπότε φαίνεται ότι, αφού δεν ήταν κρυμμένος, επιτρέπεται να τον χρησιμοποιήσετε. Αυτή η λογική είναι λανθασμένη. Το «ανοιχτός για ανάγνωση» και το «αδειοδοτημένος για χρήση» είναι διαφορετικά πράγματα.

Από προεπιλογή, κάθε δημιουργικό έργο, συμπεριλαμβανομένου του κώδικα, προστατεύεται από πνευματικά δικαιώματα από τη στιγμή που δημιουργείται. Μέχρι ο δημιουργός να παραχωρήσει ρητά άδεια, δεν μπορείτε να το χρησιμοποιήσετε. Έτσι το περιγράφει το GitHub στη δική του σελίδα αναφοράς για τις άδειες.

Το δεύτερο επίπεδο είναι το ίδιο το GitHub. Ο κόσμος νομίζει ότι, επειδή συμφώνησε με τους κανόνες του GitHub δημοσιεύοντας κώδικα, μπορεί επίσης να χρησιμοποιεί τον κώδικα άλλων από εκεί. Οι κανόνες λένε ακριβώς το αντίθετο. Κάνοντας ένα αποθετήριο δημόσιο, ο δημιουργός επιτρέπει στους άλλους μόνο να το βλέπουν και να δημιουργούν fork — δηλαδή να φτιάχνουν ένα αντίγραφό του μέσα στο ίδιο το GitHub. Αυτό δεν επιτρέπει τη χρήση του κώδικα στη δική σας εργασία.

Οι βασικές λέξεις βρίσκονται στην τελευταία πρόταση: «στο πλαίσιο των λειτουργιών του GitHub» και «τα πρόσθετα δικαιώματα προκύπτουν από μια άδεια». Ένα fork παραμένει μέσα στο GitHub. Μόλις θελήσετε να χρησιμοποιήσετε τον κώδικα στο δικό σας προϊόν, πόσο μάλλον να το πουλήσετε, χρειάζεστε ξεχωριστή άδεια από τον δημιουργό. Χωρίς άδεια, δεν υπάρχει δικαίωμα — ακόμη κι αν ο κώδικας βρίσκεται μπροστά σας σε κοινή θέα.

Τι καθορίζει αν μπορείτε να χρησιμοποιήσετε τον κώδικα κάποιου άλλου;#

Όλα εξαρτώνται από ένα αρχείο. Ένα αποθετήριο που συντηρείται σωστά περιέχει αρχείο άδειας — συνήθως LICENSE, μερικές φορές LICENSE.md ή μια σχετική αναφορά απευθείας στο README. Αυτή είναι η άδεια του δημιουργού, η οποία καθορίζει τους όρους υπό τους οποίους μπορείτε να χρησιμοποιήσετε τον κώδικα. Το GitHub συνήθως εμφανίζει το όνομα της άδειας στην πλαϊνή στήλη της σελίδας του αποθετηρίου, πριν καν ανοίξετε το ίδιο το αρχείο.

Για να μην χαθείτε στη νομική γλώσσα, είναι χρήσιμο να εξετάσετε την άδεια μέσα από τρεις ερωτήσεις για τη δική σας περίπτωση:

1. Μπορείτε να χρησιμοποιήσετε αυτόν τον κώδικα σε εμπορικό προϊόν για το οποίο πληρώνουν οι χρήστες;
2. Μπορείτε να τροποποιήσετε τον κώδικα για τις ανάγκες σας;
3. Πρέπει κατόπιν να ανοίξετε τον πηγαίο κώδικα του προϊόντος σας, ή μπορείτε να τον διατηρήσετε κλειστό;

Σχεδόν όλες οι διαφορές μεταξύ των αδειών καταλήγουν σε διαφορετικές απαντήσεις στην τρίτη ερώτηση. Στις δύο πρώτες, οι δημοφιλείς ανοιχτές άδειες συνήθως λένε «ναι»: χρησιμοποιήστε τον, τροποποιήστε τον, πουλήστε τον. Όμως το αν η άδεια θα σας υποχρεώσει να ανοίξετε τον δικό σας κώδικα είναι το σημείο όπου σκοντάφτει ο κόσμος. Στη συνέχεια, θα εξετάσουμε τους βασικούς τύπους με βάση αυτές τις τρεις ερωτήσεις.

Ποιες άδειες σάς επιτρέπουν να χρησιμοποιείτε κώδικα και να πουλάτε ένα προϊόν;#

Ας ξεκινήσουμε με τα καλά νέα. Για κάποιον που φτιάχνει ένα προϊόν προς πώληση, η καλύτερη επιλογή είναι μια ομάδα αδειών που ονομάζονται επιτρεπτικές. Υπάρχουν αρκετές, αλλά οι τρεις πιο συνηθισμένες είναι οι MIT, Apache 2.0 και BSD. Και στις τρεις, η απάντηση στις δύο πρώτες ερωτήσεις είναι «ναι», ενώ μπορείτε να διατηρήσετε κλειστό τον δικό σας πηγαίο κώδικα.

Η πιο συνηθισμένη και απλή είναι η MIT. Το κείμενό της χωρά σε μία παράγραφο.

Με απλά λόγια, η MIT σάς επιτρέπει να κάνετε σχεδόν τα πάντα με τον κώδικα, συμπεριλαμβανομένης της πώλησης του προϊόντος και της διατήρησης κλειστού του δικού σας πηγαίου κώδικα. Η μόνη υποχρέωση είναι να συμπεριλάβετε το κείμενο της άδειας και τη γραμμή αναφοράς δημιουργού. Τα Babel, .NET και Rails, για παράδειγμα, διατίθενται με άδεια MIT, οπότε σχεδόν σίγουρα έχετε ήδη χρησιμοποιήσει κώδικα με αυτή την άδεια.

Το Apache 2.0 λειτουργεί παρόμοια, αλλά προσθέτει δύο σημαντικά σημεία. Πρώτον, ρητή προστασία από αξιώσεις ευρεσιτεχνίας: οι δημιουργοί του κώδικα υπόσχονται να μην σας μηνύσουν για ευρεσιτεχνίες πάνω σε αυτόν τον κώδικα. Δεύτερον, μερικές ακόμη τυπικές απαιτήσεις χρήσης.

Το BSD (στις εκδόσεις των 2 και 3 ρητρών) είναι ουσιαστικά παρόμοιο με το MIT: χρησιμοποιήστε το, τροποποιήστε το, πουλήστε το, διατηρήστε την ειδοποίηση πνευματικών δικαιωμάτων. Έχω συγκεντρώσει και τις τρεις άδειες σε πίνακα, για να δείτε με μια ματιά τη διαφορά.

Πώς να το ερμηνεύσετε στη δική σας περίπτωση: αν δείτε MIT, Apache 2.0 ή BSD στον κώδικα κάποιου άλλου, μπορείτε να είστε ήσυχοι: μπορείτε να τον χρησιμοποιήσετε σε εμπορικό προϊόν, να τον τροποποιήσετε και να διατηρήσετε κλειστό τον δικό σας πηγαίο κώδικα. Αρκεί να μην αφαιρέσετε το αρχείο άδειας και την αναφορά δημιουργού από το μέρος που χρησιμοποιήσατε.

Πώς εφαρμόζονται υποχρεώσεις πηγαίου κώδικα GPL και AGPL;#

Το copyleft διατηρεί καλυπτόμενο έργο και παράγωγά του στην ίδια άδεια όταν ισχύουν οι σχετικοί όροι. Στην GPLv3, η διανομή αντιγράφων πηγαίου ή αντικειμενικού κώδικα καλυπτόμενου ή συνδυασμένου παράγωγου έργου απαιτεί συμμόρφωση με άδεια και υποχρεώσεις αντίστοιχου πηγαίου κώδικα. Δεν εφαρμόζεται αυτόματα σε κάθε ανεξάρτητο πρόγραμμα του ίδιου προϊόντος ή server.

Στο παράδειγμα web υπηρεσίας, η φιλοξενία βιβλιοθήκης GPL στον δικό σας server χωρίς παροχή αντιγράφων δεν απαιτεί από μόνη της δημοσίευση όλης της υπηρεσίας. Διανομή καλυπτόμενης συνδυασμένης εφαρμογής σε πελάτες μπορεί να ενεργοποιεί υποχρεώσεις GPL· ελέγξτε ενσωμάτωση και άδεια πριν αποφασίσετε ποιος πηγαίος κώδικας τη συνοδεύει. Browser client που παραδίδεται σε χρήστες είναι χωριστό ζήτημα διανομής.

Η AGPLv3 προσθέτει όρο δικτύου: αν τροποποιήσετε πρόγραμμα και χρήστες αλληλεπιδρούν απομακρυσμένα με εκείνη την έκδοση, πρέπει να τους προσφέρει εμφανώς τον αντίστοιχο πηγαίο κώδικά της. Αυτό είναι ακριβέστερο από τον ισχυρισμό ότι απλή φιλοξενία οποιουδήποτε στοιχείου AGPL ανοίγει κάθε ανεξάρτητο μέρος υπηρεσίας.

Για ιδιόκτητο προϊόν, εξετάστε καλυπτόμενο έργο, πώς συνδυάζονται στοιχεία, αν διανέμονται αντίγραφα και αν εφαρμόζεται αλληλεπίδραση δικτύου AGPL. Επιλέξτε συμβατή επιτρεπτική εναλλακτική ή λάβετε χωριστή άδεια αν δεν μπορείτε να τηρήσετε τις υποχρεώσεις. Η ίδια η εμπορική χρήση επιτρέπεται· το ζήτημα είναι συμμόρφωση με πραγματική άδεια και ενσωμάτωση.

Τι πρέπει να κάνετε αν το αποθετήριο δεν έχει καθόλου αρχείο άδειας;#

Ένα συνηθισμένο λάθος είναι να υποθέτει κανείς ότι, αν δεν υπάρχει άδεια, δεν υπάρχουν περιορισμοί και μπορεί να χρησιμοποιήσει τον κώδικα ελεύθερα. Ισχύει το αντίθετο. Η απουσία άδειας δεν είναι άδεια χρήσης· από προεπιλογή σημαίνει ότι δεν υπάρχει άδεια. Ο κώδικας χωρίς άδεια εξακολουθεί να προστατεύεται πλήρως από τα πνευματικά δικαιώματα του δημιουργού και δεν μπορείτε να τον αγγίξετε.

Ισχύει και πάλι ο κανόνας από τον οποίο ξεκινήσαμε: από προεπιλογή, ο κώδικας προστατεύεται από πνευματικά δικαιώματα και χωρίς ρητή άδεια δεν μπορείτε να τον αντιγράψετε, να τον τροποποιήσετε ή να τον διανείμετε. Η δυνατότητα προβολής και δημιουργίας fork μέσα στο GitHub δεν παρακάμπτει αυτό το εμπόδιο — δεν σας παραχωρεί το δικαίωμα να χρησιμοποιήσετε τον κώδικα στο δικό σας προϊόν.

Τι να κάνετε στην πράξη αν ο κώδικας δεν έχει άδεια αλλά τον χρειάζεστε πραγματικά:

1. Γράψτε στον δημιουργό. Απευθείας στην ενότητα συζητήσεων του αποθετηρίου ή μέσω ηλεκτρονικού ταχυδρομείου, ρωτήστε αν μπορείτε να χρησιμοποιήσετε τον κώδικα και με ποιους όρους. Μερικές φορές ο δημιουργός απλώς ξέχασε να προσθέσει άδεια και θα την προσθέσει αν του το ζητήσετε.
2. Βρείτε αντικατάσταση. Για σχεδόν κάθε εργασία υπάρχει ένα δεύτερο, τρίτο ή δέκατο παρόμοιο αποθετήριο — ανάμεσά τους θα βρείτε ένα με κατάλληλη άδεια MIT ή Apache.
3. Μην τον χρησιμοποιήσετε. Αν δεν έχετε άδεια και δεν υπάρχει αντικατάσταση, ο κώδικας δεν είναι δικός σας και δεν μπορείτε να τον βάλετε σε προϊόν που σκοπεύετε να πουλήσετε. Ο πειρασμός να σκεφτείτε «ποιος θα το μάθει;» καταλήγει άσχημα ακριβώς όταν το προϊόν αρχίζει να αποφέρει χρήματα και να τραβά την προσοχή.

Τι γίνεται αν ο ίδιος ο Claude πρόσθεσε κώδικα κάποιου άλλου στο έργο;#

Υπάρχει κι εδώ ένα δεύτερο επίπεδο, το οποίο εύκολα συγχέεται με το πρώτο. Άλλο είναι να επισκεφθείτε ένα αποθετήριο και να αντιγράψετε ένα αρχείο από εκεί: τότε όλα όσα αναφέρθηκαν παραπάνω για την άδεια αποτελούν άμεση υποχρέωσή σας. Και άλλο είναι να γράφει κώδικα για εσάς ο Claude ως απάντηση σε ένα αίτημα.

Στις συνηθισμένες περιπτώσεις, το AI παράγει δικό του κείμενο, διαμορφωμένο για την εργασία σας, αντί να αντιγράφει αρχείο κάποιου άλλου. Τότε το ερώτημα μετατοπίζεται σε διαφορετικό πεδίο: σε ποιον ανήκει ο παραγόμενος κώδικας και μπορείτε να τον πουλήσετε; Είναι μεγάλο θέμα από μόνο του και το κάλυψα σε άρθρο για το σε ποιον ανήκει ο κώδικας που γράφτηκε από AI.

Υπάρχει, όμως, μια εξαίρεση που πρέπει να έχετε υπόψη. Μερικές φορές το AI παράγει ένα αναγνωρίσιμο τμήμα κώδικα κάποιου άλλου σχεδόν λέξη προς λέξη — μια ολόκληρη συνάρτηση από γνωστή βιβλιοθήκη. Σε αυτή την περίπτωση, εξακολουθεί να ισχύει η άδεια της βιβλιοθήκης, ανεξάρτητα από το ποιος πάτησε φυσικά τα πλήκτρα. Γι’ αυτό τα μεγάλα έτοιμα τμήματα που ενσωμάτωσε ο Claude αυτούσια πρέπει να ελέγχονται σαν να τα είχατε αντιγράψει εσείς.

Πώς να ελέγξετε μια άδεια πριν χρησιμοποιήσετε κώδικα: βήματα που πρέπει να ακολουθήσετε#

Ας τα συγκεντρώσουμε σε μια σύντομη λίστα ελέγχου για κάθε κώδικα τρίτων, πριν τον ενσωματώσετε στο έργο σας. Ακολουθήστε τα βήματα από πάνω προς τα κάτω.

1. Βρείτε το όνομα της άδειας στη σελίδα του αποθετηρίου

   Ανοίξτε το αποθετήριο στο GitHub. Το όνομα της άδειας εμφανίζεται συνήθως στη δεξιά στήλη ή κάτω από τη λίστα αρχείων — για παράδειγμα, «MIT License», «Apache-2.0» ή «GPL-3.0». Αν είναι κενό και δεν υπάρχει αρχείο άδειας, αυτό είναι ήδη προειδοποιητικό σημάδι· επιστρέψτε σε αυτό στο τελευταίο βήμα.

2. Ανοίξτε το ίδιο το αρχείο άδειας

   Βρείτε το LICENSE, LICENSE.md ή COPYING στη λίστα αρχείων και ανοίξτε το. Βεβαιωθείτε ότι το όνομα ταιριάζει με αυτό που εμφανίζεται στην πλαϊνή στήλη και ότι η άδεια ισχύει για τον κώδικα που χρησιμοποιείτε, όχι μόνο για ξεχωριστό μέρος του αποθετηρίου.

3. Προσδιορίστε τον τύπο: επιτρεπτική ή copyleft

   Οι MIT, Apache 2.0 και BSD είναι επιτρεπτικές· μπορείτε να χρησιμοποιήσετε τον κώδικα σε κλειστό εμπορικό προϊόν. Οι GPL και AGPL είναι copyleft· ελέγξτε καλυπτόμενο έργο, διανομή και τυχόν δικτυακό όρο AGPL πριν καθορίσετε υποχρεώσεις πηγαίου κώδικα. Το όνομα μόνο δεν τεκμηριώνει ποια ανεξάρτητα στοιχεία καλύπτονται.

4. Συγκρίνετέ την με τη δική σας περίπτωση

   Απαντήστε σε τρεις ερωτήσεις: πουλάτε το προϊόν, τροποποιείτε τον κώδικα και θέλετε να διατηρήσετε κλειστό τον πηγαίο κώδικα; Οι MIT, Apache και BSD είναι κατάλληλες για ένα κλειστό προϊόν προς πώληση. Για GPL και AGPL, προσδιορίστε ποιο καλυπτόμενο ή συνδυασμένο έργο χρειάζεται αντίστοιχο πηγαίο κώδικα και πότε ενεργοποιείται η υποχρέωση· αξιολογήστε αν πληροίτε τους όρους.

5. Χωρίς άδεια, μην τον χρησιμοποιήσετε

   Αν δεν υπάρχει αρχείο άδειας και το README δεν λέει τίποτα για την άδεια χρήσης, δεν μπορείτε να χρησιμοποιήσετε τον κώδικα. Γράψτε στον δημιουργό και ζητήστε άδεια ή βρείτε ένα ισοδύναμο με κατάλληλη άδεια. «Είναι δημόσια διαθέσιμος» δεν σημαίνει ότι έχετε άδεια.

Αυτός ο έλεγχος φαίνεται κουραστικός μέχρι την πρώτη φορά που το προϊόν σας μεγαλώνει, αρχίζει να αποφέρει χρήματα και κάποιος ρωτά για τον κώδικα τρίτων που περιέχει. Δύο λεπτά στην αρχή κοστίζουν λιγότερο από το να αντιμετωπίσετε μια διαφορά αργότερα. Καλύπτω ξεχωριστά τι να κάνετε με το προϊόν σας μετά από αυτό, ώστε να μην μείνει στάσιμο μετά την κυκλοφορία: Έφτιαξα ένα προϊόν με AI· τι ακολουθεί.

Μεταβείτε στο Ailoot.