Ask HN: What are best practices for creating a new OSS Project based on a fork?

6 points by jetti ↗ HN
I'm thinking of forking Nemerle since it has been somewhat dead for a few years and making it my own but I'm not sure what the best way to do that is. Is it as simple as just creating a fork and then changing the name? Is there legal obligations that need to be taken into consideration?

5 comments

[ 3.0 ms ] story [ 22.5 ms ] thread
I have a similar problem. I recently forked a project to fix some stuff and want to ship another project that will use it as dependency.

The owner of the original has been inactive and I can't have a discussion or get my changes merged, so I will have to add a version to my fork. With the changes being backwards incompatible, according to semver this would be version 2.0 and it feels incredibly wrong to release a major version of someone elses project without having talked to them.

How do others handle this and similar situations?

As for legal obligations, that very much depends on the license used by the original project. With the MIT license for example you're allowed to make changes and release those, but aren't allowed to claim the whole thing as your own creation (which makes sense because it's not). Not sure about changing names but iirc that's okay.

I would think there would need to be some sort of name change so that it doesn't interfere with future releases or to dictate differences (such as Jenkins/Hudson). But I'm not sure exactly how that would work
The title made me think you were going to fork the Open Sound System (OSS)

Anyways, you should probably read the license of what you're forking, but in general it should be OK to just fork it and give credit to the person who made the original. Again, though, read the license. Also, it's probably a nice thing to do to contact the original developer and tell them you're forking them.

It depends on the license of the project you are forking. Let us know the license first.
It appears to be 4-clause BSD