<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoPlainText style='margin-left:.5in'>Kevin Fleming wrote:<br>> As a software developer I have a hard time accepting that designing an API is not a 'creative' process.... There are many other examples of API design decisions which make the API 'hard to use properly' or 'easy to use improperly' and a well-designed API is anticipated to avoid these results.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Of course, the process of designing an API is creative! Sometimes it is VERY creative. But under copyright law, creativity is not relevant to copyrightability. Whether something can be copyrighted depends only on the law (17 USC 102, et seq). For example, many of the decisions of the courts of law are very creative (some are right and some are wrong!), but none can be copyrighted.* Nor can works by employees of the US government. Nor can laws of nature that are "discovered" by brilliant and creative scientists. <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Relevant to our thread, "in no case does copyright protection for an original work of authorship extend to any idea, procedure, <a href="https://www.law.cornell.edu/uscode/text/17/102"><span style='color:black;text-decoration:none'>process</span></a>, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work." 17 USC 102(b). <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Regardless of whether lower court decisions are right or wrong about the copyrightability of APIs, the 17 USC copyright statute and corresponding EU law are authoritative. We all await the decision of the US Supreme Court in <i>Oracle v. Google</i>, which court is always right. :-) <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>So also, the policies of OSI are always authoritative with respect to open source licenses, regardless of the creativity of the work being licensed. WE define "software freedom," not the courts, and not the creative authors of APIs. This is why I am pushing back against Pam Chestek and others regarding license restrictions on copying APIs for open source software.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>/Larry <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>* See, e.g., <a href="http://media.ca11.uscourts.gov/opinions/pub/files/201711589.pdf">http://media.ca11.uscourts.gov/opinions/pub/files/201711589.pdf</a>. Cert was recently granted by the US Supreme Court in this case. See also <u><a href="https://www.law.cornell.edu/copyright/cases/293_F3d_791.htm">Veeck v. S. Bldg. Code Cong. Int'l, Inc.</a></u>, 293 <o:p></o:p></p><p class=MsoPlainText>F.3d 791 (5th Cir. 2002) (en banc). [However, other courts have declined to extend <o:p></o:p></p><p class=MsoPlainText>the Veeck rule in other, related contexts.]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p></div></body></html>