দলগত কাজ আর open source — documentation, communication আর software license

১ · দলের গঠন — feature team, component team আর Team Topologies

পর্ব ১-এ (Software engineering কী) দেখেছেন, n জনের দলে communication path n(n−1)/2টি, আর Conway's law বলে system-এর আকার দলের যোগাযোগের আকার নেয়। এই পর্বে প্রশ্ন হলো: তাহলে দল সাজাবেন কীভাবে, দলের ভেতরে আর দলের মধ্যে কথা বলবেন কীভাবে, আর দলের বাইরের পৃথিবীর — open source-এর — সাথে কোন নিয়মে কোড ভাগ করবেন।

এই দুই ভাগের আলোচনা Large-Scale Scrum (LeSS) ঘরানার লেখায় — Craig Larman আর Bas Vodde-র বইয়ে — বিস্তারিত পাবেন; তাঁরা feature team-এর পক্ষে জোর যুক্তি দেন। বাস্তবে অনেক প্রতিষ্ঠান মিশ্র পথ নেয়।

Team Topologies — চার ধরনের দল, তিন রকম মেলামেশা

Matthew Skelton আর Manuel Pais-এর বই Team Topologies (২০১৯) একটি জনপ্রিয় শব্দভান্ডার দিয়েছে। মূল কথা: প্রতিটি দলের মাথায় কতটা জিনিস ধরে — cognitive load — তার একটি সীমা আছে; দলের দায়িত্ব সেই সীমার মধ্যে রাখুন। বইয়ের প্রস্তাবিত চার ধরন:

দলগুলো কীভাবে মেলামেশা করে, তারও তিনটি নাম আছে: collaboration (একটি নির্দিষ্ট সময়ের জন্য পাশাপাশি কাজ), X-as-a-Service (একটি দল সেবা দেয়, অন্যটি নথি দেখে নিজে ব্যবহার করে, কম কথায়) আর facilitating (একটি দল আরেকটিকে শেখায়)। নিচের ছবিতে এগুলো একসাথে:

২ · দল কীভাবে বেড়ে ওঠে — Tuckman, psychological safety আর দ্বিমত

১৯৬৫ সালে মনোবিজ্ঞানী Bruce Tuckman ছোট দলের ওপর আগের গবেষণা পর্যালোচনা করে চারটি ধাপের একটি মডেল দেন (“Developmental sequence in small groups”, Psychological Bulletin); ১৯৭৭ সালে Mary Ann Jensen-এর সাথে পঞ্চম ধাপ যোগ করেন। এই Tuckman model মোটা দাগের বর্ণনা — প্রতিটি দল এই ক্রম মেনে চলে বা ধাপগুলো স্পষ্ট আলাদা, এমন নয়; নতুন সদস্য এলে দল আবার আগের ধাপে ফিরতেও পারে। নিচে একটি বিশ্ববিদ্যালয়ের ফলাফল পোর্টালের কাল্পনিক দল ধরে দেখুন:

Psychological safety — প্রশ্ন করার নিরাপত্তা

Harvard-এর গবেষক Amy Edmondson ১৯৯৯ সালে (“Psychological Safety and Learning Behavior in Work Teams”, Administrative Science Quarterly) psychological safety-কে দলের একটি যৌথ বিশ্বাস হিসেবে মাপেন: এখানে ঝুঁকি নিয়ে কথা বললে — প্রশ্ন, ভুল স্বীকার, দ্বিমত — অপমান বা শাস্তি আসবে না। তাঁর গবেষণায় এমন দলে শেখার আচরণ বেশি দেখা গিয়েছিল। পরে Google-এর ভেতরের গবেষণা Project Aristotle (ফল প্রকাশ্যে আসে ২০১৫-২০১৬ সালের দিকে, re:Work সাইট আর সংবাদমাধ্যমে) কার্যকর দলের কয়েকটি বৈশিষ্ট্যের মধ্যে psychological safety-কে সবচেয়ে গুরুত্বপূর্ণ বলে জানায় — তবে সেটি এক প্রতিষ্ঠানের নিজের তথ্যে, নিজের সংজ্ঞায় করা বিশ্লেষণ, তাই সব দলে একই ফল ধরে নেবেন না।

দ্বিমত মেটানো — কয়েকটি মৌলিক কৌশল

• স্বার্থ দেখুন, অবস্থান নয়: “আমি PostgreSQL চাই” একটি অবস্থান; “আমাদের join-ভারী report লাগে” একটি স্বার্থ। স্বার্থ লিখে ফেললে প্রায়ই তৃতীয় সমাধান বেরোয় — Fisher আর Ury-র Getting to Yes (১৯৮১) এই কৌশলের পরিচিত উৎস।
• মাপকাঠি আগে ঠিক করুন: কোন quality attribute বেশি জরুরি (পর্ব ৩), তা আগে মেনে নিলে বিকল্প বাছাই সহজ।
• সিদ্ধান্তের মালিক আর সময়সীমা: কে শেষ কথা বলবেন, কবে — আগে জানা থাকলে তর্ক অনন্তকাল চলে না। “Disagree and commit”: দ্বিমত লিখে রেখে সিদ্ধান্ত মেনে কাজ করা।
• লিখিত চ্যানেল থেকে কথায় যান: তিনবারের বেশি মন্তব্য চালাচালি হলে একটি ছোট call, তারপর ফলাফল আবার লিখে রাখুন।
• ব্যক্তিগত দ্বন্দ্ব আলাদা পথে: অসম্মান বা হয়রানি “দ্বিমত” নয় — সেটি code of conduct আর ব্যবস্থাপনার বিষয় (অংশ ৬)।

৩ · যোগাযোগ — synchronous বনাম asynchronous, সভা আর লিখিত সিদ্ধান্ত

দলের যোগাযোগ দুই রকম। Synchronous: সবাই একই সময়ে উপস্থিত — সভা, call, পাশের টেবিলে প্রশ্ন। Asynchronous: লেখা থাকে, যে যার সময়ে পড়েন আর উত্তর দেন — issue, PR-এর মন্তব্য, নথি, chat-এর thread.

সভা হলে — agenda, সময় আর লিখিত ফল

একটি ভালো সভার তিনটি অংশ: আগে পাঠানো agenda (কী সিদ্ধান্ত চাই, কী পড়ে আসতে হবে), নির্দিষ্ট সময় আর একজন সঞ্চালক, আর শেষে লিখিত ফল — সিদ্ধান্ত, কে কী করবেন, কবে। রেলের সময়সূচির মতো: ট্রেন কখন ছাড়বে আগে জানা, আর না জানলে সবাই প্ল্যাটফর্মে বসে থাকেন।

সভা: ফলাফল পোর্টাল — GPA হিসাব কোথায় হবে
সময়: ৩০ মিনিট · উপস্থিত: নীলা (সঞ্চালক), করিম, সুমি, তানভীর
আগে পড়ার: docs/adr/0007-gpa-calculation.md (খসড়া)

সিদ্ধান্ত: GPA হিসাব application code-এ, database-এ নয়
কারণ: নিয়ম বছর বছর বদলায়; unit test লেখা সহজ
দ্বিমত: করিম — report-এর গতি নিয়ে চিন্তা; ৩ মাস পরে মেপে দেখা হবে
কাজ: সুমি — ADR 0007 চূড়ান্ত করা (বৃহস্পতিবার)
      তানভীর — GPA module-এর unit test (রবিবার)

খেয়াল করুন, সিদ্ধান্তের বিস্তারিত সভার নোটে নয়, একটি ADR-এ যাচ্ছে (ADR পর্ব ৩৮-এ, Software architecture). সভার নোট শুধু বলে কোথায় খুঁজবেন।

দূর থেকে, হাইব্রিড আর ভিন্ন time zone-এ

বাংলাদেশের অনেক developer এখন বিদেশি দল বা ক্লায়েন্টের সাথে দূর থেকে কাজ করেন। বাংলাদেশের সময় UTC+6, আর বর্তমানে এখানে daylight saving time নেই — কিন্তু ইউরোপ আর উত্তর আমেরিকায় আছে, এবং দুই অঞ্চলে সময় বদলানোর তারিখও আলাদা। একটি হিসাব: ঢাকায় সকাল ১০টা–সন্ধ্যা ৬টা মানে UTC 04:00–12:00; শীতকালে Berlin-এ (UTC+1) সকাল ৯টা–বিকেল ৫টা মানে UTC 08:00–16:00. দুটি মেলালে একসাথে কাজের সময় UTC 08:00–12:00, অর্থাৎ ৪ ঘণ্টা — ঢাকায় দুপুর ২টা থেকে সন্ধ্যা ৬টা। গ্রীষ্মে Berlin UTC+2 হলে মিলিত সময় বেড়ে ৫ ঘণ্টা। অনুশীলন ৪-এ তৃতীয় একটি শহর যোগ করে নিজে হিসাব করবেন।

• লেখার সংস্কৃতি (writing culture): প্রস্তাব আগে লেখায়, তারপর আলোচনা। লেখা মানুষকে নিজের চিন্তা গুছাতে বাধ্য করে, আর যিনি সভায় ছিলেন না তিনিও অংশ নিতে পারেন। কিছু প্রতিষ্ঠান তাদের handbook প্রকাশ্যে রাখে, যা থেকে এই ধরনের নিয়ম দেখা যায়।
• উত্তরের প্রত্যাশা লিখে রাখুন: “PR review ১ কর্মদিবসে, জরুরি হলে call” — যাতে নীরবতাকে কেউ অবহেলা না ভাবেন।
• একটি প্রশ্নে পুরো প্রসঙ্গ: “হাই, আছেন?” লিখে অপেক্ষা নয়; কী চাইছেন, কী চেষ্টা করেছেন, কী error — একবারে।
• হাইব্রিড সভায় সবাই নিজের যন্ত্র থেকে যোগ দিলে দূরের মানুষ পিছিয়ে পড়েন না; সিদ্ধান্ত লেখা হয় সবার দেখা নথিতে।

৪ · Documentation — Diátaxis, README, CONTRIBUTING আর docs-as-code

সব নথি এক রকম নয়। Daniele Procida-র Diátaxis কাঠামো (আগে “Divio documentation system” নামে পরিচিত ছিল) ব্যবহারকারীর প্রয়োজন ধরে নথিকে চার ভাগ করে। কাঠামোটি জনপ্রিয় হলেও একমাত্র পথ নয় — তবু ভাগগুলো মাথায় রাখলে একটি পাতায় সব মিশিয়ে ফেলার ভুল কমে।

প্রতিটি repository-র মৌলিক নথি

এই ফাইলগুলো সাধারণ লেখার ফাইল — Markdown — কোডের পাশে একই Git repository-তে। এটাই docs as code: নথি বদলায় PR দিয়ে, review হয়, CI-তে ভাঙা link আর বানান যাচাই হয়, আর version-এর সাথে tag হয় — v2.0-এর কোড checkout করলে v2.0-এর নথিই পাবেন। Code-এর আচরণ বদলানো PR-এ নথি না বদলালে reviewer প্রশ্ন করবেন: “README-র উদাহরণ কি এখনো চলবে?”

• API documentation: সম্ভব হলে কোড থেকে তৈরি হোক — docstring বা JSDoc থেকে reference, আর HTTP API-র জন্য OpenAPI-এর মতো একটি machine-readable বিবরণ (REST API নকশা System Design কোর্সের REST API design পর্বে)। হাতে লেখা reference দ্রুত পুরোনো হয়।
• Architecture নথি: একটি ছোট overview (C4-এর context আর container ছবি) আর ADR-এর সারি — পর্ব ৩৮।
• Onboarding নথি: নতুন সদস্যের প্রথম সপ্তাহের পথ — কোন access লাগবে, কীভাবে local-এ চালাবেন, কোন ছোট issue দিয়ে শুরু, কাকে কী জিজ্ঞেস করবেন। নিয়ম: প্রতিটি নতুন সদস্য onboarding শেষে যে ধাপে আটকেছিলেন, সেটি ঠিক করে একটি PR দেবেন।
• নথি সতেজ রাখা: পুরোনো নথি — documentation rot — অনেক সময় নথি না থাকার চেয়েও খারাপ, কারণ ভুল পথ দেখায়। প্রতিকার: CI-তে README-র command চালানো বা doctest, প্রতিটি পাতায় মালিক আর “শেষ যাচাই” তারিখ, CODEOWNERS দিয়ে docs-এর reviewer, আর যে নথি কেউ রাখবেন না তা মুছে ফেলা।

নিচের খেলনা checker একটি README-র শিরোনাম আর প্রথম লাইন দেখে ছয়টি মৌলিক অংশ — title, description, install, usage, contributing, license — আছে কি না বলে। এটি শুধু heading-এর নাম মেলায়, লেখার মান বিচার করে না:

// README completeness checker: reads only Markdown headings and the top lines.
const SECTIONS = {
  install:      /^#{2,3}\s*(install|installation|setup|getting started)\b/im,
  usage:        /^#{2,3}\s*(usage|how to use|examples?)\b/im,
  contributing: /^#{2,3}\s*contribut/im,
  license:      /^#{2,3}\s*licen[cs]e\b/im,
};
function check(name, text) {
  const lines = text.trim().split("\n");
  const missing = [];
  if (!/^#\s+\S/.test(lines[0])) missing.push("title");
  const desc = lines.slice(1).find((l) => l.trim() !== "");
  if (!desc || desc.startsWith("#")) missing.push("description");
  for (const [key, re] of Object.entries(SECTIONS)) if (!re.test(text)) missing.push(key);
  const note = missing.length ? `  missing: ${missing.join(", ")}` : "  complete";
  console.log(`${name.padEnd(13)} ${6 - missing.length}/6${note}`);
}
check("bazar-cart", `# bazar-cart
Shopping-cart library for a fictional online bazar app.
## Installation
npm install bazar-cart
## Usage
cart.add("rice-5kg", 2)
## Contributing
Read CONTRIBUTING.md before opening a pull request.
## License
MIT - see LICENSE`);
check("result-portal", `# result-portal
## Setup
pip install -r requirements.txt
## License
GPL-3.0-or-later`);
check("scripts", `Some helper scripts.
## Examples
python run.py --dry-run`);

bazar-cart    6/6  complete
result-portal 3/6  missing: description, usage, contributing
scripts       1/6  missing: title, description, install, contributing, license

৫ · জ্ঞান ভাগাভাগি আর bus factor — হিসাব করে দেখা

পর্ব ৪৪-এ code review-এর একটি উদ্দেশ্য হিসেবে bus factor দেখেছেন: কতজন মানুষ হঠাৎ না থাকলে project আটকে যাবে। একে truck factor-ও বলে। প্রশ্ন হলো, এটি কি অনুমান না হিসাব? Git-এর history থেকে একটি আনুমানিক হিসাব করা যায়।

প্রথম ধাপ: কে কোন ফাইলে কাজ করেছেন। একটি scratch repository-তে কাল্পনিক অনলাইন বাজার অ্যাপের ১০০টি commit বানিয়ে Git ২.৫৩-এ চালানো হয়েছে (চারজন কাল্পনিক লেখক):

$ git shortlog -sne HEAD
    46	Rahim <rahim@example.com>
    21	Nila <nila@example.com>
    18	Karim <karim@example.com>
    15	Sumi <sumi@example.com>
$ git shortlog -sn HEAD -- api/payments.py
     9	Rahim
     6	Karim

-s শুধু সংখ্যা দেখায়, -n বেশি থেকে কম সাজায়, -e email দেখায়; -- path একটি ফাইলে সীমিত করে। HEAD লেখা হয়েছে কারণ script বা pipe থেকে চালালে revision না দিলে git shortlog standard input থেকে log পড়ার অপেক্ষা করে। একই মানুষ দুই email-এ commit করলে আগে .mailmap দিয়ে মেলাতে হবে (পর্ব ৯), নইলে হিসাব ভুল আসবে। প্রতিটি ফাইলে এভাবে গুনলে নিচের টেবিল পাওয়া যায় — সেটিই আমাদের ইনপুট।

# Truck-factor estimate, simplified (after the idea in Avelino et al. 2016).
# commits[file] = {author: commits to that file} -- fictional shop project
commits = {
    "api/orders.py":   {"Rahim": 14, "Sumi": 2},
    "api/payments.py": {"Rahim": 9, "Karim": 6},
    "api/users.py":    {"Sumi": 7, "Rahim": 1},
    "core/cart.py":    {"Rahim": 11, "Nila": 1},
    "core/stock.py":   {"Karim": 8},
    "core/price.py":   {"Rahim": 5, "Karim": 4},
    "web/app.js":      {"Nila": 12, "Sumi": 3},
    "web/cart.js":     {"Nila": 6},
    "docs/README.md":  {"Sumi": 3, "Rahim": 2, "Nila": 2},
    "ci/build.yml":    {"Rahim": 4},
}
SHARE = 0.25   # an author "knows" a file if they made >= 25% of its commits
owners = {f: {a for a, c in m.items() if c / sum(m.values()) >= SHARE}
          for f, m in commits.items()}
for f, o in owners.items():
    print(f"{f:16} knows: {', '.join(sorted(o))}")
removed, n = [], len(owners)
while True:
    left = {f: o - set(removed) for f, o in owners.items()}
    orphans = [f for f, o in left.items() if not o]
    print(f"removed={removed} -> orphan files {len(orphans)}/{n}")
    if len(orphans) > n / 2:          # more than half the files lost
        break
    count = {}
    for o in left.values():
        for a in o:
            count[a] = count.get(a, 0) + 1
    top = max(sorted(count), key=count.get)   # ties: alphabetical first
    removed.append(top)
print("truck factor =", len(removed))

api/orders.py    knows: Rahim
api/payments.py  knows: Karim, Rahim
api/users.py     knows: Sumi
core/cart.py     knows: Rahim
core/stock.py    knows: Karim
core/price.py    knows: Karim, Rahim
web/app.js       knows: Nila
web/cart.js      knows: Nila
docs/README.md   knows: Nila, Rahim, Sumi
ci/build.yml     knows: Rahim
removed=[] -> orphan files 0/10
removed=['Rahim'] -> orphan files 3/10
removed=['Rahim', 'Karim'] -> orphan files 6/10
truck factor = 2

Bus factor বাড়াবেন কীভাবে

• Review-এর বণ্টন: একই মানুষ সব review না করে, অন্য অংশের মানুষকেও reviewer করা; CODEOWNERS-এ একটি অংশে অন্তত দুজন।
• জুটি বেঁধে কাজ: pair programming আর mob programming (পর্ব ৪৪) দ্রুত জ্ঞান ছড়ায় — বিশেষ করে knowledge silo ভাঙতে।
• কাজের ঘূর্ণন: on-call, release আর “এই সপ্তাহে payments-এর bug” পালা করে।
• ভেতরের আলোচনা: মাসে একবার ২০ মিনিটের internal talk বা brown-bag session, রেকর্ড আর নোটসহ।
• নথি: অংশ ৪-এর explanation নথি আর ADR — মানুষ চলে গেলেও “কেন” থেকে যায়।

Truck factor কম হওয়া একটি project risk; risk register-এ কীভাবে লিখবেন তা পর্ব ৬২-এ (Risk আর quality management).

৬ · Open source — সংজ্ঞা, অবদানের পথ আর governance

Open source মানে শুধু “কোড দেখা যায়” নয়। Open Source Initiative (OSI) ১৯৯৮ সালে প্রতিষ্ঠিত হয়, আর তাদের Open Source Definition-এ দশটি শর্ত আছে — Debian Free Software Guidelines থেকে নেওয়া — যেমন অবাধে আবার বিতরণ, source code পাওয়া, পরিবর্তিত কাজ বানানোর অনুমতি, কোনো ব্যক্তি বা কাজের ক্ষেত্রের বিরুদ্ধে বৈষম্য না করা। OSI যে license-গুলো এই শর্ত মানে বলে পরীক্ষা করেছে, সেগুলোকে “OSI-approved” বলে। “কোড GitHub-এ আছে কিন্তু license নেই” — এমন কোড আইনগতভাবে সাধারণত ব্যবহারের অনুমতি দেয় না, কারণ কপিরাইট নিজে থেকেই লেখকের।

একটি অবদান — issue থেকে merge পর্যন্ত

পর্ব ১৬-এ (Pull request আর fork) fork-এর যন্ত্রপাতি আর review-এর নিয়ম দেখেছেন। এখানে পুরো যাত্রা, একটি কাল্পনিক open-source library bazar-cart-এ প্রথম অবদান:

CLA বনাম DCO

Project জানতে চায় আপনার অবদান ব্যবহারের অধিকার তাদের আছে। দুই প্রধান পথ:

Governance, maintainer আর code of conduct

কে সিদ্ধান্ত নেন? ছোট project-এ একজন maintainer; কিছু বড় project-এ একজন চূড়ান্ত সিদ্ধান্তদাতা — রসিকতা করে বলা হয় BDFL (“benevolent dictator for life”) — যেমন Python দীর্ঘদিন Guido van Rossum-এর এই ভূমিকায় চলেছে, ২০১৮ সালে তিনি সরে দাঁড়ানোর পরে নির্বাচিত steering council এসেছে। অন্য governance model: meritocratic committer (যেমন Apache Software Foundation-এর project-এ), নির্বাচিত কমিটি, বা একটি কোম্পানি-নেতৃত্বাধীন project. ভালো project এটি GOVERNANCE.md-এ লিখে রাখে — কীভাবে কেউ maintainer হন, সিদ্ধান্ত কীভাবে, মতবিরোধে কী হয়।

Code of conduct লেখে কোন আচরণ গ্রহণযোগ্য, কোথায় অভিযোগ করবেন আর কে কীভাবে ব্যবস্থা নেবেন। বহুল ব্যবহৃত একটি নমুনা হলো Contributor Covenant, ২০১৪ সালে Coraline Ada Ehmke-এর শুরু করা; সংস্করণ সময়ের সাথে বদলেছে, তাই ব্যবহারের আগে তাদের সাইটে সর্বশেষটি দেখে নিন। অভিযোগের ঠিকানা আর ব্যবস্থা নেওয়ার মানুষ না থাকলে নথিটি কেবল সাজসজ্জা।

৭ · Software license — permissive থেকে network copyleft

একটি software license হলো কপিরাইটের মালিকের দেওয়া অনুমতি আর তার শর্ত। মূল প্রশ্ন একটাই: আপনি যদি এই কোড ব্যবহার করে কিছু বানিয়ে অন্যকে দেন, তাহলে আপনার নিজের কোডের ওপর কী শর্ত পড়বে? উত্তরের মাত্রা ধরে license-গুলোকে একটি বর্ণালিতে সাজানো যায়:

Permissive license বলে “যা খুশি করুন, শুধু নাম রাখুন”; copyleft বলে “বিতরণ করলে একই স্বাধীনতা পরের মানুষকেও দিন”। GPL-এর একটি সূক্ষ্ম কথা: শর্ত জাগে বিতরণে। শুধু নিজের server-এ বদলানো GPL প্রোগ্রাম চালিয়ে সেবা দিলে সাধারণত বিতরণ হয় না — এই ফাঁকটি বন্ধ করতেই AGPL-এর ধারা ১৩.

License compatibility — কোন দিকে মেলানো যায়

License compatibility প্রশ্ন: license A-র কোড আমার project-এ নিয়ে পুরোটা license B-তে বিতরণ করা যাবে কি না? উত্তর দিক-নির্ভর। MIT-এর কোড GPL-3.0 project-এ নেওয়া যায় (MIT-এর notice রেখে), কিন্তু উল্টোটা নয় — GPL কোড নিলে পুরো বিতরণ করা কাজটিকে GPL-এর শর্ত মানতে হয়। FSF-এর মতে Apache-2.0 GPL-3.0-এর সাথে মেলে, কিন্তু GPL-2.0-এর সাথে নয় (Apache-2.0-এর patent-বাতিল আর indemnification-এর মতো কিছু শর্ত GPL-2.0 অনুমতি দেয় না); আর “GPL-2.0-only” কোড GPL-3.0-এ যায় না, যতক্ষণ না লেখক “or later” অনুমতি দেন। নিচের খেলনা টেবিল এই প্রচলিত ব্যাখ্যাগুলো ধরে:

// EDUCATIONAL TOY - NOT LEGAL ADVICE. A simplified table of common readings
// (mostly the FSF's). Question: may code under license A go INTO a project
// that is distributed under license B?
const B = ["MIT", "Apache-2.0", "MPL-2.0", "LGPL-2.1-only",
           "GPL-2.0-only", "GPL-3.0-only", "AGPL-3.0-only"];
// row = A (code you bring in); one letter per column of B:
// Y = yes, N = no, C = yes, but A's copyleft keeps applying to A's part
const M = {
  "MIT":           "YYYYYYY",
  "Apache-2.0":    "YYYNNYY",
  "MPL-2.0":       "CCYYYYY",
  "LGPL-2.1-only": "CCCYYYY",
  "GPL-2.0-only":  "NNNNYNN",
  "GPL-3.0-only":  "NNNNNYY",
  "AGPL-3.0-only": "NNNNNCY",
};
const WHY = { Y: "yes (keep copyright and license text)",
              N: "NO  (needs relicensing or permission)",
              C: "yes, with conditions on A's part" };
function check(a, b) {
  if (!(a in M) || !B.includes(b)) return "unknown - ask a person who knows";
  return WHY[M[a][B.indexOf(b)]];
}
const asks = [["MIT", "GPL-3.0-only"], ["Apache-2.0", "GPL-3.0-only"],
  ["Apache-2.0", "GPL-2.0-only"], ["GPL-3.0-only", "MIT"],
  ["MPL-2.0", "Apache-2.0"], ["GPL-2.0-only", "GPL-3.0-only"],
  ["AGPL-3.0-only", "GPL-3.0-only"], ["BSD-3-Clause", "MIT"]];
for (const [a, b] of asks)
  console.log(`${a.padEnd(13)} into ${b.padEnd(13)}: ${check(a, b)}`);

MIT           into GPL-3.0-only : yes (keep copyright and license text)
Apache-2.0    into GPL-3.0-only : yes (keep copyright and license text)
Apache-2.0    into GPL-2.0-only : NO  (needs relicensing or permission)
GPL-3.0-only  into MIT          : NO  (needs relicensing or permission)
MPL-2.0       into Apache-2.0   : yes, with conditions on A's part
GPL-2.0-only  into GPL-3.0-only : NO  (needs relicensing or permission)
AGPL-3.0-only into GPL-3.0-only : yes, with conditions on A's part
BSD-3-Clause  into MIT          : unknown - ask a person who knows

NOTICE ফাইল আর attribution

Apache-2.0-এর ধারা ৪ বলে: মূল project-এ NOTICE ফাইল থাকলে আপনার বিতরণেও তার attribution রাখতে হবে। বাস্তবে একটি app-এর “About → Open source licenses” পাতা বা THIRD_PARTY_NOTICES ফাইল এই কাজই করে: প্রতিটি dependency-র নাম, version, license আর কপিরাইট লাইন। Permissive license-এরও এটাই প্রায় একমাত্র শর্ত — আর এটাই সবচেয়ে বেশি ভুলে যাওয়া হয়।

৮ · SPDX, license scan আর একটি license বেছে নেওয়া

“MIT”, “The MIT License”, “Expat”, “X11-style” — মানুষ একই license-কে নানা নামে লেখে, যন্ত্র বিভ্রান্ত হয়। SPDX (Software Package Data Exchange, Linux Foundation-এর project, ২০২১ সালে ISO/IEC 5962 হিসেবে মান) প্রতিটি license-কে একটি নির্দিষ্ট ছোট নাম দেয় — SPDX license identifier: MIT, Apache-2.0, GPL-2.0-only, GPL-3.0-or-later. ২০১৭ সালের শেষে SPDX license list-এর সংস্করণ ৩.০ থেকে GPL পরিবারের জন্য “-only” আর “-or-later” আলাদা নাম এসেছে; পুরোনো GPL-3.0 এখন deprecated, কারণ এটি থেকে বোঝা যেত না কোনটি। প্রতিটি source ফাইলের শুরুতে এক লাইন:

// SPDX-License-Identifier: Apache-2.0
// Copyright 2026 The bazar-cart contributors

একাধিক license একসাথে লিখতে আছে SPDX expression: OR = বেছে নেওয়ার স্বাধীনতা (dual licensing, যেমন Rust-এর জগতে প্রচলিত MIT OR Apache-2.0), AND = দুটিই একসাথে মানতে হবে, আর WITH = একটি license-এর সাথে একটি license exception — যেমন OpenJDK-র GPL-2.0-only WITH Classpath-exception-2.0, যা library ব্যবহারকারী প্রোগ্রামকে GPL-এর শর্ত থেকে ছাড় দেয়। অগ্রাধিকার: WITH সবচেয়ে শক্ত, তারপর AND, তারপর OR; বন্ধনী দিয়ে বদলানো যায়। নিচের ছোট parser এটি গাছ হিসেবে দেখায়:

import re
# Tiny SPDX license-expression parser. Precedence: WITH > AND > OR; ( ) groups.
def parse(text):
    t = re.findall(r"\(|\)|[A-Za-z0-9.+:-]+", text)
    pos = 0
    def peek(): return t[pos] if pos < len(t) else None
    def take():
        nonlocal pos; pos += 1; return t[pos - 1]
    def chain(op, sub):                  # left-to-right chain of one operator
        node = sub()
        while peek() == op:
            take(); node = (op, node, sub())
        return node
    def atom():
        if peek() == "(":
            take(); node = or_expr()
            if take() != ")": raise ValueError("missing )")
            return node
        lic = take()
        if peek() == "WITH":
            take(); return ("WITH", lic, take())
        return lic
    def and_expr(): return chain("AND", atom)
    def or_expr():  return chain("OR", and_expr)
    tree = or_expr()
    if pos != len(t): raise ValueError("unexpected " + t[pos])
    return tree
def show(n, d=1):
    pad = "  " * d
    if isinstance(n, str): print(pad + "license:", n)
    elif n[0] == "WITH": print(pad + "license:", n[1], "+ exception:", n[2])
    else: print(pad + n[0]); show(n[1], d + 1); show(n[2], d + 1)
for e in ["MIT OR Apache-2.0", "GPL-2.0-only WITH Classpath-exception-2.0",
          "MIT AND Apache-2.0 OR BSD-3-Clause", "MIT AND (Apache-2.0 OR BSD-3-Clause)"]:
    print(e); show(parse(e))

MIT OR Apache-2.0
  OR
    license: MIT
    license: Apache-2.0
GPL-2.0-only WITH Classpath-exception-2.0
  license: GPL-2.0-only + exception: Classpath-exception-2.0
MIT AND Apache-2.0 OR BSD-3-Clause
  OR
    AND
      license: MIT
      license: Apache-2.0
    license: BSD-3-Clause
MIT AND (Apache-2.0 OR BSD-3-Clause)
  AND
    license: MIT
    OR
      license: Apache-2.0
      license: BSD-3-Clause

Dependency-র license scan

আপনার app-এর ভেতরে শত শত dependency, আর তাদেরও dependency. হাতে দেখা অসম্ভব, তাই license scanning tool package-এর metadata আর ফাইলের লেখা পড়ে প্রতিটির license বের করে, তারপর দলের নীতির সাথে মেলায়: “permissive চলবে; LGPL হলে review; GPL/AGPL হলে আটকানো; license না পেলে আটকানো”। লেখার সময়ের পরিচিত কিছু উদাহরণ: ScanCode Toolkit আর FOSSology (ফাইল ধরে গভীর scan), npm-এর জন্য license-checker-ধাঁচের package, Python-এর জন্য pip-licenses, আর hosting platform-এর dependency review — সুবিধা tool আর platform-ভেদে আলাদা। এটি CI-এর একটি ধাপ হিসেবে চালান (পর্ব ৫৮, Continuous integration), যাতে নতুন dependency যোগের PR-এই সমস্যা ধরা পড়ে। Package-এর নিজের license ঘোষণা করবেন metadata-তে: npm-এ package.json-এর "license" ঘরে SPDX expression (দেখুন npm আর tooling), Python-এ pyproject.toml-এ (দেখুন Packaging আর PyPI). Dependency-র তালিকা নিজেও software supply chain-এর অংশ (পর্ব ৫৭)।

একটি license বেছে নেওয়া — কাল্পনিক “হিসাবখাতা” library

ধরুন আপনি মুদি দোকানের বাকির হিসাব রাখার একটি ছোট open-source library বানিয়েছেন, নাম “হিসাবখাতা”। কোন license? নিচের ধাপগুলো একটি যুক্তির পথ, একমাত্র ঠিক উত্তর নয়:

৯ · AI-এর যুগে দলগত কাজ, নথি আর license

AI এখন সভার নোটের সারাংশ লেখে, README-র খসড়া দেয়, আর কোড প্রস্তাব করে। এতে সময় বাঁচে — কিন্তু দলের কাজে তিনটি নতুন ঝুঁকি আসে: ভুল তথ্য আত্মবিশ্বাসের সাথে লেখা নথি, license-এর উৎস হারানো কোড, আর prompt-এ গোপন তথ্য।

AI ব্যবহারের আগে-পরে চেকলিস্ট

• Prompt-এ কোনো secret, token, গ্রাহকের তথ্য বা অপ্রকাশিত কোড দিইনি — দলের AI-নীতি যা অনুমতি দেয় তার বাইরে নয়
• AI-এর বলা প্রতিটি license-দাবি license-এর আসল লেখা বা প্রকাশিত উৎসে মিলিয়েছি
• AI-এর দেওয়া SPDX নাম অফিসিয়াল তালিকায় আছে কি না দেখেছি
• AI-এর লেখা README-র প্রতিটি command একটি নতুন clone-এ চালিয়ে দেখেছি
• AI-এর লেখা কোড review-এ মানুষের কোডের মতোই পড়া হয়েছে, আর license scan CI-তে চলেছে
• Force push বা reset-এর পরামর্শ পেলে আগে git help পড়ে throwaway clone-এ চালিয়েছি