| *** LaurenceUrhegyi has joined #trustable | 08:04 | |
| *** ctbruce has joined #trustable | 08:30 | |
| *** toscalix has joined #trustable | 09:01 | |
| *** mdunford has joined #trustable | 09:07 | |
| *** toscalix has quit IRC | 09:40 | |
| *** toscalix has joined #trustable | 09:41 | |
| *** LaurenceUrhegyi has quit IRC | 11:28 | |
| *** toscalix has quit IRC | 12:30 | |
| *** LaurenceUrhegyi has joined #trustable | 12:40 | |
| *** tiagogomes has quit IRC | 13:33 | |
| *** toscalix has joined #trustable | 13:47 | |
| *** tiagogomes has joined #trustable | 13:48 | |
| *** tiagogomes has quit IRC | 14:01 | |
| *** tiagogomes has joined #trustable | 14:17 | |
| LaurenceUrhegyi | if we do an analysis of MISRA and CERT rules and map out the over-maps / differences, we would be directly referencing propriety content. this obviously means we can't make that analysis open to the world and freely available. We have hit these brick walls in the past with 'derivative works'. | 15:56 |
|---|---|---|
| LaurenceUrhegyi | s/over-maps/over-laps | 15:56 |
| LaurenceUrhegyi | if anyone has any thoughts on this...or advice, we'd be interested | 15:56 |
| LaurenceUrhegyi | we can ask nicely the people who are involved in trustable and the C Saf/Sec Group and who are involved in MISRA and CERT, but that's about all i can think of | 15:57 |
| paulsherwood | we can reference propretary works citing fair use | 16:01 |
| paulsherwood | s/reference/reference and quote from, within reason,/ | 16:02 |
| LaurenceUrhegyi | ok, that's certainly helpful. I wonder if a deep analysis of each rule classes as 'within reason' | 16:02 |
| jmacs | Which one of the fair dealing exceptions do you think it would come under? | 16:03 |
| LaurenceUrhegyi | or does it just depend on how much we actually quote. we'll have a look into that | 16:03 |
| persia | "proprietary" is often over-applied. Check the specific license under which a work was received. If there is no explicit license, than it is probably safest to assume the Berne Convention applies. | 16:08 |
| persia | (which only protects the expression of an idea, not the idea itself) | 16:08 |
| persia | If you're uncertain, consult counsel (as my suggestion above is very much not that sort of advice) | 16:09 |
| LaurenceUrhegyi | we will | 16:11 |
| paulsherwood | copyright exists in the text, and in the overall layout/structure. it does not exist in the ideas | 16:17 |
| paulsherwood | so i believe, for example, that i could skim down the misra rules list, write my own summaries/interpretatin of each of them, and publish | 16:18 |
| persia | That matches my understanding, although I'm not qualified to assert it is true. | 16:19 |
| jmacs | There's only so many ways you can write "Don't use trigraphs", though | 16:20 |
| LaurenceUrhegyi | I think we have a way forward here | 16:20 |
| persia | jmacs: And there exists precedent in some jurisdictions that when one can only write something in one way, that expression is not subject to copyright (for a software-relevant example, look at SCO vs. IBM) | 16:21 |
| persia | My memory is that the ruling was that because a C header for certain structures could only be expressed sensibly within certain limits and still be SUS-compliant, that the textual content wasn't subject to copyright. | 16:21 |
| persia | But that's Nevada, US, which may or may not be citeable, depending on who complains about whom, and where. | 16:22 |
| jmacs | persia: When you have a chance, could you retell your argument that git is not a version control system, or point me at an argument for the same? | 17:07 |
| persia | Quick summary: git has no concept of "version". | 17:09 |
| *** LaurenceUrhegyi has quit IRC | 17:09 | |
| persia | I'll look for some of the interviews with Linus, to see if I can find a case of him making the argument. | 17:09 |
| persia | git is properly an SCM (source code management) rather than a VCS. | 17:10 |
| persia | Note that this does *not* make git inappropriate for use for many things, including tracking versions: it just needs additional bolt-on things to do so. | 17:12 |
| persia | tags are a good start, except that tags are mutable, so one needs a bit more metadata to force git to have something equivalent to subversion's "revision" concept. | 17:13 |
| persia | Some gerrits are configured to have super-repos, where each commit includes a reference to all the commits in all the repos one-level deeper, which provides an independent source of information about the sequence of commits in a given repo, although this can also be corrupted if someone has the ability to force-push or can otherwise redirect HEAD to point to a commit with a variant parentage history. | 17:16 |
| persia | I suspect there are other solutions to the problem, although I'm not familiar with them. | 17:16 |
| jmacs | I'm afraid I'm not clear on what the problem is; why is a SHA1 not a version? | 17:19 |
| persia | There's no enforcement of either ordering or consistent parentage in git. | 17:21 |
| persia | When I add a new commit, and point HEAD at that commit, I can have the commit point at a history with no relation to the history of the previous commit referenced by HEAD. | 17:21 |
| persia | Alternately, I can keep the same set of commits, but reorder the history of the commits. Doing so changes the SHA1s, but not in a way that is easily noticeable to someone pulling a fresh copy of the repository. | 17:22 |
| persia | (actually, not in a way that is noticeable to someone updating a repository as long as all reordering happened to commits since the last update) | 17:23 |
| *** ctbruce has quit IRC | 17:24 | |
| jmacs | I don't think that having a convenient alias like HEAD which can be changed stops something being a version control system | 17:25 |
| jmacs | And the ability to reorder the history sounds like a bug to me. I'd like to read Linus's opinions on it. | 17:28 |
| persia | I consider `git rebase -i` allowing reordering to be a feature :) I will share a link as soon as I find one. | 17:30 |
| jmacs | I do to, but I'd never expected a reordering to produce the same hash | 17:32 |
| persia | It doesn't, but `git gc` later deletes the original hash, so that an external person with a hash reference has no means to identify what code is being used. | 17:33 |
| jmacs | s/to/too/ | 17:33 |
| jmacs | A hash reference to the original hash? | 17:34 |
| jmacs | Er | 17:35 |
| jmacs | the pre-rebase branch? | 17:35 |
| persia | Yes. | 17:35 |
| jmacs | Right, so you lose a branch because git didn't think it was referenced anywhere | 17:37 |
| jmacs | I'm not sure what that has to do with reordering | 17:38 |
| jmacs | It's also behaviour I would expect from most VCS systems | 17:38 |
| persia | SCCS and SVN are not subject to that sort of problem. | 17:39 |
| persia | Because there is a core ordering of revisions. | 17:39 |
| *** ctbruce has joined #trustable | 18:31 | |
| *** toscalix has quit IRC | 19:04 | |
| *** ctbruce has quit IRC | 20:51 | |
| rjek | https://blog.elpassion.com/simple-and-terrifying-encryption-story-c1f1d6707c07#.smmzcu418 | 22:32 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!