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

[Rick Moen]

Quoting Chris Travers (chris at metatrontech.com):

> Derrida's theories on text and meaning are entirely applicable to
> legal agreements even if we pretend they aren't.

I note without special objection that you pretty much ignored my point and
moved the goalposts.  No worries.  I doubt you really expected to debate
deconstructionism, anyway.  At least, I sure hope not.


> 1)  There isn't a lot of case law on what constitutes derivative works
> in software as a whole, and it isn't clear to what extent this may be
> an evolving field.  And it may not be clear how it will evolve until
> one gets into court.

I hear this stuff asserted a great deal by technology people who repeat,
conciously or not, pronouncements by other technology people -- without
actually bothering to consider (or, actually, learn) how copyright law
and legal citations work.  

The concept of 'derivative work' has a quite well developed framework[1] 
in caselaw.  A creative work in one of the statutorially covered
categories is conceived to have elements that can be conceptually 
classified as either expressive or functional.  Elements whose content
is dictated by functional demands (e.g., compatibility), as well as
those taken from the public domain, are not eligible for copyright
protection.  Only those deemed expressive are.

Even if nobody had ever filed a copyright suit over a computer program
before -- hence we didn't have CAI v. Altai, Micro Star v. Formgen,
Lotus Dev. Corp v. Paperback Software, Whelan Associates v. Jaslow
Dental Laboratory, CMS Software Design Sys v. Info Designs, Apple
Computer v. Franklin Computer, Williams Electronics v. Artic International,
etc. to guide us -- these well developed concepts would have existed
from leading cases derived from music, literature, movies, theatre, and
all the other categories of copyrightable works.  Likewise, various
defences (fair use, copyright invalidity, independent creation,
de-minimus, statutory limitations on holder righs, expiry, forfeit,
preemption, permission, misuse, abandonment, acquiescence, estoppel, 
unclean hands, other equitable defences) exist and are well developed
for reasons owing little or nothing to do with software yet are directly
applicable there.

So, actually, 'There hasn't been a lot of case law on what constitutes
derivative works in software is an extremely silly argument for at least
two reasons.  1.  Your representation of fact is profoundly mistaken.
(See litany of case citations above, for starters.)  2.  Even if that
_were_ true, judges' notion of what is a derivative work is easily
discernible from, and is consistent in, every other type of copyright
case.



> 2)  Therefore a book which doesn't include in fairly clear detail the
> various possibilities as to what courts *might* do is fundamentally
> incomplete.

This claim is pretty hilarious, seen in reasonable context after
actually bothering to understand how the law works -- unless of course
you are one of the people trying to figure out to the micrometre just
how close you can skirt infringement and get away from it.  That's that
edge case thing, so utterly beloved of many technology people, to which
I alluded earlier.

But I'm not going to waste time on that.  I mostly wanted to point out a 
type of rhetoric that's been rising in prominence around here:  '[basic
minor fact of life foo] is a Problem.'

  Inability to deterministically predict with metronomic precision what
  will and will not be a derivative work, and be utterly certain that
  a court will rule that way is a Problem.

  The fact that coders might have to work at understanding the fine
  details of the more-complex software licences is a Problem.

  The fact that MIT/X wastes a whole 13 lines is a Problem.

  [Licence foo] lacking lavish and strong defences against patent
  trolls is a Problem.

  The possibility that a plain-English explanation accompanying
  a licence might fail to convey some nuance of the licence itself
  is a Problem.

  Inability to determine absolutely for certain that some particular
  conduct with software is immune from risk of successful litigation
  without hiring expensive legal help is a Problem.

Must be nice to have time for such hobbies.  I remember thinking that
way, and then I left college.

Out in the real world, we have to deal with shades of grey and lack of
perfect knowledge, which is why a wise person will not spend huge
amounts of time pondering whether you can get away with particular types
of deployments without having created an unauthorised derivative work, 
but rather will be cautious and let someone else land in court.  

> In LedgerSMB, we have publically said that linking is fine, but OO
> inheritance implies a level of expressive intimacy that implies
> derivation, as does using our code as a basis for your code.  In other
> words, you can use our API, but you cannot create your own API based
> on it.

I'd suggest you actually bother to read some caselaw rather than going
around making pronouncements that have no discernable relation to the
criteria actually used.