Git Product home page Git Product logo

opencasebook's Introduction

The Open Source Casebook provides an analysis of several key legal topics in open source, grounded in primary sources.

This casebook does not provide legal advice, and represents the views solely of its contributors in their individual capacities. Please consult with your own lawyer for legal advice.

You can view the casebook at https://google.github.io/opencasebook/

Casebook

The Casebook reproduces and discusses primary sources like case law, statutes, and license text.

Practitioner's Guide

The Practitioner’s Guide outlines best practices for using and creating open source.

opencasebook's People

Contributors

hlry avatar sillsm avatar vanl avatar willnorris avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opencasebook's Issues

add License on Transfer Network (”LOT Network”) to patents.md#industry-agreements?

The section industry agreements focusses on the Open Invention Network, and does not mention the License on Transfer Network yet.

LOT complements OIN: OIN is a mutual irrevocable patent license grant, and a mutual non-aggression and defense commitment, giving up on patent License revenue from OIN members on "Linux System" related patents. In contrast LOT keeps the patent Licensing revenue alive and focusses on preventing patents from becoming "troll-able", i.e. a patent that is part of LOT Net can in perpetuity not be enforced against LOT Net member companies by entities doing just patent enforcement ("patent Trolls").

So LOT Net membership transparently protects Licensees from incidental future patent transfer to trolls, while it allows a fair and honest patent holder today to traditionally license their invention (far up in user space, on top of an OIN Linux System).

It's a protection against partners "breaking bad", so to speak.

Alas IANAL and I don't feel comfortable creating a pull request, citing individual cases, though.

Questions wrt license application through pull requests

Thank you so much for providing this information to the public. It's great to have a better understanding of how lawyers reason about these issues.

I'm always interested by anything that can help make the contribution flow more seamless while maintaining sufficient protection of the project and its users. In this regard, the "pull request hack" that you describe in authorship.md is particularly intriguing. I have a couple of suggestions and questions about it.

In authorship.md it states that:

The first convention to note is the technical nature of “pull request”
contributions to open source projects. When a GitHub member contributes a patch
to someone else’s project on GitHub, they generally do so in the form of a pull
request. The pull request entails copying the entire project and republishing
it, together with the contributor’s modifications, as a new version. Therefore,
as part of submitting that patch, the user has formally applied whatever license
documentation had been included in the project to the contents of the patch.

  1. Depending on the user's permission level on the project, a pull request can happen either on the user's own fork of the project or on the project itself. I assume that this doesn't change much from a legal perspective—the user has formally applied the license to their patch in both cases—but it would be nice to clarify whether both of these options are covered.

  2. Typically, once the pull request is merged, the user deletes their branch. The option to do so is part of the UI on GitHub and presented as the standard follow-up step. In doing so, doesn't the user destroy evidence of having applied the licence to their patch, and isn't that a problem?

I understand that you cannot provide legal advice here, but I think that addressing these two issues in the document itself would be helpful to readers beyond myself.

Thank you.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.