On Sat, Nov 15, 2008 at 12:05 PM, Andreas Ericsson <ae@op5.se> wrote:
The case I had in mind is not that but this: say I write a patch which
is totally open-source and uses only open-source software to add some
feature to libgit2 but I want to link that libgit2 + mypatch to a
closed source application (say, for instance, software for military
use, which I'm not allowed to open source). To state it clearly:
- My contribution is 100% open source
- My contribution is 100% towards libgit2
- In fact, I could add that very feature to my application instead of
libgit2 but as I'm open-source-friendly, I decide to contribute that
patch to libgit2.
For some reason, that patch:
- Is not accepted for some time (for instance, I'm thinking in that
tcl/tk limitation which is preventing Junio from merging a patch, it's
been in the "what's cooking" for some weeks now)
- Or is not accepted at all
According to what you said, I only have two options:
- Either I fork libgit2, or
- I keep my feature in my application and do not contribute my feature
to libgit2
It looks even more insane now!
What about rephrasing the libgcc exception to something like: "if you
have a patch, and sent us that patch, but we put the patch in stand-by
or declided the patch, you are still allowed to combine libgit2 with
your closed-source application". After all, the fault is not in the
closed-source part (I contributed the patch, it is 100% open-source
and only uses 100% open-source) but in the libgit2 part (patch is on
hold or not accepted at all).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html