[JSR358-8] Licenses can change after EG member has contributed Created: 21/Sep/11  Updated: 08/Apr/14

Status: Open
Project: jsr358
Component/s: Licensing
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sean_sheedy Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Process Document review

line numbers: JCP-2.8-21SEP2011-Redlined.pdf

285-287 - We just went through a big deal with TCK licensing. Strike last sentence of paragraph, and add RI & TCK to preceding sentence. The EG members must not have a moving target after joining an EG.

PC> Good luck with that. It's impractical. There can be many legitimate reasons to tweak the original license. EC members are free to express their disapproval of changes by voting no.

SS> But EG members have no such recourse. This is one reason I feel Individuals need to be very aware of what they are getting into when they join a JSR. It is things like this - licenses that can be moving targets, ability for spec lead to effectively withdraw a JSR from further licensing - which makes this platform not a truly open platform. Solution: wording that advises socialization of licenses prior to initial JSR approval, and upon approval, the license is final; the license can only be changed with unanimous approval of any EG member who contributed to the specification. Otherwise a spec lead can lead the charge to change licensing, get a lot of members to agree, and leave others out in the cold. What if those others were individuals who joined on the promise of getting an open source license, but it was later switched for one less open? This is totally plausible, because individuals are sometimes the minority in an EG, and the EG process for stuff like this is at best loosely defined, so what may work for corporations (which have a back-channel available to them via cross-licensing agreements) might not work for individuals. I understand something like this happened with an SE/EE Resources API JSR but I am not clear on the details. I can try to get them if necessary.

Again: proposal - don't change license after initial approval (and before EG formation) without unanimous past/present EG member vote.



 Comments   
Comment by sean_sheedy [ 21/Sep/11 ]

Related:

468 - Change "proposed" to "final" so that prospective EG members and the EC are not surprised by changes to the licenses. To this end, we should recommend to spec leads that they socialize their licenses well in advance of a vote.

PC> As I said above, prohibiting any changes to licenses after initial submission is impractical.

SS> Again, requesting this for fairness - someone who has contributed and who finds himself out of luck due to a license change that the majority approved has no recourse.

Comment by pcurran [ 22/Sep/11 ]

It's too late to try to resolve this. I've marked it Defer for future consideration.

We've only just introduced the modified language around license disclosure. Let's see how things work out in practice.

Generated at Mon Aug 31 07:06:32 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.