• 1 Post
  • 3 Comments
Joined 3 years ago
cake
Cake day: June 17th, 2023

help-circle

  • I should have been clearer with the intent of my post. The intent was more along the lines of asking people to help point out to me some detail on the topic which I might have missed, because this loophole seems to be too obvious and dangerous to FOSS…

    As the EUPL FAQ (written by EU lawyers) also points out, Directive EC 2009/24 states in point 15:

    Nevertheless, circumstances may exist when such a reproduction of the code and translation of its form are indispensable to obtain the necessary information to achieve the interoperability of an independently created program with other programs. It has therefore to be considered that, in these limited circumstances only, performance of the acts of reproduction and translation by or on behalf of a person having a right to use a copy of the program is legitimate and compatible with fair practice and must therefore be deemed not to require the authorisation of the rightholder. An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together.

    However, there is a last sentence in this point, which I only realised now that it might be the answer to my question! So good that you questioned it.

    Such an exception to the author’s exclusive rights may not be used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program.

    Maybe in court the exploitative nature of the hypothetical in my post would be covered by this. Though, this moves the matter towards some gray zone, where the question is where the line of explotiation lies. Is a plugin system, where by default the software functions as before, but functionality can be expanded with “premium” plugins that make algorithms in the software more precise or fast considered exploitative?



  • No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.

    Tldr: the problem lies in the unsafe part