
Operating Environment: essential industry background for open software licenses - beefhash
https://writing.kemitchell.com/2019/06/15/Industry-Environment.html
======
ericb
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
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
> 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
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.

