Legal tool (licenses, public domain dedication, etc.) management application for Creative Commons
Home Page: https://creativecommons.org/licenses/
License: MIT License
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Deeds & UX:
djangodjango-poPotential Issues:
See file names (gettext translation domain) and Transifex resources.
deeds_ux)We must keep the Deeds & UX translations distinct from the Legal Codes translations. The latter are legal documents and require much stricter change control.
I continually want to download the plaintext versions of the licenses, so that I can bundle them with my software repositories. However, there are no easy links to the plaintext versions in the XHTML pages for the licenses. Adding a link would be very useful in cutting down on search time.
Here are the plaintext files I am thinking of: https://creativecommons.org/2014/01/07/plaintext-versions-of-creative-commons-4-0-licenses/
Here is an example of an XHTML page without a license file that is downloadable: https://creativecommons.org/licenses/by-sa/4.0/legalcode
There are a few possible solutions:
npm i cc-by-sa-4.0, for instance.Thank you! Great work, creative commons. :)
From info@:
Hi,
Looking for the text version of the CC BY IGO (3.0).
In theory, it should be here:
https://creativecommons.org/licenses/by/3.0/igo/legalcode.txt
As is the case (for example) with CC BY 4.0:
https://creativecommons.org/licenses/by/4.0/legalcode.txt
However that just bounces to a HTML version of the document,
which isn't useful for our purposes.
Any chance of getting that fixed in the very near future?
(This is not a launch blocker)
We are hoping to tightly couple RDF/XML generation with the new legal tools infrastructure. The new data models used in the Django app should be a good step forward towards simplifying the generation of RDF/XML.
Currently, as a stopgap measure, this application simply reuses the legacy RDF/XML (with known gaps and faults).
This application should be extended to generate RDF/XML files from "source" just like it does for the HTML documents.
The generated RDF/XML files must be deterministic and well organized and based on current RDF specifications. Application updates must include test coverage.
A resource used on the Creative Commons site should not violate CC best practices; however as I will show below, the 'language turnstile' icon currently in use on the site does violate them.
The Creative Commons website would have a translation-switching interface that either eschewed use of an icon altogether, or used one released using a CC legal instrument (ideally one of the more permissive ones to better align with the rest of the content on the site), rather than a non-CC license that uses CC branding against best practices.
https://creativecommons.org/images/language_icon_x2.png
I am certain the problem is not environment-specific.
2021-01-11: added example of someone switching from the icon to the 'additional context' section.
I don't know much about agile, what do the tags/projects the bot attached mean?
2021-02-10: changed 'additional context' section from paragraph to bulleted list form
Creative Commons does not currently provide easy to use LICENSE / attribution guidelines and snippets for GitHub repositories.
This project's documentation should be organized so that project maintainers can easily find LICENSE / attribution guidelines (ideally in multiple languages). For example, see santisoler/cc-licenses.
Additionally, we may be able to leverage Transifex to manage translations of the documentation in addition to the content.
This application is unaware of legal tool category (licenses or publicdomain).
CC0 should have publicdomain instead of licenses. For example:
https://github.com/creativecommons/cc-licenses-data/blob/main/docs/publicdomain/zero/1.0/deed.en.html#L120
The Public Domain Mark (PDM) is available at two URLs (no canonical URL):
There should be a single canonical URL for the PDM. Other URLs should redirect to it.
Plain text formats for the 4.0 licenses and the CC0 public domain dedication were created using a manual process. Only the English versions of the legal tools were formatted as plain text. Additionally, that manual creation process was not without errors and is not sustainable.
Extend the CC Legal Tools App to generate deterministic plain text versions of the 4.0 licenses and the CC0 public domain dedication (including all translations):
@CreativeCommons Suggestion: I often encounter a frustrating issue: the plaintext version of licenses is only available in English.
What I would like: just like you append.txtto get https://t.co/xj09QHxa8o, get https://t.co/7BinrQoJXI to work too.
Cleaning myself is long 😉— Matti Schneider (@matti_sg) January 5, 2018
Updated requirements given cc-legal-tools-app:
The CC 4.0 plain text licenses use lower characters (a, b, ...) in the third level of the numbering, e.g. Section 2(a)(1) or 2(a)(5), but the internal references use upper case letters (A, B, ...), e.g. Section 2(a)(6) or Section 3(a)(3). This is inconsistent and potentially misleading.
The HTML versions of the license text does consistently use upper cases across all third level enumerations and references.
Consistent naming equal to the HTML version.
I would be willing to capitalise those ~30 letters if I get a go ahead.
Documentation is wrong about Django translation domain
There are only two Django translation domains:
djangodjangojsSpecialties of Django translation:
The string domain is
djangoordjangojs. This string domain is used to differentiate between different programs that store their data in a common message-file library (usually/usr/share/locale/). Thedjangodomain is used for Python and template translation strings and is loaded into the global translation catalogs. Thedjangojsdomain is only used for JavaScript translation catalogs to make sure that those are as small as possible.
However, our README.md incorrectly states:
The Django translation domain and corresponding Transifex resource is different for each tool.
The previous wording of README.md was also incorrect:
Also note: What Transifex calls a
resourceis what Django calls adomain. I'll probably use the terms interchangeably.
and
For the license legal code, for each combination of license code, version, and jurisdiction code, there's another separate domain. These are all in cc-licenses-data under
legalcode.
I expect this confusion arose because Django translations utilize Gnu gettext, which bases its translation domain on the PO file name.
The Django domain for all of our translations is always django. Only the PO file name (Gnu gettext translation domain) and the Transifex resource slug are varied. The documentation should be accurate.
We must keep the Deeds & UX translations distinct from the Legal Codes translations. The latter are legal documents and require much stricter change control.
PR #166 Broke Deeds & UX translations. This also exposes a lack of test coverage.
Run docker environment and visit http://127.0.0.1:8000/publicdomain/zero/1.0/deed.es
Translated text should be displayed. Basic translation functionality should be covered by unit tests.
django (the default) to deeds_ux.Each repo in the CC organisation should have a .cc-metadata.yml file. This one does not.
The .cc-metadata.yml file should be present.
Currently, to set up the development environment, having python 3.7 and starting a separate Postgres server is required.
This process can be automated by creating a docker image for the Django server based on python 3.7 and using Postgres docker image. Then these images can be managed by docker-compose, hence requiring only a docker-compose up to start the server.
Email from user:
If i go to https://creativecommons.org/choose/ i see the license in
danish. I guess according to the browser language preferences.Then if i click the "Kreditering 4.0 International" to go to
https://creativecommons.org/licenses/by/4.0/ that page is in english.I would be nice if the first page in danish would keep the language to
the next page.To change the link:
https://creativecommons.org/licenses/by/4.0/
To:
https://creativecommons.org/licenses/by/4.0/deed.daOr whatever way is the best to keep the language across pages.
Perhaps good idea to have the same kind og language selection box across
pages instead of different ways to select language depending on what
page you are on.
Write initial legalcode translation process proposal and discuss with Caktus (technical) and Creative Commons Legal.
Goals:
CC should want to protect its users when possible, HTTPS is a means to do that. Even though the website that links to already redirect http to https, it is good stewardship.
Some links in the repo refer to external websites using http, this needs to change to https where possible.
We could also make these links protocol agnostic.
@TimidRobot indicated that they wanted to leave links to / within RDF alone. Could you elaborate @TimidRobot?
Translation directories should use locale name instead of language code.
creativecommons/cc-licenses-data:locale/sr-latn: sr-latn is a language code, not a locale name
How Django discovers translations | Translation | Django documentation | Django:
In all cases the name of the directory containing the translation is expected to be named using locale name notation. E.g.
de,pt_BR,es_AR, etc. Untranslated strings for territorial language variants use the translations of the generic language. For example, untranslatedpt_BRstrings usepttranslations.
Django offers a function to help with this: to_locale | django.utils.translation | Django Utils | Django documentation | Django:
- to_locale(language)
- Turns a language name (en-us) into a locale name (en_US).
Coverage of i18n/utils.py is incomplete (97.50%)
docker-compose run app coverage run manage.py test --noinput
docker-compose run app coverage reportName Stmts Miss Branch BrPart Cover Missing
----------------------------------------------------------------------
i18n/utils.py 72 1 8 1 97.50% 126
licenses/git_utils.py 83 0 36 3 97.48% 70->exit, 124->126, 140->145
licenses/models.py 241 0 50 1 99.66% 534->542
licenses/transifex.py 201 0 42 1 99.59% 285->293
licenses/utils.py 172 3 78 2 98.00% 60, 154-155
----------------------------------------------------------------------
TOTAL 1000 4 282 8 99.06%
15 files skipped due to complete coverage.
Complete test coverage
The docker environment is the primary supported development environment. It offers better parity with production and testing than a purely local pipenv and related services. However, the pre-commit hooks (as currently documented in README.md) act against the local repository, not the docker environment.
If pre-commit cannot be configured to work with the Docker environment, it should be dropped.
Regardless of wether pre-commit is dropped or its configuration is updated, the GitHub action should be updated to better minimize the delta between what is done in developer's environments and what is done via GitHub Actions.
The active_translation function in i18n/utils.py uses a private Django value (see Lines 95-128).
I wonder if the function duplicates the override function in django.utils.translation:
A Python context manager that uses
django.utils.translation.activate()to fetch the translation object for a given language, activates it as the translation object for the current thread and reactivates the previous active language on exit. Optionally, it can simply deactivate the temporary translation on exit withdjango.utils.translation.deactivate()if thedeactivateargument isTrue. If you pass None as the language argument, aNullTranslations()instance is activated within the context.
overrideis also usable as a function decorator.
The Transifex integration uses deprecated APIs (v2.0 and v2.5).
Introduction to the Transifex API 2.0 | Transifex Documentation:
We are deprecating the API versions namely API v2 and v2.5, to make way for the more usable and maintainable API v3.
As of April 7th, 2022 the API versions 2 and 2.5 will no longer be operational and relevant requests will begin to fail.
Introduction to API 2.5 | Transifex Documentation:
We are deprecating the API versions namely API v2 and v2.5, to make way for the more usable and maintainable API v3.
As of April 7th, 2022 the API versions 2 and 2.5 will no longer be operational and relevant requests will begin to fail.
Translation normalization uses resource_stats revision_date instead of translations_stats last_translation_update. This results in all languages having the same (inaccurate) date instead of a date for each language.
Instead it should be:
transifex_revision = dateutil.parser.parse(
self.translation_stats[resource_slug][transifex_code]["last_translation_update"]
)I found it confusing that https://creativecommons.org/licenses/by/3.0/us/legalcode and https://creativecommons.org/licenses/by/3.0/legalcode are different licenses. Maybe links between these different variants would help others avoid the same confusion?
Rename TRANSLATION_REPOSITORY_DIRECTORY to DATA_REPOSITORY_DIR.
TRANSLATION_REPOSITORY_DIRECTORY is a misnomer. The translations directories are subdirectories of that directory (the data repository directory).
It seems that the idea of using CC license URIs to refer to them is gaining ground as a (good) idea. See for instance the rights statements of IIIF Presentation API 3.0.
My concern is that because canonical URIs are not very explicit on the website and the RDF versions are not very obvious to find (which is normal), users might start to refer to licenses with some non-canonical URIs such as the https version, or the version ending in /deed, which seems like a bad idea...
I think canonical URIs of the various licenses should appear explicitly on the website, with an indication like "URI to use to refer to this license: XXX". One possible source of inspiration is https://rightsstatements.org/page/1.0/?language=en which makes the canonical URIs very explicit.
see IIIF/api#1874
In manage.py, line 10, the environment variable DJANGO_SETTINGS_MODULE doesn't point to a settings file.
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cc_licenses.settings")
DATABASE_URL key in the virtual environment.manage.py runserverdjango.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.It is expected that it should point to the local settings file.
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cc_licenses.settings.local")
This application must clearly and cleaning handle four different language code contexts:
pt_BR (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)
sr@latin (language@script: ISO 639-1 @ ISO 15924)
https://creativecommons.org/licenses/by/2.0/deed.sr@latin (404s, but there are enough log entries to indicate it should be a redirect)zh_TW (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)
the tag "
mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-cYrL-Mn" (or any other combination), and each of these variations conveys the same meaning: Mongolian written in the Cyrillic script as used in Mongolia.[...]
Although case distinctions do not carry meaning in language tags, consistent formatting and presentation of language tags will aid users. The format of subtags in the registry is RECOMMENDED as the form to use in language tags. This format generally corresponds to the common conventions for the various ISO standards from which the subtags are derived.
These conventions include:
o [ISO 639-1] recommends that language codes be written in lowercase ('
mn' Mongolian).o [ISO 15924] recommends that script codes use lowercase with the initial letter capitalized ('
Cyrl' Cyrillic).o [ISO 3166-1 alpha-2] recommends that country codes be capitalized ('
MN' Mongolia).
pt_BR (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)sr@latin (language@script: ISO 639-1 @ ISO 15924)zh_TW (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)ar-dz (language-region: ISO 639-1 - ISO 3166-1 alpha-2)dsb (language: ISO 639-2)sr-latn (language-script: ISO 639-1 - ISO 15924)zh-hans (language-script: ISO 639-1 - ISO 15924)django/django:django/conf/global_settings.p:Lines 50-148Each of the above contexts are the same when it comes to simple languages (no locale/region or script):
django/django:django/conf/global_settings.p:Translation normalization falsely detects translations on Transifex
docker-compose exec app ./manage.py normalize_translations -v3 -n
DEBU 23:58:59 <NOP> Deeds & UX (deeds_ux) af: Transifex already contains translation.
Normalization command should properly detect state and take appropriate action.
It is currently detecting language instead of translation.
Too much code is in management command which prevents it from being effectively referenced from multiple places.
Move transstats command's gen_statistics function to i18n.utils and include in publish command.
The transstats command generates a CSV file with translation statistics
Right now, the README file only has specific instructions for mac OS systems. For new contributors, who are working on some of their first open source projects on their linux systems, it might be a little difficult finding their way through setting up the project environment with postgresql and other dependencies
Add simple step by step instructions to clone and set up the project on linux based systems like Ubuntu. As these systems are widely used by developers and students, this will make it easier for new developers to start contributing to the project.
Coverage of licenses/views.py is incomplete (91.61%)
docker-compose run app coverage run manage.py test --noinput
docker-compose run app coverage reportName Stmts Miss Branch BrPart Cover Missing
----------------------------------------------------------------------
i18n/utils.py 72 1 8 1 97.50% 126
licenses/git_utils.py 83 0 36 3 97.48% 70->exit, 124->126, 140->145
licenses/models.py 241 0 50 1 99.66% 534->542
licenses/transifex.py 201 0 42 1 99.59% 285->293
licenses/utils.py 172 3 78 2 98.00% 60, 154-155
licenses/views.py 115 7 40 4 91.61% 52-55, 163, 167, 184, 390
----------------------------------------------------------------------
TOTAL 1002 11 284 12 98.06%
14 files skipped due to complete coverage.
Complete test coverage
Currently, the legalcode errata link at the top of the deeds doesn't do anything.
The Deed & UX translations are separate from the legalcode translations, but the application currently only exposes translations based on legalcode.
Both the deeds view and the legalcode view use the same function (get_languages_and_links_for_legalcodes):
https://github.com/creativecommons/cc-licenses/blob/f42b78db9c89d52924714340f3952dc792dac7bc/licenses/views.py#L136-L167
Translation strings in cc-licenses-data:
legalcode/
.po and .mo internationalization and localization files for legalcodeslocale/
.po and .mo internationalization and localization files for deeds, contextual information, and user interfacesThe interface (and generated files) should expose all of the deed translations
Currently, this Django application uses many custom gettext translation domains:
by-nc-nd_40by-nc-sa_40by-nc_40by-nd_40by-sa_40by_40zero_10In order to support these custom gettext translation domains, private Django objects must be referenced and manipulated. This introduces complexity and fragility.
If the following were implemented, all the translation data could use the default django gettext domain while preserving legal code cohesion:
.mo & .po files)legalcode
LC_MESSAGES
by-nc-nd_40.mo (resource slug.mo)by-nc-nd_40.po (resource slug.po)by_40.mo (resource slug.mo)by_40.po(resource slug.po)zero_10.mo (resource slug.mo)zero_10.po (resource slug.po)locale
deeds_ux (resource slug)
LC_MESSAGES
django.modjango.poby-nc-nd_40 (resource slug)
LC_MESSAGES
django.modjango.poLC_MESSAGES
django.modjango.poby_40 (resource slug)
LC_MESSAGES
django.modjango.pozero_10 (resource slug)
LC_MESSAGES
django.modjango.poEach of the resource slug directories would need to be added to LOCALE_PATHS settings variable.
Leave as-is?
django and djangojs (Translation | Django documentation | Django)Currently, only the English version of the CC licenses are available in plain text:
https://github.com/creativecommons/creativecommons.org/tree/master/docroot/legalcode
Would be nice to have all legal codes formatted in plain text along with their HTML versions.
I've created a personal repository to make easier to add CC licenses to GitHub repositories which doesn't host software: https://github.com/santisoler/cc-licenses
Recently, the repository got attention and started to being used by other people all over the world.
This week, we had some Pull Requests for adding translations of the license texts in plain text.
The contributors had reformatted the HTML version of the license texts and storing those plain text files on my own repository.
I think it would be much better if those files can live inside this repository, and mine can only link to the files stored here.
Although my repository is having attention, I don't do proper maintenance, don't check for possible typos or changes on the legal codes, so I may host old-dated versions of the license texts in the future without noticing.
Django templates offer very little control over whitespace. While this has little-to-no impact on end users, it creates the following issues:
Best practice appears to be to add Jinja2 support in addition to Django templates. This can be done for new work and then existing templates can be migrated as time allows.
Existing templates seem to use a lot of Django template features. I am not yet familiar enough with them to reproduce them with Jinja templates.
makemessages doesn’t understand the syntax of Jinja2 templates. To extract strings from a project containing Jinja2 templates, use Message Extracting from Babel instead. (Translation | Django documentation | Django)
Consider using "Notice" instead of "Disclaimer".
"Notice" may offer better clarity when translated. Per #145 (comment):
Thank you for working on this. Great that you are using Dutch as a translation example. I noticed that disclaimer is being translated to 'vrijwaring'. Which is in a legal sense a good translation, but not for notices that have no legal significance. I wonder if other translation will have the same issue with translating disclaimer.
Can I suggest that we rethink the word 'disclaimer' as a heading? Should we change that heading to 'notice'?
Unless we already have "Notice" as a translation key, it is probably best to leave this until after the initial launch.
The JS we supply in the Python section of the site (under /licenses/ ) is Free Software (this is an observation not a declaration), so it would be nice to mark it as such:
https://www.gnu.org/software/librejs/free-your-javascript.html
I would like to use CC0 to help me dedicate some of my software to the public domain. I would like to include a copy of CC0 with my software since that’s recommended. Parts of CC0 are legal code, so parts of CC0 were dedicated to the public domain under CC0. Parts of CC0 aren’t legal code, so parts of CC0 are licensed under CC BY 4.0.
Other than the Creative Commons trademarks (licensed subject to the Trademark Policy below) and the text of Creative Commons legal tools and human-readable Commons deeds (dedicated to the public domain as specified below), all content on this site is licensed under the Creative Commons Attribution 4.0 International license unless otherwise marked.
Creative Commons makes the legal code of its licenses and the CC0 Public Domain Dedication available under the CC0 Public Domain Dedication.
Quotes from “CC’s Licensing Statement for Content and Software Code” by Creative Commons (CC BY 4.0)
Elements of the license page that are not part of the legal code
Anything not specifically named as legal code above, including:
- “CC is not a law firm” disclaimer at top
- […]
Quote from “Legal Code Defined” by Creative Commons (CC BY 4.0)
I’m perfectly fine with adding some attribution information whenever I distribute a copy of one of the legal tool’s text. The problem is that most software developers who included a copy of CC0 with their code (or a CC license on their assets) probably didn’t know that they needed to provide attribution. I sure didn’t when I started using it.
Another problem is that this partial licensing situation is overly complicated.
Dedicate the entirety of each legal tools' text to the public domain. This would remove the requirement for attribution and make the situation less confusing. It would also cure the accidental violations that have already happened.
We could add documentation that explains this and gives attribution instructions for the legal tools' text. This would make it more of a hassle to use the plain text versions of the licenses.
Another possible solution is to include attribution information in the legal tools' text.
Neither of these alternatives would do much to address the accidental violations in the past. Neither would make the copyright situation less complicated.
It seems like CC intended to dedicate all of the legal tools’ text to the public domain anyway.
[…]the text of Creative Commons legal tools and human-readable Commons deeds (dedicated to the public domain as specified below)[…]
Legal text (we call this legal code) and Commons deeds: Creative Commons makes the legal code of its licenses and the CC0 Public Domain Dedication available under the CC0 Public Domain Dedication.
To me, legal text would be the entire text of a legal tool and legal code would be something different. Those quotes from “CC’s Licensing Statement for Content and Software Code” imply that they’re the same thing.
Translation metadata needs to be publicly visible
PR #201 added a specific version of pipenv (2021.5.29). This was required as the current version of pipenv (2021.11.5.post0) does not work well on Ubuntu 20.04, which is the current default for GitHub Actions.
See pypa/pipenv#4833 and PR #201 GitHub Action logs.
We should be able to use the latest version of pipenv (once it is not broken).
Once pipenv has been fixed, the specific version should be removed:
--- .github/workflows/pre-commit.yml
+++ .github/workflows/pre-commit.yml
@@ -61,12 +61,9 @@ jobs:
python-version: "3.7"
- name: Install pipenv
- # Use pipenv 2021.5.29 to circumvent errors with 2021.11.5.post0 on
- # Ubuntu 20.04
- # https://github.com/pypa/pipenv/issues/4833
run: |
python -m pip install --upgrade pip
- python -m pip install pipenv==2021.5.29
+ python -m pip install pipenv
- name: Install Python dependencies
run: |Code does manage Deeds & UX translations (only Legal Code translations)
check_for_translation_updates() and check_for_translation_updates_with_repo_and_legal_codes() only check legal code resource slugs. The Deed & UX resource slug and related translations are never referenced or managed.Deeds & UX translations should also be managed.
This application must not publish to creativecommons/cc-legal-tools-data main (default branch). Updates to creativecommons/cc-legal-tools-data main must only be done via approved pull request. This application should continue to publish to creativecommons/cc-legal-tools-data translation branches.
docker-compose exec app ./manage.py publish -b mainThe Aranese dialect is an Occitan variant not Occitan itself. Additionally, it should use a Django lowercase RFC5646 language tag instead of a POSIX locale.
cc-legal-tools-app/cc_licenses/settings/base.py
Lines 166 to 171 in 2f6c6af
The Aranese dialect should be properly identified and labeled. Per [Bug] Clearly handle the variety of language code formats and cases · Issue #157, the correct language code should be used and legacy codes should redirect to the correct language code.
Correct language code: oc-aranes (as listed in the IANA Language Subtag Registry):
oc is the ISO 639-1 language for Occitanaranes is the IANA registered variant subtagThe legacy ccEngine uses the POSIX locale oci_ES (cc-archive/cc.i18n:cc/i18n/mappers.py:Line 131)
The legacy legal code uses oci (with a jurisdiction of Spain (es):
by_3.0_es_oci.htmlby-nc_3.0_es_oci.htmlby-nc-nd_3.0_es_oci.htmlby-nc-sa_3.0_es_oci.htmlby-nd_3.0_es_oci.htmlby-sa_3.0_es_oci.htmlrename 'oc' (Aranes) to 'oci', since it's oci_ES in i18n module
aranes variant subtag was added 2018-04-22 (IANA Language Subtag Registry).licenses.utils has unused functions
evaluation command:
for f in $(grep '^def' licenses/utils.py | sed -e's/^def //' -e's/(.*$//'); do echo $f; echo; ag $f; echo; echo; echo; done
functions that are defined in utils and only referenced in tests:
get_code_from_jurisdiction_urlsave_dict_to_pofilestrip_list_whitespacecleanup_current_branch_output (may be useful for future development of branch status)Unused code should be verified and either documented as potentially useful for the future or removed.
Visiting any legal code page results in a a server error
cclicdev.creativecommons.org
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.