This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Extending xm_defines syntax to get rid of more xm-files



> <<Yes, in theory  What about practice?
> >>
> 
> I was talking about relevant case law. In one case in which I was involved
> indiectly, one side argued that a single sequence of 200 bytes
> was too small to worry about, but it turned out that these 200 bytes
> were an encoded form of a crtical algorithm.

That's why I mentioned the 7-line DeCSS decoder.  If the very small
code snippet is astoundingly clever, copyright is a concern.  But if
it is highly mechanical, like "Change all occurrences of HAS_FOO to
HAS_BAR", a patch with hundreds of lines has no copyrightable content.
The "about 10 lines" rule is a deliberately fuzzy criterion, and it has
to be adjusted for short patches with unusual levels of originality.
It amounts to "this is the level of risk RMS will accept".

As Eben Moglen pointed out to us when we were talking about cleaning up
the test suite, if you're in the position where you tried to honestly
apply a criterion most people in the field would think reasonable and you
get it wrong, the court is not going to punish you badly, the worst that's
going to happen is that you have to take that piece out again (and, in
fact, if someone objects, that's what you offer to do without getting the
courts involved).  For large patches it's much more possible to argue that
the FSF was "stealing" if things aren't done right and therefore face more
damaging sanctions.

You're absolutely correct in stating that there is no defined limit
to how small a "quote" can be to be disallowed as fair use.  But that
doesn't mean "never quote".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]