MVP: Support for multiple content licenses

One think we need to think early on is whether we should support multiple content licenses, that is, different posts being under different licenses.

While the choice of license can be done right before actually creating content, the support for multiple licenses needs to be in the code, and therefore needs to be decided early on.

One place where this may crop up early is if we want to import both old and new posts from SE, while complying to the original licenses the posts were provided under.

Another way it could crop up is when importing content from several places (say SE on one hand, and a currently separate site that wants to migrate to us on the other hand), which may have different licenses on their existing content.

Finally, we might decide on a different license for newly created stuff on our site (and be it only in the addition of a “version X or later” clause), in which case we’d also have to keep track on the license differences between imported and newly written stuff.

3 Likes

I feel like this is a LOT of extra confusion for users. I certainly don’t know what the difference between licenses are, and due to not being lawyers, most users won’t care.

4 Likes

Well, it takes one user to care enough for a lawsuit, in order to get really expensive. And that user need not even act out of own interest.

One thing you really want to be sure to get right at a public-facing website is copyrights.

The rule is simple: Either we track all licenses, or we refrain from importing anything with the wrong license. There is no third option, as far as I can see, unless we want to open up the site to potential litigation.

And no matter which way we decide, a decision must be made. “I don’t care about licenses” is not an option here.

If an individual user doesn’t care about licenses, fine. Then that user can simply ignore the line “this post is under license X”. Whoever is legally responsible for the operation of the site cannot simply ignore it.

Well, I’m not going to admin the site because I lack the necessary knowledge, so I could just lay back and say, I don’t care, I’ll only write code and content, I’ll not be the one targeted by any lawsuit as long as any code or content I supply is clean. But I don’t want the project to fail due to legal issues. And that’s why I care.

2 Likes

So there’s a default license, but if the user wishes, they can specify which license they want? Would this not cause further legal trouble with certain licenses - furthermore, how would we counterract illegitemate licenses used by trolls or with malicious intent?

Well, I’d say content contributed directly on the site is under whatever license we decide on. But content imported from other places (in particular SE, should we decide on a different license) will be under whatever they were licensed under, unless the author(s) explicitly to relicensing. Any changes to such differently-licensed content will be licensed under that differing license, but with the extra clause that by changing it on the site, the authors agree that their contribution may be relicensed to the site’s license. This latter provision would mean that as soon as we get permission from the authors of the imported content, we can relicense to our chosen license without getting explicit permission from those who edited at our site.

Or in short, normally the user doesn’t choose anything on our site. Either it is contributed right on the site, then the license is determined by our ToS. Or it is imported, then the license is determined by whatever site we imported it from. Only users who authored imported posts (and can demonstrate that) have one choice: Namely the choice to allow us to relicense their old content to our chosen content license.

Note that this only applies to automatic imports; users that copy their texts by hand to our site cause our standard site license to apply, and by doing so they implicitly declare that they have the right to do it.

5 Likes

Given how scrambled up SE’s licensing is, it’s best to assume having multiple (specifically, three: CC-BY-SA 2.0, 3.0, and 4.0) licenses is essential for correctly importing, even if our license matches one of the CC-BY-SA versions.

3 Likes

This is something we should support for MVP, although not in its full incarnation necessarily.

We must have the ability to mark specific posts as being under a license distinct from other content on the site; this could be as simple as having LicenseName and LicenseLink fields on the post model that are null unless the content is differently licensed. However we do it, the ability must be there, because that lets us specify (in a configurable item) which license to use for posted content, while still being able to import SE content under a different license.

What we don’t have to do (and probably shouldn’t) for MVP is to provide the ability for users to choose the license for their own posts - there’s a discussion to be had about the merits of that, and it’s a bunch more development work that’s not essential to launch.

4 Likes

Actually, if we have such fields then they should not be null. Rather, they should be populated automatically with the current license for the system instance or community settings (I think I saw something once where Code Golf would prefer a little different licensing than the rest of SE due to the nature of the postings, but that is a separate discussion).

The reason is that this way if we should decide to change licenses at some point - not sure why, and certainly don’t want to do this frequently, and users must be given fair warning and have a say in the matter, this would make it clear (for system owners, users and anyone collecting content from us) what license a post has based on when it was created. Otherwise we end up with a mess as seen elsewhere.

7 Likes

I think this is a good idea. But I also don’t think it’s a good idea in the MVP.


Firstly I don’t think users should be able to pick a licence in the MVP. At Code Review what the OP licences their stuff under, probably, matters more than on other sites. If the OP’s code is not a licence I want the entire of my answer to be, then I have two options:

  • Not post an answer.
    1. Select the licence I want my text to be.
    2. Put a licence disclaimer around each and every code-block.
      I would also have to declare that it’s not dual licenced with the text licence.

Whilst I can see some nice benefits to this. I don’t really want to be the unfortunate soul that forgets to put a disclaimer and then suddenly I’m being sued for a licence violation.

Or a different unfortunate soul that has no clue about licences. I came to help someone with their code, and didn’t notice that my post and the OPs post are under different licences. Whatever that means. And so when I post my modified version of their program I’m committing a licence violation.


Even if you don’t allow users to pick licences. Then if you import a Code Review question, and I post an answer. I may still be committing a licence violation, if your default licence is different to Stack Exchange’s.


Note this could still effect other sites that rely on code. If I post an MCVE on SO and someone posts my MCVE with the fix, then that could be a licence violation.

There should be some safe-guards around this. And I don’t think an MVP is the place for them.

3 Likes

We can import those posts with the appropriate license by looking up last modification date and picking the license which was active at that time range. Although it’s debatable whether it’s right to consider the correct license the one which would have applied at the time of posting or at the time of last modification, but I think those are the 2 options to pick from if we want to display just one license.

Or, we could go the full context route and display all 3 licenses if the post was first created when 2.0 was active, then edited during 3.0 and 4.0 times, with links to corresponding revisions.

In any case I think it would be a good idea to display at least the latest license version for posts imported or quoted from SE.

2 Likes

Licenses are legal matter, and should not be taken lightly. In particular, just displaying several licenses for the complete content if several parts of the content are under different licenses is likely illegal to begin with.

Indeed, I would strongly suggest to not import anything where the applicable licensing is not crystal clear without consulting an actual lawyer first.

4 Likes

I work on Fedora, where a mix of code and content licenses is inevitable. I think this project could benefit from looking at our contributor agreement (which is not a license agreement or copyright assignment). It’s at https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement.

3 Likes

Whatever you do, please keep the licenses unobtrusive. Do the minimum to satisfy legal requirements, but try to keep it out of or faces as much as possible.

One example might be, a “license” link at the bottom of every page (which everyone except a lawyer will overlook and ignore), and a small “license” link at the bottom of each post that has a different license than the page as a whole. Whatever detailed nuances need to be explained about licenses and how they interact can be found by clicking the links.

3 Likes

I think there’s definitely value in simplicity. In fact, I’d say that that value in many cases outweighs the value of being able to import existing content.

4 Likes