मैं अपने प्रीमियम वर्डप्रेस ऐप थीम को कॉपी करने से कैसे बचा सकता हूं?


32

वे कहते हैं कि वर्डप्रेस जीपीएल है, और इसलिए इसके साथ किए गए सभी प्लगइन्स और थीम जीपीएल होने चाहिए। ठीक है, लेकिन अगर मैंने इसे लाभ के लिए बार-बार बेचने के इरादे से एक अत्यंत जटिल ऐप थीम कोडिंग में तीन महीने बिताए, जैसे कि मेडिकल ऑफिस शेड्यूलिंग सिस्टम थीम, तो मैं अपने निवेश की रक्षा कैसे कर सकता हूं, अगर एक मामूली राशि भी?


3
सरल: नहीं किया जा सकता।
कैसर

मेरी माफी अगर मैं गलत हूं ... तो यह सच है कि वर्डप्रेस एक मुफ्त जीपीएल सेमी है लेकिन आपके द्वारा बनाया गया कोई भी विषय कॉपीराइट कानूनों के अधीन है जैसा कि कुछ भी है ... आप जिस चीज की बिक्री करते हैं या किसी भी अधिकार का दावा करते हैं वह वर्डप्रेस या अन्य है लोग प्लगइन्स इत्यादि
Sagive SEO

1
@Sagive यह WordPress समुदाय में कई लोगों द्वारा माना जाता है कि थीम और प्लगइन्स डेरिवेटिव हैं और उनका कोड GPL के अंतर्गत होना चाहिए। कोई भी इसके खिलाफ जा सकता है, लेकिन यह बहुत से लोगों के लिए खुद को नकारात्मक रोशनी में रखने का एक तेज़ तरीका है और ऐसा कुछ नहीं है जिसे पहले चुनना चाहिए।
23

1
जब तक लोग कॉपी कर सकते हैं वे कॉपी करेंगे, आप इसके उदाहरणों को खोजने के लिए कई अलग-अलग बाजारों में कई उत्पादों को देख सकते हैं, मैं इस पर चिप से सहमत हूं, आपके कोड में एक एपीआई कुंजी का उपयोग होता है, यदि आपका कोड एक कुंजी की उम्मीद करता है और इसमें केवल एक ही एवेन्यू है इसे कोड कॉपी करने की चिंता को नकारता है (और यह जीपीएल के साथ इनलाइन है, इसलिए आपके दोनों आधारों को कवर करता है)।
t31os

1
क्षमा करें, मेरा ब्लडसुगर कम था।
व्रतकेनी

जवाबों:


27

अन्य दो सुझावों के अलावा, एक और संभावित दृष्टिकोण है: अपने सभी कस्टम-ऐप कार्यक्षमता को थीम से बाहर ले जाएं , और एक होस्ट की गई वेब सेवा में , जिसमें थीम एपीआई कुंजी के माध्यम से कनेक्ट होती है । इस तरह, थीम का पुनर्वितरण स्वयं आपके कस्टम ऐप-आधारित व्यवसाय मॉडल को प्रभावित नहीं करता है, क्योंकि ऐप के लिए थीम प्लस वैध एपीआई कुंजी की आवश्यकता होगी ।

यह दृष्टिकोण आपके कस्टम ऐप की प्रकृति के आधार पर काम कर सकता है या नहीं भी कर सकता है, लेकिन यह कुछ व्यावसायिक प्लगइन्स के लिए एक सफल मॉडल है, और पूरी तरह से GPL के अनुरूप है।


4
काम करने के लिए एक एपीआई कुंजी की आवश्यकता के साथ-साथ मैंने एक को अपग्रेड करने की आवश्यकता भी देखी है। यह एप्लिकेशन को पूरी तरह कार्यात्मक बनाता है लेकिन किसी भी अपग्रेड के लिए एक वैध कुंजी की आवश्यकता होती है। यह आपको एप्लिकेशन के लिए भुगतान करने वाले पति को एक क्लिक अपग्रेड प्रदान करने की अनुमति देता है।
ब्रुक।

15

कानूनी रूप से एक तरफ, मैं आमतौर पर इसे इस तरह से देखता हूं, अच्छा कोड लिखता हूं और अच्छा समर्थन प्रदान करता हूं और लोग आपके पास आएंगे। कई प्रीमियम थीम हैं जो जीपीएल हैं और बहुत अच्छा कर रहे हैं। पर देखो WooThemes , प्रगति , StudioPress (उत्पत्ति) बस कुछ ही कंपनियों को लिखने गुणवत्ता, पूरी तरह से जीपीएल विषयों और एक जीवित ऐसा करने बनाना नाम है।

मेरी राय में उनकी कुछ सक्सेस को क्विलिटी सपोर्ट मुहैया कराने और अपने थीम को एक ऐसी रकम पर प्रूव करने का श्रेय दिया जाता है, जिसे वे जीने का खर्च उठा सकते हैं, लेकिन दूसरे लोग उनके लिए भुगतान कर सकते हैं।

मुझे लगता है कि "अगर मैं अपनी थीम जीपीएल बनाता हूं तो कोई इसे चोरी करने जा रहा है और मेरा सारा काम चल जाएगा" बस झूठ है। ज़रूर, हो सकता है कि कोई इसे चुरा लेगा, दे देना। लेकिन अगर आप समर्थन की पेशकश करते हैं तो लोग अभी भी आपके पास आएंगे और इसे प्राप्त करेंगे। इस तथ्य का उल्लेख नहीं करने के लिए कि वे जानते हैं कि उन्हें क्या मिल रहा है। फ्री / प्रीमियम थीम (और कुछ गैर-प्रीमियम वाले) चुराए अक्सर स्पाइवेयर / मैलवेयर होते हैं। मैं इसके बजाय किसी ऐसे व्यक्ति को भुगतान करता हूं जिसे मैं जानता हूं कि बाद में एक वायरस से निपटना चाहिए।

एक अंतिम उदाहरण (और शायद मेरा पसंदीदा) जस्टिन टैडलॉक का थीम हाइब्रिड है , वह इसे जीपीएल के रूप में मुफ्त में जारी करता है और समर्थन के लिए प्रति वर्ष $ 25 का शुल्क लेता है। एक शुल्क मैं ख़ुशी से चुकाता हूँ क्योंकि उसका समर्थन अद्भुत है।

निचला रेखा, यदि आप एक विश्वसनीय वातावरण बनाते हैं और लोग आएंगे।

एक अन्य समाधान एक क्षेत्रीय समाधान होगा, उत्पाद के लिए $ X, समर्थन के लिए $ Y, अतिरिक्त ऐड-ऑन के लिए $ Z

पुनश्च: व्यक्तिगत रूप से मैं वर्डप्रेस के लिए कुछ भी नहीं खरीदता हूं जो पूर्ण-जीपीएल नहीं है।


2
"नि: शुल्क प्रीमियम विषयों (और कुछ गैर-प्रीमियम वाले) को अक्सर स्पाइवेयर / मैलवेयर होते हैं। मैं किसी ऐसे व्यक्ति के लिए भुगतान करता हूं जो मुझे पता है कि काम करता है तो बाद में एक वायरस से निपटें।" बहुत अच्छी बात!
वोलोमाइक

1
लगभग वही जो मैंने लिखा होगा, अगर मुझे कल इसे लिखने की ऊर्जा मिले।
चिप बेनेट 12

6

यदि आप अपने उत्पाद पर कुछ कानूनी प्रतिबंध लगाना चाहते हैं और वर्डप्रेस के GPL प्रथाओं के अनुरूप रहना चाहते हैं तो आपका सबसे अच्छा विकल्प विभाजन लाइसेंस है:

  • GPL के तहत PHP कोड;
  • अपनी पसंद के लाइसेंस के तहत अन्य घटक (जैसे डिजाइन, चित्र, सीएसएस)।

क्या होगा अगर मैंने थीम में कुछ PHP फाइलें शामिल की हैं जो वर्डप्रेस हेडर बूटस्ट्रैप को लोड नहीं करती हैं, और किसी भी WP कोडेक्स एपीआई का उपयोग नहीं करती हैं? क्या उन लोगों को भी जीपीएल होना चाहिए?
Volomike

2
PHP के संदर्भ में @Volomike GPL सामान थोड़े ग्रे क्षेत्र है और चीजें आमतौर पर कानूनी तथ्यों के बजाय राय का विषय हैं। मेरी व्यक्तिगत राय में यह कम से कम भ्रामक और समस्याग्रस्त है कि GPL [-compatible] के तहत सभी PHP कोड हैं।
रारस्ट

1
इस दृष्टिकोण के साथ समस्या यह है कि कस्टम-ऐप कोड PHP में लिखे जाने की संभावना है, इसलिए यदि कोई व्यक्ति आधिकारिक वर्डप्रेस व्याख्या का पालन करना चाहता है कि सभी PHP कोड व्युत्पन्न हैं , तो एक विभाजन लाइसेंस मदद नहीं करेगा।
चिप बेनेट 12

0

इस थ्रेड में जिस चीज़ का उल्लेख नहीं किया गया है, वह है एन्क्रिप्शन और ऑबसेक्शन।

IonCube या Zend एनकोडर के साथ अपने कोड को एन्क्रिप्ट करना, लेकिन संरक्षण विषयों और या प्लगइन्स के दो लोकप्रिय तरीके हैं जो मैंने उपयोग में देखे हैं।

एन्क्रिप्शन के साथ समस्या यह है कि पर्याप्त इच्छा और इच्छा के साथ आप फ़ाइलों को उनके मूल स्थिति में वापस डिक्रिप्ट कर सकते हैं। कभी-कभी परिणाम अलग-अलग होंगे और इस बात पर निर्भर करेगा कि एन्क्रिप्शन पद्धति का प्रकार कितनी अच्छी तरह समझा जाता है, अक्सर फाइलों को डिक्रिप्ट करने में सफलता या विफलता का निर्धारण करेगा।

ऐसे बेईमान व्यक्ति हैं जो आयनॉक्स, ज़ेंड और अन्य से फ़ाइलों को डिक्रिप्ट करने की कला में काफी कुशल हो गए हैं। औसत व्यक्ति के लिए, अक्सर झंझट के लायक परेशानी।

अगली कार्यप्रणाली आपत्तिजनक है जिसे मैंने शायद ही कभी देखा हो। मेरी राय में, यह उचित रूप से बाधित फ़ाइलों को समझने में असंभव के करीब बना सकता है जो बदले में यह भी मतलब है कि आप पारंपरिक तरीके से obfuscation के साथ फ़ाइलों को संपादित नहीं कर सकते हैं और किसी भी संशोधन, अपडेट, बग फिक्स के लिए अपने मास्टर फ़ाइलों की प्रतियां रखने की आवश्यकता है जो आमतौर पर कोई समस्या नहीं है।

हालांकि एन्क्रिप्शन और ऑबफिकेशन दोनों का एक संयोजन इसे असंभव बना देगा अगर असंभव नहीं तो आपका मालिकाना कोड चुरा लें। यह लोगों को इसका उपयोग करने से रोकता है, इसे कार्य मानता है, लेकिन यह लोगों को इसे संशोधित करने या कार्यक्षमता को कॉपी करने से अपने समान उत्पाद बनाने से रोक देगा।

जैसा कि ऊपर उल्लेख किया गया है कि आपके उत्पादों को सुरक्षित करने में मदद करने के लिए अन्य बढ़िया तरीका है एपीआई कुंजी का उपयोग करना, लेकिन इस विधि में एक नकारात्मक पहलू यह है कि मूल विषय या प्लगइन से आपके कुछ एप्लिकेशन लॉजिक को संग्रहीत करने का मतलब है कि उपयोगकर्ता को कनेक्ट करने की आवश्यकता है आपका सर्वर थीम या प्लगइन को ठीक से संचालित करने के लिए उस तर्क को पुनः प्राप्त करता है।

यह एक बहुत अच्छी बात लगती है और यह अधिकांश भाग के लिए है, लेकिन विचार करें कि क्या होता है यदि आपका सर्वर एक या दो घंटे के लिए भी ऑफ़लाइन हो। क्या यह आपके विषय या प्लगइन को बेकार कर देगा? इसमें कोई शक नहीं। फिर आपको विचार करना होगा कि अंत उपयोगकर्ता पर किस तरह का प्रभाव पड़ेगा।

आप इसको दरकिनार कर सकते हैं, जितना संभव हो सके, कुछ असफल सर्वर स्थानों को अपने एपीआई लॉजिक के वितरण जैसे कि अमेज़ॅन जैसी विश्वसनीय कंपनियों से क्लाउड आधारित सेवाओं का उपयोग करने और अपने सर्वर से सीधे लॉजिक एक्सेस करने के अलावा और भी अधिक।

फिर आपको ओवरहेड में लागत और अंततः आपके लिए वजन करने की आवश्यकता होगी। क्या यह वास्तव में समय के लायक है? मुझे लगता है कि यह परियोजना विशिष्ट और आश्रित है, लेकिन विचार को अंततः बनाना चाहिए।

लब्बोलुआब यह है कि ज्यादातर लोग जो आपके उत्पाद, थीम या प्लगइन को पायरेट करेंगे या चुराएंगे, वे सबसे पहले आपके उत्पाद, थीम या प्लगइन को कभी नहीं खरीद पाएंगे।

हमारे वातावरण में अक्सर तीन प्रकार के लोग होते हैं,

  1. कोई है जो चोरी करेगा और कुछ भी पायरेट करेगा, हमेशा।

  2. कोई है जो किसी उत्पाद को खरीदने से पहले कुछ भी चोरी या चोरी करने का प्रयास करेगा।

  3. कोई है जो बस आपके उत्पाद को खरीदेगा, क्योंकि इसका सही काम करना है और यह गारंटी देने का सबसे विश्वसनीय तरीका है कि आपका उत्पाद वर्णित है।

हालाँकि इंटरनेट पर व्याप्त विषयों और प्लगइन्स को पायरेट करना और चोरी करना, वास्तव में आपके थीम या प्लगइन्स का लगातार उपयोग करने वाले लोगों की मात्रा आपके नीचे की रेखा को किसी भी क्षति को वारंट करने के लिए पर्याप्त है।

यह कहने के लिए नहीं कि हमें उस नुकसान को कम करने के लिए अपनी शक्ति के भीतर सब कुछ नहीं करना चाहिए, लेकिन अक्सर आपके प्रयासों को और अधिक उत्पादों को बनाने और मौजूदा उत्पादों को विपणन करने में बेहतर खर्च किया जाएगा, साथ ही साथ जिस तरह से आप अपने उत्पाद की पेशकश करते हैं, उसमें विविधता लाएं। ।

उस दर के साथ, जिस पर कई उत्पाद या तो नई सुविधाओं के साथ अपडेट होते हैं या बग्स को ठीक करते हैं, यह अक्सर पहले से तैयार किए गए उत्पादों को बेकार कर देता है या नहीं जैसा कि इसके लिए भुगतान किया गया था।

जैसा कि ऊपर उल्लेख किया गया है, एनक्रिप्टिंग और ओबफस्कैटिंग कोड, संयुक्त रूप से, एपीआई शैली एकीकरण के अलावा आगे की जांच के लायक दो तरीके हैं, जिससे आपके उत्पादों, विषयों या प्लगइन्स को सर्वोत्तम संभव तरीके से सुरक्षित किया जा सके।


3
कृपया यह सुझाव न दें, जीपीएल लाइसेंस को "संशोधन करने के लिए काम का पसंदीदा रूप" कोड की आवश्यकता है। इसका मतलब है कि किसी भी प्रकार की कोई आपत्ति या एन्क्रिप्शन नहीं।
व्येक

यह एपीआई कुंजी का उपयोग करने से कैसे अलग है? जिस पर आपने गौर नहीं किया तो वह स्वीकृत उत्तर था! किसी तीसरे पक्ष के सर्वर पर आपके एप्लिकेशन लॉजिक का हिस्सा होस्टिंग और परिणाम के रूप में इसे रोकना प्रभावी रूप से या तो एन्क्रिप्ट या ऑबफिकेशन के समान है। यदि आप एन्क्रिप्ट कर रहे हैं या आपत्तिजनक मालिकाना कोड है जिसमें कोई वर्डप्रेस विशिष्ट एपीआई फ़ंक्शन शामिल नहीं हैं, तो मैं नहीं देखता कि यह कैसे समस्या है।
एडम

1
यह पूरी तरह से अलग है, एपीआई कोड अभी भी खुला स्रोत है और लाइसेंस के साथ संगत है, यह एक सेवा है। कृपया GPL पर पढ़ें।
व्यिक

-6

यदि आप इसे बेच रहे हैं तो इसे जीपीएल के अंतर्गत होने की आवश्यकता नहीं है क्योंकि आप इसे वर्डप्रेस की साइटों पर नहीं बेच सकते हैं। आपको जो भी लाइसेंस पसंद है, उसके तहत आप इसे स्वयं वितरित कर सकते हैं। GPL प्रतिबंध सिर्फ Wordpress.org रिपॉजिटरी के लिए है, और जैसा कि आप इसे Wordpress.org के तहत नहीं बेच सकते हैं, यह देखा जा सकता है कि आपके पास जो भी लाइसेंस है वह आपको पसंद आ सकता है।


2
वह बस असत्य है। सभी PHP जो वर्डप्रेस का विस्तार करती है, वह या तो जीपीएल है या वर्डप्रेस के स्वयं के लाइसेंस का उल्लंघन है।
क्रिस कॉक्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.