undefined | Better HN

0 pointstzs2y ago0 comments

I'm having a hard time figuring out what either of you are actually talking about.

He's talking about various ways code written by one party may invoke code on the same computer written by someone else but not saying exactly how those two chunks of code came to be on the same computer running at the same time. Without knowing all the people involved in that it is not possible to say what copyright law says about who needs to get permission from whom.

You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law.

A lot of free/open source discussion (and sometimes the licenses themselves) tends to use terms that have "derived" in them but mean some sort of vague superset of what copyright law means by "derivative work".

In particular, if work X depends on work Y, even to the point that X is not really useful unless used with Y, that does not necessarily make X a derivative work of Y. That's why game console makers had to use DRM to stop other companies from making cartridges for they game consoles. Even though the software in the cartridges was utterly dependent on the code in the console to do anything the cartridges were not derivative works.

To be a derivative work of Y, X must incorporate some or all of Y. Suppose for example Y is a text to speech library which exports a function "int speak(char * text)". If I write a file, greet.c, that contains this:

  #include "y_speech_lib.h"

  int main()
  {
      speak("Hello, World!");
      return 0;
  }

greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.

I can license greet.c under any license I want and distribute it under any terms I want without having to worry about Y's license as far as possible liability to me for direct copyright infringement goes. I'll cover indirect infringement later.

If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y.

If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner.

It is possible to be an indirect copyright infringer. There are a few different kinds of indirect infringement, such as vicarious infringement and contributory infringement. What they all have in common is for someone to be liable as an indirect infringer there must be a direct infringement for them to be indirectly liable for. If there is no direct infringer there cannot be an indirect infringer.

Since most open source licenses only impose requirements when you distribute code, doing stuff with it on your own computer just for you own use will usually not be a direct infringement, and hence no possibility of indirect infringement for those who supplied you with other code that you used with the open source code code.

Even if you combine my greet.c with someone else's code on your computer and distribute the resulting binary in violation of that other code's license (making you a direct infringer) I'd be OK unless (1) I had the right and ability to control you and received a direct financial benefit from your infringement, (2) I distributed greet.c with the object of promoting its use for such infringement and clearly expressed that or took affirmative steps to encourage it, or (3) greet.c has no other substantial uses that are not infringing.

[1] I say maybe because if they are just compiling and linking copies of greet.c and Y that they legally own in order to use them on their machine they might not need permission. US copyright law contains an exception for things that are an essential step to utilize a program on a machine (17 USC 117) and they don't do anything else with it like distribute it.

0 comments

simiones2y ago

> greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c.

I think this is very much debatable, and I believe the FSF at least takes the position that greet.c is a derived work of Y since it is designed to depend on Y. Even more, their position is that a program like this:

  #include <stdlib.h>
  
  int main() {
    create_complex_c_code_using_gcc_specific_extensions("./intermediate.c");
    system("gcc -o intermediate ./intermediate.c");
    system("./intermediate");
  }

Is quite possibly a derived work of GCC, since it depends critically on communicating with GCC using a very complex and specific data interchange format (the GCC-specific C source code). Note that this is not including any portion of GCC itself, even after compilation.

Now, this type of thing has never been tested in a court of law as far as I know, so it's difficult to say whose interpretation of copyright and its implications is actually correct. But this is similar to the idea that if you were to write an original novel that uses characters or very recognizable aspects of, say, The Lord of the Rings, you'd be creating a derived work (and thus permission from the Tolkien estate), even if you didn't include any part of the original longer than "Galadriel".

tzsOP2y ago

I just ran this shell script on my Mac:

  #!/bin/sh
  say Alexa what time is it

and my Amazon Echo told me the time. Is that shell script a derivative work of Amazon's Alexa code? It is very clearly designed to depend on Alexa.

simiones2y ago

I don't know, no one really does as this has never been tested in courts as far as I know. I believe the FSF would say that it's not a derivative work, as it doesn't interact with the Alexa code through complex data types. However, this is their own legal theory, not directly a part of any law or jurisprudence (as far as I know - if there is some case law on this topic, I would be very curious to read it).

kelnos2y ago

> If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.

Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.

But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

tzsOP2y ago

> Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.

That one.

> But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

No, I'm not asserting that that a.out would be a derivative work of Y.

j / k navigate · click thread line to collapse

0 comments

simiones2y ago

> greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c.

  #include <stdlib.h>
  
  int main() {
    create_complex_c_code_using_gcc_specific_extensions("./intermediate.c");
    system("gcc -o intermediate ./intermediate.c");
    system("./intermediate");
  }

tzsOP2y ago

I just ran this shell script on my Mac:

  #!/bin/sh
  say Alexa what time is it

and my Amazon Echo told me the time. Is that shell script a derivative work of Amazon's Alexa code? It is very clearly designed to depend on Alexa.

simiones2y ago

kelnos2y ago

> If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.

Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.

But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

tzsOP2y ago

> Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.

That one.

> But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

No, I'm not asserting that that a.out would be a derivative work of Y.

j / k navigate · click thread line to collapse

0 pointstzs2y ago0 comments

I'm having a hard time figuring out what either of you are actually talking about.

You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law.

  #include "y_speech_lib.h"

  int main()
  {
      speak("Hello, World!");
      return 0;
  }

greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y.

If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y.

If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner.