Large Proposal: Non-Standard Libraries

[David_Sweeris]

@xwu

@David_Sweeris

Could the licensing terms include letting the Swift project host a copy in a repo it controls? Just as a backup, in case the original author bails.

That doesn't solve the issue of the library not being maintained. And I doubt Apple will agree to host copies of unmaintained libraries.

If the goal is to set up a set of libraries that are going to have assurances of being maintained, that's simply not feasible without funding. I don't see how any discussion here about who hosts the code is going to change that. At best, it provides an illusion of future support to users, which is misleading at best and a liability issue at worst.

Correct. I was only addressing the part about authors taking repos down.

I don’t know that there can be a solution to the maintenance issue, other than maybe a “no non-stdlib dependencies” rule. Maintaining source/binary compatibility is the whole point of the big ABI stability push. Assuming we hold that end up, in theory the worst case is that the lib gets out of sync with best practices (which could be a big deal if it affects security).

Also, this all kinda depends on how far down the rabbit hole we want to go... If the Swift-hosted repo is just a backup, SwiftPM could automatically mark anything retrieved from there as deprecated, since the only reason to pull from there would be that the main repo disappeared.

Not really claiming that’s a good idea, just that it kinda sorta addresses the issue (to a degree, anyway).

[Karl]

Alternatively, if you want your own repo that nobody can take down, create a fork.

That's a repo that you control, and the Swift project doesn't have to worry about hosting code which is malicious or potentially infringes on somebody's copyrights or patents. Sometimes code goes down for important reasons (even if it's a pain in the backside).

[nick.keets]

I don't see how assigning more work to volunteers is going to help with the maintenance problem. And in cases where there are competing libraries (like the 3 FS libraries mentioned above), we are basically making people do spec work with the promise that one of them may be picked, i.e. making them work for exposure.

One way to frame this issue is to look at JSON. In many languages JSON is part of this "Extended Library" we are discussing. Do you think it is beneficial that we got built-in support of JSON in swift, or would you rather it was implemented and maintained by a 3rd-party?

[gwendal.roue (Gwendal Roué)]

I don’t see how assigning more work to volunteers is going to help with the maintenance problem. And in cases where there are competing libraries (like the 3 FS libraries mentioned above), we are basically making people do spec work with the promise that one of them may be picked, i.e. making them work for exposure.

We'll need involved people eventually. But I can see how you are correct, in the light of the funding topic evoked by @xwu.

One way to frame this issue is to look at JSON. In many languages JSON is part of this “Extended Library” we are discussing. Do you think it is beneficial that we got built-in support of JSON in swift, or would you rather it was implemented and maintained by a 3rd-party?

I don't care about who provides JSON decoding. I think that it's unavoidable that the StdLib and the NStdLib eventually compete on some topics. I mean: even the StdLib and Foundation are competing today!

[anon27714269]

It may be a unpopular opinion - But I don't think it's a good idea holding back Swift on macOS and iOS to get feature parity on Linux. As much as I like Linux as a server os - the user interface stuff sucks in every form I ever have seen. So a requirement that libraries have to support both platforms is imo undesirable.

[anon27714269]

Yes and that is a good thing. GPL isn't a good license for code exchange and libraries.

[taylorswift]

@anon27714269

Yes and that is a good thing. GPL isn't a good license for code exchange and libraries.

that’s a big statement when so many of the largest open source projects are GPL

[anon27714269]

In pure open source projects GPL is much less problematic. But libraries should be useable by all coders, not only open source coders.

Besides that I'm pretty sure most important open source projects use bsd/mit/apache licenses. The only exception being the linux kernel and even that is avoiding the current GPL version.

[taylorswift]

@anon27714269

In pure open source projects GPL is much less problematic. But libraries should be useable by all coders, not only open source coders.

Besides that I'm pretty sure most important open source projects use bsd/mit/apache licenses. The only exception being the linux kernel and even that is avoiding the current GPL version.

i don’t think a philosophical argument over which license is best is productive, all i’m saying is if we ever want to ship a non-standard-libraries package or even have a ‘central package repository’, there are important licensing questions that need to be answered.