Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Forking procedure (Score 1) 96

by cheba (#44582111) Attached to: Open Source Licensing Debate Has Positive Effect On GitHub

It's great that more and more developers think about licenses. Though, there's one aspect that I find... underdocumented.

From time to time there may arise a need to fork a project. Either changes are out of the scope of the original project and they wouldn't ever be accepted upstream, or the upstream maintainers are not as responsive as community requires or for whatever other reason there may be. It's counter-productive to keep the original name (and have basically two diverging projects with the same name) or have original authors listed as the maintainers to be bothered about bug/features in the project they don't maintain (I'm not talking here about attribution).

So what's the proper forking procedure? Is there any differences depending on the project license?

Ya'll hear about the geometer who went to the beach to catch some rays and became a tangent ?

Working...