Licensing – Should I Include Myself as an Author After Modifying 3rd-Party Code?

language-agnosticlicensing

It's common practice to make some tweaks or fixes in 3rd-party code (be it a simple gist or an entire library). But it's also common that many of these code have their own licensing rules and eventually a header on every file with copyright informations.

After making those modifications what's the correct thing to do next? Keep the licence info untouchable or try to update it including yourself with something like @author or @revision tags?

Another common problem is changing the 3rd-party namespace/package to fit it to your project conventions. Some license types include these kind of information in their license block, can I change it freely?

I know the answer for these questions depends on each license type, so to make my question more specific…

Considering general license rules (usually they are different in minor aspects, right?), is ethical(or at least allowed) that I freely add information to the license block about my modifications and perhaps also modify how do I refer to it in my code (e.g use YACorp.YALib as Utils.YALib)?

Best Answer

After making those modifications what's the correct thing to do next? Keep the licence info untouchable or try to update it including yourself with something like @author or @revision tags?

I think you're confusing the software license and any prologue that might be part of the software.

The license is where the owners of the copyright to the program specify the terms of use (the license) for other people. Some licenses are very permissive, others are much more restrictive.

The prologue is where authors insert @author and @revision tags to provide a way to track changes to the source code. In some cases, becoming an author of a non-trivial addition to the code may give you claim to the copyright over that section of the code. Disentangling copyright concerns can be thorny and is best handled by attorneys. However, you specifically stated you're not concerned with that aspect so I'll move on.

Another common problem is changing the 3rd-party namespace/package to fit it to your project conventions. Some license types include these kind of information in their license block, can I change it freely?

This really depends upon the conventions of the project.

If you fork the project, you can do whatever you want.

If you plan on contributing your changes back to the project, you should stick with the established convention. If there's a compelling reason to change the namespace then you need to present that to the application's community.

Considering general license rules (usually they are different in minor aspects, right?),

is ethical(or at least allowed) that I freely add information to the license block about my modifications and perhaps also modify how do I refer to it in my code (e.g use YACorp.YALib as Utils.YALib)?

Don't change the license!

First off, you likely do not have the legal rights to change the license. Second, any changes you make are likely going to mess up the license. Leave license changes to the attorneys.

As far as updating the prologue, it depends upon project norms. Some projects don't want a prologue because they use source control to track that. Other projects do. Follow the project's conventions.

Actualy my concerns are more about "respect to the community" than the legal aspects, I'm asking more about how much we can "go wild" remaining ethical if our project can be considered private or personal.

If you're keeping your changes to yourself, why do you care what others think? Something that you use only for yourself and never distribute to others has no impact back upon the original project. So they don't care what you do.

If you plan on distributing your changes or contributing them back to the project, you need to evaluate the conventions of that project. Some projects don't want to be forked and will have a license in place preventing that. Others go so far as to say "do what you want" and you're given carte blanche to do as you see fit. Ultimately, the answer here depends upon the particular project you're looking at.

Related Topic