Cum să-mi protejez tema premium WordPress pentru aplicație de copiere?
Se spune că WordPress este GPL și, prin urmare, toate pluginurile și temele create cu el ar trebui să fie GPL. Bine, dar dacă am petrecut trei luni codificând o temă extrem de complexă pentru o aplicație cu intenția de a o vinde în mod repetat pentru profit, cum ar fi o temă pentru sistemul de programare al unui cabinet medical, atunci cum îmi pot proteja investiția, chiar și într-o măsură moderată?

Pe lângă celelalte două sugestii, există o altă abordare posibilă: mutați toată funcționalitatea aplicației personalizate în afara Temelor, într-un serviciu web găzduit, la care Tema se conectează prin intermediul unui cheie API. În acest fel, redistribuirea Temei în sine nu afectează modelul de afaceri bazat pe aplicația personalizată, deoarece aplicația ar necesita Tema plus o cheie API validă.
Această abordare poate sau nu să funcționeze, în funcție de natura aplicației personalizate, dar este un model de succes pentru unele plugin-uri comerciale și este complet conform GPL.

Pe lângă faptul că necesită o cheie API pentru a funcționa, am văzut și cerința de a avea una pentru actualizare. Acest lucru face ca aplicația să fie complet funcțională, dar orice actualizare necesită o cheie validă. Acest lucru vă permite să oferiți actualizări cu un singur clic celor care plătesc pentru aplicație.

Indiferent de aspectele legale, eu privesc lucrurile în felul următor: scrie cod de calitate și oferă suport bun, iar oamenii vor veni la tine. Există multe teme premium care sunt GPL și se descurcă excelent. Uită-te la WooThemes, Headway, StudioPress (Genesis) pentru a numi doar câteva companii care creează teme de înaltă calitate, complet GPL, și își câștigă existența făcând acest lucru.
În opinia mea, o parte din succesul lor se datorează oferirii unui suport de calitate și stabilirii unor prețuri accesibile atât pentru ei, cât și pentru clienți.
Cred că ideea „Dacă fac tema mea GPL, cineva o va fura și toată munca mea va fi pierdută” este pur și simplu falsă. Sigur, poate cineva o va fura și o va distribui gratuit. Dar dacă oferi suport, oamenii vor veni în continuare la tine pentru a o achiziționa. Nu mai vorbim de faptul că știu exact ce primesc. Temele premium gratuite/furate (și unele ne-premium) conțin adesea programe spyware/malware. Aș prefera să plătesc pe cineva pentru ceva care funcționează decât să mă confrunt cu un virus mai târziu.
Un ultim exemplu (și poate preferatul meu) este Theme Hybrid al lui Justin Tadlock. El o lansează gratuit sub licență GPL și percepe 25 de dolari pe an pentru suport. Un preț pe care îl plătesc cu drag, deoarece suportul său este extraordinar.
Concluzia este că dacă creezi un mediu de încredere, oamenii vor veni.
O altă soluție ar putea fi o abordare terțiară: $X pentru produs, $Y pentru suport, $Z pentru add-on-uri suplimentare.
PS: Personal, nu cumpăr nimic pentru WordPress care nu este complet GPL.

"Temele premium gratuite/furate (și unele non-premium) conțin adesea programe spion/malware. Prefer să plătesc pe cineva pentru ceva ce știu că funcționează decât să mă confrunt cu un virus mai târziu." Punct de vedere extrem de bun!

Dacă dorești să aplici anumite restricții legale asupra produsului tău și să rămâi în conformitate cu practicile GPL ale WordPress, cea mai bună opțiune este licențierea separată:
- Codul PHP sub licența GPL;
- alte componente (cum ar fi designul, imaginile, CSS) sub licența aleasă de tine.

Ce se întâmplă dacă am inclus în temă unele fișiere PHP care nu încarcă antetul WordPress bootstrap și nu folosesc niciun API din WP Codex? Ar trebui ca și acelea să fie GPL?

@Volomike Aspectele legate de GPL în contextul PHP sunt o zonă destul de gri și de obicei sunt mai degrabă chestiuni de opinie decât fapte legale. După părerea mea personală, cel mai puțin confuz și problematic este să ai tot codul PHP sub licență GPL[-compatibilă].

Ceva ce nu a fost menționat în acest fir sunt subiectele Criptare și Ofuscare.
Criptarea codului tău cu IonCube sau Zend Encoder sunt doar două metode populare de protecție pentru teme și/sau plugin-uri pe care le-am văzut în utilizare.
Problema cu criptarea este că, cu suficientă voință și dorință, poți decripta fișierele înapoi în starea lor originală. Uneori, rezultatele pot varia, iar în funcție de cât de bine este înțeleasă metodologia de criptare, se va determina adesea succesul sau eșecul în decriptarea fișierelor.
Există indivizi necinstiți care au devenit destul de pricepuți în arta decriptării fișierelor de la IonCube, Zend și alții. Pentru persoana obișnuită, deranjul adesea depășește valoarea.
Următoarea metodologie este ofuscarea, pe care am văzut-o rar sau deloc utilizată. În opinia mea, poate face aproape imposibilă descifrarea fișierelor care au fost ofuscate corespunzător, ceea ce înseamnă, de asemenea, că nu poți edita fișierele cu ofuscare în mod tradițional și trebuie să păstrezi copii ale fișierelor master pentru orice modificări, actualizări, remedieri de erori, ceea ce de obicei nu este o problemă.
Totuși, o combinație între criptare și ofuscare ar face aproape imposibil, dacă nu chiar absolut imposibil, să fie furat codul tău proprietar. Nu va opri oamenii să-l folosească, presupunând că funcționează, dar îi va opri să-l modifice sau să copie funcționalități pentru a-și crea propriul produs similar.
Utilizarea unei chei API, așa cum am menționat mai sus, este cealaltă metodă excelentă de a ajuta la securizarea produselor tale, DAR există un dezavantaj la această metodă, și anume că prin stocarea unei părți din logica aplicației în afara temei sau plugin-ului original înseamnă că utilizatorul trebuie să se conecteze la serverul tău pentru a prelua acea logică, pentru ca tema sau plugin-ul să funcționeze corespunzător.
Asta sună ca un lucru minunat și este în mare parte, dar ia în considerare ce se întâmplă dacă serverul tău ar fi offline chiar și pentru o oră sau două. Ar face asta tema sau plugin-ul inutilizabil? Fără îndoială că ar face-o. Apoi, ar trebui să te gândești la ce fel de impact ar avea acest lucru asupra utilizatorului final.
Ai putea ocoli acest lucru, cât mai bine posibil, prin a avea unele locații de server de rezervă care să gestioneze distribuirea logicii tale API, cum ar fi utilizarea serviciilor bazate pe cloud de la companii de încredere precum Amazon și altele, în plus față de accesarea directă a logicii de pe serverul tău.
Apoi, ar trebui să evaluezi costul în overhead și, în cele din urmă, valoarea pentru tine. Merită cu adevărat timpul? Cred că este specific și dependent de proiect, dar sunt considerații pe care trebuie să le faci în cele din urmă.
Concluzia este că majoritatea oamenilor care vor pirata sau fura produsul, tema sau plugin-ul tău sunt cel mai probabil cei care nu ar fi cumpărat niciodată produsul, tema sau plugin-ul tău în primul rând.
Se crede adesea că există trei tipuri de oameni în mediul nostru:
Cineva care va fura și pirata orice, întotdeauna.
Cineva care va încerca să fure sau să pirateze orice, înainte de a cumpăra un produs.
Cineva care va cumpăra pur și simplu produsul tău, pentru că este lucrul corect de făcut și cel mai sigur mod de a garanta că produsul tău funcționează conform descrierii.
Deși pirateria și furtul de teme și plugin-uri sunt frecvente pe internet, numărul de persoane care folosesc temele sau plugin-urile tale suficient de consecvent pentru a justifica orice daună la veniturile tale este oarecum minuscul.
Nu înseamnă că nu ar trebui să facem tot ce ne stă în putință pentru a minimiza acea pierdere, dar adesea eforturile tale ar fi mai bine direcționate către crearea mai multor produse și/sau promovarea în continuare a produselor existente, precum și diversificarea modului în care oferi produsul tău.
Cu ritmul în care multe produse fie se actualizează cu noi funcționalități, fie remediază erori, adesea face produsele piratate anterioare inutile sau nu la fel de fructuoase ca dacă ar fi fost plătite.
Așa cum am menționat mai sus, criptarea și ofuscarea codului, combinate, sunt două metode care merită investigații suplimentare, în plus față de integrarea în stil API, pentru a ajuta la securizarea produselor, temelor sau plugin-urilor tale în cel mai bun mod posibil.

Te rog să nu sugerezi asta, licența GPL impune ca codul să fie „forma preferată a lucrării pentru efectuarea modificărilor asupra ei”. Asta înseamnă fără ofuscare sau criptare.

Cu ce este diferit față de utilizarea unei chei API? Pe care, dacă nu ai observat, a fost răspunsul acceptat! Găzduirea unei părți din logica aplicației pe un server terț și reținerea ei ca urmare este efectiv același lucru cu criptarea sau ofuscarea. Dacă criptezi sau ofuschezi cod proprietar care nu include funcții specifice API-ului WordPress, atunci nu văd care ar fi problema.

Dacă îl vinzi, atunci nu trebuie să fie sub licența GPL, deoarece nu poți să-l vinzi pe site-urile WordPress. Poți să-l distribuți singur sub orice licență dorești. Restricția GPL se aplică doar pentru depozitele Wordpress.org și, având în vedere că nu poți să-l vinzi pe Wordpress.org, poți alege orice licență dorești.
