4 ms·

EDIT: so now I've actually read the article. The point about legal vetting is valid. Rather than having each piece of code approved, there should be a policy

by russell 17y ago

EDIT: so now I've actually read the article. The point about legal vetting is valid. Rather than having each piece of code approved, there should be a policy some thing like, improvements to existing open source are OK, general interest utilities are OK. Core business functionality or software with significant money making potential for your company need approval.

jacquesm 17y ago
Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. A policy is made before the work starts, not at the time you think you may want to open source something (though that probably will happen plenty of times). It's a great way to be confronted with the need for such a policy though. To use the fact that you need approval from legal as a reason to forego open sourcing anything is nonsense. You need approval from legal for any kind of action that you do on behalf of the company you work for that interacts with the outside world, including opening up source code. If only to make sure you do not inadvertently expose the company to a liability or give your competitors access to the software that gives you an edge. Nobody ever suggested that would be a good idea. Even google doesn't do that, ask them to release their GFS implementation and we'll see what comes back.
- antonovka 17y ago
  Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. Yes -- the policy we have is roughly: MIT/BSD/Apache: OK for any purpose -- Note the license requirements in the project's top-level LICENSE file. LGPL - Only as a library, and only for non-statically-linked projects. GPL/MPL/Copyleft - Only for system utilities, not to be integrated into any existing code base under any circumstances. We'll still contribute GPL licensed code back to projects. On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects.
  - jacquesm 17y ago
    > On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects. There's an interesting datapoint. I wonder if that's a common thing or not. It definitely might be. Your policy makes perfect sense by the way. I don't know how large a group that policy applies to but I can imagine that if the group is large enough that you will have to have periodical refreshers on it and that people are required to sign off (or check a box) on having followed that policy before their code is accepted into 'trunk', just to reinforce it. Same with new hires.

by russell 17y ago

jacquesm 17y ago

Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. A policy is made before the work starts, not at the time you think you may want to open source something (though that probably will happen plenty of times). It's a great way to be confronted with the need for such a policy though. To use the fact that you need approval from legal as a reason to forego open sourcing anything is nonsense. You need approval from legal for any kind of action that you do on behalf of the company you work for that interacts with the outside world, including opening up source code. If only to make sure you do not inadvertently expose the company to a liability or give your competitors access to the software that gives you an edge. Nobody ever suggested that would be a good idea. Even google doesn't do that, ask them to release their GFS implementation and we'll see what comes back.

antonovka 17y ago
Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same. Yes -- the policy we have is roughly: MIT/BSD/Apache: OK for any purpose -- Note the license requirements in the project's top-level LICENSE file. LGPL - Only as a library, and only for non-statically-linked projects. GPL/MPL/Copyleft - Only for system utilities, not to be integrated into any existing code base under any circumstances. We'll still contribute GPL licensed code back to projects. On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects.
- jacquesm 17y ago
  > On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects. There's an interesting datapoint. I wonder if that's a common thing or not. It definitely might be. Your policy makes perfect sense by the way. I don't know how large a group that policy applies to but I can imagine that if the group is large enough that you will have to have periodical refreshers on it and that people are required to sign off (or check a box) on having followed that policy before their code is accepted into 'trunk', just to reinforce it. Same with new hires.