>>>>> "js" == Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> writes:
js> Do you really like Sun to be forced to verify that the kind of
js> such a patch is below the interlectual creation level to be
js> able to claim a copyright?
the common and IMHO correct practice, and the practice Sun actually
uses, is to assume all patches deserve the protection of copyright and
get contributor agreements from anyone who submits patches so that Sun
chooses the license, _and_ can change the license later (which Linux
cannot, which sucks for mostly everyone). Please stop spreading FUD.
Especially since you brought us through this exact same thing before
the last time someone brought up dual-licensing.
js> BTW: GPLv2 is still more open for license combinations than
js> GPLv3 is.
[...]
js> If you like to think about other licenses, you better stay
js> with GPLv2.
First, there is plain-GPLv2, Linux-modified-GPLv2 with the ``or any
later version'' clause deleted and the suspect ``interpretation'' of
kernel modules, and plain-GPLv3: there are three GPL licenses to
worry about.
Second, with whatever respect is due to you, I will rather take advice
about license compatibility from someone who actually _does_ like to
think about other licenses, not from the one whose license actions,
whether you personally accept the result as correct or not, led in
practice to the fork of cdrkit.
http://www.dwheeler.com/essays/gpl-compatible.html
Either that, or I'll just sign a contributor agreement if I want to
participate in the ZFS community hosted by Sun, which is really as far
as you have to think about licenses w.r.t. this list---are you willing
to sign one, or not? Even if you did object to the contributor
agreement, which I don't, there's not a big enough community around
ZFS for a fork, so for now you either sign the agreement or don't
participate, and the license is chosen by Sun and can be dual or
single or whatever. It works perfectly, as it was planned to, and
there is simply no cause for your FUD.
My own view is, I might one day become inclined to avoid ZFS entirely
because the license incompatibility with GPL is too constraining and
hassling, but once I've chosen to use it I won't mind signing an
assignment agreement to cover any patches I made. The quirks of
individual licenses often look to me less harmful than Linux and BSD's
lack of clear assignment so they can't adapt to changing thinking,
license compatibility needs, and market conditions (anti-TiVoizing
clauses, patent sandboxes, 4-clause -> 2 or 3 clause BSD, Apache 2.0
compatibility). I _like_ assignment and flexibility, and I'm not too
worried about someone changing the license out from underneath me,
because the OSI won't approve and community won't accept any of those
old greedy licenses like SCSL and the early Apple licenses that
prevents the community from forking to evade an undemocratic license
change (like happened to you with cdrkit)---the possibility of this
kind of fork is a GOOD thing because it gives us safe flexibility that
really is rooted in a community, not just a bunch of blogs and
wallpaper. I guess my flexible position depends on how much I'm
likely to contribute, though, probably pretty small for me---a lot of
larger contributors are stating outright they're focusing on btrfs,
because of license, or license incompatibility. :/
pgpjuBjR8WXaW.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
