Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconciliation Proposal #978

Closed
mikeal opened this issue Feb 26, 2015 · 222 comments
Closed

Reconciliation Proposal #978

mikeal opened this issue Feb 26, 2015 · 222 comments
Labels
discuss Issues opened for discussions and feedbacks. meta Issues and PRs related to the general management of the project.

Comments

@mikeal
Copy link
Contributor

mikeal commented Feb 26, 2015

A lot of questions have been coming our way about what a merger of the node.js and io.js projects might look like. People in both projects want to know their work won't be thrown away and that we can preserve the positive aspects of each project.

This is a draft and will be continually updated and edited based on input from the community. It is not an ultimatum to Joyent or The Node.js Foundation but rather a collaboration point for the io.js community to produce a proposal for merging.

This document uses the terms io.js and node.js to refer to those projects prior to a merge and Node to refer to a future merged project.

While io.js is often used as a starting point this document treats a future project under the foundation as a new organism made from the merger of each project and not as an extension of only node.js or only io.js. The goal of the merger should be a project that is actually greater than the sum these parts.

Technical Governance

The Node.js Foundation would adopt, as it's Technical Governance Structure (which is distinct and seperate from the foundation governance structure), a very simple structure which would ensure the following:

  • Decision making autonomy from the foundation and its board.
  • Ownership of its own governance and voting structure.

Because foundation bylaws are quite difficult to change and the TC wishes to make continued iterative improvements to its structure it would be a mistake to bake the entire governance structure as it exists today in to the foundation bylaws.

As an initial agreed upon structure, beyond what is in the bylaws, the following documents would be adopted from io.js.

In addition to the definition of "collaborator" from CONTRIBUTING.md the list of existing collaborators to io.js would also transfer.

The following changes would be made to these documents prior adoption:

  • Addition of TC members:
    • TJ Fontaine
    • Alexis Campailla
    • Julien Gilli
  • Addition of Collaborators:
    • James M Snell
    • Stephen Loomis
    • Michael Dawson

Long Term Support

High level ideas about LTS are addressed in the io.js roadmap but it lacks specifics because io.js has not yet produced a release that breaks compatibility with prior releases which would cause it to begin executing on this plan. The node.js project has an informal Long Term Support policy which is not formally documented but it does produce patch releases for prior versions so we can assume some policy does exist.

LTS WG (Long Term Support Working Group)

The following is a draft charter for the LTS WG which would be added to WORKING_GROUPS.md.

The LTS WG is responsible for maintenance and releases of prior versions of Node.

Node produces patch releases of prior versions for as long as community members are willing to maintain them. The LTS WG is responsible for when it no longer has the contributions necessary to support a particular version.

The LTS WG's responsibilities are:

  • Authoring and backporting bug fixes, stability improvements, and other relevant
    changes to prior releases (not CURRENT or CANARY).
  • Creation and maintenance of tools to help manage and automate backporting changes.
  • Documentation and enforcement of policies to ensure the stability of patch releases.

Initial Members would include

  • Michael Dawson

Note that specifics around managing branches is left out of the
charter but is part of the responsibilities for the working group under the last
bullet point.

Versions Merger

Because there is currently no overlap between io.js and node.js versions we can, and in fact must, consider all versions of both projects as now being versions of Node. If we did not we would unnecessarily break a large portion of the community that depends on these versions.

Prior Releases

The following versions are considered "prior releases" and are under the control of the LTS WG>

  • 0.8.x
  • 0.10.x
  • 0.12.x

It should be noted that while 1.0+ releases follow semver versions prior to 1.0 did not and it is at the discretion of the LTS WG whether or not they would like to take API additions in to 0.12.x and 0.10.x patch releases. However, backwards incompatible changes cannot be made to these releases in following with the existing policies of both node.js and io.js.

Current Release

  • 1.x

As it stands there are two CURRENT development lines: node.js 0.12.x and io.js 1.x. Development, in some form, will need to continue on both of these lines as different users depending on each line. The question then becomes "which line do we put in to LTS?"

In the last few months io.js has made huge gains in part due to the fact that it aligned its current stable line of development with that of its dependencies. That, along with a faster release cycle, has also brought many module authors in to core and so the ecosystem is beginning to also align its current stable development with that of core. This has ushered in a new era of collaboration between projects and the larger community which Node should continue.

This does not, however, mean that 0.12.x is a "dead" line. Far from it, 0.12.x and 0.10.x are still in use by many users and it will be the work of the LTS WG to continue to ensure those users have a stable and supported platform.

Non-Versioned Releases

CANARY ("next" V8 and any changes marked as major)

Along with the current stable line of development there should be a future line. This line exists as a branch and non-versioned nightly builds for testing. It is a testing ground for changes to Node that would necessitate bumping its major version as well as for testing the CANARY version of V8.

Just as we have done with current stable, the "next" line of Node development should align with that of its dependencies. This allows the project and its users to easily test for performance regressions and potentially breaking changes in those dependencies while active development is still occuring and long before they land in a stable version of Node.

Website

The nodejs.org website would transfer to the Website WG and become the responsibility of that working group. The website will be retooled similar to iojs.org (gulp builds) so that it can be localized by the various language communities from io.js.

Social Media

The social media accounts (Twitter, Facebook, etc) will transfer to the Evangelism WG.

Evangelism WG

This io.js WG will move to Node (pending a vote by the WG) and continue to produce weekly updates, social media engagement, etc, for the Node project.

i18n

All io.js language community working groups (32 individual teams by last count) will vote to
move to the Node project where they would continue to be endpoints for community members to
collaborate with each other in their language of choice and produce localizations of project resources.

Roadmap WG

This io.js WG will move to Node (pending a vote by the WG) and continue to draw in feedback
from users and draft roadmap materials for consideration by the TC.

Streams WG

This io.js WG will move to Node (pending a vote by the WG) along with readable-stream and will continue to define and improve streams in Node.

Tracing WG

This io.js WG will move to Node (pending a vote by the WG) and continue to improve the transparency of Node applications.

Build WG

This io.js WG will move to Node (pending a vote by the WG) and continue to maintain and improve the build infrastructure and produce Node builds.

@piscisaureus
Copy link
Contributor

Addition of TC members: TJ Fontaine, Alexis Campailla

What about Julien, Steven, James, Michael who are now only working on node?

All io.js language community working groups (32 individual teams by last cound)

Nit: cound (spelling)

@ghost
Copy link

ghost commented Feb 26, 2015

@mikeal Should we notify Node.js of this to get their input?

@mikeal
Copy link
Contributor Author

mikeal commented Feb 26, 2015

What about Julien, Steven, James, Michael who are now only working on node?

The io.js TC is a small subset of the contributors/committers to io.js. I don't know enough about each of these individuals (other than Julien) and their work on node.js to know if they should be added to the TC (also wondering if they want to being that it's another weekly meeting on their schedule). Are these other people committers to node.js? Are they involved in driving the technical direction?

I saw that Julien did the 0.12 release though so it's pretty clear that he should be added.

@jasnell
Copy link
Member

jasnell commented Feb 26, 2015

Steven, Michael and I (all from IBM) have recently been accepted as "Apprentice" members of the node.js core. Steven is primarily driving the Ecma-402 enablement, Michael's team is working on the ppc and system z ports, and I am focusing currently on globalization. As I understand it, we will soon have commit rights to node.js, albeit with an obvious need for review as we earn our stripes.

Once the foundation tc launches, we would very much like for our status to be retained, allowing us a chance to continue pushing forward with contributions. Each of us have been participating in the development of the node.js post v0.12 roadmap although we admittedly have a ways to go before rising above the "apprentice" level.

(and thank you @piscisaureus for thinking of us 👍 ...)

@mikeal
Copy link
Contributor Author

mikeal commented Feb 26, 2015

@jasnell thanks! This clears things up.

The closest thing to "apprentice contributor" we have would be "collaborator" and that would also give you commit rights. Although it should be noted that all changes are done as pull requests and reviewed in io.js, even changes being made by TC members, and if the CONTRIBUTING.md file from io.js is adopted that policy would remain.

In addition to being collaborators it would make a lot of sense to add anyone working on PPC and Z ports to the LTS WG which would be maintaining old V8/node.js lines.

Does that sound about right?

@rvagg
Copy link
Member

rvagg commented Feb 26, 2015

ECMA-402 & globalization support actually brings up an interesting issue: io.js hasn't enabled Intl support yet, both the TC and apparently the community (purely on anecdotal evidence, or the lack of it), haven't decided there is a need for this to be enabled in core. There may be technical reasons for it to be but the strong preference within the io.js "team" is to have a smaller core without overloading it with things that could be easily achieved in userland and we will strive hard to make that possible.

I have strong concerns about some of the work I see going on in joyent/node on this front. I'd like it noted that not only are there concerns on the Joyent side of this about the activity that has gone on in io.js since the fork (stated by Joyent representatives), but there are now also concerns on the io.js side of this about the activity that has gone on in joyent/node.

Clearly the longer it takes to find a mechanism for merging, the further the two projects will diverge based on both the amount of activity but also the philosophical and technical direction chosen by the separate parties and this will increase the difficulty of achieving a technical merger.

@jasnell
Copy link
Member

jasnell commented Feb 26, 2015

That sounds about right, yes.

@piscisaureus
Copy link
Contributor

Clearly the longer it takes to find a mechanism for merging the further the two projects will diverge based on both the amount of activity but also the philosophical and technical direction chosen by the separate parties and this will increase the difficulty of achieving a technical merger.

Maybe we can get concrete here/somewhere? The things that come to mind on my end -

  • Node has landed ICU (ecma402 support). I'm not against that per se, but I have my opinions on the distribution model (iow -- let's not make node 3x bigger if we can help it).
  • Node has added SSLv2 support and make SSLv2/3 configurable with a runtime option. Io.js has dropped support for either protocol for security reasons.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 26, 2015

Ok, added Julien to TC, IBM folks to collaborators and LTS WG.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 26, 2015

@rvagg @piscisaureus I think that these technical details should really be figured out by the TC and the LTS WG. New releases of 0.12.x should probably NOT drop support for something they previously supported. The 1.x line is already considered a "breaking change" from 0.12.x so there's no problem not having this stuff there (at least in terms of merging the existing versions).

As far as what happens with ICU and SSL in the CURRENT line (1.x), that's up to the TC which would gain 3 new voting members.

@piscisaureus
Copy link
Contributor

Ok, added Julien to TC, IBM folks to collaborators and LTS WG.

That's okay for now I guess. I would argue it doesn't make much sense to put 3 IBM-ers in the LTS wg.

Ee can work this out later as well, e.g. if the IBM folks want to work on something not currently on the roadmap we could just consider the idea and create a separate wg if appropriate. Also having having at least one IBMer join TC meetings would be helpful.

@ghost
Copy link

ghost commented Feb 26, 2015

@mikeal @rvagg Maybe we could have a "bare" edition (currently io.js) and a "extra" edition (currently node.js.

@jasnell
Copy link
Member

jasnell commented Feb 26, 2015

@rvagg We happen to share many of those concerns and would like to see reconciliation happen as quickly and as smoothly as possible. Doing so would benefit the community as a whole.

As far as the Ecma402 work that @srl295 has been doing, we are definitely sensitive to the concerns but proper i18n support is a must have for us. It's why we put the work into enabling it. This thread, however, does not seem like the right place to have that particular discussion.

At some point, we ought to just get everyone together from both projects and simply lay the technical concerns out on the table and figure out how we're going to resolve them. (btw, If it would help, I've got a conference room in SF we can use to get as many people face to face as we can.)

@ghost
Copy link

ghost commented Feb 26, 2015

Wait, @mikeal, do we want to notify node.js?

@jasnell
Copy link
Member

jasnell commented Feb 26, 2015

@mikeal... as @piscisaureus suggests, it would likely make more sense to just have Michael in the LTS wg as it's his team that'll be working on those particular pieces.

@piscisaureus
Copy link
Contributor

@mikeal @rvagg Maybe we could have a "bare" edition (currently io.js) and a "extra" edition (currently node.js.

I think it's not too compelling two have two versions that differ only in ecma402 support. We should just pick a reasonable default and - if needed - distribute additional bits on npm.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 27, 2015

@jasnell @piscisaureus updated so that just Michael is in LTS WG.

@piscisaureus
Copy link
Contributor

@joyent/node @iojs/collaborators

@mikeal
Copy link
Contributor Author

mikeal commented Feb 27, 2015

We'll need all the working groups to ratify so I'm going to ping them:

  • @iojs/docker-admin
  • @iojs/build
  • @iojs/collaborators
  • @iojs/core
  • @iojs/tracing
  • @iojs/crypto
  • @iojs/website
  • @iojs/evangelism
  • @iojs/streams
  • @iojs/iojs-bg
  • @iojs/iojs-bn
  • @iojs/iojs-cn
  • @iojs/iojs-cs
  • @iojs/iojs-da
  • @iojs/iojs-de
  • @iojs/iojs-el
  • @iojs/iojs-es
  • @iojs/iojs-fa
  • @iojs/iojs-fi
  • @iojs/iojs-fr
  • @iojs/iojs-he
  • @iojs/iojs-hi
  • @iojs/iojs-hu
  • @iojs/iojs-id
  • @iojs/iojs-it
  • @iojs/iojs-ja
  • @iojs/iojs-ka
  • @iojs/iojs-ko
  • @iojs/iojs-mk
  • @iojs/iojs-nl
  • @iojs/iojs-no
  • @iojs/iojs-pl
  • @iojs/iojs-pt
  • @iojs/iojs-ro
  • @iojs/iojs-ru
  • @iojs/iojs-sv
  • @iojs/iojs-ta
  • @iojs/iojs-tr
  • @iojs/iojs-tw
  • @iojs/iojs-uk
  • @iojs/iojs-vi

@ghost
Copy link

ghost commented Feb 27, 2015

@mikeal I notified joyent/node via nodejs/node-v0.x-archive#9295.

@benjamingr
Copy link
Member

As a member or @iojs/iojs-he I'm fine with moving to Node as long as contributing stays similar to how it is in io.js and the governance model remains open and community driven.

@indexzero
Copy link

This is a well written and even keeled approach to reconciling the two code bases. The only large question I see here @mikeal is what would happen to node.js@0.12.x if it was continued to support over LTS and continues to diverge from io.js@1.x.x for natural reasons under a unified TC.

That is however, largely a question for @iojs/core and the node.js core folks and I'm sure a reasonable plan will be agreed upon.

@isaacs
Copy link
Contributor

isaacs commented Feb 27, 2015

Most of this looks good to me.

The only point of significant technical divergence at this time seems to be intl.

I do not want to see io.js become "node-lite" and joyent/node to become "node-with-intl". It's not a pressing issue blocking merging the projects, but I would like to see some very clear-cut decision made by the TC about whether we're going to ship intl or not. We should not have two different flavors or distros, especially not under the same name; that's even worse than what we have now.

The most successful end-game is a single "node" that can make forward progress.

What I've heard from Joyent folks is that they'd like to see a clear-cut strategy for long-term support that doesn't leave users behind in the cold. I think that's a fair request, and the LTSWG is working on it. Let's continue that process.

Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized before the projects have had a chance to integrate and find common ground. That's also fair, in my opinion. Merging these projects will certainly cause some conflicts, and it's unlikely that anyone will be able to collaborate in good faith if they're busy watching their backs for political maneuvering. I've suggested in the past a temporary moratorium on expelling anyone from the TC for some reasonable period of time as a way to address that concern, but there may be other strategies as well.

From what I've seen and heard in the foundation setup, they do want the TC to be self-governed, and protected from undue influence by the executive board. However, they also want to make sure that the project won't be hijacked immediately in bad faith, which is why we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress.

At the last JNAB meeting, there was a suggestion of getting the io.js TC and the node foundation folks together to discuss this. I think that's a good idea, but also sent out some homework questions to hopefully prime the discussion in an empathetic and collaborative direction. Hopefully we won't just get in a room and talk past each other for hours.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 27, 2015

Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized.

I understand that this is a concern but I find it somewhat unwarranted. The process is too transparent for a set of people to successfully cut someone out in bad faith without significant negative consequences for those people and the project as a whole. Additionally, I would expect that those who are significantly invested in concerns over the stability of prior releases and LTS to be members of the LTS WG which is just being created and, being that it will mostly be involved in 0.12, I would expect it to be dominated by node.js contributors, at least at first.

Anyway, if all of this isn't enough to alleviate concerns then we can consider some period of time where people cannot be removed from the TC. That said, we can't mint membership entirely or guarantee seats for too long, considering how fast the project has grown and how much we've needed to adjust as we've gone we don't want to mint anything for too long.

@indexzero
Copy link

@isaacs we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress.

I 100% agree with you that strict consensus (i.e. veto) will be very problematic for getting things done from the technical perspective. What other significant differences are there? I've lost track of where the JNAB minute notes get posted.

@mikeal
Copy link
Contributor Author

mikeal commented Feb 27, 2015

strict consensus

I'm gonna go out on a limb and say that strict consensus for any part of decision making is a deal breaker. If an argument breaks down and we can't reach an agreement it isn't acceptable to just do nothing and grind to a halt and we already know that is where strict consensus can lead for this exact group of people.

The consensus seeking model is working tremendously well. If we're worried that the voting fallback (which we've never actually had to use BTW) is too permissive for certain decisions we can consider upping the majority necessary to 60%.

@davglass
Copy link
Contributor

I'd like to see Intl added in as a single language by default then allow the end user to compile in all the languages that they want or hot load them on the fly. We are very excited to be able to use Intl for all of the languages that we have to support 😄

@listochkin
Copy link

Like others said, the plan looks reasonable and promising, and @iojs/iojs-uk group will definitely support its current version or any modified version that still follows the spirit of the original proposal. We are interested in promoting and expanding Node-the-ecosystem and strongly believe that the unified project will benefit everyone.

Regarding Intl we support having it build into Node. Ukrainian is a distinctive Slavic language with non-Latin alphabet, distinct collation rules, etc. The target audience of our group are people who use Ukrainian to learn programming in general, JavaScript and Node in particular, and who are very likely use it to use Ukrainian in their software. The fact that many language-specific features will just work is very valuable.

We don't think it should be a separate module on npm, though. Ecma402 defines the standard I18n API with globals, and we would expect Node to behave this way, too. Ultimately, both Node.js and iojs today claim to be JavaScript platforms, and global Intl is a part of the standard.

If it can be a some kind of magic module, then so be it. However, if a person would have to download it and/or update it separately, then we'd likely repeat the mistake JVM made with an isolated copy of tzdata. JVM's tzdata can be updated separately from a system-wide one. Most developers and admins, however, don't bother with it. As a result most Java deployments out there have an up-to-date system-wide tzdata that is completely ignored by the JVM, which instead uses an obsolete version.

Speaking of binary sizes I suspect that most major operating systems have i18n libraries and APIs build in. We could potentially link to those instead of forcing users to download ICU every time they update Node.

Of couse there are certain situations when having Intl enabled is undesirable, for example for Raspberry Pi builds. However, in our opinion not having Intl should be a deliberate choice. I18n should be opt out, not opt in

@yoshuawuyts
Copy link

The goal of the merger should be a project that is actually greater than the sum these parts.

To me it's still unclear what benefits a merger with node.js would have. This issue appears to be more focused on the how of a merger, and less on the why. Is there an overview where the benefits / costs of merging with node.js are outlined? If there's not, I'd be curious to know what the view of the io.js TC and collaborators is on this (possibly in separate issue, if this is not the right place for it). Thanks!

@Fishrock123
Copy link
Member

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

The point was to have open collaboration to help move node forward. That has and will continue to happen. :)

There was no stagnation, people have been working very hard on node the whole time. Don't confuse actual stagnation with you just weren't getting the features you wanted

Why did most of the existing collaborators move (and want to move) the majority of their efforts here then?

@algesten
Copy link

There was no stagnation, people have been working very hard on node the whole time.

So where is this hard work? Which repo? An opensource project, surely there are some commits somewhere?

@mikeal
Copy link
Contributor Author

mikeal commented Mar 30, 2015

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

Why would we stop development and why would it be technical debt? If you'd read the actually reconciliation proposal you'd see that the different version lines from both io.js and node.js would remain intact.

There was no stagnation

This is simply not true. Contributions to node.js were at an all time low when we forked and releases had slowed to almost zero. You don't have to take my word for it, you can look at the contribution graphs and the release timelines. Yes, there were "people working on node the whole time" and most of those people were the initial contributors to io.js :)

Anyway, this line of complaint is not actually productive. We have a proposal for reconciliation, we have a proposal for open governance in the advisory board we're working on. joyent/nodejs-advisory-board#30 Things are progressing nicely toward a reconciliation and there is no need to stop development of io.js waiting for those to complete. I honestly don't know where that hostility came from but it seems very misplaced.

@piscisaureus
Copy link
Contributor

After processing the first round of comments, a draft charter has been landed in joyent/nodejs-advisory-board@0609b04.

Mikeal is now making an attempt to add "support" for working groups to the foundation's technical governance documents: joyent/nodejs-advisory-board#33.

@rosskukulinski
Copy link

thanks @piscisaureus

@cusspvz
Copy link
Contributor

cusspvz commented Mar 30, 2015

Because there is currently no overlap between io.js and node.js versions we can, and in fact must, consider all versions of both projects as now being versions of Node. If we did not we would unnecessarily break a large portion of the community that depends on these versions.

"Non-Versioned Releases" could use some clarification. This section notes that "It is a testing ground for changes to Node that would necessitate bumping its major version as well as for testing the CANARY version of V8."

So, does it means that CANARY v8 version merges will be available on some sort of node 1.x-canary stable builds only after testing?

It would be great if there was a second diversion on node's canary releases such as unstable which could have most of merges from nightly CANARY. It would be faster to identify which could be merged or not every day.

Couldn't it allow CURRENT and CANARY to have similar releases, or even the same?

That would allow:

Versions:
x.x.x - CURRENT
x.x.x-canary - CANARY

Non-versions:
nightly-build-current - CURRENT branch
nightly-build-canary - CANARY branch
nightly-build-canary-unstable - CANARY testing branch

@Starefossen
Copy link
Member

On 30. mars 2015, at 20:56, Travis Webb notifications@github.com wrote:

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

It is obvious that you know very little (or nothing!) about what V8 actually is and what importance it plays in node. You don't really seam to grip how open source works either. Sad.

@cjihrig
Copy link
Contributor

cjihrig commented May 12, 2015

Closing this in favor of #1664

@luke-john
Copy link

@trademark-question the trademark ownership will be transferred to the foundation as part of Joyent "putting node.js in a foundation" and the foundation will be responsible for a new trademark poilcy for node.js.

@mikeal The new foundations trademark policy contains the following text

Q: Does the Node.js Foundation Own the Node.js marks? A: No, the Node.js Foundation
does not own the registered Node.js marks, but the Foundation has full authority to
authorize your use of the Node.js marks consistent with these guidelines.
Joyent, Inc. acts as a Trademark steward for the Node.js word mark and logo. When reasonable, please
include this notice when you use a mark outside of the Foundation:
Node.js is a trademark of Joyent, Inc. and is used with its permission. We are not endorsed by or
affiliated with Joyent.”
https://nodejs.org/images/foundation-trademark-policy.pdf

Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

@Fishrock123
Copy link
Member

Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

  1. It's a legal quagmire to do the actual transfer.
  2. Owning it would mean we would have to expend resources enforcing it ourselves.

(There might be a 3? I forget.)

Edit: Also it wasn't the actual cause of the split. Poor project management would be closer to the actual reason.

@feross
Copy link
Contributor

feross commented Jun 17, 2015

  1. Why? Selling a trademark is straightforward. Joyent can sell it to the foundation for $1.
  2. Isn't that what all the corporate funding and fancy suits in the foundation should be doing?

@Nicolab
Copy link
Contributor

Nicolab commented Jun 17, 2015

+1 @Fishrock123, @feross

@mercmobily
Copy link

I am absolutely nobody here. Just giving my humble 2c

  1. It's not too hard
  2. I don't think it would be fair to expect Joyent to do all the work of protecting it. Quoting feross: "Isn't that what all the corporate funding and fancy suits in the foundation should be doing?"

Keeping the trademark, a crucial part of node, would be "leasing node to the foundation", rather than "giving it to the foundation".

@mercmobily
Copy link

  1. You don't want to end up like this

@Fishrock123
Copy link
Member

^ cc @mikeal, @piscisaureus, & @rvagg I guess.

@mikeal
Copy link
Contributor Author

mikeal commented Jun 17, 2015

Sure, transferring an asset is simple but this is an asset that has been on the books of a company for 5 years while it has done all the things you would expect it to do (raise money, acquire lines of credit for hardware, etc). Joyent is not in a position where it can transfer the ownership of the mark (I'm sure they'd prefer it as the way the deal has to be structured they are stuck with the legal bill of enforcement while the foundation administers the conditions of use). I share the concerns around prior arrangements of this nature but you'll notice that many of the companies you note were unhappy with prior arrangements are members of the Node Foundation and they worked hard to make sure this arrangement did not have the same problems prior arrangements did. I'm not a lawyer, but I'm confident that the lawyers from companies suffering from prior arrangements did a good job of protecting us from those same problems. That doesn't mean we might not have new problems of our own some day, but I'm not worried about having the same problems you've noted.

The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy. If you're looking for a policy that doesn't require any approval for uses of the mark I'm afraid you're out of luck as trademark law doesn't really allow that.

The io.js fork was primarily motivated by governance issues. Joyent had full control over governance changes because it owned the assets (domain name, trademark, etc) so you could say the trademark was a part of that but the much bigger issue was that the contributors to node.js weren't in a position to run node.js. That has been resolved. Also note that the other assets (domain name, twitter handle, etc) should be transferred to the foundation outright.

@cusspvz
Copy link
Contributor

cusspvz commented Jun 17, 2015

The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy.

👏

@jasnell
Copy link
Member

jasnell commented Jun 19, 2015

Just to echo Mikeal's remarks: the new trademark policy grants the
foundation full freedom to use and manage the node.js trademark. While the
mark is owned by joyent, it is fully managed by the foundation via a
perpetual, non-revokable license. The language referencing joyent is not
only appropriate, it's respectful of the fact that joyent is the company
that brought node.js forward.
On Jun 17, 2015 12:04 PM, "Mikeal Rogers" notifications@github.com wrote:

Sure, transferring an asset is simple but this is an asset that has been
on the books of a company for 5 years while it has done all the things you
would expect it to do (raise money, acquire lines of credit for hardware,
etc). Joyent is not in a position where it can transfer the ownership of
the mark (I'm sure they'd prefer it as the way the deal has to be
structured they are stuck with the legal bill of enforcement while the
foundation administers the conditions of use). I share the concerns around
prior arrangements of this nature but you'll notice that many of the
companies you note were unhappy with prior arrangements are members of the
Node Foundation and they worked hard to make sure this arrangement did not
have the same problems prior arrangements did. I'm not a lawyer, but I'm
confident that the lawyers from companies suffering from prior arrangements
did a good job of protecting us from those same problems. That doesn't mean
we might not have new problems of our own so me day, but I'm not worried
about having the same problems you've noted.

The new policy seems just as problematic as the previous one, which as I
understand it caused the whole iojs/node split in the first place.

The new policy allows the foundation (an independent body, not a single
company) to approve uses of the mark. That is much different from the
previous policy. If you're looking for a policy that doesn't require any
approval for uses of the mark I'm afraid you're out of luck as trademark
law doesn't really allow that.

The io.js fork was primarily motivated by governance issues. Joyent had
full control over governance changes because it owned the assets (domain
name, trademark, etc) so you could say the trademark was a part of that but
the much bigger issue was that the contributors to node.js weren't in a
position to run node.js. That has been resolved. Also note that the
other assets (domain name, twitter handle, etc) should be transferred to
the foundation outright.


Reply to this email directly or view it on GitHub
#978 (comment).

@mercmobily
Copy link

@jasnell Are you saying that the reasons why the trademark isn't transferred is for the language referencing the trademark, where Joyent is perpetually included? I am asking because all Mickeal mentioned was the difficulty in handing it over, rather than the wording of the reference to the trademark that will "respectfully" include Joyent.

I think it's great that Joyent started node, and that their name will be in history no matter what.

@jasnell
Copy link
Member

jasnell commented Jun 19, 2015

No, I'm not saying that was the reason ownership wasn't transferred, just
that the exact ownership isn't important. The foundation is managing the
trademark now.
On Jun 19, 2015 8:07 AM, "Tony Mobily" notifications@github.com wrote:

@jasnell https://github.com/jasnell Are you saying that the reasons why
the trademark isn't transferred is for the language referencing the
trademark, where Joyent is perpetually included? I am asking because all
Mickeal mentioned was the difficulty in handing it over, rather than the
wording of the reference to the trademark that will "respectfully" include
Joyent.

I think it's great that Joyent started node, and that their name will be
in history no matter what.


Reply to this email directly or view it on GitHub
#978 (comment).

@mikeal
Copy link
Contributor Author

mikeal commented Jun 19, 2015

The reason you have to, in very few but noticeable circumstances, put a trademark notice referencing the owner is due to trademark law itself. In some scenarios if you were allowed to do that without a notice the mark would in danger of being considered "generic" and would be lost to all of us. The reason the notice says "is a trademark of Joyent" is because it is still owned by Joyent even though it is administered by the foundation.

@bnoordhuis
Copy link
Member

I think it's great that Joyent started node

Not so much 'started' as 'acquired'. They have a great PR department though.

@ravi
Copy link

ravi commented Oct 22, 2015

@jasonwilliams200OK I just noticed your comment addressed to me (for some reason GitHub did not notify me, or I missed the notification). You wrote:

@ravi, it is considered rude to delete your comments from the thread, especially when you are tagged and answered adequately. I am reading this thread now and noticed that rather than being appreciative to people who are trying to address your concerns, you instead deleted the comments.

The above is not quite correct. One of the comments in which I provided a significant bit of my thoughts was indeed deleted, albeit not by me. I do not recall by whom, but it was likely someone moderating this issue/discussion and I am perfectly fine with that. However, I cannot have a discussion reflect a partial view of what I had written. Consequently I removed the rest of my comments.

This has nothing to do with appreciativeness. I appreciate the effort every node contributor puts into all aspects of building node.

@nodejs nodejs locked and limited conversation to collaborators Oct 23, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
discuss Issues opened for discussions and feedbacks. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests