Defensive Publications: Difference between revisions
(Direct nominations to the mailing list or forums. The Wiki pages are empty and will be deleted.) |
m (Typos & grammar. Added a few links. (Seems unfinished..)) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
Qt Project and [https://web.archive.org/web/20110718132815/http://linuxdefenders.org/about Linux Defenders] - an initiative of [https://www.openinventionnetwork.com/ Open Invention Network] - are cooperating on creating defensive publications about innovations in Qt. Generally, the goal of defensive publications is to document the Open Source body of knowledge so that it becomes relevant prior art for later patent applications and patent invalidations.<ref>https://web.archive.org/web/20150908052338/http://www.defensivepublications.org/defensive-pubs-faqs</ref><ref>https://www.nature.com/articles/nbt0202-191</ref> | |||
Defensive publications are comprehensive, typically one or two page technical reports that document ideas, describing how they work (usually, with some kind of visualization) and how they change the state of the art. There is no formal granting process like that of patents, and cost is negligible. As soon as a defensive publication has been accepted, the described innovation becomes state of the art and is no longer patentable by other parties. There are a number of examples of defensive publications on the Linux Defenders website. | |||
Open Invention Network submits defensive publications into a database searched by patent offices worldwide. The database is hosted on IP.com, a digital notary - thus, the documents are time-stamped and trusted. | |||
Qt Project and Linux Defenders | |||
Defensive publications are comprehensive, one | |||
Open Invention Network submits defensive publications into a database searched by patent offices worldwide. The database is hosted on IP.com | |||
== Authoring defensive publications on Qt == | == Authoring defensive publications on Qt == | ||
The goal is to identify the relevant innovative features or implementation details in Qt for every minor release (5.0, 5.1, …), create defensive publications about these, and publish them along with the Qt release. The developers of the feature and the author will be attributed in the publication. | The goal is to identify the relevant innovative features or implementation details in Qt for every minor release (5.0, 5.1, …), create defensive publications about these developments, and publish them along with the Qt release. The developers of the feature and the author will be attributed in the publication. | ||
=== Identifying new developments that are worth publishing === | === Identifying new developments that are worth publishing === | ||
Identifying | Identifying innovative or novel ideas simply requires input from the developers that are involved in the project along with an ability to recognize when things are done in an innovative way. Inspiration can be drawn from the Qt roadmap, the issue tracker, developer days and contributor summit presentations, and, of course, from the regular Qt development process. Every contributor is encouraged to flag features or commits as innovative, so that they may be taken into account for publication. Nominations can be sent to the [http://lists.qt-project.org/mailman/listinfo/development Development mailing list] or the [https://forum.qt.io/ Qt Forums]. | ||
=== Tracking the progress of defensive publication authoring === | === Tracking the progress of defensive publication authoring === | ||
| Line 23: | Line 19: | ||
== How to write defensive publications == | == How to write defensive publications == | ||
Defensive publications are one | Defensive publications are one or two pages and consist of the following elements: a title, a few paragraphs of text, a list of steps that need to be taken to recreate the invention, and at least one picture that describes the flow of data, the steps to be taken, or similar. | ||
Technology specific jargon should be avoided to make the defensive publication apply as broadly as possible. For example, | Technology-specific jargon should be avoided to make the defensive publication apply as broadly as possible. For example, one should substitute 'MySQL' with 'database'. | ||
It is | It is acceptable to contain references to other resources such as conference publications, magazines/books (preferably with ISBN/ISSN numbers), source code repositories, or software downloads. Since the documents are time-stamped, these references will be recorded, as well - making it easier for patent examiners to find the references. | ||
= FAQ = | = FAQ = | ||
Q: | Q: Do I need to perform a prior art search when writing a defensive publication to see if any patents cover the technology? | ||
A: No. Defensive publications do not have the same legal status as patents. Doing a patent search on statements of prior art does not make sense: you would needlessly limit yourself and do a lot of interpretation of patents, which is best left up to the courts. | A: No. Defensive publications do not have the same legal status as patents. Doing a patent search on statements of prior art does not make sense: you would needlessly limit yourself and do a lot of interpretation of patents, which is best left up to the courts. | ||
Q: | Q: Doesn’t writing defensive publications make me vulnerable for lawsuits, because aggressors can see in which direction I’m developing? Aren’t defensive publications the same as handing them a lawsuit on a silver plate? | ||
Latest revision as of 22:22, 26 December 2024
Qt Project and Linux Defenders - an initiative of Open Invention Network - are cooperating on creating defensive publications about innovations in Qt. Generally, the goal of defensive publications is to document the Open Source body of knowledge so that it becomes relevant prior art for later patent applications and patent invalidations.[1][2] Defensive publications are comprehensive, typically one or two page technical reports that document ideas, describing how they work (usually, with some kind of visualization) and how they change the state of the art. There is no formal granting process like that of patents, and cost is negligible. As soon as a defensive publication has been accepted, the described innovation becomes state of the art and is no longer patentable by other parties. There are a number of examples of defensive publications on the Linux Defenders website. Open Invention Network submits defensive publications into a database searched by patent offices worldwide. The database is hosted on IP.com, a digital notary - thus, the documents are time-stamped and trusted.
Authoring defensive publications on Qt
The goal is to identify the relevant innovative features or implementation details in Qt for every minor release (5.0, 5.1, …), create defensive publications about these developments, and publish them along with the Qt release. The developers of the feature and the author will be attributed in the publication.
Identifying new developments that are worth publishing
Identifying innovative or novel ideas simply requires input from the developers that are involved in the project along with an ability to recognize when things are done in an innovative way. Inspiration can be drawn from the Qt roadmap, the issue tracker, developer days and contributor summit presentations, and, of course, from the regular Qt development process. Every contributor is encouraged to flag features or commits as innovative, so that they may be taken into account for publication. Nominations can be sent to the Development mailing list or the Qt Forums.
Tracking the progress of defensive publication authoring
Writing a defensive publication is just another task on the way to a Qt release. These tasks are tracked in the Qt issue tracker and become part of the release roadmap.
TODO: How exactly are defpubs tracked in the issue tracker.
How to write defensive publications
Defensive publications are one or two pages and consist of the following elements: a title, a few paragraphs of text, a list of steps that need to be taken to recreate the invention, and at least one picture that describes the flow of data, the steps to be taken, or similar. Technology-specific jargon should be avoided to make the defensive publication apply as broadly as possible. For example, one should substitute 'MySQL' with 'database'. It is acceptable to contain references to other resources such as conference publications, magazines/books (preferably with ISBN/ISSN numbers), source code repositories, or software downloads. Since the documents are time-stamped, these references will be recorded, as well - making it easier for patent examiners to find the references.
FAQ
Q: Do I need to perform a prior art search when writing a defensive publication to see if any patents cover the technology?
A: No. Defensive publications do not have the same legal status as patents. Doing a patent search on statements of prior art does not make sense: you would needlessly limit yourself and do a lot of interpretation of patents, which is best left up to the courts.
Q: Doesn’t writing defensive publications make me vulnerable for lawsuits, because aggressors can see in which direction I’m developing? Aren’t defensive publications the same as handing them a lawsuit on a silver plate?