I'm looking for user feedback on a set of proposed changes to the terms
of service. You can read the full diff here:
https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9
The changes to the privacy policy are just a bunch of minor
clarifications that I've had queued up for the next time we needed to
make a major change. The meat of it is in the terms of service, and the
most important change is to the licenses permitted for use on public
projects using the service.
The short of it is that all public projects would be required to use
licenses approved by the Free Software Foundation, Open Source
Initiative, or Creative Commons, within 90 days of appearing on sr.ht.
These changes, if we moved forward with them, would be announced 90 days
in advance to give you ample time to deal with the changes as necessary
for your projects.
To answer some expected questions right off the bat:
# Does this mean I have to use the GPL? I hate viral licenses.
No, licenses like MIT, BSD, Apache 2.0, and so on, are approved by both
the Free Software Foundation and the Open Source Initiative. The full
lists of approved licenses are here:
https://www.gnu.org/licenses/license-list.en.htmlhttps://opensource.org/licenses/category
You can use Creative Commons, too, but the idea behind allowing CC
licenses is to provide a better option for things which are not code.
There is a loophole here, which is that you could license software
projects with a non-commercial Creative Commons license, which would
make your project neither open source nor free software. This loophole
might be closed before the changes are made final.
# Can I use the Public Domain?
No, because it does not work in all countries. CC-0 is recommended
instead, which is basically equivalent to the public domain.
# But, I'm basically conscientious objector to licenses in general.
I kind of understand where you come from, but this is the world we live
in. If you want to make a statement with your license, consider
WTFPL[0], which is on the list of approved licenses.
[0]: http://www.wtfpl.net/txt/copying/
# Can I use non-commercial licenses, like the Commons Clause?
# Can I use ethical-source licenses, like the Hippocratic License?
No, these would not be permitted.
# Can I use an "open core" model?
Yes, but you can only use sr.ht to host the "core" part of your project.
# Can I dual-license my software?
Yes, so long as sr.ht users may, at their choice, pick at least one
license which qualifies.
# What about private repos?
Private and unlisted repositories may continue to use any license they
wish.
# How will this be enforced?
I don't plan on doing automated scans of all projects or anything
similar. We will point out errors when we encounter projects which are
out of compliance, or when someone reports such a project to us for
review, and give such projects reasonable time to either come into
compliance or move to another platform.
# Are self-hosted or third-party SourceHut installs affected?
No, you can still install sr.ht on your own infrastructure and use it
as you please.
It is your platform to do as you please. Overall I find this acceptable. Normally I wouldn't like the idea of disallowing projects, but, I can understand
your reasons for such actions. The reasons I'm ok with this is mainly because of the GPL, which if I'm not mistaken allows for the software to be sold
and the source code be provided upon payment. In theory I could host a private repo of GPL source code but provide it to customers that pay for the product
and not be breaking the terms of service of sr.ht.
If I am wrong on this please correct.
Overall If I'm correct then I see no problem allowing for this restricted model.
Thanks,
Jordan
I started by reading the diff linked at the top of your email, then the rest
of your email.
This:
> The short of it is that all public projects would be required to use> licenses approved by the Free Software Foundation, Open Source> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.> These changes, if we moved forward with them, would be announced 90 days> in advance to give you ample time to deal with the changes as necessary> for your projects.
was alarming to me initially. Mentally, I consider unlisted repositories
"public" but I most frequently use them when I haven't done the legwork to
make sure licensing is in order and I'm seeking limited feedback from a small
circle of people.
I initially read your sentences above as prohibiting that, which would suck
some value out of a forge for me.
I understood once I got to this part:
> # What about private repos?> > Private and unlisted repositories may continue to use any license they> wish.>
that my usage is unaffected.
The level of alarm I started to react with makes me want to suggest an earlier
mention of the fact that unlisted repositories don't need to meet this
standard.
I would be incredibly disappointed if these changes were applied.
While I only have a handful of proprietary things on Sourcehut, and
they're all private repos for now, at some point I might want to make
them public. Not to open source them, but to make sure that anyone who
uses the software can build it themselves and know exactly what code
they are running (even though they still don't have the right to
redistribute that code or the binaries) or because I do not plan on
maintaining them anymore and want users to have the source code so that
they can continue to support their own internal installs.
I also have a handful of projects (none of which I've moved to Sourcehut
yet, thankfully) that do use licenses that are not OSI approved. These
are mostly joke projects or small experiments that use silly licenses
like the WTFPL or a variation on the "Good, not Evil" license. Even
though I don't generally continue to develop small experiments or silly
joke projects, I would still like them to be able to live in the same
place as the rest of my portfolio.
In general I agree with Sourcehut's stance that all projects should have
an open source license and that license proliferation is a bad thing,
but I can't predict what I will want to do with all of my projects in
the future and couldn't use any platform that tried to dictate how I
licensed my own projects. Of course, I understand that Sourcehut doesn't
need me as a customer and that me leaving the platform won't matter in
the long run, but it would be incredibly disappointing for me personally
as I like Sourcehut's workflows much more than any other development
platform I've tried and I've invested a lot of time moving from GitHub
to Sourcehut (a process which takes a surprisingly long time, repos and
projects do pile up, don't they?)
Please do not make these changes.
—Sam
On Thu, May 28, 2020, at 21:07, Drew DeVault wrote:
> I'm looking for user feedback on a set of proposed changes to the> terms of service. You can read the full diff here:>> https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9>> The changes to the privacy policy are just a bunch of minor> clarifications that I've had queued up for the next time we needed to> make a major change. The meat of it is in the terms of service, and> the most important change is to the licenses permitted for use on> public projects using the service.>> The short of it is that all public projects would be required to use> licenses approved by the Free Software Foundation, Open Source> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.> These changes, if we moved forward with them, would be announced 90> days in advance to give you ample time to deal with the changes as> necessary for your projects.>> To answer some expected questions right off the bat:>>> # Does this mean I have to use the GPL? I hate viral licenses.>> No, licenses like MIT, BSD, Apache 2.0, and so on, are approved by> both the Free Software Foundation and the Open Source Initiative. The> full lists of approved licenses are here:>> https://www.gnu.org/licenses/license-list.en.html>> https://opensource.org/licenses/category>> You can use Creative Commons, too, but the idea behind allowing CC> licenses is to provide a better option for things which are not code.>> There is a loophole here, which is that you could license software> projects with a non-commercial Creative Commons license, which would> make your project neither open source nor free software. This loophole> might be closed before the changes are made final.>>> # Can I use the Public Domain?>> No, because it does not work in all countries. CC-0 is recommended> instead, which is basically equivalent to the public domain.>>> # But, I'm basically conscientious objector to licenses in general.>> I kind of understand where you come from, but this is the world we> live in. If you want to make a statement with your license, consider> WTFPL[0], which is on the list of approved licenses.>> []: http://www.wtfpl.net/txt/copying/>>> # Can I use non-commercial licenses, like the Commons Clause? Can I> # use ethical-source licenses, like the Hippocratic License?>> No, these would not be permitted.>>> # Can I use an "open core" model?>> Yes, but you can only use sr.ht to host the "core" part of your> project.>>> # Can I dual-license my software?>> Yes, so long as sr.ht users may, at their choice, pick at least one> license which qualifies.>>> # What about private repos?>> Private and unlisted repositories may continue to use any license> they wish.>>> # How will this be enforced?>> I don't plan on doing automated scans of all projects or anything> similar. We will point out errors when we encounter projects which are> out of compliance, or when someone reports such a project to us for> review, and give such projects reasonable time to either come into> compliance or move to another platform.>>> # Are self-hosted or third-party SourceHut installs affected?>> No, you can still install sr.ht on your own infrastructure and use it> as you please.>
--
Sam Whited
On Thu May 28, 2020 at 7:56 PM EDT, Sam Whited wrote:
> While I only have a handful of proprietary things on Sourcehut, and> they're all private repos for now, at some point I might want to make> them public. Not to open source them, but to make sure that anyone who> uses the software can build it themselves and know exactly what code> they are running (even though they still don't have the right to> redistribute that code or the binaries) or because I do not plan on> maintaining them anymore and want users to have the source code so that> they can continue to support their own internal installs.
You should just make them open source :) This is exactly the kind of
repository that would be affected by these changes, by design. You can
make software open source without committing to its maintenance, your
logic doesn't follow here.
> I also have a handful of projects (none of which I've moved to Sourcehut> yet, thankfully) that do use licenses that are not OSI approved. These> are mostly joke projects or small experiments that use silly licenses> like the WTFPL or a variation on the "Good, not Evil" license. Even> though I don't generally continue to develop small experiments or silly> joke projects, I would still like them to be able to live in the same> place as the rest of my portfolio.
Note that the WTFPL is specifically called out in the FAQ as permitted
under these changes.
> In general I agree with Sourcehut's stance that all projects should have> an open source license and that license proliferation is a bad thing,> but I can't predict what I will want to do with all of my projects in> the future and couldn't use any platform that tried to dictate how I> licensed my own projects. Of course, I understand that Sourcehut doesn't> need me as a customer and that me leaving the platform won't matter in> the long run, but it would be incredibly disappointing for me personally> as I like Sourcehut's workflows much more than any other development> platform I've tried and I've invested a lot of time moving from GitHub> to Sourcehut (a process which takes a surprisingly long time, repos and> projects do pile up, don't they?)
You can also use multiple forges, or a self-hosted forge, or stick to
keeping the repositories private or unlisted.
On Thu, May 28, 2020, at 23:57, Drew DeVault wrote:
> You should just make them open source :) This is exactly the kind of> repository that would be affected by these changes, by design. You can> make software open source without committing to its maintenance, your> logic doesn't follow here.
I don't want them to be open source because I don't want them
redistributed or because I'm not sure what if anything I'm going to do
with them yet. I may open source them in the future, or I may not.
However, I may still end up wanting them to be public.
Another example I just thought of is Go libraries we maintain at work: a
number of them aren't open source, but Go code has to be public to be
redistributed (ie so that go get can fetch the repos). If I wanted to do
something similar with a proprietary Go library, I couldn't do this on
Sourcehut after these changes. In general I can't see myself writing a
Go library that I didn't juts open source, but the point is that I can't
predict why I might want to do this in the future and would not be
comfortable working on a platform that denied me this flexibility.
> Note that the WTFPL is specifically called out in the FAQ as permitted> under these changes.
Ah yes, so it is. Never the less, several others aren't.
> You can also use multiple forges, or a self-hosted forge, or stick to> keeping the repositories private or unlisted.
I would prefer to have everything in one place, and have the flexibility
to do with my own code what I please (which may include making it
public). I understand that this doesn't matter to Sourcehut, but it
matters to me.
Thanks for considering my points and the position I'm now in. I
appreciate all the hard work you've put into Sourcehut; it's a
great product, and I'd be very sad to have to find somewhere else
to host my code.
Best, Sam
--
Sam Whited
On Thu May 28, 2020 at 8:06 PM EDT, Sam Whited wrote:
> I don't want them to be open source because I don't want them> redistributed or because I'm not sure what if anything I'm going to do> with them yet. I may open source them in the future, or I may not.> However, I may still end up wanting them to be public.
Then I'm afraid you would have no recourse under these terms. Not
everyone is going to come away happy here, I am well aware that some
users are not going to find these changes tolerable.
> Another example I just thought of is Go libraries we maintain at work: a> number of them aren't open source, but Go code has to be public to be> redistributed (ie so that go get can fetch the repos). If I wanted to do> something similar with a proprietary Go library, I couldn't do this on> Sourcehut after these changes. In general I can't see myself writing a> Go library that I didn't juts open source, but the point is that I can't> predict why I might want to do this in the future and would not be> comfortable working on a platform that denied me this flexibility.
You could use unlisted repositories in this case.
On Fri, May 29, 2020, at 00:12, Drew DeVault wrote:
> Then I'm afraid you would have no recourse under these terms. Not> everyone is going to come away happy here, I am well aware that some> users are not going to find these changes tolerable.
May I ask, the way this response was phrased sounded like you've already
made up your mind and asking was just a formality? If so fair enough, I
just wanted to provide feedback like you asked.
> You could use unlisted repositories in this case.
Ah yes, I did forget this was supported, this specific case would be
okay then.
—Sam
--
Sam Whited
Drew DeVault <sir@cmpwn.com> writes:
> # Can I use an "open core" model?>> Yes, but you can only use sr.ht to host the "core" part of your> project.
Responding on "open core" section even though my point is more general.
Personally, I would like to see more of a rational behind this change.
The usual contract I am used to is roughly: I give you money, you serve
my bits. With restrictions on my bits not harming your business. These
changes really push your beliefs on me, which I do not support. I would
be OK with this if the public repositories were free repositories, but
since I'm paying, I expect to be able to run my business how I want on a
paid services with obvious restrictions around abuse.
>>>> # What about private repos?>> Private and unlisted repositories may continue to use any license they> wish.
It might be worth making the language clearer in the TOS. It's not
clear to me if a "public project" is a "public repo" or something else.
--
Malcolm Matalka
Abiogenesis Computer Systems Lab
On Thu May 28, 2020 at 8:22 PM EDT, Sam Whited wrote:
> May I ask, the way this response was phrased sounded like you've already> made up your mind and asking was just a formality? If so fair enough, I> just wanted to provide feedback like you asked.
No, I haven't made up my mind, and I am receptive to feedback. I'm just
saying that negative feedback from a few people was expected, and is not
the only criteria which will make the decision.
On Fri, May 29, 2020, at 00:23, Drew DeVault wrote:
> No, I haven't made up my mind, and I am receptive to feedback. I'm> just saying that negative feedback from a few people was expected, and> is not the only criteria which will make the decision.
Ah yes, of course. I apologize if I implied that I thought that just by
providing negative feedback it would sway you, I just wanted to provide
some feedback like you asked and try to explain why I would no longer be
able to use Sourcehut. Hopefully it will be useful to you as you make
your decision.
Thanks again,
Sam
--
Sam Whited
On Fri May 29, 2020 at 2:24 AM EDT, Malcolm Matalka wrote:
> Responding on "open core" section even though my point is more general.>> Personally, I would like to see more of a rational behind this change.> The usual contract I am used to is roughly: I give you money, you serve> my bits. With restrictions on my bits not harming your business. These> changes really push your beliefs on me, which I do not support. I would> be OK with this if the public repositories were free repositories, but> since I'm paying, I expect to be able to run my business how I want on a> paid services with obvious restrictions around abuse.
Paying for the service does not entitle you to any particular kind of
service; you can always choose not to pay. The core mission of SourceHut
is to support and improve the free and open source software ecosystem -
not to provide a hosted software forge to paying customers who wish to
use it for any purpose they please. We believe that the software forge
is a great way to support the free and open source community, but using
it to support the proprietary software community does not really
contribute to our mission.
Drew DeVault <sir@cmpwn.com> writes:
> On Fri May 29, 2020 at 2:24 AM EDT, Malcolm Matalka wrote:>> Responding on "open core" section even though my point is more general.>>>> Personally, I would like to see more of a rational behind this change.>> The usual contract I am used to is roughly: I give you money, you serve>> my bits. With restrictions on my bits not harming your business. These>> changes really push your beliefs on me, which I do not support. I would>> be OK with this if the public repositories were free repositories, but>> since I'm paying, I expect to be able to run my business how I want on a>> paid services with obvious restrictions around abuse.>> Paying for the service does not entitle you to any particular kind of> service; you can always choose not to pay. The core mission of SourceHut> is to support and improve the free and open source software ecosystem -> not to provide a hosted software forge to paying customers who wish to> use it for any purpose they please. We believe that the software forge> is a great way to support the free and open source community, but using> it to support the proprietary software community does not really> contribute to our mission.
I'm not sure if you acknowledged the other piece of feedback but I think
unlisted is a good "escape hatch" for the policy so I think making it
explicit in the TOS what a "public project" is would be good. The
person responding about Go repositories would be able to use that for
their needs.
--
Malcolm Matalka
Abiogenesis Computer Systems Lab
On Friday, May 29, 2020 3:07 AM, Drew DeVault <sir@cmpwn.com> wrote:
> The short of it is that all public projects would be required to use> licenses approved by the Free Software Foundation, Open Source> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.
Maybe that's a minor point, but what would be the recommended solution
for "less important" repos like dotfiles? It would be annoying to have
a LICENSE file lying around in ~, or to add a license header to all
files. I suppose these repos could be unlisted, but that would be a
hack to just workaround the rule.
Hi,
On 28-05-2020 21:07:48, Drew DeVault wrote:
> https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9
I can totally see where this comes from and what the purpose of such a change
is. I think that changing the rules this way is a step forward (IMHO into the
right direction, but that is of course to be discussed, hence your mail :-) ).
My only concern is, that one may argue that you're taking away freedoms of the
user, essentially. This is just a really minor thing and I am personally not
affected, as my repos on sourcehut are MPL or (L)GPL, but I can see that users
might point out that you're restricting their freedom.
The obvious counter argument is that they still have the freedom to unlist their
repos or self-host sourcehut, of course.
Please don't understand the paragraph above as a statement in either direction,
just as a statement what others might say and that their concerns might be valid
to some degree (no black-or-white here, but shades of grey).
I like that you send this around for discussion and this encourages me to
continue using sourcehut as it clearly shows you're concerned about users, not
about business!
--
Kind regards,
Matthias Beyer
> On May 29, 2020, at 16:45, Matthias Beyer <mail@beyermatthias.de> wrote:> > My only concern is, that one may argue that you're taking away freedoms of the> user, essentially. This is just a really minor thing and I am personally not> affected, as my repos on sourcehut are MPL or (L)GPL, but I can see that users> might point out that you're restricting their freedom.> The obvious counter argument is that they still have the freedom to unlist their> repos or self-host sourcehut, of course.
I personally think that what Drew is doing is actually increasing user freedom.
sr.ht, the service, is designed to help free and open source software, by clarifying the rules to reach that, Drew helps users make choices that are right for them.
But sr.ht, the solution, which is also free software, empowers users with high quality free software to use in their non free development as a self-hosted solution.
So, yes. Thank you. And I'm sorry I can only support this endeavor financially and not by contributing any code at all.
--
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com
Am 29.05.20 um 08:41 schrieb Simon Ser:
> Maybe that's a minor point, but what would be the recommended solution> for "less important" repos like dotfiles? It would be annoying to have> a LICENSE file lying around in ~, or to add a license header to all> files. I suppose these repos could be unlisted, but that would be a> hack to just workaround the rule.
To further expand on this point: what if I want a public repo but don't
know or care about proper licensing my grandma's pancake recipes or
helloworlds in lisp?
If a license will be mandatory for public repos, probably a bit of
guidance on how to quickly choose one could also help. Maybe a link to
something like https://choosealicense.com?
I second the comment that sr.ht is Drew's platform, so my humble .2
cents are that is perfectly fine whatever he chooses.
Cheers,
> Maybe that's a minor point, but what would be the recommended solution> for "less important" repos like dotfiles? It would be annoying to have> a LICENSE file lying around in ~, or to add a license header to all> files. I suppose these repos could be unlisted, but that would be a> hack to just workaround the rule.
Depending on what you use to manage your dotfiles locally there may be a
solution to that already provided to you. Example my dotfiles are currently
hosted on GitLab [1] and it currently licensed under the WTFPL [2] and my
dotfile manager YADM [3] allows me to have a bootstrap script that runs when
the repo is cloned. One of the tasks this script does is moves the COPYING and
the README file out of my $HOME directory and does a "git update-index --
assume-unchanged" on them. I'm sure other tools have a similar functionality
that could be used here.
[1]: https://gitlab.com/vendion/dotfiles
[2]: https://gitlab.com/vendion/dotfiles/-/blob/master/COPYING
[3]: https://yadm.io/> To further expand on this point: what if I want a public repo but don't> know or care about proper licensing my grandma's pancake recipes or> helloworlds in lisp?
I would say for things like this take advantage of the fact that CC-0 and
WTFPL licenses are allowed and are pretty close to putting the project in
public domain.
> If a license will be mandatory for public repos, probably a bit of> guidance on how to quickly choose one could also help. Maybe a link to> something like https://choosealicense.com?
Sourcehut already provides such a page at https://man.sr.ht/license.md and
even links to other sites including choosealicense.com. Although since these
proposed changes explicitly calls out that WTFPL and CC-0 will be allowed for
public repos this page should be updated with a section that covers them.
Question for Drew: with these changes where would the Unlicense [4] fall? It's
a similar licenses to WTFPL and CC-0 with the exception of recommending that
project owners require contributors digitally sign a waver or include a
statement in their patchset indicating that their contribution falls under the
Unlicense.
Full disclaimer I'm not a lawyer nor am I an expect in software/IP licensing,
and everything I said is my own opinion and should be taken as such.
On Fri, May 29, 2020 at 08:03:03AM -0400, Adam Jimerson wrote:
> Question for Drew: with these changes where would the Unlicense [4] fall?
It's on the FSF's licence list as a "GPL-compatible Free Software
Licence", so I'm sure it's fine:
https://www.gnu.org/licenses/license-list.html#Unlicense
On Friday, May 29, 2020 8:37:24 AM EDT you wrote:
> On Fri, May 29, 2020 at 08:03:03AM -0400, Adam Jimerson wrote:> > Question for Drew: with these changes where would the Unlicense [4] fall?> > It's on the FSF's licence list as a "GPL-compatible Free Software> Licence", so I'm sure it's fine:> > https://www.gnu.org/licenses/license-list.html#Unlicense
Yeah it's on the FSF's list of "GPL-compatible" licenses, but between that and
the proposed changes saying that Public Domain public projects wouldn't be
allowed. The fact that the Unlicense is very close to being public domain (at
least IMO) with this suggestion/recommendation https://unlicense.org/
#unlicensing-contributions makes it feels like it could fall in a grey area
with the proposed ToS and was just looking for some clarification for users
that may not want to go with a more formal copyleft/permissive license for
their repos.
I only bring this up because the WTFPL and CC-0 (IIRC been a while since I
reviewed it) does not have such a suggestion/recommendation when using those
licenses and was curious of how that will affect matters.
The Unlicense is permitted under these terms. The specific criteria for
licenses allowed from this list is "any license which is not marked as
'nonfree'".
On Fri, May 29, 2020, at 4:15 AM, Jean-Christophe Helary wrote:
> I personally think that what Drew is doing is actually increasing user freedom.
I'm sorry, but I have to disagree on this point.
You can't restrict what a user can do on a platform and say it is increasing
their freedom. That doesn't mean that it is wrong or shouldn't be done,
but you can't do one thing and call it another.
-Zach
On Fri May 29, 2020 at 2:41 AM EDT, Simon Ser wrote:
> Maybe that's a minor point, but what would be the recommended solution> for "less important" repos like dotfiles? It would be annoying to have> a LICENSE file lying around in ~, or to add a license header to all> files. I suppose these repos could be unlisted, but that would be a> hack to just workaround the rule.
Maybe we could have a UI for declaring the license out-of-band. It is
useful to have a license for dotfiles, too, for example if someone wants
to repurpose one or your user scripts or incorporate your custom theme
upstream.
On Fri May 29, 2020 at 4:52 AM EDT, Zachary King wrote:
> I'm sorry, but I have to disagree on this point.>> You can't restrict what a user can do on a platform and say it is> increasing their freedom. That doesn't mean that it is wrong or> shouldn't be done, but you can't do one thing and call it another.
I don't want to get into the weeds on this, but by requiring all public
projects to use a FOSS license, it increases the freedom of *everyone
else* by making sure that any project they see on sr.ht is something
they can use under terms they understand.
On Fri May 29, 2020 at 7:23 AM EDT, wrote:
> To further expand on this point: what if I want a public repo but don't> know or care about proper licensing my grandma's pancake recipes or> helloworlds in lisp?
I agree with earlier comments: it's not especially burdensome to ask you
to drop CC-0 next to 'ma's receipes, or MIT with the helloworlds.
Another quick question:
What about repos that are not actually copyrightable? For example, I
maintain a list of folk dances (some that I have written, some by other
callers). In the U.S. at least these are not copyrightable even if
you're the author of the dance, so a license like CC would not apply.
—Sam
On Thu, May 28, 2020, at 21:07, Drew DeVault wrote:
> I'm looking for user feedback on a set of proposed changes to the> terms of service. You can read the full diff here:>> https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9>> The changes to the privacy policy are just a bunch of minor> clarifications that I've had queued up for the next time we needed to> make a major change. The meat of it is in the terms of service, and> the most important change is to the licenses permitted for use on> public projects using the service.>> The short of it is that all public projects would be required to use> licenses approved by the Free Software Foundation, Open Source> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.> These changes, if we moved forward with them, would be announced 90> days in advance to give you ample time to deal with the changes as> necessary for your projects.>> To answer some expected questions right off the bat:>>> # Does this mean I have to use the GPL? I hate viral licenses.>> No, licenses like MIT, BSD, Apache 2.0, and so on, are approved by> both the Free Software Foundation and the Open Source Initiative. The> full lists of approved licenses are here:>> https://www.gnu.org/licenses/license-list.en.html>> https://opensource.org/licenses/category>> You can use Creative Commons, too, but the idea behind allowing CC> licenses is to provide a better option for things which are not code.>> There is a loophole here, which is that you could license software> projects with a non-commercial Creative Commons license, which would> make your project neither open source nor free software. This loophole> might be closed before the changes are made final.>>> # Can I use the Public Domain?>> No, because it does not work in all countries. CC-0 is recommended> instead, which is basically equivalent to the public domain.>>> # But, I'm basically conscientious objector to licenses in general.>> I kind of understand where you come from, but this is the world we> live in. If you want to make a statement with your license, consider> WTFPL[0], which is on the list of approved licenses.>> []: http://www.wtfpl.net/txt/copying/>>> # Can I use non-commercial licenses, like the Commons Clause? Can I> # use ethical-source licenses, like the Hippocratic License?>> No, these would not be permitted.>>> # Can I use an "open core" model?>> Yes, but you can only use sr.ht to host the "core" part of your> project.>>> # Can I dual-license my software?>> Yes, so long as sr.ht users may, at their choice, pick at least one> license which qualifies.>>> # What about private repos?>> Private and unlisted repositories may continue to use any license> they wish.>>> # How will this be enforced?>> I don't plan on doing automated scans of all projects or anything> similar. We will point out errors when we encounter projects which are> out of compliance, or when someone reports such a project to us for> review, and give such projects reasonable time to either come into> compliance or move to another platform.>>> # Are self-hosted or third-party SourceHut installs affected?>> No, you can still install sr.ht on your own infrastructure and use it> as you please.>
--
Sam Whited
On Fri May 29, 2020 at 5:05 AM EDT, Sam Whited wrote:
> What about repos that are not actually copyrightable? For example, I> maintain a list of folk dances (some that I have written, some by other> callers). In the U.S. at least these are not copyrightable even if> you're the author of the dance, so a license like CC would not apply.
We can probably make an exception for works which are not copyrightable
in the US. I've also been thinking about adding an exception for the US
Public Domain, so that works of the US government could be hosted here.
SourceHut is a US entity, so it's from that context that such exceptions
would have to be made.
Am 29.05.20 um 14:03 schrieb Adam Jimerson:
> I would say for things like this take advantage of the fact that CC-0 and > WTFPL licenses are allowed and are pretty close to putting the project in > public domain.> Sourcehut already provides such a page at https://man.sr.ht/license.md and > even links to other sites including choosealicense.com. Although since these > proposed changes explicitly calls out that WTFPL and CC-0 will be allowed for > public repos this page should be updated with a section that covers them.
Ah, interesting thanks!
W dniu 29.05.2020 o 15:05, Sam Whited pisze:
> What about repos that are not actually copyrightable? For example, I> maintain a list of folk dances (some that I have written, some by other> callers). In the U.S. at least these are not copyrightable even if> you're the author of the dance, so a license like CC would not apply.>
IANAL, but if you grant a permission (a license) to someone
who doesn't need your permission, does it really hurt?
On Fri, May 29, 2020, at 9:14 AM, Drew DeVault wrote:
> We can probably make an exception for works which are not copyrightable> in the US. I've also been thinking about adding an exception for the US> Public Domain, so that works of the US government could be hosted here.
That might be interesting. Could be used to host the legal code and track
bills passed as commits... though that would probably be a ton of work.
I know there was a project like that for the US Constitution on Github, but
that doesn't change nearly as fast.
-Zach
On Fri, May 29, 2020, at 9:39 AM, Wolf480pl wrote:
> IANAL, but if you grant a permission (a license) to someone> who doesn't need your permission, does it really hurt?
You can't grant a license for something you don't have
rights to. You would need to transform it in some way to
gain copyright, which you could then put under any license
you want. See this article by CC. [1]
-Zach
1: https://creativecommons.org/2019/11/20/reproductions-of-public-domain-works/
W dniu 29.05.2020 o 15:52, Zachary King pisze:
> You can't grant a license for something you don't have> rights to. You would need to transform it in some way to> gain copyright, which you could then put under any license> you want. See this article by CC. [1]
ok, from the article linked:
> If the work is in the public domain [...] the application> of a CC license is ineffective
IOW, adding a LICENSE file to a non-copyrightable work is a no-op,
right?
Drew DeVault <sir@cmpwn.com> writes:
> On Fri May 29, 2020 at 4:52 AM EDT, Zachary King wrote:>> I'm sorry, but I have to disagree on this point.>>>> You can't restrict what a user can do on a platform and say it is>> increasing their freedom. That doesn't mean that it is wrong or>> shouldn't be done, but you can't do one thing and call it another.>> I don't want to get into the weeds on this, but by requiring all public> projects to use a FOSS license, it increases the freedom of *everyone> else* by making sure that any project they see on sr.ht is something> they can use under terms they understand.
Question out of curiosity:
Would it be against policy for me to run an external public project
directory that people can submit unlisted projects, so they can work
around the license restriction?
Similarly, would it be against policy to create a public project that
contains links to unlisted projects (like the "awesome-blah" repose that
exist for topics) that do not have licenses that reflect public project
requirements?
--
Malcolm Matalka
Abiogenesis Computer Systems Lab
On Fri, May 29, 2020, at 10:00, Wolf480pl wrote:
> IOW, adding a LICENSE file to a non-copyrightable work is a no-> op, right?
It is definitely a no-op, but it still seems confusing at best and
misleading at worst. I'd definitely think twice about putting a CC-0 on
my repo, then also saying somewhere "please ignore the license, it's
just there so that we can make this public". This particular line of
inquiry doesn't really matter though since Drew said he'd make an
exception for it.
—Sam
On Fri May 29, 2020 at 12:03 PM EDT, Malcolm Matalka wrote:
> Would it be against policy for me to run an external public project> directory that people can submit unlisted projects, so they can work> around the license restriction?>> Similarly, would it be against policy to create a public project that> contains links to unlisted projects (like the "awesome-blah" repose that> exist for topics) that do not have licenses that reflect public project> requirements?
This would definitely be against the spirit of the terms, and would
likely make me rethink the exception for unlisted projects.
On 29 May 2020 14:52:46 CEST, Zachary King <zchrykng@fastmail.com> wrote:
>On Fri, May 29, 2020, at 4:15 AM, Jean-Christophe Helary wrote:>> I personally think that what Drew is doing is actually increasing>user freedom.>>I'm sorry, but I have to disagree on this point.>>You can't restrict what a user can do on a platform and say it is>increasing>their freedom. That doesn't mean that it is wrong or shouldn't be done,>but you can't do one thing and call it another.>>-Zach
This is a common mistake. In this situation you are not the user, the freedoms of the users of your software is considered here.
Free Software cares very little about the freedoms of the programmer.
On 5/29/20 11:07 AM, Drew DeVault wrote:
> I'm looking for user feedback on a set of proposed changes to the terms> of service. You can read the full diff here:> > https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9> > The changes to the privacy policy are just a bunch of minor> clarifications that I've had queued up for the next time we needed to> make a major change. The meat of it is in the terms of service, and the> most important change is to the licenses permitted for use on public> projects using the service.> > The short of it is that all public projects would be required to use> licenses approved by the Free Software Foundation, Open Source> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.> These changes, if we moved forward with them, would be announced 90 days> in advance to give you ample time to deal with the changes as necessary> for your projects
Broadly speaking I agree with the terms, however I would request a
clarification on the definition of a `public project'. Do you mean a
public repository or do you mean the newly rolled out project hub?
~Kunal
On 2020-05-28 21:07, Drew DeVault wrote:
> I'm looking for user feedback on a set of proposed changes to the terms> of service. You can read the full diff here:> > > The short of it is that all public projects would be required to use> licenses approved by the Free Software Foundation, Open Source> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.> These changes, if we moved forward with them, would be announced 90 days> in advance to give you ample time to deal with the changes as necessary> for your projects.>
In another thread someone asked the question if they were allowed to
store their non code related projects in sr.ht (i.e. blogs, writings,
etc). The answer was yes. They did not elaborate further on what kind of
content these would contain. If I extrapolate that to my case I would be
interested in hosting a small personal web page and maybe my resume
here. However I would not want to lose my rights over my documents.
Did you envision classifying public code repositories differently than
public files for hosting web sites or maybe having other web sites point
to the assets stored in sr.ht?
Jon
On Sat May 30, 2020 at 9:35 AM EDT, Jon Fineman wrote:
> Did you envision classifying public code repositories differently than> public files for hosting web sites or maybe having other web sites point> to the assets stored in sr.ht?
For your personal website, you could use a creative commons license,
which offers lots of flexibility to you in how strict or lenient the
distribution terms are. The most strict is CC-BY-ND-NC, which prohibits
derivative works and commercial use, and requires attribution.
As part of feedback, I'll skip the political part of the story and ask
about a technical approach. Would it be feasible to ask the user to pick
one of the allowed licences if they're marking their project public?
Something like "To further free software, all publicly listed projects
at this site need to put one of the following licences: ", then them
listed, along with the options for like 'US Government thing' etc etc."
I think this would help avoid surprises make the intention explicit. Of
course, since you also let people host their own stuff, it would also
mean it's configurable. But still, does this sound like something
feasible? And if not, I'd be curious to know why.
--
Zlatko
> On May 31, 2020, at 2:35, Jon Fineman <jon@fineman.me> wrote:> > > On 2020-05-28 21:07, Drew DeVault wrote:>> I'm looking for user feedback on a set of proposed changes to the terms>> of service. You can read the full diff here:>> The short of it is that all public projects would be required to use>> licenses approved by the Free Software Foundation, Open Source>> Initiative, or Creative Commons, within 90 days of appearing on sr.ht.>> These changes, if we moved forward with them, would be announced 90 days>> in advance to give you ample time to deal with the changes as necessary>> for your projects.> > In another thread someone asked the question if they were allowed to store their non code related projects in sr.ht (i.e. blogs, writings, etc). The answer was yes. They did not elaborate further on what kind of content these would contain. If I extrapolate that to my case I would be interested in hosting a small personal web page and maybe my resume here. However I would not want to lose my rights over my documents.
All the licenses that exist in the FOSS ecology are licenses that *protect* copyright. They don't make copyright weaker.
As far as writings/blogs etc. are concerned *most* people do not associate a license to what they post on the public web and just (if they do) use the weak "copyright" mark to indicate that they "own" the text.
Just take the habit to use a license for your documents.
(my blog below is *explicitely* under the GFDL)
--
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com
I don't care to comment much on the rest of the discussion, but there
are some comments that are potentially misleading that deserve
clarification.
Note I am not a lawyer, nor is this legal advice. That said I have been
in plenty of IP discussions with lawyers for works I and companies I
work for have created and am conversant on these topics. Also note that
this is US-focused, though is likely broadly similar in many other
jurisdictions.
On Sun, 2020-05-31 at 09:49 +0900, Jean-Christophe Helary wrote:
> All the licenses that exist in the FOSS ecology are licenses that> *protect* copyright. They don't make copyright weaker.
Copyright needs no protection or clarification. Copyright is
automatically, immediately, and exclusively granted to an author when a
creative* work is fixed in a tangible form. Unless granted
permission/license by the author, no one has any right to distribute or
make copies of the work. No license protects or weakens copyright, per
se. Some licenses grant rights to others, but copyright still vests in
the author or copyright-holder (if assigned to some entity other than
the author).
> As far as writings/blogs etc. are concerned *most* people do not> associate a license to what they post on the public web and just (if> they do) use the weak "copyright" mark to indicate that they "own" the> text.
The copyright mark is neither weak nor does it merit using quotes to
imply a question about ownership. A published creative* work (which any
blog post would count as) is protected by copyright, which right is held
by the author. No license need be posted, or any other affirmative
action taken to cement the copyright. Any non-approved use of this work
would be infringing.
A posted license may grant certain rights to others (e.g. the types of
FOSS and CC licenses discussed in this thread). Without any rights
explicitly granted, you should assume none are, and should not infringe
the work (i.e. use it in a manner that is not fair use or a derivative
work), but rather should acquire permission from the copyright-holder if
you wish to distribute the work. Assuming otherwise will likely open you
up to liability for copyright infringement.
All of the above *explicitly includes* works published for free in
public fora (e.g. an individual's blog) that have no license declared.
> Just take the habit to use a license for your documents.
This is generally good advice.
If you have any major questions or concerns about copyright (or any
other legal matter), *seek legal counsel*. Do not depend on my very
generalized discussion above. Do not depend upon mailing list or other
fora of laypeople. I will repeat myself: if you want legal advice, then
retain legal counsel. If the work subject to copyright is important to
you, and especially if it is important to your income or wellbeing, then
give strong consideration to the license you choose, and seek legal
counsel if you have questions.
* "Creative", for the purposes of copyright discussions, should
typically be considered as "minimally creative".
> On May 31, 2020, at 10:35, Greg B <g@greggyb.com> wrote:> > I don't care to comment much on the rest of the discussion, but there> are some comments that are potentially misleading that deserve> clarification.
Greg, thank you for the clarifications, and I apologize for my poor choice of words.
> On Sun, 2020-05-31 at 09:49 +0900, Jean-Christophe Helary wrote:>> All the licenses that exist in the FOSS ecology are licenses that>> *protect* copyright. They don't make copyright weaker.> > Copyright needs no protection or clarification. Copyright is> automatically, immediately, and exclusively granted to an author when a> creative* work is fixed in a tangible form. Unless granted> permission/license by the author, no one has any right to distribute or> make copies of the work. No license protects or weakens copyright, per> se. Some licenses grant rights to others, but copyright still vests in> the author or copyright-holder (if assigned to some entity other than> the author).
Indeed. But the discussion here takes place in a space where FOSS licenses will be *compulsory* in some conditions.
> No license need be posted, or any other affirmative> action taken to cement the copyright. Any non-approved use of this work> would be infringing.
I did not intend to imply otherwise.
> A posted license may grant certain rights to others (e.g. the types of> FOSS and CC licenses discussed in this thread).
This is where I say that "All the licenses that exist in the FOSS ecology are licenses that *protect* copyright. They don't make copyright weaker."
And that was as a reply to Jon Fineman who wrote "However I would not want to lose my rights over my documents."
So, yes, *protect* is not appropriate. And you are correct to state that copyright applies automatically. But Jon doesn't seem to know that and Jon seems to worry that he may lose some rights by using a FOSS license.
This is not the case, and you (seem to) agree with me in your reply.
My stance is that authors are stronger when they use a FOSS license because they don't have to worry about granting rights on an individual basis, so they are free to worry about writing for one. And obviously users of derivative works authors are stronger because they don't have to worry about asking permission on a file basis.
That's also why I wrote earlier in the thread "I personally think that what Drew is doing is actually increasing user freedom." and I include sr.ht service users and external users.
>> Just take the habit to use a license for your documents.> > This is generally good advice.> > If you have any major questions or concerns about copyright (or any> other legal matter), *seek legal counsel*. Do not depend on my very> generalized discussion above. Do not depend upon mailing list or other> fora of laypeople. I will repeat myself: if you want legal advice, then> retain legal counsel. If the work subject to copyright is important to> you, and especially if it is important to your income or wellbeing, then> give strong consideration to the license you choose, and seek legal> counsel if you have questions.
Also, there is plenty of literature on copyright/FLOSS licenses and a lot of people specialized in this area of copyright law.
--
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com
Hello,
On Sat 30 May 2020 at 01:38PM -04, Drew DeVault wrote:
> On Sat May 30, 2020 at 9:35 AM EDT, Jon Fineman wrote:>> Did you envision classifying public code repositories differently than>> public files for hosting web sites or maybe having other web sites point>> to the assets stored in sr.ht?>> For your personal website, you could use a creative commons license,> which offers lots of flexibility to you in how strict or lenient the> distribution terms are. The most strict is CC-BY-ND-NC, which prohibits> derivative works and commercial use, and requires attribution.
Note that these restrictive licenses are not considered free software
licenses by at least Debian, and probably FSF and OSI too. So I think
the proposed policy needs contain an exception for these.
--
Sean Whitton
Hi,
> I'm looking for user feedback on a set of proposed changes to the> terms> of service. You can read the full diff here:> > https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9
If you're still looking for feedback on this one, and since mailing
lists don't work with "likes" or "+1"s (thank God they don't!), I'm
just gonna drop in and say it quick: sounds great to me.
Thanks,
Sergiu
On 2020-05-30 22:35, Jean-Christophe Helary wrote:
> > >> On Sun, 2020-05-31 at 09:49 +0900, Jean-Christophe Helary wrote:>>> All the licenses that exist in the FOSS ecology are licenses that>>> *protect* copyright. They don't make copyright weaker.>>>> Copyright needs no protection or clarification. Copyright is>> automatically, immediately, and exclusively granted to an author when a>> creative* work is fixed in a tangible form. Unless granted>> permission/license by the author, no one has any right to distribute or>> make copies of the work. No license protects or weakens copyright, per>> se. Some licenses grant rights to others, but copyright still vests in>> the author or copyright-holder (if assigned to some entity other than>> the author).> > Indeed. But the discussion here takes place in a space where FOSS licenses will be *compulsory* in some conditions.> >> A posted license may grant certain rights to others (e.g. the types of>> FOSS and CC licenses discussed in this thread).> > This is where I say that "All the licenses that exist in the FOSS ecology are licenses that *protect* copyright. They don't make copyright weaker."> > And that was as a reply to Jon Fineman who wrote "However I would not want to lose my rights over my documents."> > So, yes, *protect* is not appropriate. And you are correct to state that copyright applies automatically. But Jon doesn't seem to know that and Jon seems to worry that he may lose some rights by using a FOSS license.> > This is not the case, and you (seem to) agree with me in your reply.> > My stance is that authors are stronger when they use a FOSS license because they don't have to worry about granting rights on an individual basis, so they are free to worry about writing for one. And obviously users of derivative works authors are stronger because they don't have to worry about asking permission on a file basis.> >
I agree with the above statement as it relates to files comprising a
software application. I also would not want to be burdened with getting
rights on a file by file basis. However using my resume as an example I
think those burdens would be a good thing as it allows me to know who is
trying to use my resume.
A summary to several of the above statements. From reading articles and
the rational around why the copy left movement started was because the
original COPYRIGHT rules didn't allow for a more free distribution or
placed restrictions on how files were used, notices placed, or
republished. Choosing one of those kinds of copyrights is different than
choosing the original COPYRIGHT obviously. And by choosing one of those
allows more or different uses of the work*. So back to my original
premise that by choosing one of these more liberal copyrights the rules
are different and more permissive. Not something I would want for a resume.
* Another post indicated that the more restrictive kinds of copyrights
were not being considered here.
Jean-Cristophe,
My apologies for exclusively excerpting you in my message. I didn't
realize at the time I had done so. My response was based on several
messages in the thread that implied to me some confusion on the topic of
copyright, but it seems in my editing I only chose your quotes to
directly respond to. It wasn't my intent to single anyone out. This is
a topic of interest to me. In my haste to respond I think I came across
as directing my response personally to you, rather than as a general
response as I intended. Thank you for the generous response to what, in
hindsight, seems like a direct refutation.
As you mention we're largely in agreement. Your clarifications/extended
response are also very helpful.
-gb
> On Jun 1, 2020, at 0:15, Jon Fineman <jon@fineman.me> wrote:> > I agree with the above statement as it relates to files comprising a software application. I also would not want to be burdened with getting rights on a file by file basis. However using my resume as an example I think those burdens would be a good thing as it allows me to know who is trying to use my resume.
Thing of the "licensed" source of your resume as a template for other resumes.
As long as you put you CV in public, it is *visible* to everybody (which is the point of having your CV online) and putting a license to its *source* allows people to use it for their resumes (within what you grant them in the license).
> Choosing one of those kinds of copyrights is different than choosing the original COPYRIGHT obviously.
As Greg correctly stated, using a license does *not* weaken your copyright. NEVER EVER.
--
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com
> On Jun 1, 2020, at 0:31, Greg B <g@greggyb.com> wrote:> > Jean-Cristophe,> > My apologies for exclusively excerpting you in my message. I didn't> realize at the time I had done so. My response was based on several> messages in the thread that implied to me some confusion on the topic of> copyright, but it seems in my editing I only chose your quotes to> directly respond to. It wasn't my intent to single anyone out. This is> a topic of interest to me. In my haste to respond I think I came across> as directing my response personally to you, rather than as a general> response as I intended. Thank you for the generous response to what, in> hindsight, seems like a direct refutation.> > As you mention we're largely in agreement. Your clarifications/extended> response are also very helpful.
I am not a specialist, so I am totally fine if someone who knows more corrects me *especially* for important issues like what is being discussed here. And your tone was super professional, so that was good too :)
--
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com
Taking things a bit out of order here. Notes:
- US-centric view (though largely similar in many jurisdictions thanks
to several international IP treaties)
- Not a lawyer
- Not legal advice
- Seek legal counsel if you have questions and if your works are
important to you, particularly if important to your wellbeing
If you want to discuss copyright and license implications for specific
works, I am happy to do that, but I will repeat that if there is
anything really important, *seek legal counsel*. If seeking counsel
feels too onerous, then that seems a strong indicator (though not
conclusive, by any means) that the thing is not so important.
On Sun, 2020-05-31 at 11:15 -0400, Jon Fineman wrote:
> So, what summary to several of the above statements. From reading> articles and the rational around why the copy left movement started > was because the original COPYRIGHT rules didn't allow for a more free > distribution or placed restrictions on how files were used, notices> placed, or republished. Choosing one of those kinds of copyrights is > different than choosing the original COPYRIGHT obviously. And by > choosing one of those allows more or different uses of the work*. So > back to my original premise that by choosing one of these more > liberal copyrights the rules are different and more permissive. Not > something I would want for a resume.
There's some important clarification here. Copyright and copyleft are
not on the same continuum. Copyright is a legal protection of creative
works granted by most (all?) jurisdictions in the world. Copyright is
granted immediately, automatically, and exclusively to the author of a
without any requirement for affirmative action. Copyright can be
assigned to another by action of the author. A copyrighted work may be
copied and distributed only by the copyright-holder, or by entities to
whom the copyright-holder has granted a license.
Copyleft is a colloquial term used to refer to licenses that share
certain characteristics, largely focusing on a share and share alike
philosophy, which I am not going to dive too deeply into here.
By default, no one can copy or distribute a work to which you hold
copyright without your permission. You need take no action beyond fixing
your creative work in tangible form to have this control. What this
means is that as soon as you make something, you hold its copyright.
In general, you may choose to grant license(s), or not for any work to
which you hold copyright. A copyleft license grants certain rights to
everyone. This does not change the fact that you still hold copyright to
the work. For example, an MIT-style license grants others the right to
copy, modify, sell, and redistribute the copyrighted work so long as
they preserve the copyright and license in all copies of the work (also
some other verbiage). If you put an MIT license on something, you still
hold the copyright, and copies of the work must maintain attribution to
you. Beyond this, it is very permissive and allows others to use the
work very freely. There are other free licenses that are more
restrictive on the uses others may make of the copyrighted work, or
requirements that must be met to distribute the copyrighted work.
Specifically, the proposal being discussed in this thread is Drew's
intent to require certain types of license for works hosted publicly on
SourceHut.
> * Another post indicated that the more restrictive kinds of> copyrights > were not being considered here.
Per one of Drew's comments elsewhere, CC BY-NC-ND would be allowed under
this proposal, described below.
On Sat, 2020-05-30 at 13:38 -0400, Drew DeVault wrote:
> For your personal website, you could use a creative commons license,> which offers lots of flexibility to you in how strict or lenient the> distribution terms are. The most strict is CC-BY-ND-NC, which> prohibits> derivative works and commercial use, and requires attribution.
On Sun, 2020-05-31 at 11:15 -0400, Jon Fineman wrote:
> However using my resume as an example I > think those burdens would be a good thing as it allows me to know who> is trying to use my resume.
For something like a resume, there are a few things to keep in mind:
1. Regardless of license, anyone who modifies and distributes a copy
would absolutely have to make it clear that they are not you, otherwise,
they could be seen as impersonating you. If they were to use the
modified resume to persuade anyone to do anything, they could be
perpetrating a fraud by representing themselves as you.
2. If you don't want your resume to be freely redistributed, then you
should not use a free license for it. This would prevent you from
hosting it publicly on SourceHut. That said, the same reasons that cause
you to not want it freely redistributed would likely cause you to not
want to publicly host the work on a site where you cannot track views of
the thing. In any case, host it publicly somewhere that allows you to
use a license acceptable to you.
3. The CC BY-NC-ND license is likely acceptable for a publicly hosted
resume on a forge focused on FOSS. As Drew mentions above, this allows
only redistribution of the work, but does not permit modification or
commercial use. This is largely similar to someone passing on your
resume to someone that might find it interesting.
4. I do not think there is any license that requires someone to inform
you of when they use/view the copyrighted work. Certainly you would not
know who's viewing it if you hosted it in a public SourceHut repo.
If you don't want people seeing your resume without your knowledge, then
don't host it anywhere publicly.