Brad Boyer wrote:
This sounds slightly petty to me. For example, generic_file_read() is
there just to make it easier to implement the read callback, but it
isn't required. In fact, I would think that any filesystem complex
enough to be worth making proprietary would not use it. However, that
doesn't seem to me to be a good argument for marking it GPL-only. The
functionality in question is easier to reimplement, but that doesn't
make it right to force it on people just because of a license choice.
Yes, most filesystems have their own scheme for managing i_ino
assignment, so this is primarily for "pseudo-filesystems". Stuff like
pipefs, sockfs, /proc, etc...
I'm certainly open to discussion though. Is there a compelling reason to
open this up to proprietary software authors?
I don't think there is a compelling reason to open it up since the
functionality could be reimplemented if needed, but I also think
the only reason it is being marked GPL-only is the very common
attitude that there should not be any proprietary modules.
To be honest, I think it looks bad for someone associated with redhat
to be suggesting that life should be made more difficult for those
who write proprietary software on Linux. The support from commercial
software is a major reason for the success of the RHEL product line.
I can't imagine that this attitude will affect support from software
companies as long as there is a demand for software on Linux, but
it isn't exactly supportive.
I have no problem with someone writing, selling and supporting
proprietary modules. Knock yourself out. I just don't see a reason why I
should contribute code to such an effort.
Still though, this was coded in part on company time. I certainly don't
want to go against Red Hat's policy in such a matter, so I'll do some
due diligence internally as to how this should be done.
In the meantime, does anyone have objections or comments on this
approach on technical grounds?
Thanks,
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
