سرقے کا الزام تقریباً کبھی بھی موزوں تاریخ پر نہیں آتا۔ اشاعت کی صنعت میں سب سے عام پیٹرن اس کے برعکس ہے: یہ الزام کہ مسودہ، کہانی، یا کوئی خاص حصہ کسی اور کے کام سے لیا گیا ہے، کتاب کے لانچ کے آس پاس کے دنوں میں سامنے آتا ہے، جب پیشگی پریس کوریج پہلے ہی شائع ہو چکی ہوتی ہے، ریٹیلر پلیسمنٹ طے ہو چکی ہوتی ہے، اور مارکیٹنگ کا بجٹ پہلے ہی خرچ کیا جا چکا ہوتا ہے۔ اس مقام پر ناشر شپ کرنے یا نہ کرنے کے درمیان انتخاب نہیں کر رہا ہوتا۔ وہ کھلے تنازعے میں لانچ کرنے یا پہلے سے ادا شدہ لانچ کو روکنے کے درمیان انتخاب کر رہا ہوتا ہے، اور دونوں آپشنز نظر آتے ہیں۔
وقت اصل مسئلہ کیوں ہے
الزام میں دم ہے یا نہیں، یہ شاذ و نادر ہی پہلے ہفتے میں اس کی قیمت طے کرتا ہے۔ وقت طے کرتا ہے۔ ادارتی ترقی کے دوران اٹھایا گیا الزام ایک قانونی اور ادارتی سوال ہے جسے معمول کی رفتار سے حل کیا جا سکتا ہے۔ لانچ کے ہفتے میں اٹھایا گیا وہی الزام ریٹیل اور پریس کی ٹائم لائنز پر چلتا ہے جنہیں ناشر کنٹرول نہیں کرتا، اور جب تک یہ کھلا رہتا ہے، ہر دن ریٹیلرز، ناقدین اور مصنف کے اپنے قارئین اسے غیر حل شدہ دیکھتے رہتے ہیں۔ قانونی لاگت خطرے کا صرف ایک حصہ ہے۔ تقسیم میں تاخیر اور مصنف و اشاعتی ادارے دونوں کی ساکھ کو نقصان اکثر بڑا ہوتا ہے، اور لانچ ونڈو گزرنے کے بعد دونوں میں سے کوئی بھی واپس نہیں آتا۔
تنازعے کو اصل میں کیا مختصر کرتا ہے
جو ناشر اس قسم کے الزام کو تیزی سے حل کرتے ہیں وہ وہ نہیں ہوتے جن کی رائے سب سے مضبوط ہو کہ صحیح کون ہے۔ وہ وہ ہوتے ہیں جو فوراً مسودے کی صاف، تاریخ شدہ تاریخ پیش کر سکتے ہیں: حتمی نسخہ ان کے سسٹمز میں کب داخل ہوا، اس کے بعد کون سی مخصوص تبدیلیاں کی گئیں، اور کب۔ یہ ریکارڈ ایسے شخص کے سامنے بھی برقرار رہنا چاہیے جس کے پاس اسے چیلنج کرنے کی ہر وجہ ہو، یعنی یہ صرف ناشر کے کہنے پر انحصار نہیں کر سکتا۔
اندرونی فائل ٹائم اسٹیمپس کافی کیوں نہیں ہوتے
زیادہ تر ناشرین کے پاس پہلے سے ہی کچھ ایسا موجود ہوتا ہے جو اس ریکارڈ جیسا لگتا ہے: مسودے کی فائل کی ترمیمی تاریخ، شیئرڈ ڈرائیو میں ورژن ہسٹری، یا کنٹینٹ مینجمنٹ سسٹم میں ٹائم اسٹیمپس۔ مسئلہ یہ ہے کہ یہ سب مکمل طور پر ناشر کے کنٹرول شدہ سسٹمز کے اندر موجود ہوتا ہے۔ فائل کی ترمیمی تاریخ اس وقت بدل جاتی ہے جب اسے کاپی کیا جائے، دوبارہ محفوظ کیا جائے، یا غلط سسٹم گھڑی والی مشین پر کھولا جائے۔ شیئرڈ ڈرائیو کی ورژن ہسٹری کو ایڈمن رسائی رکھنے والا کوئی بھی شخص تبدیل یا حذف کر سکتا ہے۔ ان میں سے کسی کا بھی ماخذ ناشر کے اپنے ڈھانچے سے باہر نہیں ہوتا، یعنی تنازعے میں یہ ناشر کا اپنے ہی ریکارڈ پر بیان ہے، آزاد ثبوت نہیں۔
مخالف فریق کو ٹائم اسٹیمپ کو بیکار ثابت کرنے کے لیے یہ ثابت کرنے کی ضرورت نہیں کہ وہ غلط ہے۔ اسے بس یہ دکھانا ہوتا ہے کہ اسے بدلا جا سکتا تھا، اور زیادہ تر ادارتی عمل میں یہ ممکن ہوتا ہے۔
اندرونی ٹائم اسٹیمپس بمقابلہ آزادانہ طور پر تصدیق شدہ تاریخ شدہ ثبوت
| تنازعے سے اٹھنے والا سوال | اندرونی فائل ٹائم اسٹیمپ | آزادانہ طور پر تصدیق شدہ تاریخ شدہ ثبوت |
|---|---|---|
| کیا ناشر اکیلے اسے بعد میں بدل سکتا تھا؟ | ہاں | نہیں، تصدیق ناشر کے اپنے سسٹمز پر منحصر نہیں ہوتی |
| کیا کوئی تیسرا فریق تاریخ کی تصدیق کرتا ہے؟ | نہیں | ہاں |
| کیا یہ کسی مخصوص، تصدیق شدہ شخص سے جڑا ہے؟ | شاذ و نادر، اکثر ایک شیئرڈ لاگ اِن | ہاں، ایک تصدیق شدہ شناخت سے جڑا |
| کیا اسے ناشر کے بیان پر بھروسہ کیے بغیر جانچا جا سکتا ہے؟ | نہیں | ہاں |
ایک قابلِ دفاع ریکارڈ کو اصل میں کیا چاہیے
چار عناصر ایک اندرونی مسودہ تاریخ کو ایسے ثبوت میں بدل دیتے ہیں جس پر بیرونی وکیل اور عدالت واقعی بھروسہ کر سکیں:
- حتمی مسودہ ناشر کے سسٹمز میں کب داخل ہوا، اس کا تاریخ شدہ ریکارڈ۔ پہلا مسودہ نہیں، بلکہ پروڈکشن کے لیے لاک شدہ وہ ورژن، جو لاک ہونے کے لمحے میں محفوظ کیا گیا ہو۔
- اس کے بعد کی گئی اہم تبدیلیوں کا تاریخ شدہ ریکارڈ۔ کس نے کیا بدلا، اور کب، ایسی شکل میں جسے بعد میں خاموشی سے تبدیل نہ کیا جا سکے۔
- آزادانہ تصدیق۔ ناشر کے اپنے فائل سسٹم یا کنٹینٹ مینجمنٹ ٹول سے باہر کا ایک ماخذ، جو ناشر کے کہنے پر انحصار کیے بغیر تاریخوں کی تصدیق کر سکے۔
- ہر اندراج کے پیچھے ایک حقیقی، تصدیق شدہ شناخت۔ ایک شیئرڈ ادارتی لاگ اِن کسی کو نہیں بتاتا کہ اصل میں تبدیلی کس نے کی، جو مصنف اور ایڈیٹر کے درمیان اندرونی تنازعے میں اتنا ہی اہم ہے جتنا بیرونی سرقے کے الزام کے خلاف۔
یہ دعویٰ نہیں ہے کہ الزام خودکار طور پر غلط ہے۔ یہ اس حقیقی سوال کا جواب دینے کا ایک طریقہ ہے کہ یہ مسودہ اصل میں کب مکمل ہوا اور کس نے مکمل کیا، اتنی جلدی کہ تنازعہ اپنی اصل بنیاد کی بجائے لانچ کی گھڑی پر نہ چلے۔
یہ ادارتی عمل میں کہاں فٹ ہوتا ہے
Swiss Trust Layer کسی مسودے پر، جس لمحے وہ ناشر کے سسٹم میں داخل ہوتا ہے، ایک کرپٹوگرافک مہر اور آزادانہ طور پر جانچے جانے والا ٹائم اسٹیمپ لگاتا ہے، اور اہم تبدیلیوں کے وقت مخصوص ورژنز پر بھی، جو تبدیلی کرنے والے کی تصدیق شدہ شناخت سے جڑا ہوتا ہے۔ نتیجہ ایک ایسا ریکارڈ ہے جس کی ساکھ ناشر کے اپنے ڈھانچے پر منحصر نہیں ہوتی۔ یہ اس بات کا ثبوت ہے کہ کوئی مخصوص فائل کب موجود تھی اور کس نے اسے چھوا، جسے بیرونی وکیل یا عدالت ناشر سے اس کے اپنے سسٹمز کی ضمانت مانگے بغیر تصدیق کر سکتے ہیں۔ یہی وہ ثبوتی بنیاد ہے جو ایک ناشر کسی الزام کے آنے سے بہت پہلے تیار رکھنا چاہتا ہے، نہ کہ لانچ کے ہفتے کی آخری تاریخ کے دباؤ میں جوڑی گئی کوئی چیز۔ موجودہ مسودہ پائپ لائن میں یہ کیسے فٹ ہوتا ہے، اس کے لیے دیکھیں ناشرین کے لیے Swiss Trust Layer۔
لانچ کی منصوبہ بندی کے لیے نتیجہ
لانچ کے ہفتے میں سرقے کا الزام بنیادی طور پر اس لیے مہنگا ہوتا ہے کہ یہ کب پیش آتا ہے، نہ کہ اس لیے کہ زیادہ تر ایسے الزامات درست ثابت ہوتے ہیں۔ جو ناشرین اس سے سب سے تیزی سے گزرتے ہیں وہ وہ ہیں جن کے پاس الزام آنے سے پہلے ہی مسودے کی تاریخ شدہ، آزادانہ طور پر تصدیق شدہ تاریخ موجود تھی، تاکہ یہ سوال کہ صحیح کون ہے، لانچ کیلنڈر کی بجائے اپنے ہی وقت پر حل ہو سکے۔
