I wonder if it’s a good Idea to unlist this topic after @hanakp has reached his conclusions. I guess it’s a good compromise to helping a teacher, and not giving (too many) students ideas on how to thwart plagiarism detection.
2 Likes
@eelik Thanks for the tips. I tried extracting component UUIDs in the meantime, and it doesn’t even need any programming. I feed SCH files to (Windows) Grep, search them for “(symbol” string and take next 10 lines. I pipe them to another Grep which returns bare UUIDs. I feed them all to a text file, and use Sort and/or Notepad++ to detect whether there are any duplicate lines. It’s ugly and I have to check the results manually, but I need to do this only once a year. Nevertheless, I’ll probably add some simple improvements, like separating blocks of UUIDs with source file paths etc.
I actually looked inside the files before I even asked here and I indeed wondered about the “paths” in PCB. The students have to do both SCH and PCB and they have to be properly synced etc., I check all that personally in front of them. So next year I’ll probably ditch SCH analysis altogether and just extract paths from PCBs instead.
@paulvdh Yeah, I was reluctant to even ask about it here in the first place. Do you have the rights to hide or delete threads?
Before KiCad, I’d been teaching Eagle and I developed 2 other methods do detect plagiates. But they’re less reliable with KiCad. On the other hand, maybe other teachers could find my script useful, even if it’s currently just 6 lines in Windows CMD file.
BTW, out of 61 projects, I detected 2 plagiates with my old methods and 1 more via UUIDs…
Any moderator, and all level 4 users have the ability to unlist topics. Unlisted topics do not show up in the index, and do not show up in searches. This is mostly used to fight spam.
I am not a moderator, I also don’t want to be a moderator, as my social skills are a bit “below average”, but as a regular I’ve reached level 4 and I have unlisted a bunch of spam topics from this forum myself.
It’s (very likely) not a total delete. All posts and edits are logged in a sourcecode revision system (probably GIT) and I have no control over that. It’s a system which can be used to for example repair deliberate damage to posts.
Why not make them turn in their Git repos? It’ll be a lot harder to hide repurposing someone else’s design than the circumvention to this plan, which is sed -i '/uuid /d' *.kicad_{pcb,sch} (delete all UUIDs and let KiCad generate shiny new random ones on next load).
Plus forcing them to learn version control if they don’t already know it is a hugely useful skill in itself.
1 Like
I would still say that using “path” would be better than using “uuid”. It would be of course possible to write a script which replaces each “path” in both the schematic and the PCB, so it’s not foolproof either. But nothing is.
Using git is an interesting idea. Git is designed to ensure integrity. It would be difficult to forge the history. Even the hash of the first commit is unique for each new repository made from scratch.
BTW, the OP said
Is the goal to teach to use KiCad, or is it just a tool to design circuits/boards? If the goal is to learn KiCad, any check which prevents copying without knowing how to do it in KiCad helps at least a bit. If the goal is to learn circuit design, nothing prevents looking at an existing schematic/PCB and creating the same with KiCad, and uuid/path/git history doesn’t matter.
Whatever you do, nothing is foolproof. For example, I can ask ChatGPT: “Can I copy git history using diffs and create a new repository based on those with similar commits but different commit hashes?”
It gives at least something to work on. It’s enough that one student is a semi-malicious hacker and writes a script which is applied to the original to create an undetected copy.
In short, if there exist steps to copy and modify a project, which steps can be applied manually without using KiCad, they can be combined in a script which anyone can use. Therefore the check should use some kind of fuzzy logic. It should force the students to take some steps which necessarily vary from one case to another. But I don’t know it that’s possible. For example, for a hacker student it would be possible to modify a final version of an existing KiCad project, then to create a counterfeit git history by creating random chunks of diffs to create commits. At least the examiner should peek into the commit message history to see if it’s sensible. A commit history with sensible messages should then be part of the project requirement. This, combined with automated checks for KiCad files and git repository details might be pretty efficient.
@johnbeard Heh, this is exactly what I was afraid of: that somebody would come along and spill some one-click trick to work around UUID detection. Now I’m really thinking about hiding this thread…
@eelik The goal is both. You can see course annotation here, KiCad section is near bottom. Most students will never use it (or any other PCB EDA) again, but about 1/5 need it for their bachelor’s/master’s thesis. Unlike most manuals, YouTube videos etc., I don’t just teach them “how to click in KiCad”. I intersperse it with real-world considerations like applicable standards, part naming conventions, grounding layout, PCB manufacturability etc. I also spend lots of time demonstating various bugs, pitfalls and general clunkiness, which are unfortunately plentiful in KiCad. (Breaking board sync after cutting and pasting in schematic is one of them.)
Anyway, as a rule of thumb, students who would be smart enough to create elaborate fakes generally don’t tend to cheat in the first place. Using GIT would be another huge headache on top of KiCad, since KiCad itself is already rather user-hostile, particularly to beginners (which about half the students are). But, desktop Eagle will die in 2026 and I refuse to use (and teach) some cloud-based garbage like Autodesk Fusion or Altium 365. It’s one of the reasons why I’ve already replaced most commecial software with open source variants, and KiCad was just another in line.
@johnbeard Maybe edit your comment? No need to give lazy students nefarious idea’s.
I don’t really agree with this. I started with KiCad over 10 years ago, and during evaluation I made my first PCB in KiCad in the first afternoon I Installed KiCad. Back then KiCad had a lot more “missing features”, faults and gaps in it’s capabilities. And the “Getting started in KiCad” was enough back then (KiCad V3 or so, even version numbers were a bit vague back then) to get an idea of the workflow in KiCad and avoid the biggest pitfalls. Also see this other thread: [feedback] My first PCB. Felt pretty easy... what am i missing? - #11 by Piotr A beginner, first project, (probably) did not read much of the manual, was apprehensive to start, but still quite liked his KiCad experience.
For your course:
I understand Git is a bit of a sidetrack. But IMHO KiCad should just be a vehicle, and not the main part of the course. Things like signal integrity and EMC considerations. How to get routing done on a 2 layer PCB while keeping it compact is a puzzle on it’s own, but these days 4 layer PCB’s are getting pretty common. Prices are reasonable, (especially in bigger production runs, the cost difference is manageable). 4-layers also make it much easier to be on the safe side of EMC regulations, and it saves a lot of design time. Two factors that can drive up costs significantly.
Rick Hartley (from altium) has made a 2hour and 10 minute video about the importance and use of GND planes. It’s a very good video with a lot of background info. I think I saw it two, maybe 3 times myself.
No question about that, KiCad v8/9 is light-years ahead of what v4 used to be. It already surpasses some commercial packages (coughOrcadcoughPADS) when it comes to user interface and general usability. But the fact is, Eagle “just works”. You can concentrate on actual design, with no worries about proper symbol/footprint matching, net name conflicts, never-ending manual syncing and other headaches. Sure, Eagle is dated and has its own quirks too, but for total beginners, there was no better option. Its name is acroym for Easily Applicable Graphical Layout Editor and it actually did live up to it. Every year, me and my colleagues used to sat down and mull about other PCB EDAs. But at the end of the day, Eagle had alway won because it’s clean, simple and easy to use. That’s why it became so popular among european hobby community back in early 2000s. But, desktop Eagle is going to die in 2026. In fact, it’s already been dead for the last 4 years. And KiCad is the best (desktop) alternative there is.
During the course, I actually force the students to do a single-layer layer board first, so they would understand the importance of proper component arrangement. Because that’s the most important part of PCB layout, especially on SMD boards. Only then I move to 2 and more layers. Unfortunately, even official KiCad tutorials are as bad as the project you’ve linked - trivial boards that unnecessarily use 2 or more copper layers and super-thin traces. Cringey stuff, even if 2-layer PCBs cost next to nothing these days. Sadly, prevalence of similar “examples” online makes it harder to explain that such ineffective board design has other disadvatages, too. Oh well.
Anyway, the course already devotes 2 hours to grounding and another 2 hours to EMI/RFI prevention. And there is a different course about EMC testing. But as you can imagine, it’s not very popular…
Students generally aren’t smart enough to hide their plagiarism very well. Those who are smart enough are also smart enough to do their own work.
A couple of years ago I did some random searches for some keywords I used in my blog. I discovered a graduate student at a large US university had lifted two long paragraphs from one of my blog entries and inserted them into his project report verbatim as if they were his own work. I wrote to his college, saying that while I was tickled that someone had found my musings helpful, I expected these paragraphs to be formatted as a citation with proper attribution. I also pointed out that this sort of thing could have been a career-ending event, had it been a significant published paper rather than a rather mundane project. I received a very apologetic reply from his supervising professor, and a later check showed that the report had indeed been corrected with a proper citation.
I only wish I’d been in the room when the professor met with his student. 
3 Likes
Good to read 
These days, there is no price difference at all for single or dual layer PCB’s in the “pooling services”. Single layer PCB’s still exist, but it’s mostly mass produced FR2 such as SMPS power supplies, and cheap consumer stuff. I understand encouraging the students to learn routing on a single layer, but in these modern times, it makes more sense to me to have one continuous GND plane on the back layer, and do all footprint placement and the routing on the front.
When I was evaluating a new PCB program, I tried eagle too, and I found it horrible. I was used to older programs having separate symbols and footprints, and I could not get the hang of how the concept of “parts” worked in eagle. My motivation for learning eagle was also quite low, because it was not an open source project. My guess of it’s popularity back then was that it was “free” and “usable”. That’s a good enough combination for a lot of hobbyists, but I was also already frowning my brows about the board size and layer limits. So I never looked back after evaluating KiCad a week later.
Eagle libraries are one of the main reasons why it’s so easy for total beginners. You don’t have to deal with (extremely error-prone) footprint assignment every single time, because someone else already did that for you. And there is another huge advantage: imagine you have a MCU with 200+ pins that comes in TQFP and BGA package. In KiCad, you have to create 2 symbols with totally different pin numbering. In Eagle, you draw the symbol only once and then create different pin-pad mapping for each package (they call it “Device”). You can also map multiple pads to one pin. AFAIK Eagle and Diptrace are the only EDAs that handle this mapping in sane and efficient manner, all others need to resort to various clunky and error-prone workarounds. Unlike KiCad, Eagle won’t even allow you to switch to a footprint that would result in wrong pin-pad mapping. That’s a big plus for beginners. Sadly, Eagle libraries are getting quite dated now, even though Autodesk made deals to include libraries from Beaglebone and other popular projects.
Granted, most EDAs tout the “footprint assignment freedom and library reusability” mantra. But in reality, if you did the assignment blindly, vast majority of them would be wrong. Even I get it wrong sometimes. As for the reusability, KiCad libraries already contain hundreds of identical footprints just with different names, so that footprint filters can work. Because as it turns out, the “total assignment freedom” is simply too cumbersome to work with. I still vividly remember the nightmare from earlier Orcad and KiCad releases, when a list with thousands of footprints popped at me and I had to manually choose the right one. Thankfully, KiCad librarians spent an eternity to make the footprint filters work, so we don’t have to deal with that.
When I was evaluating my new to be EDA suite (during switch from Windoze to Linux), one of the mayor things for me is how easy it is to create new symbols and footprints, because there are always parts that are not yet in libraries. For me, an extra layer of indirection is just needles complexity and annoying. eagle is not “better” (or worse") in this regard. It’s just different. Different people think in different ways. But to be fair to eagle, I never got far enough to figure out exactly how that indirection layer works. The way KiCad works is much closer to what I expect and appreciate. If I had spend more time with eagle, I may have gotten used to the way it works. And that is also an important issue. When you get to know software better, you learn to appreciate it’s strengths, and live with it’s (perceived) weaknesses and workarounds. After a few years you can even get to the point that you forgot what the workarounds are. You’re just grown used to how it works. That is also one of the reasons that it’s difficult for people who have used a software package for a long time to write a “getting started” manual. Such manuals are (probably) best written by people who started recently and struggled though the quirks and discovered the workarounds so it’s all fresh in their memory.
I don’t think hiding trivial, and it is trivial, information is the solution. If that’s what a system hinges on, it is misguided at best. You may detect the unlucky few that copied files wholesale, but it is blind to those who figure out or luck into the “trick” of changing UUIDs. sed is just one option: g/awk, grep, Python, Bash, Perl, PowerShell, etc., not to mention good old copy-paste, will all work.
The solution is not to misuse technical implementation details to produce a fundamentally unsound detection system because it seems like a nifty trick at first glance. That is simply not good engineering and worse pedagogy. Specifically, it’s most unfair on the good students being lumped in with plagiarists who by luck or insight go undetected.
Even without formal version control (which I maintain is a core concept that should be being taught early on by any institution that claims to educate competent engineers in 2025), the traditional solution hasn’t ever stopped being highly effective and useful for far more than plagiarism detection: notes, diagrams and screenshots on the development of the project in a log book. Faking a log book retrospectively is an incredible amount of effort, and basically impossible to do for practical benefit if you stamp the pages or otherwise checkpoint the document (i.e. it’s another kind of version control)
Unfortunately, even official KiCad tutorials are as bad as the project you’ve linked - trivial boards that unnecessarily use 2 or more copper layers and super-thin traces. Cringey stuff
KiCad documentation is open for merge requests for the track width. Remember that the example is designed to show how to flip component side, so it naturally has things on both sides. It’s a tutorial on KiCad usage basics, not a tutorial on designing a good board for an specific application with specific constraints like “single-sided placement for once-through placement and reflow”.
As for the reusability, KiCad libraries already contain hundreds of identical footprints just with different names, so that footprint filters can work.
KiCad specifically does not require duplicating footprints by decoupling symbols and footprints. the libraries sometimes get a few duplicates because a manufacturer called a TQFP a VQFP and we didn’t notice we already had a compatible part. And sometimes we have footprints that differ only in 3D model and description (something I’d like to eventually change). We also have some variants of footprints to allow users to select better alternatives for their applications (long pads, handsoldering, without thermal vias, etc). But we don’t generally keep straight duplicates for filter convenience.
That is a weak point in KiCad in my opinnion too. If I place a transistor in schematics, I don’t care if it is BCE/GDS or whatever. I’ll decide that later when assigning a specific type. KiCad forces you to make that assignment in an (too) early stage. OTOH, I had my problems with the pin assignment in EAGLE when I started with it.
The reason why I used EAGLE was initially just because there was a free version. Later on, I used EAGLE at work (paid version), but I never liked the UI. For me, it was as odd as LTSpice still is to me. For me, it is “the wrong way round”. While using EAGLE at work, I watched KiCad and then, when I saw a video how shuffling works, I tried KiCad for a simple private project and was convinced. Used KiCad at work for a small 4 layer board and after that quit using EAGLE. I think that was KiCad version 5.
You don’t spend most of the time assigning footprints. You spend most of the time drawing a schematic and for making the layout. All my fault. You just have to be aware of the possible pitfalls.
And yes, I tripple check my double checks for footprints. And it went wrong in KiCad and EAGLE.
Anyhow, what is your criteria for detecting a plagiat? In schematics? In layout?
In schematics, it might be the netlist and values (resistors, caps, type of transistors). In layout placement and how the routing maze was solved.
Netlists should be easy to compare.
Placement gets more fuzzy as components might have been moved a bit. Criteria might be the geographical relation (X/Y distance) between parts with some allowance in distance (like +/- 10%).
If I place a transistor in schematics, I don’t care if it is BCE/GDS or whatever.
FYI, you can use Device:Q_NPN (say) for this. There are many “generic” devices in the Device library that don’t have pin assignments. In fact, we have recently started moving many devices with pin assignments out of the Device library into Transistor_FET/BJT etc.
Sure, it is trivial, and it won’t help against the nefarious. But student plagiarism is usually done by the lazy students. Those probably don’t even know KiCad has UUID’s in their files without (accidentally) reading a thread like this.
Thanks for the heads up! Next time, I’ll look better.
Just checked …
The problem (by design) of KiCad is, that there are no symbolic pin names. IIRC, in EAGLE, you had the symbolic names B C E and later in the design process, when you selected a specific transistor, you made the assignment to pin numbers (automagically with the translation table).
OTOH, if you look at µCs, pins do have multiple functions like GPIO, USART, ADC for a single pin. Now what name do you choose? You’d have to make a translation table that maps ADC to pin 1, USART to pin 1, … etc. But that only works until the µC offers pin remapping. So for example TX1 could be assigned to a set of pins (pick only one) but just once.
Oh well! Maybe the way KiCad does it is better in the long run. And only annoying at a first glance.
This is supported by KiCad, although the necessary information is not present for all microcontrollers. All STM32 seem to be good in this regard (I guess the symbols are generated from a script). To change the pin name:
- Place an STM32 IC on a schematic.
- Edit it’s properties by hovering over it and press e.
- Go to the Pin Functions tab page.
- Choose one of the available names from the Alternate Assignment column. I changed PA6 to an ADC input, and PB1 apparently has 4 alternative assignments available.
I don’t know of any plans to do this, but maybe someday someone will write a script to read these alternative pins directly from external sources such as STM32Cube.
In my first trial with eagle, I wanted to draw a simple schematic, without even having the intention of making a PCB. I happened to have a 0.2 Ohm shunt resistor, and I could not put such a resistor on the schematic in eagle. You could not type in a value for a resistor!
When I’m brainstorming an Idea, I don’t want to be bothered with details that are probably not ever relevant. It distracts and destroys the flow of the creative process. And sure, having to verify pin mapping between symbols and footprints is also not ideal, but you only do it when it’s needed, and after some time any sensible person would build up a personal library of verified parts. In bigger companies it’s even common to have people dedicated to maintaining libraries and verifying their integrity. (That’s also where KiCad’s database connection is invaluable to a lot of people. I don’t know if eagle has anything comparable to that.)
Dammit. I have the feeling I need some update by reading the manuals.
Thanks for the education!