Pattern: InnerSource License - #147
Conversation
|
@cornelius this is the result of our work in the gDoc, converted to markdown. Pending review from others in the InnerSourceCommons Patterns community. |
|
@lenucksi how would I best go about finding a reviewer for this PR? |
maxcapraro
left a comment
There was a problem hiding this comment.
Wow. I am really excited about this pattern. Great great great work, @spier!
I added some thoughts and comments. At times, I get a bit pedantic about writing texts (habbit from my day job) - so please stop me where I went overboard.
One additional thing that would be great: Do you think you could win Schlomo or Cornelius to also perform a review? :)
|
Thanks. I will take a look at your feedback. Cornelius has written this thing with me ;) So I don’t think he needs to review it again. |
True that :) Congrats on this very good initial version to you as well, Cornelius! |
|
@maxcapraro thanks for the detailed review. Unfortunately there were only a few "easy merges" in your suggestions so I often had to ask clarifying questions. To get this PR merged to master I would suggest these next steps:
What do you think? |
Co-Authored-By: Maximilian Capraro <maxcapraro@users.noreply.github.com>
lenucksi
left a comment
There was a problem hiding this comment.
I think this is good stuff on an important topic. I've added of bunch of comments (unfortunately outside of the review function) and inside the review process.
Quite a few can likely be resolved by means of commit suggestions from existing discussions or just agreements, others possibly by Ctrl-F + Replace.
Happy to merge once all discussions are resolved.
Co-authored-by: Maximilian Capraro <maxcapraro@users.noreply.github.com>
|
Just to confirm the latest status down here as well: I worked in all feedback, and resolved the open conversations. Waiting for confirmation on the remaining open conversation above. Once that clears, this PR should be ready to merge. |
|
Thanks, @spier. The PR looks good to me now. Also thanks to everybody else who chimed in with feedback. I like the result. This is a great first iteration of the pattern. |
gruetter
left a comment
There was a problem hiding this comment.
Nice pattern, well done guys! I wonder why this wasn't created earlier ;).
| - A large organization (consisting of many legal entities) has many **internal regulations**. Any new agreements that are made have to comply with these regulations, e.g. security, privacy, procurement processes, etc. The volume of regulations can make it difficult to assess whether sharing software between two legal entities is compliant with these regulations, especially when there is no standard procedure. | ||
| - If any of the legal entities in the organization has a **business model** that depends on proprietary code and accounting of licensing fees within the organization | ||
| - **Company culture** that isn’t used to InnerSource collaboration and sharing code. This results in uncertainty about the rights and obligations when using shared code. | ||
| - Freedom over using the software leads to competition, and spread of ownership |
There was a problem hiding this comment.
This one' a bit fuzzy to me.
| - Freedom over using the software leads to competition, and spread of ownership | |
| - Unregulated use of the software can lead to unclear ownership structures, duplication of improvement effort or unwanted competition |
| - **Company culture** that isn’t used to InnerSource collaboration and sharing code. This results in uncertainty about the rights and obligations when using shared code. | ||
| - Freedom over using the software leads to competition, and spread of ownership | ||
| - There are legal contracts in place which cover the sharing of source code. These contracts are not standardized, so they create additional effort in negotiating and understanding for every project. The existing contracts may also not allow sharing source code in an open enough sense to support a true InnerSource approach. | ||
| - Alternatively, there are no legal contracts in place but source code is shared informally. That might create uncertainty in cases where clarity about ownership and rights and obligations is needed. |
There was a problem hiding this comment.
This one is at least partially a duplication of the force above, regarding the consequences of Freedom over using the software"
| It is important to write the InnerSource License such that it truly allows for OpenSource-like collaborations across the boundaries of the involved legal entities. Therefore the 4 freedoms of free software should be integrated into the license. | ||
|
|
||
| The License is written as a formal legal document, and can be used as part of contracts between the legal entities to govern the code sharing agreements. | ||
|
|
There was a problem hiding this comment.
We should mention that an InnerSource license needs to be ratified by the responsible bodies in the respective organisation. If there is no such ratification, the license might not be widely accepted by management ... or developers with a high need for job security.
There was a problem hiding this comment.
It might also make sense to mention to not be too strict about what can be done with the SW. We (at Bosch) made that mistake and precluded the use of InnerSource software in Open Source projects later on. This turned out to be a killer criterium for some of our projects and eventually triggered the development of a new version of the license, which took a lot of effort.
| - building communities for collaboration on projects, just like in Open Source | ||
|
|
||
| It is worth mentioning that so far the software shared under this InnerSource license is mostly tooling, infrastructure, and tools lower in the stack. | ||
|
|
There was a problem hiding this comment.
Add Bosch as an known instance, too. Here's my proposal for content:
"The InnerSource initiative at Robert Bosch GmbH was also governed with a license from the beginning in 2009. With over 500 legal entities, sharing software internally was very difficult and time consuming to implement in a compliant way. InnerSource and specifically the InnerSource license changed that completely. Today, collaboration in software projects governed by their InnerSource license is the de facto standard and widely practiced. Bosch has evolved their license over the years, e. g. to also allow the eventual publication of InnerSource software as Open Source software, which wasn't possible with early versions of their license."
|
@gruetter thanks for your feedback. The additional info on the "known instances" of this pattern in Bosch will certainly be interesting for the readers. As this PR has already taken 23 days up to this point, I would like to get the current version merged, and move further modification proposals to separate PRs. e.g. As soon as this PR here is merged, you can open a new PR that adds the "known instance" portion for Bosch. Hope this approach is ok? @maxcapraro we got sign-off from Cornelius on the latest version of this pattern (see above). If you could review and resolve the last open conversation thread at the very top, then @lenucksi can merge this PR :) Thanks. |
maxcapraro
left a comment
There was a problem hiding this comment.
Thanks @spier and @cornelius :) All my comments were adressed. Thus, I am changing my review status on this PR to approved.
(PS: Some comments by other reviewers are still open and worth adressing)
|
Hi @gruetter and @maxcapraro , thanks your reviews! |
InnerSource License pattern. Implements #138.
This has already gone through 3 iterations between Cornelius and myself (Sebastian).
We tried to use the Pattern template to the best of our knowledge.
We would like to get this merged into master as quickly as possible, so that Cornelius can get feedback from a broader audience, and hopefully also hear from companies that have used similar approaches.
If it speeds up the merge to master, we can also post this Pattern as "Pattern Drafts (proven, not yet fully reviewed)".