Hacker News new | comments | ask | show | jobs | submit login




It's really interesting that they decided to retain the full history! It also gives away some information about the initial contributors and the timeframe of when they started.


I love it. I've never taken a compiler class so going through and reading all the commits since day one is really fascinating. It's easy to see exactly how the language and structure of the code base came to be. Super cool in my book.


right!


Here are some visual aids that better shows how this project has evolved. It also shows how active things are today.

http://imgur.com/a/HyQWv


Anyone willing to make a Gource video?

https://github.com/acaudwell/Gource/wiki/Videos



It's cool to see that it was basically all Lattner at the beginning and his decisions about the license/exception still stand.

EDIT: License/Header in each of files were apparently retroactively added.


First page of commits if you'd like to see how the codebase iterated. Find it quite fascinating personally.

https://github.com/apple/swift/commits/master?page=819


Thanks. Actually, first page is 822 for me [0]

[0] https://github.com/apple/swift/commits/master?page=822



Look carefully at that copyright date: 2014-2015. They've rewritten history.


It looks like they used an automated tool to add copyright notices to files in the repository. Probably were required to do that by legal. So it's not 100% faithful history, but close.


This raises some interesting legal questions. If I start a git repo and only add a license in the Nth commit, does that license apply retroactively to a checkout of the first N-1 commits? What if I start out with one license but I change it in the Nth commit? If someone clones the git repo with the Nth commit in it and then checks out an earlier commit, which license applies?

(For simplicity, assume I am the only author of the repo, so I can always change the license arbitrarily whenever I want to.)


"does that license apply retroactively to a checkout of the first N-1 commits"

No, unless you explicitly state it somewhere (and even then, I'm not certain).

If they add a license to the older commits via rewriting history then yes, those older commits will now be licensed. If they don't do so, then copyright will be default i.e. you can't do anything with it.

Now, if they had a large history and didn't retroactively license files, but just pushed the repository out all at once, I have no idea if the license on the latest commit would apply to the older commits. In the end, the question is all about whether or not Apple has the legal ability to sue you for copyright infringement.


Is there any legal precedent for this? It seems like one could make a reasonable legal argument for either interpreting a repo as a single distribution or as a bunch of separate ones.


You can retroactively make a license more open, but you cannot retroactively make it more closed.


If I am the sole owner of a work, I can change the license of newly distributed copies from any previous license to any new license that I want to, even if the new license is more restrictive. The new license doesn't retroactively apply to copies that were distributed under the old license, only new copies distributed under the new license.

However, my original question still stands. If I hack privately on a git repo and never distribute it, and then I only add a license in commit N right before first releasing it publicly, what is the license of commits 1 through N-1, which do not contain a license themselves (or perhaps contain a different license) but were never distributed separately from the license contained in commit N?


Unspecified, so legally murky. But there's a notion of "implied license", so someone using the code could argue that "openly putting it somewhere publicly" constitutes and implicit license grant.

Note by the way that you are ALREADY explicitly granting some rights by putting it on GitHub:

We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

Arguing that this constitutes an implicit license to use this code probably wouldn't be too hard. However trying to relicense/redistribute is less likely. In the end this will have to be decided by a judge in court.


I'm a law student but not an expert, and I haven't researched the caselaw (yet?). Rcthompson, I apologize for taking this opportunity to go way beyond your question (see below). [This also reflects my assumption that you are coding within the US. And also this is not legal advice, merely hypothetical musing.]

Whatever you write, if copyrightable, automatically achieves copyright protection when fixed in tangible form - and you automatically obtain authorship rights. That gives you the right to grant licenses for any of the rights you've obtained (including to produce derivative works). Swift's license (https://swift.org/LICENSE.txt) allows you to modify the license of your additions (your right under federal law anyway), but not the sections you didn't author.

I mean... I can see it cutting both ways. On its face, it's a very fair system - you can use whatever you want but only own whatever you wrote. What becomes problematic is if companies (realistically) with wide distribution nets grab open-source code, modify it slightly, alter the license of the bundle and resell it. I know that's not a new phenomenon.

Another concern I see is if libraries or maybe files or something have proprietary names, then in theory you'd require an express license from the proprietor (in this case basically Apple).

I was concerned I didn't understand the basic question that prompted my response, which was from rcthompson, but he reframed it: commits 1 to n-1 have sort of Schrodinger's Cat licenses. They have copyright protection (regardless of any of this). And that grants you the right to control licensing of those rights (reproduction, public display, derivative works, etc.). But I don't see why you couldn't retroactively apply whatever you want. The Swift license applies itself, if you don't specify otherwise, upon submission of your work to the licensor (I guess per notice requirements). Until then it's unclear. However, federal copyright protections and state common and statutory laws would also apply (and would basically grant you the right to control licensing).


It depends on how the license was intended to be applied.

If you're the sole owner and declare the entire repository contents under XYZ, the previous commits would be available under the license, regardless of the actual commit that adds the license file. If you declare a specific revision under XYZ, then only that revision is under the license.

A different example is the case of a repository with many copyright holders changing the license, and not being able to drag all the previous code into the newly licensed version. You wouldn't be able to take all the commits in history under the terms of the new license.


That may be true for some open source/free software licenses, but I don't think it is true for all. It would depend on whether or not the license says it is irrevocable and whether or not the license is sub-licensable.

Let's suppose Alice gives Bob a copy of code whose copyright is owned by Charles, and the code was licensed to Alice under and open/free license.

If the license is revocable, Charles should be able to revoke the licenses for existing copies, and offer replacements that are more closed. Those who do not accept that replacement license should, I think, be able to continue using the copies they have but they will not have a license. Their rights will be limited to those rights that copyright law gives to owners of legally made copies. For software, that would mean they could use the code, but could not make and distribute copies or derivative works.

If the license is irrevocable, then Charles should not be able to take away existing licenses, but he may be able to stop issuing new licenses. That brings is to the issue of sub-licensing. If the license is sub-licensable, then when Alice gives Bob a copy, Alice can also give Bob a license via her sub-licensing right.

If the license is not sub-licensable, then Alice cannot give Bob a license. Bob's license has to come from Charles. So what happens if before Alice gives Bob a copy, Charles has decided to stop issuing new licenses?

I think Alice should still be able to distribute to Bob, because she has a license that allows distribution. Without a license from Charles, though, Bob would only be able to use the code for things copyright allows the owner of a particular legal copy to do without a license, which would be use it himself but would not include making and distributing copies and derivative works.

Alice might be able to argue that the terms of her license with Charles require Charles to provide licenses to those whom Alice distributes to, and so perhaps Alice could go to court to force Charles to keep granting licenses.

I don't recall enough from law school about third party beneficiaries to figure out whether Bob could sue Charles based on Alice's license to get a license from Bob for a copy he got from Alice, or whether, if Charles sued Bob for copyright infringement Bob could use Charles' contractual obligation to Alice in his defense.


You can retroactively do anything that doesn't change the status of existing copies held by others under valid licenses that don't allow you to force a licensing change.

You can remove GPL from something you yourself put GPL on, but existing copies held by others are still under GPL.

You can make something Apache licensed that was proprietary too, and old copies will remain proprietary unless you declare an exception valid for all existing copies under your copyright (which may be what you meant?).


They apply to those copies you added the notices in and any copy made from those with the notice.

If nobody ever has made a copy of a version without the notice, that effectively means that all published versions now are under that license and that nobody may use it under another license, because they have no legal source of it under any other license.

If there's already copies been made, those copies remain under the previous licenses if any (which may be "all rights reserved" as the legal default).


Whatever you write is copyright under the creator or the employer of the creator. What license you put past that is whatever you want, whenever you want.


It's also interesting that Lattner joined Github only in October.


They just made public the repo with the guidelines for Swift's evolution process: https://github.com/apple/swift-evolution/blob/master/process...


It's also interesting to see the graph of contributors (https://github.com/apple/swift/graphs/contributors). I noticed for example that Slava Pestov (The creator of the Factor programming language) has made a number of commits. Apple has hired some really smart people to work on Swift!

Edit: Also jckarter the creator of the Clay programming language is in there too!


Lexer.cpp: int X;

Interesting that they started with git, instead of even a very small section of working code first


I think it's because they need a repo before they can start collaborating, so it's best to set it up ASAP to allow people to start pushing code. In my opinion it also helps to set up the initial repo right away so you can benefit from version control features and be in the mindset of making proper commits instead of a huge initial commit that appears out of thin air.


Interesting there is no link to add issues to those repositories !


Probably because they will want to use radar for bugs and general discussion might be done like Linux mailing lists.

Edit yeah. that's basically how they are handling it but with the exception that they are using a public jira instance for language bugs, radar for xcode and nda bound bugs and a mailing list for general discussion.


https://bugs.swift.org/ <-- public jira instance




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: