Prototypes exception too limited?

[laughinghan]

This license is in great shape—a long ways from the Shared Component days for sure!

I wonder if the Prototypes exception is too limited, though. Does this mean if the software doesn't quite do what I want, so I git-cloned it and every couple of weeks I come back to it and tinker with it trying to get it to do what I want, then after 30 days I'm technically in violation?

A simple change would be to replace "all of these criteria" with "any of these criteria". This makes more sense for Round Robin specifically than Parity, since Round Robin's purpose is to ensure competitors share their changes, and competing with you probably requires sharing their version with customers (or operating it on behalf of customers), whereas Parity-licensed software may be for personal use. Not sure how much you care about the Prototypes clause being the same as in Parity?

Two possible problems are that that would allow people to ship stuff and only publish the source 30 days later (and do so routinely, not just the first time as Excuse allows), and that "non-production user testing" could be read to include "beta testing", but Gmail's 5-year "beta" was basically production.

Maybe one way to distinguish "hallway testing a prototype" from "endless beta" is duration of the test as advertised to the user? If testers understand they only have access for a few days, they probably can't treat it as basically production. So maybe the language could be:

You don't have to contribute any change, addition, or other software that isn't shared outside the team developing it, or is shared only briefly for user testing purposes. Sharing means distributing a copy or providing access to the functionality. User testing means providing a subject with access to a copy or to the functionality in order to gathering feedback. Sharing for user testing purposes means that the value gained from sharing is solely due to the feedback gathered, not due to the subject being granted access to the copy or functionality. Briefly means the subject has access for no more than 30 days at a time.

(I go out of my way to define "sharing for user testing purposes" because some software might be mostly single-use, like deleted-file-recovery, where most customers don't need >30 days of access anyway. I also include a time limit since that seems much easier to enforce. But maybe one's unnecessary, given the other? Should "briefly" be shortened to a day or something? The strict definition of "sharing for user testing purposes" excludes sharing for demonstration purposes, but is that necessary considering the main purposes we want to exclude are profiting off of it, obviously from directly selling access but also from it being some kind of value-add (like Gmail was for Google)? I specifically don't just say "you can't profit from it" because testing is arguably profitable.)

Anyway, if you like this direction, I'm sure that can be improved and hopefully simplified.

[kemitchell]

@laughinghan, great to hear from you! First and foremost, I hope you and yours are all doing well. It's been a tough year.

I can see the thirty-day time limit being too simple, and snagging on edge cases like your on-again, off-again project. I like the idea that "checking a project out" should come with a sense of urgency, but agree that thirty days is strangely specific. Certainly I've had folks come to me for slightly shorter or longer trial periods under other licenses. There's no one-size-fits-all number.

So one question is whether the clarity and objectivity of a fixed time limit is worth more than the cost of oversimplification. And another question is how to pick a number in days to tune that balance. The big, overarching question is whether an exception for prototypes is the right way to go at all. Should there just be a free trial period?

As for the other criteria in the license right now, I don't think production use aligns with my intuitive sense of a prototype. I could see a case for allowing "hallway testing" with colleagues who are not themselves developers, but wanted to avoid drawing another fuzzy or arbitrarily sharp line between permitted testers and customers. In the company context, we could talk about employees and contractors. But that wouldn't offer much clarity in other situations.

I don't care at all about uniformity with Parity or other licenses. If they aim at the same goals, they should be able to reuse language. When their goals or likely circumstances differ, their language likely should, as well.

[laughinghan]

I appreciate that so much, same to you!

Speaking for myself, a prototypes exception better fits my conception of how I would use this license than a free trial period—I think of it as a right-to-repair/right-to-tinker/right-to-improve kind of thing. Pragmatically, I also think a "private use"-style exception makes it easier to gain acceptance from the broader F/OSS community.

I don't think production use aligns with my intuitive sense of a prototype

I'm confused by this paragraph, but I was probably unclear to begin with and this is responding to that. I agree with you that any kind of production use should be excluded from the prototypes exception. The primary goal of my suggested language was to clarify what is and isn't production use, and in particular, be explicit that Gmail's 5-year "beta" is actually production use for the purposes of this license. This explicitness isn't important in the currently published version of the license because the 30-day limit serves as a backstop to any ambiguity about "non-production user testing", but this ticket is about potentially removing that 30-day limit.

My intuitive sense of a prototype is that you would only share it for testing purposes or maybe demo purposes; if you're giving customers access because actual use of it provides value to the customer, then it's basically production use and not a prototype.

I also realized my suggested language introduces a big problem: I intended for "access to the functionality" to cover "use it on behalf of", but it totally doesn't, it would be quite a stretch to say GitHub offers me "access to the functionality" of whatever database they're using. Here's my attempted fix, which is also shorter:

You don't have to contribute any change, addition, or other software that isn't shared outside the team developing it, or is shared only briefly and only to gather feedback. Briefly means no more than 30 days at a time. Operating software on behalf of someone is sharing it with them, as is distributing a copy. If your reasons for sharing go beyond the feedback gathered, such as if use of the software provides value to the user, then you have to contribute it.

[kemitchell]

Ah. I didn't register the depth of your concern with "production".

I've printed out a copy of the license, and will read with that in mind later tonight.

Without looking at it, a side note from the legal department: If there were a dispute about the word "production" in the license, an American court would likely identify that as an industry term and allow evidence about how industry people use and understand it. The search terms for one entry point to that topic: "usage of trade".

[kemitchell]

On fresh read, I see the reason for concern. It's not just "production", it's "non-production", and bound up with another squish industry concept, "user testing", to boot.

The current approach is just to punt that complexity to industry usage. That's a trade-off between clarity and potential for slippage over time. The people reading the license are likely to be industry people, and it's helpful to have a rule that says courts will try to understand the terms the way industry people do. On the other hand, the way industry people understand terms can change.

One way to avoid this might be to restrict the idea of a prototype to something purely technical, "in the lab" only. You build a prototype to make sure that the software will work as software, and not for any other questions, like whether users like it or the business case looks strong. That would mean dropping all mention of user testing, so it's just the development team. I'd rather not, because many times the "users" are bringing just as much expertise to the team as the developers. The developers may be able to wire up, say, a library for a scientific task, but they'll need a user-scientist to tell if the outputs are scientifically sound.

As a first stab, how about making clear that a development team can also include non-software people?

  ## Prototypes

  You don't have to contribute any change, addition, or other software
  that meets all these criteria:

  1.  You don't use it for more than thirty days.

- 2.  You don't share it outside the team developing it,
-     other than for non-production user testing.
+ 2.  You don't share it outside the team developing it,
+     which may include software developers,
+     business managers, testers, and other team members.

  3.  You don't use it on behalf of anyone outside
      the team developing it.

If this feels promising, I'll be happen to open a PR.

[laughinghan]

Well, if you want to keep the thirty day backstop, I think the industry meaning of "non-production user testing" is plenty clear enough, and it benefits from brevity. I also like that it allows for "hallway testing" with people who aren't team members, which your suggested change appears to exclude.

Personally, for any project where I'd consider using Round Robin, I'd want some kind of "private use"-style exception without a strict time limit, as a matter of right-to-repair/right-to-tinker sensibilities. I totally understand if the fixed trial period is an intentional design choice that is part of your conception of the license, though.

[kemitchell]

I'm not sure that I feel like the usual ethics of "right to repair" apply to prototypes. The idea there, for me at least, is that you get a chance to try the code out to see if it meets your needs. Once you're truly reliant on it, or using it "in production", you need to contribute. At that point it's just more open software.

"Right to Tinker" is new on me, but I see the appeal. The obvious escape valve here is a project-specific exception. Even if the form license says thirty days, you could be more generous in a note in README or LICENSE:

The Round Robin license limits use of prototypes to thirty days, but I give extra permission for this project to use prototypes for ninety days.

I think the alternative would be to add more language trying to express the idea of intermittent attention to a project. So something like:

You don’t use it [the prototype] on more than thirty different days, which might be thirty days in a row or thirty days spread across a longer period.

[laughinghan]

The idea there, for me at least, is that you get a chance to try the code out to see if it meets your needs. Once you're truly reliant on it, or using it "in production", you need to contribute. At that point it's just more open software.

Totally with you there, it's just that the current language reads to me as requiring contributing even before you're reliant on it or using it "in production". Hence the suggestion to trigger based on whether sharing is just to get feedback, or is actually providing value beyond just feedback gained.

[kemitchell]

Yeah, I see the case for dropping the time limit here.

The time limit isn't really part of the definition of "prototype". It's more of a safety catch and a concession to the practicalities of enforcement. At some point, you want to move beyond arguments about uses or sharing---things the user only really knows firsthand and might have evidence about---to something clear and objective that's easy to prove without the user fessing up.

The question in my mind could be described as "prototype" versus "trial". I think thirty is a rational number for a trial. It's plenty of time to see if the thing will work, as it's described and integration. A prototype could continue long after that's clear.

My concern is that once that is clear, we probably want changes and additions contributed back, even if the business or other group producing them doesn't end up taking them into production.

We don't necessarily want the prototype itself, which may very well be an application. Sharing an application as a whole is never required. But if the prototype is more of an embellishment or extension of the licensed software, and somebody is putting more than a month of effort into it, we want that contributed back, not kept closed because their particular business case hasn't become clear.