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

Re: FRR package in Debian violates the GPL licence



On Thu, Mar 21, 2019 at 11:17:23AM +0100, Giacomo Tesio wrote:
> Technically, he is asserting that any text that use substantial
> original words defined in another original copyrightable text is a
> derivative work of such original text.

You can't copyright words.  You probably can't even copyright a title
like "Harry Potter and the Sourcerer's Stone".  You certainly can't
copyright the name "Harry Potter".

Copyright requires a creation of sufficient "height" of the work.
Neither a word nor a book title meets that requirement.

Literary characters _do_ meet the requirement since the character as a
whole is a complex creation.  It has a backstory, attributes, flaws, -
that's what you can base a copyright claim against fan fiction on, if
you chose to do so.  But if you put a character named "Harry Potter" in
a new novel that has nothing to do with JK Rowling's Potterverse, there
is no copyright issue.

There is however a trademark issue, at least the title is probably
trademarked (not sure if you can trademark the name alone.)

[Add.: apparently you can trademark the name -
https://register.dpma.de/DPMAregister/marke/register/300125666/DE ]

> To be honest, the form of the text (in C, plain english, or
> mechanically translated to an object form for mechanical consumption),
> I'd say that it shouldn't change much.

It changes by incorporating additional material.  If a C file contains
no include statements, only the copyright of the source applies to the
object file.  But creating an accumulative work is very much a legal
concept (in software as well as in art.)

> All translations of a book are derivative work of the original, even
> if they are ALSO copyright of the translators.

Yes, translations of books are derivative.  But a translation of a word,
or even a sentence, isn't.  (Caveats apply - you can probably cram
enough content into a sentence to make it copyrightable.  This boundary
is something that courts determine on a case-by-case basis.)

[...]
> I agree that the course of action you suggest to Paul is correct, but
> I'd really like if you might elaborate about your concerns about API
> copyrightability.

btw: the POSIX standards itself are copyrighted:
  UNIX ® is a registered Trademark of The Open Group.
  POSIX ® is a registered Trademark of The IEEE.
  Copyright © 2001-2018 IEEE and The Open Group, All Rights Reserved

Just because it is a standard, that doesn't free you up from adhering to
their copyright.  But as far as I'm concerned, implementing a standard
isn't derivative of the standard unless you start copying or deriving
actual content in your implementation.

There are actually legislations that have enshrined this in law, as a
reaction to Microsoft's marked position in the 90ies.  They explicitly
specify that any parts of a system that are required for interoperation
with that system can be freely copied regardless of copyright or
license.  Sometimes this also extends to reverse engineering.

(Take this as hearsay, I'm not a lawyer and I don't have time to double
check.)

> I know that this is a widely minoritarian position, but I think that a
> strong copyleft over innovative APIs might be very beneficial to Free
> Software.
> 
> Most of commercial APIs are crap so we wouldn't lose much.
> OTOH Free Software is strong enough to innovate and through a strong
> enough copyleft, we might create a new and better stack that keep most
> future software in the Commons, spreading knowledge and collaboration,
> for the benefit of the whole Humanity.
> 
> 
> So why do you think that this is a "toxic precedent"?

I agree that this is a toxic precedent, because in your world we need to
reimplement everything from scratch at once.

This is, in my experience, neither how software development works, nor
is it doable.  Essentially, your precedent would immediately shut down
most open source because it would no longer be able to mesh into the
existing world, however crappy it might be.

Sorry,


-David


Reply to: