Discussion: relicensing LightGraphs v2.

[sbromberger]

Hi all,

I wanted to start a discussion around LightGraphs v2 and some work i've done in private on getting the codebase up to an acceptable release candidate. I also want to express my thoughts around how I would like to release these changes, and get opinions on the best way to do it. I figure a public github issue provides the most transparency.

It is no secret that I disapprove of much of what Julia Computing and (specific members of) the leadership of the Julia Community have done, specifically around telemetry and re-hosting code on their own servers so they can collect download statistics. From a privacy perspective, this is intolerable to me; from a security perspective, I don't appreciate the increased risk of having the code hosted outside JuliaGraphs (and, by implication, my) control; and from a developer perspective I find the whole situation off-putting and not conducive to collaboration, as the changes were made without any input from developers and offered no opportunity for us to opt out. Simply put, I no longer trust Julia Computing* to do the right thing when it comes to the privacy and security of its users and its developers.

The above is my opinion; it is not open to debate (you won't get me to change my mind). I've included it as a way to frame the current discussion. You may (likely do) have a different opinion, and that's ok.

I have decided, after my experiences with the Julia community this year, that if I am to continue to work on Julia projects, especially LightGraphs, I will want reassurance that the one source of code is maintained by people I trust. That is, the folks who have commit bits here. It specifically DOES NOT include members of any of the aforementioned groups except to the extent that there may be some overlap. This is the only way I can feel comfortable in the integrity of the code and its distribution process.

I have been working on finalizing LightGraphs 2.0 outside of this repo for the past several months and have been using it off and on to good effect. I would like to contribute this code back to our users, because I think it represents a really great way to handle graph analytics. But the current MIT license does not meet my objective to preclude anyone else (specifically, the groups mentioned above) from publicly hosting the code.

I am therefore considering relicensing LightGraphs 2.0 under a less permissive license: for individuals and organizations wishing to USE the code, nothing would/should change. However, it would prohibit public (re)distribution or (re)publication of the code. (That is, if you want a copy, you're free to grab one from the set of official repositories, but you may not further publicly distribute it. If you need to distribute it within your own organization, I would like that to be permitted.)

So far I have not found a good license that combines the individual permissiveness of the MIT license with these restrictions. I am working with some software contract folks and some lawyers to see what might be feasible, but I wanted to throw this out to the folks who have contributed here for their opinions.

From a logistics perspective, assuming we find a good license, this is my proposed process:

1. Tag a final MIT-based version of the codebase
2. change the license, and make a PR template that informs contributors of the license terms
3. change the README to emphasize the new license
4. upload my proposed changes
5. merge the changes (after review, of course) under the new license
6. tag / release LG 2.0 - but do not register it in the Julia Registry.
7. update the documentation to include the correct way to add the package and to keep it up to date

Anyway - Happy Holidays, and I would appreciate your comments/feedback.

cc @jpfairbanks @matbesancon @simonschoelly @abhinavmehndiratta @somil55 @SohamTamba @kshyatt @juliohm

* edited to clarify: Yes, I know it's not technically "Julia Computing" - but the list of people who would have access to the telemetry statistics included most senior members of Julia Computing at one point, and also included others who, in my opinion, had no need to access that data. Most tellingly, it did NOT include any of the core LightGraphs team. I'm still conflating "Julia Computing" with "leaders of the Julia Community" in part because, in my opinion, they have not done an adequate job of communicating the distinction and I am confused as to how they achieve separation of responsibilities.

[jpfairbanks]

Hi Seth, while I understand your grievances with the community, I don't support a decision to relicense LG for this purpose. I think it will make LG2.0 harder to adopt and risks significant fracturing of the JuliaGraphs community.

My primary concern going forward is that we have a reliable maintainer for LG1.X since that will be the default graphs package in Julia since LG2.0 will be unregistered and thus cannot be used by any registered package. I can't volunteer to take on the time commitment but we need to have a long term plan for LG.

[birm]

If I'm understanding correctly, a license with a distribution restriction like this would not be a free/open license. Would this prevent someone from, for example, forking LG and making "light-er graphs" and distributing that?

I can agree with not continuing to publish on a non-open platform, but I'm not sure if a license is the right tool for this problem.

[sbromberger]

@jpfairbanks thanks for your feedback. From my personal perspective, it doesn't really have a great impact on me - I've been using my code for a while and I will continue to do so. I'd like to make it available to others, and to (continue to) support it.

As far as LG 1.x, I think it's pretty much stable (the occasional bugfix notwithstanding, and given the inconsistencies in the API). I can continue with maintaining it since it really doesn't take that much effort. If 1.x is to be the go-forward "official" version then I think we need to move the stable branch to master and bring it back to a normal git structure. This would, in effect, revert the existing 2.0 work.

@birm There is an ambiguity in the term "free/open" depending on whether you ask the OSI, or the FSF, or other group. Dual-licensing is another option, perhaps.

Would this prevent someone from, for example, forking LG and making "light-er graphs" and distributing that?

I guess my thought is that they could fork it, but the license would still hold - the pieces that were incorporated under the proposed new LG license would not be able to be rehosted anywhere.

[sbromberger]

Another option - which might be more disruptive to the JuliaGraphs community, but which at least has some precedence*, is to create a LightGraphsNext.jl (bikeshedding of the name expected) repo that is, essentially, LG 2.0, under this new less-permissive license.

* MetaGraphs vs MetaGraphsNext

[abhinavmehndiratta]

Hi Seth, while this is a good step to ensure privacy, it would make it harder for developers to extend the library and use it even within their organization. Is there any other way we could prevent organizations from misusing LightGraphs ?

[sbromberger]

@abhinavmehndiratta I'm open to other options. I think you're right that this would make it a bit harder for developers to extend the library, but it shouldn't be too onerous a task. There's nothing that REQUIRES the use of the Julia General Registry.

[matbesancon]

Hi everyone,

I agree with @jpfairbanks on the risk of splitting the LG community and breaking code for the many people that depend on LG.

Another option - which might be more disruptive to the JuliaGraphs community, but which at least has some precedence*, is to create a LightGraphsNext.jl (bikeshedding of the name expected) repo that is, essentially, LG 2.0, under this new less-permissive license.

I think this might be more sound from the perspective of users while respecting your choice, having the current (registered or not) packages remain standard registered Julia packages under their open-source license, and create separate repositories with specific licensing conditions that restrict distribution.

LightGraphs 1.x is fairly stable, although it can always use improvements and bug fixes, but I believe it is acceptable as-is without a major overhaul.

[matbesancon]

If 1.x is to be the go-forward "official" version then I think we need to move the stable branch to master and bring it back to a normal git structure. This would, in effect, revert the existing 2.0 work.

That can be a solution, possibly with a backport of the PRs that were made and could still be integrated within 1.x (all those PR not touching the structure nor relying on it)

One thing to watch out for is to bring back the stable branch as master without erasing the current master history, so no rebase I believe, otherwise, the current work on master, which was added under an MIT license, could be lost

[juliohm]

Thank you @sbromberger for your transparency and for sharing your concerns with us publicly. We have had the chance to chat in private about these "senior" Julia members and I can reassure you that many of my colleagues are feeling the same about their attitude and lack of inclusion in these major decisions around the language. Before I continue typing, I would like to say that you are a really amazing member of the community and I hope we will stick together regardless of this "seniority" we've been experiencing. ❤️

I agree with other LG members that the risk is high of splitting with a different license. If there is another mechanism to address your concerns, I'd support that instead. Can you maybe share with us what exactly you would like to inhibit? I think inhibiting redistribution goes against the open-source movement (no matter the definition FSF, OSI, ...), so maybe we could find ways to allow redistribution and still address your concerns. Are you concerned that Julia Computing will have statistics about LG that we won't have access to? What exactly we are trying to improve upon?

Looking forward to finding a solution that preserves this awesome LG community we've built over the years.

[sbromberger]

@juliohm - thank you for your kind words. They do mean a lot.

Can you maybe share with us what exactly you would like to inhibit?

My un-nuanced answer follows:

I would like to maintain a package that is entirely free of Julia Computing / Julia community* interference, decisions, policies, telemetry, and politics. That is, it should be able to be used without relying on any Julia Computing / Julia community resources (other than the obvious language/code dependencies). I want to maintain publishing control over the package within a group I trust (this group of core committers), and prohibit others from republishing or redistributing the code to a general audience**.

The way it works now, as I understand it, Julia Computing / Julia community scrapes the repos and uses their own versions on servers under their control when people use ]add - this allows them to capture telemetry and also would allow them to do a few things that concern me:

1. continue to host the code when the original author decides not to participate in its development anymore (My proposal mitigates in the JuliaGraphs community by the fact that we have several active core committers, so a left-pad incident is unlikely);

2. decide not to publish a specific version of code (My proposal mitigates this because they will no longer have any editorial decisions regarding the code);

3. modify the code distributed to the users without the authors' permission (though there is no evidence that this has happened, it is a possibility. This is fully mitigated by my proposal. Again, I believe the most secure and privacy-preserving way to use LightGraphs is to download it directly from the Github repo); and

4. use and distribute the code while changing the terms under which the code was originally submitted to the registry (this has already happened - when we originally registered LightGraphs, the code was not copied, and there was no telemetry. This was added after it was too late to do anything about it, and since the code is MIT-licensed, they were perfectly within their rights to bundle the code themselves to serve to everyone who used Pkg.)

This last concern is one of the main reasons we're having this discussion in the first place. Another example of where the policies changed is when you compare the hoops we had to jump through to get LightGraphs accepted in the first place (multiple name changes, lots of picayune bikeshedding, etc.) versus what's being accepted into the registry today (I'll use the IsTwo / IsURL episode as my exemplar, but there are others).

Sorry for the lengthy response, but I wanted to ensure you had a good answer to your excellent question.

* Again, I don't want to disparage either group unfairly, but I honestly don't understand the practical distinction and who's doing what. If a member of either group reads this and decides it doesn't apply to him/her, then please don't assume it does.

** My current thoughts: Including a link to the official download source is perfectly ok, as is downloading the code and making it available on a private network, or somewhere that is not accessible to the general public. Creating a public fork in order to make a PR that is submitted to the repo is an area that deserves further discussion. My feeling is that this would be ok, but I would not want that fork to be used as the 'source of truth' for the code.

[sbromberger]

@matbesancon

I think this might be more sound from the perspective of users while respecting your choice, having the current (registered or not) packages remain standard registered Julia packages under their open-source license, and create separate repositories with specific licensing conditions that restrict distribution.

This is my thought as well. It's effectively what I've been doing for the past several months in any case - maintaining my own private repo that is an almost-complete v2 (going back to it, there are some significant gaps that need to be finished before it gets released, but it's certainly closer than the current master branch). The idea would be then to rename the repo and make it public, and provide instructions on how to install it (and any companion packages, which would need to be changed and republished to use the new library).

possibly with a backport of the PRs that were made

As far as I'm aware, there are no bugfixes in 2.0 that apply to 1.x and have not been merged there, so this might not be a huge issue. If there are, then it shouldn't be too big a deal to port them as normal PRs.

[sbromberger]

@jpfairbanks - I wanted to explore this comment of yours further:

since LG2.0 will be unregistered and thus cannot be used by any registered package

Why is this the case? My understanding is that it is possible to include unregistered packages as dependencies via URL. Do I have it wrong?

[sbromberger]

Another option would be to create a JuliaGraphs registry that would make all the graph-related code available. It would require users to add a separate registry, but my understanding is that it's a single Pkg command, after which the users would have access to all packages in that registry. Thoughts?

[juliohm]

Thank you @sbromberger , I'd like to comment on each of the 4 concerns you've raised:

The way it works now, as I understand it, Julia Computing / Julia community scrapes the repos and uses their own versions on servers under their control when people use ]add - this allows them to capture telemetry and also would allow them to do a few things that concern me:

• continue to host the code when the original author decides not to participate in its development anymore (My proposal mitigates in the JuliaGraphs community by the fact that we have several active core committers, so a left-pad incident is unlikely);

I'd argue that this is a good feature, i.e. the ability to preserve existing releases of the project moving forward regardless of who is heading the development in the present and whether or not the project is being actively maintained. I understand that the Julia community just wants to provide existing releases from a backup in case the original repository is lost or deleted. If the original author of the project decides to stop participating in the development, other contributors may find it important to keep working on it for various reasons. If the original author wants to inhibit other contributors from adding more features or improving the codebase, he/she could suggest a fork but that effectively kills the original project.

• decide not to publish a specific version of code (My proposal mitigates this because they will no longer have any editorial decisions regarding the code);

You mean reviews in the General registry that could potentially inhibit a new release? I've never seen this happen, especially now that the bot in the General registry merges new releases automatically without human intervention. It is unlikely that a human will argue against a new release of a project he/she doesn't own, but I get your point that there exists the possibility. I try to trust the good intentions of the community as a whole and so I don't base my estimates of behavior on specific "senior" members.

• modify the code distributed to the users without the authors' permission (though there is no evidence that this has happened, it is a possibility. This is fully mitigated by my proposal. Again, I believe the most secure and privacy-preserving way to use LightGraphs is to download it directly from the Github repo); and

Again I trust the community as a whole, and I don't think someone would modify a project under the hood without permission, that would be super unethical and would put off a lot of people out there. Perhaps we should be concerned about these things when they actually start happening. As of this moment we are discussing hypothetical situations that are very unlikely. If there is precedence, then we can reevaluate the issue with different eyes.

• use and distribute the code while changing the terms under which the code was originally submitted to the registry (this has already happened - when we originally registered LightGraphs, the code was not copied, and there was no telemetry. This was added after it was too late to do anything about it, and since the code is MIT-licensed, they were perfectly within their rights to bundle the code themselves to serve to everyone who used Pkg.)

You mean that instead of cloning directly from GitHub, the package manager is installing LG from a cloned repo in the Julia servers, right? This shouldn't be an issue as I don't think they are modifying the code in the servers, just hosting a copy in order to have a more robust ecosystem. Regarding telemetry, I understood that it was not implemented according to that major thread of discussion on Discourse. Isn't that the case? Finally, I think that the MIT license is a good default license for open source. Everyone is adopting it to avoid license proliferation as it allows all kinds of uses in enterprise and education. Changing the license to something else seems like a step backwards to be honest.

As a final remark, I would like to say that we should separate really well the fact that we are annoyed by specific "senior" members in the community from the possibility of other inefficiencies in the Julia ecosystem as a whole. There are other methods to address the former issue, and they would not impact LG so drastically like a change of license would.

[jpfairbanks]

I agree with everything that Julio has said here. The OSI publishes the 10 principles of open source licensing and I think that any license that achieves the goals of prohibiting redistribution by JuliaComputing runs aground on some of these principles. Specifically principle 1, 3, 4, 5, 6, 9, 10 are all impacted when you restrict who can redistribute your code.

[juliohm]

@sbromberger regarding the idea of a custom registry that you shared above:

Another option would be to create a JuliaGraphs registry that would make all the graph-related code available. It would require users to add a separate registry, but my understanding is that it's a single Pkg command, after which the users would have access to all packages in that registry. Thoughts?

I don't understand the exact details of how it works, but as far as I understand it wouldn't inhibit the package manager from doing things with the repositories during installation in the future. I just want to point out that we don't want to follow this path where we start avoiding everything the community is building based on the assumption that there is bad intention or personal motivations.

As far as I can tell, the real issue we are discussing here transcends LG. It is an issue regarding unknown motivations behind decisions of core members of the community that also work for Julia Computing. This issue needs to be addressed somewhere else in my opinion and with different mechanisms. It doesn't seem to be a problem with the LG project, its license or anything that is hosted in this organization. Do you agree?

If we can work these details somewhere else with a broader community, that would be great. I don't know how exactly yet, but we could start a channel on Zulip or some other platform that everyone uses to brainstorm ideas.

[sbromberger]

@juliohm with respect, it appears you are trying to reframe the problem by disagreeing with my premises. I want to reiterate that my distrust of Julia Computing / the Julia community is not up for discussion - you will not change my mind, though I understand that my views are not universally shared.

Given the problem statement above:

I would like to maintain a package that is entirely free of Julia Computing / Julia community* interference, decisions, policies, telemetry, and politics. That is, it should be able to be used without relying on any Julia Computing / Julia community resources (other than the obvious language/code dependencies). I want to maintain publishing control over the package within a group I trust (this group of core committers), and prohibit others from republishing or redistributing the code to a general audience**.

I don't see how your suggestions further that objective. I do appreciate your responses, though, and perhaps I've misunderstood something.

[juliohm]

@sbromberger sorry if I expressed myself poorly. I do not disagree with your premises, or at least I think we have the same premises that some members of Julia Computing may have motivations that are not the same motivations of the community as a whole. So to be clear, I am not trying to change your mind about Julia Computing, or some of its members. Do you trust the Julia community as a whole? That is what is not clear to me yet.

What I am trying to say is that maintaining a package that is entirely free of Julia Computing / Julia Community (as a whole) is an impossible goal. You have to rely on something at some point like the package manager, the language itself, otherwise you will be rebuilding a separate language and community. What is not clear to me is where you want to draw the line in the community. Is it LG contributors versus the rest of the community? Is it everyone versus Julia Computing? It is not clear to me who is the agent that is taking your freedom. Without properly characterizing this agent, it will be hard to come up with a reasonable plan of action.

[jpfairbanks]

From my understanding of his perspective, Seth wants to be completely uninvolved in the community and is willing to accept the ramifications. My concern is that it is not possible to have a sustainable julia package without participating in the broader OSS community around the Julia language. I think those ramifications will be too steep for a project to bear, which is why I focused in my original post on the idea of stable maintainership for the current stable branch on this repo.

[juliohm]

I share this concern as well @jpfair , it is hard to sustain a project without participating in the broader OSS community around the language. I hope we can find a solution that preserves LG's impact and reach. It was quite fun to help build this project in the early days, and to make colleagues here.

Sorry again if I misunderstood your concerns @sbromberger. I am genuinely trying to figure out something together.

Best,

[sbromberger]

So if we as a group are unwilling or unable to figure out a way to move forward with my contributions, I guess I'll withhold them from the main repo. I'm sad to have to do that, but I am not willing to contribute my time and energy to support policies and people with which I vehemently disagree.

That said, I will continue to help maintain the LG 1.x branch by reviewing and merging code, responding to issues, and managing the JuliaGraphs organization. It is only my own code that will not be contributed until such time as my concerns are resolved.

If we decide that this is the correct path forward, I would suggest that we move the stable branch to the master branch so we don't have two completely disparate code bases out there. (To @matbesancon 's point above, we should do it in a way that preserves the history so we don't actually lose the 2.x development work that was contributed.)

[sbromberger]

And @jpfairbanks has it pretty much right. My surprise is the truth of this statement:

it is not possible to have a sustainable julia package without participating in the broader OSS community around the Julia language

That appears to be the case, and it is really unfortunate. Other languages (Rust, C++, Swift, Go, and even Python) do not require developers to buy in to the politics and processes in order to contribute useful code to users. This should be a red flag to any potential Julia contributors.

[jpfairbanks]

That said, I will continue to help maintain the LG 1.x branch by reviewing and merging code, responding to issues, and managing the JuliaGraphs organization. It is only my own code that will not be contributed until such time as my concerns are resolved.

I'm worried that this is not a sustainable position and would rather focus on getting your concerns resolved.

That appears to be the case, and it is really unfortunate. Other languages (Rust, C++, Swift, Go, and even Python) do not require developers to buy in to the politics and processes in order to contribute useful code to users. This should be a red flag to any potential Julia contributors.

Given the increasing focus on the community aspects of open source communities, I imagine that within a few years all OSS ecosystems will have similar levels of community focus as Julia. Part of the differences in the Rust/Go/Swift/C++ communities is attributable to their deployment in enterprise software systems where there are more people writing proprietary code for their employers. I would bet that Julia has one of the highest fraction of OSS involvement of any PL since there are so few companies using Julia in proprietary systems.

In general I think the idea that online communities are communities that need to be governed by systems of norms and rules is increasing as part of the recognition that technology is a human endeavor more than a sterile, technical pursuit. Swimming against that tide seems futile.

[sbromberger]

Swimming against that tide seems futile.

That's a bit defeatist to me. In that case I will probably find a different ocean to spend my free time in :)

[DilumAluthge]

There is no telemetry in Julia or Pkg.jl. Zip, nada, zero.

There was a long and public discussion about this, and in the end, the community made its opinion clear. So we do not have any telemetry.

[DilumAluthge]

I'm still conflating "Julia Computing" with "leaders of the Julia Community" in part because, in my opinion, they have not done an adequate job of communicating the distinction and I am confused as to how they achieve separation of responsibilities.

This has been clarified many times, in blog posts (https://julialang.org/blog/2019/02/julia-entities/), on Discourse, and on Slack.

[DilumAluthge]

Here is a roadmap that I think meets all of your requirements.

1. Create a new GitHub organization. I would recommend that the name of this organization not include the word "Julia". Perhaps you could name the GitHub organization something like LightGraphTheory.
2. In the LightGraphTheory GitHub organization, create new repositories. For example, you might create a new repository named LightGraphs2.jl.
3. License the LightGraphs2.jl package under whatever non-free license that you want. You could even just license it under "All Rights Reserved." I am not a lawyer, and this is not legal advice.
4. In the READMEs for LightGraphs2.jl and the other packages in the LightGraphTheory organization, just make sure that you briefly mention that the license is not an OSI-approved license, just so that there is no misunderstanding with your users.
5. In the LightGraphTheory GitHub organization, create a private registry. Perhaps you could name it something like LightGraphRegistry. Managing private registries is pretty straightfoward. And, if you want, there are optional tools (such as the great LocalRegistry.jl) that make it even easier.
6. In the README for LightGraphRegistry, make sure you briefly mention that some (or all) of the packages registered in LightGraphRegistry do not have OSI-approved licenses.
7. Register LightGraphs2.jl (and the other packages in the LightGraphTheory organization) in the LightGraphRegistry. Like I said, LocalRegistry.jl makes this really easy, but you don't have to use LocalRegistry.jl if you don't want to.

The packages in your LightGraphTheory organization will not be served by the Julia project's Pkg servers, for two reasons:

1. The Julia project's Pkg servers only serve the General registry. So they won't even know that your LightGraphRegistry registry exists.
2. The packages in your LightGraphTheory organization will have licenses that prohibit the Julia project from redistributing them.

That's pretty much it.

I think this meets all of the requirements, right? The packages you develop will have no relationship with the Julia community.

Does this roadmap work for you?

[DilumAluthge]

This has been clarified many times, in blog posts (https://julialang.org/blog/2019/02/julia-entities/), on Discourse, and on Slack.

And yet, when I asked the question as to who would have access to the telemetry data, nobody could give me a comprehensive list.

Before the telemetry was removed, I was working on adding a page to the Julia website that would list out those people (which would be a subset of the "set of people who have commit access to the JuliaLang GitHub organization" as described in the post).

But then telemetry was removed, so I dropped that project.

[jpfairbanks]

Therefore, there exists a group who can UNILATERALLY change the terms under which code developed for Julia is presented to (the majority of) Julia users.

Apparently no one could unilaterally change the terms, because there was an objection and it didn't happen. If an equally objectionable change was proposed today, a similar protest would defeat the change again.

Edited to add: it's not just telemetry; it's also the fact that the code is provided by a service that scrapes the authors' github repos and provides the code from its own resources. I don't much like that...

I don't get this grievance, all of your public repos are on the public internet, which means anyone can download it or re-serve it. If Github used a third party CDN to distribute that content, I wouldn't say that I have been harmed. Any web service that hosts content has the unilateral right to change the TOS. If they aren't serving different code (as ensured by checksumming), then what is the harm? I don't have control how over the ISPs route the bits, but that is just how the internet works.

[DilumAluthge]

Anyway, although I personally disagree with the goal, I do believe that the following statement is true: it is definitely possible to develop and release Julia packages without any relationship or participation in the Julia open-source community or the Julia project.

I think the roadmap I posted above achieves this goal. Please let me know if this is not the case.

[DilumAluthge]

(as ensured by checksumming)

This is exactly correct. Packages and artifcts are cryptographically hashed and verified on the client, so the Pkg servers are not able to modify the content of anything they serve.

[DilumAluthge]

But that's moot to the larger discussion - if you follow the roadmap that I have posted, your code will never be served by the Julia project's Pkg servers.

[jpfairbanks]

While it may be possible to publish Julia software without participating in the OSS community, I don't think it is possible to sustain a noncommercial software package over the long term without participation in an open source community.

[sbromberger]

Apparently no one could unilaterally change the terms, because there was an objection and it didn't happen.

In my mind it was just dumb luck that there was sufficient blowback for the people in charge to decide it wasn't in their interest to pursue telemetry. There's nothing that forced them to change their minds, and there is no way for a package, once submitted, to be removed from the registry - so once your code is in the registry/on the package servers, if the terms change to something you don't like, you're out of luck with respect to the existing code you've contributed.

Packages and artifcts are cryptographically hashed and verified on the client

Except that the hashes and the code are managed / hosted by the same group, so it should be trivial to alter the code and then provide the correct hash for the altered code. What am I missing? How am I, as a user, assured that the code served up by pkg.julialang.org (or wherever it is) is exactly the same as what I get when I go to github.com/JuliaGraphs/LightGraphs.jl (without downloading and doing my own checks)?

if you follow the roadmap that I have posted, your code will never be served by the Julia project's Pkg servers.

I appreciate your willingness to find a way around, but that's a lot of work to undertake for the ability to host code that few people will ever use because it's not advertised in the default installations. It's probably easier just to have people add the code via URL.

[DilumAluthge]

I appreciate your willingness to find a way around, but that's a lot of work to undertake for the ability to host code that few people will ever use because it's not advertised in the default installations. It's probably easier just to have people add the code via URL.

I recommend the "private registry" approach over the "add the code via URL" approach because the former approach allows you the full power of the resolver, with compat entries and everything.

With the "private registry" approach, you just tell users to do this one time:

] registry add https://github.com/LightGraphTheory/LightGraphRegistry

And now they can just add your code with:

] add LightGraphs2

I think the "private registry" approach is relatively simple with LocalRegistry.jl.

But yes, if you really want, you can completely omit the private registry, and just tell people to add the code via URL:

] add https://github.com/LightGraphTheory/LightGraphs2.jl

Regardless of whether of not you use the private registry approach, I very strongly recommend doing this in a new GitHub organization, e.g. something like a LightGraphTheory organization.

[sbromberger]

I very strongly recommend doing this in a new GitHub organization, e.g. something like a LightGraphTheory organization.

Is there a reason for that? I suppose I could just host it in my sbromberger account, but it'd get more traction in JuliaGraphs.

[jpfairbanks]

I agree that your personal account would be better, because of the lack of OSI compliant license. JuliaGraphs as an organization should remain in the Julia open source community.

[DilumAluthge]

I remember for example a recent post by Ronis sharing his frustration to get code merged in the Julia repo that was just fixing a docstring. It took a year to get noticed and reviewed.

That is a good Discourse discussion. As an action item out of that discussion, Chris de Graaf and I are working on some tooling to improve the situation: https://github.com/JuliaLang/pull-request-state-machine. The idea is that with some automation and reminders, we can improve (and speed up) the process of PRs from non-committers. This is of course open-source - would love for others to help work on this tool.

In general, I think we can always improve the process of contributing to the Julia language.

[DilumAluthge]

I agree that your personal account would be better, because of the lack of OSI compliant license. JuliaGraphs as an organization should remain in the Julia open source community.

James beat me to it. This is exactly correct.

I personally find that organization-owned repos are easier to manage than personally-owned repos - for example, an organization-owned repo can have multiple admins, but a personally-owned repo can only have one admin (the person that owns the repo). So that's why I recommend organizations.

But yes the JuliaGraphs organization should remain in the Julia open source community.

So you could either own the repos under sbromberger, or make an LightGraphTheory organization for all your non-open source repos.

[sbromberger]

I don't get this grievance, all of your public repos are on the public internet, which means anyone can download it or re-serve it.

Unless the license prohibited this, which is the very proposal you'll find in the first post.

I think we're going in circles, though, and I don't have much time to go down rabbit holes. As it stands now, my likely course of action is to do nothing. That is, I will continue to maintain LightGraphs (1.3.x) and review and merge PRs, and answer questions. I won't be doing any public development work on LightGraphs 2.0 (or any other Julia project outside of the occasional bug fix / report), but I'm happy to engage here if someone wants to continue the work I started before this whole thing blew up.

My recommendation still stands, however, that we move the stable branch onto master in a way that preserves the existing 2.0 work, but allows contributors to file PRs against master (which is pretty standard).

[jpfairbanks]

Yes I agree that resetting master to stable and keeping the current master on a different branch is the right move.

[DilumAluthge]

out of nowhere people announce Telemetry on Discourse

I just want to correct the facts here. The telemetry code had been in the open-source Pkg.jl repository for a long time before the Discourse discussion. The Pkg.jl repo is open source. Personally, I use the GitHub "watching" feature to "watch" the Pkg.jl repo, and the JuliaLang/julia repo, and other related repos. So, when the telemetry PR was opened in Pkg.jl (a long time before the Discourse discussion), I got a GitHub notification.

Nothing was done in secret.

[sbromberger]

Nothing was done in secret.

Except, perhaps, curating the list of folks who would have access to the telemetry data.

Edited to add: if the idea of transparency and openness is "check the source code for any changes and raise objections if you see them", then this is untenable for most people. I certainly don't have time to trawl through PRs and discussions on packages that I don't maintain. It's unreasonable to expect others to do this.

If your openness requires folks to verify, then you've missed the boat on the trust relationship.

[DilumAluthge]

Nothing was done in secret.

Except, perhaps, curating the list of folks who would have access to the telemetry data.

When in doubt, the "Julia project" refers to these people:

The most clear cut line that can be drawn is that there is a set of people who have commit access to the JuliaLang GitHub organization: there are currently 67 committers (36 active and 31 dormant).

So either:

1. That set of people would have access
2. That set of people would select a subset of those people to have access

[DilumAluthge]

Anyway, I agree that we are going in circles.

[DilumAluthge]

Yes I agree that resetting master to stable and keeping the current master on a different branch is the right move.

Just to clarify: is there currently any code in this repo (LightGraphs.jl) that is NOT licensed under this license? https://github.com/JuliaGraphs/LightGraphs.jl/blob/master/LICENSE.md

In other words, are there any branches in the LightGraphs.jl repo that contain code that is not licensed under https://github.com/JuliaGraphs/LightGraphs.jl/blob/master/LICENSE.md?

[sbromberger]

are there any branches in the LightGraphs.jl repo that contain code that is not licensed under https://github.com/JuliaGraphs/LightGraphs.jl/blob/master/LICENSE.md?

No.

[DilumAluthge]

I realize that I don't think I fully replied to @juliohm

Every now and then we see similar issues popping up on Discourse about old community members feeling excluded from the language decisions.

Yeah, I think this is an important topic, and there is always room for improvement. As I mentioned above, one concrete area for improvement is to improve the process for PRs made from non-committers. Chris and I are working on this from a tooling perspective, and as I said, contributions from others are welcome (https://github.com/JuliaLang/pull-request-state-machine) is open source. And there are probably also other non-tooling steps we can take to improve this area.

In general, I think it is important that any community member that wants to participate in language decision-making be able to participate in language decision-making. I think some concrete steps towards this are:

1. Better tooling to support PRs from non-contributors
2. Encourage more people to "Watch" the JuliaLang/julia repo, the JuliaLang/Pkg.jl repo, and other repos in the JuliaLang org.
3. Encourage everyone to join the #triage and/or #pkg-dev channels in Slack
4. Encourage everyone to join the triage call and/or the Pkg call

Are there other concrete steps that we can take?

[abhinavmehndiratta]

I will continue to maintain LightGraphs (1.3.x) and review and merge PRs, and answer questions. I won't be doing any public development work on LightGraphs 2.0 (or any other Julia project outside of the occasional bug fix / report), but I'm happy to engage here if someone wants to continue the work I started before this whole thing blew up.

Will LightGraphs accept contributions for the 2.0 branch and would it ever go public ? I think that there's a lot of optimizations and improvements in 2.0 and would love to see it get released even if it takes more time.

[juliohm]

Thank you @DilumAluthge for following up. To be honest, I think the main issue we have currently is a lack of leadership from some of the core members of the community. The discussion we are having here is very polite and professional, it is happening without personal attacks even when the subject is quite stressful for some of us. I think technology can help, but ultimately what is really needed is some form of education. Core Julia contributors could benefit from watching lectures or from online material on leadership skills. There are people that I really respect like Tim Holy, Keno Fischer, ... they are true leaders who can participate with productive comments on the various community channels. They are very welcoming and careful with their words whenever they share a point of view with the community. The same can't be said about other members that just jump in a thread to "show off". You know what I mean.

I am here to help improve this situation as I want the success of the community, but it doesn't depend on us. People need to want to change, they need to acknowledge the issue and grow as professionals. That is beyond our control.

[sbromberger]

Will LightGraphs accept contributions for the 2.0 branch and would it ever go public ?

I don't see why not. I'm happy to review them myself and provide feedback.

I think this discussion has run its course and we have a go-forward (or at least a stay-in-place) plan:

1. move master to development
2. move stable to master
3. no change to committers, policies, or license

I'll close this out - @juliohm and @DilumAluthge, I don't mean to stifle your discussion but it's probably better done in private at this point. If you object to this decision please feel free to continue here.

Thanks for all the input.

[sbromberger]

I have renamed the branches. Right now, master reflects v1.3.4, and development reflects the old master branch (that is, 2.0-dev).