begin quoting John H. Robinson, IV as of Mon, Aug 22, 2005 at 10:53:03AM -0700: > Stewart Stremler wrote: [snip] > > So if a rider were allowed -- say, "if you contribute code that is accepted, > > then so long as that code is in the product, you will have your existing > > license applied to the product" -- people would have much less of a problem? > > If you own the code you contribute, you have a say in your code getting > relicensed.
Is there such a concept as dual ownership? You own original code you contribute AND the original vendor does as well? > This is why the FSF encourages projects with multiple people > to say ``GPL v2 or later'' instead of ``GPL v2''. This way the license > can be ``upgraded'' w/o having to go to foreach ($TEAMMEMBER) for > permission to change the license. When GPL v666 comes out and RMS claims ownership over all software, there will be a lot of annoyed people. > So, I think the answer to your question is ``yes.'' I think that if I (generic) get a license to subsequent versions of the product to which I have contributed code (but I don't have distribution rights to that product), I would be *more* motivated to contribute meaningful patches. The whole "I got mine" attitude... > > As I see it, we have two fears -- one, that the author will turn into a > > moocher, and two, the users will be nothing but moochers -- but only one > > seems to be addressed at a time. > > Are they both addressable? Or do we have to seek a middle ground > somewhere? Is it a cd speed/case colout thing, or more of a > security/convenience thing? Good question. I would *like* to think that they are both addressable. Thus my scheme of "you contribute, you have a llcense to the code and source for as long as your code [plus one version?]" -- contributors are rewarded for contributing, vendors are motivated to provide source code to their users, and the moochers are left whining that it isn't a fair license. [snip] > I've had my patches applied upstream (WindowMaker and MRTG). I don't > have much of an issue for small patches. It could be an issue if it was > a larger patch, like say adding SSL to a client/daemon, or adding a new > filesystem to a non-modular linux distro installer. Those I might be > more interested in keeping under a license I like. Yes, very large changes are problematic. Coordination with the author would probably be wise before undertaking such a venture, even with GPL software. > > When the author/vendor makes it easy to provide feedback, ideas, bug > > reports, and improvements -- and then acknowledges your contribution -- > > it's a joy to do so, even if you give up your "rights". When they make > > it difficult, and then disregard your contribution, it's hard to justify > > the effort, even if it's "more free". > > Agreed. This is why I avoid anything that uses bugzilla. Heh. Bugzilla isn't the worst by a long shot. [snip] > Monopolies suck. Unregulated ones even moreso. Amen. -Stewart "Let there be... alternatives." Stremler
pgpnwSn0QK57z.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
