This is a short one.
@Marc.2377 outlined in a previous issue some ideal candidates for licenses.
I went ahead and chose CC-BY-ND for our feature-development repo because it seemed ‘right’ as our design and use case/feature development is what is going to make our software shine and we want to protect that whilst still remaining true to our OSS nature.
You can see the WIP PR here
In essence we want to protect our community and all the work everyone is putting in.
With that in mind, could people who know far more about this than myself weigh in on this please
@manassehkatz @ArtOfCode @Marc.2377 @cellio
5 Likes
Looks OK to me, though I don’t consider myself anything close to a License Expert.
“No derivatives” doesn’t sound to me compatible with “open source” though I’m no expert.
https://opensource.stackexchange.com/q/357/8652
I’m not sure what you think it means to have open-source software based on a no-derivatives functional spec.
2 Likes
@mattjbrent can confirm/deny and/or explain more. But I think the license here is for stuff related to planning/designing the software and not the actual software code.
2 Likes
Yeah. Thanks @cwellsx and @manassehkatz. I think if reading those posts at face value are correct, then it might not be the best license. Id like to reiterate I’m a complete noob when it comes to licensing legality.
My general feeling or thoughts on my choice was. This is open source software created by a community of people for communities and we want to protect this body of work so that a for profit company or another Ill meaning organisation can’t take core aspects of the product and essentially rip it off.
A complete made up scenario but what happens if we create an especially good feature in our use case and design and a for-profit competitor comes along and entirely rips it off. Or someone else comes along and tries to impersonate the codidact brand and design/software? How do we protect our communities from that legally whilst remaining true to the heart of open source. Something like that early enough could derail the project.
1 Like
The usual way to do that with software might be the Gnu license (GPL) i.e. “you can use this open source software but if you do then your software which you use this with must be or become open source too”, also the newer Affero license.
I’ve never heard of licensing e.g. the functional specs though, can’t guess what it means in practice.
Perhaps I’m wrong, IANAL, my understanding is that your restrictive license is restrictive if or to the extent that you’re willing to go to court to protect it, which you’re not, because doing that is expensive – like having a patent portfolio, it’s a game for bigger fish.
So “protecting our community” means only that you try to ensure that Ty Coon doesn’t sue our community for violating one of their licenses.
A GPL license can be used to try to “poison the well” (and to benefit from changes other people make) – in theory – a commercial company won’t want to touch stuff licensed with GPL because their touching would will open-source their software, which they might want to keep closed.
That’s a different matter, i.e. trademark, and whether the public can tell whether the two things are different (e.g. different name and logo and “trade dress”).
It seems to me that licensing the design documents doesn’t achieve much except make it slightly harder for other open-source projects to reuse what we work out.
It certainly doesn’t make it at all challenging for a closed-source competitor to mimic our work, since they could probably avoid violations, and certainly avoid any visible violations, without even needing to avoid using our design documents.
CC-BY-SA is fine, if we even need anything.
2 Likes
CC-BY-ND is, indeed, not an open license, and that’s the point. It’s one of the two most restrictive options listed in the linked issue, the other being “a custom license, granting rights to copy and modify for the sole purpose of contributing to our projects”.
Under discussion here is a content license for project assets (graphic design/artwork, use cases), not for software - as that’s already covered in another thread: What software license should we use?.
With that out of the way, my recommendation would be CC-BY-SA for functional design documents and specs, and CC-BY-ND for graphic design/artwork. The rationale being, we can expect derivatives for specs documents (text, diagrams) but not for actual creative “brand assets” work - I suppose.
1 Like
How about the point that a company might take our stuff and build on top of it, and build very useful stuff, which would then be kept from the public?
As far as I understand our choice of license also made sure that such improvements have to be presented to us and we can decide if we include them?
That sounds like this topic …
https://opensource.stackexchange.com/q/5785/8652
… i.e. if it’s open source then people can use and modify it privately without telling you.
I think that the open source license means they have to give the source to their users – not to you.
If they use it publicly, though, then one of those users might be you.
1 Like
There should be no non-FLOSS content until a non-profit organisation is started that can own it.
The idea of “protecting” feature specs with a ND license sounds pretty pointless to me. All it would do is stop someone from modifying the feature spec. They could still copy it freely, they could still implement it all they liked.
2 Likes