التراخيص والنزاهة والإفصاح
في هذا الدرس 11 موضوعات
هذا الدرس متاح حاليًا باللغة الإنجليزية فقط، ولم تُنشر نسخته العربية بعد.
Lesson Overview
So far this module was technical: read the draft, trace it, test it. This lesson covers the rules around the code. Is it allowed to use? Is it safe to ask? And how do you say honestly that an assistant helped?
You will not become a lawyer in six minutes of video, and nothing here is legal advice. The goal is practical: to know which questions to ask, where the answers live (your course rules, your employer's policy, a project's licence), and what an honest disclosure looks like.
Why this matters: the verified code you produce in this module is only useful if you may use it and can say where it came from. Students lose marks and engineers lose trust over exactly this: pasting something they should not have, or hiding help they should have declared.
You need the safe-use rules from BEG-056 (never paste passwords, keys, or personal data) and the workflow from lessons 1 to 3. The next lesson is a demo that puts the whole workflow into practice on a binary search.
Learning Objectives
By the end of this lesson you will be able to:
- Explain why generated code may be subject to a licence or may resemble existing code.
- Say what must never be pasted into a public assistant, and why.
- Follow academic-integrity rules by finding and applying your course's policy on AI.
- Write a disclosure that names the tool, what you asked it for, and what you changed or tested.
- Explain why submitting code you cannot explain, as if it were your own, breaks the rules.
Written Explanation
Licences: generated code may not be "yours alone"
A licence is the permission slip attached to code. By default, code that someone wrote belongs to its author, and nobody else may copy or change it. GitHub's documentation puts it this way: without a licence, default copyright law applies, and others cannot copy, distribute, or build on the work. An open-source licence gives others permission to use, modify, and share the code, usually with conditions: for example, keeping the author's notice, or sharing your changes under the same licence. Different licences have different conditions, so "open source" does not mean "no rules".
Why does this touch generated code? An assistant learned from a huge body of code, and a suggestion can occasionally match code that exists publicly. GitHub's documentation says this about its own assistant: the chance of a match is low but not zero, and depending on settings a matching suggestion is either blocked or shown with the source repository and licence. The same documentation states that the user takes on the risks of generated code, including bugs, security problems, and intellectual-property problems. Other tools differ, so check your tool's documentation rather than assuming it has such a filter.
What should you do in practice?
- Follow the policy of the place you submit to. Your employer, your project, or your course may allow, restrict, or forbid assistants. The policy decides. If you do not know it, ask before you use the tool, not after.
- Be suspicious of long, distinctive blocks. A three-line loop is not a licensing concern. A long, unusual block with distinctive names or comments that you did not ask for might be copied. Search for a distinctive phrase, and check where it came from before you keep it.
- Keep the source and licence if you do reuse code. If you deliberately copy code from a project, follow that project's licence conditions.
- Treat the legal question as open. How the law treats AI-generated code differs between countries and is changing. We did not verify any legal claims beyond the documentation cited below. For anything that matters (a product you will sell, a client's code), ask someone qualified, for example your employer's legal or open-source contact.
Never paste secrets, personal data, or private code into a public assistant
A public assistant is a service run by someone else: what you type leaves your computer. Treat everything you paste as something you are publishing. Never paste:
- Secrets: passwords, API keys, tokens, database credentials, private keys. (This is why BEG-055 read credentials from environment variables rather than the source file.)
- Personal or customer data: names, addresses, emails, account numbers, or real database rows.
- Private or employer code, unless your employer's policy allows that tool for that code.
When you need help with an error, paste a minimal example with fake values. If you pasted a secret by mistake, treat it as leaked: rotate it (replace it with a new one) and tell the person responsible. GitHub's documentation also warns that generated code can itself expose sensitive information or introduce vulnerabilities, which is one more reason to review it.
Academic integrity
Courses publish rules about AI. Three common arrangements are: AI is not allowed; AI is allowed for some uses (for example explaining errors, but not writing the solution); or AI is allowed if you disclose it. Your course's rule is the one that applies, and "everyone does it" is not a rule. If the rule is unclear, ask your instructor in writing and keep the answer. We could not verify one universal standard to cite here; policies differ by institution, so this lesson stays at the level of "find your policy and follow it".
Whatever the policy, the same principle holds: you are being assessed on your understanding. Submitting code you cannot explain as if you had written and understood it is dishonest, and it also means you have not learned the skill. The lab in this module asks you to explain the final code in your own words, which is both the learning and the evidence.
What a good disclosure contains
An honest disclosure is short and specific. It answers three questions:
- Which tool? (Name and, if you know it, the version.)
- What did you use it for? (Draft a method, explain an error, suggest test ideas.)
- What did you check or change? (The tests you wrote, the bugs you fixed, the lines you rewrote.)
"I used AI" is too vague to be useful. A good disclosure also shows your own work: it tells the reader what you can vouch for.
Examples
Example 1: a disclosure line (simple)
A README at the end of the module's lab:
## AI use
Binary search was first drafted with an AI assistant (tool: <name of your tool>).
I wrote the tests from the requirement before pasting the draft, found and fixed
a boundary bug in the loop condition, and can explain every line (comments in `Search.java`).It names a tool (fill in yours), says what it was used for, and states what you did. The reader can also see that the tests came first, which is evidence of a sound process.
Example 2: deciding what to paste (practical)
You are stuck on a failing method and want to ask an assistant. Check each item first:
| Candidate | Paste it? | Why |
|---|---|---|
| The method with the bug, and the exact error message | Yes | Needed for a good question; no secret in it |
application.properties with the database password | No | A secret; replace it with DB_PASSWORD=<placeholder> or leave it out |
| A CSV export of 200 real customers | No | Personal data; build five invented rows instead |
| The whole employer repository | No (unless your policy allows it) | Private code; reduce the problem to a minimal example |
| A stack trace containing a file path with your username | Check first | Remove personal details and re-read the trace before sending |
The pattern: share the smallest invented example that shows the problem.
Example 3: one task, three policies (realistic)
You used an assistant to draft a canBorrow rule, then wrote tests and fixed a bug. What you do depends on the policy:
- Policy A: "no AI tools". Do not use it. If you already did, tell the instructor rather than hope nobody notices.
- Policy B: "AI for explanations only, not solutions". Asking it to explain a trace is allowed. Having it write the method is not, even if you rewrite it later. Ask the instructor if you are unsure where your use falls.
- Policy C: "AI allowed with disclosure". Submit with a note such as: "The
canBorrowrule was first drafted with an assistant. It used<=where the requirement needed<; my boundary test (3 books at limit 3) caught it. I rewrote the condition and the tests are mine."
The same work is honest under C and a violation under A or B. The code did not change; the rule did. That is why you check the policy first.
Backend Insight
In a company, three of these rules turn into daily practice. First, policy: many employers approve particular tools and forbid pasting source code or customer data into others; breaking this can be a security incident, not just bad manners. Second, licences: shipped products need an accurate list of the open-source code they contain, and unknown provenance is a risk teams avoid. Third, review: a pull request with generated code is judged like any other. The author must understand it, and the team may ask what tool helped, as a matter of traceability rather than punishment.
The habits from this lesson (minimal examples with fake data, a note about where code came from, tests that prove it works) are what make generated code acceptable to a team.
Common Mistakes
Mistake 1: Assuming that code from an assistant is free of any licence concern
- Incorrect: "The tool wrote it, so there is nothing to check."
- Correct: "It may resemble existing code. For short, ordinary code that is unlikely to matter; for long distinctive blocks I check the source and follow the policy."
Mistake 2: Pasting real credentials or customer rows to get help faster
The risk (a leaked key, exposed personal data) is much larger than the minute you saved. Use placeholders and invented data.
Mistake 3: A vague or missing disclosure
"I used AI" says nothing about what you did. Missing disclosure where it is required is an integrity violation. Name the tool, the use, and what you checked.
Mistake 4: Submitting code you cannot explain
If a classmate or reviewer asks "why this line?" and you cannot answer, the work is not yours yet. Go back to lesson 2.
Exercises
Level A: Foundation
A1. What three things does an honest disclosure contain?
أظهر الحل A1
A1. The tool used; what you used it for; what you checked or changed (for example the tests you wrote and the bugs you fixed).
A2. Which of these may you paste into a public assistant? (a) A method and the exception message it throws. (b) An API key for a payment service. (c) A table of invented test rows. (d) A list of real customer emails.
أظهر الحل A2
A2. (a) Yes: it has no secret, provided the message has no private data. (b) No: a secret. (c) Yes: invented data. (d) No: personal data.
A3. A repository has no licence file. Is it free to copy into your project? Explain.
أظهر الحل A3
A3. No. Without a licence, default copyright applies, so the author keeps the rights and others cannot copy, change, or distribute the code. Ask the author, or look for an alternative with a licence that allows your use.
Level B: Application
B1. You asked an assistant to draft isValidPin, wrote the tests first, found that it accepted a five-digit PIN, and fixed it. Write a two-sentence disclosure for your README.
أظهر الحل B1
B1. Example: "The isValidPin method was first drafted with an AI assistant (tool name here). I wrote the tests from the requirement first, found that the draft accepted a five-digit PIN, and fixed the length check; I can explain each line."
B2. Your course says "AI may be used to explain errors, but not to write graded code." You asked the assistant to write the whole method and then edited a few lines. Was that allowed? What should you do now?
أظهر الحل B2
B2. It was not allowed: the policy permits explanations, not writing graded code, and editing the result does not turn it into your own work. Tell your instructor what you did, ask how to proceed (most likely redo the method yourself), and follow that answer. Telling the instructor early is better than being found out.
B3. Rewrite this disclosure so it is useful: "I used AI for some parts."
أظهر الحل B3
B3. Example: "I used an assistant (tool name here) to draft search and to explain a stack trace. I wrote the tests myself, found and fixed one off-by-one error, and wrote the comments in my own words."
Level C: Challenge
C1. An assistant gives you a 40-line sorting routine with unusual variable names and a comment you did not ask for. Write a short checklist (four steps) for what you do before using it.
أظهر الحل C1
C1. Example: (1) Check your policy for whether such use is allowed. (2) Search a distinctive phrase from the code or comment to see whether it appears in a public project. (3) If it matches, find that project's licence and follow its conditions, or write your own version. (4) Whatever you keep, trace it, test it, and explain it, and disclose the use if required.
C2. Write the "AI use" section of the README for the module lab (a search method, a hash map operation, and a Library borrowing rule). Include the tool, the use for each method, the evidence that the tests came first, and one defect found.
أظهر الحل C2
C2. Answers vary. A good one lists each method (for example: "search: drafted by the assistant, bug in the loop condition"; "removeKey: drafted, tests passed first time, I read and traced it"; "canBorrow: drafted, <= should have been <"), says the tests were committed before the code was pasted, and describes one defect with the test that caught it.
Mini Challenge
Write a one-page "AI use policy for myself" that you will follow for the rest of the course. It must contain: where you will check the rules before using an assistant; three things you will never paste; the exact format of your disclosure line; and one situation in which you will choose not to use an assistant, with a reason.
Check your work: the policy points to a real source of rules (your course page or instructor), your three "never" items are specific, and the disclosure line contains tool, use, and what you checked or changed.
Summary & Next Lesson
Key takeaways
- Generated code can resemble existing code, so licences may apply. Follow the policy of the place you submit to, and be careful with long, distinctive blocks.
- Never paste secrets, customer or personal data, or private code into a public assistant. Use minimal examples with invented data.
- Academic integrity means following your course's AI rules and being assessed on your own understanding.
- An honest disclosure names the tool, what you used it for, and what you checked or changed.
- Submitting code you cannot explain as if it were yours breaks the rules.
Next lesson
The next lesson, "Demo: catching a subtle bug in generated binary search with tests", puts the whole module together on one example, and prepares the lab. It also closes the Beginner level with a look back at how its modules fit.
Self-check
- Why might generated code raise a licensing question?
- Name three kinds of information you must never paste into a public assistant.
- What do you do when your course's AI rule is unclear?
- What three things does an honest disclosure contain?
- Why is code you cannot explain a problem even if it works?
أظهر الإجابات
- A suggestion can occasionally match existing public code, which may be under a licence with conditions.
- Any three of: secrets (passwords, keys, tokens), personal or customer data, private or employer code.
- Ask your instructor, in writing, and keep the answer.
- The tool, what you used it for, and what you checked or changed.
- You cannot vouch for it or maintain it, and you are being assessed on your own understanding.
References
- GitHub Docs, Responsible use of GitHub Copilot code completion. It says suggestions can occasionally match public code, that matches are blocked or shown with source and licence depending on settings, that generated code may expose sensitive information or be insecure, and that users take on the risks of generated code. It describes one tool; other tools differ.
- GitHub Docs, Licensing a repository. It says that without a licence default copyright applies and others cannot copy or distribute the work, and that an open-source licence lets others use, modify, and share it.
- Open Source Initiative, Licenses. It describes open-source licences as giving broad freedom to use, modify, and share software. It did not state the conditions; that "licences have conditions" comes from the GitHub page and general knowledge, and was not verified for specific licences.
- Not verified: any statement about copyright law for AI-generated code, and any universal academic-integrity standard. The lesson deliberately defers to your own policy for both.
التطبيق
طبّق هذا الدرس بمختبر الوحدة وتمارينها واختبارها.
تعليم الدرس كمكتمل اختياري ويمكنك التراجع عنه في أي وقت. يبقى تقدمك محفوظًا في هذا المتصفح.