On Fri, Jan 6, 2017 at 8:38 PM Jacek Furmankiewicz <jace...@gmail.com>
wrote:
>
> We've had really difficult individuals who refused to be bothered with
> going through proper license review.
> Some of them don't work here any more.
>
>
This is a social problem with the people you've hired, or with how they
have been instructed. You can't block copy/paste. You can't block blind
injection of random code from {stuck,stack} {overfail,overflow}. You can't
stop people from memorizing code at home and then adding said code to your
project. In order to handle licensing issues around code, your people must
be on-board and understand the problem.
Usually, the reason you end up in a bad situation is due to complex
factors, so you can't place the blame or the fault on any single
individual, or on the management. Rather, you have to understand that more
than a single factor often leads to sick work environments where these
things happen. Sometimes, the guy who inserts illegal code into the code
base does it because he is under pressure to deliver. Which means that the
fault is partially him, but also partially management. In that case, firing
the guy will not put out the tire fire you have. Another poor individual
will just takes the same seat and ends in the same situation months down
the line.
If you can't survive a rejection of an audit, you must have procedures
internally to remove the risk of rejection. These are usually a combination
of technical solutions (code search) and human solutions (manual review).
There is no way you can move the risk to 0%, but you can get it close.
Also, consider social solutions (company culture).
My suggestion is to run an internal vendoring tree from which you are
allowed to pull software packages. And then make it a process to add
something to the tree. This will slow down development, short term, but I
have a hunch you will gain from such a procedure long-term. In addition to
solving the audit problem it also solves a number of other problems:
* You can reproduce builds
* You make updating a package a deliberate decision
* You guard against people who are not able to manage a stable API for
backwards compatibility
* You can run internal patches on software if the maintainer of the
software on the outside are not willing to handle the problem you have.
The price you pay are:
* You have to watch for security updates more
* If you diverge too much from the external project, you can't merge their
strain of changes into your world easily
* You must spend time to keep things up-to-date
In your case, I think the benefits outweigh the cost, simply because an
audit is always lurking in the back.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
