views:

329

answers:

3

The languages used in the licensing are very confusing, and also it is getting very time consuming to read salient features.

Just need a license with which source code is open/re-distributable/fork-able (good if the parent project gets credit, non-monetary or monetary eg donations). But I shall be able to have control, put a stop list to further inclusions in terms of features/code. I other words it should be contributable in terms of features/code but i shall be able to manage it, so that it remains small tight and easy for others to learn, may be as case studies.

I think the best license for me might be MIT or BSD types. Of course, i might be absolutely wrong.

And, so if i start with licenseA can i migrate to licenseB. It might also mean, if i start in any open-license can i later migrate to copyrighted(proprietary) form, if I had too.

Thanks in advance.

+1  A: 

It all depends on the specific type of license you use.

If you originally use a restrictive license, and are the owner, I believe you can always make it less strict if you wish.

However if you freely distribute the source with a completely open license (freely modify/use for commercial/uncommercial) then I don't believe you can retract it later on (at least for the code you've already released).

Again, it depends on the licenses in question. All of them are different, so a generic answer isn't really going to cut it.

Ian Elliott
that's a good point. Start strict and then lighten up, but the problem then may be that people will not adopt it if the license is restrictive...
Tim
+7  A: 

You can choose whatever license you want for code since you are the copyright owner.

However, once you release a piece of code under a license, you can't revoke that retroactively. Estoppel would prevent you from showing users didn't have a valid license.

You can release a later version of your code under a different license (or even dual-license it) but, if users aren't happy, they're free to fork the old code provided they follow the terms of the old license.

That means users of your new code would have to follow the new license.

However, this has been done before by companies which built up their product in the community then tried to close-source it. I don't think it's ever worked out too well. Still, it's your code, you can do what you want with it.

As an aside, I would not be asking legal questions of anyone but a lawyer, and one trained in copyright law at that. Advice off the web is worth every cent you pay for it :-) It also depends on your jurisdiction - law is not consistent across the planet.

paxdiablo
Thanks, I am not sure, but I think yes, I pretty much get it. and also can u please recommend a license? Which is simplest to follow.
Vivek Sharma
None of them are simple. From your description, you want it forkable but you want to keep control - you can't have it both ways. The only control you'll have is over your particular build of the source; no-one can force you to add features to that. But you also cannot stop people from adding features to their own fork. I'd tend to choose "GPL for non-commercial" to stop companies "stealing" my work without compensation. You can always do add-ons as commercial only if you want a revenue stream while still giving to the community. MIT/BSD means you have *no* control IMHO.
paxdiablo
+1  A: 

Another point - if you include contributions from other people, they're usually done in the original license. Unless they transfer copyright to you first you can't relicense their contributions unless the original license allows it.

e.g. if they contributed to you under the MIT license, you can probably relicense to the GPL, but you can't relicense a GPL'd contribution to the MIT license.

orip