search

licensezero / parity-public-license

the free for open software license
https://paritylicense.com
Other
98 stars 8 forks source link

Examples #72

Open skorokithakis opened 5 years ago

skorokithakis commented 5 years ago

Hello! I'm not sure this is an issue with the license itself (feel free to close this if it's not), but as an OSS developer evaluating the license, it would be helpful to see a few examples somewhere, just because I don't entirely trust my ability to interpret legal documents.

For example, a short paragraph in the README or license body saying "this means that, under this license, you can/cannot <use the software in non-OSS software/use it in a SaaS/charge for it/include it in a codebase without opening that codebase up too/etc>".

It would help in making me more confident that I know what my license does, especially for a new license that hasn't had as much written about it as the GPL/MIT/BSD/etc.

makkus commented 5 years ago

I agree, I would like that too. I'm not sure how much (or whether at all) this is possible, without straying too much into 'legal-advice' territory. Also, it depends very much on the type of software you are offering, what can be done with it, and which contexts it is used in.

For my project, I added a sort of FAQ that is specific to the code in question, and I think that's a good idea either way (even with more established licenses, except the very permissive ones): https://freckles.io/license#private-licenses

Nonetheless, if at all possible, having examples and interpretations for non-ambiguous scenarios would be great. I wonder whether those test-cases Kyle had on some branches could be reused in some way ( https://github.com/licensezero/parity-public-license/blob/simplify-copyleft/tests/copyleft.md ).

Edit: Maybe -- if it isn't possible to explicitly use examples -- we could come up with a discussion-type-format that at least highlights some aspects in certain situations.

kemitchell commented 1 year ago

Going through issues again. This is still a good idea.

kemitchell commented 1 year ago

Must Always Contribute:

Assume all software falls into three categories: software programs, software components, and software platforms. Apps, plugins, and development tools are programs. Libraries, frameworks, and services are components. Kernels, base systems like BusyBox, interpreters, and orchestrators like Kubernetes are platforms.

If the Parity-licensed software is a ... licensees must contribute....:

Based on past licenses, I'm guessing the key points to get across in examples are that:

All the above is still pretty abstract. We would want to give examples in more specific terms. For example, not:

If you build a program using a Parity-licensed component, contribute your program.

But:

If you build an app using a Parity-licensed software library, contribute your app, whether you copy the code, link to it, or load it at runtime.

There are tons and tons of combinations in these more specific terms. Too many to list. Which to prioritize?

  1. Make clear Parity is a strong, network copyleft license that covers code like those licenses do: patches, additions, programs including Parity-licensed frameworks and libraries, network services using Parity-licensed databases.

  2. Emphasize where Parity reaches further than previous common network-copyleft licenses, like AGPL: software built with Parity-licensed development tools, broader systems using Parity-licensed services like databases, software built on Parity-licensed platforms like interpreters.

Focusing on just the examples that get key points across, we might keep the examples short enough to include right in the license text. I would strongly prefer that to creating any kind of "official" FAQ.