[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: reiser4 non-free?



@ 06/05/2004 15:56 : wrote Hans Reiser :

I don't think my clarifications of what is a derivative work conflicted
with the GPL, they merely make it less vague as to what is a derivative work. The notion that if something is linked determines whether it is derivative has no basis in either copyright law or the GPL. rms, correct me if you disagree.
In Brazilian copyright law, a derivative work has a simple definition: the work achieved by some transformation of the original work, but is a novel intellectual creation in itself.

Even the GPL is excessively verbose about what a derivative work is, and some of it contradicts the various copyright laws in a lot of jurisdictions. What I'm trying to say is: please don't. Solve the credits problem in any other way. I would be glad to help you. I care. Really.

Vagueness is not a benefit to a license, but in this aspect of the GPL it is curable only in specific to a particular program being licensed. It would be nice if the GPL explicitly allowed particular instances of it to specify what are derivative works with some clarity. (Richard, please consider that.....)
But, it currently does not. It currently (and, in the case of the linux kernel, forever -- the linux kernel is licensed by GPL V2 only, not later) forbids aditional restrictions. It already places some restrictions, even on what is to be considered a derived work, which is a little bit out of its reach. If your work is a derived work (and I'm assuming reiser4, for instance, is a derived work of the linux kernel), Debian could only distribute it if it's licensed under the GPL V2 -- and no aditional restrictions, as per the GPL text itself.

Here is the text of the GPL, section 6, with my coments between {{}}:
*6.* Each time you redistribute the Program (or {{ in this case, reiser4 }} any work based on the Program {{ linux }} ), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. {{ important part: }} You may not impose any further restrictions on the recipients' exercise of the rights granted herein {{ which include, for example, moving printf-credits to some-file-credits }}. You are not responsible for enforcing compliance by third parties to this License.

I can see that not very clever people who view the GPL as some sort of holy writ will make more of an issue out of it than I want to deal with. So, as a result reiser4 plugins will always be compiled in and never dynamically loadable and the clarifications of what is or is not a derivative work have been removed for now. Users and I will both lose as a result, and maybe some needless lawsuit will result at some time in
the future that would have been avoided with clear definitions.
This seems to be unnecessary: in this case, specifically, if reiser4 plugins were or not derived works of reiser4, is settled even without the clarifications -- they are. Rule of thumb to derived works: could them (plugins) be created (as they are, not in a different way) if the original work (reiser4) was not created? Yes = derived; no = original. Likewise, could reiser4 be created as it is now, had linux not been created? Yes = reiser4 is a derived work on linux; no = it's an original work.

It's the same case as Windows NDIS drivers loading on linux. They were created in a different environment, and would exist as they are even if linux did not exist. Provided GPL'd glue code, you can load them in the linux kernel, and they are _not_ derivative works. This wouldn't happen with reiser4 plugins... unless, of course, someone took, for instance, NTFS plugins (if those ever come to existence) and put some (GPL'd) glue code to load them as reiser4 plugins (this would not render the previously-non-derived NTFS plugins in derived code from reiser4.)

Hans
I renew my plea for a peaceful and consensual resolution of these matters. Thank you, and please keep up the good work in the filesystems.

--
best regards,
Humberto Massa



Reply to: