On 14-10-22 06:59 AM, lkcl . wrote:
On Tue, Oct 21, 2014 at 8:11 PM, Kern Sibbald <[email protected]> wrote:
It is my belief that the LGPL was designed to allow linking with any other
code without that code being LGPL. So concerning your statement that it
would be the end of LGPL, I don't agree.
kern may i respectfully remind you that top-posting in a complex
discussion places a burden on others to work out what you are replying
to: it is against standard netiquette rules, please don't do it.
Yes, of course. I assume you prefer that I answer in-line, if not
please let me know. When I make a small on paragraph request I usually
top post because it seems simpler to me, but I'll gladly respect the
usage of this list.
let's first take the time (my time) to re-structure what you wrote,
then we can reply.
If APIs were to be copyrightable, it would have a huge impact, especially
for the C/C++/Linux world. In that universe, APIs are usually defined in
header files containing type definitions (data structures) and function
signatures. In order to use software (e.g. a library) with such API, you
will have to include the header file into your code. If the API is
copyrightable and the library+header file are licensed, say, under LGPL,
your code would need to be licensed under (L)GPL, too. This would be the end
of proprietary applications using LGPL libraries.
It is my belief that the LGPL was designed to allow linking with any other
code without that code being LGPL. So concerning your statement that it
would be the end of LGPL, I don't agree.
the LGPL has been designed with the assumption that the API - which
is IMPLEMENTED as a header file - is NOT IN ANY WAY INVOLVED IN THE
LICENSE.
to emphasise this, before going any further and before criticising or
reading any statements below, please read - in full - the text at the
following link:
https://www.fsf.org/blogs/community/who-ever-thought-apis-were-copyrightable-anyway
OK, I read the article (one page -- seems a bit short) and it
corresponds to my concept of what an API is, because I am a programmer.
so we are talking NOT about the-implementation-of-the-API: that *is*
covered by the LGPL, and the *header* file *IS* permitted to be
utilised in linking to proprietary applications.
so think, kern: why would you explicitly even put something in a
license when it isn't even considered to be copyright? that would be
insane.
so *nobody* has put in explicit language to license something that
cannot even be licensed!!
and the definition of functions (name, argument types) have NEVER
been considered copyright, so nobody has ever been *ABLE* to include
licensing THAT WHICH CANNOT BE COPYRIGHTED.
OK, I understand the above, and didn't mean to imply I believe something
different.
... now some idiots want to have the definition of functions (the
actual name, the actual argument types) NOT REPEAT NOT REPEAT NOT I
REPEAT AGAIN AND COUNTLESS TIMES AGAIN ***NOT*** the IMPLEMENTATION
but the ***CONCEPT*** of what goes into an API... these idiots at
oracle want the definitions of functions to become copyrighted.
Yes, copyrighting APIs would make interoperability impossible or almost
impossible. I agree that most people believe that APIs are not
copyrightable and we in open source have always assumed this is the
case. However, certain APIs are copyrighted and they are generally
protected by not disclosing the API -- such as Oracle's DB backup
interface. Bacula Systems (open core) was able to write an Oracle DB
plugin only because we signed an NDA.
I believe that most APIs are a unique creative work, but at the same
time, I believe that they should not be copyrightable otherwise, it
permits monopolies, and would effectively lock out open source.
Some writers were complaining on this list that copyrighting APIs would
have a big effect on the GPL, and I was asking about that, because I
think the effect is not specifically on the GPL but on *any* free/open
code that could use the interface.
Bottom line: as an open source author and advocate, I would not like to
see published APIs copyrightable.
is.
this.
now.
clear.
l.
Yes, it is. Best regards,
Kern