3 ms·

Operating Environment: essential industry background for open software licenses

46 points by beefhash 7y ago

ericb 7y ago
My company forked an Apache 2 licensed abandoned project, the BrowserMob proxy, a utility to watch, test, and manipulate web application network traffic often used alongside Selenium. We put it under our name as we plan on expanding it. https://github.com/browserup/browserup-proxy https://github.com/browserup/browserup-proxy When we did it, this Apache License clause caught my eye: > You must cause any modified files to carry prominent notices stating that You changed the files; So to literally comply with the license, and avoid any mishaps, we made a "change" to each file by appending a notice that we have changed the file to the file. The way this reads, we have complied. We did it to every file so as to not risk missing any. Whether the intention is something else, I can't say.
- pgeorgi 7y ago
  Many open source licenses have this clause (and few care about them). The intent for that type of clause is to ensure that nobody can come back to the original author with your modified file and claim that they violated some rule (eg. copied stuff from other-licensed sources, patent law, libel, ...) that you violated in your edits. Assuming that, your compliance step was valid: whoever comes up with that file and tries to annoy the original author in some way gets to check if the reason for that isn't in your change (probably not if it's only that notice). When these clauses were first put in licenses, revision control wasn't really a thing, so a notice like that was rather useful. These days it's easy to figure out who touched any given version of any given file under revision control - but strictly speaking your approach is the safer one.
  - kemitchell 7y ago
    > The intent for that type of clause is to ensure that nobody can come back to the original author with your modified file and claim that they violated some rule (eg. copied stuff from other-licensed sources, patent law, libel, ...) that you violated in your edits. As usual, there wasn't just one reason. The gist is the "integrity" of the official version of the software. Integrity has a few uses. Earlier licenses with these kinds of requirements were primarily motivated by reputation concerns. For the maintainer of the project, who could be "blamed" for the ill-considered patches of others. For the project as a whole, when unofficial forks failed to interoperate, or included novel bugs. Some of those licenses, notably Artistic, required renaming so as not to compete with the official version in package or PATH namespaces, as well as giving notice of instructions to get back to that official version from the fork, if the end-user desired.
    - detuur 7y ago
      I perfectly understand anti namespace conflict clauses. Luckily this is usually already done in practice when open-source projects are forked. mplayer -> mplayer2 -> mpv, ffmpeg -> libav, openoffice -> libreoffice, etc.

46 points by beefhash 7y ago

My company forked an Apache 2 licensed abandoned project, the BrowserMob proxy, a utility to watch, test, and manipulate web application network traffic often used alongside Selenium. We put it under our name as we plan on expanding it. https://github.com/browserup/browserup-proxy https://github.com/browserup/browserup-proxy When we did it, this Apache License clause caught my eye: > You must cause any modified files to carry prominent notices stating that You changed the files; So to literally comply with the license, and avoid any mishaps, we made a "change" to each file by appending a notice that we have changed the file to the file. The way this reads, we have complied. We did it to every file so as to not risk missing any. Whether the intention is something else, I can't say.

pgeorgi 7y ago
Many open source licenses have this clause (and few care about them). The intent for that type of clause is to ensure that nobody can come back to the original author with your modified file and claim that they violated some rule (eg. copied stuff from other-licensed sources, patent law, libel, ...) that you violated in your edits. Assuming that, your compliance step was valid: whoever comes up with that file and tries to annoy the original author in some way gets to check if the reason for that isn't in your change (probably not if it's only that notice). When these clauses were first put in licenses, revision control wasn't really a thing, so a notice like that was rather useful. These days it's easy to figure out who touched any given version of any given file under revision control - but strictly speaking your approach is the safer one.
- kemitchell 7y ago
  > The intent for that type of clause is to ensure that nobody can come back to the original author with your modified file and claim that they violated some rule (eg. copied stuff from other-licensed sources, patent law, libel, ...) that you violated in your edits. As usual, there wasn't just one reason. The gist is the "integrity" of the official version of the software. Integrity has a few uses. Earlier licenses with these kinds of requirements were primarily motivated by reputation concerns. For the maintainer of the project, who could be "blamed" for the ill-considered patches of others. For the project as a whole, when unofficial forks failed to interoperate, or included novel bugs. Some of those licenses, notably Artistic, required renaming so as not to compete with the official version in package or PATH namespaces, as well as giving notice of instructions to get back to that official version from the fork, if the end-user desired.
  - detuur 7y ago
    I perfectly understand anti namespace conflict clauses. Luckily this is usually already done in practice when open-source projects are forked. mplayer -> mplayer2 -> mpv, ffmpeg -> libav, openoffice -> libreoffice, etc.