3 ms·

I appreciate the response. The ethical level, in my opinion, is reproducing the functioning software and the "business" specific logic. At a specific function l

I appreciate the response. The ethical level, in my opinion, is reproducing the functioning software and the "business" specific logic. At a specific function level, and particularly for boilerplate code, I don't view that as specific to this (GPLv3 licensed FOSS) project. There are also dozens more examples of the same code being used, I don't think FOSS necessary gets a monopoly on technology. Which I think creates an interesting debate, where is the line of general technology vs the intent of not allowing private companies to re-package FOSS for their own benefit? > You can't lift a function from a GPL licensed codebase and plant it to a MIT licensed codebase. It's that simple. If that function is a 'pad-left' type of function, is there an ethical violation? Or is this similar to learning Javascript by viewing the source code of webpages? At some point, functions are hardly unique in what they do, and there are only so many different ways to write a 'pad-left' function. I mention this question not to refute what you've said (I think I agree there is a likely license violation), but to explore where the line is for the ethics. I mean, an inferred implication could be that software developers stop looking at HTML source in order to learn. If you learn how to write a standard algorithm or function, and then you reproduce that later in private software, that is "lifting code". It's not much different committing that to memory then doing an outright copy-paste of a 2 or 3 liner. This makes me also think to the variety of shell scripts and standard bash'isms, if a single FOSS project uses a 'sort | uniq -c | sort -n', does that mean a MIT codebase has to re-invent a new way to do that?

bayindirh 4y ago
You're welcome. First of all thanks for your kind and welcoming response. It's an interesting debate for sure. When a program is divided into many functions, and when there are many utility functions, the debate indeed gets blurry. Moreover, many of the open projects in today's world are web applications and "simple" in nature. In this context, simple means that the application can be composed via many simple, relatively general functions with a unique asset set and unique way of connecting them, so the magic (or sauce if you pardon the term) gets more abstract. On the other hand, we have another group of programs, which can be similarly called "complex" programs. The biggest difference is these programs use complex, one of a kind functions. Consider Blender, KiCAD, many open source and GPL licensed scientific software, libraries like Eigen, video/audio encoders, CD/DVD tools. Even a three liner in these programs and libraries can be a game changer. I have a research oriented code, and a ~25 line function in this is worthy of its paper. I published a paper, and didn't obfuscate the language and algorithm, so you can implement it if you want. However, if I open the code of this algorithm with AGPL3, can you say it's too small to be licensed? I don't think so. A more general algorithm can be ruled out as "too simple", but "fast_inverse_square_root" or my function or any other math heavy secret sauce can't be excluded because it's 2-3 lines. As a result, while this issue needs serious discussion, we need to understand that even a small piece of code can carry a lot of research, knowledge and advantage in itself, regardless of its size. So, while lifting a left pad from a GPL code can be understandable up to a certain point, getting the secret sauce, improving it and keeping it closed or merging into a similar, but incompatibly licensed software is inexcusable. At the end of the day, this means we need to defend our GPL codebases, because we can't protect our secret sauce functions without defending the simpler ones.

bayindirh 4y ago

You're welcome. First of all thanks for your kind and welcoming response. It's an interesting debate for sure. When a program is divided into many functions, and when there are many utility functions, the debate indeed gets blurry. Moreover, many of the open projects in today's world are web applications and "simple" in nature. In this context, simple means that the application can be composed via many simple, relatively general functions with a unique asset set and unique way of connecting them, so the magic (or sauce if you pardon the term) gets more abstract. On the other hand, we have another group of programs, which can be similarly called "complex" programs. The biggest difference is these programs use complex, one of a kind functions. Consider Blender, KiCAD, many open source and GPL licensed scientific software, libraries like Eigen, video/audio encoders, CD/DVD tools. Even a three liner in these programs and libraries can be a game changer. I have a research oriented code, and a ~25 line function in this is worthy of its paper. I published a paper, and didn't obfuscate the language and algorithm, so you can implement it if you want. However, if I open the code of this algorithm with AGPL3, can you say it's too small to be licensed? I don't think so. A more general algorithm can be ruled out as "too simple", but "fast_inverse_square_root" or my function or any other math heavy secret sauce can't be excluded because it's 2-3 lines. As a result, while this issue needs serious discussion, we need to understand that even a small piece of code can carry a lot of research, knowledge and advantage in itself, regardless of its size. So, while lifting a left pad from a GPL code can be understandable up to a certain point, getting the secret sauce, improving it and keeping it closed or merging into a similar, but incompatibly licensed software is inexcusable. At the end of the day, this means we need to defend our GPL codebases, because we can't protect our secret sauce functions without defending the simpler ones.