[License-discuss] Copyright on APIs

[Russell McOrmond]

On Mon, Jul 8, 2019 at 5:38 PM VanL <van.lindberg at gmail.com> wrote:

> Hi Larry,
>
> Just making sure I understand:
>
> On Mon, Jul 8, 2019 at 3:22 PM Lawrence Rosen <lrosen at rosenlaw.com> wrote:
>
>> I again plead with OSI, regardless of what the Supreme Court does with
>> the Oracle v. Google case, that OSI never again approve an open source
>> license* that  purports to impede in any way by copyright infringement the
>> freedom to copy and use any functional API in any open source software.
>> This should be OUR requirement for software freedom. You should educate the
>> public that this is OUR goal for open source....
>>
>> ...
>>
>>
>>
>> * Like the GPL and the AGPL!
>>
>
> So your view is that the OSI should never approve an additional reciprocal
> license? Under any circumstance?
>


A few people have made this leap, so I'm wondering the basis for it.

Supporting reciprocal licenses isn't the same thing as supporting exclusive
rights on interfaces (including, but not in my mind limited to, APIs).

When we had a collection of C files which the compiler would then link into
a single binary, what was required of license compatibility was obvious:
all the code that was linked together in a single binary needed to
simultaneously honour all the licenses of any code that was linked
together.  What was considered a derivative was also obvious.  This is the
context in which the GPL was first authored, and while the BSD camp
(freedom to?) might not have liked this reciprocal license, those of us
(meaning, including me) part of the copyleft camp (freedom from?) wanted to
ensure that derivatives would be under the same terms.  We didn't want
royalties as payment, but we did want the source code of any derivatives:
share and share alike.

When we moved to dynamic library linking, and later calls over a network
(sockets/etc), the policy question moved beyond discussing derivatives to
discussing whether licensing terms can or should extend past an API.

Those of us who see excessive exclusive rights as itself being a reduction
of software freedom want to ensure that we as a community are never seen as
wanting to extend (or even excusing extensions of ) the control of an
exclusive rights-holder to interfaces.  In the case of the AGPL it goes
much further to seek to restrict private modification, something that I
also believe should never be granted any exclusive right or enforceable
under a license/contract.




I understand the fear some people have that an API can be added to any
program, and thus non-FLOSS software could be created that made use of that
software through an API.  I believe that the harm of extending exclusive
rights to APIs is far more harmful to the FLOSS community than the fear
associated with non-FLOSS use of FLOSS software through APIs.

I call it 'fear', as I have yet to be convinced that there is any actual
harm.  Some people disliking specific types of entities being FLOSS users.
Different people dislike different types of entities:  Sometimes it is
companies engaged in some controversial activity (pipelines in Canada),
non-unionised companies, SaaS, a military, companies in specific countries,
specific governments, or .... insert your own discrimination against
person, groups, or fields of endeavour.   Fundamentally I see all this fear
as leading to a desire to violate OSD#5 and/or OSD#6, and thus I believe we
should not recognise software under these terms as being FLOSS.

-- 
Russell McOrmond, Internet Consultant: <http://www.flora.ca/>

Please help us tell the Canadian Parliament to protect our property rights
as owners of Information Technology. Sign the petition! http://l.c11.ca/ict/

"The government, lobbied by legacy copyright holders and hardware
manufacturers, can pry my camcorder, computer, home theatre, or portable
media player from my cold dead hands!" http://c11.ca/own
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190709/bc11f683/attachment.html>