Somehow I prefer the real Johnson over any of the figurative ones... ;)

Trump? One giant f-you that feels good? Be aware that nine months later, you might discover unintended consequences... :-)

I would ask you: do you understand how the code works? Are you adding reasonable features, or fixing user-visible bugs? Are you restricting your changes to items that will achieve the project's goals, and meet the required deadlines?

If you are not doing these things, your changes are doomed to fail. If you are creating huge changesets that require additional review [time which could be spent making meaningful changes] but do not add (or fix) functionality, you are wasting the senior's time. Worse, if your changesets have bugs, you are actively hurting the development effort.

So what do you do? Add comments to help you find your way around; perhaps make suggestions as to how you think the code should go. Focus on how you can make a positive difference, and earn the senior's trust to rewrite the sections that bother you the most.

Change for the sake of change -- or to meet some irrelevant book's standards -- does not make production code work any better. And that's the usual goal. Be very aware of it.

If tuition was paid, can't the lecture be considered work-for-hire, and thus the shared property of all tuition-paying students?

Furthermore, if the professor draws a paycheck from the university, how does he have the copyright rather than the university? Does he lack standing to legitimately file suit?

And finally, if he's conveying knowledge -- the knowledge cannot be copyrighted, can it? Only the exact expression of it can be, not any notes or works written therefrom. Otherwise every textbook writer out there would be... well, SOL.

Disclaimer: I'm not a lawyer, but I do read too much Groklaw.

MKP has prior art on his web site...

http://mkp.net/glo-loo.html