[License-discuss] [License-review] CC withdrawl of CC0 from OSI process

[Chris Travers]

Rick;

I think you are missing one key point in your reply to me.  In short:
Part of the point is to realize that the engineer's question is "What
do I have to do to stay safe?  How do I know if this license applies?"
 Any answer you can give to the engineer's question will be both
heavily overinclusive and underinclusive because the frameworks do not
match.

The point of a software license is not to give lawyers an opportunity
to have long discussions with the engineers.  The point is to give
engineers an idea of what they can do with the software or not.  That
derivative works law is relatively developed as a framework does not
mean that it is  something where an engineer can know in advance what
behaviors are likely to raise problems, or even that a lawyer will be
able to say with certainty how a court will resolve many of those
problems.

On to the longer version.....

Here's the fundamental problem as I understand it:

Copyright law is about protecting creative expression.  Software
authoring and engineering is about creating functional tools.
Functional elements are not subject to copyright, nor are creative
elements closely tied to those at least in the US (this is as I
understand it very much settled law).  This of course leads to the AFC
tests etc.  This is why I don't think that linking ever creates
derivative works by itself.  At most you are copying some header files
or the like and merely depending on external sources is not the same
thing as being derivative of them.  This being said using two products
together can create derivative works.  If I distribute third party CSS
files for your web application (let's be extreme here and say it's an
HTML5 game), then the result that is generated by the user's web
browser may in fact be a derivative work, and so may my module (I can
look up the case that lead me to this conclusion if you'd like).  Thus
I might be subject to the requirements of the GPL here.

This was the big issue when we contacted the translation authors for
SQL-Ledger who licensed their work under the GPL and SQL-Ledger
changed the license (back at 2.8.0).  It's not enough that there is
functional connection, but the fact that there is *expressive*
derivation in the output suggested to us that this pressure could
legitimately be brought to bear.  Now, maybe the strings don't have
very many ways of being translated, and so they are purely functional
and de minimis requirements are not met.....  Maybe not.... There
isn't a clear way for us to tell.....

The reason why we draw the line where we do is this:

We are not claiming that every use of inheritance leads to derivation.
 That of course is fact sensitive and requires lawyers and probably
judges to resolve.  However, we can say with reasonable certainty that
the mere use of our API's is not protected by copyright.  However,
once you get into inheritance, I think the situation changes in ways
which are meaningful for the AFC type test.  In particular the
expressive elements in the inheriting class are more closely tied to
those in the inherited class (the API's functionally merge, and so
forth--- it's not a matter of mere exposure of the API, but rather the
way it is exposed, namely as part of the other copyrighted module,
which makes a difference in our view).

So we get back to the problem that Bruce was trying to answer, which
is how we explain what a license allows to non-lawyers.  And more to
the point, letting an engineer be able to answer, the question of
"what exactly do you have to take out to make that application clearly
non-infringing?"  Inheritance is a nice line to draw there.

Best Wishes,
Chris Travers