Should I include myself as an author after modifying 3rd-party code?

Question

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)?

Answer 1

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.

Answer 2

I would add a comment, partly to signal to a reader that the file is not "vanilla", with links to any relevant documentation or an issue tracking system.

Edit: So this situation reminds me of when a Linux distribution packages e.g. a library. Debian has guidelines and standards around how packages should be built and named, which could well vary from how the library is usually distributed pre-built.

I don't think you should be shy about naming / building / modifying a library, since I'm guessing you won't be distributing the result to the wider world? In this case I would include a README along with the source that describes what changes you've made and why. E.g. README.${companyName}.changes

Answer 3

You'll have to consult the licensing rule of the code.

In general, many open source frontend applications (e.g. Firefox, OpenOffice) considers their application name and logo as a trademark; so if you were to release a modified version of the app you will not be able to use the original trademarks/trade dress (thus IceWeasel, Torbrowser, LibreOffice).

However, most programming libraries are often less concerned about trademarks as long as it's fairly clear who does what (usually this can be found from the version control metadata).

Author information serves two purposes:

1. Giving credit where it is due
2. Giving blame where it deserves

The latter become more important as your changes become larger. The actual authorship information can generally be found in the version control, but some projects formally credit a set of authors in a separate file. The cutoff point where people would be formally credited varies for each projects, contact the original authors if in doubt.