On 3/31/07, Chad P. [email protected] wrote:
Good for you.
No need to be rude.
Funny – “Good for you.” was my way of saying “No need to be rude.”
I apologize if what I said seemed harsh. That was not the intention.
- I tend to dual-license whenever anyone really wants it.
Dual licensing is an acceptable way to provide both your terms and a
more standard set of terms, but it’s not ideal. It means if I want to
contribute back to you, I still need to understand your home grown
license, which, at least in my case, means you’d be less likely to see
contributions from me.
So sorry. If I don’t like the license you’d rather use, it’s not the
license I’m going to use. That’s pretty much tautological.
That’s not what I mean. I mean that if you dual license something, it
does create a complication.
For example, anyone out there using license of Ruby, if you’ve broken
GPL compatibility in your distribution by accepting GPL incompatible
patches, well, you can’t meaningfully use the same distribution terms
as Ruby 1.8. Ironically, same goes if you’ve accepted patched under
the GPL itself.
Dual licensing tells the user they have a choice, but the distributor
needs to maintain compliance with both of the terms they distribute
under. Someone please correct me on this if I’m wrong, because I’ve
had this interpretation for a while.
So what I’m saying is, I’d use code you wrote if it were under a
disjunctive license with the MIT license and the License Of The Flying
Oak Tree, because I’d just ignore the latter and treat it as if it
were under MIT.
But for me to patch back, and understand what rights I have to that
work, I’d need to understand License Of The Flying Oak Tree, and
unless I really care, I might not be inclined to go read that, so
you might lose my patch. Of course, I could also just offer it back
under MIT or some other compatibility, but then you’d be having to
keep track of all these different patch licenses, which sucks!
So my point is that if you use standard licenses, you avoid this
confusion. That to me is more important than bickering over wording
issues. If you’re in the case where you have serious issues with the
existing licenses out there, maybe you’re being sensible by rolling
your own, and being kind by dual licensing. But it seems to me these
cases are more rare than others, and when they do happen, someone
should be notified upstream of your concerns.
Have you contacted CC about your issues with their terms?
certain other licenses?
I don’t know. It’s certainly a hard problem. I’m not terribly happy
with most licenses, either. If I were working on end-user apps or
fringe stuff, I’d probably be less concerned with the potential
confusion of self-created licenses. However, most of my work tends to
need to play nice in a lot of places, be used by a lot of people with
varying opinions about stuff, and generally be diplomatic about its
So I choose LoR for all my Ruby work, similar arrangements in other
languages, and CC by SA for documentation. This seems to work for me.
Of course, like anything else, YMMV