solid
solid copied to clipboard
solid
Solid Licencing Information is not available
There is no software licence for solid included with the software. On the projects home page it states that solid is "Open Source".
A Free licence document, such as the AGPL, should be included for those who clone/download the software. It should be readily apparent to visitors of the page, with an obvious file name, like licence.txt.
Hi @yeehi
There is no software licence for solid included with the software.
Yes there is, in individual software repositories such as https://github.com/solid/node-solid-server/blob/master/LICENSE
This repository is not a software repository, that's why it does not have a license.
Thanks for your work on devloping Solid, @RubenVerborgh !
Could a text file with the MIT licence be included in this github? Others might spend time looking for licencing statement, too. A Free licence is clearly a great asset and I am sure a matter of pride.
Also, we should probably have a license on the documentation too, or is all that intended to be "All rights reserved"?
Also, we should probably have a license on the documentation too, or is all that intended to be "All rights reserved"?
@kjetilk or some kind of creative commons license?
+1 to CC BY
Edited: if CC BY (or something more restrictive), it needs to be associated with legal entities eg. MIT, list of contributors. CC 0 would be a good alternative to getting around this.
@kjetilk If "All rights reserved", reserved to who? Which legal entity? Many people have contributed to the documentation over the years in different ways eg. through github, gitter, as well as offline. I suggest that the rights/license on the documentation acknowledges and reflects that to some extent. CC0 may be a safe way of muddling through that mess.
@kjetilk If "All rights reserved", reserved to who?
It seems that @kjetilk's point was more that, given the lack of a license now, this is what should be assumed.
In any case, I think it is up to @timbl as a project owner to decide on this, or at least weigh in.
Indeed, the default legal fallback is quite unclear, so it seems like we need to have this explicit.
Indeed, the default legal fallback is quite unclear
The rights then are very limited.
Indeed, the default legal fallback is quite unclear
The rights then are very limited.
Yup, but also unclear in the sense that it has many contributors who might have been unaware of the conditions.
More on this conversation can be found here https://forum.solidproject.org/t/solid-licencing-information/535
I'm not sure this is a topic that is appropriate for foras. This is something that the copyright owners (i.e. for the most part, this is an issue for Inrupt, not the community) have to decide, but soon, so that the community knows what they are contributing towards.
I couldn't disagree more.
The "community" - we can debate about its composition - is what got Solid to this point. Not Inrupt Inc. or any single entity. I don't speak for the community, but I sincerely don't think that all the contributors from the past years were pushing Solid forward with the belief that it will one day be confronted with a claim like "an issue for Inrupt, not the community". There is of course always the "they should've known better", but that's where you take the opportunity to be a good steward, along the lines of "Here is how we can acknowledge the hard work of everyone from the past, and how we can move forward..."
I would argue that, closing the issue and moving the "discussion" to Inrupt's jurisdiction [1][2], and then making such claims is a sure way to tell the community off. That's not a good signal. You can do better.
What do you think will be the incentive for the community to make "free" contributions going forward or potentially find themselves conflicting with IP down the line? AFAICT, that does not even align with Inrupt's values, but I'm not the judge of that. IMO, you should reconsider your position and think about how your sense of keeping control will actually play out in the wild.
If I've misinterpreted you - and I'm notorious for misunderstanding - please do let me know.
[1] With the expectation that in order to take part in the conversation, one has to agree with Inrupt's terms (read: sign away rights). [2] What's at https://forum.solidproject.org/t/solid-licencing-information/535 is not a "conversation". It hasn't evolved in any shape or form. It is a copy/paste of what's here, without citing the original source. Yikes!
Yeah, you misinterpreted me. Or I misunderstood what the issue was about, or something. :-) At least, we're not talking about the same thing.
So, this issue started to diverge from the original reporter's issue pretty fast, that was mostly about what was around the software, but that was always covered by the MIT license. Moreover, documentation in the repositories are arguable covered by the license that applies to the software in that repository. So, I don't think it is about that either, but IANAL and all that. If that is unclear, YA reason to resolve this. It has never been about the discourse forums or gitter chats. And then, as you say:
but I sincerely don't think that all the contributors from the past years were pushing Solid forward with the belief that it will one day be confronted with a claim like "an issue for Inrupt, not the community".
Those contributions are not something that anybody can slap a license on without the agreement of every substantial contributor, and I thought you knew me well enough, @csarven that you'd know I'd never propose such a thing. So, it not about those things either.
What remains is mostly the stuff that Inrupt employees are writing right now, the community needs to know how they can be used. If it was up to me, I'd have a liberal CC license on that, but it is not up to me and that's why I say that it has to be done by Inrupt. And if somebody else makes a contribution that is not a derivative work, it is up to them to decide what license they want to use. Consulting the community is fine, of course. But I think it is really urgent that this is resolved, so that people know what license things are under if they contribute to derivative works.
But I think I should probably not mess this up even further by engaging into legal stuff, sorry to have been the source of misunderstanding here.
Based on the feedback from Arnold Schrijver in the forum I was inspired to compile a list of the repositories and their attributed licenses (if any), and add some suggestions:
Note that these are only suggestions, but my reasoning have been to split repos into two categories: code repo and text repo. The former can by default have MIT licenses, while the latter can have CC0-1.0. (This difference is not always clear cut, but I think my proposals aren't way off in any case.)
If this approach sounds reasonable, I will commit the proposals as PRs for the various projects, to raise this question for the owners of the various repos, and let them have the final say on this matter.
I am a little wary about dividing repository code and not code, when specs and code are not very clearly distinguished. Would making even the specs by MIT licensed be safer for people who pull stuff from all of the project? You can argue that specs are code.
I am a little wary about dividing repository code and not code, when specs and code are not very clearly distinguished. Would making even the specs by MIT licensed be safer for people who pull stuff from all of the project? You can argue that specs are code.
I'm ok with putting MIT license as the default as well, I'm not married to any particular proposal. The reason I proposed CC0-1.0 for "text-repos" was that the text of the license made more sense to be applied for "pure textual work". But of course, if we argue that specs are code, this doesn't make as much sense.
Do you perhaps know the reasoning behind choosing MIT for webid-oidc-spec and CC0-1.0 for solid-spec?
What is important for me is that we're consistent in our licensing, and the reasoning behind it. So I'm ok with saying "MIT licenses by default for all solid projects, unless stated otherwise and reasoning documented in README.md". (Or maybe the license-file itself?)
Hi All. @csarven raised this yesterday in chat. I'm not in any way an expert on this, but that we have a long term contributor (@csarven) uncomfortable with our licensing, is something we should pay attention to.
@csarven what would you suggest at this point?
As community leader I have always required that all code MUST be MIT license. I would like to request that all specs and doc be moved to it too. If we put for example shapes in the specs then they are also code.
@melvincarvalho, you've left out an important context from the chat. I was responding to why I don't feel comfortable with a particular discussion forum: https://forum.solidproject.org/tos#3 and that it had to do with the CC BY-NC-SA license ( https://gitter.im/solid/chat?at=5c6d3a12c4da4a11f586dc09 ) . Nothing related to solid code or any repository. So, I think that's outside the scope of this particular issue.
@timbl, no issues with the current MIT license from my end.
@csarven thanks for raising the context!
Can we establish what would be preferred outcome?
How about we remove NC and align with the ubuntu forum.
Appreciate that we are drifting away from the original topic but I'd be keen to know more :)