www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Is it OK to remove MIT header in this case?
Date Wed, 26 Apr 2017 18:15:30 GMT
> On Apr 25, 2017, at 8:24 PM, Alex Harui <aharui@adobe.com> wrote:
> 
> Hi,
> 
> What we are creating is a file that contains a list of the APIs we do not
> want the Google Closure Compiler to rename.  It is not code per-se.  But
> Google chose to have the list appear like JavaScript function definitions
> instead of a plain text file with strings in it.  Adobe Legal was asked if
> this list is considered a derivative work.  They said no, a list is not a
> derivative work.

Right, that is the kind of answer that I would expect from Legal: they
answered your specific question without actually looking at the file.

A couple things to note: 1) copyright laws and precedence are not based on
software, they are based on artistic works (novels, movies, music, paintings, ...).
An expression is copyrightable (meaning the owner has the ability to restrict
its reproduction via the copyright laws) whenever the expression is
sufficiently original; 2) each time a change is made to an expression,
we need to decide whether the result is a new original work (and derivative
of the original) or not (same as the original for the sake of copyright).

When legal says a list is not a derivative work, what they mean is that a
list (on its own) does not create something original and thus is not subject
to an additional copyright.  The original copyright still applies if the new
expression still contains whatever it was that made the original expression
copyrightable.

For some lists (the canonical case being alphabetical phone listings), there
is no copyright at all because the maker does nothing original in compiling
a list in lexical order and the entries themselves are not copyright.

As a separate issue, extracting a list of operational names from an API is
often considered non-copyrightable (even when the API is subject to copyright)
because those bare names are operational, meaning they are specifically
excluded from copyright to make way for patent law.  Note, however, that this
exclusion does not apply to the commentary surrounding those bare names, nor
the order in which the names appear in header files.

Hence, if you want to extract a list of API names without keeping the original
content that is subject to copyright, the right way to do that is to extract
only the operable names and then reorder them alphabetically.

> So all of you are correct if this was still source code, but it isn't.  It
> is a list.  It doesn't actually perform any execution, nor is it ever
> executed.  It is simply fed to the compiler and consumed as a list.

I looked at the file.  It is not a list.  It is a patch containing
the original and the end result.  Furthermore, the end result is not a
list -- it is a slight modification of the original, including all of the
original's copyrightable comments.

It doesn't matter how or why the file is created or how our product
intends to use it; the file (expression) is still subject to the original
copyright, which means the MIT license is required for us to redistribute
that file (even to the extent it remains in our repo).

> So, how should I create such a list?  If I were to do it manually, I would
> copy a function definition from the original source, and reformat it and
> modify the comments to conform to the way Google wants the list to be
> formatted.  The patch file simply automates that process.  If the format
> was a plain text file, would you still decide that it requires the same
> licensing terms as the original?

Yes.

> Let me know if you think this still needs to be considered under MIT.

MIT is an allowed license for inclusion in Apache products. Just publish
the patch and APIs under the MIT license.  Adobe has no copyright here.
Adobe might have copyright to your script, or if it added something
original to the output that wasn't defined by Google, but that doesn't
change the copyright of what it operates upon (just like Photoshop doesn't
change the ownership of an image when a modified form is written).

> Note that several other providers of these lists seem to have reached the
> same conclusion and do not use the same licensing terms as the original
> source.
> 
> Thanks,
> -Alex

Perhaps, but they are not Apache's responsibility.

....Roy


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message